path: root/ec/fb3bfe7d14f8eaeb77bb11247a8750dab26c5c

Return-Path: <joost.jager@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0E6C7C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Jun 2023 19:26:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id DCF3F820F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Jun 2023 19:26:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DCF3F820F6
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=HpDlSmjU
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ljMv00PgrsDA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Jun 2023 19:26:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BEBEA820F1
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [IPv6:2a00:1450:4864:20::52e])
 by smtp1.osuosl.org (Postfix) with ESMTPS id BEBEA820F1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Jun 2023 19:26:20 +0000 (UTC)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-51478f6106cso6435754a12.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Jun 2023 12:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686511579; x=1689103579;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=kA6p0i71pkyMh4BrWcgkoDK77w1HRItmf+l4NFya+lc=;
 b=HpDlSmjUoMNPx8ZObkGQfM/kDfwupi2+lTts1quxtbW3+VlcQkZKm1+k7MptnMeCDB
 qmN4ZRH7P11Uw+3sFi935FWV2Xtt+noH8W7Ka5tUTU80GlQGY17MpxKkpLEngZ8x9haa
 yEErU9pdoB6u9bTOgJGi2Ic7H4NzVrze/eYSdBsXE16qZyfYXX0GBdWto6/eWZY7rxST
 SKSNE0afr9PIkbSO5R/hNIxcRNIkix3ZkVc1el4y9eiRJVEzNPYtdsv1WUd25AEmgwhV
 gqEWiA1zG/XG3bDtarlRi79PH6hedgooRfzXXk0DQCJsmo0XYOZ1UK7A4SZ10e1q4Vql
 ZzIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686511579; x=1689103579;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=kA6p0i71pkyMh4BrWcgkoDK77w1HRItmf+l4NFya+lc=;
 b=VO7Dky/qsjudg/1GWfeh+dXWaL378F6wXvAIj9U5pTdGxpMJVWUtTELvRfAetbLcFo
 PCbTo6ijgLz8J9Y09n0U4Md091U03v/WTbNLpTYal1vXRNXEU6dTdVHFe+eMtDWVurm5
 GV+u1VGSjNp0E97VXsEO/N0YePnrjSCL6Uz8efVj/SQM/0OvR9m+x8gQqE+PXmlAHq0J
 HhWwzlqcXkQySJLPiYc5h7fgF/pmWoi/t3jA5vmk5AmjHYobrLo2x4n0XPzjWFGto3CQ
 RlZydSMyOijFJ1tnKbIkOg+NWk/Hes1VPvxO1zBlAahqrtdUI/xgDYqSn3xH/mC9C2xn
 3efA==
X-Gm-Message-State: AC+VfDxTFlp7kWVMMvvJKa6syoieLRH2Cbfgt/Ez7kJR/Vsyj7H85q+r
 kVZ7oppcvY6TgYz32bsNJjYdRcK2+V/FQxLr5ZSxI7eWpLg=
X-Google-Smtp-Source: ACHHUZ6L0Pq/9NaUgUyAoEx+u4kwUOJJs1HNCGzkOvDlBaM3jv69aK1M+Qw6WfQ4W76yRtRDPFvOVizaA2vkUWLJbpM=
X-Received: by 2002:a17:907:6da1:b0:979:65f0:cced with SMTP id
 sb33-20020a1709076da100b0097965f0ccedmr7129536ejc.17.1686511578545; Sun, 11
 Jun 2023 12:26:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
 <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
 <fe630ee713829e1ce2df33a8438cbcf5@dtrt.org>
In-Reply-To: <fe630ee713829e1ce2df33a8438cbcf5@dtrt.org>
From: Joost Jager <joost.jager@gmail.com>
Date: Sun, 11 Jun 2023 21:25:42 +0200
Message-ID: <CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000008c84c205fddf9319"
X-Mailman-Approved-At: Sun, 11 Jun 2023 20:36:09 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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: Sun, 11 Jun 2023 19:26:22 -0000

--0000000000008c84c205fddf9319
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dave,

On Sun, Jun 11, 2023 at 12:10=E2=80=AFAM David A. Harding <dave@dtrt.org> w=
rote:

> 3. When paying the script in #2, Alice chooses the scriptpath spend from
>     #1 and pushes a serialized partial signature for the ephemeral key
>     from #2 onto the stack, where it's immediately dropped by the
>     interpreter (but is permanently stored on the block chain).  She also
>     attaches a regular signature for the OP_CHECKSIG opcode.
>

Isn't it the case that that op-dropped partial signature for the ephemeral
key isn't committed to and thus can be modified by anyone before it is
mined, effectively deleting the keys to the vault? If not, this would be a
great alternative!

Even better, I think you can achieve nearly the same safety without
> putting any data on the chain.  All you need is a widely used
> decentralized protocol that allows anyone who can prove ownership of a
> UTXO to store some data.
>

I appreciate the suggestion, but I am really looking for a bitcoin-native
solution to leverage bitcoin's robustness and security properties.

By comparison, rolling
> out relay of the annex and witness replacement may take months of review
> and years for >90% deployment among nodes, would allow an attacker to
> lower the feerate of coinjoin-style transactions by up to 4.99%, would
> allow an attacker to waste 8 million bytes of bandwidth per relay node
> for the same cost they'd have to pay to today to waste 400 thousand
> bytes, and might limit the flexibility and efficiency of future
> consensus changes that want to use the annex.


That years-long timeline that you sketch for witness replacement (or any
other policy change I presume?) to become effective is perhaps indicative
of the need to have an alternative way to relay transactions to miners
besides the p2p network?

I agree though that it would be ideal if there is a good solution that
doesn't require any protocol changes or upgrade path.

Joost

--0000000000008c84c205fddf9319
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Dave,</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, Jun 11, 2023 at 12:10=E2=80=AFAM Davi=
d A. Harding &lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; wro=
te:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">3. When paying t=
he script in #2, Alice chooses the scriptpath spend from<br>
=C2=A0 =C2=A0 #1 and pushes a serialized partial signature for the ephemera=
l key<br>
=C2=A0 =C2=A0 from #2 onto the stack, where it&#39;s immediately dropped by=
 the<br>
=C2=A0 =C2=A0 interpreter (but is permanently stored on the block chain).=
=C2=A0 She also<br>
=C2=A0 =C2=A0 attaches a regular signature for the OP_CHECKSIG opcode.<br><=
/blockquote><div><br></div><div>Isn&#39;t it the case that that op-dropped =
partial signature for the ephemeral key isn&#39;t committed to and thus can=
 be modified by anyone before it is mined, effectively deleting the keys to=
 the vault? If not, this would be a great alternative!</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Even better, I think you can achieve nearly the same safety without<br>
putting any data on the chain.=C2=A0 All you need is a widely used<br>
decentralized protocol that allows anyone who can prove ownership of a<br>
UTXO to store some data.=C2=A0=C2=A0<br></blockquote><div><br></div><div>I =
appreciate the suggestion, but I am really looking for a bitcoin-native sol=
ution to leverage bitcoin&#39;s robustness and security properties.</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">By compariso=
n, rolling<br>
out relay of the annex and witness replacement may take months of review<br=
>
and years for &gt;90% deployment among nodes, would allow an attacker to<br=
>
lower the feerate of coinjoin-style transactions by up to 4.99%, would<br>
allow an attacker to waste 8 million bytes of bandwidth per relay node<br>
for the same cost they&#39;d have to pay to today to waste 400 thousand<br>
bytes, and might limit the flexibility and efficiency of future<br>
consensus changes that want to use the annex.</blockquote><div><br></div><d=
iv>That years-long timeline that you sketch for witness replacement (or any=
 other policy change I presume?) to become effective is perhaps indicative =
of the need to have an alternative way to relay transactions to miners besi=
des the p2p network?</div><div><br></div><div>I agree though that it would =
be ideal if there is a good solution that doesn&#39;t require any protocol =
changes or upgrade path.</div><div><br></div><div>Joost</div></div></div>

--0000000000008c84c205fddf9319--