From: Pieter Wuille <pieter.wuille@gmail•com>
To: "Russell O'Connor" <roconnor@blockstream•io>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] New serialization/encoding format for key material
Date: Sat, 23 Jun 2018 12:49:54 -0700 [thread overview]
Message-ID: <CAPg+sBihc83xBNCRR37-F2hnJ8Rs3C5pkWutF8iGdKAkDFcvKg@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkXhyGcHs3z-qq-eVwnTg3oqZf3dO25BtBY=PvTnOoucg@mail.gmail.com>
On Fri, Jun 15, 2018 at 8:54 AM, Russell O'Connor
<roconnor@blockstream•io> wrote:
>
>> 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.
Here are some more numbers then. It's important to note that the
number of correctable errors includes errors inside the checksum
characters themselves. So if you want to aim for a certain percentage
of correctable characters, the numbers go up much more dramatically.
For codes restricted to 341 characters total (including the checksum
characters), and assuming 103 data characters (enough for 512 bits):
* With 26 checksum characters (adding 25%, 20% of overall string), 7
errors can be corrected (5% of overall string)
* With 62 checksum characters (adding 60%, 38% of overall string), 17
errors can be corrected (10% of overall string)
* With 116 checksum characters (adding 113%, 53% of overall string),
33 errors can be corrected (15% of overall string)
* With 195 checksum characters (adding 189%, 65% of overall string),
60 errors can be corrected (20% of overall string)
For codes restricted to 1023 characters total (including the checksum
characters), and assuming 103 data characters (enough for 512 bits):
* With 27 checksum characters (adding 26%, 21% of overall string), 7
errors can be corrected (5% of overall string)
* With 64 checksum characters (adding 62%, 38% of overall string), 17
errors can be corrected (10% of overall string)
* With 127 checksum characters (adding 123%, 57% of overall string),
36 errors can be corrected (15% of overall string)
* With 294 checksum characters (adding 285%, 74% of overall string),
80 errors can be corrected (20% of overall string)
* With 920 checksum characters (adding 893%, 90% of overall string),
255 errors can be corrected (25% of overall string)
I'll gladly construct reference source code for any of these.
Cheers,
--
Pieter
next prev parent reply other threads:[~2018-06-23 19:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 6:30 shiva sitamraju
2018-05-30 14:08 ` Gregory Maxwell
2018-05-30 19:03 ` Jonas Schnelli
2018-06-03 16:51 ` Jonas Schnelli
2018-06-03 19:23 ` Pieter Wuille
2018-06-03 21:30 ` Jonas Schnelli
2018-06-13 2:44 ` Pieter Wuille
2018-06-15 15:54 ` Russell O'Connor
2018-06-23 19:49 ` Pieter Wuille [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-05-29 9:13 Jonas Schnelli
2018-06-13 14:58 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPg+sBihc83xBNCRR37-F2hnJ8Rs3C5pkWutF8iGdKAkDFcvKg@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox