[bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

Entering a BTC address for a transaction can pose a risk of error (human or technical). While 
there is a checksum integrated in BTC addresses already, this is used only at a technical 
level and does not avoid entering a valid but otherwise wrong address. Moreover, it does not 
improve the overall user experience.

In case this hasn't been discussed before, I propose to implement a 3 or 4 digit code (lets 
call it 4DC for this text), generated as checksum from the address. This 4DC should be shown 
in all wallets next to the receiving address. When entering a new address to send BTC, the 
sending wallet should also show the 4DC next to the entered address. This way, the sending 
person can easily verify that the resulting 4DC matches the one from the receiving address.

This would mean that a receiver would not only send his public address to the sender, but also 
the 4DC. A minor disadvantage since a) it is not mandatory and b) it is very easy to do. 
However, it would greatly reduce the probability of performing transactions to a wrong address.

Technically, this is very easy to implement. The only effort needed is agreeing on a checksum 
standard to generate the code. Once the standard is established, all wallet and exchange 
developers can start implementing this.

Agreeing on a good name for this code would be helpful for a fast adoption (human readable 
checksum, verification code or 4DC are just examples).

Obviously, this solution could be used for all other coins/networks. But ideally, each of them 
should have its own checksum algorithm, in order to further avoid sending funds to the wrong 
network. Especially when the address standard is the same like it is the case with BTC and BCH.

Hopefully, Bitcoin can implement this first and serve as example-to-follow to other 
coins/networks.

Cheers,
TS

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ZmnSCPxj]

Good morning TS,

> Entering a BTC address for a transaction can pose a risk of error (human or technical). While
> there is a checksum integrated in BTC addresses already, this is used only at a technical
> level and does not avoid entering a valid but otherwise wrong address. Moreover, it does not
> improve the overall user experience.
>
> In case this hasn't been discussed before, I propose to implement a 3 or 4 digit code (lets
> call it 4DC for this text), generated as checksum from the address. This 4DC should be shown
> in all wallets next to the receiving address. When entering a new address to send BTC, the
> sending wallet should also show the 4DC next to the entered address. This way, the sending
> person can easily verify that the resulting 4DC matches the one from the receiving address.
>
> This would mean that a receiver would not only send his public address to the sender, but also
> the 4DC. A minor disadvantage since a) it is not mandatory and b) it is very easy to do.
> However, it would greatly reduce the probability of performing transactions to a wrong address.
>
> Technically, this is very easy to implement. The only effort needed is agreeing on a checksum
> standard to generate the code. Once the standard is established, all wallet and exchange
> developers can start implementing this.

I think the "only" effort here is going to be the main bulk of the effort, and it will still take years of agreement (or sipa doing it, because every review is "either sipa made it, or we have to check *everything* in detail for several months to make sure it is correct").

In any case --- the last 5 characters of a bech32 string are already a human-readable 5-digit code, with fairly good properties, why is it not usable for this case?

On the other side of the coin, if you say "the existing bech32 checksum is automatically checked by the software", why is forcing something to be manually checked by a human better than leaving the checking to software?


Regards,
ZmnSCPxj

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

Hello ZmnSCPxj,

ZmnSCPxj wrote on 8/16/21 5:34 AM:
> Good morning TS,
> 
>> Entering a BTC address for a transaction can pose a risk of error (human or technical). While
>> there is a checksum integrated in BTC addresses already, this is used only at a technical
>> level and does not avoid entering a valid but otherwise wrong address. Moreover, it does not
>> improve the overall user experience.
>>
>> In case this hasn't been discussed before, I propose to implement a 3 or 4 digit code (lets
>> call it 4DC for this text), generated as checksum from the address. This 4DC should be shown
>> in all wallets next to the receiving address. When entering a new address to send BTC, the
>> sending wallet should also show the 4DC next to the entered address. This way, the sending
>> person can easily verify that the resulting 4DC matches the one from the receiving address.
>>
>> This would mean that a receiver would not only send his public address to the sender, but also
>> the 4DC. A minor disadvantage since a) it is not mandatory and b) it is very easy to do.
>> However, it would greatly reduce the probability of performing transactions to a wrong address.
>>
>> Technically, this is very easy to implement. The only effort needed is agreeing on a checksum
>> standard to generate the code. Once the standard is established, all wallet and exchange
>> developers can start implementing this.
> 


Thanks for your comments.


