Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Matt Whitlock
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Gregory Maxwell
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:

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller
- 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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Matt Whitlock
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Matt Whitlock
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Justin A
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Nikita Schmidt
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

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-22 Thread Wladimir
On Tue, Apr 22, 2014 at 3:30 PM, Warren Togami Jr. wtog...@gmail.com wrote: Development Roadmap of Bitcoin Core 0.9.2 The Bitcoin Core developers have a desire to do a mostly bug-fix and translation update release in v0.9.2. A feature and string freeze will start about 3 weeks from now. ACK,

Re: [Bitcoin-development] bits: Unit of account

2014-04-22 Thread Natanael
I am in favor of xbit, my only concern is if average Joes will consider that name stupid (like various attempts at cool branding with unusual letters like Q, X, Z, etc). We should see if we can get support for it in the community and if there would be any notable opposition against it or not. If

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Mark Friedenbach
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,

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
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,

[Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-22 Thread Peter Todd
You may have seen my reddit post of the same title a few days ago: http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/ I've done some more experiments since, with good results. For instance here's a real-world double-spend of the gambling service

Re: [Bitcoin-development] Economics of information propagation

2014-04-22 Thread Tom Harding
Jonathan - These are a few things I've been wishing for recent data on: - 95th percentile transaction propagation time vs. fees/kb, vs. total fees - Count of blocks bypassing well-propagated transactions vs. fees/kb, vs. total fees - Signed-double-spend confirmation probability vs.

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-22 Thread Tom Harding
Since no complete solution to preventing 0-confirmation respends in the bitcoin network has been proposed, or is likely to exist, when evaluating partial solutions let's ask what kind of network does this move toward? Does the solution move toward a network with simple rules, where the

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-22 Thread Matt Whitlock
On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote: A network where transaction submitters consider their (final) transactions to be unchangeable the moment they are transmitted, and where the network's goal is to confirm only transactions all of whose UTXO's have not yet been seen in