Bitcoin Core 0.16.0 brings not just the long anticipated SegWit implementation

[fabianji]

With the 0.16.0 version of the Bitcoin Core we are finally getting SegWit as the most notable upgrade but also the in 0.15.0 implemented "replace-by-fee" tag (to get stuck or slow transaction moving by adding extra mining fees) now set as default. The introduction the bech32 address format is probably the most critical for day-to-day interaction though as it affects compatibility with other wallets.

What are your feeling towards the most recent upgrade?

[1715286326]

1715286326

[vit05]

replace-by-fee" tag (to get stuck or slow transaction moving by adding extra mining fees)[/replace-by-fee" tag (to get stuck or slow transaction moving by adding extra mining fees)

This was already possible in other wallets, was not it? I think this change is very important since for some moments you need more agility and it is not so easy to calculate what would be the best Fee for this.

[buwaytress]

Oh this took me by surprise! Just a few days ago wondering if Electrum was the only wallet that fully supported native SegWit, and someone else was commenting that there didn't seem any plan from Core to do the same (mystified me) and here they are. That makes two wallet client users now able to use bech32, and puts to bed all those excuses from exchanges and services saying "we're not because core isn't".

theymos thinks it'll still take years for native to become ubiquitous but I sense this forum at least to get things going. Yep, time to kick myself into bech32 era and go full SW.

[LoyceV]

My personal favourite is a configurable location for -walletdir. Up until recently, I could symlink my wallet to any path outside it's own data directory, but version 0.15 disabled this standard Linux functionality ("for security reasons").
Version 0.16 makes this possible again. From the Release notes:

Wallets directory configuration (-walletdir)

Bitcoin Core now has more flexibility in where the wallets directory can be located. Previously wallet database files were stored at the top level of the bitcoin data directory. The behavior is now:

    For new installations (where the data directory doesn’t already exist), wallets will now be stored in a new wallets/ subdirectory inside the data directory by default.
    For existing nodes (where the data directory already exists), wallets will be stored in the data directory root by default. If a wallets/ subdirectory already exists in the data directory root, then wallets will be stored in the wallets/ subdirectory by default.
    The location of the wallets directory can be overridden by specifying a -walletdir=<path> option where <path> can be an absolute path to a directory or directory symlink.

Care should be taken when choosing the wallets directory location, as if it becomes unavailable during operation, funds may be lost.

[fabianji]

replace-by-fee" tag (to get stuck or slow transaction moving by adding extra mining fees)[/replace-by-fee" tag (to get stuck or slow transaction moving by adding extra mining fees)

This was already possible in other wallets, was not it? I think this change is very important since for some moments you need more agility and it is not so easy to calculate what would be the best Fee for this.

Yes this feature was introduced in 0.15.0 but the new release sets it as default...

[Kakmakr]

It is actually unbelievable how many people are in some way involved with this, if you look at the credits in the Release documents, https://bitcoin.org/en/release/v0.16.0

I just hope my local exchange and Ledger will switch to Bech32 now, because both of them use multisigature (P2SH) addresses.

In any way, thank you to everyone involved in this. We appreciate every little contribution to improve this technology.   

[TheQuin]

There seems to be a large increase in the percentage of Segwit transactions since 0.16.0 was released which I'm sure is not just coincidence.

http://segwit.party/charts/#

Last 7 day snapshot

[1Referee]

There seems to be a large increase in the percentage of Segwit transactions since 0.16.0 was released which I'm sure is not just coincidence.

It's not coincidence. Bitcoin Core is the main client people were waiting for in order to utilize Segwit, and that was the case for me as well to a certain extent. I am in the process of creating new backups, paper wallets, etc, all Segwit. I think before the end of this week, I am completely moved away from the legacy addresses, which feels great.

Another sign of Segwit being utilized is when you look at the addresses showing up here second after second; https://blockchain.info/unconfirmed-transactions

I am sure that within two months from now, Segwit transactions will have taken over to such an extent, that legacy transactions will become the minority.

[fabianji]

It is actually unbelievable how many people are in some way involved with this, if you look at the credits in the Release documents, https://bitcoin.org/en/release/v0.16.0

