Why Nostr? What is Njump?
2023-06-07 22:58:11
in reply to

Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-29 📝 Original message:On Saturday, August 28th, ...

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

* 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
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r