Bitcoin Core 0.14.0 release candidate 1 available

[gmaxwell]

https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2017-February/000032.html

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release candidate 1 of a new major bitcoin Core release, version 0.14.0, has
been made available.

This is a release candidate for a new major version release, including new
features, various bugfixes and performance improvements.

Preliminary release notes for the release can be found here:

    https://github.com/bitcoin/bitcoin/blob/0.14/doc/release-notes.md

Binaries can be downloaded from:

    https://bitcoin.org/bin/bitcoin-core-0.14.0/test.rc1/

Source code can be found on github under the signed tag

    https://github.com/bitcoin/bitcoin/tree/v0.14.0rc1

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.14.0 final, otherwise
a new rc will be made available after these are solved.

Please report bugs using the issue tracker at github:

    https://github.com/bitcoin/bitcoin/issues

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJYqYjyAAoJEHSBCwEjRsmmyjwH/3J4ML+yUgj7j6hGr9/cQm4T
5I1lcGNIeh12qlJV/0ZlOI4U1gi+PgDUlGVflKWNN87h/S6XebGE5ovjF1bNZEed
KRB/gQTXQIg4v/rObslibs8W1LESGB6Ttif7icvUZ7uMFqP7N76tMOEQM8WGK6NZ
6v0fqTC15RoEkv+/y5ZwSYPm5F+ZT0JEBXMIIQ873nQ45JckJ3+aU4i321gn0KDk
kBm348wYqOqdEpQ7hpbMPStoXMrfsijM00FK5/98F5LTLubbf0a0+cdZDVak1t44
roLA2dfh3cYHFncEBFO4nJ71iSnbaqgfx9HRilfCF5O4zfDcZgWRKkUTHft1Z9o=
=2z+P
-----END PGP SIGNATURE-----

[1714024569]

1714024569

[1714024569]

1714024569

[gmaxwell]

The release notes are still a bit in flux.

There are some really nice performance improvements in 0.14 which aren't mentioned in the release notes yet.

Another major feature in 0.14 is support for after the fact fee bumping-- if a transaction is taking longer to confirm than you want, you can increase the fee.

The release notes make it sound like getinfo is gone completely. This isn't the case, it has been marked deprecated and will be phased out in the future. But for now the only change is that the help for it tells you not to use it anymore.

[Meuh6879]

what is the "share" folder and how is stored the mempool file indicated in the debug.log ?

[kolloh]

The release notes are still a bit in flux.

There are some really nice performance improvements in 0.14 which aren't mentioned in the release notes yet.

Another major feature in 0.14 is support for after the fact fee bumping-- if a transaction is taking longer to confirm than you want, you can increase the fee.

The release notes make it sound like getinfo is gone completely. This isn't the case, it has been marked deprecated and will be phased out in the future. But for now the only change is that the help for it tells you not to use it anymore.

Nice. I'm assuming the fee bumping is utilizing RBF to accomplish this and just providing an interface to make the process easy for users?

[-ck]

Nice to see the preciousblock feature. I assume you submit your block and then send the preciousblock message?

[achow101]

what is the "share" folder and how is stored the mempool file indicated in the debug.log ?

Can you ask that again with less broken English?

There is no "share" folder.

Nice. I'm assuming the fee bumping is utilizing RBF to accomplish this and just providing an interface to make the process easy for users?

Yes, that uses opt-in RBF. Your transactions will need to be created with RBF opted in though. AFAIK there is no GUI feature to bump the fee yet, you have to use the debug console.

Nice to see the preciousblock feature. I assume you submit your block and then send the preciousblock message?

Yes. The node needs to know about the block before it can be marked as "precious"

[LFC_Bitcoin]

The release notes are still a bit in flux.

There are some really nice performance improvements in 0.14 which aren't mentioned in the release notes yet.

Another major feature in 0.14 is support for after the fact fee bumping-- if a transaction is taking longer to confirm than you want, you can increase the fee.

The release notes make it sound like getinfo is gone completely. This isn't the case, it has been marked deprecated and will be phased out in the future. But for now the only change is that the help for it tells you not to use it anymore.

This is a great new feature, it will help a lot of people. Personally I'll wait until the stable version is released though.

[Real-Duke]

This is a release candidate for a new major version release, including new
features, various bugfixes and performance improvements.

Would you suggest that the performance improvements make this update possible for users with smaller hardware?
Still running my little node with 0.12.1 on a Banana Pi with 1GB RAM because I hadn't good experiences with 0.13.x on it
Thanks!

[Holliday]

Ran this for 16 hours and had a two issues.

Did not shut down cleanly (popped up windows error message).

When I started .13.1 immediately after, I noticed it was 2 hours behind even though I had 8 connections before shutting down .14.

This is on a clean (besides Core .13.1) Windows 10 install that is only used as a Core node.

[achow101]

Ran this for 16 hours and had a two issues.

Did not shut down cleanly (popped up windows error message).

What was the error? Anything in the debug.log?

When I started .13.1 immediately after, I noticed it was 2 hours behind even though I had 8 connections before shutting down .14.

IIRC it will rewind the blockchain a bit on the next start if the shut down was unclean so that any errors in the blockchain and the databases can be caught and fixed.