> I think the "only" effort here is going to be the main bulk of the effort, and it will still take years of agreement (or sipa doing it, because every review is "either sipa made it, or we have to check *everything* in detail for several months to make sure it is correct").

I understand. If sipa could do it that would greatly simplify the process. Once an algorithm 
for the generation of the code exists, it just needs to be communicated to wallet developers 
and let it grow organically. No need of extensive testing, since it is only a very simple 
function.


> In any case --- the last 5 characters of a bech32 string are already a human-readable 5-digit code, with fairly good properties, why is it not usable for this case?

Well, because
a) most people don't know that
b) it is specific to bech32
c) it is not easily readable being the last digits of a long address (although this could be 
fixed by the wallet by showing those digits bigger or separately)
d) and most importantly: as mentioned in above my proposal, it only proves that an address is 
valid, but not necessarily the correct one (perhaps the user copied the wrong address, there 
was an old address in the clipboard, etc.)


> On the other side of the coin, if you say "the existing bech32 checksum is automatically checked by the software", why is forcing something to be manually checked by a human better than leaving the checking to software?

Not better, it should be on top. And not forced, but just as an optional check for the user. 
The SW can (and should) only check that the address is valid (the SW doesn't know the user's 
intent). Only the human can "double-check" an easy-to-read-code to quickly know that he is 
doing the right thing. (Entering a valid but wrong address is even worse than entering an 
invalid one, since the latter will be stopped by the wallet. But the former most likely 
results in loosing the funds.)

Note: The code should never be entered manually or even copied together with the address in 
one string. From the SW point of view, the code is an output only, never an input. It is 
merely a visual verification for the user.

Example of use: person A calls via phone person B and says: "Send me 0.1 BTC to my address I 
just sent you via whatsapp. When entering the address, make sure that you get the verification 
code 4385."

Regards,
TS


> 
> 
> Regards,
> ZmnSCPxj
> 

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

As an alternative, you might want to consider LifeHash, which includes a
visual indicator as well as a readable fingerprint value.

LifeHash is an open source visual hashing algorithm that we use for all our
projects. Lifehash has a number of desirable qualities, including high
complexity, good aesthetics, a printer-friendly (CMYK) color gamut and
robustness when transformed to grayscale.

