Towards Atomic Delivery of Data

The Bitcoin and Lightning community has been exploring the use of Lightning micropayments to support delivery of data. For example, imagine that you pay for access to a news article using a lightning micropayment. In this case, it would be very useful to be able to ensure that the news article is delivered upon receipt of the micropayment. This would make data delivery an atomic operation which makes it much easier to perform data receipt transactions with third parties.

There’s a new proposal out on the Lightning mailing list that provides a sketch of a protocol for making atomic delivery of data possible. The basic idea is to use properties of hash pre-images. In particular, if the data seller decides upon a secret s, they can commit to the hash of the secret H(s) publicly without revealing any information about the secret. This s is called a “hash pre-image”. It’s possible to use these hash pre-images to create clever atomic locking constructions. The idea is that you make it so that the data seller can’t receive their payment without unlocking the user’s access to data.

It might help clarify this construction if we walk through the steps involved in a Lightning data transaction. Let’s say that the two parties involved are the buyer and the seller.

  1. Buyer requests data D from the seller
  2. Seller selects a one-time secret s and publicly commits to h = H(s) its hash.
  3. Seller delivers data encrypted with AES using the secret s as the private key. Buyer receives e = \text{Enc}(D, s)
  4. Buyer makes payment of data to seller. This payment is locked by a Hash lock on h. This lock can only be unlocked by a hash pre-image of h (which is s)
  5. Seller has to reveal s publicly to unlock Hash lock. Seller receives buyer payment
  6. Buyer runs \text{Dec}(e, s) to obtain data D

This construction is very carefully designed to work with Bitcoin’s contract primitives and comes with a nice reference python gist. It’s important to note that it’s not at all hard to adapt this same construction to Ethereum with some smart contract methods. This is very interesting, because it suggests that we might be able to adopt this atomic delivery scheme to improve the Datatrust data delivery scheme.

At present, the data delivery scheme for the Datatrust works as follows

  1. Buyer requests delivery of data
  2. Payment is transferred to the Datatrust.vy contract
  3. Reserve receives its payment fraction up front.
  4. Datatrust reports which listings were accessed. This unlocks payments for listing owners and the datatrust

This scheme does not have any hard guarantees that the Datatrust could not have cheated the buyer and failed to deliver the data. If we add an atomic data delivery construct, we would be able to require that the Datatrust make a delivery to the buyer in order for their payments to be unlocked. This would provide a powerful on-chain guarantee of data delivery that enforces behavior of the datatrust operator.

One limitation of this protocol however is that the Datatrust could deliver a random string r that resembles \text{Enc}(D, s) instead of delivering the true data. The buyer wouldn’t be able to detect this type of fraud until after they’ve made the payment. However, if we make the Datatrust commit to H(\text{Enc}(D, s)) publicly as part of the protocol, the buyer can at least prove fraud was committed by publishing r and s publicly. Stakeholders could verify the fraud for themselves using this information and vote to remove the datatrust if needed.