Bitcoin Forum

I really want to try this upgrade. :) Are we still on-target for it to be available tomorrow?

Go to https://bitcoin.org/bin/bitcoin-core-0.12.0/ if you would like to try the release candidate today. I think they're up to rc2 now.

Thanks for that link, but we seem so close to the real thing, that I thought I'd wait. As a relative newbie to Bitcoin, I don't feel capable of resolving any oddities in the release candidate. I'm keen to try pruning on a second computer for example.

Well, the irony there is that if you did discover an oddity, the development team (and any fellow sufferers) would likely really appreciate you reporting it on https://github/bitcoin/bitcoin (having checked first the issue has not already been identified). Whether that constitutes speeding the release up or slowing it down is subjective ("but it's more work to fix" v.s. "but known bugs==unfinished release"), but I can tell you that the software seems pretty robust at both rc1 & rc2 for me on Xen/Debian Linux.

I've also been running rc1 on Debian without any issue, syncing speed has improved a lot, and wallet now available with pruning mode enable.

Updating to rc2. :)

I think there will be an rc3 that will come out this week. Then the final version will be next week.

It seems that block relaying is still disabled with pruned nodes, unfortunately. I'll be skipping these RC's. One thing at a time, I guess... Good that it can be used as a wallet, pretty handy for those who like to use Core as their daily wallet.

Have you tried running in pruned mode yet?  I'm curious how much disk space bitcoin uses with that feature enabled

It is not disabled. New blocks will be relayed by pruned nodes. Says it here: https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md#direct-headers-announcement-bip-130

Possibly a 2016 LTE phone could be capable of running 0.12 in pruned mode. Seems inevitable that will happen at some point, if not this year.

Guess I messed that section on the release notes. I went straight ahead to the pruning part to see if block relaying was enabled or not and it redirects to the release notes of v0.11.0, so I assumed that everything related to pruning was still pretty much the same as it is on 0.11. My bad :)

Regarding BIP 130, all clients 0.10+ support this? That's what I gather from reading it...



That wouldn't be bad at all :)

No, only 0.12+ because the sendHeaders message does not exist prior to 0.12.

Then we're back to square one, at least until pretty much everyone updates. Good thing about this it will probably make most people update :)

Will the pruneing reduce the 60GB needed atm?

Yes, a pruned Core install takes much less space

How many GB can you save with this feature ? Also, will the pruned nodes still be considered as full nodes ? I'm pretty sure that the asnwer is no, but maybe...

With prune=550, the blocks and chainstate folder use about 2GB in total.

Wow ! That's awesome ! And what about the full node status of the Bitcoin Core wallet ? With such a pruning, I'm sure that it is no longer considered as a full node, but maybe, with some magic...

You still:

# verify all transactions
# verify all blocks
# relay transactions
# relay recent blocks (not old ones though)

the only thing you cant do with a purned node is help someone else to become a node, but thats not a requirement of a full node IMHO.

Wow , now to post a question for rokos

I'm running a full node over public WiFi, so I don't have any inbound connections. I suspect that prevents me from helping someone else to become a node.

Not necessarily, you create 8 outbound connections and one of them might go to a node that accepts inbound connections but is still syncing. As long as your node is not pruned you could help said node to sync up. Im not sure how the chances for that are though.

So this look promising, even if you're node won't be really usefull to the network. Can it still receive and send money ? Now I'm not sure since you don't precised it in the capacibilities of a pruned node.

You also can't rescan, which I suspect is what people will end up missing the most with pruning.

0.12 will send and receive money using pruning mode. 0.11.x cannot use the wallet in pruning mode.

When will the 0.12 stable version be out? I never upgrade when there might be teething problems, bugs etc.

Should be soon. I think it will be out in a week or so. Rc3 was just tagged today and I think it will be the last rc.

I've got a Satoshi.0.12.0 in my peer list right now.

I can't find anywhere to download it though.

The release candidate is here:

https://bitcoin.org/bin/bitcoin-core-0.12.0/test/ (https://bitcoin.org/bin/bitcoin-core-0.12.0/test/)

Would thast show up as 0.12.0 , or would it have some test suffix like rc3.

