Nikita Schmidt [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-03 to 2014-08-14
💬 Posted a total of 7 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:25:11

- reply

📅 Original date posted:2014-08-14
📝 Original message:On 12 May 2014 15:09, Jan Møller <jan.moller at gmail.com> wrote:
>
> I think having 3 encoding formats (long/short/compact) is over engineered,
> and basically only makes implementing the standard a pain in the rear. From
> a user experience point of view only the long format makes sense, and it is
> only a few bytes longer than the short version.
>
True. Since nobody has objected, the draft has been reworked and is
much leaner now:
https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki .
The reasons for not making M and checksum fields optional are added to
the Rationale section.
The main difference is that the shared secret can be in encoded form,
e.g. SIPA or BIP38 instead of a plain private key. This makes SSS a
general purpose container for any kind of secret data. The benefits
are:
- no need to change the spec to carry another type of content;
- testnet and altcoins do not need any treatment in this spec;
- content-specific metadata, such as compressed/uncompressed,
encrypted/non-encrypted, key inception time point etc., are encoded
together with the secret, rather than provided for separately and
individually in this spec.
As we are now dealing with secrets of arbitrary length, GF(256) as the
underlying field becomes much more advantageous than GF(large prime).
An inconvenience of variable length is that we have no control of the
Base58 prefix. This was solved by moving the magic prefix outside of
the Base58 encoded content: SSS-abcdefgh. 'SSS-' acts as the
application identifier both to humans and machines, and abcdefgh is
the Base58 encoding of the share without any application/magic bytes.
(This may seem mildly controversial, but is there a better way?)

2023-06-07 17:21:00

- reply

📅 Original date posted:2014-05-05
📝 Original message:A fork of Matt's proposal converted to GF(2^8) is here:
https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki
Other changes include:
- only six application/version bytes are allocated, which is the
minimum to ensure that the encoded form starts with S in all cases;
- encoded prefixes are SK/SL for a shared private key
(mainnet/testnet) and SS/ST for a shared BIP32 seed;
- the only hash function in use is SHA-256, which is the all-purpose
hash function in the Bitcoin protocol;
- double SHA is used for similarity with Bitcoin, although Jan and I
believe single SHA is enough in this application;
- bias-less encoding of M and x, because there can't be more than 255
shares over GF(2^8).
On 23 April 2014 09:16, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Apr 22, 2014 at 10:33 PM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> So you agree, that SSS should not contain specific flag for testnet?
>>
>> Or for that matter not even BIP32 needs them since it is not an address to
>> send to.
>
> I think the convention we have so far is that addresses and address
> relate thing we share normally contain an opaque 'version' identifier
> which we use to identify the purpose for the data (E.g. network
> meaning, etc.) and I think its a generally reasonable custom.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:17:15

- reply

📅 Original date posted:2014-04-22
📝 Original message:>
> A fair point. I'll add some prefixes for testnet.
>
I've looked at the latest draft and am worried about the increased AVB
namespace usage. Would it make sense to differentiate main/testnet in
the prefix byte instead of the AVB? Perhaps aiming for ST rather than
TS.
> I'll welcome forks of my draft BIP. I don't really have the inclination to research GF(2^8) secret sharing schemes and write an implementation at the present time, but if someone wants to take my BIP in that direction, then okay.
I'm willing to fork it.
The maximum number of shares possible over GF(2^8) is 255. That would
make M and x biases unnecessary.

2023-06-07 17:17:10

- reply

📅 Original date posted:2014-04-10
📝 Original message:> What do you think a big-integer division by a word-sized divisor *is*? Obviously rolling your own is always an option. Are you just saying that Base58 encoding and decoding is easier than Shamir's Secret Sharing because the divisors are small?
Well, yes, to be fair, in fact it is. The small divisor and lack of
modulo arithmetic make base-58 encoding and decoding noticeably
smaller and easier than Shamir's Secret Sharing over GF(P256).

2023-06-07 17:17:09

- reply

📅 Original date posted:2014-04-07
📝 Original message:>
> I'd be fine with changing the key fingerprint algorithm to something else. Do you like CRC16?
>
I like CRC16. Do you intend to use it in conjunction with a cryptographic hash?
Regarding the choice of fields, any implementation of this BIP will
need big integer arithmetic to do base-58 anyway. The operations
required for SSS are nearly the same as for base-58 and can probably
be done by the same subset of the chosen bignum library. So in fact
using GF(2^8) will add complexity to both the BIP and its
implementations. However, the maths in GF(2^8) is so simple that this
additional complexity can be considered negligible.
As a co-author of a bitcoin application running on a real
microcontroller (not the sort of big-iron thing Trezor runs on), I was
also going to implement my SSS over a 256-bit prime field. (I am not
going into 512-bit master seeds at this time.)
Uniform processing of secrets of any size (instead of using different
primes for different cases) is a valid argument in favour of GF(2^8),
though. I have no preference one way or another.

2023-06-07 17:17:06

- reply

📅 Original date posted:2014-04-04
📝 Original message:On 4 April 2014 01:42, Matt Whitlock <bip at mattwhitlock.name> wrote:
> 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.
Right, of course. Sorry, I didn't notice there was an update. Two
bytes are plenty.
I'm worried however about the dependency on SHA-512, which may be
stretching it for a tiny embedded application. The other uses of
HashL can be avoided. We are balancing here between consistency with
the rest of this proposal, where everything is done via HashL, and
consistency with the general practice of generating fingerprints with
SHA-256, like in Base58Check.
Similarly, re-assembly software suddenly finds itself having to
implement Hash16 just to check this particular fingerprint. So I'd
vote for a more traditional approach here, also considering that HashL
is designed specifically to generate numbers in a finite field.
>
>> Encoding for the testnet is not specified.
>
> Hmm, is that actually needed?
It's been a tradition to support it in general, however I guess it's
not really needed here. I'm happy without a dedicated testnet
encoding.
>
>> 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.
Yes, "5" for uncompressed private key and "K" or "L" for compressed
private key. One A/VB and three prefixes in base58. Am I the only
one to see this as a counter-example?
However, thinking about this, I can find logic in wanting to stabilise
text prefixes at a cost of six A/V bytes (as per the latest spec).
There are only 58 first characters versus 256 AVBs, so we should
rather be saving the former.
>> 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.
Fair enough. Although I would have chosen the field order (p) simply
because that's how all arithmetic already works in bitcoin. One field
for everybody. It's also very close to 2^256, although still smaller
than your maximum prime. Now of course with different bit lengths we
have to pick one consistency over others.
>
>> 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.
Wow, big deal. It's hard to imagine anyone needing exactly 256
shares, but who knows. And with j = x (starting from 1) we'd get
user-friendly share numbering and simpler formulas in the spec and
possibly in the implementation, with no off-by-one stuff. And M
instead of M-2...
>
> If you want a sentinel value reserved for future extensions, then you might take notice that 0xFFFF 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 0xFFFF 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!)
Exactly. Thank you. Without these fields, a secret share still fits
into a 29x29 QR code. Add one more byte and it'll need a 33x33.
Imagine engraving that onto metal plates! Or the hassle of going
above 32 bits per line in a tiny embedded system.

2023-06-07 17:17:05

- reply

📅 Original date posted:2014-04-03
📝 Original message: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.