* [LifeHask Overview and links to reference code](
https://github.com/BlockchainCommons/lifehash)

* [LifeHash Explainer on YouTube](
https://www.youtube.com/watch?v=cu0K__KLxKo)

* [Our LifeHash UX best practices - The Object Identity Block](
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2021-002-digest.md#object-identity-block
)

-- Christopher Allen
   Principal Architect, Blockchain Commons

[-- Attachment #2: Type: text/html, Size: 1244 bytes --]

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

Good day Christopher,

Thanks for your comment! LifeHash looks indeed quite interesting. I can imagine some examples 
where it would be very useful, and I guess it could be used as a visual verification for the 
address in a wallet as well.

However, for my proposal (Human readable checksum (verification code) to avoid errors) it 
could have the following disadvantages:

1. It would be only one standard instead of one standard per crypto network (it should be 
different on each of them as described in the proposal). This could be solved with the 
inclusion of a network identifier somehow, but would increase the complexity of the 
implementation.

2. For this special use case, a simple 3 to 4 digit code is easier to implement than a 
graphic, and easier to include in an existing app, with minimal layout changes. The simpler it 
is, the more likely it will be for developers to actually implement it.

3. A graphic cannot be communicated by voice (in some situations this could be an easier way 
to communicate the verification code)

Greetings,
TS



Christopher Allen wrote on 8/19/21 12:37 PM:
> As an alternative, you might want to consider LifeHash, which includes a visual indicator as 
> well as a readable fingerprint value.
> 
> LifeHash is an open source visual hashing algorithm that we use for all our projects. Lifehash 
> has a number of desirable qualities, including high complexity, good aesthetics, a 
> printer-friendly (CMYK) color gamut and robustness when transformed to grayscale.
> 
> * [LifeHask Overview and links to reference 
> code](https://github.com/BlockchainCommons/lifehash 
> <https://github.com/BlockchainCommons/lifehash>)
> 
> * [LifeHash Explainer on YouTube](https://www.youtube.com/watch?v=cu0K__KLxKo 
> <https://www.youtube.com/watch?v=cu0K__KLxKo>)
> 
> * [Our LifeHash UX best practices - The Object Identity 
> Block](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2021-002-digest.md#object-identity-block 
> <https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2021-002-digest.md#object-identity-block>)
> 
> -- Christopher Allen
>     Principal Architect, Blockchain Commons
> 
> 

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Karl]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Something that could work really well here could be having a norm of using
the checksum for bright colors, weights, sizes, capitalizations, and/or
spacing of the characters of the address, making different addresses more
clearly visually distinct.

Ethereum uses mixed case to do this a little bit:
https://eips.ethereum.org/EIPS/eip-55#implementation

It seems to me the checksum at the end of the address is sufficient for
differentiating error, but making a checksum more visually distinctive is
indeed an opportunity to add another digest, reducing collisions and such.

[-- Attachment #2: Type: text/html, Size: 768 bytes --]

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

Hello Karl,

Yes, I agree in general. But while the visual checksum could be sometimes more interesting and 
even useful, I guess that the technically simpler solution might be more likely to be adopted. 
And also less prone to error. Just a thought.

Cheers,
TS


Karl wrote on 8/19/21 4:05 PM:
> Something that could work really well here could be having a norm of using the checksum for 
> bright colors, weights, sizes, capitalizations, and/or spacing of the characters of the 
> address, making different addresses more clearly visually distinct.
> 
> Ethereum uses mixed case to do this a little bit: 
> https://eips.ethereum.org/EIPS/eip-55#implementation 
> <https://eips.ethereum.org/EIPS/eip-55#implementation>
> 
> It seems to me the checksum at the end of the address is sufficient for differentiating error, 
> but making a checksum more visually distinctive is indeed an opportunity to add another 
> digest, reducing collisions and such.

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Pieter Wuille]

On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> > In any case --- the last 5 characters of a bech32 string are already a human-readable 5-digit code, with fairly good properties, why is it not usable for this case?

Side note: it's actually the last six characters.

>
> Well, because
>
> a) most people don't know that
>
> b) it is specific to bech32
>
> c) it is not easily readable being the last digits of a long address (although this could be

I think this is a misconception. For the purpose of verifying that you have the *right* address (rather than just a valid one), the checksum, or even the knowledge that a checksum is present, is completely irrelevant.

In honestly-generated addresses, every character except the prefix (the ~2 first characters for P2PKH and P2SH, and the ~4 first characters for BIP173/BIP350 native segwit addresses) has exactly the same amount of entropy. Instead of adding say a 4 character code, just tell people to compare any 4 characters of their choosing. Or more - I would hope people are already comparing (much) more than 4 characters already.

It doesn't matter if the characters being compared are checksum characters or data characters. In honestly-generated addresses, both are equally random.

Adding a special 4 character "external" checksum IMO would instead encourage people to perhaps just compare those 4 characters instead of the rest (or at least, focus mostly on those). That could easily worsen how well comparisons are done in practice...

Cheers,

--
Pieter

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

Pieter Wuille wrote on 8/29/21 9:42 AM:
> On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>>> In any case --- the last 5 characters of a bech32 string are already a human-readable 5-digit code, with fairly good properties, why is it not usable for this case?
> 
> Side note: it's actually the last six characters.
> 
>>
>> Well, because
>>
>> a) most people don't know that
>>
>> b) it is specific to bech32
>>
>> c) it is not easily readable being the last digits of a long address (although this could be
> 
> I think this is a misconception. For the purpose of verifying that you have the *right* address (rather than just a valid one), the checksum, or even the knowledge that a checksum is present, is completely irrelevant.

Exactly, it is irrelevant in that case. That's why I added d) "...it only proves that an 
address is valid, but not necessarily the correct one..."


> In honestly-generated addresses, every character except the prefix (the ~2 first characters for P2PKH and P2SH, and the ~4 first characters for BIP173/BIP350 native segwit addresses) has exactly the same amount of entropy. Instead of adding say a 4 character code, just tell people to compare any 4 characters of their choosing. Or more - I would hope people are already comparing (much) more than 4 characters already.
> 
> It doesn't matter if the characters being compared are checksum characters or data characters. In honestly-generated addresses, both are equally random.

Yes, I agree with this basically, the entropy would be the same. My proposal is all about 
improving the user experience.


> Adding a special 4 character "external" checksum IMO would instead encourage people to perhaps just compare those 4 characters instead of the rest (or at least, focus mostly on those). That could easily worsen how well comparisons are done in practice...

This is a good point. This feature should not encourage people to just compare the code on its 
own or to focus mostly on it. It should be understood as a verification ON TOP. But then 
again, is there a perfect solution? As it is now, most users focus on only a few characters, 
if any.

* New variant
This discussion is now leading me to a new thought. Since the entropy is the same with a given 
number of characters from the address as you say and the address has already an inbuilt 
checksum, an alternative way to do this would be to just take 4 or 5 characters (as you 
proposed above) from a fixed position and present them to the user separately. Say, characters 
from position 11th to 15th. Those 5 characters should be displayed by the wallet next or 
bellow to the address in a clear box and big font. It could be called "Quick Verification Box" 
or some other catchy name.

Of course, the user could do this by looking at the address on his own. But this way he is 
encouraged to look at a given number of characters. Plus, a the bigger font makes it easier to 
see.

Example (characters 11th-15th):
1KM7GsxUvQiYC8eohKA2QHr9fCjkJXDFvg  [YC8eo] <- in a bigger font
            ^^^^^

Or alternatively, the first 2 characters, chars. at position 11 and 12, and the last 2 characters:
1KM7GsxUvQiYC8eohKA2QHr9fCjkJXDFvg  [1K-YC-vg] <- in a bigger font
^^         ^^                   ^^

Or characters at pos. 11-13 and 18-20:
1KM7GsxUvQiYC8eohKA2QHr9fCjkJXDFvg  [YC8-A2Q] <- in a bigger font
            ^^^    ^^^

Whatever combination is used, the important thing is that it becomes a standard and all 
wallets use the same one.

The advantage of this solution is that it would be technically even easier to implement, and 
more transparent at the same time. It is again all about agreeing on which characters to pick.


* Avoiding the confusion among networks (or blockchains)
In my original proposal, I mentioned that each network should use its own code generation 
algorithm. This way, for networks sharing the same address format, like BTC and BCH, the user 
would have this extra level of verification (in case he intends to send coins from BCH network 
to BTC or viceversa).
For the new variant above, this is easy to achieve too - each network should agree on a 
different subset of characters,

I hope I could explain this clearly enough, and that someone can see a value in this.

Cheers,
TS

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

Following up on my original proposal, I would like to get some more feedback of the community 
to see if this could be realized at some point. Also, any recommendations as to who to contact 
to get things rolling?

Thanks,
TS



ts wrote on 8/15/21 11:23 PM:
> Entering a BTC address for a transaction can pose a risk of error (human or technical). While 
> there is a checksum integrated in BTC addresses already, this is used only at a technical 
> level and does not avoid entering a valid but otherwise wrong address. Moreover, it does not 
> improve the overall user experience.
> 
> In case this hasn't been discussed before, I propose to implement a 3 or 4 digit code (lets 
> call it 4DC for this text), generated as checksum from the address. This 4DC should be shown 
> in all wallets next to the receiving address. When entering a new address to send BTC, the 
> sending wallet should also show the 4DC next to the entered address. This way, the sending 
> person can easily verify that the resulting 4DC matches the one from the receiving address.
> 
> This would mean that a receiver would not only send his public address to the sender, but also 
> the 4DC (or communicate it via a different channel). A minor disadvantage since a) it is not  > mandatory and b) it is very easy to do.
> However, it would greatly reduce the probability of performing transactions to a wrong address.
> 
> Technically, this is very easy to implement. The only effort needed is agreeing on a checksum 
> standard to generate the code. Once the standard is established, all wallet and exchange 
> developers can start implementing this.
> 
> Agreeing on a good name for this code would be helpful for a fast adoption (human readable 
> checksum, verification code or 4DC are just examples).
> 
> Obviously, this solution could be used for all other coins/networks. But ideally, each of them 
> should have its own checksum algorithm, in order to further avoid sending funds to the wrong 
> network. Especially when the address standard is the same like it is the case with BTC and BCH.
> 
> Hopefully, Bitcoin can implement this first and serve as example-to-follow to other 
> coins/networks.
> 
> Cheers,
> TS

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Pieter Wuille]

