Re: Preventing double-spending attacks with semi-trusted 3rd parties

Quote from: gglon on April 30, 2013, 10:12:40 AM

No. Imagine that it is like sending bunch of bitcoin to an "M of N address" before the actual tx. To perform actual tx, your and some trusted parties private keys are needed. So you make tx with specified output at will. Because a merchant trusts those parties won't make double spend, he doesn't need to wait for confirmation.

T = trusted party
C = customer
M = merchant

Setup
C sends 1 BTC to pay if signed by T & C

Single Spend
C goes to M and spends T&C coin
M accepts transaction since M trusts T
M sends transactions to T for the 2nd signature

T signs and broadcasts transaction (tx sends money to M and fee to T)

Double Spend
C goes to M1 and spends T&C coin
M1 accepts transaction since M trusts T

C goes to M2 and spends T&C coin
M2 accepts transaction since M trusts T

M1 sends transactions to T for the 2nd signature
M2 sends transactions to T for the 2nd signature

T detects double spend and says he can't sign either transaction

T, M1 and/or M2 calls law enforcement
M1 sends 50% of the tx value to M2.
After M1's transaction is 10 deep on the chain, T signs M1's version of the transaction

-----------

This way the double spender can't get his money back. Both merchants get 50% of their money refunded and law enforcement can be contacted.

If T has an always-on server, both M1 and M2 could submit their transactions for signature immediately. The first one would be accepted, but when M2 sends his version, the T will refuse.

The fee could be included in the original transaction to sign.