rich1.0npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925uhttps://nostr.ae/npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925unjumphttps://nostr.ae📅 Original date posted:2011-08-24 🗒️ Summary of this message: Discussion on implementing multi-signature transactions for more secure Bitcoin wallets. Proposal for new 'standard' transactions and potential compatibility issues. 📝 Original message:wow, with all the feature requests and bug fixing that needs to be done you want to go off on a tangent. Vision my friend, once centered on robust architecture, may then be directed on a hard left turn. Lets get a feature road map done, bug fix and testing framework set up ... or fork this puppy to folks that can execute the above. -rick On Wed, Aug 24, 2011 at 8: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? > > ByteCoin pointed to a research paper that gives a scheme for splitting > a private key between two people, neither of which every knows the > full key, but, together, both can DSA-sign transactions. That's very > cool, but it involves high-end cutting-edge crypto like zero-knowledge > proofs that I know very little about (are implementations available? > are they patented? have they been thoroughly vetted/tested? etc). > So I'm assuming that is NOT the fastest way to solving the problem. > > If anybody has some open-source, patent-free, thoroughly-tested code > that already does DSA-key-splitting, speak up please. > > > 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 > > > 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. > > 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. > > > > -- > -- > Gavin Andresen > > > ------------------------------------------------------------------------------ > 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/887027f8/attachment.html>