Scaling Bitcoin workshop : Tel Aviv 2019
WIP: Storm: layer 2/3 storage and messaging
Work in progress sessions
Scaling Bitcoin 2019 Tel Aviv "yesod"
Storm: layer 2/3 storage and messaging
Maxim Orlovsky (Pandora Core)
This idea of economical incentives to do the storage of incentives. This is early work in progress.
The problem we're trying to solve is storage. I am not going to describe why we have to store all this data like lightning network, scriptless scripts and single-use seals that all have off-chain data that we need to store remotely.
Can it be trustless but also guaranteed? Yes. By using probabilistically checkable proofs, HTLCs and partially-signed bitcoin transactions.
Basically the idea is to have users pay other users for data storage. Bob can prove the fact that he has the data in a succinct way both to Alice and on-chain with a bitcoin script. We use probabilistically checkable proofs for that. Alice gets obscured data from Bob encrypted with his yet unknown public key and is able to decrypt them only when Bob takes his payment for storage. Alice only learns this at that point.
I won't have time to describe probabilistically checkable proofs. It's a kind of zero knowledge technology. You use the hash of a merkle root over some random oracle to select more pieces of the data, and then you provide those pieces together with a merkle path tree to demonstrate with some probability you can't assume this number upfront but for a small number of the data you have, you're still able to prove something on that and I'll show how we are using that for storage.
Bob stores data for Alice. She puts a payment for that storage. Bob puts it under an escrow timelock contract. There's two inputs, coming from Alice and Bob. There are two options to be spent. If Alice forgets about her data (maybe she dies or whatever), Bob still takes the payment for storage and his stake back. After that, they sign a number of transactions but they don't publish them. Bob encrypts Alice data with some public and private key pair. Bob constructs a special PCP proof showing Alice that he has really encrypted the original data. If they close cooperatively, she signs pre-signed Bob's transaction. When bob claims funds, he reveals a decryption key that allows Alice to decrypt the data. Alice can verify that she has the correct encrypted blob through some mechanism. If Bob doesn't provide Alice with the key, and he doesn't take his money, Alice will be able to get her money back plus Bob's stake to compensate for the loss of the data.
There are also two uncooperative cases. Maybe Alice is unhappy with Bob's proofs and he is trying to cheat. She signs another pre-signed transaction. After some delay, she will be able to get both her money back and Bob's stake again to compensate for Bob's negliglence. But if Alice is trying to cheat, Bob can appeal to that fact and provide another PCP proof showing on-chain that he really has this data and Alice is just not wanting to pay. In this case, Bob takes his stake back and the reward from Alice maybe not the full reward it depends on the agreement between the two parties when they setup the contract at the moment.
How can Bob prove on chain that he has the data?
At setup time, Alice uses her newly derived public key for both the funding transaction output and deterministic definition of some small portion of the source data. She puts into the funding transaction the hash of the public key she will be using later. She uses this public key to select some random portion of the data she has. This portion is double hashes by some hash, and included into HTLC fallback. This hash can be unlocked only if you have the source data and the public key of Alice. When Bob wants to prove he still has the data available, he sees that Alice has published a management transaction and he extracts the public key from that transaction, and now he knows what part of the source data to use, he hashes that, and then he .... to unlock his... output.
Why is this important? This is tech for incentivized data storage. Alice only needs to store a seed phrase. This can potentially be done on top of the lightning network, and zero transactions will reach the blockchain.