Storm: layer 2/3 storage & messaging
or «a favorite shitcoins use case is being destroyed with Bitcoin L2»

contributors:
Maxim Orlovsky, PhD, MD
Chief Engineering Officer,Pandora Core AG, Swiss

Giacomo Zucco,
Federico Tenga, Chainside
Marco Amadori, inbitcoin
Martino Salvetti, inbitcoin
Nicola Busanello, inbitcoin
Sabina Sachtachtinskagia, Pandora Core
Stefan Richter @stefanwouldgo
ZmnSCPxj...

Problem: storage• Lightning Network channel state history• Eltoo channel state• Scriptless scripts• Single-use seals off chain data
• … much more
We need economic incentives for all of that!!!

Can it be trestles but guaranteed?
Yes, by utilizing• Probabilistically checkable proofs• HTLCs• PBSTSetting• Bob stores data for Alice• Alice must be guaranteed to receive Bobs money if she stored thedata – no matter if Bob is still interested in receiving the dataor running with the data away without paying once he has the data

• Bob must be compensated if Alice fails to keep the data

Bob may encrypt the data, split the data across different Alice(s)etcIntuition for core "tricks"• Bob can proof the fact that he has the data in a succinct way
both to Alice and on-chain with the current Bitcoin script byutilizing probabilistically checkable proofs• Alice gets obscured data from Bob encrypted with his yet unknown
public key and is able to decrypt them only when the Bob takes
his payment

Probabilistically checkable proofs
Random selection of data pieces for probabilistic proofs
Source data

Merklezation#Steps• Bob stores data for Alice• Alice puts payment and Bob puts stake under escrowed time locked
contractLegend:

Funding transaction (on-chain)#0#0

input (possible multiple)with at least `reward`
amount coming fromAlice
Alice

Alice3input(s) with at least`stake` amount comingfrom BobnSequence: 0x00
nTimeLock: 0x00

# Alice# Bob– by delay: in case Alice did
not appear with a request forthe data, Bob takes bothstake and reward for himself

#1

Bob

Partially-signed transaction`stake+reward` output– by cooperative closing:
Alice provides Bob with HTLC
transaction

nSequence: 0x00

Bob

On-chain transaction

2

# Bob

1

Final outcome numberedaccording to the listof possible scenarios

Local party:

Remote party:

Signature

Signature

Unsigned

Unsigned

Public key

Public key#Hash value of everythingthat follows after this sign
Secret (like decryption key)
OP_CSVSteps• Bob stores data for Alice• Alice puts payment and Bob puts stake under escrowed time locked
contract• They pre-sign partial transactions for different scenarios

Closing scenarios: Alice timeout
Funding transaction (on-chain)#0#0

input (possible multiple)with at least `reward`
amount coming fromAliceAliceAlice`stake+reward` output– by cooperative closing:
Alice provides Bob with HTLC
transaction

3nSequence: 0x00

input(s) with at least`stake` amount comingfrom BobnSequence: 0x00
nTimeLock: 0x00

Bob

# Bob

– by delay: in case Alice did
not appear with a request forthe data, Bob takes bothstake and reward for himself#1Bob# Alice2# Bob• If Alice forgets about her data,
Bob still takes the payment forstorage and his stake back

Random selection of data pieces for probabilistic proofs
Source data

Merklezation• Bob encrypts Alice data

Decryption key

with some public andprivate key pair

Encryption key#

Encrypted data

PCP proof showing Alicethat he has reallyencrypted the originaldata

Merklezation

Hashing#BOB ("STORAGE PROVIDER")
ALICE ("USER")

Decryption key hash#Encrypted data

• Bob constructs special

zk PCP ProofClosing scenarios: cooperative
HTLC settlement transaction (pre-signed by Bob)#0spends output from theHTLC confirmation tx
Alice
AliceBobBob

1nSequence: ____
nTimeLock: ____

#0– cooperative: Bob has toexpose decryption key inorder to access the funds.
This private key is used by
Alice to decrypt the data

# 3 # Bob
– by delay: if Bob does nottakes the reward and his
stake within some predefined time, leaving Alice
without an ability to accessthe data, she can claim both
reward and Bob’s stake forherself# Alice• If Alice is happy with Bob’s proof,
she signs pre-signed Bob’stransaction.

• When Bob claims funds from #0 output,
he reveals encryption key, so Aliceis able to decrypt her dataClosing scenarios: cooperative
HTLC settlement transaction (pre-signed by Bob)

#0spends output from theHTLC confirmation tx
AliceBobAliceBob

1nSequence: ____
nTimeLock: ____

#0– cooperative: Bob has toexpose decryption key inorder to access the funds.
This private key is used byAlice to decrypt the data

