mimblewimble team mailing list archive

[Ruben <rsomsen@xxxxxxxxx>]

 Hi Jeff,

Dryja's DLC uses payment channels and is compatible with the Lightning
Network. I recommend you check out his presentation:
https://youtu.be/Vpr3vKeByfM

Around https://youtu.be/Vpr3vKeByfM?t=2257 Dryja mentions how it can
function on Lightning and what you'll have to do if the wrong transaction
gets published.

If you apply Poelstra's AS here, it simply becomes impossible for the wrong
transaction to get published. This makes DLC on Lightning more
simple/efficient.

Cheers,
Ruben Somsen


On Wed, May 23, 2018 at 2:29 PM, Jeffrey Rufino <jeff@xxxxxxxxxxxxxxxxxxxxxx
> wrote:

> Hi Ruben,
>
> Is this concept similar to Lighting Network?
>
> Regards,
>
> Jeff
>
> *Jeffrey Rufino*
>
>
>
>
>
> Jeffrey Rufino
>
> *Digital Marketing Manager*
>
> m: 0411 530 910
> a: Level 1, 187 Mulgrave Road, Cairns, 4870
> <https://maps.google.com/?q=Level+1,+187+Mulgrave+Road,+Cairns,+4870&entry=gmail&source=g>
> w: www.localvisibility.com.au/  e: jeff@xxxxxxxxxxxxxxxxxxxxxx
>
> Let's Chat - Book A Time <http://calendly.com/jeffreyrufino>
>
> On Tue, May 22, 2018 at 8:43 PM, Ruben <rsomsen@xxxxxxxxx> wrote:
>
>> Hi all,
>>
>>
>> Tadge Dryja's Discreet Log Contracts (DLC) can be combined with Andrew
>> Poelstra's Adaptor Signatures (AS). I'm simply describing the
>> combination of the two existing concepts without any fundamental changes,
>> but I thought it was worth writing out explicitly since I haven't seen any
>> write-up. Hopefully it doesn't contain any errors.
>>
>> Starting from Schnorr signature [R, s].
>>
>> In DLC, the oracle will reveal one of multiple possible s values as part
>> of signing the outcome of an event. This s is essentially a private key for
>> which the public key S can be calculated ahead of time (because R is
>> committed to in advance).
>>
>> In AS, instead of just R (essentially a public key), you add a second
>> public key P of which the payer wishes to obtain the private key p from the
>> payee. Only by revealing p can the payee make the signature valid, and thus
>> receive the payment.
>>
>> If we use S in place of P, we have essentially combined DLC and AS.
>>
>> I believe this reduces the complexity of the Bitcoin contracts described
>> in Dryja's DLC paper, since it is no longer possible to submit the wrong
>> state (the signature won't be valid).
>>
>> As a side note, DLC + graftroot can achieve the same thing.
>>
>>
>> More detailed example:
>>
>> Alice and Bob (A and B) want to bet 1 BTC on whether it will rain
>> tomorrow.
>>
>> Olivia will publish "yes" or "no" under her key O and commitment R.
>>
>> This means there are two possible values for S:
>>
>> S1 = R + hash(R, "yes")*O
>> S2 = R + hash(R, "no")*O
>>
>> Alice and Bob create a payment channel under key A + B = C with 1 BTC
>> each.
>>
>> They propose two possible channel updates: 2 BTC for Alice if it rains,
>> or 2 BTC for Bob if it doesn't.
>>
>> The channel update (simplified to single key C) where Alice wins is
>> signed with:
>>
>> R1 = r*G + S1
>> s' = r + hash(R1, transaction)*c
>>
>> Note that we wrote s' because s is not complete. We added S1 to R, so we
>> need to add s1 to s' in order to get s.
>>
>> And similarly for Bob:
>>
>> R2 = r*G + S2
>> s' = r + hash(R2, transaction)*c
>>
>> Let's say Bob was right and Olivia signs "no", thereby revealing s2. This
>> now completes the signature: s = s' + s2.
>>
>> s*G == R2 +  hash(R2, transaction)*C
>>
>>
>> Cheers,
>> Ruben Somsen
>>
>>
>>
>> On Sun, Jun 4, 2017 at 4:29 AM, Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx
>> > wrote:
>>
>>>
>>> Yep, I was around MIT a few days ago and Tadge explained the proposal to
>>> me. Like pay-to-contract, it works with ECDSA or Schnorr, and is totally
>>> compatible with Mimblewimble.
>>>
>>>
>>> On Sat, Jun 03, 2017 at 01:50:12PM -0400, Ignotus Peverell wrote:
>>> > Hi all,
>>> >
>>> > Tadge just published a paper very much along the lines of Andrew's
>>> scriptless scripts and other proposals we've seen on the list:
>>> >
>>> > https://adiabat.github.io/dlc.pdf
>>> >
>>> > It describes a form of futures contract with an Oracle that only
>>> relies on time-based transactions and Schnorr. Seems we could support that
>>> form of contract as well.
>>> >
>>> > - Igno
>>>
>>> > --
>>> > Mailing list: https://launchpad.net/~mimblewimble
>>> > Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~mimblewimble
>>> > More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>> --
>>> Andrew Poelstra
>>> Mathematics Department, Blockstream
>>> Email: apoelstra at wpsoftware.net
>>> Web:   https://www.wpsoftware.net/andrew
>>>
>>> "A goose alone, I suppose, can know the loneliness of geese
>>>  who can never find their peace,
>>>  whether north or south or west or east"
>>>        --Joanna Newsom
>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~mimblewimble
>>> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~mimblewimble
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~mimblewimble
>> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~mimblewimble
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>