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.