"Gavin Andresen" <gavinandre...@gmail.com> wrote: > It seems to me the fastest path to very secure, very-hard-to-lose > bitcoin wallets is multi-signature transactions. > > To organize this discussion: first, does everybody agree?
I agree. For example, a corporate wallet can require threshold signatures to disburse. Or for personal use you can have a couple of additional keys, one stored on a secure device for confirmation and one offline as emergency backup if you lose your secure device. ... > I've been trying to get consensus on low-level 'standard' transactions > for transactions that must be signed by 2 or 3 keys; current draft > proposal is here: > https://gist.github.com/39158239e36f6af69d6f > and discussion on the forums here: > https://bitcointalk.org/index.php?topic=38928.0 > ... and there is a pull request that is relevant here: > https://github.com/bitcoin/bitcoin/pull/319 For context - I am the author of the latter. > I still think it is a good idea to enable a set of new 'standard' > multisignature transactions, so they get relayed and included into > blocks. I don't want to let "the perfect become the enemy of the > good" -- does anybody disagree? > > The arguments against are that if the proposed standard transactions > are accepted, then the next step is to define a new kind of bitcoin > address that lets coins be deposited into a multisignature-protected > wallet. > > And those new as-yet-undefined bitcoin addresses will have to be 2 or > 3 times as big as current bitcoin addresses, and will be incompatible > with old clients. Incompatible at the UI level, but not at the block chain level. Changing the block chain rules will be quite an undertaking. You will have to set a block number for the rule change a few months in advance and will have to get agreement from the pools. I think it is important to increase trust in the bitcoin ecosystem sooner than that. The current flat exchange rate and difficulty may be a signal that people are getting risk averse. > So, if we are going to have new releases that are incompatible with > old clients why not do things right in the first place, implement or > enable opcodes so the new bitcoin addresses can be small, and schedule > a block chain split for N months from now. > > My biggest worry is we'll say "Sure, it'll only take a couple days to > agree on how to do it right" and six months from now there is still no > consensus on exactly which digest function should be used, or whether > or not there should be a new opcode for arbitrary boolean expressions > involving keypairs. And people's wallets continue to get lost or > stolen. That is my worry too. We already have working code for this (pull 319), and the addresses are not so long as to be unusable. I hope we can move forward on the existing code and in parallel move forward on block chain rule proposals at an agreed upon block number. -- Bobby Groff ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