[nemgun]

I just had a look at the release notes, and i am really pleased by all the features i just found, you did a great job on this release, i am eager to test all the new implementations and changes.
Is it possible to have some examples of "-named" ? along with nested RPC commands ?
I awaited for a long time these features, and i am happy to see them in action, thank you.

[LLec]

If was to download this new release would I need to download the entire bootstrap again?

How many gigs is it as of right now?
Last time I checked it was counted off to the nearest over 100 gigs.

And no I won't be copying over the core from an old version.
HD crashed.
So starting from scratch.

[achow101]

If was to download this new release would I need to download the entire bootstrap again?

No. Upgrading to a new version of Bitcoin Core does not require redownloading the entire blockchain. Also, you don't need the bootstrap, that method is outdated now and will take longer than just letting it sync.

How many gigs is it as of right now?
Last time I checked it was counted off to the nearest over 100 gigs.

The blockchain is currently ~110 GB. However you don't need to store all of it if you enable pruning. Pruning will reduce the size on the disk to only a few gigs.

[Holliday]

Ran this for 16 hours and had a two issues.

Did not shut down cleanly (popped up windows error message).

What was the error?

Anything in the debug.log?

No, it abruptly ends. It doesn't display the normal shut down info.

When I started .13.1 immediately after, I noticed it was 2 hours behind even though I had 8 connections before shutting down .14.

IIRC it will rewind the blockchain a bit on the next start if the shut down was unclean so that any errors in the blockchain and the databases can be caught and fixed.

The above error occurs every time I shut down .14 yet I haven't had a repeat of needing to sync the last two hours upon restart, regardless of whether I start .13.1 or .14 after getting the error.

[achow101]

Anything in the debug.log?

No, it abruptly ends. It doesn't display the normal shut down info.

That is quite strange. Can you find any windows crash logs?

Do you happen to be running it with --disablewallet? If so, then this bug is known and has been fixed for the next rc.

[Holliday]

Anything in the debug.log?

No, it abruptly ends. It doesn't display the normal shut down info.

That is quite strange. Can you find any windows crash logs?

Do you happen to be running it with --disablewallet? If so, then this bug is known and has been fixed for the next rc.

Yes, I run with --disablewallet.

[achow101]

Yes, I run with --disablewallet.

Ok, good, not a new issue. The bug was fixed in https://github.com/bitcoin/bitcoin/pull/9817 which has been merged and backported.

[redicerock]

#8448 101c642 Store mempool and prioritization data to disk (sipa)
#9312 a72f76c Increase mempool expiry time to 2 weeks (morcos)

Does this affect the waiting time to get low-fee but above minrelaytxfee transactions cancelled and return them to our wallets? From my understanding, unconfirmed transactions will be back to the sender when they are dropped from the mempool of most nodes if they are not mined at all. And it usually takes a few days now.
With my little knowledge, it seems some users will have to wait 2 weeks rather than 72 hours and they can't expect the transactions will be evicted due to the restart of nodes after 0.14. I'm not really sure as I also heard some nodes/wallets rebroadcast the transactions constantly and it makes the mempool expiry time little or nothing.　(then why those transactions are back to the sender only in a few days.)
I know I can send RBF transactions or CPFP or sometimes doublespend even without RBF flag but i'm just curious because most users don't know how.

[achow101]

Does this affect the waiting time to get low-fee but above minrelaytxfee transactions cancelled and return them to our wallets? From my understanding, unconfirmed transactions will be back to the sender when they are dropped from the mempool of most nodes if they are not mined at all. And it usually takes a few days now.

First of all, transactions are not "canceled" nor "returned". When your wallet forgets about a transaction, nothing is sent back, it simply acts as if the transaction never happened.

With my little knowledge, it seems some users will have to wait 2 weeks rather than 72 hours and they can't expect the transactions will be evicted due to the restart of nodes after 0.14. I'm not really sure as I also heard some nodes/wallets rebroadcast the transactions constantly and it makes the mempool expiry time little or nothing.　(then why those transactions are back to the sender only in a few days.)
I know I can send RBF transactions or CPFP or sometimes doublespend even without RBF flag but i'm just curious because most users don't know how.

The previous expiry time was 3 days. However, often times transactions will either expire out of the mempool and be rebroadcast and subsequently put back into the mempool, so the expiry time did not matter at all. If your transaction is unconfirmed for more than 2 or 3 days, it will probably get evicted from the mempool anyways because the fee is too low. The minrelay fee has been changed to be dynamic for a couple of releases already. If a transaction remains unconfirmed for several days, its fee is likely too low and the minrelay fee will have moved to be greater than that transaction's fee rate so it is evicted anyways. Transactions that pay a sufficient fee will probably confirm within two or three days so this does not really affect that.

[gmaxwell]

Does this affect the waiting time to get low-fee but above minrelaytxfee transactions cancelled and return them to our wallets?

There is no "cancel and return" in Bitcoin, as mentioned.

Testing indicated that there was little difference in these cases both because they'll expire due to low fees, and also because there are parties going around aggressively rebroadcasting old transactions anyways. The artificial expiration mostly only had the effect of making it harder to get low fee long delay transactions in for those who care to make them.