I’d like to add some notes about the new “soft checkpoints” feature that was commited yesterday. Let’s try a FAQ format.
- What is this “soft checkpoint” thing?
- What is it good for?
- So can’t we just keep using “hard” checkpoints?
- Does it mean we are immune to reversal attacks now?
- How do we fix it permanently?
- So a 51% attack is still possible?
- Is this the same as Feathercoin’s Advanced Checkpointing?
- So how is twister’s soft checkpoint decentralized?
- Unique Node List? A fixed list? Do we trust these people?
- Why can’t we let every username to vote for a checkpoint?
- You asked for volunteers to enter this user list, why?
- How is the new soft checkpoint accepted?
- Does it replace the standard block chain decision algorithm?
- Should I update my twister-core?
- I have something to say…
Checkpoint is a standard feature of original Bitcoin where a given block number (height) is associated to a certain hash. That means that the main block chain MUST include this specific block at that height since any alternative chain or branch will not be accepted. These checkpoints are hardcoded into the client’s source code, so i will refer to them as “hard” checkpoints. Hard checkpoints require users to update their clients to become effective.
The new “soft” checkpoint is not coded into the client code but is rather received from the network (from other peers).
Having more frequent checkpoints mean that we can resist reversal attacks better. The reversal attack of 01/18/2014 reverted about two days of user registrations but the attacker couldn’t go further in the past because we had a “hard” checkpoint as of 01/16/2014.
No, this is not a viable solution. Updating “hard” checkpoints takes time, it is a manual intervention by developers (therefore centralized), it requires users to recompile their clients etc.
Sorry but no, soft checkpoint is no silver bullet. However I expect it to work as a nice harm reduction mechanism: instead of being able to revert days or even months of user registrations by submitting an alternative (longer) block chain to the network, the attacker will be able to revert just 6 blocks. This is about one hour of user registrations.
This is also a very clear win for twister users. Now, instead of being always worried about the real possibility of losing their usernames at any time without further notice, they will be able to trust that their usernames are permanent if 6 blocks have passed since their registration.
That’s simple: we need more hash power. Any block chain to be secure needs people “mining” the chain, trying to generate blocks. Start generating blocks yourself and help securing twister!
Yes, but it won’t be able to revert more than 6 blocks. The powerful attacker is still able, however, to prevent any new registration to the twister network. He just needs to keep attacking twister all the time, preventing new registrations… But then, by attacking the network all the time, it will be much easier to find out who he is…
No, Feathercoin is a totally centralized solution, the checkpoints are still manually defined by their lead developer. Feathercoin developers have just created a faster delivery of centralized checkpoints to the clients. I don’t see why should we call it “advanced” by any standard.
The idea is not new, it has been proposed before in Bitcoin forum (Feb 2013) but was mostly ignored. twister is, AFAICT, the first project to implement this.
Instead of relying on a single developer to decide what the checkpoint is, the twister’s soft checkpoint is automatically obtained by consensus, following Ripple’s consensus model. Users are suggested to read these links if they want to learn more about the concept.
No, the nice thing about this consensus model is that we don’t need to trust these people individually. Some of them might even be trying to attack the network in some way, but the premise is that they will not collude to undermine twister security. It is their interest (at least for the majority of them) that twister user registration is trustful.
The username is not necessarily tied to different individuals. One would be able to generate arbitrary usernames and then fake the votes. It would only make the attack easier.
Because their usernames will be publicly available. To this end, I have also suggested using a different username than the one they use to post messages. We just need to twisterd running with that given username’s private key in the wallet, preferably running 24×7. The daemon detects the username and does the rest (signing block hashes to cast votes).
A new soft checkpoint is accepted whenever we have verified the signatures for votes of 51% of the Unique Node List. So it is important these people to have their nodes running most of the time, otherwise some votes will be missing.
No, proof-of-work based block chain is the same. We just want to persist an existing consensus among the nodes of the network about the recent past of the block chain. We do still allow branching/forking as usual, but the older (deep) history of the block is not allowed to change.
There is no good reason to allow deep history rewrites of the block chain, it is just that there is no good method to algorithmically forbid this. Limiting the size of rollback is not an option as it allows the attacker to create permanent chain forks among the nodes.
Yes, please. Soft checkpoint is available since 01/19/2014 changeset 102d172. This is twisterd version >= 0.9.8.
Then post it here.
Leave a Reply