From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Rama Gan <ganrama@proton•me>
Cc: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Penlock, a paper-computer for secret-splitting BIP39 seed phrases
Date: Thu, 16 May 2024 13:27:55 +0000 [thread overview]
Message-ID: <ZkYJ21cloqyvT93G@camus> (raw)
In-Reply-To: <e1V4sbaLiJ4XGzEEEnr7lg2O1h3OxQabGcSoeTmDeo8bLVgIGhz9HHo3qtGQIVi-5aoU4xc2Kdj_qcC8Rt_xtFvQDahhXcIg4V0raMJxh2Y=@proton.me>
[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]
On Thu, May 16, 2024 at 07:43:29AM +0000, Rama Gan wrote:
> > But I guess this is explained by the large number of characters produced by
> > the checksum.
>
> For clarity, 45 mins was from a benchmark in real conditions. It includes the
> whole process of copying the seed phrase, checksumming it, generating the random
> share A, checksumming it, deriving both shares B and C, verifying the checksums
> and finally correcting a few mistakes. Recovery took 20 minutes.
>
> The checksum is the second source of inefficiency, the first one being that
> BIP39 isn't compact. GF(29) can encode 128 bits within 7 words, and the checksum
> would cost 7 more words. In comparison, BIP39 low density of information costs
> 10 more words (5 data + 5 checksum). With a compact data format, the entire
> 2-of-3 split process would take less than 30 minutes; and recovery with
> verification would be under 15 minutes. I don't know if it can be optimized
> further, but we're already looking at figures that the general public might find
> acceptable.
>
With BIP39 density you have 24 words (96 characters). With GF29
compaction you could get this down to 14 words (56 characters). But
codex32 does the same in 45 characters, plus a fixed/preprinted HRP.
(And 6 of those 45 are a header which is usually faster to deal with
since you're always dealing with the same characters.)
In your case, since there's no way to get down to 48 characters, I
wouldn't bother trying to compress any further. Either you fit in one
side of a cryptosteel (no) or you fit in two sides of a cryptosteel or
into a tube (yes, even without compression).
And I agree that the existing figures are not bad, especially because
the checksumming (which is the most common and also the least fun) is so
fast.
I think if you were able to squeeze an extra word of header data or
version info, that would be worth doing, but probably not at the expense
of making the user do a re-encoding phase. Which I suspect would be
needed to try to get more information density out of your characters.
> > Very cool. Though you say "single wheel" but you actually need two -- one to
> > get the solving window and one to actually do the recovery. If I understand
> > correctly, the "solving window" is equivalent to a "recovery symbol" in
> > codex32.
>
> The solving window is the is the distance between two shares, and not a Lagrange
> basis (to the best of my knowledge). It can be determined from the same single
> wheel, that already implements subtraction.
>
> [3]: The 2-of-M wheel "Recovery" window shows the distance between two shares:
> https://beta.penlock.io/2ofm-wheel.html
>
Ah, I understand. Looking again at your wheel, I see that it's a
combination slide wheel (for addition/subtraction) and slide chart (for
"recovery windows").
What I'm saying is that you don't need to have extra cutout windows for
the recovery windows. You should be able to just label the characters on
the inner wheel with them, similar to how you have already labeled =
with (1).
> > If so, despite the simple interpretation as "the difference between the
> > shares", this object is secretly a Lagrange polynomial and you can _also_
> > compute it using a slide wheel rather than a full lookup-table volvelle.
>
> I'm not sure if I understand that, but it sounds like I missed an optimization
> opportunity there. Can I ask you to develop that point a little?
>
I don't think this discussion of Lagrange polynomials is relevant
actually. My point is that you don't need the cutout squares, and I
think this is clearer if you think in terms of share index differences
than if you think in terms of Lagrange polynomials.
But. What I'm saying is that if you do the Lagrange polynomial
calculation using the formula from Wikipedia, magically your differences
will appear. They're the same thing, just expressed differently.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZkYJ21cloqyvT93G%40camus.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-05-16 15:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-12 18:04 'Rama Gan' via Bitcoin Development Mailing List
2024-05-13 13:40 ` Andrew Poelstra
2024-05-14 12:03 ` 'Rama Gan' via Bitcoin Development Mailing List
2024-05-14 13:42 ` Andrew Poelstra
2024-05-16 7:43 ` 'Rama Gan' via Bitcoin Development Mailing List
2024-05-16 13:27 ` Andrew Poelstra [this message]
2024-05-16 17:24 ` Andrew Poelstra
2024-05-24 10:39 ` 'Rama Gan' via Bitcoin Development Mailing List
2024-05-24 14:14 ` Andrew Poelstra
2024-05-24 15:02 ` 'Rama Gan' via Bitcoin Development Mailing List
2024-05-14 12:43 ` 'Rama Gan' via Bitcoin Development Mailing List
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=ZkYJ21cloqyvT93G@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=ganrama@proton$(echo .)me \
/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