Bitcoin Multisig Payment Protocol

bitcoin_multisig_payment_proto.mediawiki

  BIP: ?
  Title: Multisig Payment Protocol
  Author: Martin Habovštiak <martin.habovstiak@gmail.com>
  Status: Draft
  Type: ?
  Created: 2014-01-30

Table of Contents Abstract Motivation Protocol Backward compatibility Security implications

Abstract

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.

Motivation

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:

1. 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.
2. Secure fiat currency exchange.
3. General purpose arbiter, who doesn't wish to hold bitcoins on his own.

How this would work after implementation of this BIP:

1. All three parties manually exchange (and verify) the addresses.
2. They construct a multisig address.
3. The customer sends amount to the multisig address and others confirm the transaction.
4. The seller sends goods to the customer.
5. 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.

This process is inconvenient and error-prone if done manually. The payment protocol should work as follows:

1. The customer clicks "pay" on arbiter's website, a payment link is generated.
2. The customer inputs the link into his wallet and sees "Pay AMOUNT bitcoins to SELLER_NAME arbitrated by ARBITER_NAME( plus deposit DEPOSIT_AMOUNT)( plus arbiter fee ARBITER_FEE)?"
3. The customer clicks "Confirm"
4. After the delivery customer opens his wallet and confirms the signing of final transaction.

Protocol

The protocol is based on BIP70 with these extensions:

1.  The client sends Accept: application/bitcoin-paymentrequest; multisig=1 HTTP 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.
2.  Multisig Output message MUST have amount field equal to AMOUNT + DEPOSIT_AMOUNT
3. If deposit is used, optional deposit field should declare it.
4. The arbiter fee output should be marked with string field purpose = "arbiter fee"
5. Instead of script field, two fields arbiter_pubkey, dst_pubkey should be provided containing public keys. (Output script is generated by client.)
6. In Payment, the client provides generated multisig_script and partially signed refund_tx spending AMOUNT + DEPOSIT_AMOUNT to his address (so refund can be done without his interaction). Field refund_to contains the address to which deposit should be returned.
7.  PaymentACK contains confirm_tx field with partially signed transaction, spending AMOUNT to sellers output and DEPOSIT_AMOUNT to client-specified address. The signature may be provided either by the arbiter or the seller.

Backward compatibility

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.

Security implications

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.

Flaws:

• If the attacker is the customer, he may benefit from attacking the server if AMOUNT is 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.