public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
@ 2021-08-16  4:23 ts
  2021-08-16 10:34 ` ZmnSCPxj
  2021-08-28 21:17 ` ts
  0 siblings, 2 replies; 14+ messages in thread
From: ts @ 2021-08-16  4:23 UTC (permalink / raw)
  To: bitcoin-dev

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

• * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
    2021-08-16  4:23 [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses ts
  @ 2021-08-16 10:34 ` ZmnSCPxj
    2021-08-19 17:02   ` ts
    2021-08-28 21:17 ` ts
    1 sibling, 1 reply; 14+ messages in thread
  From: ZmnSCPxj @ 2021-08-16 10:34 UTC (permalink / raw)
    To: ts, Bitcoin Protocol Discussion
  
  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
  
  
  ^ permalink raw reply	[flat|nested] 14+ messages in thread

• • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
      2021-08-16 10:34 ` ZmnSCPxj
    @ 2021-08-19 17:02   ` ts
      2021-08-19 17:37     ` Christopher Allen
                           ` (2 more replies)
      0 siblings, 3 replies; 14+ messages in thread
    From: ts @ 2021-08-19 17:02 UTC (permalink / raw)
      To: bitcoin-dev
    
    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
    > 
    
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread

  • • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
        2021-08-19 17:02   ` ts
      @ 2021-08-19 17:37     ` Christopher Allen
        2021-08-21  4:52       ` ts
        2021-08-19 21:05     ` Karl
        2021-08-29 14:42     ` Pieter Wuille
        2 siblings, 1 reply; 14+ messages in thread
      From: Christopher Allen @ 2021-08-19 17:37 UTC (permalink / raw)
        To: ts, Bitcoin Protocol Discussion
      
      [-- 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 --]
      
      ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
          2021-08-19 17:37     ` Christopher Allen
        @ 2021-08-21  4:52       ` ts
          0 siblings, 0 replies; 14+ messages in thread
        From: ts @ 2021-08-21  4:52 UTC (permalink / raw)
          To: Christopher Allen, Bitcoin Protocol Discussion
        
        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
        > 
        > 
        
        
        ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
        2021-08-19 17:02   ` ts
        2021-08-19 17:37     ` Christopher Allen
      @ 2021-08-19 21:05     ` Karl
        2021-08-21  4:52       ` ts
        2021-08-29 14:42     ` Pieter Wuille
        2 siblings, 1 reply; 14+ messages in thread
      From: Karl @ 2021-08-19 21:05 UTC (permalink / raw)
        To: ts, Bitcoin Protocol Discussion
      
      [-- 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 --]
      
      ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
          2021-08-19 21:05     ` Karl
        @ 2021-08-21  4:52       ` ts
          0 siblings, 0 replies; 14+ messages in thread
        From: ts @ 2021-08-21  4:52 UTC (permalink / raw)
          To: Karl, Bitcoin Protocol Discussion
        
        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.
        
        
        ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
        2021-08-19 17:02   ` ts
        2021-08-19 17:37     ` Christopher Allen
        2021-08-19 21:05     ` Karl
      @ 2021-08-29 14:42     ` Pieter Wuille
        2021-08-31  2:17       ` ts
        2 siblings, 1 reply; 14+ messages in thread
      From: Pieter Wuille @ 2021-08-29 14:42 UTC (permalink / raw)
        To: ts, Bitcoin Protocol Discussion
      
      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
      
      
      
      ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
          2021-08-29 14:42     ` Pieter Wuille
        @ 2021-08-31  2:17       ` ts
          0 siblings, 0 replies; 14+ messages in thread
        From: ts @ 2021-08-31  2:17 UTC (permalink / raw)
          To: Pieter Wuille, Bitcoin Protocol Discussion
        
        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
        
        
        
        ^ permalink raw reply	[flat|nested] 14+ messages in thread

• * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
    2021-08-16  4:23 [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses ts
    2021-08-16 10:34 ` ZmnSCPxj
  @ 2021-08-28 21:17 ` ts
    2021-08-29 14:24   ` Pieter Wuille
    1 sibling, 1 reply; 14+ messages in thread
  From: ts @ 2021-08-28 21:17 UTC (permalink / raw)
    To: bitcoin-dev
  
  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
  
  
  ^ permalink raw reply	[flat|nested] 14+ messages in thread

• • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
      2021-08-28 21:17 ` ts
    @ 2021-08-29 14:24   ` Pieter Wuille
      2021-08-31  2:16     ` ts
      0 siblings, 1 reply; 14+ messages in thread
    From: Pieter Wuille @ 2021-08-29 14:24 UTC (permalink / raw)
      To: ts, Bitcoin Protocol Discussion
    
    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
    
    
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread

  • • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
        2021-08-29 14:24   ` Pieter Wuille
      @ 2021-08-31  2:16     ` ts
        2021-08-31  8:47       ` Marek Palatinus
        0 siblings, 1 reply; 14+ messages in thread
      From: ts @ 2021-08-31  2:16 UTC (permalink / raw)
        To: Pieter Wuille, Bitcoin Protocol Discussion
      
      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
      
      
      ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
          2021-08-31  2:16     ` ts
        @ 2021-08-31  8:47       ` Marek Palatinus
          2021-09-03  5:08         ` ts
          0 siblings, 1 reply; 14+ messages in thread
        From: Marek Palatinus @ 2021-08-31  8:47 UTC (permalink / raw)
          To: ts, Bitcoin Protocol Discussion
        
        [-- 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 --]
        
        ^ permalink raw reply	[flat|nested] 14+ messages in thread

      • • * Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
            2021-08-31  8:47       ` Marek Palatinus
          @ 2021-09-03  5:08         ` ts
            0 siblings, 0 replies; 14+ messages in thread
          From: ts @ 2021-09-03  5:08 UTC (permalink / raw)
            To: Marek Palatinus, Bitcoin Protocol Discussion
          
          [-- 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 --]
          
          ^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-09-03  5:08 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-16  4:23 [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses ts
2021-08-16 10:34 ` ZmnSCPxj
2021-08-19 17:02   ` ts
2021-08-19 17:37     ` Christopher Allen
2021-08-21  4:52       ` ts
2021-08-19 21:05     ` Karl
2021-08-21  4:52       ` ts
2021-08-29 14:42     ` Pieter Wuille
2021-08-31  2:17       ` ts
2021-08-28 21:17 ` ts
2021-08-29 14:24   ` Pieter Wuille
2021-08-31  2:16     ` ts
2021-08-31  8:47       ` Marek Palatinus
2021-09-03  5:08         ` ts

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox