Double funded outputs for protecting against double spends

Technical
#1

One of the potential issues with hardening zero-confirmation transactions is a hostile mining pool that doesn’t broadcast double spends. This makes double spend proofs ineffective.

An attacker sends his double spending transaction only to the hostile mining pool. Only the hostile mining pool knows about the double spend, so no double spend proofs are sent.

Outputs that can be spent more than once could be used to close this remaining loophole. It would be a hard fork, though maybe there is some soft fork way to get it to work.

The concept would be outputs that can be spent more than once. A user would need to fund the output double the normal amount, but then could spend it twice. Both spending transactions must be different, so the merchant can’t try to use the same transaction twice. In addition, the output could only be spent once per block.

A merchant could demand that they will only accept payments that are sourced from a double funded output.

The customer pays the merchant, and the merchant broadcasts the transaction. The customer sends two double spends to a hostile miner.

Assuming that 95% of the miners enforce the first seen rule, then the merchant has a 95% chance of getting their payment.

However, if the hostile miners win, the double spender the double spender might still not win.

Since the output can be spent twice, the merchant’s transaction is still a valid spend for the next block. The 95% of honest miners will have the transaction in their memory pool, so will be first seen for the next block.

This gives the merchant a second chance of winning the race. If the hostile miner wins again, then the merchant would lose the money.

The effect is that if 5% of the miners supported double spending, then instead of a 5% chance of success, the double spend only has a 0.25% chance of winning.

It is extendable, miners could ask for triple spendable outputs (assuming the protocol supported it) in order to reduce to odds to 0.0125% chance, though that is probably overkill.

Even if it is not used, having this system as an option reduces the incentive to setup a double spend supporting mining pool in the first place.

2 Likes
#2

Sounds quite complicated IMO.

1 Like
#3

It does sound complicated. And the fact its required suggests dsproofs are an incomplete solution.
My gut feeling is that it’s best not to fix a patch with a band-aid.

#4

I think it could potentially be simplified. I just wanted to go with the easiest to explain example. It may even be possible with some kind of soft fork. I didn’t spend much time searching for a method.

It could be made easy for users to use. The address format could include a flag that indicates that it requires a double address. Wallets would have to make sure they use those types of output in those cases.

As long as mining pools have a policy that spendable transactions remain in the memory pool when a new block arrives, then there is no specific code required to follow the first seen rule for those transactions.

I don’t think it is required for double spend proofs to be useful. The current double spend proposal covers lots of (most) threats. It just assumes that mining pools wouldn’t support hidden double spending (since it harms the owners of the mining hardware).

This is an add-on that helps mitigate that situation. It also creates a disincentive for creating a double spending mining pool.