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 <na...@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 <na...@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.fo...@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 <na...@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.fo...@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 <na...@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@lists.linuxfoundation.org > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
