Cancel the best block when a duplicate stake is received

[sigmike]

No description provided.

[dooglus]

Does this make it easier to double-spend?

Here's the attack:

• I pay you for something
• I stake my transaction into a block
• You see the confirmation, and send me the goods
• I stake my transaction into another block at the same height - I am guaranteed to be able to do this with no extra work
• This code change cancels the block I staked, leaving my transaction unconfirmed
• I send the same coin to myself and try to stake that transaction into a block
• It's now a simple race to see whether my original transaction gets staked before my replacement one. You thought you had 1 confirmation on my payment to you, but I was able to "undo" that confirmation

Is there a problem with that attack? I think it would work (assuming you accept a single confirmation, of course).

[dooglus]

Does this make it easier to double-spend?

Here's the attack:

• I pay you for something
• I stake my transaction into a block
• You see the confirmation, and send me the goods
• I stake my transaction into another block at the same height - I am guaranteed to be able to do this with no extra work
• This code change cancels the block I staked, leaving my transaction unconfirmed
• I send the same coin to myself and try to stake that transaction into a block
• It's now a simple race to see whether my original transaction gets staked before my replacement one. You thought you had 1 confirmation on my payment to you, but I was able to "undo" that confirmation

Is there a problem with that attack? I think it would work (assuming you accept a single confirmation, of course).

[sigmike]

I guess in step 4 you actually don't stake your transaction into the duplicate block. Otherwise there's no way you could send the coins to yourself in the next block.

The behavior of the nodes when they cancel a block is to put all its transactions into the memory pool. So when they see the transaction sending the same coins to yourself they will just reject it. The next node that will find a block will include the same transactions.

If you're the one who finds the next block then you can do it. But with 2 consecutive blocks you can already double spend a single confirmation transaction even without this change.

[sigmike]

I guess in step 4 you actually don't stake your transaction into the duplicate block. Otherwise there's no way you could send the coins to yourself in the next block.

The behavior of the nodes when they cancel a block is to put all its transactions into the memory pool. So when they see the transaction sending the same coins to yourself they will just reject it. The next node that will find a block will include the same transactions.

If you're the one who finds the next block then you can do it. But with 2 consecutive blocks you can already double spend a single confirmation transaction even without this change.

[dooglus]

Maybe I misunderstand this pull request, but I was thinking that the duplicate stake in step 4 has the effect of cancelling both itself and its twin block. That leaves the coin unspent (on the blockchain, obviously it's still spent in my original transaction) and free for me to double-spend it if I can stake the next block.

Re. your last paragraph, currently to successfully double-spend a 1-confirmation transaction by finding 2 consecutive blocks, I need to be attempting to stake on top of the last-but-one block. This is likely to result in a loss of income for me, since unless I have a large percentage of the staking weight I'm unlikely to succeed in finding the required 2 blocks. It seems to me that this change makes it easier to double-spend confirmed transactions.

[dooglus]

Maybe I misunderstand this pull request, but I was thinking that the duplicate stake in step 4 has the effect of cancelling both itself and its twin block. That leaves the coin unspent (on the blockchain, obviously it's still spent in my original transaction) and free for me to double-spend it if I can stake the next block.

Re. your last paragraph, currently to successfully double-spend a 1-confirmation transaction by finding 2 consecutive blocks, I need to be attempting to stake on top of the last-but-one block. This is likely to result in a loss of income for me, since unless I have a large percentage of the staking weight I'm unlikely to succeed in finding the required 2 blocks. It seems to me that this change makes it easier to double-spend confirmed transactions.

[sigmike]

Maybe I misunderstand this pull request, but I was thinking that the duplicate stake in step 4 has the effect of cancelling both itself and its twin block.

You're right. The content of the block in step 4 doesn't matter.

currently to successfully double-spend a 1-confirmation transaction by finding 2 consecutive blocks, I need to be attempting to stake on top of the last-but-one block. This is likely to result in a loss of income for me,

What loss of income? The reward of the first block? It would only be delayed.

since unless I have a large percentage of the staking weight I'm unlikely to succeed in finding the required 2 blocks

In both scenarios you need 2 very close valid kernels (in the first scenario you create 3 blocks but you only use 2 kernels).

[sigmike]

Maybe I misunderstand this pull request, but I was thinking that the duplicate stake in step 4 has the effect of cancelling both itself and its twin block.

You're right. The content of the block in step 4 doesn't matter.

currently to successfully double-spend a 1-confirmation transaction by finding 2 consecutive blocks, I need to be attempting to stake on top of the last-but-one block. This is likely to result in a loss of income for me,

What loss of income? The reward of the first block? It would only be delayed.

since unless I have a large percentage of the staking weight I'm unlikely to succeed in finding the required 2 blocks

In both scenarios you need 2 very close valid kernels (in the first scenario you create 3 blocks but you only use 2 kernels).