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

2021-08-19 Thread ts via 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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2021-08-19 Thread Christopher Allen via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2021-08-19 Thread Karl via bitcoin-dev
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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-19 Thread Jeremy via bitcoin-dev
one interesting point that came up at the bitdevs in austin today that
favors remove that i believe is new to this discussion (it was new to me):

the argument can be reduced to:

- dust limit is a per-node relay policy.
- it is rational for miners to mine dust outputs given their cost of
maintenance (storing the output potentially forever) is lower than their
immediate reward in fees.
- if txn relaying nodes censor something that a miner would mine, users
will seek a private/direct relay to the miner and vice versa.
- if direct relay to miner becomes popular, it is both bad for privacy and
decentralization.
- therefore the dust limit, should there be demand to create dust at
prevailing mempool feerates, causes an incentive to increase network
centralization (immediately)

the tradeoff is if a short term immediate incentive to promote network
centralization is better or worse than a long term node operator overhead.


///

my take is that:

1) having a dust limit is worse since we'd rather not have an incentive to
produce or roll out centralizing software, whereas not having a dust limit
creates an mild incentive for node operators to improve utreexo
decentralizing software.
2) it's hard to quantify the magnitude of the incentives, which does matter.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev