Topic: Preventing double-spending attacks with semi-trusted 3rd parties (Read 1316 times)

Right, I said something similar about  Jon Waller's Green Addresses proposal https://bitcointalksearch.org/topic/idea-distributed-anonymous-green-addresses-169558 ) but if you're effectively having to lock some of your money up with the agent (and anticipate the amount you need with them 6 blocks in advance), you're probably better just making a single deposit that acts as a bond against double-spending, leaving that money there, then sending a separate payment for the stuff you're buying direct to the merchant. The agent would keep track of how much unconfirmed money you've got "in-flight" at any given time and communicate to the merchant that you'd posted enough of a bond to cover it. That way you could make payments up to the value of your bond, then once they'd confirmed you'd be able to do the same with your next payment without needing to top up the money you'd got locked up with the agent.

Obviously the downside of doing it this way is that to make a payment of 1 BTC you need to have 2 BTC to your name (1 BTC locked up with the agent as a bond and the other 1 BTC for the actual payment) but that's probably OK here as I'd assume it's mainly for small, quick payments. In the few cases where people are spending their entire life savings they probably don't mind waiting an hour.

Keep in mind that it doesn't cost them much money. They would just have to run a server that checks and signs some transactions, so we don't need a large incentive. For instance, a merchant or exchange operator could offer this service for free because it protects themselves from double-spends. Given that double-spends have already happened on the network, this should be a significant incentive.

Alternatively, auditors could also charge for their service. Fees wouldn't have to be high. Given that the auditor is only doing very little work, fees would be no more than ~ €0.10 per commenced 1000 tx. This fee would be payed in advance because including a seperate output for that purpose in each tx would be too expensive.

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.

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.
That depends on the number of trusted parties. And it wouldn't need to be that big in most situations. Furthermore some auditors pools may emerge, so the fee would have one output.
That is why we need a change in the protocol suggested by falschgeld .

The problems with this approach (if i understand correctly)
1. You still have to send bitcoins to this "M of N" address and so you still have to wait while this transaction get 6 confirmations.
2. What is incentive for the trusted auditors? You could send fees as an output in transaction, and if they see that tx includes fee they provide a signature, but tx would be huge, compared to standard tx
3. What to do in case of auditor closing its service, well, there is small chance that all auditors shutdown their services at once, but if you send bitcoins to this address and then want to use it after 2 years you may, to your surprise,  find that these auditors don't exists anymore.

However this is still much better than trusting to the one green address provider.

 I don't really like the term "semi-trusted 3rd party". Does someone have a suggestion for a synonym?
Independent auditors ?

I think you misread what I wrote. I suggested that my funds would sit a special address from which they could only be spent with signatures from all (or at least the majority) of my "semi-trusted 3rd parties". If one of the "semi-trusted 3rd parties" refused to sign my transaction, every node in the network would reject it. No hashing power needed.

This feature would already be feasible today without changing the existing protocol. However, it puts the user at the risk to lose their coins if one of the "semi-trusted 3rd parties" just refuses their signature, disappears or has trouble with their internet connection. Keep in mind that any of my ST3P can block my transactions, so the chance that my coins get frozen because of a dead ST3P is higher than the chance that a particular e-wallet service disappears. In order to mitigate this risk, we would need the option to perform an exit transaction and that would require a change to the protocol.

Btw, I don't really like the term "semi-trusted 3rd party". Does someone have a suggestion for a synonym?

Your semi trusted parties would need to posses large majority of hashrate in order to limit double spend success. Since even if they will block it, other would not necessary do that. Still they can rebroadcast the double spend to the original receiver, so he would know that double spend attack took place before the 1st confirmation.
[Edit]
Yes, you are right. I think it's nice idea.

I think I got yet another idea how double-spending attacks can be discouraged. Previous ideas included green addresses and pre-paid accounts. Both of these approaches have drawbacks because they require the user to trust either the beneficiary or the 3rd party and funds still need to be sent to some kind of pre-paid account or e-wallet service at least 6 blocks in advance. And you always have to know whom you want to send money to during the next 6 blocks because each beneficiary can come up with different requirements - some want a Mt. Gox green address, another may have their own prepaid system. In addition to that, you always need to trust the guy who has your money.

Now I think I got an idea: The bitcoin protocol already allows for funds to be owned by several keys (for 2-out-of-3 agreements and similar stuff). This would allow us to mark an output as "can only be spent if A, B, C, D, E and F agree". In this case, A would be the owner of the output and B, C, D, E and F would be semi-trusted third parties. Now if I wanted to spend my output, I would first sign the transaction and then, I would go to B, C, D, E and F. They would check whether I have signed the transaction and then, they would check whether I'm trying to perform a double-spending attack (they would just have to check whether they have already signed a conflicting transaction). If there's no problem, I'd get my 5 signatures and could start broadcasting my transaction. The beneficiary can now see that I could only conduct a double-spending attack with approval from B, C, D, E and F; He just needs to trust one of these 5 3rd parties. If it turns out that some merchants out there don't trust any of my 3rd parties but instead only trust in G or H, I could add those to my list of semi-trusted parties as well.

Now there's just one small issue - what happens if one of the semi-trusted 3rd parties refuses to approve my transactions, for any non-legitimate reason? Then I'll be unable to access my funds. In fact, nobody can access them. In order to solve this, we would need a feature that I would call an "exit transaction". An exit transaction is a way to remove the above restrictions from an output. However, this kind of feature obviously needs some kind of protection against abuse, and I got a simple idea how we could implement such a protection: We just need to require that A (the owner of the funds) announces their intent to perform an exit transaction some time (let's say ~100 blocks) in advance. This announcement would have to be made in the form of a special transaction that would be put into the blockchain. Now, A (the owner of the output) would have to wait 100 blocks. After these 100 blocks he would be allowed to perform his exit transaction without approval from his semi-trusted 3rd parties. However, during these 100 blocks, regular transactions would still be allowed to clear as usual, so a regularly signed transaction would still be allowed to clear. Obviously, merchants should refrain from trusting any transaction involving the output in question after an exit transaction was announced. However, if an announcement transaction is broadcasted just after they received a payment and the customer is already gone, they don't have to fear anything because the legitimate transaction would have plenty of time to clear before the bad exit transaction would be allowed to go into the blockchain.



I'm a bit worried that this approach might cause transactions to grow significantly in size; But apart from that, what do you think? Would this approach work?