When to make bech32 the default -addresstype? #15560

issue fanquake opened this issue on March 8, 2019
  1. fanquake commented at 11:23 AM on March 8, 2019: member

    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.

  2. fanquake added the label Brainstorming on Mar 8, 2019
  3. fanquake added this to the milestone Future on Mar 8, 2019
  4. instagibbs commented at 1:01 PM on March 8, 2019: member

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

  5. NicolasDorier commented at 1:31 PM on March 8, 2019: contributor

    Ledger Live https://github.com/LedgerHQ/ledger-live-desktop/issues/1842

  6. fanquake commented at 1:32 PM on March 8, 2019: member

    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.

  7. Sjors commented at 5:24 PM on March 8, 2019: member

    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]"

  8. fanquake commented at 2:11 AM on March 10, 2019: member

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

  9. moneyball commented at 7:36 PM on March 11, 2019: contributor

    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.

  10. bitschmidty commented at 8:02 PM on March 11, 2019: none

    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.

  11. MarcoFalke commented at 8:10 PM on March 11, 2019: member

    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.

  12. moneyball commented at 8:32 PM on March 11, 2019: contributor

    @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.

  13. moneyball commented at 6:36 PM on March 20, 2019: contributor

    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.

  14. fanquake removed this from the milestone Future on Mar 21, 2019
  15. fanquake added this to the milestone 0.19.0 on Mar 21, 2019
  16. gmaxwell commented at 5:54 AM on March 23, 2019: contributor

    https://github.com/blockchain/blockchain-wallet-v4-frontend/pull/193 < recent events

  17. MarcoFalke commented at 5:08 PM on March 23, 2019: member

    Many exchanges don't support it yet :(

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

  18. Sjors commented at 11:19 AM on March 26, 2019: member

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

  19. harding commented at 12:07 AM on March 31, 2019: contributor

    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?

  20. gmaxwell commented at 2:45 AM on March 31, 2019: contributor

    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. :)

  21. moneyball commented at 7:53 PM on March 31, 2019: contributor

    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

  22. MarcoFalke commented at 10:04 PM on March 31, 2019: member

    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
  23. MarcoFalke commented at 4:59 PM on April 2, 2019: member

    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.

  24. fanquake added the label Needs release note on Apr 3, 2019
  25. nopara73 commented at 4:05 PM on April 3, 2019: none

    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? 😄

  26. harding commented at 8:35 PM on April 10, 2019: contributor

    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

  27. fanquake removed the label Needs release note on Apr 16, 2019
  28. gmaxwell commented at 6:58 PM on May 29, 2019: contributor

    https://github.com/LedgerHQ/ledger-live-desktop/pull/2026

  29. fanquake commented at 7:19 AM on July 23, 2019: member

    Native Segwit support recently became available to end users in Ledger Live Desktop as part of the 1.11.0 release:

    🎊 Native SegWit is now available!

    Native SegWit, also known as bech32, is a new address format for Bitcoin that is more efficient and thus reduces the requires network fees. Native SegWit addresses for Bitcoin start with bc1.

    To start using native SegWit in Ledger Live, please create a new account and transfer your Bitcoin to it.

    Not all exchanges or wallet providers support sending to bc1 addresses, therefore Ledger Live still allows you to create compatibility SegWit (3 addresses).

  30. bitschmidty commented at 2:56 PM on August 20, 2019: none

    Some data to help with this decision from the just launched Optech Compatibility Matrix: https://bitcoinops.org/en/compatibility/

    Most wallets/services, of the ones we tested, support bech32 sending.

  31. MarcoFalke removed this from the milestone 0.19.0 on Sep 16, 2019
  32. MarcoFalke added this to the milestone 0.20.0 on Sep 16, 2019
  33. MarcoFalke commented at 1:56 PM on September 16, 2019: member

    This has missed the deadline in #15940.

    I think we can move forward with this in 0.20.0

  34. MarcoFalke added the label Wallet on Sep 16, 2019
  35. MarcoFalke added the label Up for grabs on Sep 16, 2019
  36. MarcoFalke added the label good first issue on Sep 16, 2019
  37. MarcoFalke removed the label Up for grabs on Sep 16, 2019
  38. instagibbs commented at 2:12 PM on September 16, 2019: member

    to be clear, I think that was the intention:

    Starting with Bitcoin Core 0.20 (expected about a year after 0.18), Bitcoin Core will default to native segwit addresses

    in release notes

  39. instagibbs commented at 2:14 PM on September 16, 2019: member

    What do we want to do about change type? Right now we do bech32 change if the wallet selected it, or if the recipient is using bech32. It might also be time to simple default to bech32, or whatever the user chooses in their conf.

  40. instagibbs commented at 4:04 PM on September 16, 2019: member

    Either way I think it's time, so I made a proposal PR to do so: https://github.com/bitcoin/bitcoin/pull/16884

  41. MarcoFalke closed this on Oct 2, 2019
  42. MarcoFalke removed the label good first issue on Oct 2, 2019
  43. MarcoFalke locked this on Dec 16, 2021
Contributors
fanquakeinstagibbsNicolasDorierSjorsmoneyballbitschmidtyMarcoFalkegmaxwellhardingnopara73
Labels
BrainstormingWallet

Milestone
0.20.0

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-21 15:14 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me