On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Following up on my original proposal, I would like to get some more feedback of the community
>
> to see if this could be realized at some point. Also, any recommendations as to who to contact
>
> to get things rolling?

I honestly don't understand the point of what you're suggesting.

* If you're concerned about random typos, this is something already automatically protected against through the checksum (both base58check or bech32/bech32m).

* If you're concerned about accidentally entering the wrong - but honestly created - address, comparing any few characters of the address is just as good as any other. It doesn't even require the presence of a checksum. Looking at the last N characters, or the middle N, or anything except the first few, will do, and is just as good as an "external" checksum added at the end. For randomly-generated addresses (as honest ones are), each of those has exactly as much entropy.

* If you're concerned about maliciously constructed addresses, which are designed to look similar in specific places, an attacker can just as easily make the external checksum collide (and having one might even worsen this, as now the attacker can focus on exactly that, rather than needing to focus on every other character).

Things would be different if you'd suggest a checksum in another medium than text (e.g. a visual/drawing/colorcoding one). But I don't see any added value for an additional text-based checksum when addresses are already text themselves. This is even disregarding the difficulty of getting the ecosystem to adopt such changes.

Cheers,

--
Pieter

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

Pieter, thanks for your comments. Here my thoughts:

Pieter Wuille wrote on 8/29/21 9:24 AM:
> On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> Following up on my original proposal, I would like to get some more feedback of the community
>>
>> to see if this could be realized at some point. Also, any recommendations as to who to contact
>>
>> to get things rolling?
> 
> I honestly don't understand the point of what you're suggesting.

It is about creating a simple technical assistance that makes it more user friendly and less 
error prone to verify the entered address. For all types of users, including those who are 
less tech savvy.


> * If you're concerned about random typos, this is something already automatically protected against through the checksum (both base58check or bech32/bech32m).

I agree, but as mentioned in the original proposal, it is not about random typos (although 
this would help for other coins without integrated checksum of course), but rather about 
copy&paste errors (both technical or user caused).


> * If you're concerned about accidentally entering the wrong - but honestly created - address, comparing any few characters of the address is just as good as any other. It doesn't even require the presence of a checksum. Looking at the last N characters, or the middle N, or anything except the first few, will do, and is just as good as an "external" checksum added at the end. For randomly-generated addresses (as honest ones are), each of those has exactly as much entropy.

Correct. However, I believe that ADDITIONALLY to looking at N characters, a quick check of a 3 
or 4 digit code in bigger font next to the address would make for a better user experience. 
This gives the user the reassurance that there is definitely no error. I agree that most users 
with technical background including most of us here will routinely check the first/last N 
characters. I usually check the first 3 + last 3 characters. But I don't think this is very 
user friendly. More importantly, I once had the case that two addresses were very similar at 
precisely those 6 characters, and only a more close and concentrated look made me see the 
difference. Moreover, some inexperienced users that are not aware of the consequences of 
entering a wrong address (much worse than entering the wrong bank account in an online bank 
transfer) might forget to look at the characters altogether.


> * If you're concerned about maliciously constructed addresses, which are designed to look similar in specific places, an attacker can just as easily make the external checksum collide (and having one might even worsen this, as now the attacker can focus on exactly that, rather than needing to focus on every other character).

Not so concerned about this case, since this is a very special case that can only occur under 
certain circumstances. But taking this case also into consideration, this is why the user 
should use the verification code ADDITIONALLY to the normal way of verifying, not instead. If 
the attacker only focuses on the verification code, he will only be successful with users that 
ONLY look at this code. But if the attacker intends to be more successful, he now needs to 
create a valid address that is both similar in specific places AND produces the same 
verification code, which is way more difficult to achieve.


> Things would be different if you'd suggest a checksum in another medium than text (e.g. a visual/drawing/colorcoding one). But I don't see any added value for an additional text-based checksum when addresses are already text themselves.

Yes, a visual checksum could also work. Christopher Allen proposed to use LifeHash as an 
alternative. It would be a matter of balancing the more complex implementation and need of 
space in the app's layout with the usability and advantages of use. One advantage of the digit 
verification code is that it can be spoken in a call or written in a message.

> This is even disregarding the difficulty of getting the ecosystem to adopt such changes.

No changes are needed, only an agreement or recommendation on which algorithm for the code 
generation should be used. Once this is done, it is up to the developers of wallets and 
exchanges to implement this feature as they see fit.

Greetings,
TS

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Marek Palatinus]

[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]

I fully agree with sipa and his reasoning that this proposal is not solving
any particular problem, but making it actually a bit worse.

Also, do you know what I hate more than copy&pasting bitcoin addresses?
Copy pasting zillion random fields for SEPA/wire transfers. And I believe
that a single copy pasta of a bitcoin address is a much better user
experience after all.

