Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-17 📝 Original message: Hi Nadav, Interesting. Is ...
📅 Original date posted:2019-07-17
📝 Original message:
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/20190718/7d81834a/attachment.html>;
📝 Original message:
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/20190718/7d81834a/attachment.html>;