Uh, no -rescan? So, also no -wallet? I have a few different wallets. wallet1.dat, wallet2.dat, wallet3.dat

When I switch wallets, I usually have to shutdown Core, then start it with a -rescan while pointing to the other wallet.

What I could try to do, is make several separate folders or directories of core with each wallet, then prune each one. So for 3 different wallets, I'll be running 3 separate pruned nodes. Could also be separate machines (virtual or real.)

I'll definitely wait until then. Thanks as always bro!

In the peer list, it will show up as 0.12.0.

That'd work, though if I were you I'd just store the whole blockchain. At least on my machines, rescans tend to be a lot quicker than syncing.

In the future Core maybe needs something like:

- You keep the last n levels of ancestor transactions for each UTXO. Electrum servers do this. Then you can almost always rescan, but still save quite a bit of space (though the savings are unpredictable).
- Rescan using only the portion of the block chain that Core is keeping with the prune=<kept chain data in MB>. So if you do prune=20000 or something you'll probably always be able to usefully rescan.
- The ability to rescan by relying on an archival node (maybe one you trust) and bloom filters. Then you can run just one archival node and point your other nodes to it. Note that this is a massive privacy issue if you're relying on random public nodes.

Yes, -prune enable.

You decide how much space is dedicated to the blockchain.

Shouldn't this problem be solved with an HD wallet? In this case, it should be high on the priorities of core devs. I didn't know many people use bitcoin core as their wallet.

No, that's not the purpose of HD wallets (they provide one-time-only wallet backups and/with "master" public keys)

So who is currently developing core considering those who are working on Classic?

Everyone who has been working on Core still works on Core. No one jumped from Core to Classic.

If you want names:

• Wladimir J. van der Laan
• Luke-Jr
• Pieter Wuille
• Jorge Timon
• MarcoFalke
• Suhas Daftuar

To name a few.

I've been testing out 0.12.0rc3 in pruned mode, and have run into the following error message when restarting Bitcoin Core: "last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of pruned node)"

To reproduce:
0.) Start from scratch, deleting the entire Bitcoin data directory if it exists (leaving no wallet file or blockchain data).
1.) Install Bitcoin Core
2.) Create Bitcoin data directory if it doesn't exist, create bitcoin.conf, set "prune=550" without quotes
3.) Run Bitcoin Core
4.) After you've verified, say, 100,000 blocks, close Bitcoin Core. Wait until the warning window to not shutdown/restart computer completely closes.
5.) Run Bitcoin Core again, let it verify some more, close it again.
6.) Rinse and repeat step 5...

At some point, I get the above error message on starting Bitcoin Core.

I don't know what exactly is causing this, but if you're like me and you've verified a large amount of blocks and then you're told that you have to start completely over, you'll probably be pissed.

This error message is not new, as a related fix for this kind of error, when converting non-pruned nodes to pruned nodes was made here: https://github.com/bitcoin/bitcoin/issues/6345

While it's obviously easy to reproduce this error *if* you try plopping an *already existing* wallet.dat file into a pruned node data directory and then running Core -- that's not what I've been experiencing. I've been seeing this error with a brand new wallet.dat that was created from scratch *alongside* a fresh, pruned node.

Edit: If it's a brand new node from scratch, it seems that if you delete the wallet.dat after getting this error, a brand new one will be created, and the blockchain will continue to sync from where it left off, so at least there's that, though, it's still a bug.

Not sure what would cause this, but you would get a better response by posting on the github issue tracker. Or rather watch the issue thread that gmaxwell opened for you here: https://github.com/bitcoin/bitcoin/issues/7494

If everyone ran in pruned mode then would that be a problem?  How would a new node catch up from the beginning?  I'm sure it's just that I am missing the obvious point.  Sorry to be such a dummy.

Maybe the idea is at least a few nodes will always keep the full history?  I am willing to if that helps.

Correct, some nodes with the entire blockchain will always need to exist.

In the future Core will let you choose to "donate x GB to the network", and then you'll store a random range of historical blocks. Then nodes doing an initial sync will have to search out nodes that have the blocks they want from among these nodes storing chunks of the historical chain. It's a bit like how BitTorrent works.

I run a full node now on 0.11.2, is it possible to upgrade to 0.12 RCx and still serve the network?

