utACK 4959aa9a62ded74fcd343d6e402c79e3ebcba241
Needs squash.

Please see this comment #11991 (comment)

tl/dr: Maybe "spend from" is not correct phrasing, but clicking this checkbox once won't reduce all your future transaction fees either

Although I'm fine with this change, I think #11937 is a better solution for users who launch with -addresstype=legacy, because it also lets users select P2SH wrapped SegWit.

If #11937 is merged, I think it's more clear to hide the checkbox when the user switches to legacy, if only so they don't forget to switch back to p2sh.

There's a certain airdrop coin that just switched to using bech32 without SegWit. In addition bech32 is used by Lightning, so calling this "native segwit" might lead to confusion. I also don't think the phrase "native SegWit" is any less intimating than "bech32".

Maybe call it "Use modern address format (Bech32)?"

Adding support back for -addresstype=legacy makes the tooltip either longer or more vague, because you can't mention "P2SH wrapped SegWit". But not the end of the world. Mixing @flack's, @makomk's and your own suggestion:

The generated address begins with bc1 and lowers your fees when you spend it (BIP173). These addresses are not accepted everywhere yet. If the sender says your address is invalid, turn off this option to generate a address beginning with 1 or 3.

Alternatively "beginning with a digit" or make the "1" and "3" a variable in the string that you can switch during runtime.

bcash's thing is not bech32, it's gratuitously incompatible. I would prefer to call these "bc1 addresses" because that's how they're recognize able to users. Something like "Use bc1-style addresses. These addresses use segwit natively which reduces your transaction fees later on and offers better protection against typos, but old wallets don't support them. When unchecked, an address compatible with older wallets will be created instead."

[Edit] The text above "begins with Bc1 ... " sounds quite good to me. Esp the instructions telling you what to do if it fails! The "when you spend it" could be changed to "later when you spend the received funds".

No reason to block off Bech32 access with legacy address default.

Yes there is, the reason for having legacy in the first place is backwards compatibility. That reason is blown up the first time the user selects anything but legacy. Also, more choices aren't without a cost.

Along those lines, I don't see the usecase for #11937 but will comment there.

I think it's more clear to hide the checkbox when the user switches to legacy,

An alternative to hiding it completely would be when legacy is set it could grey out the BC1 address option (and perhaps add a note 'legacy mode enabled'). ... this would reduce confusion for someone that managed to follow some instruction to set legacy and then are later confused when they can't find the combobox.

+1 for "bc1 address"

I agree the bcash thing is weird, but assuming wallets hide** the bitcoincash: part*, users will assume it's the same kind of thing because it looks visually similar, it just doesn't start with bc1. Which is another argument in favor of "bc1 address".

* = the prefix is implied by the URI, whereas in bitcoin:bc1... the prefix is redundant. But bech32 doesn't require the use of URI's so again, weird...
** = except in places where you need to copy-paste it. Also note that double clicking on the right side of a bitcoin cash address will only select the bits after the colon, which should confuse their users and is probably the reason for using 1 as a separator in the standard. However, the checksum will still prevent accidents.

"The separator is 1 because using a non-alphanumeric character would complicate copy-pasting of addresses (with no double-click selection in several applications)" -- BIP173

There were many design considerations in BECH32 which we didn't explain in the spec but that wasn't one of them.

One of them was the potential for using an invisible magic value instead of or in addition to the HRP for distinguishing uses. Instead of has the problem of having no useful error reporting, in addition to had the problem that cross application usage would be more likely to be falsely accepted.

However, the checksum will still prevent accidents.

Almost all of the time: but not all the time-- the HRP they use is so long that any replacement one is going to exceede the guaranteed detection difference and possibly accept a swapped address however this would be very rare. Though preventing an erroneous send won't stop the user from being confused and doing something to fix it that makes things worse since UI's can't give feedback. I'd take a bet that someone will create a spinoff that doesn't change the effective HRP for the checksum, since it's not operably part of the address.

I don't think they're all that visually similar compared to any other string of encoded data, but the big difference is the bc1 prefix--- talking about that more will make people pay attention to it.

utACK 5f5fe406d6e9b5b64c13a76c2d74b0dc7f27c01a

Maybe I'm alone here, but from previous discussions the goal is to push native segwit addresses forward.

IMO the UI should not give the impression it is optional to not generate native segwit, instead, it should give the option to generate non-native segwit address.

