When to make bech32 the default -addresstype?

[fanquake]

From gmaxwell on IRC (line 435).

We've been able to send to bc1 addresses since 0.16.0 which was released feb 2018.
Should it be a goal for 0.19? 0.20?
Bitcoin core makes it pretty easy to get other addresses when you need them for compatiblity, fortunately.

when satoshi completely broke compatiblity with the p2p protocol, he gave two years time for people to upgrade. On one hand, that was a much harder break, on the other hand, it as a much smaller ecosystem at that time.

I'm somewhat disappointed to see that some parties that I've past identified as tech leaders still don't have sending support... which is an argument against rushing.
But maybe announcing a plan to default by version X might help some parties prioritize.

[instagibbs]

Might be worth figuring out which larger services/wallets cannot decode them and figuring out what the blocker there is.

[NicolasDorier]

Ledger Live LedgerHQ/ledger-live-desktop#1842

[fanquake]

https://twitter.com/Ledger/status/1095971576229580800

It's on our roadmap but we can't provide an ETA unfortunately. The on-device apps support bech32 but there's still back-end and front-end engineering to be done. For now you can use Electrum to enjoy bech32 on your Ledger Nano S.

[Sjors]

I think we can make it the default in 0.19, if we make it super obvious in the GUI how to get a p2sh address. Something like "Looking for an address starting with 1... or 3...? Click here. [but blah blah, most wallets can handle bech32... blah blah save fees]"

[fanquake]

Maybe something for @bitcoinops? cc @moneyball, @jamesob.

[moneyball]

I worked pretty closely with the folks at BRD, who developed the whensegwit initiative, and I know they are keen on pushing the ecosystem toward widespread adoption of bech32 addresses. The first step for any service is quite clear - supporting sending to bech32 addresses, which is relatively easy to implement and does not introduce any complications for users. As noted by @gmaxwell, Core wallet has been able to do this since v0.16, and many other wallets support this too (whensegwit.com has a list).

Nevertheless, it is still far from 100% adoption and thus any service supporting bech32 receive addresses creates a risk of user confusion if the user attempts to send funds to a Core bech32 address from a wallet that doesn't support sending to bech32 (and thus would fail for the user). Optech is planning to research this further (similar to the RBF in the Wild research) to ensure the list is as comprehensive as possible. This will give services an idea of potentially how much user confusion might be created by generated bech32 receive addresses. Optech also does proactive outreach to services that don't yet support sending to bech32 addresses.

There are several UI options a wallet can consider for bech32 receiving addresses, depending on a number of factors such as how the wallet is marketed/positioned, how sophisticated its userbase is, its ability to handle customer service requests, and its attitude toward pushing for ecosystem wide adoption.

UI options:

1. Show only backwards compatible addresses. Wait to support receiving bech32 until broader adoption. [most conservative position]
2. Show backwards compatible addresses by default. Separately show an "advanced user" option that provides sophisticated users the ability to generate a bech32 receiving address. As the user has to go out of their way to do it, the odds of them being confused if it fails and generated a customer support ticket is reduced. [fairly conservative position]
3. Show bech32 addresses by default. Separately show a "backwards compatible" option that provides an escape valve in case a user is trying to send funds from a wallet that does not yet support sending to bech32 addresses. [more aggressive position]

What is being proposed in this PR is option 3.

The team at Optech has a number of other ideas we're considering to help with adoption, and we will follow up here within a week proposing additional steps we can take to help with this. It is likely that some of our work will aid in determining which version of Core should adopt the more aggressive stance on receiving bech32 addresses.

[bitschmidty]

For testing Bech32 support across Bitcoin services, Optech's initial tests are to include:

• Does wallet allow sending to Bech32
• Which receive address types are supported
• What is the default receive address type
• UX of each via screenshots and screen recordings

If there is another aspect of a Bitcoin service's handling of Bech32 that would be useful, I am happy to test that as well.

[maflcko]

https://whensegwit.com/ does not include wallets/exchanges that do not support sending to a bech32 address, so it seems not too useful in the context of the brainstorming in this issue.

Last time I checked, at least Gemini (exchange) would not support sending to bech32 addresses. Not sure if this changed in the meantime.

[moneyball]

@MarcoFalke See @bitschmidty's post above - we plan to do research that will identify services that do and do not support bech32. This should help with Core's decision.

[moneyball]

Also, Optech started a 24 week(!) bech32 educational campaign in this week's newsletter. https://bitcoinops.org/en/newsletters/2019/03/19/

I suspect there is a good chance that by August we'll have more information to inform the decision whether v0.19 should make bech32 the default address type.

[gmaxwell]

blockchain/blockchain-wallet-v4-frontend#193 < recent events