Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
On Tue, Aug 31, 2021 at 12:18 PM Peter D. Gray wrote: > QR Codes do not use IANA mime-types. > > If anyone wanted to use UR encoding for PSBT data in a web context (http), > NFC, or email, it would probably be best to discourage them. > > While I can understand the need for UR encoding in animated QR > codes, I don't think any other use-case could justify introducing > a new word list (ByteWords), a unique checksum algo (Xoshiro256), > fountain codes (Luby Transform) and CBOR... just to wrap a few k > of binary. > > I do love CBOR though. It's the best. UR is more than just a QR, it is URL conformant text that is optimized for compression in QRs. In particular, take a look at the explanation of the UR format at the 20m0s mark in this video: https://youtu.be/RYgOFSdUqWY The rest of the video explains why we made the choices we did. We wanted to leverage existing standards, but there were too many compromises expecially give QR requirements. See the section on “Why Another Standard” in our overview at https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-1-overview.md#why-another-standard Note that the UR specification just is not just being adopted by wallet vendors, but also a number of online services / transaction coordinators that only have access watch-only keys. These services can then do a crypto-request for the airgapped wallet to sign the PSBT. — Christopher Allen > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
QR Codes do not use IANA mime-types. If anyone wanted to use UR encoding for PSBT data in a web context (http), NFC, or email, it would probably be best to discourage them. While I can understand the need for UR encoding in animated QR codes, I don't think any other use-case could justify introducing a new word list (ByteWords), a unique checksum algo (Xoshiro256), fountain codes (Luby Transform) and CBOR... just to wrap a few k of binary. I do love CBOR though. It's the best. --- @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 On Tue, Aug 31, 2021 at 12:01:23PM -0700, Christopher Allen wrote: > Note that a number of wallet companies are now supporting the UR encoded > version of PSBTs, allowing for better QR & Airgap solutions, and also > leverage CBOR which is an IETF standard. > > We have a community of Airgap wallet developers at > https://github.com/BlockchainCommons/Airgapped-Wallet-Community > > …and libraries at > https://github.com/BlockchainCommons/crypto-commons#urs > > We’d love for you to register UR as well, maybe as bitcoin/psbt+ur > > Can you bring this up in our community for further discussion? > https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions > > Thanks! > > — Christopher Allen [via iPhone] > > On Tue, Aug 31, 2021 at 11:41 AM Peter D. Gray via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Hi list! > > > > I am proposing to register the following MIME (RFC 2046) media types with > > the IANA: > > > > > > bitcoin/psbt > > > > - aka. a BIP-174 file, in binary > > - does not make any claims about signed/unsigned status; lets leave > > that to the file > > > > bitcoin/txn > > > > - aka. wire-ready fully-signed transaction in binary > > > > bitcoin/uri > > > > - aka [BIP-21]( > > https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) > > - could be just a bare bech32 or base58 payment address > > - but can also encode amount, comments in URL args > > - potentially interesting as a response to 402 - Payment required > > > > > > Other thoughts > > > > - some mime-types are proposed in BIP-71 but those are unrelated to above, > > and never > > seem to have been registered > > > > - for those who like to encode their binary as base64 or hex, that can be > > indicated > > as "encoding=hex" or "encoding=base64" in the optional parameters, just > > like > > "text/plain; encoding=utf-8" does. However, the default must be binary. > > > > - although the above are useful for web servers, they are also useful > > elsewhere and I > > intend to use them in NFC (NDEF records) where a shorter length is > > critical. > > > > - I have no idea how easily IANA will accept these proposals. > > > > - current approved mime types: > > https://www.iana.org/assignments/media-types/media-types.xhtml > > > > Thoughts? > > > > --- > > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Note that a number of wallet companies are now supporting the UR encoded version of PSBTs, allowing for better QR & Airgap solutions, and also leverage CBOR which is an IETF standard. We have a community of Airgap wallet developers at https://github.com/BlockchainCommons/Airgapped-Wallet-Community …and libraries at https://github.com/BlockchainCommons/crypto-commons#urs We’d love for you to register UR as well, maybe as bitcoin/psbt+ur Can you bring this up in our community for further discussion? https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions Thanks! — Christopher Allen [via iPhone] On Tue, Aug 31, 2021 at 11:41 AM Peter D. Gray via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi list! > > I am proposing to register the following MIME (RFC 2046) media types with > the IANA: > > > bitcoin/psbt > > - aka. a BIP-174 file, in binary > - does not make any claims about signed/unsigned status; lets leave > that to the file > > bitcoin/txn > > - aka. wire-ready fully-signed transaction in binary > > bitcoin/uri > > - aka [BIP-21]( > https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) > - could be just a bare bech32 or base58 payment address > - but can also encode amount, comments in URL args > - potentially interesting as a response to 402 - Payment required > > > Other thoughts > > - some mime-types are proposed in BIP-71 but those are unrelated to above, > and never > seem to have been registered > > - for those who like to encode their binary as base64 or hex, that can be > indicated > as "encoding=hex" or "encoding=base64" in the optional parameters, just > like > "text/plain; encoding=utf-8" does. However, the default must be binary. > > - although the above are useful for web servers, they are also useful > elsewhere and I > intend to use them in NFC (NDEF records) where a shorter length is > critical. > > - I have no idea how easily IANA will accept these proposals. > > - current approved mime types: > https://www.iana.org/assignments/media-types/media-types.xhtml > > Thoughts? > > --- > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Hi Peter, It would be nice to have mime types registered for Bitcoin things, but I'm not sure that it will be possible, at least not in the way that we would like. I tried doing this with "application/bitcoin-psbt" back in 2019 but it was not accepted. From that attempt, here is what I have learned: There are only a few accepted top level types, so we would not be able to use "bitcoin" as the top level (unless you want to submit an RFC to add a "bitcoin" top level). Of the available top level types, "application" is the most appropriate for Bitcoin. Next is the tree that the mime type should be in. The best would be the Standards tree, but it has some requirements that Bitcoin doesn't really meet. In order to be in the standards tree, the registration must be either associated with an IETF specification (so a RFC) or registered by a recognized standards related organization. Unfortunately the closest thing to a standards organization that Bitcoin has is the BIPs process, and that is not a really a standards organization nor is it recognized by IANA. So in order to register the mimetypes as Standards tree types, we would need to write an RFC, but this could be an independent submission (https://www.rfc-editor.org/about/independent/) rather than IETF-stream submission. I did not continue to pursue this because I didn't have the time. Another alternative would be to use the Vendor tree, but that would prefix the mimetype with "vnd." so it would end up being something like "application/vnd.bitcoin.psbt". I did not think this was an reasonable so I did not continue to pursue this avenue. Andrew Chow On 8/31/21 2:27 PM, Peter D. Gray via bitcoin-dev wrote: > Hi list! > > I am proposing to register the following MIME (RFC 2046) media types with the > IANA: > > > bitcoin/psbt > > - aka. a BIP-174 file, in binary > - does not make any claims about signed/unsigned status; lets leave that > to the file > > bitcoin/txn > > - aka. wire-ready fully-signed transaction in binary > > bitcoin/uri > > - aka > [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) > - could be just a bare bech32 or base58 payment address > - but can also encode amount, comments in URL args > - potentially interesting as a response to 402 - Payment required > > > Other thoughts > > - some mime-types are proposed in BIP-71 but those are unrelated to above, > and never >seem to have been registered > > - for those who like to encode their binary as base64 or hex, that can be > indicated >as "encoding=hex" or "encoding=base64" in the optional parameters, just > like >"text/plain; encoding=utf-8" does. However, the default must be binary. > > - although the above are useful for web servers, they are also useful > elsewhere and I >intend to use them in NFC (NDEF records) where a shorter length is > critical. > > - I have no idea how easily IANA will accept these proposals. > > - current approved mime types: > https://www.iana.org/assignments/media-types/media-types.xhtml > > Thoughts? > > --- > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Hi list! I am proposing to register the following MIME (RFC 2046) media types with the IANA: bitcoin/psbt - aka. a BIP-174 file, in binary - does not make any claims about signed/unsigned status; lets leave that to the file bitcoin/txn - aka. wire-ready fully-signed transaction in binary bitcoin/uri - aka [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) - could be just a bare bech32 or base58 payment address - but can also encode amount, comments in URL args - potentially interesting as a response to 402 - Payment required Other thoughts - some mime-types are proposed in BIP-71 but those are unrelated to above, and never seem to have been registered - for those who like to encode their binary as base64 or hex, that can be indicated as "encoding=hex" or "encoding=base64" in the optional parameters, just like "text/plain; encoding=utf-8" does. However, the default must be binary. - although the above are useful for web servers, they are also useful elsewhere and I intend to use them in NFC (NDEF records) where a shorter length is critical. - I have no idea how easily IANA will accept these proposals. - current approved mime types: https://www.iana.org/assignments/media-types/media-types.xhtml Thoughts? --- @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value
Good morning Zac, > Hi ZmnSCPxj, > > Thank you for your helpful response. We're on the same page concerning > privacy so I'll focus on that. I understand from your mail that privacy would > be reduced by this proposal because: > > * It requires the introduction of a new type of transaction that is different > from a "standard" transaction (would that be P2TR in the future?), reducing > the anonymity set for everyone; > * The payment and change output will be identifiable because the change > output must be marked encumbered on-chain; > * The specifics of how the output is encumbered must be visible on-chain as > well reducing privacy even further. > > I don't have the technical skills to judge whether these issues can somehow > be resolved. In functional terms, the output should be spendable in a way > that does not reveal that the output is encumbered, and produce a change > output that cannot be distinguished from a non-change output while still > being encumbered. Perhaps some clever MAST-fu could somehow help? I believe some of the covenant efforts may indeed have such clever MAST-fu integrated into them, which is why I pointed you to them --- the people developing these (aj I think? RubenSomsen?) might be able to accommodate this or some subset of the desired feature in a sufficiently clever covenant scheme. There are a number of such proposals, though, so I cannot really point you to one that seems likely to have a lot of traction. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value
Hi ZmnSCPxj, Thank you for your helpful response. We're on the same page concerning privacy so I'll focus on that. I understand from your mail that privacy would be reduced by this proposal because: * It requires the introduction of a new type of transaction that is different from a "standard" transaction (would that be P2TR in the future?), reducing the anonymity set for everyone; * The payment and change output will be identifiable because the change output must be marked encumbered on-chain; * The specifics of how the output is encumbered must be visible on-chain as well reducing privacy even further. I don't have the technical skills to judge whether these issues can somehow be resolved. In functional terms, the output should be spendable in a way that does not reveal that the output is encumbered, and produce a change output that cannot be distinguished from a non-change output while still being encumbered. Perhaps some clever MAST-fu could somehow help? I imagine that the offered functionality does not justify the above mentioned privacy reductions, so unless these can be addressed, without functional modification this proposal sadly seems dead in the water. Thanks again. Zac On Tue, Aug 31, 2021 at 11:00 AM ZmnSCPxj wrote: > Good morning Zac, > > > > Perhaps you could help me understand what would be required to implement > the *unmodified* proposal. That way, the community will be able to better > assess the cost (in terms of effort and risk) and weigh it against the > perceived benefits. Perhaps *then* we find that the cost could be > significantly reduced without any significant reduction of the benefits, > for instance by slightly compromising on the functionality such that no > changes to consensus would be required for its implementation. (I am > skeptical that this would be possible though). The cost reduction must be > carefully weighed against the functional gaps it creates. > > For one, such output need to be explicitly visible, to implement the > "change outputs must also be rate-limited". > A tx spending a rate-limited output has to know that one of the outputs is > also a rate-limited output. > > This flagging needs to be done by either allocating a new SegWit version > --- a resource that is not lightly allocated, there being only 30 versions > left if my understanding is correct --- or blessing yet another > anyone-can-spend `scriptPubKey` template, something we want to avoid which > is why SegWit has versions (i.e. we want SegWit to be the last > anyone-can-spend `scriptPubKey` template we bless for a **long** time). > > Explicit flagging is bad as well for privacy, which is another mark > against it. > Notice how Taproot improves privacy by making n-of-n indistinguishable > from 1-of-1 (and with proper design or a setup ritual, k-of-n can be made > indistinguishable from 1-of-1). > Notice as well that my first counterproposal is significantly more private > than explicit flagging, and my second coutnerproposal is also more private > if wallets change their anti-fee-sniping mitigation. > This privacy loss represented by explicit flagging will be resisted by > some people, especially those that use a bunch of random letters as a > pseudonym (because duh, privacy). > > (Yes, people can just decide not to use the privacy-leaking > explicitly-flagged outputs, but that reduces the anonymity set of people > who *are* interested in privacy, so people who are interested in privacy > will prefer that other people do not leak their privacy so they can hide > among *those* people as well.) > > You also probably need to keep some data with each output. > This can be done by explicitly storing that data in the output directly, > rather than a commitment to that data --- again, the "change outputs must > also be rate-limited" requirement needs to check those data. > > The larger data stored with the output is undesirable, ideally we want > each output to just be a commitment rather than contain any actual data, > because often a 20-byte commitment is smaller than the data that needs to > be stored. > For example, I imagine that your original proposal requires, for change > outputs, to store: > > * The actual rate limit. > * The time frame of the rate limit. > * The reduced rate limit, since we spent an amount within a specific time > frame (i.e. residual limit) which is why this is a change output. > * How long that time frame lasts. > * A commitment to the keys that can spend this. > > Basically, until the residual limit expires, we impose the residual limit, > then after the expiry of the residual limit we go back to the original rate > limit. > > The commitment to the keys itself takes at least 20 bytes, and if you are > planning a to support k-of-n then that takes at least 32 bytes. > If this was not explicitly tagged, then a 32 byte commitment to all the > necessary data would have been enough, but you do need the explicit tagging > for the "change outputs must be rate-limited
Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value
Good morning Zac, > Perhaps you could help me understand what would be required to implement the > *unmodified* proposal. That way, the community will be able to better assess > the cost (in terms of effort and risk) and weigh it against the perceived > benefits. Perhaps *then* we find that the cost could be significantly reduced > without any significant reduction of the benefits, for instance by slightly > compromising on the functionality such that no changes to consensus would be > required for its implementation. (I am skeptical that this would be possible > though). The cost reduction must be carefully weighed against the functional > gaps it creates. For one, such output need to be explicitly visible, to implement the "change outputs must also be rate-limited". A tx spending a rate-limited output has to know that one of the outputs is also a rate-limited output. This flagging needs to be done by either allocating a new SegWit version --- a resource that is not lightly allocated, there being only 30 versions left if my understanding is correct --- or blessing yet another anyone-can-spend `scriptPubKey` template, something we want to avoid which is why SegWit has versions (i.e. we want SegWit to be the last anyone-can-spend `scriptPubKey` template we bless for a **long** time). Explicit flagging is bad as well for privacy, which is another mark against it. Notice how Taproot improves privacy by making n-of-n indistinguishable from 1-of-1 (and with proper design or a setup ritual, k-of-n can be made indistinguishable from 1-of-1). Notice as well that my first counterproposal is significantly more private than explicit flagging, and my second coutnerproposal is also more private if wallets change their anti-fee-sniping mitigation. This privacy loss represented by explicit flagging will be resisted by some people, especially those that use a bunch of random letters as a pseudonym (because duh, privacy). (Yes, people can just decide not to use the privacy-leaking explicitly-flagged outputs, but that reduces the anonymity set of people who *are* interested in privacy, so people who are interested in privacy will prefer that other people do not leak their privacy so they can hide among *those* people as well.) You also probably need to keep some data with each output. This can be done by explicitly storing that data in the output directly, rather than a commitment to that data --- again, the "change outputs must also be rate-limited" requirement needs to check those data. The larger data stored with the output is undesirable, ideally we want each output to just be a commitment rather than contain any actual data, because often a 20-byte commitment is smaller than the data that needs to be stored. For example, I imagine that your original proposal requires, for change outputs, to store: * The actual rate limit. * The time frame of the rate limit. * The reduced rate limit, since we spent an amount within a specific time frame (i.e. residual limit) which is why this is a change output. * How long that time frame lasts. * A commitment to the keys that can spend this. Basically, until the residual limit expires, we impose the residual limit, then after the expiry of the residual limit we go back to the original rate limit. The commitment to the keys itself takes at least 20 bytes, and if you are planning a to support k-of-n then that takes at least 32 bytes. If this was not explicitly tagged, then a 32 byte commitment to all the necessary data would have been enough, but you do need the explicit tagging for the "change outputs must be rate-limited too". Note as well that the residual needs to be kept with the output. Bitcoin Core does not store transactions in a lookup table, it stores individual *outputs*. While the residual can be derived from the transaction, we do not have a transaction table. Thus, we need to explicitly put it on the output itself, directly, since we only have a lookup table for the unspent outputs, not individual transactions. (well there is `txindex` but that is an option for each node, not something consensus code can rely on) So yes, that "change outputs must also be rate-limited" is the big sticking point, and a lot of the "gaps" you worry about occur when we drop this bit. Drop this bit and you can implement it today without any consensus code change, and with privacy good enough to prevent people with random letters as pseudonym from trying to stop you. 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
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 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 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.
Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
Pieter Wuille wrote on 8/29/21 9:42 AM: On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev 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 ___ 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
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 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 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
