Advanced Checkpointing - New Feature
-
[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.
-
[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 share this concern. Firstly I want to get this checkpointing in so we can protect against malicious users trying to control the network.
I have some ideas going forward to remove the centralisation of this solution. The majority of miners are on pools, we could ask these pools to contribute to the checkpoint feed. Checkpoints would not be published unless we had agreement between the majority. This would not work so well for adhoc checkpointing but should work for the continuos feed. The consensus between pools would stop anyone individual from controlling the checkpoints and prevent attackers from replacing the chain.
I think that this would be a sensible approach to distribution of our checkpointing solution.
-
We can delegate authority on checkpointing to the largest pools. Each pool can have a pair of keys (public/private) to sign feeds. They may also exchange information between themselves on consensus before distributing it to miners and users. A protocol needs to be defined first though. Anyway, I’d like to look at the code when it’s ready.
-
[quote name=“ghostlander” post=“15668” timestamp=“1371388489”]
We can delegate authority on checkpointing to the largest pools. Each pool can have a pair of keys (public/private) to sign feeds. They may also exchange information between themselves on consensus before distributing it to miners and users. A protocol needs to be defined first though. Anyway, I’d like to look at the code when it’s ready.
[/quote]Right, so it’s still decentralized overall with some centralized decisions within each larger pool?
-
[quote name=“justabitoftime” post=“15669” timestamp=“1371388761”]
[quote author=ghostlander link=topic=1878.msg15668#msg15668 date=1371388489]
We can delegate authority on checkpointing to the largest pools. Each pool can have a pair of keys (public/private) to sign feeds. They may also exchange information between themselves on consensus before distributing it to miners and users. A protocol needs to be defined first though. Anyway, I’d like to look at the code when it’s ready.
[/quote]Right, so it’s still decentralized overall with some centralized decisions within each larger pool?
[/quote]Let’s say large pools work together on centralised decisions. Small pools and solo miners subscribe to them. It’s like long polling.
-
[quote name=“justabitoftime” post=“15669” timestamp=“1371388761”]
Right, so it’s still decentralized overall with some centralized decisions within each larger pool?
[/quote]First iteration will be single feeds that people can subscribe to. The next iteration we can look to make sure that several miners will have to agree upon the checkpoints in the feed.
-
I’m liking the idea a LITTLE more when you started bringing in signing using PKE, but then you still have a central authority doing things like certificate issuing/revocation. Problem not solved.
-
[quote name=“Kevlar” post=“15731” timestamp=“1371410717”]
I’m liking the idea a LITTLE more when you started bringing in signing using PKE, but then you still have a central authority doing things like certificate issuing/revocation. Problem not solved.
[/quote]The central authority maintains the client & daemon. Hope you don’t mind.
-
There are already checkpoints defined in the source code of the client. This new solution allows us to continue creating checkpoints without everyone having to download a new version of the client. If we get to allow several entities to define checkpoints together then we have an improvement over the current system.
I would rather have the legitimate pools where the miners are working help define the blocks in the network than a malicious attacker with 51% of the total hashing power.
If we do not evolve against threats like this then we are not going to last. The attackers out there are savvy and they seem to be getting more powerful over time. This solution will stop attackers from orphaning blocks and therefore rolling back transactions. If we end up with 100MH again and have this solution then we do not need to worry about attacks.
