Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cancel the best block when a duplicate stake is received #75

Merged
merged 1 commit into from Oct 18, 2014

Conversation

sigmike
Copy link
Member

@sigmike sigmike commented Oct 5, 2014

No description provided.

sigmike added a commit that referenced this pull request Oct 18, 2014
Cancel the best block when a duplicate stake is received
@sigmike sigmike merged commit 6658331 into peercoin:develop Oct 18, 2014
@dooglus
Copy link

dooglus commented Aug 10, 2015

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
Copy link
Member Author

sigmike commented Aug 10, 2015

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
Copy link

dooglus commented Aug 10, 2015

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
Copy link
Member Author

sigmike commented Aug 10, 2015

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants