path: root/50/54b17674a9bbf80bd208965ae89d9244ab0791

Return-Path: <joost.jager@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7BA41C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Jun 2023 10:38:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 4969B40492
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Jun 2023 10:38:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4969B40492
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=pd3+y8Mm
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id KurTeZpw1om0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Jun 2023 10:38:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DF94740223
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [IPv6:2a00:1450:4864:20::629])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DF94740223
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Jun 2023 10:38:43 +0000 (UTC)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-97454836448so762518166b.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Jun 2023 03:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686652722; x=1689244722;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=F15Cu05Gr+0pyBhFOaJzNSyETN2tAt7oqdHyswPWrSM=;
 b=pd3+y8MmqzAOsCbXimkmpqy/XGY1Iumku3elF6qx1gE6KhLkEmLIYX3GBJ9WpdJ6In
 ZL8WhJvwH4TOfST85x3r930DFGrxNkpfPKyywNn0yApplpfWj8OD2Gv3lLIRglyULP15
 I/2BAWsOHe+pTFkePaBsfmRwO+6WyfYgIgMl5bs2wQGhY/fxeThGmQ3HM+tLwMYYZyOo
 drCOt+CQnT/K1HAgoUeMnoZlHwHygo+RqiA81mq1EFlomIffZYpsjqS//dMWH+ORqL5D
 4U3iZBSX94enYgn0H2Mgc7wjNoFmemTMGvHA0+G6jCeqMPKJ8i050OwqbyJF0qyOrz1P
 yKQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686652722; x=1689244722;
 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=F15Cu05Gr+0pyBhFOaJzNSyETN2tAt7oqdHyswPWrSM=;
 b=HQvV/SxyUbXTVcB07STrnm/2psu/UG14gDKUGdxB23XF1RJB+cKTYrOhxjltTgpdnV
 Nfpa2y9NzkGt4nCYKKek8Ysl7E9twUCSoNJ203rnTo7V3Y77aFSvqaarlU14CXa5RZhd
 TAWfdfPF+DpEjchVWDyUdR6CCecOoszn9bsQseK9H3u6BmtTtnKcqA/N2fpdIP0M46JH
 TNf5PvRU4Z5JX/cz215WER0A/Z0Oe4czM6Js1us2xS/38pHHlUb4DczSBKJDNsXCg0oH
 vsxR5q8kwz7ROR09vLai3gLrcNdqqsm/u1NA1I7FqWKY0JnwZvE384o3VrZcOLIyXeYq
 hJFw==
X-Gm-Message-State: AC+VfDz6d/BK+IQRv2s8ITAopJarMeY6BnT21VrqbnkGwz7uFt0/omB5
 1+b8DAlg6LFJMNC3GcUbu5abmGSalm8Bw6+938U=
X-Google-Smtp-Source: ACHHUZ6s7CsDTG1iTWmGuywvapkz1zik+IBQ72rqzrDIBfLHhBksiFLkQM75FWdqlVTAecEcaNB2FQBRWdJujeEz5d4=
X-Received: by 2002:a17:907:807:b0:94f:3b07:a708 with SMTP id
 wv7-20020a170907080700b0094f3b07a708mr11540121ejb.29.1686652721707; Tue, 13
 Jun 2023 03:38:41 -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>
 <CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com>
 <211fef60bb46fae7f69e8e5882ff27cb@dtrt.org>
In-Reply-To: <211fef60bb46fae7f69e8e5882ff27cb@dtrt.org>
From: Joost Jager <joost.jager@gmail.com>
Date: Tue, 13 Jun 2023 12:38:05 +0200
Message-ID: <CAJBJmV9tx40iJUi-fvi5xib2-Y+Ewg3TD_HmW3zeV4DR7ex-EQ@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000563fb105fe007061"
X-Mailman-Approved-At: Tue, 13 Jun 2023 11:32:21 +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: Tue, 13 Jun 2023 10:38:45 -0000

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

On Tue, Jun 13, 2023 at 10:51=E2=80=AFAM David A. Harding <dave@dtrt.org> w=
rote:

> > I am really looking for a bitcoin-native solution to leverage
> > bitcoin's robustness and security properties.
>
> I understand.  I would briefly point out that there are other advantages
> to not storing a signature for an ephemeral key in the annex.  For
> example, if you want to generate multiple different potential spending
> transactions, you need to store one signature for each potential
> transaction.  The more data you store in the annex, the less scalable
> the vault protocol becomes; by comparison, it's possible to cheaply
> store a very large amount of data offchain with high robustness.
>

Each byte on-chain indeed has a cost. Though for practical vault usage, you
may only need two spend paths - one for the unvaulting transaction and
another for an emergency transaction.

Also, depending on construction of the vault, a possible advantage of a
> presigned vault (without using the annex) over a solution like OP_VAULT
> is that all actions might be able to use keypath spends.  That would be
> highly efficient, increasing the usability of vaults.  It would also be
> more private, which may be important to certain classes of vault users.
> Even if OP_VAULT was added to Bitcoin, it would be interesting to have
> an alternative vault protocol that offered different tradeoffs.
>

It would indeed be interesting to compare the on-chain footprint of both
vault protocols. The main downside of presigned transactions of course is
the requirement for an ephemeral signer and key deletion. I am not sure if
a potentially smaller on-chain footprint is able to compensate for that.
But the landscape of tradeoffs is complicated, and hard to say what users
prefer if both options would be available to them.


> > 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?
>
> The speed depends on the policy change.  In this case, I think there's a
> reasonable argument to be made that a mitigation for the problems of
> annex relay should be widely deployed before we enable annex relay.
>

On the other hand, maybe we are inside a window of opportunity where the
annex can still be enabled without mitigating this problem fully. Taproot
is still young and you could argue that there are not that many
applications that would be affected by this yet. By clearly communicating
the lack of witness replacement by commonly used node software now,
developers may want to hold off on implementing these applications, rather
than giving them a false sense of security offered by policy. But we've
covered that in this thread before.


> To be specific towards this proposal, if an alternative relay network
> naively implemented annex relay, any miners who used that network could
> receive a coinjoin-style transaction with a large annex that
> significantly reduced the transaction's feerate.  By comparison, any
> miners who continued to only receive transactions from the P2P network
> of Bitcoin Core (or similar) nodes would have received the transaction
> without an annex at its original (higher) feerate, allowing them to to
> receive greater revenue if they mined it.  If, instead, the alternative
> relay network implemented the witness replacement proposal you've linked
> to, those miners could still receive up to 4.99% less revenue than
> Bitcoin Core-based miners


Perhaps way to fix this is to combine the 5% (or whatever constant is
chosen) with Greg's proposal above to also always allow replacement by an
empty annex? That way it's always possible to put in an annex-less
transaction that is part of an annex-less protocol, regardless of how few
extra bytes the annex was inflated with in a previous version of that tx.


> and the operators of the alternative relay
> network might have had to pay extra costs for the replacement relays.
> You can tweak the proposal to tweak those ratios, but I'm not sure
> there's a case where an alternative relay network comes up as a clear
> winner over the existing network for general purpose transactions.
> Instead, like many things, it's a matter of tradeoffs.
>

It is the question whether those 5% replacement DoS attacks are powerful
enough to make it worthwhile for an attacker. And in the case for example
the nostr proposal, there could be anti DoS on a different level as well.


> > I agree though that it would be ideal if there is a good solution that
> > doesn't require any protocol changes or upgrade path.
>
> Apologies for the salt, but there is a good solution: don't use the
> block chain to store backup data.
>

Any auxiliary system that is required for operating a vault adds risk.
Whether it is still good enough is debatable, but I expect some users to
hold the opinion that it isn't.

Joost

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

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jun 13, 2023 at 10:51=E2=80=AFAM =
David A. Harding &lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt;=
 wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">&gt; I am really looking for a bitcoin-native solution t=
o leverage<br>
&gt; bitcoin&#39;s robustness and security properties.<br>
<br>
I understand.=C2=A0 I would briefly point out that there are other advantag=
es<br>
to not storing a signature for an ephemeral key in the annex.=C2=A0 For<br>
example, if you want to generate multiple different potential spending<br>
transactions, you need to store one signature for each potential<br>
transaction.=C2=A0 The more data you store in the annex, the less scalable<=
br>
the vault protocol becomes; by comparison, it&#39;s possible to cheaply<br>
store a very large amount of data offchain with high robustness.<br></block=
quote><div><br></div><div>Each byte on-chain indeed has a cost. Though for =
practical vault usage, you may only need two spend paths - one for the unva=
ulting transaction and another for an emergency transaction.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, depending on construction of the vault, a possible advantage of a<br>
presigned vault (without using the annex) over a solution like OP_VAULT<br>
is that all actions might be able to use keypath spends.=C2=A0 That would b=
e<br>
highly efficient, increasing the usability of vaults.=C2=A0 It would also b=
e<br>
more private, which may be important to certain classes of vault users.<br>
Even if OP_VAULT was added to Bitcoin, it would be interesting to have<br>
an alternative vault protocol that offered different tradeoffs.<br></blockq=
uote><div><br></div><div>It would indeed be interesting to compare the on-c=
hain footprint of both vault protocols. The main downside of presigned tran=
sactions of course is the requirement for an ephemeral signer and key delet=
ion. I am not sure if a potentially smaller on-chain footprint is able to c=
ompensate for that. But the landscape of tradeoffs is complicated, and hard=
 to say what users prefer if both options would be available to them.</div>=
<div>=C2=A0</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">
&gt; That years-long timeline that you sketch for witness replacement (or<b=
r>
&gt; any other policy change I presume?) to become effective is perhaps<br>
&gt; indicative of the need to have an alternative way to relay<br>
&gt; transactions to miners besides the p2p network?<br>
<br>
The speed depends on the policy change.=C2=A0 In this case, I think there&#=
39;s a<br>
reasonable argument to be made that a mitigation for the problems of<br>
annex relay should be widely deployed before we enable annex relay.<br></bl=
ockquote><div><br></div><div>On the other hand, maybe we are inside a windo=
w of opportunity where the annex can still be enabled without mitigating th=
is problem fully. Taproot is still young and you could argue that there are=
 not that many applications that would be affected by this yet. By clearly =
communicating the lack of witness replacement by commonly used node softwar=
e now, developers may want to hold off on implementing these applications, =
rather than giving them a false sense of security offered by policy. But we=
&#39;ve covered that in this thread before.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
To be specific towards this proposal, if an alternative relay network<br>
naively implemented annex relay, any miners who used that network could<br>
receive a coinjoin-style transaction with a large annex that<br>
significantly reduced the transaction&#39;s feerate.=C2=A0 By comparison, a=
ny<br>
miners who continued to only receive transactions from the P2P network<br>
of Bitcoin Core (or similar) nodes would have received the transaction<br>
without an annex at its original (higher) feerate, allowing them to to<br>
receive greater revenue if they mined it.=C2=A0 If, instead, the alternativ=
e<br>
relay network implemented the witness replacement proposal you&#39;ve linke=
d<br>
to, those miners could still receive up to 4.99% less revenue than<br>
Bitcoin Core-based miners </blockquote><div><br></div><div>Perhaps way to f=
ix this is to combine the 5% (or whatever constant is chosen) with Greg&#39=
;s proposal above to also always allow replacement by an empty annex? That =
way it&#39;s always possible to put in an annex-less transaction that is pa=
rt of an annex-less protocol, regardless of how few extra bytes the annex w=
as inflated with in a previous version of that tx.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">and the operators of the al=
ternative relay<br>
network might have had to pay extra costs for the replacement relays.<br>
You can tweak the proposal to tweak those ratios, but I&#39;m not sure<br>
there&#39;s a case where an alternative relay network comes up as a clear<b=
r>
winner over the existing network for general purpose transactions.<br>
Instead, like many things, it&#39;s a matter of tradeoffs.<br></blockquote>=
<div><br></div><div>It is the question whether those 5% replacement DoS att=
acks are powerful enough to make it worthwhile for an attacker. And in the =
case for example the nostr proposal, there could be anti DoS on a different=
 level as well.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
&gt; I agree though that it would be ideal if there is a good solution that=
<br>
&gt; doesn&#39;t require any protocol changes or upgrade path.<br>
<br>
Apologies for the salt, but there is a good solution: don&#39;t use the<br>
block chain to store backup data.<br></blockquote><div><br></div><div>Any a=
uxiliary system that is required for operating a vault adds risk. Whether i=
t is still good enough is debatable, but I expect some users to hold the op=
inion that it isn&#39;t.</div><div><br></div><div>Joost</div></div></div>

--000000000000563fb105fe007061--