Best,
slush

On Tue, Aug 31, 2021 at 9:08 AM ts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Pieter, thanks for your comments. Here my thoughts:
>
> Pieter Wuille wrote on 8/29/21 9:24 AM:
> > On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> Following up on my original proposal, I would like to get some more
> feedback of the community
> >>
> >> to see if this could be realized at some point. Also, any
> recommendations as to who to contact
> >>
> >> to get things rolling?
> >
> > I honestly don't understand the point of what you're suggesting.
>
> It is about creating a simple technical assistance that makes it more user
> friendly and less
> error prone to verify the entered address. For all types of users,
> including those who are
> less tech savvy.
>
>
> > * If you're concerned about random typos, this is something already
> automatically protected against through the checksum (both base58check or
> bech32/bech32m).
>
> I agree, but as mentioned in the original proposal, it is not about random
> typos (although
> this would help for other coins without integrated checksum of course),
> but rather about
> copy&paste errors (both technical or user caused).
>
>
> > * If you're concerned about accidentally entering the wrong - but
> honestly created - address, comparing any few characters of the address is
> just as good as any other. It doesn't even require the presence of a
> checksum. Looking at the last N characters, or the middle N, or anything
> except the first few, will do, and is just as good as an "external"
> checksum added at the end. For randomly-generated addresses (as honest ones
> are), each of those has exactly as much entropy.
>
> Correct. However, I believe that ADDITIONALLY to looking at N characters,
> a quick check of a 3
> or 4 digit code in bigger font next to the address would make for a better
> user experience.
> This gives the user the reassurance that there is definitely no error. I
> agree that most users
> with technical background including most of us here will routinely check
> the first/last N
> characters. I usually check the first 3 + last 3 characters. But I don't
> think this is very
> user friendly. More importantly, I once had the case that two addresses
> were very similar at
> precisely those 6 characters, and only a more close and concentrated look
> made me see the
> difference. Moreover, some inexperienced users that are not aware of the
> consequences of
> entering a wrong address (much worse than entering the wrong bank account
> in an online bank
> transfer) might forget to look at the characters altogether.
>
>
> > * If you're concerned about maliciously constructed addresses, which are
> designed to look similar in specific places, an attacker can just as easily
> make the external checksum collide (and having one might even worsen this,
> as now the attacker can focus on exactly that, rather than needing to focus
> on every other character).
>
> Not so concerned about this case, since this is a very special case that
> can only occur under
> certain circumstances. But taking this case also into consideration, this
> is why the user
> should use the verification code ADDITIONALLY to the normal way of
> verifying, not instead. If
> the attacker only focuses on the verification code, he will only be
> successful with users that
> ONLY look at this code. But if the attacker intends to be more successful,
> he now needs to
> create a valid address that is both similar in specific places AND
> produces the same
> verification code, which is way more difficult to achieve.
>
>
> > Things would be different if you'd suggest a checksum in another medium
> than text (e.g. a visual/drawing/colorcoding one). But I don't see any
> added value for an additional text-based checksum when addresses are
> already text themselves.
>
> Yes, a visual checksum could also work. Christopher Allen proposed to use
> LifeHash as an
> alternative. It would be a matter of balancing the more complex
> implementation and need of
> space in the app's layout with the usability and advantages of use. One
> advantage of the digit
> verification code is that it can be spoken in a call or written in a
> message.
>
> > This is even disregarding the difficulty of getting the ecosystem to
> adopt such changes.
>
> No changes are needed, only an agreement or recommendation on which
> algorithm for the code
> generation should be used. Once this is done, it is up to the developers
> of wallets and
> exchanges to implement this feature as they see fit.
>
> Greetings,
> TS
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6130 bytes --]

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts]

[-- Attachment #1: Type: text/plain, Size: 6632 bytes --]

Hi Marek,

Marek Palatinus wrote on 8/31/21 3:47 AM:
> I fully agree with sipa and his reasoning that this proposal is not solving any particular 
> problem, but making it actually a bit worse.
Ok, I understand. I'm just trying to find ways to reduce the risk of sending to the wrong 
address and to make the transaction process a bit more user friendly, specially for 
inexperienced users. I am sure that it can be implemented in a way without making it "worse". 
For example, if there is the risk that the user looks ONLY at the code and not at the address, 
then the code should have enough entropy to account for it. If looking at 6 characters is 
considered to be enough, then the code should also be 6 characters long. As I mentioned in my 
following message, the code could be made from specific characters of the address instead of a 
checksum (e.g. first 4 and last 2 characters). By showing these characters to the user 
separately and in a bigger font, he will be encouraged to verify all of these characters.

> Also, do you know what I hate more than copy&pasting bitcoin addresses? Copy pasting zillion 
> random fields for SEPA/wire transfers. And I believe that a single copy pasta of a bitcoin 
> address is a much better user experience after all.

I totally agree with this :)

