{"type":"rich","version":"1.0","author_name":"npub1ldnkgsksgfdvdzn3e2fgdtdxudrsl35qu3jfup0h2kwrxhg2477sddfrax","author_url":"https://nostr.ae/npub1ldnkgsksgfdvdzn3e2fgdtdxudrsl35qu3jfup0h2kwrxhg2477sddfrax","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-25\n📝 Original message:Hi, I'm part of the team building copay \u003chttps://github.com/bitpay/copay\u003e,\na multisignature P2SH HD wallet. We've been following the discussion\nregarding standardizing the structure for branches both on this list and on\ngithub (1 \u003chttps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\u003e,\n2 \u003chttps://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki\u003e,\n3\u003chttps://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki\u003e,\n4 \u003chttps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki\u003e,\n5\u003chttps://github.com/bitcoin/bips/pull/52\u003e).\nSoon, we realized the assumptions in the discussions were not true for a\nmultisig hd wallet, so we wanted to share our current approach to that, to\nget feedback and see if we can arrive to a new standard (and possibly a new\nBIP)\n\nThese are our assumptions:\n - N parties want to share an m-of-n wallet.\n - Each party must generate their master private keys independently.\n - Use multisig P2SH for all addresses.\n - Use BIP32 to derive public keys, then create a multisig script, and use\nthe P2SH address for that.\n - The address generation process should not require communicating with\nother parties. (Thus, all parties must be able to generate all public keys)\n - Transaction creation + signing requires communication between parties,\nof course.\n\n-------------------------------------------------\n\nFollowing BIP43, we're be using:\n\n\nm / purpose' / *\n\nwhere *purpose* is the hardened derivation scheme based on the new BIP\nnumber.\nWe then define the following levels:\n\n\nm / purpose' / cosigner_index / change / address_index\n\nEach level has a special meaning detailed below:\n\n*cosigner_index* \u003chttp://en.wikipedia.org/wiki/Co-signing\u003e: the index of\nthe party creating this address. The indices can be determined\nindependently by lexicographically sorting the master public keys of each\ncosigner.\n\n*change*: 0 for change, 1 for receive address.\n\n*address_index*: Addresses are numbered from index 0 in sequentially\nincreasing manner. We're currently syncing the max used index for each\nbranch between all parties when they connect, but we're open to considering\nremoving the index sync and doing the more elegant used-address discovery\nvia a gap limit, as discussed in\nBIP44\u003chttps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit\u003e.\nWe feel 20 might be too low though.\n\n*Wallet high-level description:*\nEach party generates their own extended master keypair and shares the\nextended purpose' public key with the others, which is stored encrypted.\nEach party can generate any of the other's derived public keys, but only\nhis own private keys.\n\n*General address generation procedure:*\nWhen generating an address, each party can independently generate the N\nneeded public keys. They do this by deriving the public key in each of the\ndifferent trees, but using the same path. They can then generate the\nmultisig script and the corresponding p2sh address. In this way, each path\ncorresponds to an address, but the public keys for that address come from\ndifferent trees.\n\n*Receive address case:*\nEach cosigner generates addresses only on his own branch. One of the n\ncosigners wants to receive a payment, and the others are offline. He knows\nthe last used index in his own branch, because only he generates addresses\nthere. Thus, he can generate the public keys for all of the others using\nthe next index, and calculate the needed script for the address.\n\n*Example: *Cosigner #2 wants to receive a payment to the shared wallet. His\nlast used index on his own branch is 4. Then, the path for the next receive\naddress is m/$purpose/2/1/5. He uses this same path in all of the cosigners\ntrees to generate a public key for each one, and from that he gets the new\np2sh address.\n\n*Change address case:*\nAgain, each cosigner generates addresses only on his own branch. One of the\nn cosigners wants to create an outgoing payment, for which he'll need a\nchange address. He generates a new address using the same procedure as\nabove, but using a separate index to track the used change addresses.\n\n*Example: *Cosigner #5 wants to send a payment from the shared wallet, for\nwhich he'll need a change address. His last used change index on his own\nbranch is 11. Then, the path for the next change address is\nm/$purpose/5/0/12. He uses this same path in all of the cosigners trees to\ngenerate a public key for each one, and from that he gets the new p2sh\naddress.\n\n\n*Transaction creation and signing:*\nWhen creating a transaction, first one of the parties creates a Transaction\nProposal. This is a transaction that spends some output stored in any of\nthe p2sh multisig addresses (corresponding to any of the copayers'\nbranches). This proposal is sent to the other parties, who decide if they\nwant to sign. If they approve the proposal, they can generate their needed\nprivate key for that specific address (using the same path that generated\nthe public key in that address, but deriving the private key instead), and\nsign it. Once the proposal reaches m signatures, any cosigner can broadcast\nit to the network, becoming final. The specifics of how this proposal is\nstructured, and the protocol to accept or reject it, belong to another BIP,\nin my opinion.\n\n*Final comments:*\n- We're currently lexicographically sorting the public keys for each\naddress separately. We've read Mike Belshe's comments about sorting the\nmaster public keys and then using the same order for all derived addresses,\nbut we couldn't think of any benefits of doing that (I mean, the benefits\nof knowing whose public key is which).\n- We originally thought we would need a non-hardened version of purpose for\nthe path, because we needed every party to be able to generate all the\npublic keys of the others. With the proposed path, is it true that the\ncosigners will be able to generate them, by knowing the extended purpose\npublic key for each copayer? (m/purpose')\n- The reason for using separate branches for each cosigner is we don't want\ntwo of them generating the same address and receiving simultaneous payments\nto it. The ideal case is that each address receives at most one payment,\nrequested by the corresponding cosigner.\n\n\nThoughts?\nManuel\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/65b0a04c/attachment.html\u003e"}