Soft checkpoints

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?
  • 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).

  • What is it good for?
  • 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.

  • So can’t we just keep using “hard” checkpoints?
  • 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.

  • Does it mean we are immune to reversal attacks now?
  • 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.

  • How do we fix it permanently?
  • 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!

  • So a 51% attack is still possible?
  • 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…

  • Is this the same as Feathercoin’s Advanced Checkpointing?
  • 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.

  • So how is twister’s soft checkpoint decentralized?
  • 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.

  • Unique Node List? A fixed list? Do we trust these people?
  • 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.

  • Why can’t we let every username to vote for a checkpoint?
  • 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.

  • You asked for volunteers to enter this user list, why?
  • 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).

  • How is the new soft checkpoint accepted?
  • 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.

  • Does it replace the standard block chain decision algorithm?
  • 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.

  • Should I update my twister-core?
  • Yes, please. Soft checkpoint is available since 01/19/2014 changeset 102d172. This is twisterd version >= 0.9.8.

  • I have something to say…
  • Then post it here.

Posted in Uncategorized

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>