Fix for reviseing history


#1

In a thread (http://www.peercointalk.org/index.php?topic=2976.msg27609#msg27609) there is an attack described that this technically possible.

The basic idea is that the attacker use private addresses that once held lots of coins and coin age. Actually so much that the attacker using a customized version of a Peernode, could build a new blockchain history and broadcast this attack chain to the network.

The duplicate block check mechanism would not protect against this attack, since the private key that held the coins was not used for minting. The assumption is also that the attacker can gather enough private keys to make the attack possible, spending only very little resources on doing so.

Although I can only come up with pretty unlikely scenarios, the attack vector is interesting enough for other people to comment on (so I created this thread). learnmore writes:


#2

I recall reading somewhere that the network selects the blockchain that has the most coin age destroyed. If this is true, it means that it isn’t enough for the attacker to build a long attack chain , it has to have more coin age destroyed.

I was thinking that perhaps it could be possible to protect against a massive, long/deep re-writing of blockchain history, by simply putting a limit on how deep a replacement can go. For instance, we know how often new blocks are created, thus we could create a limit that says something down the line of: “When a new chain is detected, that is longer then thirty days (or a week, a day), it should not be propagated by the network”.

It would be kind of a checkpoint, that isn’t static but more of a sliding window.

The purpose it would serve, would be to protect against someone accumulating private keys that held huge amounts of coins a “long time ago”. That would force the attacker to get private keys that are less then thirty days old, yet have enough coin age to rewrite all the history required. It makes the attack even more unlikely (because it requires enough people willing having sold enough coins to even make the attack remotely possible, and the attacker being able to gather these keys).


#3

The spent index is already there.
The check is already there.
There is no special treatment of coinstake.

How it works during attack and if existence of such index help attacker to split the blockchain is above me currently.


#4

Public Service Announcement

If you have access to an address that at any point in the past has contained 100,000 PPC or more at one time (and has since been zeroed out), please send me a PM. I’d like to purchase your private keys.


#5

While it would prevent simple double spent it would also introduce devastating giant forks to whole picture.


#6

[quote=“Ben, post:4, topic:2547”]Public Service Announcement

If you have access to an address that at any point in the past has contained 100,000 PPC or more at one time (and has since been zeroed out), please send me a PM. I’d like to purchase your private keys.[/quote]

Four guys contacted to you, ABCD, w/ their past stakes.

A i___|____o
B ___i___o
C ______i___|__o
D ________i___|__o

i: stake ~enters key
o: stake ~leaves key
|: stake was eligible for minting

You have to choose start point. Let’s take Ai. Key question: can you move Bi,Ci,Di to the past by creation with Ai A| of hidden fork with future transactions with other stakes’ entry points?
When you create a fork you can exclude o points. But how chaintrust will be build?


#7

Ah, perhaps this attack vector is so unlikely that we might even call it a myth then? That would be great, because then I can chalk it up in the “myth buster” thread.

I need some kind of explanation of how unlikely this is, that is so simple that a layman can easily comprehend that even if the attack is technically possible its of no concern in reality.

Jordan Lee did an excellent walk through of the “Nothing at Stake”. Is it possible to do something like it for this “myth”?


#8

I cannot find anything in the code preventing Ci,Di move to the past.
I’d like to hear core-devs here.
Now we have

A i___|____
B ___i___|_
C ____i___|
D ____i___|

#9

I have the vague memory that recently (after the last interview to Sunny) that someone asked question about this attack and both Sunny and Sigmike said it wasn’t possible with Peercoin, without explanation.

edit: wrong information. see below.


#10

[quote=“Ben, post:4, topic:2547”]Public Service Announcement

If you have access to an address that at any point in the past has contained 100,000 PPC or more at one time (and has since been zeroed out), please send me a PM. I’d like to purchase your private keys.[/quote]

How do you know the seller doesn’t keep a copy after selling it to you?


#11

If so, I missed something.


#12

[quote=“mhps, post:10, topic:2547”][quote=“Ben, post:4, topic:2547”]Public Service Announcement

If you have access to an address that at any point in the past has contained 100,000 PPC or more at one time (and has since been zeroed out), please send me a PM. I’d like to purchase your private keys.[/quote]

How do you know the seller doesn’t keep a copy after selling it to you?[/quote]

I’ll just have to deal with that scenario at some point in future if it arises.


#13

I really hope that he or sigmike could weight in on this topic, before I add any more information to the “myth thread”. My plan is to push that one thread hard to on social forums, so its important that it is accurate.


#14

[quote=“Ben, post:12, topic:2547”][quote=“mhps, post:10, topic:2547”][quote=“Ben, post:4, topic:2547”]Public Service Announcement

If you have access to an address that at any point in the past has contained 100,000 PPC or more at one time (and has since been zeroed out), please send me a PM. I’d like to purchase your private keys.[/quote]

How do you know the seller doesn’t keep a copy after selling it to you?[/quote]

I’ll just have to deal with that scenario at some point in future if it arises.[/quote]

If you want to experiment you can make such addresses on the testnet. It takes 80 blocks instead of 520 to confirm new coins and stakes that find blocks can be spent after 1 day instead of 30 days.


#15

I really hope that he or sigmike could weight in on this topic, …[/quote]

I will try to find that post.

edit: I find the post. As it turns out it wasn’t about revising history attack. Sorry to have added misinformation :frowning:


#16

I’m going to set up a local fork and try it there. I’l report back any findings (but it may be a while, because while this is important, it’s “important item #324” on my list of things that need to be done).


#17

Rewriting a blockchain from a point where you had the majority of the minting coins is possible but there are a few things that protect us:

  1. The hard checkpoints in the source code. The last one is from 0.4 release so the new blockchain cannot start before block 99999 generated on 2014-03-06. So the attacker cannot use coins that were spent before this date.

  2. The synchronized checkpoints. The last one is from 1 hour ago. They will be removed, but I guess only when the last protection is strong enough:

  3. The stakes that have been minting since the attacker wants to start the rewrite. For example if the coins the attacker had in the past have been constantly used for minting since they were sold then he won’t be able to compete with the main chain. And in general the more coins are minting the more difficult it is to rewrite the blockchain. Imagine we get an average of 60% of the coins minting since the last checkpoint, then the attacker needs outputs that had 61% of the coins.


#18

Thank you sigmike.
I’d appreciate a word on past stakes ‘alignment’, post http://www.peercointalk.org/index.php?topic=3005.msg27655#msg27655 and next one.


#19

[quote=“kac-, post:6, topic:2547”]Four guys contacted to you, ABCD, w/ their past stakes.

A i___|____o
B ___i___o
C ______i___|__o
D ________i___|__o

i: stake ~enters key
o: stake ~leaves key
|: stake was eligible for minting

You have to choose start point. Let’s take Ai. Key question: can you move Bi,Ci,Di to the past by creation with Ai A| of hidden fork with future transactions with other stakes’ entry points?[/quote]

You cannot move transactions in the past because:

  1. you cannot change the date of the transaction (you need the previous private key to do that)
  2. a block cannot include transactions whose date is in the future (https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1881-L1883)

Chaintrust is built from the difficulty. So I think you can evaluate your ability to rewrite a chain by comparing the average amount of coins involved in minting during the period. If your average amount of coins is bigger than the average amount of coins minting on the main chain, you can overwrite it.
It’s not absolutely accurate because the coin age should be taken into account, but over a long period I think it doesn’t really matter. And over a short period there’s a lot of randomness involved that makes the attack far less guaranteed to succeed.


#20

[quote=“sigmike, post:19, topic:2547”]…
2. a block cannot include transactions whose date is in the future (https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1881-L1883)
…[/quote]
That is what I was looking for, I didn’t find it and was little worried, ty.

IMO: myth totally busted