 |
February 05, 2012, 09:13:32 AM |
|
I've been thinking about 0-confirmation txs and how accepting them can be made safer. I'm of the opinion that they are already safe (well safer than competing options) for most applications. If you are buying something from a bricks-and-mortar retailer and attempting a double spend shortly after leaving the paypoint, there is a real chance that you can still be apprehended. The longer you wait before sending the second tx, the smaller the chance of being caught gets, but the chance of a successful double spend also shrinks very rapidly. In addition, CCTV footage of the paypoint means that you can still be identified and blacklisted, even if your double spend attempt failed.
However, there are applications where a customer could attempt a double spend with essentially zero risk of negative consequences. It is these that are of real interest. One example is a bitcoin vending machine. The second tx can be sent as soon as the machine dispenses the product, and the machine cannot reasonably delay more than a few seconds after receiving the first tx. CCTV could also be trivially defeated in this case (masks, hoodies, or even just holding your hand in front of your face). The chance of a successful double spend is still low, but since the risk is almost non-existent, we can expect many double spend attempts and consequently, some successes.
My proposal hinges on the way that miners handle the case when they see multiple conflicting txs. Today, they are supposed to accept only the first tx seen, but this behaviour cannot be enforced. A profit-optimising miner would accept whichever version carries the largest tx fee and no-one would be able to prove that it wasn't following the rules. This allows for miner bribing double spend attacks, where a larger tx fee is offered in order to increase the odds of one version of a tx winning the race into a block.
Others have proposed earlier that miners should include BOTH of these txs in a special "double-spend alert" section of the block. The problem remains that we have no way of knowing which of the versions goes to the merchant and which is the back-to-self version. I'm suggesting that we can improve matters without knowing which is which. BOTH versions of the tx become invalid and the money is effectively destroyed. Therefore, the merchant doesn't get paid, but the cheating customer does not get his money back either. Importantly, both the paying output and the change
is destroyed.
So, if I am a vending machine operator, I may "safely" accept instant txs for a value of X, conditional that the input(s) used to pay me add up to at least 10 X (or some other multiplier of my choice, the more paranoid I am the higher). Then I know that the cash I accepted can still be burnt after I dispensed the product, but the customer would also burn 9 times as much of his own money in the process. This seems pretty safe to me. If I was really paranoid, I could buy insurance against events like these. The premium would be incredibly small, because there is no possibility of defrauding the insurance company. The only way to claim X would be to burn 10 X. In a rational world that never happens. In the real world, it happens very rarely and with very small amounts.
An improved variation, would be to burn only half the money and award the other half to the miner who reported the double spend attempt. This incentivises miners to mine these, while eliminating the "bribe-a-miner" attack.
Then the only way for someone to safely execute a successful double spend is to not broadcast the second tx and mine the block containing it themselves. This radically reduces the number of potential perpetrators (essentially only a pool-op has a non-negligible chance of doing this). If we wanted to close this theoretical loophole as well, we could allow a double spend report to occur, one or two blocks AFTER the first tx had allready made it into the chain). This complicates book-keeping, since the tx fee reward for the first block is now effectively less than what is stated in the block, but it is certainly possible.
I realise that it is probably too late for this to be used in bitcoin as it would require a hard fork of the blockchain. Might be useful for an alt-chain though. Or am I missing something?
|
