Date: Sun, 21 Jun 2020 02:10:32 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <v959z56ko0Nzdl9BGs-zRWIxIy9o960OfvH6bRszIC9_JI-zdtQuSb7fPD4L_VnngBp_nLMMfl_Nfd6ZLtSeZZRKhZoFO5Xxryvo6GT0zT4=@protonmail.com>
In-Reply-To: <wRX9uiX_fFrjZvlmgx3Sj64VA3DdXakJZJq2_7DHJWIS7QBlphgpaBDdm4SjdY4aij5pESsumww8iJw8QZe5mO8bPgpYFyp6eImF2xbaXR4=@protonmail.com>
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>
 <wRX9uiX_fFrjZvlmgx3Sj64VA3DdXakJZJq2_7DHJWIS7QBlphgpaBDdm4SjdY4aij5pESsumww8iJw8QZe5mO8bPgpYFyp6eImF2xbaXR4=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
	and Competing Interest
Precedence: list

Good morning again,

> 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 wit=
h
> > 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]
>
> <snip>
>
> The signed message could be a signature to `SIGHASH_NONE`, finally an act=
ual use for that flag.

If you are going to embed it in an `OP_RETURN` in the same transaction, you=
 also need `SIGHASH_ANYPREVOUT`, otherwise you cannot embed the adaptor sig=
nature for spending from that transaction in the transaction being spent, i=
t also implies `A[p4s] =3D a[p4s] * G` is a one-time-use keypair.

Regards,
ZmnSCPxj