ts [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-08-16 to 2021-09-03
💬 Posted a total of 8 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 22:58:11

- reply

📅 Original date posted:2021-08-30
📝 Original message: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 at 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

2023-06-07 22:58:10

- reply

📅 Original date posted:2021-08-30
📝 Original message: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 at 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

2023-06-07 22:58:10

- reply

📅 Original date posted:2021-08-28
📝 Original message: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

2023-06-07 22:58:09

- reply

📅 Original date posted:2021-08-21
📝 Original message: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.

2023-06-07 22:58:08

- reply

📅 Original date posted:2021-08-21
📝 Original message: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
>
>

2023-06-07 22:58:07

- reply

📅 Original date posted:2021-08-19
📝 Original message: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
>

2023-06-07 22:58:06

- reply

📅 Original date posted:2021-08-16
📝 Original message: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