When g_address_type == OUTPUT_TYPE_BECH32:

• Use address compatible with old wallets
  If checked, use OUTPUT_TYPE_P2SH_SEGWIT, otherwise use OUTPUT_TYPE_BECH32.

When g_address_type != OUTPUT_TYPE_BECH32:

• Use native segwit address
  If checked, use OUTPUT_TYPE_BECH32, otherwise use g_address_type.

I'm not fond of "changing" the texts of the UI, but with this approach, the checkbox text will reflect when the -addresstype default value is changed, which IMO is a win.

Please correct me if my reasoning is wrong in any way.

goal is to push native segwit addresses forward

Having this checkbox already goes a long way in encouraging adoption. Firstly it lets normal (non-RPC) users actually use it. Secondly it raises the bar for other wallets / services and gives them some confidence they're not wasting engineering time. See e.g. this tweet from Kraken.

Like RBF, I think this needs to happen in two phases: first we clearly offer it to the user and then - assuming no unexpected problems arise and the rest of the industry actually adopts it - we make it the default.

Making it the default now would lead to confusion, especially from users who don't even notice the checkbox, suddenly see a different address format and think something is wrong with their wallet. I forgot the word for "UX should not change as fast as technology allows, but should respect human ability to adapt to these changes", but it's similar to how Apple used Skeuomorphism on their early iPhones but switched to more abstract representations (and relied more on gestures) once people became familiar with smart phones in general.

Making it the default now would lead to confusion

I'm not suggesting that.

FWIW, my view on deployment is that even having the checkbox is rushing things... but not unacceptably. I think initially software should be made able to send to these addresses, then later made able to receive them. Having the checkbox allows faster usage, but at a cost of creating a small amount of confusion due to having a somewhat complicated option that often (esp initially) won't work. I think it's a good trade-off, and I'm already using BC1 addresses (as I assume many other advanced users will)-- but it's not a free decision either.

Making it the default now would lead to confusion

I'm not suggesting that.

I was confused by what you meant with:

IMO the UI should not give the impression it is optional to not generate native segwit, instead, it should give the option to generate non-native segwit address.

I don't think it's worth changing the text for when a user launches with -addresstype=bech32 as they probably know what they're doing. It does make sense to change the text to what you suggest once we change the default in some future version.

I don't think it's worth changing the text for when a user launches with -addresstype=bech32

It does make sense to change the text to what you suggest once we change the default in some future version

Those users would get the "future" UI. They won't see a difference when the default is changed.

Is this for 0.16?

Concept ACK, i think the new text is fine. It's always going to be a bit fuzzy to explain the way in which a new address format influences fees later, but the current text is non-actionable anyway (users don't generally control the coin selection, so the link between transactions and fees is vague at best).

Needs rebase

Rebased. I wouldn't mind "bc1", but the existing terminology seems well-established, and listing all 3 seems like a bit much.

+1 for "bc1 addresses."
While introducing a new synonymous term is rarely preferable, because of the confusion it creates, "bc1 address" doesn't have the usual cons. Advanced users may cringe the first time seeing this dumbed down version, but they will grasp the concept right away. While, for less advanced users, it is orders of magnitude more descriptive, than "bech32", "native segwit" or "P2WPKH".

Is this for 0.16?

Echoing @MarcoFalke.

How about "bravo charlie one" ?
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015477.html

IMO "aka X" is standard English these days...?

@luke-jr You make a fair point, especially since English has been changing due to acronyms being used in texting on cellular phones (e.g., "afaik" is obviously easier to type than "a.f.a.i.k."), and so I don't think that you're wrong. My thinking was that in many circles "aka," (without the periods) is still regarded as slang, leaving "a.k.a.," (with the periods) as being the more traditional usage, but of course English is evolving (as it always has).

Also, for people who are not fluent in English, "aka" has the potential to be confusing because it looks like a word, whereas "a.k.a." will be much more easily understood as an acronym.

My personal preference is to favour the English style that lends itself more to academia and English writing tradition because from my perspective it gives the Bitcoin software, as a whole, a more professionally-polished appearance, which I think is ultimately beneficial to this project overall. But this is also peer-review, and what I think isn't necessarily correct either.

Needs rebase.

Rebased

utACK

Needs rebase again (seems merge ready).

Needs simple rebase, utACK thereafter.

I've rebased this in #13251.