Yes, just upgrade it.  Depending on what you mean by "serve the network" you'd want to avoid turning pruning on. 

How many nodes do we need to satisfy initial syncs?  https://bitnodes.21.co/ indicates there are over 5,800 right now.  That seems like plenty for sure.  As pruning becomes more popular, who's job is it make sure the number doesn't dwindle too low?

What would happen if managed to lose every copy of the old blocks?

Keep a copy on a USB stick.

Does it make any sense at all to think about paying folks running full nodes (with or without all old blocks) even if they aren't mining?

Paying them might get complicated. It could be worth giving them a partial refund on their own transaction fees though.

The question is how you distinguish a real node from a fake one.

Ah! That's beyond my level of knowledge. :)

there's no point having million nodes. 5000 is enough and they would easily handle millions of transactions.

much more important is for people to archive a copy of blockchain and validate it. in this way we can discover every possible problem, scam or attack.

I'm looking forward to this.
The reduced Blockcahin size would help a lot, its 60GB in size already indeed.
The first installation took about two days, as i remember.
This was way too long.

With pruning mode enable you still need to download and verify the entire blockchain, if you don't wanna do this try a hosted or SPV wallet.

Soon I think. Rc5 was tagged today and during the meeting today it was mentioned that rc5 would be the last rc for 0.12

This could be the greatest plus thing we need and then I would be more than happy in contributing again.
When you talk about future, how far is this future? thanks  ;)

I think it would be done now, if not for all the drama in the last year.

In 0.12 you can run a pruned node and you'll at least relay blocks on the tip.

I hope to see more sophistication maybe towards then end of the year; I'm hesitant to give any concrete numbers in the current climate.

RC4 or RC5 will be out soon, some additional bugs were discovered and taken care of.

So, running a full node is the only way to use Bitcoin in its most trustless form. But there's nothing stopping people from, say, running a full client to achieve this trustlessness, but still turning off the accepting of incoming connections so save bandwidth; well, that is, until *everyone* else decides to do the same, and then there isn't anyone left running an archival node from which to download the blockchain.

Full nodes enforce the consensus rules.  But even miners aren't directly incentivized to run their own full nodes. However, miners and businesses may rely on particular behavior from custom full node features that they may want to make use of, so they will often be incentivized to run their own full nodes for this purpose.

The two disadvantages to running a full node seem to be storage and bandwidth (unless you run some cpu intensive programs). Storage isn't really a problem with modern hard drives. So bandwidth seems to be the big disincentive. At the moment I'm running a full node for around eight hours a day with no inbound connections. This is part of my mobile computing research. Hopefully, this is of some samll benefit to the Bitcoin system.

It should fallback to inv messages in that case.  Is there a reason for not doing that?

Not sure. That is just what I understood from the release notes and the bip. I suppose a more definitive answer could be gotten by looking at the code.

It could just be that they assume that most will update reasonably quickly.  Once most people are using 0.12, pruning nodes will be connected to 0.12 nodes anyway.

It looks like they have a "revert to inv" flag which is set if the node doesn't prefer headers.

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L5411

The only thing the fPruneMode flag does is stop it going back to far when sending blocks.  So, I guess, nevermind then :).

