Published on: 2014-04-28T01:37:00+00:00
In an email exchange between Thomas Voegtlin and Jeff Garzik, the issue of standardization of public keys in the redeem script was discussed. Voegtlin suggested that the public keys should be sorted in a standardized order to prevent the p2sh address from depending on their order. Garzik agreed with this solution, mentioning that it had already been implemented in some wallets.The discussion revolves around using a shared branch or separate branches for generating receiving addresses in a 2-of-2 multisig wallet. The issue with using one shared branch is that two cosigners could end up distributing the same address, which can be problematic. However, if each cosigner has their own unique seed and key hierarchy, then there is no shared branch. Instead, every address generated by either party is a 2-of-2 address using private seeds k1 and k2. In an email conversation, Mike Hearn discussed the use of HD wallets for cosigners and why a separate branch is necessary for each cosigner. Hearn suggests using regular HD wallets and swapping watching keys to avoid generating the same address and receiving simultaneous payments. By separating branches and having each cosigner use only one branch, this problem can be eliminated. The purpose of the cosigner_index is to prevent race conditions when receiving payments.In another email exchange, Mike Hearn proposed swapping watching keys instead of giving individuals a cosigner index since they all have unique root keys. Another individual agreed with this suggestion. The only standardization necessary may be the order of public keys in the redeem script to ensure that the p2sh address does not depend on the order of pubkeys.Manuel Araoz, part of the team that developed Copay, a multisignature P2SH HD wallet, shared their approach to a new standard for the structure of branches in such wallets. Each party generates their own extended master keypair and shares the extended purpose’ public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys, and then generate the multisig script and the corresponding p2sh address. All parties must be able to generate all public keys, and transaction creation and signing requires communication between parties.The team building the multisignature P2SH HD wallet called Copay has shared their approach for a new standard in response to discussions on standardizing the structure for branches. Each cosigner generates their own extended master keypair and shares the extended purpose' public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys. They do this by deriving the public key in each of the different trees, but using the same path. One of the n cosigners wants to receive a payment to the shared wallet. He knows the last used index in his own branch because only he generates addresses there. Thus, he can generate the public keys for all of the others using the next index and calculate the needed script for the address. When creating a transaction, first one of the parties creates a Transaction Proposal. This is a transaction that spends some output stored in any of the p2sh multisig addresses (corresponding to any of the copayers' branches). This proposal is sent to the other parties, who decide if they want to sign. If they approve the proposal, they can generate their needed private key for that specific address (using the same path that generated the public key in that address, but deriving the private key instead), and sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network, becoming final.The team building the multisignature P2SH HD wallet has shared their approach to address generation and transaction signing for a multisig HD wallet. They have proposed the use of BIP43, with levels defined as m / purpose' / cosigner_index / change / address_index. Each level has a special meaning, including the index of the party creating the address, whether it is for change or receive address, and addresses numbered from index 0 in sequentially increasing manner. The team's high-level description of their wallet involves each party generating their own extended master keypair and sharing the extended purpose' public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys. In the receive address case, only one of the n cosigners generates addresses and knows the last used index in his own branch, while in the change address case, one of the n cosigners wants to create an outgoing payment, for which he'll need a change address. When creating a transaction, one of the parties creates a Transaction Proposal which is sent to the other parties who decide if they want to sign it.
Updated on: 2023-08-01T09:03:33.563527+00:00