📅 Original date posted:2014-04-04
📝 Original message:On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:
> >> I still repeat my concern that any private key secret sharing scheme
> >> really ought to be compatible with threshold ECDSA, otherwise we're
> >> just going to have another redundant specification.
> >
> > I have that concern too, but then how can we support secrets of sizes other than 256 bits? A likely use case for this BIP (even more likely than using it to decompose Bitcoin private keys) is using it to decompose BIP32 master seeds, which can be 512 bits in size. We can't use secp256k1_n as the modulus there.
>
> Well, if you're not doing anything homorphic with the result the
> computation should probably be over a small field (for computational
> efficiency and implementation simplicity reasons) and the data split
> up, this also makes it easier to deal with many different data sizes,
> since the various sizes will more efficiently divide into the small
> field. The field only needs to be large enough to handle the number
> of distinct shares you wish to issue, so even an 8 bit field would
> probably be adequate (and yields some very simple table based
> implementations).
Are you proposing to switch from prime fields to a binary field? Because if you're going to "break up" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code.
> If that route is taken, rather than encoding BIP32 master keys, it
> would probably be prudent to encode the encryption optional version
> https://bitcointalk.org/index.php?topic=258678.0 ... and if we're
> talking about a new armored private key format then perhaps we should
> be talking about Mark Friedenbach's error correcting capable scheme:
> https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki
> (though it would be nicer if we could find a decoding scheme that
> supported list decoding without increasing the complexity of a basic
> implementation, since an advanced recovery tool could make good use of
> a list decode)
Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :)
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:17:07
in reply to nevent1q…afg8
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetPublished at
2023-06-07 15:17:07Event JSON
{
"id": "d2cb22de447fb52d55ceeb65f68891750fa54c7c4c1bc25738e8993ceb7884c8",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151027,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"26d0e18a2b7e794ff17ea42a82250296d1956a95951a516bcd12b52d51c39c9e",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-04-04\n📝 Original message:On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote:\n\u003e On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e \u003e On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:\n\u003e \u003e\u003e I still repeat my concern that any private key secret sharing scheme\n\u003e \u003e\u003e really ought to be compatible with threshold ECDSA, otherwise we're\n\u003e \u003e\u003e just going to have another redundant specification.\n\u003e \u003e\n\u003e \u003e I have that concern too, but then how can we support secrets of sizes other than 256 bits? A likely use case for this BIP (even more likely than using it to decompose Bitcoin private keys) is using it to decompose BIP32 master seeds, which can be 512 bits in size. We can't use secp256k1_n as the modulus there.\n\u003e \n\u003e Well, if you're not doing anything homorphic with the result the\n\u003e computation should probably be over a small field (for computational\n\u003e efficiency and implementation simplicity reasons) and the data split\n\u003e up, this also makes it easier to deal with many different data sizes,\n\u003e since the various sizes will more efficiently divide into the small\n\u003e field. The field only needs to be large enough to handle the number\n\u003e of distinct shares you wish to issue, so even an 8 bit field would\n\u003e probably be adequate (and yields some very simple table based\n\u003e implementations).\n\nAre you proposing to switch from prime fields to a binary field? Because if you're going to \"break up\" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code.\n\n\u003e If that route is taken, rather than encoding BIP32 master keys, it\n\u003e would probably be prudent to encode the encryption optional version\n\u003e https://bitcointalk.org/index.php?topic=258678.0 ... and if we're\n\u003e talking about a new armored private key format then perhaps we should\n\u003e be talking about Mark Friedenbach's error correcting capable scheme:\n\u003e https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki\n\u003e (though it would be nicer if we could find a decoding scheme that\n\u003e supported list decoding without increasing the complexity of a basic\n\u003e implementation, since an advanced recovery tool could make good use of\n\u003e a list decode)\n\nWeren't you just clamoring for implementation *simplicity* in your previous paragraph? :)",
"sig": "89acf5953a4ece87608b24ba71f49abb443cfcae75ed2f92816de5b6e5a14edb423feeb24aee54cd66bd4d7c53c89da1e87195232fb99c03665119dc8dc229bb"
}