Published on: 2011-06-22T20:44:38+00:00
Gavin Andresen proposed the idea of publishing a new type of bitcoin address called "m of n address" that requires m out of n signatures to spend. The proposed use-case for this browser-centric flow is a 2-of-3 scenario, where the user selects a transaction observer and is redirected to the observer by the merchant. The observer presents the multisign address and terms and conditions, under which the observer will sign. The user copy/pastes the multisign address to their bitcoin client and sends funds.After some blocks pass by, the merchant ships the product. For redemption, the merchant reminds the user to release funds, and the user creates a partial tx, which pays out to merchant-addr and emails or copy-pastes it to the merchant. Finally, the merchant signs and publishes the tx. This process requires two pastes for funding and one paste for redemption. A browser plug-in would reduce the user effort to a couple of confirmatory clicks.In a discussion, Gavin presented a potential solution to reduce address length involving 3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL CHECKMULTISIGVERIFY. However, upon further consideration, he realized that this approach may not be feasible as it would require distributing each party's pubkey ahead of time. Failure to do so could result in the loss of pubkeys and an inability to provide hash(pubkey1+2+3) EQUALVERIFY. Gavin suggested that either the pubkeys or the hash160(pubkey)'s should be distributed ahead of time, rendering the reduction in address length moot. Bobby Groff was part of this discussion.Gavin Andresen proposed the creation of a new type of bitcoin address that is an "m of n address" which requires m of n signatures to spend. He suggested publishing a really long address with all n public keys, citing his current 2-of-3 example as a new address type. Gavin also wondered if the straightforward "n PUBKEYS m CHECKMULTISIG" transaction type is the right thing to do and suggested that 2 of 2 and 2 of three should be done following the pattern of the standard DUP HASH160 etc. transaction type. Spending those transactions would mean putting the m signatures and the n public keys in the TxIn, but sending funds would only require the hash of the sum of the public keys. The major advantage of summing is shorter address for the end user to copy-paste.The author is questioning whether the "n PUBKEYS m CHECKMULTISIG" transaction type is appropriate. The public key is hashed for convenience purposes, but it would not be necessary if a higher level protocol was in place to verify the identities of the parties involved in the multipay transactions. In that case, the verification process would be automated and typing convenience would no longer be a concern.During a conversation, someone suggests that the word 'escrow' should not be used in a patch as it is only one use case for multisignature (multisig) transactions. They suggest using 'multisign' or 'multipay' instead of 'escrow' in the patch. Bobby Groff agrees with the suggestion and decides to rename it to 'multisign'.Gavin Andresen has suggested a new type of bitcoin payment address that could be generic and contain a version byte, m, n, hash of xor of all n public keys and a checksum. The purpose of this address would be for an "m of n address" where anyone could pay into it but would require m of n signatures to spend. This could be useful in a scenario where an escrow requires m of n signatures to release funds securely. Andresen suggests that the higher level protocol for pay-to-escrow should just involve getting a bitcoin address via https or other secure mechanism. Andresen also questions whether the straightforward "n PUBKEYS m CHECKMULTISIG" transaction type is the right thing to do and suggests that 2 of 2 and 2 of three should have a different transaction type. Spending those transactions would mean putting the m signatures and the n public keys in the TxIn, but sending funds you'd only need the hash of the sum of the public keys.In a conversation between Mike and an unknown individual, it was revealed that Satoshi Nakamoto did not provide much information on the implementation of MULTISIG transactions. The unknown individual had written up about half of what Satoshi had told him but required more details. Mike suggested hard-coding new standard script templates in script.cpp Solver() to support 1/2 of 2 and 1/2/3 of 3 signatures.
Updated on: 2023-08-01T01:59:43.572918+00:00