Date: Sat, 20 Jun 2020 16:01:16 +0000
To: "David A. Harding" <dave@dtrt.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <wRX9uiX_fFrjZvlmgx3Sj64VA3DdXakJZJq2_7DHJWIS7QBlphgpaBDdm4SjdY4aij5pESsumww8iJw8QZe5mO8bPgpYFyp6eImF2xbaXR4=@protonmail.com>
In-Reply-To: <20200620103647.g62srlcxbjqpaqj6@ganymede>
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
 <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
 <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>
 <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>
 <CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>
 <20200619195846.fclw4ilngvbbf2kk@ganymede>
 <20200619205220.fshbr7pbijaerbf2@ganymede>
 <CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com>
 <20200620103647.g62srlcxbjqpaqj6@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
	and Competing Interest
Precedence: list

Good morning Dave,

> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a transaction with
> a second output that OP_RETURN included the serialized adaptor
> signature. The pubkey would be designed to be spendable by anyone with
> the final signature in a way that revealed the hidden value to the
> pubkey's creator, allowing them to resolve the PTLC. But if that's
> fundamentally not possible, I think we could advocate for making
> pay-to-revealed-adaptor-signature possible using something like
> OP_CHECKSIGFROMSTACK.[3]


Not a cryptographer, I just play one on the Internet, but maybe the pay-for=
-signature construction could work...?

Assuming a PTLC has a pointlocked branch, which involves signing with MuSig=
(A, B).
A offers to B the amount if B reveals the secret `t` behind `T =3D t * G`; =
A knows `T` but not `t`.
This is done by B handing over `R[B]` and `s'[B]`:

    R =3D R[A] + R[B] + T
    s'[B] =3D r[B] + h(MuSig(A, B) | R | m) * b

Then A provides its partial signature to B.

    s[A] =3D r[A] + h(MuSig(A, B) | R | m) * a

B has to complete the signature by:

    s =3D s[A] + s'[B] + t

Since A knows both `s[A]` and `s'[B]`, once it knows `s`, it can compute `t=
`.


Now, we can massage the equation for `s`:

    s =3D r[A] + h(MuSig(A, B) | R | m) * a + r[B] + h(MuSig(A, B) | R | m)=
 * b + t
    ; multiply both sides by G
    s * G =3D r[A] * G + h(MuSig(A, B) | R | m) * a * G + r[B] * G + h(MuSi=
g(A, B) | R | m) * b * G + t * G
    ; replace with public points
    s * G =3D R[A] + h(MuSig(A, B) | R | m) * A + R[B] + h(MuSig(A, B) | R =
| m) * B + T

Note that A can compute `s * G` above, because it generated `R[A]`, was giv=
en `R[B]` and `T`, and knows who `A` and `B` are.

So what A needs to do is to offer a fund that can only be claimed by leakin=
g knowledge of `s` behind `s * G`.
A can do this by creating a new keypair `A[p4s] =3D a[p4s] * G` and putting=
 a fund into it.

Then A generates an `R[A][p4s] =3D r[A][p4s] * G`, and computes:

    R[p4s] =3D R[A][p4s] + s * G
    s'[A][p4s] =3D r[A][p4s] + h(A | R[p4s] | m) * a[p4s]

The signed message could be a signature to `SIGHASH_NONE`, finally an actua=
l use for that flag.

A reveals publicly (in an `OP_RETURN` as you suggest):

* `R[A][p4s]`
* `s * G`
* `s'[A][p4s]`
* `A[p4s]` - Already the Schnorr output pubkey.

In order to complete the above signature, a third party C has to learn `s` =
from B.

The third party has to scan every onchain 1-of-1 signature for an `s` that =
matches `s * G`, so there is greater processing (point multiplies are more =
expensive than hashes, also there are more 1-of-1s).
But once learned, the third party can complete the signature and claim the =
funds.
And A then learns `s`, from which it can derive `t`.

The third party learns about which channel (i.e. the UTXO that was spent to=
 create the PTLC in the first place), but never learns `t` or `T`, which is=
 a small but nice privacy bonus.


Regards,
ZmnSCPxj