On 12 May 2014 15:09, Jan Møller jan.mol...@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 Java implementation of what is called BIPSS in lack of an official number
can be found here:
https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/crypto/BipSs.java
(passing all test vectors)
Which is based on a GF2^8 implementation here:
A fork of Matt's proposal converted to GF(2^8) is here:
https://github.com/cetuscetus/btctool/blob/bip/bip-.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
On Tuesday, 22 April 2014, at 10:06 am, Jan Møller wrote:
This is a very useful BIP, and I am very much looking forward to
implementing it in Mycelium, in particular for bip32 wallets.
To me this is not about whether to use SSS instead of multisig
transactions. In the end you want to protect a
On Tue, Apr 22, 2014 at 1:06 AM, Jan Møller jan.mol...@gmail.com wrote:
This is a very useful BIP, and I am very much looking forward to
implementing it in Mycelium, in particular for bip32 wallets.
I haven't seen commentary from you on the Kogelman draft, it would be
helpful there:
- Please allow M=1. From a usability point of view it makes sense to
allow
the user to select 1 share if that is what he wants.
How does that make sense? Decomposing a key/seed into 1 share is
functionally equivalent to dispensing with the secret sharing scheme
entirely.
I agree that
Extra encoding for testnet is quite useless complexity in face of many alt
chains.
BIPS should be chain agnostic.
Regards,
Tamas Blummer
http://bitsofproof.com
On 22.04.2014, at 10:35, Matt Whitlock b...@mattwhitlock.name wrote:
On Tuesday, 22 April 2014, at 4:11 am, Matt Whitlock wrote:
On
Necessary Shares = M+1, not a problem
I would probably encode N-of-M in 1 byte as I don't see good use cases with
more than 17 shares. Anyway, I am fine with it as it is.
On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock b...@mattwhitlock.namewrote:
On Tuesday, 22 April 2014, at 10:27 am, Jan
I am concerned about space, but more about usability :-)
I'll definitely use both M and the checksum.
On Tue, Apr 22, 2014 at 10:43 AM, Matt Whitlock b...@mattwhitlock.namewrote:
On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
Necessary Shares = M+1, not a problem
I would
I do not suggest to encode the chain, in contrary.
I consider the encoding of main and testnet in WIF and BIP32 as legacy, that I
ignore, and suggest that new BIPs should no longer carry this forward.
Regards,
Tamas Blummer
http://bitsofproof.com
signature.asc
Description: Message signed
On Tuesday, 22 April 2014, at 10:39 am, Tamas Blummer wrote:
Extra encoding for testnet is quite useless complexity in face of many alt
chains.
BIPS should be chain agnostic.
I would argue that Bitcoin should be altcoin-agnostic. :)
I have no interest in catering to altcoins. But that's just
I did comment on it back in october (
https://bitcointalk.org/index.php?topic=258678.msg3298089#msg3298089) :-)
But I must admit that I haven't been tracking it since then.
I have never been a proponent of BIP 38 (which this BIP is derived from)
and generally think that encrypting a secret with a
On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock b...@mattwhitlock.namewrote:
On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
- Please allow M=1. From a usability point of view it makes sense to
allow
the user
Is there a reason you prefer doing the M-1 offset as opposed to limiting
the range to 255 instead? Seems like something that will certainly confuse
some developers in exchange for adding one more value at the high end of a
range. I don't gather there's much difference between 255 and 256 here is
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
Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
Unfortunately few of the alts ever figured this out.
On 04/22/2014 01:39 AM, Tamas Blummer wrote:
Extra encoding for testnet is quite useless complexity in face of many
alt chains.
BIPS should be chain agnostic.
Regards,
Yes, it is current norm. I am questioning if we should hang on to it in BIPs.
I see testnet as a tool for a certain type of testing. Its existence is likely
a consequence of Satoshi not writing unit tests and having automated
integration tests, but creating a shadow chain to try things out,
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
On Monday, 7 April 2014, at 7:07 pm, Gregory Maxwell wrote:
On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock b...@mattwhitlock.name wrote:
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
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.
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
Regarding the choice of fields, any implementation of this BIP will
need big integer arithmetic to do base-58 anyway.
Nah, it doesn't. E.g.
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
Regarding the choice of fields, any implementation of this BIP will
need big integer arithmetic to do base-58 anyway.
Nah, it doesn't. E.g.
On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock b...@mattwhitlock.name wrote:
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
Regarding the choice of fields, any implementation of this BIP will
On Fri, Apr 4, 2014 at 6:51 AM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
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
On Friday, 4 April 2014, at 5:51 pm, Nikita Schmidt wrote:
On 4 April 2014 01:42, Matt Whitlock b...@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
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
On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote:
On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock b...@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
On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote:
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
On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote:
On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote:
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
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock b...@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
On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote:
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock b...@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
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
Great stuff Matt!
I have an implementation of Shamir's Secret Sharing here:
https://github.com/bitsofproof/bop-bitcoin-client-misc/blob/master/src/main/java/com/bitsofproof/supernode/misc/ShamirsSecretSharing.java
What was missing was nice serialization. Thanks a lot for defining and starting
Hi Matt,
I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that
is I think more future relevant than a single key.
Therefore suggest to adapt the BIP for a length used there typically 16 or 32
bytes and have a magic code to indicate its use as key vs. seed.
Regards,
On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key,
that is I think more future relevant than a single key.
Therefore suggest to adapt the BIP for a length used there typically 16 or 32
bytes and have a magic
Matt, could you expand on use cases for which you see Shamir's Secret Sharing
as the best tool for the job? In particular, when do you see that it would be
superior to simply going with multisig in the first place? Perhaps you see
these as complimentary approaches, toward defense in depth? In
Matt, could you expand on use cases for which you see Shamir's Secret Sharing
Scheme as the best tool for the job? In particular, when do you see that it
would be superior to simply going with multisig in the first place? Perhaps you
see these as complimentary approaches, toward
On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
Matt, could you expand on use cases for which you see Shamir's Secret Sharing
Scheme as the best tool for the job? In particular, when do you see that it
would be superior to simply going with multisig in the first place? Perhaps
On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
Matt, could you expand on use cases for which you see Shamir's Secret Sharing
Scheme as the best tool for the job? In particular, when do you see that it
would be superior to simply going with multisig in the first place? Perhaps
Enlightening; thanks, Matt. And apologies to the list for my earlier
inadvertent double-post.
On Mar 29, 2014, at 12:16 PM, Matt Whitlock b...@mattwhitlock.name wrote:
On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
Matt, could you expand on use cases for which you see Shamir's
Right - the explanation in the BIP about the board of directors is IMO a
little misleading. The problem is with splitting a private key is that at
some point, *someone* has to get the full private key back and they can
then just remember the private key to undo the system. CHECKMULTISIG avoids
On Saturday, 29 March 2014, at 2:36 pm, Mike Hearn wrote:
Right - the explanation in the BIP about the board of directors is IMO a
little misleading. The problem is with splitting a private key is that at
some point, *someone* has to get the full private key back and they can
then just
On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Multisig does not allow for the topology I described. Say the board has seven
directors, meaning the majority threshold is four. This means the
organization needs the consent of six individuals in order to sign a
On Saturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote:
On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock b...@mattwhitlock.name
wrote:
Multisig does not allow for the topology I described. Say the board has
seven directors, meaning the majority threshold is four. This means the
On Saturday, 29 March 2014, at 7:36 am, Gregory Maxwell wrote:
On Sat, Mar 29, 2014 at 7:28 AM, Watson Ladd w...@uchicago.edu wrote:
This is not the case: one can use MPC techniques to compute a
signature from shares without reconstructing the private key. There is
a paper on this for
Nobody is exactly thrilled by IsStandard, but it's not a deal-killer. If
you have a use for a new type of script it can be added, and people do
upgrade:
http://getaddr.bitnodes.io/dashboard/chart/?days=30
As you can see the 0.9 rollout is going OK. If a new script type had been
made standard for
On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key,
that is I think more future relevant than a single key.
Therefore suggest to adapt the BIP for a length used there typically 16 or 32
bytes and have a magic
Armory has had Fragmented Backups for over a year, now. Advanced
users love it. Though, I would say it's kind of difficult to
standardize the way I did it since I was able to implement all the
finite field math with recursion, list comprehensions and python
arbitrary-big-integers in about 100
On Saturday, 29 March 2014, at 12:59 pm, Alan Reiner wrote:
I won't lie, there's a lot of work that goes into making an interface
that makes this feature usable. The user needs clear ways to identify
which fragments are associated with which wallet, and which fragments
are compatible with
Right now there are also people simply taking base58-encoded private
keys and running them through -split.
It has a lot going for it, since it can easily be reassembled on any
Linux machine without special software (B Poettering's Linux command
line implementation[1] seems to be included
On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
Thanks. This is great, although it makes some critical references to an
ACM paper
I had Matt's answer already, see below, but then I recognized that the group
was not cc:-d, so I repeat:
It would help on the user interface to include into individual shares:
1. Number of shares needed
2. A few bytes fingerprint of the secret so shares that likely belong together
can be
On Saturday, 29 March 2014, at 10:25 am, Dev Random wrote:
On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
Thanks. This is
On Sat, Mar 29, 2014 at 10:38 AM, Matt Whitlock b...@mattwhitlock.name wrote:
But can threshold ECDSA work with BIP32?
Yes.
In other words, can a threshold ECDSA public key be generated from separate,
precomputed private keys,
No.
can it only be generated interactively?
Yes.
But see the
On Sat, 2014-03-29 at 13:38 -0400, Matt Whitlock wrote:
On Saturday, 29 March 2014, at 10:25 am, Dev Random wrote:
On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
On Sat, Mar 29, 2014 at 01:42:01PM -0400, Matt Whitlock wrote:
On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote:
Right now there are also people simply taking base58-encoded private
keys and running them through -split.
It has a lot going for it, since it can easily be
On Saturday, 29 March 2014, at 10:48 am, devrandom wrote:
On Sat, 2014-03-29 at 13:38 -0400, Matt Whitlock wrote:
Threshold ECDSA certainly sounds nice, but is anyone working on a BIP
for it? I would take it on myself, but I don't understand it well
enough yet, and publicly available
On 03/29/2014 01:19 PM, Matt Whitlock wrote:
I intentionally omitted the parameter M (minimum subset size) from the shares
because including it would give an adversary a vital piece of information.
Likewise, including any kind of information that would allow a determination
of whether the
On 03/29/2014 02:00 PM, Matt Whitlock wrote:
On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
On 03/29/2014 01:19 PM, Matt Whitlock wrote:
I intentionally omitted the parameter M (minimum subset size) from the
shares because including it would give an adversary a vital piece of
On Saturday, 29 March 2014, at 2:08 pm, Alan Reiner wrote:
Regardless of how does it, I believe that obfuscating that
information is bad news from a usability perspective. Undoubtedly,
users will make lots of backups of lots of wallets and think they
remember the M-parameter but don't.
Armory does exactly this: it defines the Fragment ID as the first few
bytes of the hash of the root pubKey + M-parameter, converted to
base58. Then it explains to the user All fragments with the same
fragment ID are compatible (which only works if you use deterministic
coefficients). Each
Den 29 mar 2014 19:15 skrev Matt Whitlock b...@mattwhitlock.name:
On Saturday, 29 March 2014, at 2:08 pm, Alan Reiner wrote:
Regardless of how does it, I believe that obfuscating that
information is bad news from a usability perspective. Undoubtedly,
users will make lots of backups
On 29.03.2014, at 18:46, Gregory Maxwell gmaxw...@gmail.com wrote:
In this case I don't see anything wrong with specifying secret
sharing, but I think— if possible— it should be carefully constructed
so that the same polynomials and interpolation code can be used for
threshold signatures (when
63 matches
Mail list logo
