Advanced Checkpointing - New Feature
-
[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
-
I’m going to finish the leathercoin changes tonight or tomorrow afternoon.
But I’d like to suggest a strategy:
Mutually exclusive choices are more effective than barriers.
Make it easy to challenge a minted checkpoint (25% threshold of disagreement), make it hard to establish a false block segment (75%).
Award the challengers.By doing so you split the attacker’s resources. If they can execute a 51% now they have to split that. If they needed 66% of the network, that would mean 2x the network.
Also the real vulnerability here is that there is no handicap on the reorganization process.
I would be that if reorgs had to be minted just as blocks do, injecting a false chain would be very difficult.
We might not even be talking about checkpoints.
-
i like the idea. but I have in mind some scenario that need to be take care of and this needs to be considered for a complete solution:
central authority for checkpoint is a single point of failure. so any distortion like DDOS can make it useless. if mandatory can even stop the chain. if not mandatory
from pool. what happen when like in some attack some pool id DDOS. the pools can make a consensus so this will be useless against the attack.
what happen in case of network fork, two legitimate chain exist and should be resolved. potentially having both checkpoints depending on the implementation. especially in case of pool issuing if 3 pool are isolated and have power to checkpoint they will.
the attacker put 5-10 blocks at a time and invalidate the existing one 1-9 so checkpoint need to be place in that 1-9 to be efficient. how can this be differentiate from a split chain. this is where the checkpoint should be useful.
writing this gives me an idea. (known registered address checkpoint, more stamping then checkpoint)
in fact the checkpoint can be as simple as known address sending coin to themself in a block they found in the chain(i think the generation lock don’t have signature, if yes this can be used instead or the generation block can be change to include the signature of the transaction this would prevent the 33000 address ). (by known address i mean pool address and possibly some big solo miner that are trust). so a chain without registered address can’t be considered valid if it invalidate a chain containing registered address. nothing prevent from adding to a regular chain by anyone. chain having registered address on both side of a fork should be considered business as usual and resolve as of now: the longest winso non registered solo miner would always lost in a fork against a pool. this don’t prevent registered address from making 51%, even facilitate it for them but they are identified so should be a single bullet gun except possibly if the pool/miner registered is compromise. in that case a second bullet can be possible for pool, but all this make lots of work for the attacker compromise a known address and 51%.
the know address registration should be similar to an SSL cert, you need to prove who you are to be registered. the open question is now how to distribute the known address list.
[list]
[*]putting it in the code is one way but don’t scale and is difficult to maintain.
[*]
500 block confirmation in a special block in that chain can be a way to publish them and make sure they are not from a compromise node. this block would need to be from a signer
[*]any other idea ?[/list]
-
I’m going to focus on creating a new block mining responsibility: reorganization.
Checkpointing is a crutch we need because we allow immediate reorganization of blocks rewitten by 51% attack.
Eh, nope. As long as that door is open, there will always be attacks.
All reorgs should require mining. This means the attacker has to sustain the payoff of the attack as well as the beginning.
Double spending will be nearly impossible. Only new blocks will be injectable easily.
-
A novel method to stop attacks, distribute the confirmations logarithmically.
I had an idea to make Feathercoin quicker / more secure. “Confirmation locality”. This would mean confirmations would decrease in value the distance (time) from the transaction with an exponential decay. This would mean the transaction is proportionally confirmed, but not fully confirmed till time > 80% network time. This means one person could not mount a 51% attack as the confirmations are distributed more widley through the network. Local confirmations have more value, the attacker cannot be local to everyone!
It would also have the added benefit local (small) payments are confirmed almost immediately with 99% validity.
