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

2019-07-20 Thread Jonas Nick
Perhaps worth noting that in addition to selling signatures, it's also possible
to sell blind Schnorr signatures [0] and anonymous credentials [1].

[0] 
https://github.com/ElementsProject/scriptless-scripts/blob/master/md/partially-blind-swap.md
[1] https://youtu.be/XORDEX-RrAI?t=26552, slides 
https://nickler.ninja/slides/2018-bob.pdf

On 7/17/19 3:37 PM, Nadav Kohen 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


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

2019-07-17 Thread ZmnSCPxj via Lightning-dev
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  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  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  
> > 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  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  
> > > > 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  
> > > > > 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

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

2019-07-17 Thread 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  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 
> 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  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 
>>> 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 
 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


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

2019-07-17 Thread Nadav Kohen
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 
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  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 
>> 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  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


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

2019-07-17 Thread Lloyd Fournier
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  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 
> 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  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


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

2019-07-17 Thread Nadav Kohen
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 
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  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


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

2019-07-17 Thread Lloyd Fournier
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  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


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

2019-07-17 Thread Nadav Kohen
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