Bitcoin Forum

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?

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.

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.

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 (https://bitcoin.org/en/release/v0.16.0):

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

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.   

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 (https://i.snag.gy/rnhBav.jpg)
https://i.snag.gy/rnhBav.jpg

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.

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!

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.

Yes SegWit usage hit 30% for the first time!

https://pbs.twimg.com/media/DXHHSR7XcAANCqo?format=jpg

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!

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 (https://bitcoin.org/en/release/v0.16.0)

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


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

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
https://i.snag.gy/R2HXGl.jpg

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

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:

https://cdn.pbrd.co/images/H9TqCIJ.png

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.

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

getnewaddress -addresstype legacy



Agreed, that would be a lot easier.

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

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.

The market has to demand that services and exchanges support the features/improvements that they want.  Service providers are not inclined to do any more work than their customers demand until they reach a point that they have to expand functionality in order to attract new ones.  It's unfortunate, but unless the business sees a direct benefit (ROI) to implement this or that, they have no incentive.

But, like the very careful and deliberative improvements in Bitcoin Core, they also need to be careful with deploying upgrades to their platform.  If I were an exchange, I'd hope I'd be able to have some staff engaged in the evolution of Bitcoin, at least aware of what is coming so that code to support potential PRs could be written and begin QA when it was still in pre-release.  I know there are extra costs involved in doing that, but I also see extra benefits and believe that key influencers in the market would also notice and that could be a benefit from a marketing perspective.  I think it's responsible for any major crypto business to figure in enough of a testnet infrastructure as well as a certain amount of payroll that would subsidize staff participation in the underlying open source projects.

That's my view, I don't believe that every business should wait until something is "in Core" before they begin planning for things that are very likely to be in the next release.

Best regards,
Ben