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

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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