Intercoin Technology: Recovery


#1

If all else fails, there is a failsafe mechanism whereby people have cryptographically signed receipts of a transaction. The Permissionless Timestamping Network is an additional innovation at Intercoin that allows each transaction for a given token to be timestamped in a totally ordered way. Thus, as long as each party claiming to hold the token presents their receipts, we can find out who got the token first (by finding the “first fork” by timestamp).

In the catastrophic event that an entire portion of the network fails (e.g. it is blown up), the truth can be reconstructed from receipts provided by people who store their tokens in their wallets (possibly with backups, etc.) A call would go out for token holders (or their agents) to present their receipts, and reclaim the tokens on the reconstituted ledger. There are only two caveats:

  1. All affected tokens are frozen during the reconstruction
  2. This process needs to have a cutoff time, so that the tokens become usable (otherwise we’d always be waiting to see if someone in the world has an even better claim to the token).

This recovery mechanism would only kick in as a last resort and would not operate the vast majority (99.9999999999%) of the time for the lifetime of any token. However, it is good to be extra careful and have this mechanism available.

Previous Topics:
Next Topics:
Intercoin Technology: Background
Intercoin Technology: Architecture
Intercoin Technology: The Tokens
Intercoin Technology: The Ledger
Intercoin Technology: Consensus
Intercoin Technology: Mitigation


Intercoin Technology: The Ledger
Intercoin Technology: Overview
Intercoin Technology: Architecture
Intercoin Technology: Mitigation
Intercoin Technology: Consensus
#2

This is interesting, and I haven’t seen this proposed for other blockchains. For geographically distributed nodes, the chances of most of them being destroyed simultaneously is very low. This could be more of a risk for community coins, where nodes may be located within the same region (thus leaving all nodes vulnerable to the same hurricane or earthquake). It seems to me that just one full node run by a relatively trustworthy person would be the best basis for reconstituting the network in this extreme case (and the person risks their reputation if other parties come forward with conflicting records).


#3

You can mix and match various techniques. The SAFE network is against a failsafe like this because, for them, (a subset of) the network is the ultimate source of truth. They try to make it very hard to compromise all computers in a particular “section” looking after a token/file, by things like:

  1. Using Kademlia for routing
  2. Splitting up files into chunks
  3. Encrypting chunks so the nodes don’t know what they’re storing
  4. Forcing nodes to get new ids periodically and join different sections
  5. All nodes in a section periodically checking that the others are still hosting a resource

Indeed, with 1-5 it seems very hard to compromise this and you don’t need the recovery mechanism. On the other hand, you can have just one validator per token together with the PTN and just have this recovery mechanism. Every time the validator is caught forking, this is stored and the end users reconstitute the token on a new validator using their receipts.

The first way (heavy on prevention, no recovery) can’t be done entirely using nodes in a local community because many communities will have so few nodes that they are easily compromised or blown up, forced to forget some transactions. The trick is to have communities install software on their infrastructure and then update this software to make them provide infrastructure for each other. So each token is stored “in the cloud” — but not a centralized cloud like Amazon Web Services or Digital Ocean but a truly decentralized, blurry cloud. All the tokens would float in this cloud, being issued/managed by some community or other.

The second way (light on prevention, heavy on recovery) is fast the vast majority of the time, and also can be done entirely within in a local community. However, it may be inconvenient to keep recovering and migrating to new infrastructure. It seems to me that this would only be needed for entirely isolated communities (eg on another planet) where we don’t want to rely on any nodes in the “cloud” to validate transactions.

It’s good to separate all these techniques into independent pieces that you can mix and match.


#4

Basically it comes down to this:

If A pays B some token T, B is interested in having it known that B is the latest owner of T.

Now suppose that latest update was somehow erased from the ledger, and it went back to a previous history where A still owned T. Now A can spend T again — but what’s worse is that B can’t spend it.

However, once B has spent T, it is no longer so interested in the network remembering the updates to the token since A. Only the latest owner of the token is really invested in having the ledger remember its ownership of T.

So what is the incentive for ledger participants to forget that A spent T and revert back to an earlier history (ie “fork” the history and permit a double-spend?) Well maybe A can track them all down and bribe them, perhaps T is worth more than the reputation they would collectively lose by “forking”.

So SAFE Network tries to make tracking down and colluding with the validators as hard as possible. But since it’s sharded, there are only a few computers to compromise, and maybe some technique (a backdoor or virus or sybil sleeper attack) can start an epidemic of double-spends. Each token T can be worth a limited amount but together such double-spends could add up and also shake confidence in the system.

Bitcoin tries to make it extremely expensive to make a different fork. You need to have more hash rate than the entire network. But then every potential miner has to get every transaction. And every full node has to store every trasaction ever. That’s not very scalable or quick.

So unless there is some way to make it totally infeasible (probabilistically speaking) to make all the validators watching T to forget, it may happen. And in theory there should be a way to recover as soon as a proof of a fork is furnished.

The latest token holders and the people they pay are the ones who will not want to deal with a corrupt network, so as long as the proof of fork by a validator is communicated to them, they will ignore those corrupted validators. If they don’t, someone down the line won’t accept their payment.

At the end of the day, you are responsible for keeping backups of your own files and your own money in redundant places. The network can do the best it can but if some parts are blown up, information may be lost. This is what happened in the movie “Fight Club”. Everyone should have had off-site backups :slight_smile:

What is the probability of that happeneing, though? Turns out is can be made very small even when the network is sharded: