Would it be possible to develop a layer 2 solution that works well in delay tolerant network environments? From my understanding, the purpose of most layer 2 off-chain solutions such as Lightning Network is to delay settlement onto the blockchain until a later point of time, but when a client has intermittent access to the internet, it is branded as non-responsive. Non-responsive clients are a liability to their peers, as if a peer has bitcoin tied up in the channel, it is stuck there until the timeout period. Now envisage a scenario in a third world country, where you have sporadic network access - would you have to rely on third-parties to settle your payments when you're offline?
I started thinking at this point... it would be possible to create a layer 2 solution that works on the basis of Message Authentication Codes (MAC) which establish an agreement between the payer and payee? This protocol enables value to be transferred from Alice to Bob by copying 8 digits in one direction and 8 digits in another. The code is computed using secret keys assigned to each participant, which is based on several parameters. Both systems are completely offline, so it is important that both the transaction is capable of validating without access to an internet connection.
The steps outlined to complete this transaction are as follows:
- Alice agrees to pay Bob X.
- Bob enters into phone the transaction amount X and Alice's phone number A. Bob's phone then generates a random 4 digit nonce (NB). Then it computes a MAC on A, B, NB, X and the log of the previous transactions T between the two parties. The MAC and the nonce together make up the 8 digit Code 1.
- Alice enters into her phone the transaction amount X and Bob's phone number A. It prompts her for Code 1, which she asks Bob for and enters. If there is a disagreement at this stage, or attempted cheating by Bob, then Alice's phone will generate an error.
- If Code 1 is correct, then Alice's account's available balance is decreased by the transaction amount X and then generates Code 2 to authenticate the transaction. Code 2 is 8 digits long, it consists of a random 4 digit nonce (NA) generated by Alice's phone, and 4 digits from a MAC on A, B, NB, X and the log of the previous transactions T between the two parties.
- Alice then gives Code 2 to Bob. If it is valid, then Bob's account balance is incremented by X.
- A confirmation message is displayed to both Alice and Bob confirming the completion of the transaction.
Now there's a number of security implications here - what's to stop Alice from tampering with things on her end to just "forget" the transaction took place?
An example:
- Alice sets up an offline account with 1 BTC in it. Alice then takes a snapshot of the state of her account.
- Alice then spends 0.5 BTC with Bob. This is an offline transaction so the only basis Bob has to go on that Alice has the funds is Alice's digital wallet. The transaction goes through, Bob is assumably happy with his decentralised money.
- Alice then resets the state of her digital wallet to before the transaction. Suddenly she has 1 BTC again and goes and spends more money. As far as Bob's concerned he's been paid, but there's no external verification.
Now, even if Bob posts the transaction information down the road and Alice's real account is billed, Alice still has an offline digital wallet with $100 in it that no-one verifies. She essentially can spend this repeatedly.As the transaction needs to be trustless and operate offline with intermittent access to the internet, how would such a problem be resolved? Essentially it currently relies on the integrity of a secret key to prevent rolling-back/double-spends, and in the event that one person gets the secret key the trust disintegrates because with the same algorithm you can generate whichever codes you want. Would 2 nodes who have transacted in a offline bidirectional channel need to be penalised if they do not go online frequently enough (i.e. once a week) to sync their balances?
