BIP: ? Title: Multisig Payment Protocol Author: Martin Habovštiak <firstname.lastname@example.org> Status: Draft Type: ? Created: 2014-01-30
Table of Contents
This BIP describes improvement on payment protocol BIP70 in order to make use of Bitcoin multisignature features to increase security of Bitcoin payments while maintaining good usability. The aim of this BIP is NOT to solve the trust problem but to avoid attacks on a single entity holding a huge amount of money.
BIP70 introduced huge improvement in the Bitcoin payments but it lacks multisignature support. It is possible to specify multisig output in the
script field of Output message but there is no way for the user to verify authenticity of particular public keys. Also, BIP70 allows extensions but there is no standardized way for multisig outputs.
Let's look at some common situations where multisig can improve security:
- Online retailer like e-bay who doesn't wish to hold bitcoins on his own. Instead he would like to create multisig made of addresses provided by the customer, the seller and himself.
- Secure fiat currency exchange.
- General purpose arbiter, who doesn't wish to hold bitcoins on his own.
- All three parties manually exchange (and verify) the addresses.
- They construct a multisig address.
- The customer sends amount to the multisig address and others confirm the transaction.
- The seller sends goods to the customer.
- The customer confirms the delivery by signing the transaction spending to the address of the seller. In the case of inappropriate rejection, the arbiter and the seller can spend the coins. In the case of rightful rejection, the arbiter and the customer can both spend the coins.
- The customer clicks "pay" on arbiter's website, a payment link is generated.
- The customer inputs the link into his wallet and sees "Pay
ARBITER_NAME( plus deposit
DEPOSIT_AMOUNT)( plus arbiter fee
- The customer clicks "Confirm"
- After the delivery customer opens his wallet and confirms the signing of final transaction.
The protocol is based on BIP70 with these extensions:
- The client sends
Accept: application/bitcoin-paymentrequest; multisig=1HTTP header field. Server which accepts only multisig payments MUST reject any request without such header field. Server which accepts both payment types SHOULD prefer multisig one.
- Multisig Output message MUST have
amountfield equal to
- If deposit is used, optional
depositfield should declare it.
- The arbiter fee output should be marked with string field
purpose = "arbiter fee"
- Instead of
scriptfield, two fields
dst_pubkeyshould be provided containing public keys. (Output script is generated by client.)
- In Payment, the client provides generated multisig_script and partially signed refund_tx spending
DEPOSIT_AMOUNTto his address (so refund can be done without his interaction). Field
refund_tocontains the address to which deposit should be returned.
- PaymentACK contains
confirm_txfield with partially signed transaction, spending
AMOUNTto sellers output and
DEPOSIT_AMOUNTto client-specified address. The signature may be provided either by the arbiter or the seller.
This protocol is NOT FULLY compatible with BIP70. While the server can support both protocols, there is no way old client can pay to multisig. The reason is to avoid losing coins (because old client would have no way to confirm payment) and forcing server to accept less secure protocol. The protocol is still very similar to BIP70, so it should be easy to improve existing BIP70 implementation.
Proposed protocol provides these security improvements:
- No need for "hot wallets" - multisig keys are harmless on their own and fees can be sent to cold wallet (ideally using BIP32).
- In case of arbiter disappearance, customer can still confirm the delivery. (Or the seller can refund the customer.)
- Nobody can take all the bitcoins from the arbiter by either force or server attack.
- If the attacker is the customer, he may benefit from attacking the server if
AMOUNTis big enough. This can be mitigated by keeping multisig keys of such transactions in a cold wallet.
- If the client lost confirmation transaction, he must manually communicate with the arbiter or the seller to recover it. This draft should be improved to make it easier.