Double Spend Proofs: Protocol Improvements and Providing End-User Guidance

[TierNolan]

@dgenr8

Whether it is relevant that a customer just tried a double-spend, even if merchant didn’t see the tx that would have paid him, is subjective. Personally, I think it is quite relevant.

Right. I was assuming SPV nodes of some kind.

If the plan is for full nodes to handle DS proofs, then that issue goes away, since a full node will remember the DS proof. All transactions in the memory pool could have a bit mask to indicate which inputs have DS proofs outstanding for them. If a valid DS proof is received for an input the bit is set and the DS proof is forwarded to peers only if the bit was zero before.

If the node wants to be able to send the DS proofs to SPV nodes, then it has to remember at least 1 DS proof for any UTXO that has a DS proof. This reduces the number of transactions that can be stored in the mempool.

An SPV node connected to the full node could ask for DS proofs related to a transaction or input.

Other SPV-like protocols would need to have supported added to support DS proofs.

@groot-verde

But why wouldn’t dishonest nodes just send you as many fake double-spend proofs as they can get away with? Maybe they’d have to be more targeted, or separate their efforts across more nodes, but they would likely still be effective at harassing others.

You can only send 1 DS per UTXO and you have to control that UTXO.

Another spam control would be to require that at least 1 of the two spends is actually linked to a real transaction. This would mean that spamming double spends would inherently require paying at least some fees, since one of the two transactions would be included in the blockchain. Given low fees, this is less of a deterrent.