Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When to make bech32 the default -addresstype? #15560

Open
fanquake opened this Issue Mar 8, 2019 · 20 comments

Comments

Projects
None yet
10 participants
@fanquake
Copy link
Member

commented Mar 8, 2019

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.

@fanquake fanquake added this to the Future milestone Mar 8, 2019

@instagibbs

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

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

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

@fanquake

This comment has been minimized.

Copy link
Member Author

commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Mar 10, 2019

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

@moneyball

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

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

This comment has been minimized.

Copy link

commented Mar 11, 2019

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.

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

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.

@fanquake fanquake modified the milestones: Future, 0.19.0 Mar 21, 2019

@gmaxwell

This comment has been minimized.

Copy link
Member

commented Mar 23, 2019

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Mar 23, 2019

Many exchanges don't support it yet :(

See https://en.bitcoin.it/wiki/Bech32_adoption

@Sjors

This comment has been minimized.

Copy link
Member

commented Mar 26, 2019

@gmaxwell that PR is from a year ago, but could be a useful code example.

@harding

This comment has been minimized.

Copy link
Member

commented Mar 31, 2019

This was discussed in the most recently weekly meeting. My reading of the conclusion was that the project commits to switch to bech32 receiving addresses by default for the 0.20 release but will optionally switch at the 0.19 release if project members believe there is enough bech32 sending support in other programs and services at that time that the change won't be needlessly disruptive to inexperienced Bitcoin Core users.

Specifically mentioned in this PR's OP is the project announcing this planned change, but I didn't see anything in the discussion about how the project planned to make that announcement. Maybe a sentence in the 0.18 release notes or a post to the rarely-used bitcoin-core-dev mailing list?

@gmaxwell

This comment has been minimized.

Copy link
Member

commented Mar 31, 2019

0.18 release notes ACK from me, likewise mailing list sounds fine. We should mention that we'll send more announcements once we've decided on 0.19.

Should probably use language that makes 0.19 sound likely: my expectation is that we'll do 0.19 too unless someone shows up with arguments not to, and if it sounds too much like we won't, maybe the person with the golden argument won't make it. :)

@moneyball

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2019

FYI here is the draft Optech newsletter coverage of this issue in case anyone would like to provide feedback by end of day Monday prior to Tuesday's publication. https://github.com/bitcoinops/bitcoinops.github.io/pull/127/files#diff-6ade689824ee4c2e6d315bb25d14851aR56

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Mar 31, 2019

As a low-risk first step, I suggest to modify it in the GUI. A user in the GUI will see the tooltip right away and can choose a different address type on each occasion for each service.

Changing the default for the RPC is a bit more involved, since changing the address type is potentially no longer offered to the user on a case-by-case basis. (I think Gemini does it, but others might not or oversee it). So such a change needs to update the documentation, release notes, and optionally education through some optech newsletters.

See:

  • gui: Generate bech32 addresses by default #15711
@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Apr 2, 2019

There is a well-written section in the optech news: https://bitcoinops.org/en/newsletters/2019/04/02/#news

Would be nice if someone could copy-paste this to our ./doc/release-notes.md.

@nopara73

This comment has been minimized.

Copy link

commented Apr 3, 2019

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

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

Recent Bech32 sendability statuses:

Now the question is who'll have the balls to test the darknetmarkets and report his findings here? 😄

@harding

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

I've added the note suggested by @MarcoFalke to the release notes draft: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft#planned-changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.