At Suredbits, we use the Lightning Network to create monetized data services. We currently have Lightning APIs selling NFL and NBA stats as well as cryptocurrency market data. In the future, we think that Lightning will be used to monetize all forms of data. Any content such as games, music, sports, weather, financial, or blog posts will be monetized with cryptocurrency. A couple weeks ago, we posted a proposal Lightning Application Standard (LAS) to the lightning-dev mailing list with some details about how we think data should be sold using lightning. We internally refer to this scheme as PAID (Payment-Atomic Information Decryption).
Every Lightning transaction includes what is called a proof of payment (PoP). A PoP is some random secret that acts like a receipt in the sense that you get this random secret if and only if your payment goes through. In the current version of Lightning, this is the pre-image to the payment hash but all future versions of Lightning will also have a PoP.
Our proposal is to use this PoP to encrypt the data being sold and to send this encrypted data to the user when you send them the invoice for the data. In this way, the user can be assured that they will always receive the data if they pay.
Even if the seller’s server goes down or anything else happens which would cause the seller to be unresponsive, if your payment for the data goes through, then you receive the data because you already have it, it is just encrypted with your PoP. It is also important to note that the user does not receive the data if they do not pay: They will be unable to decrypt what they have without the PoP which can only be attained by paying the vendor’s invoice.
Once a payment has been received by the data provider using PAID, they may offer the payment preimage directly to the data recipient if there is a communication channel to the user – for example over a websocket. The data provider can also simply make the payment pre-image publicly available, e.g. via a public API. This is done to provide for a better user experience by reducing latency as well as reducing the amount of communication a lightning application (Lapp) client must have with a lightning node.
You can see a PAID API in action on our recently released Historical Crypto prices API service.
We are working to improve our PAID API and the standard it implements. We hope that by having a standard that the community adopts for PAID APIs, all lightning applications will benefit from improved user experience and interoperable payment that will be as seamless as those on sites such as www.yalls.org. There have been lots of helpful suggestions from the thread for this proposal on the lightning-dev mailing list. In the future, we will also be implementing authentication on the data so that users know that they are paying for exactly what the vendor intended to send them (and nothing has been corrupted in transit). We also plan on adding a way to this specification for PAID to be used over insecure channels. This can be accomplished by encrypting the data a second time with a buyer’s public key so that eavesdroppers don’t learn what is being bought and sold (although this addition to the standard does not affect our implementation since we send the data over a secure channel using HTTPS).
Contact us @Suredbits
Contact Nadav @Nadav_Kohen
All of our API services are built using Lightning technology and the Lightning Network. All API services are live on Bitcoin’s mainnet. Our fully customizable data service allows customers to stream as much or as little data as they wish and pay using bitcoin.
You can connect to our Lightning node at the url:
038bdb5538a4e415c42f8fb09750729752c1a1800d321f4bb056a9f582569fbf8e@ln.suredbits.com
To learn more about how our Lightning APIs work please visit our API documentation or checkout our new websocket playground to start exploring custom data feeds.
If you are a company or cryptocurrency exchange interested in learning more about how Lightning can help grow your business, contact us at [email protected].