ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-17 📝 Original message: Good morning Nadav, I ...

📅 Original date posted:2019-07-17
📝 Original message:
Good morning Nadav,

I strongly disagree that I first proposed payment points + scalars for Lightning.

My understanding is that Andrew Poelstra first proposed this.
Indeed, his work on Scriptless Script was, to my understanding, primarily motivated by a goal of eventually enabling Lightning over a MimbleWimble blockchain.
The first main use of Scriptless Script was as a replacement for HTLCs, the construction we currently use to enable cross-channel atomic swaps.

(the efforts of Lightning over MimbleWimble have been stymied, I believe, by the difficulty of implementing relative locktimes in a MimbleWimble blockchain while retaining its "magical shrinking blockchain" property; Andrew Poelstra has figured out how to implement absolute locktimes without strongly requiring storage linear to block height under MimbleWimble, to my understanding)

The first time I have mentioned the use of payment points + scalars was here, I believe: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001100.html

At the time my understanding was already that we would eventually (but not yet in the foreseeable future at that time) switch to payment points + scalars.

The "Multi-hop Locks" paper is basically the proposal to use payment point + scalar and also provide path decorrelation.

I believe the features we already know to be enabled or enhanced by payment point + scalar are:

1. Path decorrelation. "Multi-hop locks"
2. "High" AMP https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001100.html
3. Escrow over Lightning.
4. Stuckless payments.
5. Pay-for-signature

There may be others.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 18, 2019 3:25 AM, Nadav Kohen <nadav at suredbits.com> wrote:

> I've gotten a couple questions about the payment point idea. Here are the threads I've seen where ZmnSCPxj mentions payment points may help:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002030.html
>
> Nadav
>
> On Wed, Jul 17, 2019 at 1:27 PM Nadav Kohen <nadav at suredbits.com> wrote:
>
> > Here is a pretty comprehensive write-up on how to make a DLC: https://medium.com/crypto-garage/p2p-protocol-based-crypto-asset-derivative-settled-in-bitcoin-on-discreet-log-contracts-13c823448ae8
> > I believe they also put the txid and such of their CET so you can find the actual script in a block explorer.
> >
> > Also this is always great in case you haven't read it: https://adiabat.github.io/dlc.pdf
> >
> > Best,
> > Nadav
> >
> > On Wed, Jul 17, 2019 at 1:16 PM Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
> >
> > > Hi Nadav,
> > >
> > > Interesting. Is there a writeup anywhere of this CET idea that I can add to my reading list. I feel like I am missing some background.
> > >
> > > LL
> > >
> > > On Thu, Jul 18, 2019 at 2:56 AM Nadav Kohen <nadav at suredbits.com> wrote:
> > >
> > > > Hi Lloyd,
> > > >
> > > > Glad you like it :) And to address your concern, I think that although certainly it is possible for oracles to sell options contracts, it is also possible to have a more decentralized setup with normal DLC oracles (that can be used for all kinds of things as all they do is schnorr sign messages with pre-commited R values), and then have the CETs be 3-of-3 multisig outputs. In this way the oracle is still not learning about the contract, just like normal DLCs.
> > > >
> > > > Best,
> > > > Nadav
> > > >
> > > > On Wed, Jul 17, 2019 at 11:23 AM Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
> > > >
> > > > > Hi Nadav,
> > > > >
> > > > > This is cool idea. I always imagined oracles would either give their DLC signatures away for free or work via a subscription model.
> > > > >
> > > > > The downside to this proposal is that the seller of the signature knows which signature they're selling and therefore learns what kind of contract the buyer must be involved in.
> > > > >
> > > > > LL
> > > > >
> > > > > On Thu, Jul 18, 2019 at 1:37 AM Nadav Kohen <nadav at suredbits.com> wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I recently posted a proposal here for a scheme through which a trusted data provider can utilize the Lightning Network to privately sell data where data is received atomically with purchase.
> > > > > >
> > > > > > I've more recently been thinking about situations where a party, that is *not* trusted, is attempting to sell its signature to a known message. One example of a situation where this would be useful is if someone is trying to offer a DLC-like Option contract where they are essentially collateralizing themselves in a funding transaction and then selling their signatures to Contract Execution Transactions (CETs). In this example, we must ensure that the buyer of the signatures pays if and only if they receive valid signatures for the CETs which are known.
> > > > > >
> > > > > > I believe that this is achievable in a relatively straightforward way if we were to use ZmnSCPxj's proposed payment points with scalars (as opposed to payment hashes with pre-images). The (Schnorr) signature seller could give the buyer their one-time public key, `R = k*G`, through which the buyer could compute the payment point whose scalar is the seller's signature: `sig*G = R + h(m, R)*A` where `A` is the seller's public key. Using this value as the payment point, the buyer could be assured that they pay if and only if they receive `sig` from the seller, where `sig` is the desired valid signature of `m`!
> > > > > >
> > > > > > Best,
> > > > > > Nadav
> > > > > > _______________________________________________
> > > > > > Lightning-dev mailing list
> > > > > > Lightning-dev at lists.linuxfoundation.org
> > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev