GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default

luke-jr commented at 7:25 am on January 17, 2018: member

“Bech32” isn’t very user-friendly; used “native segwit” as in #11937.
You don’t spend from addresses.
No reason to block off Bech32 access with legacy address default.

in src/qt/forms/receivecoinsdialog.ui:212 in 72a574a727 outdated

205@@ -206,10 +206,10 @@
206              <enum>Qt::StrongFocus</enum>
207             </property>
208             <property name="toolTip">
209-             <string>Bech32 addresses (BIP-173) are cheaper to spend from and offer better protection against typos. When unchecked a P2SH wrapped SegWit address will be created, compatible with older wallets.</string>
210+             <string>Native segwit addresses (aka Bech32 or BIP-173) reduce your transaction fees later on and offer better protection against typos, but old wallets don't support them. When unchecked, an address compatible with older wallets will be created instead.</string>
211             </property>
212             <property name="text">
213-             <string>Generate Bech32 address</string>
214+             <string>Generate native segwit address</string>

jonasschnelli commented at 7:29 am on January 17, 2018:

I think adding (bech32) here would be preferable since it seems to be used by the industry (Electrum, etc.).

luke-jr commented at 7:32 am on January 17, 2018:

k

jonasschnelli commented at 7:55 am on January 17, 2018: contributor

utACK 4959aa9a62ded74fcd343d6e402c79e3ebcba241 Needs squash.

luke-jr force-pushed on Jan 17, 2018

jonasschnelli added the label GUI on Jan 17, 2018

flack commented at 9:21 am on January 17, 2018: contributor

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

Sjors commented at 9:49 am on January 17, 2018: member

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.

gmaxwell commented at 11:16 am on January 17, 2018: contributor

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.

Sjors commented at 11:30 am on January 17, 2018: member

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

gmaxwell commented at 3:53 pm on January 17, 2018: contributor

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

achow101 commented at 5:31 pm on January 17, 2018: member

utACK 5f5fe406d6e9b5b64c13a76c2d74b0dc7f27c01a

promag commented at 0:41 am on January 18, 2018: member

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.

Sjors commented at 9:01 am on January 18, 2018: member

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.

promag commented at 2:17 pm on January 18, 2018: member

Making it the default now would lead to confusion

I’m not suggesting that.

gmaxwell commented at 2:21 pm on January 18, 2018: contributor

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.

Sjors commented at 2:33 pm on January 18, 2018: member

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.

promag commented at 4:00 pm on January 18, 2018: member

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.

MarcoFalke commented at 7:41 pm on January 18, 2018: member

Is this for 0.16?

sipa commented at 11:03 pm on January 18, 2018: member

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

MarcoFalke commented at 0:44 am on January 19, 2018: member

Needs rebase

luke-jr force-pushed on Jan 23, 2018

luke-jr commented at 8:53 am on January 23, 2018: member

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

nopara73 commented at 10:03 pm on January 25, 2018: none

+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”.

promag commented at 3:47 pm on January 27, 2018: member

Is this for 0.16?

Echoing @MarcoFalke.

supersonic71 commented at 6:35 pm on January 27, 2018: none

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

randolf changes_requested

randolf commented at 7:05 pm on February 14, 2018: contributor

In line 209 of src/qt/forms/receivecoinsdialog.ui, please change “(aka Bech32 or BIP-173)” to: (a.k.a., Bech32 or BIP-173)

(This is only a minor correction to punctuation.)

luke-jr commented at 7:18 pm on February 14, 2018: member

IMO “aka X” is standard English these days…?

randolf commented at 1:27 am on February 15, 2018: contributor

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

laanwj added this to the milestone 0.16.1 on Feb 15, 2018

laanwj added the label Needs backport on Feb 16, 2018

in src/qt/receivecoinsdialog.cpp:150 in 0cdd445a29 outdated

148+    if (ui->useBech32->isChecked()) {
149+        address_type = OUTPUT_TYPE_BECH32;
150+    } else {
151+        address_type = model->getDefaultAddressType();
152+        if (address_type == OUTPUT_TYPE_BECH32) {
153+            address_type = OUTPUT_TYPE_P2SH_SEGWIT;

laanwj commented at 4:59 pm on February 16, 2018:

I don’t understand the logic here: if default address type is BECH32 set it to P2SH_SEGWIT

flack commented at 5:08 pm on February 16, 2018:

because ui->useBech32->isChecked() is false in line 145, no?

luke-jr commented at 5:21 pm on February 16, 2018:

Indeed. The logic is that if useBech32 is unchecked, we don’t want to use Bech32 even if that’s the user’s default. In that case, we use P2SH_SEGWIT instead. But if the default is P2SH_SEGWIT or LEGACY, then we leave it alone.

Addresstype default	Checkbox	Result
legacy	on	Bech32
p2sh-segwit	on	Bech32
bech32	on	Bech32
legacy	off	Legacy
p2sh-segwit	off	P2SH-Segwit
bech32	off	P2SH-Segwit

Sjors commented at 5:32 pm on February 16, 2018:

That makes sense.

Sjors commented at 5:48 pm on February 16, 2018: member

Tested ACK 0cdd445a, though I have a light preference for dropping that commit and sticking to 39206331 (just the text change).

When launched with -addresstype=legacy the phrase “an address compatible with older wallets will be created instead” is ambiguous. It might be better to drop the last sentence in legacy mode.

It’s weird that the user can’t create a P2SH_SEGWITaddress, but it’s strictly an increase in functionality over the current situation.

laanwj commented at 9:06 pm on March 29, 2018: member

Needs rebase.

GUI: Rephrase Bech32 checkbox text/tooltip

- "Bech32" isn't very user-friendly
- You don't spend from addresses

717e6538db

GUI: Allow generating Bech32 addresses with a legacy-address default c21f42a503

luke-jr force-pushed on Mar 31, 2018

luke-jr commented at 4:53 pm on March 31, 2018: member

Rebased

sipa commented at 5:02 pm on March 31, 2018: member

utACK

jonasschnelli commented at 6:34 pm on April 10, 2018: contributor

Needs rebase again (seems merge ready).

TheBlueMatt commented at 1:55 pm on May 7, 2018: member

Needs simple rebase, utACK thereafter.

fanquake commented at 2:03 am on May 17, 2018: member

I’ve rebased this in #13251.

fanquake closed this on May 17, 2018

fanquake removed the label Needs backport on May 17, 2018

MarcoFalke referenced this in commit ef0e5cd517 on May 17, 2018

TheArbitrator referenced this in commit 47013b051d on Jun 21, 2021

DrahtBot locked this on Sep 8, 2021

GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default #12208