{"type":"rich","version":"1.0","author_name":"npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925u","author_url":"https://nostr.ae/npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-08-24\n🗒️ Summary of this message: Discussion on implementing multi-signature transactions for more secure Bitcoin wallets. Proposal for new 'standard' transactions and potential compatibility issues.\n📝 Original message:wow, with all the feature requests and bug fixing that needs to be done you\nwant to go off on a tangent.\n\nVision my friend, once centered on robust architecture, may then be directed\non a hard left turn.\n\nLets get a feature road map done, bug fix and testing framework set up\n\n... or fork this puppy to folks that can execute the above.\n\n-rick\n\nOn Wed, Aug 24, 2011 at 8:12 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003ewrote:\n\n\u003e It seems to me the fastest path to very secure, very-hard-to-lose\n\u003e bitcoin wallets is multi-signature transactions.\n\u003e\n\u003e To organize this discussion: first, does everybody agree?\n\u003e\n\u003e ByteCoin pointed to a research paper that gives a scheme for splitting\n\u003e a private key between two people, neither of which every knows the\n\u003e full key, but, together, both can DSA-sign transactions.  That's very\n\u003e cool, but it involves high-end cutting-edge crypto like zero-knowledge\n\u003e proofs that I know very little about (are implementations available?\n\u003e are they patented?  have they been thoroughly vetted/tested?  etc).\n\u003e So I'm assuming that is NOT the fastest way to solving the problem.\n\u003e\n\u003e If anybody has some open-source, patent-free, thoroughly-tested code\n\u003e that already does DSA-key-splitting, speak up please.\n\u003e\n\u003e\n\u003e I've been trying to get consensus on low-level 'standard' transactions\n\u003e for transactions that must be signed by 2 or 3 keys; current draft\n\u003e proposal is here:\n\u003e  https://gist.github.com/39158239e36f6af69d6f\n\u003e and discussion on the forums here:\n\u003e  https://bitcointalk.org/index.php?topic=38928.0\n\u003e ... and there is a pull request that is relevant here:\n\u003e  https://github.com/bitcoin/bitcoin/pull/319\n\u003e\n\u003e\n\u003e I still think it is a good idea to enable a set of new 'standard'\n\u003e multisignature transactions, so they get relayed and included into\n\u003e blocks.  I don't want to let \"the perfect become the enemy of the\n\u003e good\" -- does anybody disagree?\n\u003e\n\u003e The arguments against are that if the proposed standard transactions\n\u003e are accepted, then the next step is to define a new kind of bitcoin\n\u003e address that lets coins be deposited into a multisignature-protected\n\u003e wallet.\n\u003e\n\u003e And those new as-yet-undefined bitcoin addresses will have to be 2 or\n\u003e 3 times as big as current bitcoin addresses, and will be incompatible\n\u003e with old clients.\n\u003e\n\u003e So, if we are going to have new releases that are incompatible with\n\u003e old clients why not do things right in the first place, implement or\n\u003e enable opcodes so the new bitcoin addresses can be small, and schedule\n\u003e a block chain split for N months from now.\n\u003e\n\u003e My biggest worry is we'll say \"Sure, it'll only take a couple days to\n\u003e agree on how to do it right\" and six months from now there is still no\n\u003e consensus on exactly which digest function should be used, or whether\n\u003e or not there should be a new opcode for arbitrary boolean expressions\n\u003e involving keypairs.  And people's wallets continue to get lost or\n\u003e stolen.\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e EMC VNX: the world's simplest storage, starting under $10K\n\u003e The only unified storage solution that offers unified management\n\u003e Up to 160% more powerful than alternatives and 25% more efficient.\n\u003e Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/887027f8/attachment.html\u003e"}