📅 Original date posted:2018-06-15
📝 Original message:> For codes designed for length 341 (the first length enough to support
> 512 bits of data):
> * correct 1 error = 3 checksum characters
> * correct 2 errors = 7 checksum characters
> * correct 3 errors = 11 checksum characters
> * correct 4 errors = 15 checksum characters
> * correct 5 errors = 19 checksum characters
> * ...
> * correct 7 errors = 26 checksum characters (~ length * 1.25)
> * correct 13 errors = 51 checksum characters (~ length * 1.5)
> * correct 28 errors = 102 checksum characters (~ length * 2)
>
> So it really boils down to a trade-off between length of the code, and
> recovery properties.
>
At the risk of making the proposal more complex, I wonder if it might be
better to support multiple checksum variants? The trade-off between code
length and recovery seems to be largely determined by the user's medium of
storage, which is likely to vary from person to person. I personally would
probably be interested in the 51 or even 102 character checksums variants.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180615/0d043e8d/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:12:48
in reply to nevent1q…6n9w
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:12:48Event JSON
{
"id": "d9e24ffe397b784a419d68afea888e1e717ac39b69dc2a24619bc6ceab636060",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161568,
"kind": 1,
"tags": [
[
"e",
"8fb615948865860f25fd6b1793e512bab6bc5d35c31efb44e9c1188c8de338e8",
"",
"root"
],
[
"e",
"f5559477a43e10914c3edb8a6a396ae4541c3aa75ab0d466bf3062c4e3d740bd",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2018-06-15\n📝 Original message:\u003e For codes designed for length 341 (the first length enough to support\n\u003e 512 bits of data):\n\u003e * correct 1 error = 3 checksum characters\n\u003e * correct 2 errors = 7 checksum characters\n\u003e * correct 3 errors = 11 checksum characters\n\u003e * correct 4 errors = 15 checksum characters\n\u003e * correct 5 errors = 19 checksum characters\n\u003e * ...\n\u003e * correct 7 errors = 26 checksum characters (~ length * 1.25)\n\u003e * correct 13 errors = 51 checksum characters (~ length * 1.5)\n\u003e * correct 28 errors = 102 checksum characters (~ length * 2)\n\u003e\n\u003e So it really boils down to a trade-off between length of the code, and\n\u003e recovery properties.\n\u003e\n\nAt the risk of making the proposal more complex, I wonder if it might be\nbetter to support multiple checksum variants? The trade-off between code\nlength and recovery seems to be largely determined by the user's medium of\nstorage, which is likely to vary from person to person. I personally would\nprobably be interested in the 51 or even 102 character checksums variants.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180615/0d043e8d/attachment.html\u003e",
"sig": "941002fc619a8742cfa4a547344c368859afcb229e79176b19ead25092ae2dfe2e6ddf86a9bbad23e83ec0204e5966a4682b5df845af19288462a130e6663525"
}