(E)mail Client for Limited or Blocked Internet

There are two motivations for this post

  1. Some countries, such as China and Belarus are already blocking Tor. We can expect that in future some countries will try to block cryptocurrency protocols in a similar way.

  2. Internet just being restored in Iran after week-long shutdown caused by unrest. Previously there were partial or complete shutdowns in Egypt, Ethiopia, Sudan, Turkey.

However, people have right to store value available, whether the value is under threat from monetary policies, political instability, or war. Happily, with digital communications and digital gold this problem could be solved.

As possible solution for Bitcoin, Blockstream satellite network could be used, however, satellite signal could be jammed. Another workaround which I am going to propose is to use e-mail (which is last to be blocked usually) or other low-bandwidth and not very interactive means of communication (fax, modem call over a landline to a bulletin board system, mail).

So assume Alice is willing to buy X ergs from Bob (paying with cash), but internet is very limited or does not working in their area. Bob owns a box protected by a public key (stored locally). Then the protocol could be as follows.

  1. Bob is creating transaction from his box which is creating a new box where X ergs are locked by the condition “Before deadline: Bob’s signature and spending transaction has an output of X ergs which belongs to Alice’s public key; After deadline: Bob’s signature”. I will refer to the new box as to the “deal box” further. Please note that for a signed transaction outputs with respective identifiers are known.

  2. Bob sends the transaction over (e)mail to a gateway. Gateway sends efficient NiPoPoW proof for a header having enough confirmations + proof of box membership against state digest from the header. This proof is small, tens of kilobytes. for better security, Bob may ask another gateway for header proof as well.

  3. Bob shows proofs to Alice. Alice checks proofs and also that deadline will not likely met when a new transaction with their deal will reach the Ergo blockchain. Bob signs the new transaction which is spending the deal box created on step 1 and creating the output box for Alice.

  4. Now Alice sends the transaction signed by Bob to the gateway and gets the proof of inclusion from it.

With proofs of such size (tens of kilobytes), email / fax / ADSL modem or even paper work fine as means of communication between the users and the gateways.


This is a pretty interesting use of NiPoPoW, and shows there’s a lot of potential with such things.

The specific way this situation is laid out, this would only be useful if at some later point in time Alice could regain access to the internet to send her Ergs, right? I am sure this would still be quite useful in a lot of situations where a person’s local currency might be heavily depreciating and they are looking for a way to store their value with the hope that in the next few months/years/… they’ll be able to get out and then be able to spend said funds.


Right, in most cases Alice will buy to hold until better times, or to relocate with value stored in safe digital haven, as I can imagine

Interesting use of NiPoPoWs as Robert said. The goal is to have people without Internet access, or at least so limited access that they cannot run a node. So this is for “nodeless” people I might say.

I might be missing something or perhaps there is a typo in the original post?

Did you mean?

I presume you want Bob to put the coins in some sort of an escrow (emulated by the deal box) such that Bob can take it back after the deadline, and Alice has some assurance that she will be able to perform Step 4 before the deadline expires, otherwise Bob can double-spend the deal box. Is this correct?

Does it protect from a cheating gateway that is running a private blockchain with reduced difficulty?

1 Like

Yes, the “deal” escrow box prevents double-spending (within certain time-window).

On attacks from malicious mining power, the protocols (IPoPoW / NIPoPoW) assume multiple provers, with at least on of them being honest. Similarly, Alice for better security should use several gateways with at least one of them being honest.

1 Like