I just hope my local exchange and Ledger will switch to Bech32 now, because both of them use multisigature (P2SH) addresses.

In any way, thank you to everyone involved in this. We appreciate every little contribution to improve this technology.   

Yes true it is amazing to see how many dedicated members of the community are working to gather to bring this to the next level.

My sincere gratitude!

[HCP]

I just hope my local exchange and Ledger will switch to Bech32 now, because both of them use multisigature (P2SH) "P2SH-P2WPKH SegWit" addresses.

Just for the record: All MultiSig Addresses are P2SH addresses... but NOT all P2SH addresses are MultiSig Addresses.

Or, to put it another way, just because an address starts with a "3", does NOT mean that it is a MultiSig address.


However, I agree... hopefully the implementation of bech32 addresses in Core will help uptake and enabling of "native" SegWit across more wallets and platforms.

[fabianji]

There seems to be a large increase in the percentage of Segwit transactions since 0.16.0 was released which I'm sure is not just coincidence.

http://segwit.party/charts/#

Yes SegWit usage hit 30% for the first time!

[Bluecore]

Segwit adoption is as high as it has ever been. Hardware wallets have Segwit on by default. Every week a new mobile wallet adds Segwit support.
What a time to be alive!

[hugeblack]

I am sorry because my question is off-topic, but I don’t want to create a new topic
why Bitcoin Core 0.16.0 developers start using/enabling native segwit addresses by default while sign message/verify message doesn’t support segwit addresses? I know this is because some RPCs do not yet support segwit addresses but why they make it default? "it’s better to make a new private key and full support segwit by default, correct?"
Sources : https://bitcoin.org/en/release/v0.16.0

[TheQuin]

I am sorry because my question is off-topic, but I don’t want to create a new topic
why Bitcoin Core 0.16.0 developers start using/enabling native segwit addresses by default while sign message/verify message doesn’t support segwit addresses? I know this is because some RPCs do not yet support segwit addresses but why they make it default? "it’s better to make a new private key and full support segwit by default, correct?"
Sources : https://bitcoin.org/en/release/v0.16.0

This might help a little: https://bitcointalk.org/index.php?topic=2885058.msg29664816#msg29664816

My doubt, regarding signing in segwit address is if this is a "bug" and will soon be corrected, or is it an abandoned feature?

It is neither a bug nor an abandoned feature. It is just that we are still working on creating a more generalized signing scheme that lets people sign with things like P2SH addresses (e.g. sign with a multisig address). There is simply no standard yet for signing with such scripts or with Segwit.

Note that you don't actually sign with an address. You sign with a public-private keypair and your wallet interprets it as an address. Your wallet could just as easily interpret it as a segwit address. We are working on creating something that actually specifies the address type, and more generally, allows signing with scripts.

But don't be afraid to start a new topic if you still have further questions.

[cellard]

I was disappointed to see that they haven't bothered to add an option on the GUI to change between legacy-nested-bech32. I want to create a legacy address and I can't find this option. I assume I will need to add some sort of command on the shortcut or something. Same for bech32. This is annoying because you have to restart the wallet everytime you want to create an address of a different format. Oh well, I hope they add this in the next update.

[TheQuin]

I was disappointed to see that they haven't bothered to add an option on the GUI to change between legacy-nested-bech32. I want to create a legacy address and I can't find this option. I assume I will need to add some sort of command on the shortcut or something. Same for bech32. This is annoying because you have to restart the wallet everytime you want to create an address of a different format. Oh well, I hope they add this in the next update.

Start with the default nested option then go to the Receive tab and check the Generate Bech32 address box.

https://i.snag.gy/R2HXGl.jpg


Edit: Obviously doesn't help for legacy '1' address.

[cellard]

I was disappointed to see that they haven't bothered to add an option on the GUI to change between legacy-nested-bech32. I want to create a legacy address and I can't find this option. I assume I will need to add some sort of command on the shortcut or something. Same for bech32. This is annoying because you have to restart the wallet everytime you want to create an address of a different format. Oh well, I hope they add this in the next update.

Start with the default legacy nested option then go to the Receive tab and check the Generate Bech32 address box.

https://i.snag.gy/R2HXGl.jpg

Oh shit how did I miss that? Anyway, but how do I generate a legacy address? Again I guess I just need to add some command and reboot or something? because I can't see it on the GUI. I will check the documentation later, im at work now and I shouldn't be posting, but anyway, this is how it should look like IMO:



I expected something like this. With this design you can't miss it. You get the 3 formats and you get to generate them easily before making a payment request. I added the parenthesis with the (1....) etc so noobs don't get confused. I think it looks neat.

[TheQuin]

Oh shit how did I miss that? Anyway, but how do I generate a legacy address? Again I guess I just need to add some command and reboot or something? because I can't see it on the GUI. I will check the documentation later, im at work now and I shouldn't be posting, but anyway, this is how it should look like IMO:

So far the only way I have found is from the console window:

getnewaddress -addresstype legacy

I expected something like this. With this design you can't miss it. You get the 3 formats and you get to generate them easily before making a payment request. I added the parenthesis with the (1....) etc so noobs don't get confused. I think it looks neat.

Agreed, that would be a lot easier.

[BenOnceAgain]

With the 0.16.0 version of the Bitcoin Core we are finally getting SegWit as the most notable upgrade but also the in 0.15.0 implemented "replace-by-fee" tag (to get stuck or slow transaction moving by adding extra mining fees) now set as default. The introduction the bench32 address format is probably the most critical for day-to-day interaction though as it affects compatibility with other wallets.

What are your feeling towards the most recent upgrade?

I think those are great additions, I especially like bech32 addressing though I recognize it will take a long time before their use is commonplace.  The BIP-0173 that describes bech32 is really a great example of a standard that takes into account the real-world considerations of an addressing scheme (QR scannability, mixed case, etc.).  I hope bech32 is more widely implemented ASAP, including on other cryptocurrencies, especially ones based on BTC addressing.  Having a human-readable prefix that clearly differentiates between various crypto assets is a great boost to usability as Bitcoin adoption grows to less technically savvy people.

Replace by fee is a great attribute to have enabled by default in Core.  I've never had to use that, but I think it may have more utility in a world where mining effort is flipped between competing currencies based on which one delivers the best ROI at a given moment.  Which is selfish, in my view, but I do understand that from a business perspective.

Bitcoin Core's approach to incremental improvements in the reference client and underlying protocol is in my view the best approach to take.  When dealing with significant sums of money, every change should be subject to careful deliberation.  Bitcoin, as the first and largest cryptocurrency, also has an added responsibility to avoid missteps that could inflict larger harm on the overall crypto asset community.  That is a consideration I keep closely in mind because I know that legacy finance would have a field day with any issue.  Given that, frankly I am very surprised to see them all bandied around the Enterprise Ethereum Alliance.  I don't know what to make of that organization.  I have concerns about Ethereum's stability and clearly demonstrated violations of immutability.  I suppose these can be overcome if enough effort were put into improving these things, though immutability concerns will remain.  Then again, some of these large legacy financial institutions probably like the idea of being able to rewind the clock.

I don't.

Best regards,
Ben

[Rath_]

I hope bech32 is more widely implemented ASAP, including on other cryptocurrencies, especially ones based on BTC addressing.  Having a human-readable prefix that clearly differentiates between various crypto assets is a great boost to usability as Bitcoin adoption grows to less technically savvy people.

Thanks to the 0.16 Bitcoin Core update, bech32 might become more popular in short period of time. It isn't default type of address, though. If they forced people to use them then the adaptation would be much faster but there are many services and exchanges which still don't support sending to such addresses. It looks like they don't really care about fees.

I really like your attitude to Bitcoin Core's actions. Most people would like to push a lot of upgrades as soon as possible. It causes a lot of technical problems and tension in the community. Since scalability problem seems to be solved for now (assuming that Lightning Network will succeed soon), maybe it's time for making transactions more private? Although, I'm afraid that this could lead to ban of Bitcoin in more countries.