Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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