📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Honestly, that sounds a lot more complicated than what I have now. I made my current implementation because I just wanted something simple that would let me divide a private key into shares for purposes of dissemination to my next of kin et al.
I suggest you go look at some of the other secret sharing
implementations that use GF(2^8), they end up just being a couple of
dozen lines of code. Pretty simple stuff, and they work efficiently
for all sizes of data, there are implementations in a multitude of
languages. There are a whole bunch of these.
> I already have a fairly polished implementation of my BIP, and it's not written in a "very high-level language"; it's C++, and the parts that do the big-integer arithmetic are basically C. I'm using the GMP library: very straightforward, very reliable, very fast.
With respect for the awesome work that GMP is— It's 250,000 lines of
LGPLed code. It's not just "pic microcontrollers" that would find
that scale of a dependency unwelcome.
> Do you have a use case in mind that would benefit from byte-wise operations rather than big-integer operations? I mean, I guess if you were trying to implement this BIP on a PIC microcontroller, it might be nice to process the secret in smaller bites. (No pun intended.) But I get this feeling that you're only pushing me away from the present incarnation of my proposal because you think it's too similar (but not quite similar enough) to a threshold ECDSA key scheme.
It lets you efficiently scale to any size data being encoded without
extra overhead or having additional primes. It can be compactly
implemented in Javascript (there are several implementations you can
find if you google), it shouldn't be burdensome to implement on a
device like a trezor (much less a real microcontroller).
And yea, sure, it's distinct from the implementation you'd use for
threshold signing. A threshold singing one would lack the size agility
or the easy of implementation on limited devices. So I do think that
if there is to be two it would be good to gain the advantages that
can't be achieved in an threshold ECDSA compatible approach.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:17:08
in reply to nevent1q…g6r3
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:17:08Event JSON
{
"id": "90fa75018f5da341fecbef99612ff4c3c12170506e17978c65e4cabe4073709c",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151028,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"ce308ee6fca30a0d59e0bdfaca1df8bcc6d893b8f5ab7c81d076ae53ec0a8022",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2014-04-04\n📝 Original message:On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e Honestly, that sounds a lot more complicated than what I have now. I made my current implementation because I just wanted something simple that would let me divide a private key into shares for purposes of dissemination to my next of kin et al.\n\nI suggest you go look at some of the other secret sharing\nimplementations that use GF(2^8), they end up just being a couple of\ndozen lines of code. Pretty simple stuff, and they work efficiently\nfor all sizes of data, there are implementations in a multitude of\nlanguages. There are a whole bunch of these.\n\n\u003e I already have a fairly polished implementation of my BIP, and it's not written in a \"very high-level language\"; it's C++, and the parts that do the big-integer arithmetic are basically C. I'm using the GMP library: very straightforward, very reliable, very fast.\n\nWith respect for the awesome work that GMP is— It's 250,000 lines of\nLGPLed code. It's not just \"pic microcontrollers\" that would find\nthat scale of a dependency unwelcome.\n\n\u003e Do you have a use case in mind that would benefit from byte-wise operations rather than big-integer operations? I mean, I guess if you were trying to implement this BIP on a PIC microcontroller, it might be nice to process the secret in smaller bites. (No pun intended.) But I get this feeling that you're only pushing me away from the present incarnation of my proposal because you think it's too similar (but not quite similar enough) to a threshold ECDSA key scheme.\n\nIt lets you efficiently scale to any size data being encoded without\nextra overhead or having additional primes. It can be compactly\nimplemented in Javascript (there are several implementations you can\nfind if you google), it shouldn't be burdensome to implement on a\ndevice like a trezor (much less a real microcontroller).\n\nAnd yea, sure, it's distinct from the implementation you'd use for\nthreshold signing. A threshold singing one would lack the size agility\nor the easy of implementation on limited devices. So I do think that\nif there is to be two it would be good to gain the advantages that\ncan't be achieved in an threshold ECDSA compatible approach.",
"sig": "fd0a7def20f031ea278c40fdb06632108a7c11e46743cf9c7ac886f9f1870ae2d03948e4df0ae0db7ba26e073eb76eeb29b37da3f46fff3fc174ee3bf8dc6fc5"
}