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?