Re: [Bitcoin-development] Finite monetary supply for Bitcoin
Matt Whitlock wrote: > The creation date in your BIP header has the wrong format. It should be > 01-04-2014, per BIP 1. > At first, I thought this was a second April Fool's joke, but then I looked and saw that all of the BIPs really do use this format. As far as I can tell, we are using this insane format because RFC 822 predates ISO 8601 by half a decade. Since we don't have half a gajillion mail servers to patch, we could, if we desired, adopt a sensible date format here. The cost to the community would be minimal, with probably not more than a half dozen people needing to update scripts. It could even be as simple as one guy running sed s/parseabomination/parsedate/g -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
On Sat, Mar 29, 2014 at 2:10 PM, Matt Whitlock wrote: > Okay, you've convinced me. However, it looks like the consensus here is that > my BIP is unneeded, so I'm not sure it would be worth the effort for me to > improve it with your suggestions. Discussion of whether you should or should not use SSS is separate from whether you should or should not write a BIP. If people are using SSS in the field, it is better to write a BIP than not. Informational BIPs describing existing practice can be useful. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
On Thursday, 3 April 2014, at 4:41 pm, Nikita Schmidt wrote: > I agree with the recently mentioned suggestion to make non-essential > metadata, namely key fingerprint and degree (M), optional. Their > 4-byte and 1-byte fields can be added individually at an > implementation's discretion. During decoding, the total length will > determine which fields are included. The fingerprint field, Hash16(K), is presently specified as a 16-bit field. Rationale: There is no need to consume 4 bytes just to allow shares to be grouped together. And if someone has more than 100 different secrets, they probably have a good system for managing their shares and won't need the hash anyway. > Encoding for the testnet is not specified. Hmm, is that actually needed? > Speaking of encoding, is it not wasteful to allocate three different > application/version bytes just for the sake of always starting with > 'SS'? It would be OK if it were accepted as a BIP, but merely as a > de-facto standard it should aim at minimising future chances of > collision. I agree on principle, however I think the more user-acceptable behavior is for all base58-encoded Shamir shares to begin with a common prefix, such as "SS". Users are accustomed to relying on the prefix of the base58 encoding to understand what the object is: "1" for mainnet pubkey hash, "3" for mainnet script hash, "5" for uncompressed private key, "P" for passphrase-protected private key, etc. > I'd add a clause allowing the use of random coefficients instead of > deterministic, as long as the implementation guarantees to never make > another set of shares for the same private key or master seed. I'm not sure that's necessary, as this is an Informational BIP. Implementations are free to ignore it. Shares with randomly selected coefficients would work just fine in a share joiner that conforms to the BIP, so I would expect implementors to feel free to ignore the deterministic formula and use randomly selected coefficients. > What about using the same P256 prime as for the elliptic curve? Just > for consistency's sake. The initial draft of this BIP used the cyclic order (n) of the generator point on the secp256k1 elliptic curve as the modulus. The change to the present scheme was actually done for consistency's sake, so all sizes of secret can use a consistently defined modulus. > Also, I'm somewhat inclined towards using the actual x instead of j in > the encoding. I find it more direct and straightforward to encode the > pair (x, y). And x=0 can denote a special case for future extensions. > There is no technical reason behind this, it's just for (subjective) > clarity and consistency. There is a technical reason for encoding j rather than x[j]: it allows for the first 256 shares to be encoded, rather than only the first 255 shares. If you want a sentinel value reserved for future extensions, then you might take notice that 0x is an invalid key fingerprint, along with several other values, and also that 0xFF is an unusable value of M−2, as that would imply M=257, but the scheme can only encode up to 256 shares, so one would never have enough shares to meet the threshold. I considered having the two optional fields be mandatory and allowing 0x and 0xFF as "redacted" field values, but I like allowing the shares to be shorter if the optional fields are omitted. (Imagine engraving Shamir secret shares onto metal bars by hand with an engraving tool. Fewer characters is better!) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detailed gitian build guide
On Thu, 2014-04-03 at 07:51 +0200, Wladimir wrote: > > On Thu, Apr 3, 2014 at 6:47 AM, devrandom > wrote: > Nice! > > I wonder how much of this could be scripted. > > > Everything, probably, using vmbuilder (and/or vagrant as Nick Simpson > suggests). But that's not the point here. It is to provide exact steps > that people can follow to get a basic (virtual) machine that they can > use to do gitian builds. Understood. > > I didn't want to end up with a > gitian-builder-that-builds-a-gitian-builder :-) The host machine may > not even have any scripting languages installed (in the case of > Windows). Yes, I can see the turtles there. > > > It may be possible to script *some* parts (most of the quoted bash > script is runnable as script) without automating the entire process, > but I hope that over time we can make Gitian itself easier to > use/setup, so that less steps are needed in the first place. Understood. :) I would definitely like to see in Gitian any improvements that make it easier for newcomers to get started. > > > Wladimir > > > -- Miron / devrandom -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Matt Whitlock wrote: > Okay, you've convinced me. However, it looks like the consensus here is > that my BIP is unneeded, so I'm not sure it would be worth the effort > for me to improve it with your suggestions. I need your BIP. We are going to implement SSS and we'd rather stick with something publicly discussed, even if it has not formally become a BIP, than invent our own stuff. I'll go ahead and comment on the current proposal here. BIP or no BIP, I propose to finalise this spec anyway for those who want to implement SSS now or in future. I agree with the recently mentioned suggestion to make non-essential metadata, namely key fingerprint and degree (M), optional. Their 4-byte and 1-byte fields can be added individually at an implementation's discretion. During decoding, the total length will determine which fields are included. For example, as a compromise between usability and security, the metadata can be supplied out-of-band, like in plain text accompanying the Base-58 encoded share. Encoding for the testnet is not specified. Speaking of encoding, is it not wasteful to allocate three different application/version bytes just for the sake of always starting with 'SS'? It would be OK if it were accepted as a BIP, but merely as a de-facto standard it should aim at minimising future chances of collision. I'd add a clause allowing the use of random coefficients instead of deterministic, as long as the implementation guarantees to never make another set of shares for the same private key or master seed. What about using the same P256 prime as for the elliptic curve? Just for consistency's sake. Also, I'm somewhat inclined towards using the actual x instead of j in the encoding. I find it more direct and straightforward to encode the pair (x, y). And x=0 can denote a special case for future extensions. There is no technical reason behind this, it's just for (subjective) clarity and consistency. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
