every night, and keeps those backups for
> years, are they in violation of whatever pseudo-law is involved?
>
> I think it's a bit early to think about these things right now. Michael
> Grønager and Jan Møller
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:
https://github.co
>Of course, this is an especially difficult case, as you must send the
>double-spend after the original transaction - normally just sending a
>non-standard tx to Eligius first would suffice. Note how this defeats
>Andresen's double-spend-relay patch(3) as proposed since the
>double-spend is a non-s
Treating testnet differently is quite the norm, we have that in BIP 32, 38,
70, SIPA private keys (no BIP for that I guess), bitcoin addresses etc. At
the same time none of them define values for alt coins as far as I recall.
On Tue, Apr 22, 2014 at 5:49 PM, Tamas Blummer wrote:
> I use several
Tue, Apr 22, 2014 at 1: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.
>
> I haven't seen commentary from you on the Kogelman draft, it would be
> helpful there:
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 wrote:
> On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> > Necessary Shares = M+1, not a problem
> >
> >
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 wrote:
> On Tuesday, 22 April 2014, at 10:27 am, Jan Møll
>
>
> > - 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.
>
>
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 secret (be it a HD master
seed or a private key) in such a way
The reason why client side certificates have never gained traction because
it is a pain to safely store/backup secrets.
In bitcoinland we are forced to solve the problem of safely storing
secrets, and over the years we have come up with software and hardware
solutions to make this safer and easier
10 matches
Mail list logo
