Quote from: tholenst on May 18, 2013, 08:01:58 PM

OK, I'll try.

Buyer B wants to buy an item with value 0.1 BTC from Merchant M. B has 20.4 BTC in total. These are stored in two transactions outputs B0, B1, both of the buyer.

B0: Transaction Output with 0.4 BTC, private key known to B
B1: Transaction Output with 20 BTC, private key known to B

Now, to buy the item, the buyer sends two transactions Tx2 and Tx3 to the merchant. The merchant has address

Tx2:
  Input B0
  Outputs
   1: 0.1 BTC to
   2: 0.3 BTC to (another address of B)

Tx3:
  Input B1
  Outputs:
   1: 0.1 BTC to
   2: 9.9 BTC to
   *only valid with two spends of B0*

the transaction Tx3 is special (this would need an extension of the scripting language). In order to use it, one needs to provide two *different* spendings of B0.

The merchant M gets both these transactions, waits 10 seconds, and then gives the item to B. If later another transaction of B0 shows up before transaction Tx2 is in a block, he can broadcast Tx3; and it will be worthwile for a miner to use it (note that it has 10BTC fee included).

There is nothing stopping Tx3 from being broadcast and accepted by the network (assuming input B1 is from standard Tx), so the merchant could extort the buyer under threat of prematurely broadcasting. Scripts are only evaluated when someone tries to spend outputs. Tx3 coins would be sent to an address that is unspendable unless the script conditions were met (presumably, proof of a dbl spend). There is also nothing stopping the buyer from dbl spending B1, making the "safety" Tx invalid.

I am unconvinced there is a way to do what this thread is proposing that isn't exploitable. The proposers have the burden of proof to show otherwise. For instance, you cannot wave your hand and say there is a non-exploitable way to make a Tx valid only when a dbl spend attempt occurs. That is a major change to Tx scripting and will require technical details on your part.