Topic: Double spend protection with replace by fee (Read 1058 times)

They could, but if 20% of miners are implementing replace by fee, then a double spend had an inherent 20% chance of working.

This system would protect against double spending, even if all miners implemented replace by fee.

And there is no scope for nodes to reject blocks containing double spends?

This is a stronger protection, since the merchant gets the money.

The service creates a transaction with 200 0.001BTC inputs and the fee is 0.002 BTC (1%).

One of the transactions is for 0.001 BTC.  If the attacker tries to double spend, the miner has 2 choices.

Accept the double spend, but this means that the large transaction cannot be accepted, since it spends the valid transaction.

At best the double spender can offer 0.001 in fees, but the 200 transaction passthrough has a fee of 0.002.  Even if the double spender gives up the benefit of double spending, he still can't pay enough to get the miner to switch.

If the miner accepts the passthrough transaction, then the double spend fails.

I thought "replace by fee" could already be hardened against double spending by the merchant dumping  the whole transaction into fees if a double spend is detected.

Double spenders could directly communicate with miners.  Zero confirmation transactions are inherently unsafe. 

Basing the security of the system on miners acting against their self interest is not a good long term plan.

The problem with punishing miners who mine double spends is that there is no way to agree on what counts as a double spend.  An innocent miners might happen to receive the double spend first and mine it in good faith.

Why can't the core protocol refuse to relay double spends?

If a significant number of miners full replace by fee, then it makes it easier to carry out a double spend against zero confirm operations.

The attacker pays for and then immediately receives the item.  The attacker can then create a new transaction that spends the same outputs by with a higher fee and sends the money back to an address that he controls.

Miners with replace by fee will mine that new transactions instead of the original and thus the attacker gets the item and also (most of) their money back.

A double spend protection service could be offered by transaction aggregator.

The merchant would send the original transaction to the aggregator and get a YES/NO reply.  If the aggregator has already received a transaction which spends one of inputs, then it will refuse to accept the transaction.

Otherwise, it will accept the transaction and add it to its set of pending transactions.  The aggregator would charge a fee for the service.

The service creates a passthrough transaction for the pending transaction.  Each output has a matched input.

A -> A'

B -> B'

...

F -> F'

X-> X'

Fee: 1% of total value

The X transaction spends the X output of the previous transaction (value = 0).  This means that the block cannot include a passthrough transaction unless all previous are included.

When a new block is found, the chain is started again.

This has the effect of providing a fee for miners who are willing to include all the transactions in the set.  If they leave any out, then they get none of the extra fees.

If the aggregator combines 100 transactions per block and pays 1% fees, then the cost of not using the aggregator's transaction is about the same as the total value of one transaction.

Even if the attacker sends 100% of the transaction to fees, he only matches the "bid" of the aggregator's transaction.

As more people use the aggregator's system, it is even harder for a double spender.

If multiple aggregators exist, they could work together.  By reference each others transactions, they increase the effective number of transactions in the combined transactions.

This has the nice feature of eliminating the need for making contracts with individual pools.  All miners would see the aggregation transactions and could include them.

This may need child-pays-for-parent depending on exactly what full replace by fee actually does.

On the negative side, it means transaction space being used up.  It is only needed for transactions that are zero-confirm.