Advanced Checkpointing - New Feature
-
[b]Intro[/b]
The recent attacks have made us look around for ways to protect ourselves when the hash power is low. There may be longterm solutions, but we need something to protect us now.Checkpoints allow us to define in the client, blocks from our blockchain, that the client will look for. The client will reject any chain that does not have the blocks specified. There is more information on checkpoints on the page below.
https://en.bitcoin.it/wiki/Checkpoint_Lockin
Currently checkpoints need to be coded into the client which then needs to be redistributed. This system is far to slow to be able to protect us when we are under attack. What Advanced Checkpointing will allow us to do is define checkpoints without having to redistribute the client.
[b]How it works[/b]
The system works by allowing clients to subscribe to checkpoints that we issue. Subscribed clients will then only accept chains with the checkpoints we define. The idea is that we would ask the pools to subscribe so that the majority is protected. Local clients can choose whether to subscribe or not. After attacks have finished we can remove the checkpoints from the system and continue as normal.[b]In practice[/b]
This would have been extremely useful in the last attack we found ourselves under. We could clearly see the genuine blocks which got orphaned seven or more blocks a time. They were using a continuos chain to try and make the next difficulty start from a day earlier. With Advanced Checkpointing we would have checkpointed a genuine block moving the attacker away from on our chain who would end up with his own fork, separate from the subscribed network. When the attacker stop the attackers chain will die and all the clients will pick up the protected chain. -
This would be great.
Can this be implemented soon, or is there a lot of testing to be done?
-
how are checkpoints defined and distributed?
Doesnt this imply some sort of centralization?
-
[quote name=“Smoothie” post=“15233” timestamp=“1371292612”]
Doesnt this imply some sort of centralization?
[/quote]The flip side is that the attackers are running their own form of centralisation with 51% hashing power. We can already define checkpoints in our source code, this system first came from Bitcoin when faced with these problems. Bitcoin no longer has to worry about such things but we are looking to progress the system further.
The attacks we suffered were unprecedented and it shows that there is a need for coins with less hash rate to protect themselves.
About centralisation, anyone should be able to define their own feed to subscribe to :)
In the long run I hope that we can forget about this system like Bitcoin has forgotten about checkpoints.
-
Sounds like the way to go, so if i understand this properly attackers can still attempt 51% and orphan blocks, they just can not profit from it or create a new block chain?
-
[quote name=“Bushstar” post=“15236” timestamp=“1371293427”]
[quote author=Smoothie link=topic=1878.msg15233#msg15233 date=1371292612]
Doesnt this imply some sort of centralization?
[/quote]The flip side is that the attackers are running their own form of centralisation with 51% hashing power. We can already define checkpoints in our source code, this system first came from Bitcoin when faced with these problems. Bitcoin no longer has to worry about such things but we are looking to progress the system further.
The attacks we suffered were unprecedented and it shows that there is a need for coins with less hash rate to protect themselves.
About centralisation, anyone should be able to define their own feed to subscribe to :)
In the long run I hope that we can forget about this system like Bitcoin has forgotten about checkpoints.
[/quote]+1
This sounds like a more feasible solution rather than changing the hash algorithm altogether.
Although having a different alg would have its Pros , the change would have its cons too.
Right now I am curious to see if the hash rate from miners starts to stick around mining FTC on a higher average than usual.
-
This is defeating the distribution, reminds me of tainting.
I would do this instead:
Make it so every certain number of blocks hashing has to be devoted to checkpoint prehashing (index blocks). If the blocks do not enter the index block, they are postponed to the next index block. What’s interesting is that now the attacker has to split their hashing to both the blockchain and the index blocks. If they try to fake the index block they risk losing their grip on the fork, but if they don’t hash the index blocks then the index blocks get rejected.If index blocks disagree by more than 25% they are rejected. If the blockchain disagrees with the index blocks by more than 75% the chain segment is rejected.
This also gives us the index block hashing algorithm:
Create a random chain segment and index block matching sequence. Make the reward 400 FTC, separate difficulty, retarget rate, block rate, and recheck rate. The incentive will be there to make it difficult for an attacker to get a foot in.Remember, the genius behind bitcoin is that we’re all a bunch of transaction announcers (lolthiefs) forced by probability and maybe a little moral substance to work together. So the way to solve problems like these is to accept the fact that fraud exists and use that fraud effort to secure the chain.
Also if it seems like we are developing cryptocoin immune system, that’s because we are. I want to highlight this one issue: we have purists in the cryptocoin universe. The numbers guys reject structure beyond the transaction and naturally fall victim to all or nothing dynamics. The philosophy guys reject numbers and overdesign resulting in code no one can use.
We have to be better than both.
-
This naturally leads to that other thing I have to send to Bush.
Also… we could have empty index blocks at the beginning of a series of blocks and full blocks at the end. And then the goal would be for all clients to agree on the transition from one to the other.
I’m going back to the code. I’m having too much fun here. :)
-
[quote name=“zerodrama” post=“15245” timestamp=“1371295035”]
This naturally leads to that other thing I have to send to Bush.Also… we could have empty index blocks at the beginning of a series of blocks and full blocks at the end. And then the goal would be for all clients to agree on the transition from one to the other.
I’m going back to the code. I’m having too much fun here. :)
[/quote]I don’t understand this comment. Would this prevent the blockchain from growing too big years down the road?
-
Zerodrama is talking about a more radical solution to dealing with attackers. This is something that will go into our test coin for some basic research. Hopefully this will yield some solutions that are desperately sort after.
In the mean time we can progress with our more conventional extension of the Bitcoin checkpointing system. This may be something that Bitcoin may actually need in the future. It is hard to know what challenges Bitcoin may face, especially if it loses a lot of value as well as its dominant position.
-
[b]Bushstar[/b], that’s the concept of continuous checkpointing. PPC claims to use it until the network becomes strong enough to resist 51% attacks. That’s fine except the currency is decentralised no more, and checkpoint distribution has to be well organised and resistant to DDoS attacks. Are we going to borrow the implementation from PPC or develop something better ourselves?
-
[quote name=“ghostlander” post=“15298” timestamp=“1371305556”]
[b]Bushstar[/b], that’s the concept of continuous checkpointing. PPC claims to use it until the network becomes strong enough to resist 51% attacks. That’s fine except the currency is decentralised no more, and checkpoint distribution has to be well organised and resistant to DDoS attacks. Are we going to borrow the implementation from PPC or develop something better ourselves?
[/quote]This is not PPCoin’s system but is based on PPCoin’s system. The client needs to run a command to subscribe to our checkpoints and can also unsubscribe. Also the checkpoints themselves can automatically generate or we can define them manually. I suggest that we only use this system when we are vulnerable with a low hashrate or we find ourselves under attack like the last attacks we suffered.
-
[quote name=“Bushstar” post=“15226” timestamp=“1371291854”]
[b]Intro[/b]
The recent attacks have made us look around for ways to protect ourselves when the hash power is low. There may be longterm solutions, but we need something to protect us now. There is an Advanced Checkpointing system that Sunny King has developed. If you do not know, Sunny King is the chap who first implemented Proof-of-Stake in PPCoin.Checkpoints allow us to define in the client, blocks from our blockchain, that the client will look for. The client will reject any chain that does not have the blocks specified. There is more information on checkpoints on the page below.
https://en.bitcoin.it/wiki/Checkpoint_Lockin
Currently checkpoints need to be coded into the client which then needs to be redistributed. This system is far to slow to be able to protect us when we are under attack. What Advanced Checkpointing will allow us to do is define checkpoints without having to redistribute the client.
[b]How it works[/b]
The system works by allowing clients to subscribe to checkpoints that we issue. Subscribed clients will then only accept chains with the checkpoints we define. The idea is that we would ask the pools to subscribe so that the majority is protected. Local clients can choose whether to subscribe or not. After attacks have finished we can remove the checkpoints from the system and continue as normal.[b]In practice[/b]
This would have been extremely useful in the last attack we found ourselves under. We could clearly see the genuine blocks which got orphaned seven or more blocks a time. They were using a continuos chain to try and make the next difficulty start from a day earlier. With Advanced Checkpointing we would have checkpointed a genuine block moving the attacker away from on our chain who would end up with his own fork, separate from the subscribed network. When the attacker stop the attackers chain will die and all the clients will pick up the protected chain.
[/quote]Dam i had this idea - and i contacted Balthazar about implementing it for nibble - if you guys implement that would rock ! : D -
-
Who is going to set these checkpoints(time & which chain is valid if there is already a second one)
, and who is distributing them?nice regards
hynodeva.com dev
btw. i would help implement such system, if more details how to do that in our case are given to me.
i would like to help FTC to get out of this pretty dangerous situation… since the only thing holding the attacker back right now is the high netspeed, which might change once price drops again,
-
I believe this is fitting:
https://forum.feathercoin.com/index.php?topic=1845.0
If you’re interested in helping out with any aspect of Feathercoin (dev to artist to merchant services), please make sure you fill out the survey. I use the survey information to help organize teams as well as give Bushstar immediate resources when he requests it.
==
Ok, back to Advanced Checkpointing
-
[quote name=“hynodeva” post=“15326” timestamp=“1371310953”]
Who is going to set these checkpoints(time & which chain is valid if there is already a second one)
, and who is distributing them?nice regards
hynodeva.com dev
btw. i would help implement such system, if more details how to do that in our case are given to me.
i would like to help FTC to get out of this pretty dangerous situation… since the only thing holding the attacker back right now is the high netspeed, which might change once price drops again,
[/quote]pm me if you need help coding… no time for any surveys…
-
[quote name=“hynodeva” post=“15335” timestamp=“1371312531”]
[quote author=hynodeva link=topic=1878.msg15326#msg15326 date=1371310953]
Who is going to set these checkpoints(time & which chain is valid if there is already a second one)
, and who is distributing them?nice regards
hynodeva.com dev
btw. i would help implement such system, if more details how to do that in our case are given to me.
i would like to help FTC to get out of this pretty dangerous situation… since the only thing holding the attacker back right now is the high netspeed, which might change once price drops again,
[/quote]pm me if you need help coding… no time for any surveys…
[/quote]That’s fine. It takes all of 3 minutes and helps allocate resources correctly. With 1500+ members, it’s becoming more of a challenge to organize.
Bushstar: Please drop hyno a PM when you have a chance
-
I’m VERY wary of this solution because it threatens to un-decentralize the currency.
Whoever controls the checkpoint subscriptions… need I say more?
-
[quote name=“Kevlar” post=“15565” timestamp=“1371358564”]
I’m VERY wary of this solution because it threatens to un-decentralize the currency.Whoever controls the checkpoint subscriptions… need I say more?
[/quote]I’m probably on the other side of the spectrum. I believe in compromises concerning straight decentralization, I realize others do not.
-
[quote name=“justabitoftime” post=“15573” timestamp=“1371360215”]
[quote author=Kevlar link=topic=1878.msg15565#msg15565 date=1371358564]
I’m VERY wary of this solution because it threatens to un-decentralize the currency.Whoever controls the checkpoint subscriptions… need I say more?
[/quote]I’m probably on the other side of the spectrum. I believe in compromises concerning straight decentralization, I realize others do not.
[/quote]If you haven’t got dynamic decentralization (a tendency to spread out), you’ll get run over anyway.
Best option: get in the code and make things happen right.
