diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-06-20 16:01:16 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-06-20 16:01:28 +0000 |
| commit | 2d95b530096df59d9fa05ec16a84e162799c38b1 (patch) | |
| tree | d9068273f17f11344b5ae36a33182f83183715db | |
| parent | d58aa73b9b7f4e59ca0ce121ee0f23907390abfc (diff) | |
| download | pi-bitcoindev-2d95b530096df59d9fa05ec16a84e162799c38b1.tar.gz pi-bitcoindev-2d95b530096df59d9fa05ec16a84e162799c38b1.zip | |
Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest
| -rw-r--r-- | f0/635c20a0af2095cfaf86a03d8309372136843c | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/f0/635c20a0af2095cfaf86a03d8309372136843c b/f0/635c20a0af2095cfaf86a03d8309372136843c new file mode 100644 index 000000000..3d1df9f5f --- /dev/null +++ b/f0/635c20a0af2095cfaf86a03d8309372136843c @@ -0,0 +1,150 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id E4C99C016E; + Sat, 20 Jun 2020 16:01:28 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by silver.osuosl.org (Postfix) with ESMTP id D4AF720532; + Sat, 20 Jun 2020 16:01:28 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from silver.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 6jHKtZDBPKFk; Sat, 20 Jun 2020 16:01:26 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch + [185.70.40.140]) + by silver.osuosl.org (Postfix) with ESMTPS id 5A9222001E; + Sat, 20 Jun 2020 16:01:26 +0000 (UTC) +Date: Sat, 20 Jun 2020 16:01:16 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail; t=1592668883; + bh=sxmsoUy5qN34lSw5S2tuI6xNmBRPaI4a4XPpoMMDVmo=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; + b=uYFH09dgXMoEx/BYy7276ql77kzMjgLhnbSj+8LovCrIusYAciU4mZTVt56Rw/tRg + ouQ9t/MWeQyzJNt5uzzv+G9ZfRObWibSCFt/GWQrnx+xmUVUfIkuJb5o5KkI7GHZtl + 9wMU2xkk4gTttp1J9b1E2Cj8PbHgKOir0u9c+qlM= +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 +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sat, 20 Jun 2020 16:01:29 -0000 + +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 + |