I was thinking about a protocol for protecting against double spending. It would require a new opcode via a soft fork.

OP_CHECK_DOUBLE

This marks the transaction as invalid unless txd double spends one of the inputs.

If it replaced a NOP, then it would be backwards compatible.

This allows a system similar to channels to support double spend protection.

Client creates public key (Kc)

Merchant creates public keys (Km1 and Km2)

Client creates payment transaction (P) which pays double the amount

Code:

TXO1(Pays X):
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

TXO2(Pays X):
OP_IF
2 2 CHECKMULTISIG
OP_ELSE
OP_CHECK_DOUBLE OP_CHECKSIG
OP_ENDIF

Client creates refund transaction (R). It pays TX02 back to the the client but is time-locked 12 blocks in the future.

Client sends R to the Merchant

Merchant signs it with the private key for Km2 and sends back the signature.

Client verifies the signature, and sends P.

The merchant broadcasts P to the network. The merchant is now paid X.

12 blocks later the client spends the refund transaction to recover the deposit.

If the client successfully double spends the payment successfully, then P is cancelled, so the merchant gets nothing.

However, if the client attempts to double spend P, but fails, then the merchant gets double the amount.

If there is a 10% chance of a successful double spend, then double spending has a 90% chance of losing X and a 10% chance of gaining X. This makes it uneconomical to double spend.

The double spend "deposit" could be scaled with that probability. If only 5% of double spends succeed, then a merchant might demand a 10% double spend deposit.

OP_CHECK_DOUBLE would have to be accepted by > 50% of the miners like pay to script hash.

Maybe txd could be a digest of some kind, so that it doesn't get to large. For example, it might include internal states of the hashing function.