From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20200620103647.g62srlcxbjqpaqj6@ganymede> References: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com> <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com> <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com> <20200619195846.fclw4ilngvbbf2kk@ganymede> <20200619205220.fshbr7pbijaerbf2@ganymede> <20200620103647.g62srlcxbjqpaqj6@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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