Cheers,
TS


> Best,
> slush
>
> On Tue, Aug 31, 2021 at 9:08 AM ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Pieter, thanks for your comments. Here my thoughts:
>
>     Pieter Wuille wrote on 8/29/21 9:24 AM:
>     > On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>>
>     wrote:
>     >
>     >> Following up on my original proposal, I would like to get some more feedback of the
>     community
>     >>
>     >> to see if this could be realized at some point. Also, any recommendations as to who
>     to contact
>     >>
>     >> to get things rolling?
>     >
>     > I honestly don't understand the point of what you're suggesting.
>
>     It is about creating a simple technical assistance that makes it more user friendly and
>     less
>     error prone to verify the entered address. For all types of users, including those who are
>     less tech savvy.
>
>
>     > * If you're concerned about random typos, this is something already automatically
>     protected against through the checksum (both base58check or bech32/bech32m).
>
>     I agree, but as mentioned in the original proposal, it is not about random typos (although
>     this would help for other coins without integrated checksum of course), but rather about
>     copy&paste errors (both technical or user caused).
>
>
>     > * If you're concerned about accidentally entering the wrong - but honestly created -
>     address, comparing any few characters of the address is just as good as any other. It
>     doesn't even require the presence of a checksum. Looking at the last N characters, or
>     the middle N, or anything except the first few, will do, and is just as good as an
>     "external" checksum added at the end. For randomly-generated addresses (as honest ones
>     are), each of those has exactly as much entropy.
>
>     Correct. However, I believe that ADDITIONALLY to looking at N characters, a quick check
>     of a 3
>     or 4 digit code in bigger font next to the address would make for a better user experience.
>     This gives the user the reassurance that there is definitely no error. I agree that most
>     users
>     with technical background including most of us here will routinely check the first/last N
>     characters. I usually check the first 3 + last 3 characters. But I don't think this is very
>     user friendly. More importantly, I once had the case that two addresses were very
>     similar at
>     precisely those 6 characters, and only a more close and concentrated look made me see the
>     difference. Moreover, some inexperienced users that are not aware of the consequences of
>     entering a wrong address (much worse than entering the wrong bank account in an online bank
>     transfer) might forget to look at the characters altogether.
>
>
>     > * If you're concerned about maliciously constructed addresses, which are designed to
>     look similar in specific places, an attacker can just as easily make the external
>     checksum collide (and having one might even worsen this, as now the attacker can focus
>     on exactly that, rather than needing to focus on every other character).
>
>     Not so concerned about this case, since this is a very special case that can only occur
>     under
>     certain circumstances. But taking this case also into consideration, this is why the user
>     should use the verification code ADDITIONALLY to the normal way of verifying, not
>     instead. If
>     the attacker only focuses on the verification code, he will only be successful with
>     users that
>     ONLY look at this code. But if the attacker intends to be more successful, he now needs to
>     create a valid address that is both similar in specific places AND produces the same
>     verification code, which is way more difficult to achieve.
>
>
>     > Things would be different if you'd suggest a checksum in another medium than text
>     (e.g. a visual/drawing/colorcoding one). But I don't see any added value for an
>     additional text-based checksum when addresses are already text themselves.
>
>     Yes, a visual checksum could also work. Christopher Allen proposed to use LifeHash as an
>     alternative. It would be a matter of balancing the more complex implementation and need of
>     space in the app's layout with the usability and advantages of use. One advantage of the
>     digit
>     verification code is that it can be spoken in a call or written in a message.
>
>     > This is even disregarding the difficulty of getting the ecosystem to adopt such changes.
>
>     No changes are needed, only an agreement or recommendation on which algorithm for the code
>     generation should be used. Once this is done, it is up to the developers of wallets and
>     exchanges to implement this feature as they see fit.
>
>     Greetings,
>     TS
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>

[-- Attachment #2: Type: text/html, Size: 9630 bytes --]