rich1.0npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925uhttps://nostr.ae/npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925unjumphttps://nostr.ae📅 Original date posted:2011-08-24 🗒️ Summary of this message: Discussion on the use of multi-signature transactions for secure Bitcoin wallets, including the possibility of new Bitcoin addresses and opcodes. 📝 Original message:On Wed, Aug 24, 2011 at 8:45 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote: > On Wed, Aug 24, 2011 at 11:12 AM, Gavin Andresen > <gavinandresen at 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? > > It's a good tool which we should have in our tool-belt. > > Though it's a bit of when you are a hammer all problems are nails. > This issue can also be addressed by things like external private key > protectors. But someone would have to build one. > > Someone might be more inclined to build such a thing if the software > had good support for tracking public keys without private keys, and > generating unsigned transactions for export to the device for signing. > > > ByteCoin pointed to a research paper that gives a scheme for splitting > > a private key between two people, neither of which every knows the > [snip] > > So I'm assuming that is NOT the fastest way to solving the problem. > > Regardless, it might be useful to contact the authors. > > > 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? > > I agree. > > > 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. > > > > 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. > > One way of doing this would be to have an address which hashes an > ordered concatenation of many addresses (perhaps plus a length > argument). To redeem you provide the public keys which are signing, > plus the addresses which aren't signing, and the receiver validates. > > If it can be done, then yes, I agree it would be worth forking the chain. > > This _feels_ like something which could and should be done with the > existing (but disabled opcodes). > > > It's not exclusive, however, with a long N-address address type for > multisig destinations. We could support that _now_ and defer the > 'compressed version' until after people have experience with this > usage. The only cost would be supporting this address type forever, > which isn't that bad. > > It's also important to note that incompatibility wouldn't be complete: > The only limit is that old clients couldn't send funds to escrow > addresses— which is an issue no matter how you encode the information. > > > ------------------------------------------------------------------------------ > 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/4805602a/attachment.html>