* [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
@ 2019-08-19 22:08 Dr Maxim Orlovsky
2019-08-21 4:14 ` ZmnSCPxj
0 siblings, 1 reply; 8+ messages in thread
From: Dr Maxim Orlovsky @ 2019-08-19 22:08 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
Hi,
I'd like to propose a design for distributed storage and messaging with escrow/economic incentivization leveraging LNP/BP ecosystem and working at Layer 2 and 3. It is described in details here: https://github.com/storm-org/storm-spec [1]
Briefly, it allows to construct special type of payment channels guaranteeing remote data storage and retrieval with counterparty risks mitigated by economic stimulus (stakes etc). Next, it can be combined with Lightning Network, i.e. operate completely off-chain ("Storm with Lightning" :).
This proposal came as a side-effect of our joint work on RGB and single-use seals technologies (recently mentioned by Peter Todd here [2]). In the nearest future I will be busy with finalizing and implementing these protocols, but don't want this idea to be missed/forgotten, since it can be very useful for other L2/L3 technologies requiring client-stored data, like guaranteeing external storage of script data for Taproot, scriptless scripts or Prometheus (technology for scalable computing [3]). So I'd welcome any possible comments, critics, or interest in driving Storm development forward.
[1] https://github.com/storm-org/storm-spec
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017257.html
[3] https://github.com/pandoracore/prometheus-spec/blob/master/prometheus.pdf
------
Dr Maxim Orlovsky
Pandora Core AG
https://twitter.com/dr_orlovsky
https://github.com/dr-orlovsky
xorlovsky[1..]@pandoracore.com
[-- Attachment #2: Type: text/html, Size: 1750 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
2019-08-19 22:08 [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3 Dr Maxim Orlovsky
@ 2019-08-21 4:14 ` ZmnSCPxj
2019-08-21 7:32 ` ZmnSCPxj
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: ZmnSCPxj @ 2019-08-21 4:14 UTC (permalink / raw)
To: Dr Maxim Orlovsky, Bitcoin Protocol Discussion
Good morning Maxim,
Insufficient/unclear Description of Probabilistic Proof
=======================================================
It seems to me that the probabilistic checkable proof, whose description I read naively, is not sufficient to prove the statement:
* The source data is the same as the source data originally stored by Alice.
When generating the proof, Bob can use the output of any PRNG as the "source data".
If Alice only checks validity of this proof, then it will accept the output of the PRNG as the actual stored data, which from what I understand is not your goal.
The probabilistic checkable proof by itself just proves the statement:
* The encrypted data corresponds to the given plaintext.
So, before Alice sends its local copy of the data to Bob for storage and deletes it, Alice must first compute a Merkle Tree of the data chunks and store the Merkle Tree root (a small 32-byte data).
And the probabilistic checkable proof has to include the Merkle Tree Path proofs of the selected *source* data chunks together with the source chunks.
Similar problems arise in the pay-for-data scheme proposed in Lightning:https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html
The data provider is trusted to give actual data instead of the output of a PRNG.
In the case of paid storage, Alice had access to the data originally stored (presumably) and can keep a short "checksum" of the original data.
It might be that you imply this in your step 1 for Alice validation of the probabilistic checkable proof though it may be better clarified that Alice has to keep the Merkle Tree root for the original data it originally requested:
> With this data Alice will be able to check with this zero-knowledge argument by:
> 1. Checking Merkle tree paths leading to the chunks and resulting Merkle tree root hash to correspond to them
Will the Real Decryption Key Please Stand Up?
=============================================
Also, it seems to me that the encryption used must be an asymmetrical encryption.
That is, the encryption and decryption keys must be different, with the encryption key being a "public" key Bob can safely share with Alice and the decryption key being a "private" key that Bob can share only once it has acquired its funds.
An issue that arises is: while an HTLC is used to atomically transfer the decryption key in exchange for payment, what is the assurance given to Alice that the hash of the decryption key is indeed the hash of the decryption key and not, say, the output of a PRNG?
That is, Bob must prove:
* The given hash h is the hash of the secret decryption key d whose equivalent encryption key is e
...while revealing only h and e to Alice.
If there exists some asymmetric encryption using EC (I know of no such, but that is only due to my ignorance), where the decryption key is a scalar and the encryption key is the scalar times the generator then it would be possible to use 2p-ECDSA / Schnorr Scriptless Script to atomically pay for knowledge of the scalar / decryption key, while knowing the encryption key.
Instead of a hash of the decryption key, Bob sends the encryption key during setup and Alice and Bob use that in the pointlocked timelocked contract under Scriptless Script.
Transporting Storm Over Lightning
=================================
Of note is that any mechanism that requires multiple participants to put up money into a contract (as in the case of Storm, which requires both the stake from Bob and the reward from Alice to be put into a single timebound HTLC) can only live inside a single LN channel and is not transportable across intermediate nodes.
This is because intermediate nodes potentially become subject to attack in case of routing failure.
(Though it *may* be possible to reuse the sketch I give here for HTLC-enforced publication of combined HTLCs: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html)
This is part of what makes LN difficult to work with multiple asset types due to HTLCs naturally forming premium-free American Call Options.
Avoiding premium-free American Call Options is possible by extracting the premium from the receiver and combining it with the money from the exchange, but this again is doable only onchain, or in a single LN channel (meaning receivers must centralize around exchanges).
It may be possible to get around this, once Lightning supports payment points + scalars, by use of EC magic homomorphisms, though I lack the energy right now to go dig up the resources on lightning-dev.
But the storage provider can route a payment to Alice to serve as stake, which can be claimed only if knowing some secret, then Alice routes the stake+reward to Bob, and use some of the EC magic homomorphism while keeping intermediate nodes unaware.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
2019-08-21 4:14 ` ZmnSCPxj
@ 2019-08-21 7:32 ` ZmnSCPxj
2019-08-21 9:33 ` Stefan Richter
2019-08-21 17:04 ` Dr Maxim Orlovsky
2019-08-21 10:51 ` Dr Maxim Orlovsky
[not found] ` <A733B8A1-2E88-47F4-A6CF-C56C84E8FF9A@pandoracore.com>
2 siblings, 2 replies; 8+ messages in thread
From: ZmnSCPxj @ 2019-08-21 7:32 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Dr Maxim Orlovsky
Good morning Maxim,
The Deaf Bob Attack
===================
It seems to me that Bob can promote the N3 problem to the N2 problem.
Suppose Alice contacts Bob to get the data.
However, Bob happens to have lost the data in a tragic boating accident.
Now, supposedly what Alice does in this case would be to broadcast the HTLC settlement transaction, whose signature was provided by Bob during protocol setup.
But this seems unworkable.
* If Bob managed to sign the HTLC settlement transaction, what `SIGHASH` flags did Bob sign with?
* If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already selected the decryption key at setup time.
* If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, including `<Alice> OP_CHECKSIG`.
If Bob already selected the decryption key at setup time, then Bob can ignore Alice.
* If Alice does not publish the HTLC settlement transaction, then Bob will eventually enter the N2 state and get the stake+reward.
* If Alice *does* publish the HTLC settlement transaction, without Bob giving the encrypted data, then Bob can just use the hashlock and reveal the decryption key.
* The decryption key is useless without the encrypted data!
It seems this part is not workable?
As the decryption key is embedded in the HTLC, Alice cannot get a signature from Bob without the decryption key already being selected by Bob (and thus already claimable even without any data being returned by Bob).
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
2019-08-21 7:32 ` ZmnSCPxj
@ 2019-08-21 9:33 ` Stefan Richter
2019-08-21 17:04 ` Dr Maxim Orlovsky
1 sibling, 0 replies; 8+ messages in thread
From: Stefan Richter @ 2019-08-21 9:33 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]
Please see the github issues and the twitter discussion (e.g. here:
https://twitter.com/stefanwouldgo/status/1163801056423403520) for similar
points other people including me have made. At this point I feel there are
quite a few unclear points in the presentation and it is not clear to me if
they can be salvaged.
Am Mi., 21. Aug. 2019 um 09:32 Uhr schrieb ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org>:
> Good morning Maxim,
>
> The Deaf Bob Attack
> ===================
>
> It seems to me that Bob can promote the N3 problem to the N2 problem.
>
> Suppose Alice contacts Bob to get the data.
> However, Bob happens to have lost the data in a tragic boating accident.
>
> Now, supposedly what Alice does in this case would be to broadcast the
> HTLC settlement transaction, whose signature was provided by Bob during
> protocol setup.
>
> But this seems unworkable.
>
> * If Bob managed to sign the HTLC settlement transaction, what `SIGHASH`
> flags did Bob sign with?
> * If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already selected
> the decryption key at setup time.
> * If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, including
> `<Alice> OP_CHECKSIG`.
>
> If Bob already selected the decryption key at setup time, then Bob can
> ignore Alice.
>
> * If Alice does not publish the HTLC settlement transaction, then Bob will
> eventually enter the N2 state and get the stake+reward.
> * If Alice *does* publish the HTLC settlement transaction, without Bob
> giving the encrypted data, then Bob can just use the hashlock and reveal
> the decryption key.
> * The decryption key is useless without the encrypted data!
>
> It seems this part is not workable?
> As the decryption key is embedded in the HTLC, Alice cannot get a
> signature from Bob without the decryption key already being selected by Bob
> (and thus already claimable even without any data being returned by Bob).
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2798 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
2019-08-21 4:14 ` ZmnSCPxj
2019-08-21 7:32 ` ZmnSCPxj
@ 2019-08-21 10:51 ` Dr Maxim Orlovsky
2019-08-21 12:48 ` ZmnSCPxj
[not found] ` <A733B8A1-2E88-47F4-A6CF-C56C84E8FF9A@pandoracore.com>
2 siblings, 1 reply; 8+ messages in thread
From: Dr Maxim Orlovsky @ 2019-08-21 10:51 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Hi ZmnSCPxj,
Thank you very much for spending your time on analysing my idea at such a deep level – and writing the detailed review proposing possible solutions to the main found issues.
> Insufficient/unclear Description of Probabilistic Proof
> =======================================================
>
> <...>
> It might be that you imply this in your step 1 for Alice validation of the probabilistically checkable proof though it may be better clarified that Alice has to keep the Merkle Tree root for the original data it originally requested:
>
>> With these data, Alice will be able to check with this zero-knowledge argument by:
>> 1. Checking Merkle tree paths leading to the chunks and resulting Merkle tree root hash to correspond to them
Correct, I forgot to put this step into the description, will fix, sorry for that. Indeed, Alice needs to take a "shot" from the data in a form of Merkle tree and keep its root for herself, and Bob has to provide her with
* "PCP-selected" blocks of source
* "PCP-selected" blocks of encrypted data
* siblings of the Merkle root "leafs" for the selected source data (required for Alice to check source data paths up to the Merkle root which she had kept for herself)
* Merkle paths for both of them
* public key used for the encryption, so Alice can re-encrypt received source data blocks and make sure they are equal to the provided encrypted blocks, so this public key is true
> Will the Real Decryption Key Please Stand Up?
> =============================================
>
> Also, it seems to me that the encryption used must be an asymmetrical encryption.
> That is, the encryption and decryption keys must be different, with the encryption key being a "public" key Bob can safely share with Alice and the decryption key being a "private" key that Bob can share only once it has acquired its funds.
Correct, it should be working like in PGP/GPG
> That is, Bob must prove:
>
> * The given hash h is the hash of the secret decryption key d whose equivalent encryption key is e
>
> ...while revealing only h and e to Alice.
Yes, that is an important point, I've missed that out.
> If there exists some asymmetric encryption using EC (I know of no such, but that is only due to my ignorance), where the decryption key is a scalar and the encryption key is the scalar times the generator then it would be possible to use 2p-ECDSA / Schnorr Scriptless Script to atomically pay for knowledge of the scalar / decryption key, while knowing the encryption key.
> Instead of a hash of the decryption key, Bob sends the encryption key during setup and Alice and Bob use that in the pointlocked timelocked contract under Scriptless Script.
A very elegant solution, thank you! Yes, seems one can encrypt/decrypt with EC: https://developer.ibm.com/swift/2019/03/04/blueecc-elliptic-curve-cryptography/ and this should work. I will include your solution to the proposal.
It also might be possible to implement your solution with threshold ECDSA signatures, that will enable Storm before Schorr's will get to Bitcoin. I am not very good in understanding them yet, but it seems that multiparty ECDSA (or threshold ECDSA, t-ECDSA) unlock many of Schnorr’s signature features and benefits.
One may check https://github.com/KZen-networks/multi-party-ecdsa and papers:
* https://eprint.iacr.org/2019/114.pdf
* https://link.springer.com/chapter/10.1007/978-3-319-39555-5_9 https://twitter.com/alexbosworth/status/1163116574238056448
I will investigate that in more details.
> Transporting Storm Over Lightning
> =================================
>
> Of note is that any mechanism that requires multiple participants to put up money into a contract (as in the case of Storm, which requires both the stake from Bob and the reward from Alice to be put into a single timebound HTLC) can only live inside a single LN channel and is not transportable across intermediate nodes.
> This is because intermediate nodes potentially become subject to attack in case of routing failure.
> (Though it *may* be possible to reuse the sketch I give here for HTLC-enforced publication of combined HTLCs: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html)
>
> This is part of what makes LN difficult to work with multiple asset types due to HTLCs naturally forming premium-free American Call Options.
> Avoiding premium-free American Call Options is possible by extracting the premium from the receiver and combining it with the money from the exchange, but this again is doable only onchain, or in a single LN channel (meaning receivers must centralize around exchanges).
> It may be possible to get around this, once Lightning supports payment points + scalars, by use of EC magic homomorphisms, though I lack the energy right now to go dig up the resources on lightning-dev.
> But the storage provider can route a payment to Alice to serve as stake, which can be claimed only if knowing some secret, then Alice routes the stake+reward to Bob, and use some of the EC magic homomorphism while keeping intermediate nodes unaware.
You are right, my solution is limited to a single LN channels, i.e. there must be a direct dually-funded channel between Alice and Bob (and we don't have dually-funded channels as a part of current LN BOLT's). I will add this disclaimer to the spec.
Your solution to the transporting problem is indeed very interesting, however, I need some time to analyze it in more details. Meanwhile, if you don't mind, I will open an issue on GitHub and will be copying the discussion to there as well, so others from outside of this mail list can also join.
Kind regards,
Maxim Orlovsky
https://github.com/dr-orlovsky
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
[not found] ` <A733B8A1-2E88-47F4-A6CF-C56C84E8FF9A@pandoracore.com>
@ 2019-08-21 12:12 ` ZmnSCPxj
0 siblings, 0 replies; 8+ messages in thread
From: ZmnSCPxj @ 2019-08-21 12:12 UTC (permalink / raw)
To: Maxim Orlovsky; +Cc: Bitcoin Protocol Discussion
Good morning Maxim,
I also sent another email with the below text, it seems to have gotten missed somehow or not sent properly or some other problem.
The Deaf Bob Attack
===================
It seems to me that Bob can promote the N3 problem to the N2 problem.
Suppose Alice contacts Bob to get the data.
However, Bob happens to have lost the data in a tragic boating accident.
Now, supposedly what Alice does in this case would be to broadcast the HTLC settlement transaction, whose signature was provided by Bob during protocol setup.
But this seems unworkable.
* If Bob managed to sign the HTLC settlement transaction, what `SIGHASH` flags did Bob sign with?
* If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already selected the decryption key at setup time.
* If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, including `<Alice> OP_CHECKSIG`.
If Bob already selected the decryption key at setup time, then Bob can ignore Alice.
* If Alice does not publish the HTLC settlement transaction, then Bob will eventually enter the N2 state and get the stake+reward.
* If Alice *does* publish the HTLC settlement transaction, without Bob giving the encrypted data, then Bob can just use the hashlock and reveal the decryption key.
* The decryption key is useless without the encrypted data!
It seems this part is not workable?
As the decryption key is embedded in the HTLC, Alice cannot get a signature from Bob without the decryption key already being selected by Bob (and thus already claimable even without any data being returned by Bob).
Regards,
ZmnSCPxj
> Hi ZmnSCPxj,
>
> Thank you very much for spending your time on analysing my idea at such deep level – and writing the detailed review proposing possible solutions to the main found issues.
>
> > Insufficient/unclear Description of Probabilistic Proof
> >
> > ========================================================
> >
> > <...>
> > It might be that you imply this in your step 1 for Alice validation of the probabilistic checkable proof though it may be better clarified that Alice has to keep the Merkle Tree root for the original data it originally requested:
> >
> > > With this data Alice will be able to check with this zero-knowledge argument by:
> > >
> > > 1. Checking Merkle tree paths leading to the chunks and resulting Merkle tree root hash to correspond to them
>
> Correct, I forgot to put this step into the description, will fix, sorry for that. Indeed, Alice needs to take a "shot" from the data in a form of Merkle tree and keep its root for herself, and Bob has to provide her with
>
> - "PCP-selected" blocks of source
> - "PCP-selected" blocks of encrypted data
> - siblings of the Merkle root "leafs" for the selected source data (required for Alice to check source data paths up to the Merkle root which she had kept for herself)
> - Merkle paths for both of them
> - public key used for the encryption, so Alice can re-encrypt received source data blocks and make sure they are equal to the provided encrypted blocks, so this public key is true
>
>
> > Will the Real Decryption Key Please Stand Up?
> >
> > ==============================================
> >
> > Also, it seems to me that the encryption used must be an asymmetrical encryption.
> > That is, the encryption and decryption keys must be different, with the encryption key being a "public" key Bob can safely share with Alice and the decryption key being a "private" key that Bob can share only once it has acquired its funds.
>
> Correct, it should be working like in PGP/GPG
>
> > That is, Bob must prove:
> >
> > - The given hash h is the hash of the secret decryption key d whose equivalent encryption key is e
> >
> > ...while revealing only h and e to Alice.
>
> Yes, that is an important point, I've missed that out.
>
> > If there exists some asymmetric encryption using EC (I know of no such, but that is only due to my ignorance), where the decryption key is a scalar and the encryption key is the scalar times the generator then it would be possible to use 2p-ECDSA / Schnorr Scriptless Script to atomically pay for knowledge of the scalar / decryption key, while knowing the encryption key.
> > Instead of a hash of the decryption key, Bob sends the encryption key during setup and Alice and Bob use that in the pointlocked timelocked contract under Scriptless Script.
>
> Very elegant solution, thank you! Yes, seems one can encrypt/decrypt with EC:https://developer.ibm.com/swift/2019/03/04/blueecc-elliptic-curve-cryptography/ and this should work. I will include your solution into the proposal.
>
> It also might be possible to implement your solution with threshold ECDSA signatures, that will enable Storm before Schorr's will get to Bitcoin. I am not very good in understanding them yet, but it seems that multiparty ECDSA (or threshold ECDSA, t-ECDSA) unlock many of Schnorr’s signature features and benefits.
> One may check https://github.com/KZen-networks/multi-party-ecdsa and papers:
>
> - https://eprint.iacr.org/2019/114.pdf
> - https://link.springer.com/chapter/10.1007/978-3-319-39555-5_9 https://twitter.com/alexbosworth/status/1163116574238056448
>
> I will investigate that in more details.
>
>
> > Transporting Storm Over Lightning
> >
> > ==================================
> >
> > Of note is that any mechanism that requires multiple participants to put up money into a contract (as in the case of Storm, which requires both the stake from Bob and the reward from Alice to be put into a single timebound HTLC) can only live inside a single LN channel and is not transportable across intermediate nodes.
> > This is because intermediate nodes potentially become subject to attack in case of routing failure.
> > (Though it may be possible to reuse the sketch I give here for HTLC-enforced publication of combined HTLCs: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html)
> > This is part of what makes LN difficult to work with multiple asset types due to HTLCs naturally forming premium-free American Call Options.
> > Avoiding premium-free American Call Options is possible by extracting the premium from the receiver and combining it with the money from the exchange, but this again is doable only onchain, or in a single LN channel (meaning receivers must centralize around exchanges).
> > It may be possible to get around this, once Lightning supports payment points + scalars, by use of EC magic homomorphisms, though I lack the energy right now to go dig up the resources on lightning-dev.
> > But the storage provider can route a payment to Alice to serve as stake, which can be claimed only if knowing some secret, then Alice routes the stake+reward to Bob, and use some of the EC magic homomorphism while keeping intermediate nodes unaware.
>
> You are right, my solution is limited to a single LN channels, i.e. there must be a direct dually-funded channel between Alice and Bob (and we don't have dually-funded channels as a part of current LN BOLT's). I will add this disclaimer to the spec.
>
> Your solution to the transporting problem is indeed very interesting, however I need some time to analyze it in more details. Meanwhile, if you don't mind, I will open an issue in GitHub and will be copying the discussion to there as well, so others from outside of this mail list can also join.
>
> Kind regards,
> Maxim Orlovsky
> https://github.com/dr-orlovsky
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
2019-08-21 10:51 ` Dr Maxim Orlovsky
@ 2019-08-21 12:48 ` ZmnSCPxj
0 siblings, 0 replies; 8+ messages in thread
From: ZmnSCPxj @ 2019-08-21 12:48 UTC (permalink / raw)
To: Dr Maxim Orlovsky; +Cc: Bitcoin Protocol Discussion
Good morning Maxim,
> > <...>
> > It might be that you imply this in your step 1 for Alice validation of the probabilistically checkable proof though it may be better clarified that Alice has to keep the Merkle Tree root for the original data it originally requested:
> >
> > > With these data, Alice will be able to check with this zero-knowledge argument by:
> > >
> > > 1. Checking Merkle tree paths leading to the chunks and resulting Merkle tree root hash to correspond to them
>
> Correct, I forgot to put this step into the description, will fix, sorry for that. Indeed, Alice needs to take a "shot" from the data in a form of Merkle tree and keep its root for herself
Thank you for the clarification, indeed it is better to explicit this step.
> > If there exists some asymmetric encryption using EC (I know of no such, but that is only due to my ignorance), where the decryption key is a scalar and the encryption key is the scalar times the generator then it would be possible to use 2p-ECDSA / Schnorr Scriptless Script to atomically pay for knowledge of the scalar / decryption key, while knowing the encryption key.
> > Instead of a hash of the decryption key, Bob sends the encryption key during setup and Alice and Bob use that in the pointlocked timelocked contract under Scriptless Script.
>
> A very elegant solution, thank you! Yes, seems one can encrypt/decrypt with EC:https://developer.ibm.com/swift/2019/03/04/blueecc-elliptic-curve-cryptography/ and this should work. I will include your solution to the proposal.
>
> It also might be possible to implement your solution with threshold ECDSA signatures, that will enable Storm before Schorr's will get to Bitcoin. I am not very good in understanding them yet, but it seems that multiparty ECDSA (or threshold ECDSA, t-ECDSA) unlock many of Schnorr’s signature features and benefits.
> One may check https://github.com/KZen-networks/multi-party-ecdsa and papers
I did mention 2p-ECDSA, which the last time I checked, was the "best" available multiparty ECDSA.
I have not checked in detail the relative security details of 2p-ECDSA compared to the various multiparty ECDSAs.
In this particular case this is only between two parties, thus 2p-ECDSA should be sufficient.
https://eprint.iacr.org/2011/494.pdf
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html
I have not checked your links and it is possible we are referring to the exact same thing, or your t-ECDSA is a strict improvement over 2p-ECDSA.
> You are right, my solution is limited to a single LN channels, i.e. there must be a direct dually-funded channel between Alice and Bob (and we don't have dually-funded channels as a part of current LN BOLT's). I will add this disclaimer to the spec.
Strictly speaking, dual-funding is completely and totally unnecessary.
As submarine swaps / off-to-onchain swaps are already possible, a simple ritual like the below can emulate dual-funding (at the cost that one side must own the total they agree on onchain):
1. Alice and Bob agree to each put 10mBTC each to form 20mBTC channel.
2. Alice happens to have 20mBTC onchain in her pocket, while Bob has 10mBTC.
3. Bob puts his 10mBTC into an onchain 10mBTC HTLC with locktime 2*L paying to Bob, hashlock paying to Alice (with a preimage known only by Bob).
4. Alice sets up the 20mBTC channel using her 20mBTC onchain.
5. After the channel funding tx is deeply confirmed, Alice forwards a 10mBTC HTLC over that channel with locktime L paying to Alice, hashlock paying to Bob (with the same hash as the above).
6. Bob claims the payment offchain.
7. Alice can now claim the onchain payment.
8. Alice and Bob now have a perfectly balanced channel (as all channels should be), while Alice is now in possession of an extra 10mBTC onchain.
So Alice has 10mBTC offchain, 10mBTC onchain, while Bob has 10mBTC offchain on the same channel.
Dual-funding simply makes the above *much* more efficient, but is not strictly necessary in a world where atomic cross-system swaps are already possible.
From this point of view, every distinct channel is a unique cryptocurrency system, and if atomic cross-system swaps are possible at all, it is immaterial if one system is a blockchain and the other is a payment channel, etc.
You may also be interested in Fulgurite.
This is a project to "split" a channel into Lightning part and DLC (discreet log contract) part.
The reason for splitting is because LN is expected to have much more state updates than DLC (you forward payments all the time, but set up only a few DLCs with direct counterparties).
DLCs require a lot of signatures if they are reanchored to a new state update transaction, so splitting the channel into an LN part with many updates and a DLC part with few updates is sensible to reduce processing and bandwidth.
Similar reasoning may hold for Storm.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
2019-08-21 7:32 ` ZmnSCPxj
2019-08-21 9:33 ` Stefan Richter
@ 2019-08-21 17:04 ` Dr Maxim Orlovsky
1 sibling, 0 replies; 8+ messages in thread
From: Dr Maxim Orlovsky @ 2019-08-21 17:04 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Hi ZmnSCPxj,
> The Deaf Bob Attack
> =============================================
> - If Alice does not publish the HTLC settlement transaction, then Bob will eventually enter the N2 state and get the stake+reward.
> - If Alice does publish the HTLC settlement transaction, without Bob giving the encrypted data, then Bob can just use the hashlock and reveal the decryption key.
> - The decryption key is useless without the encrypted data!
That is the main attack already addressed by couple of other guys in different forms; and you have provided the most detailed explanation of it, thank you. I was working for its solution over the last day and I'd like to propose the following update: https://github.com/storm-org/storm-spec/issues/6#issuecomment-523497555
Briefly, I introduce two new intermediary HTLC transactions (called confirmation and fallbacks). Alice has now a choice to sign HTLC fallback tx if she didn't get the data, and in that case she will get her money (reward) back and Bob's stake as a compensation. Bob can "appeal" to this by confirming that he had hold the data for Alice. Bob does this by providing a "preimage" to the secret hashed by Alice.
This secret is composed at setup time by Alice, and she uses her newly-derived public key for both funding transaction output and deterministically definition of some small portion of the source data. This portion is double-hashed to 160-bit hash and included into HTLC fallback tx by Alice as a hash lock. Later, when Bob wants to prove that he still has the data available, he see the published HTLC transaction, extracts Alice public key and uses it to get the same deterministic piece of the source data as Alice. Bob computes a single hash on the date, which gives him a preimage to unlock the hash lock from HTLC transaction output before Alice will spend it (Alice's output is timelocked).
This solution requires Bob to select decription key at setup time, when he pre-signs the transaction, as you correctly have pointed out:
> If Bob already selected the decryption key at setup time, then Bob can ignore Alice.
Now, we need to aviod situation where by selecting the encryption/decryption pair Bob knows which part of the data he needs to provide Alice in PCP proof, and can discard the rest of the data. This can be mitigated by requiring that the data have to be encrypted using EC multiplication with some factor provided by Alice at the request time.
The only case for possible cheating now is Alice not needing data anymore and avoiding paying the full amount for the storage. However, this can be a part of the Bob business risk and may be covered by some insurance + Alice's reputation & taken into account by Bob at setup time.
Kind regards,
Maxim Orlovsky
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-21 17:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-19 22:08 [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3 Dr Maxim Orlovsky
2019-08-21 4:14 ` ZmnSCPxj
2019-08-21 7:32 ` ZmnSCPxj
2019-08-21 9:33 ` Stefan Richter
2019-08-21 17:04 ` Dr Maxim Orlovsky
2019-08-21 10:51 ` Dr Maxim Orlovsky
2019-08-21 12:48 ` ZmnSCPxj
[not found] ` <A733B8A1-2E88-47F4-A6CF-C56C84E8FF9A@pandoracore.com>
2019-08-21 12:12 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox