{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-26\n📝 Original message:I'm not sure I understand why you need any special structure for this at\nall. The way I'd do it is just use regular HD wallets for everyone, of the\nregular form, and then swap the watching keys. Why do people need to be\ngiven a cosigner index at all, given that they all have unique root keys\nanyway?\n\n\nOn Sat, Apr 26, 2014 at 12:27 AM, Manuel Araoz \u003cmanu at bitpay.com\u003e wrote:\n\n\u003e Hi, I'm part of the team building copay \u003chttps://github.com/bitpay/copay\u003e,\n\u003e a multisignature P2SH HD wallet. We've been following the discussion\n\u003e regarding standardizing the structure for branches both on this list and on\n\u003e github (1 \u003chttps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\u003e,\n\u003e 2 \u003chttps://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki\u003e, 3\u003chttps://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki\u003e,\n\u003e 4 \u003chttps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki\u003e, 5\u003chttps://github.com/bitcoin/bips/pull/52\u003e).\n\u003e Soon, we realized the assumptions in the discussions were not true for a\n\u003e multisig hd wallet, so we wanted to share our current approach to that, to\n\u003e get feedback and see if we can arrive to a new standard (and possibly a new\n\u003e BIP)\n\u003e\n\u003e These are our assumptions:\n\u003e  - N parties want to share an m-of-n wallet.\n\u003e  - Each party must generate their master private keys independently.\n\u003e  - Use multisig P2SH for all addresses.\n\u003e  - Use BIP32 to derive public keys, then create a multisig script, and use\n\u003e the P2SH address for that.\n\u003e  - The address generation process should not require communicating with\n\u003e other parties. (Thus, all parties must be able to generate all public keys)\n\u003e  - Transaction creation + signing requires communication between parties,\n\u003e of course.\n\u003e\n\u003e -------------------------------------------------\n\u003e\n\u003e Following BIP43, we're be using:\n\u003e\n\u003e\n\u003e m / purpose' / *\n\u003e\n\u003e where *purpose* is the hardened derivation scheme based on the new BIP\n\u003e number.\n\u003e We then define the following levels:\n\u003e\n\u003e\n\u003e m / purpose' / cosigner_index / change / address_index\n\u003e\n\u003e Each level has a special meaning detailed below:\n\u003e\n\u003e *cosigner_index* \u003chttp://en.wikipedia.org/wiki/Co-signing\u003e: the index of\n\u003e the party creating this address. The indices can be determined\n\u003e independently by lexicographically sorting the master public keys of each\n\u003e cosigner.\n\u003e\n\u003e *change*: 0 for change, 1 for receive address.\n\u003e\n\u003e *address_index*: Addresses are numbered from index 0 in sequentially\n\u003e increasing manner. We're currently syncing the max used index for each\n\u003e branch between all parties when they connect, but we're open to considering\n\u003e removing the index sync and doing the more elegant used-address discovery\n\u003e via a gap limit, as discussed in BIP44\u003chttps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit\u003e.\n\u003e We feel 20 might be too low though.\n\u003e\n\u003e *Wallet high-level description:*\n\u003e Each party generates their own extended master keypair and shares the\n\u003e extended purpose' public key with the others, which is stored encrypted.\n\u003e Each party can generate any of the other's derived public keys, but only\n\u003e his own private keys.\n\u003e\n\u003e *General address generation procedure:*\n\u003e When generating an address, each party can independently generate the N\n\u003e needed public keys. They do this by deriving the public key in each of the\n\u003e different trees, but using the same path. They can then generate the\n\u003e multisig script and the corresponding p2sh address. In this way, each path\n\u003e corresponds to an address, but the public keys for that address come from\n\u003e different trees.\n\u003e\n\u003e *Receive address case:*\n\u003e Each cosigner generates addresses only on his own branch. One of the n\n\u003e cosigners wants to receive a payment, and the others are offline. He knows\n\u003e the last used index in his own branch, because only he generates addresses\n\u003e there. Thus, he can generate the public keys for all of the others using\n\u003e the next index, and calculate the needed script for the address.\n\u003e\n\u003e *Example: *Cosigner #2 wants to receive a payment to the shared wallet.\n\u003e His last used index on his own branch is 4. Then, the path for the next\n\u003e receive address is m/$purpose/2/1/5. He uses this same path in all of the\n\u003e cosigners trees to generate a public key for each one, and from that he\n\u003e gets the new p2sh address.\n\u003e\n\u003e *Change address case:*\n\u003e Again, each cosigner generates addresses only on his own branch. One of\n\u003e the n cosigners wants to create an outgoing payment, for which he'll need a\n\u003e change address. He generates a new address using the same procedure as\n\u003e above, but using a separate index to track the used change addresses.\n\u003e\n\u003e *Example: *Cosigner #5 wants to send a payment from the shared wallet,\n\u003e for which he'll need a change address. His last used change index on his\n\u003e own branch is 11. Then, the path for the next change address is\n\u003e m/$purpose/5/0/12. He uses this same path in all of the cosigners trees to\n\u003e generate a public key for each one, and from that he gets the new p2sh\n\u003e address.\n\u003e\n\u003e\n\u003e *Transaction creation and signing:*\n\u003e When creating a transaction, first one of the parties creates a\n\u003e Transaction Proposal. This is a transaction that spends some output stored\n\u003e in any of the p2sh multisig addresses (corresponding to any of the\n\u003e copayers' branches). This proposal is sent to the other parties, who decide\n\u003e if they want to sign. If they approve the proposal, they can generate their\n\u003e needed private key for that specific address (using the same path that\n\u003e generated the public key in that address, but deriving the private key\n\u003e instead), and sign it. Once the proposal reaches m signatures, any cosigner\n\u003e can broadcast it to the network, becoming final. The specifics of how this\n\u003e proposal is structured, and the protocol to accept or reject it, belong to\n\u003e another BIP, in my opinion.\n\u003e\n\u003e *Final comments:*\n\u003e - We're currently lexicographically sorting the public keys for each\n\u003e address separately. We've read Mike Belshe's comments about sorting the\n\u003e master public keys and then using the same order for all derived addresses,\n\u003e but we couldn't think of any benefits of doing that (I mean, the benefits\n\u003e of knowing whose public key is which).\n\u003e - We originally thought we would need a non-hardened version of purpose\n\u003e for the path, because we needed every party to be able to generate all the\n\u003e public keys of the others. With the proposed path, is it true that the\n\u003e cosigners will be able to generate them, by knowing the extended purpose\n\u003e public key for each copayer? (m/purpose')\n\u003e - The reason for using separate branches for each cosigner is we don't\n\u003e want two of them generating the same address and receiving simultaneous\n\u003e payments to it. The ideal case is that each address receives at most one\n\u003e payment, requested by the corresponding cosigner.\n\u003e\n\u003e\n\u003e Thoughts?\n\u003e Manuel\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Start Your Social Network Today - Download eXo Platform\n\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e http://p.sf.net/sfu/ExoPlatform\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/fbf87fbc/attachment.html\u003e"}