• If Alice is happy with Bob’s

proof, she signs pre-signed Bob’s
transaction# 3 # Bob
– by delay: if Bob does nottakes the reward and his
stake within some predefined time, leaving Alice
without an ability to accessthe data, she can claim bothreward and Bob’s stake forherself# Alice• If Bob disappears after that,

Alice will be able to get her
money back plus Bob’s stake tocompensate the loss of the dataClosing scenarios: non-cooperative• If Alice is not happy with Bob’s

HTLC fallback transaction (pre-signed by Alice)#0
spends output from thefunding transaction via
the multisig option
AliceBob

Alice

Bob– appeal: stake andsome pre-defined portionof reward go to Bob if hecan proof that he stillholds Alice data

# 2 # Bob– default:`stake+reward*factor` goback to Alice after somedelay# Alice#1

the rest of reward go
back to Alice anyway, asa compensation for client
dissatisfaction

nSequence: _____
nTimeLock: _____

proof, she signs another presigned Bob’s transaction# Alice• with it, after some delay she will
get both her money and Bob’s staketo compensate the loss of the dataClosing scenarios: non-cooperative• If Alice is not happy with Bob’s

HTLC fallback transaction (pre-signed by Alice)#0
spends output from thefunding transaction via
the multisig option
AliceBobAliceBob– appeal: stake andsome pre-defined portionof reward go to Bob if hecan proof that he stillholds Alice data

# 2 # Bob– default:`stake+reward*factor` goback to Alice after somedelay# Aliceproof, she signs another pre-signed
Bob’s transaction• Bob can appeal to that and prove that
he has actually kept the data. He has
to provide a pre-image composed ofparts of the data selected according
to the Alice public key exposed toBob by this closing transaction#1

the rest of reward go
back to Alice anyway, asa compensation for client
dissatisfaction

nSequence: _____
nTimeLock: _____# Alice• In this case Bob still gets his stakeback plus the reward (or part of thereward, since Alice as a client isunhappy)

Bob’s proof of data storage• At setup time Alice uses her newly-derived public key for both

funding transaction output and deterministic definition of somesmall portion of the source data.

• This portion of the data is double-hashed to 160-bit hash andincluded into HTLC fallback tx by Alice as a hash lock.

• When Bob wants to prove that he still has the data available, hesee the published HTLC transaction, extracts Alice public key anduses it to get the same deterministic piece of the source data as
Alice. Bob computes a single hash on the data, which gives him apreimage to unlock the hash lock from the HTLC transaction output
before Alice will spend it (Alice's branch is timelocked).

Closing scenarios: non-cooperative• If Alice is not happy with Bob’s

HTLC fallback transaction (pre-signed by Alice)#0
spends output from thefunding transaction via
the multisig option
AliceBobAliceBob– appeal: stake andsome pre-defined portionof reward go to Bob if hecan proof that he stillholds Alice data

# 2 # Bob– default:`stake+reward*factor` goback to Alice after somedelay# Aliceproof, she signs another pre-signed
Bob’s transaction• Bob can appeal to that and prove that
he has actually kept the data. He has
to provide a pre-image composed ofparts of the data selected according
to the Alice public key exposed toBob by this closing transaction#1

the rest of reward go
back to Alice anyway, as
a compensation for client
dissatisfaction

nSequence: _____
nTimeLock: _____# Alice• In this case Bob still gets his stakeback plus the reward (or part of thereward, since Alice as a client isunhappy)

Why important?
• Alice needs to store only seed phrase to keep all here L2/L3 data
• Incentivization for watchtowers and other schemes• Potentially can be done on top of Lightning Network: zerotransactions will reach blockchain

Limitations• The same security assumptions as for ZP: proofs are probabilistic• Bob can cheat with hash of the decryption key. ZK can be used toavoid that, but this will be very computationally-expensive.

• Tradeoff between protecting data storage providers from DDoS attacks
and protecting clients from being wrong-treated by data storage
providers• adjustable parameter in each case• reputation system for storage providers may help
• storage redundancy for critical data for anonymous providers isrequired

What’s next?
Potentially can be done on top of Lightning Network: zerotransactions will reach blockchain

To find out more
• https://github.com/storm-org/storm-spec• https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019August/017269.html• https://bitcoinmagazine.com/articles/dr-maxim-orlovsky-on-stormand-bitcoin-l2-l3-file-storage

Ways to contact me• https://twitter.com/dr_orlovsky• https://github.com/dr-orlovsky• @dr_orlovsky on Telegram• orlovsky@pandoracore.com

https://tippin.me/@dr_orlovsky
bc1qdzyxmdjqq4cl2k2u4kp8vash3t2qhtfvnswhnu