In any case something like theymos said sound awesome to me, maybe because I first heard the word Bitcoin linked to Bittorrent (I don't even remember how and when).
Don't worry about giving some dates, no rush. Let the talking continue. Thanks

We tested rc5 on Debian. it seems to work ok

Can someone please post Bitcoin.conf? I'm not sure how this must look like now.
I'm interested for prune mode..I don't want synchronization 7 years..
as i understood this is gonna take about 2 gb space on hd, is this stable and safe?

I have downloaded version for Windows , 32 bit.
https://bitcoin.org/bin/bitcoin-core-0.12.0/

Just create a shortcut with the "Target" changed to "C:\Program Files\Bitcoin\bitcoin-qt.exe -prune=8000" (as an example). Just adding the "-prune=8000" at the end. 8000 means 8GB.

By the way, you will still need to download the entire 50GB blockchain, and the software prune the chain as it is being downloaded.

The name  "C:\Program Files\Bitcoin\bitcoin-qt.exe -prune=8000" specified in the Target box is not valid.Make sure..

But i also need to download entire blockchain so i have much time to figur it out. Very stupid from me.

Bitcoin Core 0.12.0 release candidate 5 binaries available:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012448.html

Im very tempted to try it by myself because I can't wait to test the increased speed on the software, but I think right now it would be a waste of time for me and I would rather wait. They should be releasing it pretty soon. Hopefully this is the last RC version but I don't mind a bunch of RC versions as long as the final is as solid as possible.

You still have to synchronize the full 7 years with a pruned node.

Bitcoin 0.12.0 has finally been tagged. The official release should be in a day or two after all of the gitian builds are finished.

I saw the news on reddit, I cant wait to see how fast it is compared to the current release thanks to the improvements.
Actually gmaxwell said that it's done and that version is the final one and that if there is any problems, they will fix it on 0.12.1

https://www.reddit.com/r/Bitcoin/comments/46f67s/bitcoin_v0120_has_been_tagged_for_release/d05hmkz

But I will wait until its listed here just in case:

https://bitcoin.org/en/bitcoin-core/

So please someone update the website soon.

Bitcoin.org will probably update sometime between today and Monday - I'm not sure when.

If you're really itching to try 0.12.0, I uploaded the binaries here:
https://mega.nz/#F!Q9MUgQZD!Wq44qDAtHzGEvifAxQIZbA

Verify them against the available gitian sigs (https://github.com/bitcoin/gitian.sigs). (Ie. look at the out_manifest section of the assert files in the gitian.sigs repo, compare those hashes to the files you download, and also gpg-verify the signatures on the assert files.)

Looking forward upgrading to the final 0.12.0 version, been running the 0.12.0RC versions for several weeks now
without any problems  :)

Core RC3 is good so far. I am synching right now, and I believe when I launched it, was 7 years and a few weeks behind. 10 minutes later, 5 years behind. SEEMS better at synching now than before.

Use the latest official release, rc5, or grab a build of the final. You can use Theymos's posted above or use mine at https://github.com/achow101/bitcoin/releases/tag/v0.12.0. Make sure you verify the checksums against the sigs at https://github.com/bitcoin/gitian.sigs.

I expect someone will make a torrent available of a fully pruned .bitcoin/ folder. You would need to trust them, but it would be a good fast way of getting your "full node" initialized if you do.

I don't think that will work, as you have to customise the pruning to your wallet. You can also set the pruning size, and I don't think all people will use the same value.

I just built a 0.12 (Bitcoin Core version v0.12.0.0-g188ca9c (64-bit) for a qt-wallet in a linux x64 system...

I'm lagging 4 days behind and I'm evaluating the performance on a quad core q8200 / 2.33ghz, 4gb ram / samsung 850evo. Validation threads are set manually to 4.

So, there are some points during the sync process where

- either network is downloading and cpu doing almost nothing
- network is not downloading much or at all and cpu is doing nothing (2-3% cpu use)

I use to think it was mechanical I/O lag as long as I had it in the mechanical disk, back in the 11.2 version, but now even that is excluded (due to SSD use / I'm also monitoring write/read/IO data and it's pretty low).

There are simply some points in which time is wasted for whatever reason and it's just plain faster to shut bitcoin-qt down, restart the wallet, and it immediately starts syncing faster again - chewing blocks fast instead of being stuck or doing them slowly.

11.1 used to be good, 11.2 I think had this type of performance regression / inconsistent syncing, 12 is similar - at least in my experience.

No, you can prune a previously full node.

Edit: Oh, an already pruned blockchain as a torrent download? That might work to drop in and have it generate a new wallet.dat. It doesn't generally work if you already have a wallet.dat that you want to use with it.

It's monday already and still no 0.12.0 in official site :(
Can you confirm if it will happen today? What happened. I am going to wait for the official site to update since it should be happening soon anyway and I don't have much free time this week so im not in a rush to update, but I thought it would be up today.

No idea why it hasn't officially been released yet. I will be asking this shortly in the mailing list.

It's supposed to be released today or maybe tomorrow.

So, the prune mode, how does it compare to Electrum, relative to size and setup time?

It takes way longer, because you still need to download the entire blockchain.

It uses way more space, because you still need to store a significant amount of data (~2 GB IIRC).

Anything I need to be aware of as a technical amateur? I'm running 0.11.2 simply as a way to store a portion of my stash safely. Anything I need to know when I upgrade to 0.12 ?

You can check the release notes at https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md but no, I don't think there is anything really that you should be worried about when upgrading.

Thanks bro, as always literally one of the most helpful, knowledgable posters I've come across here :)

It's official now: https://bitcoincore.org/en/2016/02/23/release-0.12.0/

Well this is odd.  I just updated from 11.2 and now I have a 'Pending' amount in my wallet that was not there before and there are no transactions for that amount that show in my wallet or blockchain for my address.

Did you do this transaction or is it an incoming one? It is weird that it doesn't show up on the blockchain, usually this is because it hasn't spread yet to the network, but im not sure how the pending stuff works tbh.

Not sure what would cause that, but a rescan might fix it.

Ok not sure what is going on.

I cant get Linux to recognize 0.12.0 exists.  It is almost like my registry is not updating.   I have also tried removing 0.11.2 and re installing using all the normal commands I use and when I try to load back on Ubuntu. I'm still on 0.11.2.    I have never had a problem in the past.  Any ideas?

Most likely, it's installed in more than one place so you've still got a copy of the old version after you thought you removed it. What happens when you run "which -a bitcoin-qt"?

Well, since linux doesn't have a registry, and I guess more the concern that you run a pool ... maybe this will help?
http://www.dummies.com/store/product/Linux-For-Dummies-9th-Edition.productCd-0470467010.html

The repos take a few days usually, if you installed from a repo (apt-get install ...) you need to wait.

Sorry was 2 am and had a few.  Intended to say repository not registry.  

Thanks that was it. They have it fixed now.

I maybe going crazy  :o I installed Bitcoin-qt 0.12 on OSX El Capitan, started it, it starts syncing then I stopped it so I can change the datadir to directory on my USB HD... I open finder (I enabled to see hidden files) and go to ~/Library/Application Support/ but NO Bitcoin folder there !! did something change with 0.12? can't find any info about it. Please help... I don't know where to put bitcoin.conf now

Not sure about your issue, but you cant change the datadir with the bitcoin.conf file as the file is within the datadir. You have to pass a path durring launch or create links.

It is solved after a restart of my laptop, the Bitcoin directory is visible now. Never seen this before on OSX but Bitcoin 0.12 is running fine now.

Question for you all:

I have enabled pruning in 0.12 on Mac OSX, but I did it via the command line rather than using a config file. But now, whenever I open Bitcoin Core by just clicking on the icon in my Applications folder (rather than opening it via the command line), it tells me I need to -reindex to go back to unpruned mode (which I don't want to do). It does not let me open my wallet without trying to redownload the blockchain.

If I'm understanding it right, in order to be able to have Bitcoin Core run in pruned mode by default whenever I click on the Bitcoin Core icon, I need to set up the config file. But for some reason, I'm having trouble setting it up. Can anyone help me trouble shoot?

- I've created a .rtf file named bitcoin.conf
- The ONLY thing in the file is: prune=1024
- The file is saved to /Library/Application Support/Bitcoin
- That folder must be my data directory, because it's where everything else is stored.
- After creating that file and closing it, I then go to start up Bitcoin Core. But it still gives me the same error message about needing to -reindex

Appreciate any input!!

You need to remove the rtf file ending. The file needs to be a simple text file, which an rtf file is not. It is best if you simply used a plain text editor and named the file bitcoin.conf.txt. Then in the file explorer renamed that file to remove the .txt part.

but this is an official version of bitcoin wallet?
who "create" and "share" it and decide the implementation?
sorry but I am a newbie and I need to know more in depth BTC

What I realy would like to see in an next version of Bitcoin Core,
would be an implement of Multisig to the UI.

Because I think this is a very useful "service" no other currency has and its a little bit "hidden".

This is Bitcoin Core, which is currently considered the reference implementation. It is an official wallet and it is based off of the original client written by Satoshi. The writers of the software include many people in the community, but most of them aren't active on Bitcointalk because good discussions don't happen here.