{"type":"rich","version":"1.0","author_name":"npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h","author_url":"https://nostr.ae/npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-26\n📝 Original message:I will just chime in that I've been working on a similar spec for Armory\nto implement P2SH multisig and I came up with basically an identical\nscheme.  I think you covered most of what is needed.   The one thing I\ndid differently was try to match the BIP 32 structure, by keeping the\noriginal 3 levels (wallet, chain, addresses), and use 2*N chains to\nhandle the N different parties generating receiving and change\naddresses.  It's not necessary, but it follows more closely the\nthree-level scheme that BIP 32 originally envisioned.  I also concluded\nthat the chain indices are ordered by lexicographical sorting of root\npublic keys, but resorting each individual address.  There are use cases\nwhere it will be necessary for parties to know how to combine public\nkeys into a multi-sig address without knowing the root keys.\n\nAlso, for the purposes of one-off types of escrow multi-sig, we have\nincluded a \"wallet locator\" field in the transaction that must be passed\naround.  This \"wallet locator\" is stored with each key (perhaps at the\ntime public keys are collected and merged), and passed around with\ntransactions to be signed.  This allows lightweight devices like\nhardware wallets, to recognize their own keys.  It would encoded in a\nVAR_STR, and doesn't have to be meaningful to the other participants --\neach device would look at all signing slots in a transaction (either\nsinglesig or each key in a multisig) and would generate a public key\nalong each path, and see if the result matches.  If so, it can sign it. \nIf not, it must be someone else's.\n\nI bring this up, because this multisig wallet structure you're talking\nabout has a very simple \"wallet locator\" scheme -- all parties will use\nthe same locator for a given receiving address.  But that field should\nremain part of the data structure for each key, to accommodate all types\nof multisig, not just linked/parallel tree schemes. \n\n-Alan\n\n\n\n\nOn 04/25/2014 06:27 PM, Manuel Araoz wrote:\n\u003e Hi, I'm part of the team building copay\n\u003e \u003chttps://github.com/bitpay/copay\u003e, a multisignature P2SH HD\n\u003e wallet. We've been following the discussion regarding standardizing\n\u003e the structure for branches both on this list and on github (1\n\u003e \u003chttps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\u003e, 2\n\u003e \u003chttps://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki\u003e, 3\n\u003e \u003chttps://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki\u003e, 4\n\u003e \u003chttps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki\u003e, 5\n\u003e \u003chttps://github.com/bitcoin/bips/pull/52\u003e). Soon, we realized the\n\u003e assumptions in the discussions were not true for a multisig hd wallet,\n\u003e so we wanted to share our current approach to that, to get feedback\n\u003e and see if we can arrive to a new standard (and possibly a new 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\n\u003e use the P2SH address for that.\n\u003e  - The address generation process should not require communicating\n\u003e with other parties. (Thus, all parties must be able to generate all\n\u003e public keys)\n\u003e  - Transaction creation + signing requires communication between\n\u003e parties, of course.\n\u003e\n\u003e -------------------------------------------------\n\u003e\n\u003e Following BIP43, we're be using:\n\u003e m / purpose' / *\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 m / purpose' / cosigner_index / change / address_index\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\n\u003e of the party creating this address. The indices can be determined\n\u003e independently by lexicographically sorting the master public keys of\n\u003e each 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\n\u003e considering removing the index sync and doing the more elegant\n\u003e used-address discovery via a gap limit, as discussed in BIP44\n\u003e \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\n\u003e encrypted. Each party can generate any of the other's derived public\n\u003e keys, but only 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\u003e N needed public keys. They do this by deriving the public key in each\n\u003e of the different trees, but using the same path. They can then\n\u003e generate the multisig script and the corresponding p2sh address. In\n\u003e this way, each path corresponds to an address, but the public keys for\n\u003e that address come from 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\n\u003e knows the last used index in his own branch, because only he generates\n\u003e addresses there. Thus, he can generate the public keys for all of the\n\u003e others using the next index, and calculate the needed script for the\n\u003e address. \n\u003e\n\u003e /Example: /Cosigner #2 wants to receive a payment to the shared\n\u003e wallet. His last used index on his own branch is 4. Then, the path for\n\u003e the next receive address is m/$purpose/2/1/5. He uses this same path\n\u003e in all of the cosigners trees to generate a public key for each one,\n\u003e and from that he 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\n\u003e of the n cosigners wants to create an outgoing payment, for which\n\u003e he'll need a change address. He generates a new address using the same\n\u003e procedure as above, but using a separate index to track the used\n\u003e 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\n\u003e his 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\n\u003e trees to generate a public key for each one, and from that he gets the\n\u003e new p2sh 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\n\u003e stored in any of the p2sh multisig addresses (corresponding to any of\n\u003e the copayers' branches). This proposal is sent to the other parties,\n\u003e who decide if they want to sign. If they approve the proposal, they\n\u003e can generate their needed private key for that specific address (using\n\u003e the same path that generated the public key in that address, but\n\u003e deriving the private key instead), and sign it. Once the proposal\n\u003e reaches m signatures, any cosigner can broadcast it to the network,\n\u003e becoming final. The specifics of how this proposal is structured, and\n\u003e the protocol to accept or reject it, belong to another BIP, in my\n\u003e 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\n\u003e the master public keys and then using the same order for all derived\n\u003e addresses, but we couldn't think of any benefits of doing that (I\n\u003e mean, the benefits of knowing whose public key is which).\n\u003e - We originally thought we would need a non-hardened version of\n\u003e purpose for the path, because we needed every party to be able to\n\u003e generate all the public keys of the others. With the proposed path, is\n\u003e it true that the cosigners will be able to generate them, by knowing\n\u003e the extended purpose 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\n\u003e simultaneous payments to it. The ideal case is that each address\n\u003e receives at most one 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\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/c7d5c529/attachment.html\u003e"}