Advanced Checkpointing - New Feature
-
[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.
-
Bushstar: I completely understand.
My question to you is: Who defines when to checkpoint? Can it be automated, and decentralized? Right now the answer is “The developers”. If you’re now pushing that responsibility to pool operators, how do you get a consensus among them?
-
[quote name=“Kevlar” post=“15757” timestamp=“1371413588”]
If you’re now pushing that responsibility to pool operators, how do you get a consensus among them?
[/quote]By voting. The majority decides unless we end up implementing some advanced weighing system based upon hash rate, number of miners, etc.
-
Checkpointing can be automatic, perhaps it should be rather than than any one person setting them.
I imagine it as ghostlander suggests, the majority, at least 51%. We can discuss whether this needs any weighting.
-
If the current thinking is that it is a dedicated rogue pool which is carrying out the attacks, or at least some massive solo miners, we could allow “trusted” pools who have a lot to lose to nominate blocks they have mined as checkpoint blocks after they’ve had 6 confirmations or so. The other pools could then choose to accept the checkpoint block and create a consencus (sp?).
The nomination of checkpoints could be limited to x per day or hour or whatever to avoid excess overhead.Any technical reason why this would not be a good idea?
-
I find myself liking your idea.
We have a list of certificates, say 30 or so, and we build these into the client.
We use the script features of the blockchain to have a pool mine a checkpoint block by signing the block with it’s private key, and we include that as part of the block.
Clients can verify that the checkpoint was signed using a trusted certificate. Certificate revokations/additions can be done by releasing a new client.
It still adds a single point of failure though: The first time someone’s pool get’s hacked, the key is leaked, and the attacker can checkpoint his alt-chain.
It’s almost like we need a block chain for our block chain…
Well shit, now I’ve gone and said it. Now this is gonna keep me up all night. A crypto-currency who’s entire purpose is checkpointing another crypto-currency. Damn. That’s interesting in a ‘whoops, your peanut butter got on my chocolate’ kinda way. More thinking required on my part now.
-
In PGP we use revocation certs in a case like that, surely we can implement something similar?
It could be weighted so if a single trusted pool has received a revocation notification, it could stop a block from becoming accepted as a checkpoint by “countersigning” it with a hash of the revocation cert or something.
-
Ok. So what if minting a checkpoint block was a statistical probability, just like finding the right nonce?
What if it required you to produce a block with 2x the current difficulty? Or 10x?
In doing so, you’d have it happen naturally as a function of time, and at random yet statistically probable rates?
That means that to attack the network, he would have to not only reach 51%, but also reach 51% of diff * x, making the attack (… I’m not sure what the progression on that is. Linear I think?) that much more difficult?
Wouldn’t that work? In fact, couldn’t you just release a new client that treated all existing blocks that way as well? That way it will have already happened and we can see what multipliers would be effective and what wouldn’t?
-
[quote name=“Bushstar” post=“15743” timestamp=“1371412753”]
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.
[/quote]I’m pro checkpoint till FTC is strong enough to stand it’s legs
