[Lightning-dev] Selling Signatures: Another Reason to Move to Payment Points

[Nadav Kohen]

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
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190717/48877984/attachment.html>