1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id C1E69C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Feb 2023 14:00:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 8EC5C4098D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Feb 2023 14:00:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8EC5C4098D
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=mail.wpsoftware.net
header.i=@mail.wpsoftware.net header.a=rsa-sha256 header.s=default
header.b=rB+YBHO/
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 91m_w2i3m4MB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Feb 2023 14:00:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5BAF940940
Received: from mail.wpsoftware.net (unknown [66.183.0.205])
by smtp4.osuosl.org (Postfix) with ESMTP id 5BAF940940
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Feb 2023 14:00:51 +0000 (UTC)
Received: from camus (camus-andrew.lan [192.168.0.190])
by mail.wpsoftware.net (Postfix) with ESMTPSA id 0174D400D3;
Wed, 8 Feb 2023 14:00:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net;
s=default; t=1675864850;
bh=HL4P9kNINRYg2F2L+wyo+giDlSUbtCYUhwjd+onTMrY=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=rB+YBHO/X+fdKJOZuztuqiwBUN0/bau3vZQSt6iwtPFk5WPdRYCygT9X3mJXejw4U
mbEWXHYR68Kk5GHRZWjaIqLL0j9CQsWV7AholkM+RMrd1aGFkvV4dkCNq/FEmWbrfx
758Gy/vKGn2iBZbCtrhKwqtns4TuE0hz1Oz4cryPvRrcB0wbFx4tnDjknZ4+w+/Nyz
+Li/GkHvz8gDx4GPzN4w1ERrNDKne7jzy3rquijiOAOtySLV/Vh/ThpcoJkKn4lQ8K
UpTR67xFHPZuj1PgyXvawWYRBuRMYiybiQXpcftH7sBPvQsX3VNSVpALOuyO7LwxCb
SBTAc1zK6x7IQ==
Date: Wed, 8 Feb 2023 14:00:48 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <Y+OrEDooHlijDpJV@camus>
References: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
<Y+JWLsc80gxL4kpG@camus> <Y+KUAlsPc8ohPecb@camus>
<CAMZUoK=u2114uv0Uc0u_RVMBv-cq-gJiNxiyOk_T_xxTYO0Ghw@mail.gmail.com>
<VWZ9Dc2gIe0Y02yY3qSbjQTEPqwCm6YAtRzfNrIANBXCEJzr73SdxZT4LwBKDyriDfmDZyTlkKWtoZmVIUbYqqZUAeTMDLHUNFCBwR6hitQ=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="kQxarOc/A3GibG2Z"
Content-Disposition: inline
In-Reply-To: <VWZ9Dc2gIe0Y02yY3qSbjQTEPqwCm6YAtRzfNrIANBXCEJzr73SdxZT4LwBKDyriDfmDZyTlkKWtoZmVIUbYqqZUAeTMDLHUNFCBwR6hitQ=@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty
protocols with Taproot inputs
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: Wed, 08 Feb 2023 14:00:52 -0000
--kQxarOc/A3GibG2Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 08, 2023 at 09:34:57AM +0000, Michael Folkson wrote:
> Hi Andrew
>=20
> > There is a bug in Taproot that allows the same Tapleaf to be repeated m=
ultiple times in the same Taproot, potentially at different Taplevels incur=
ring different Tapfee rates.
> >> The countermeasure is that you should always know the entire Taptree w=
hen interacting with someone's Tapspend.
>=20
> I wouldn't say it is a "bug" unless there is a remedy for the bug that wa=
sn't (and retrospectively should have been) included in the Taproot design.=
In retrospect and assuming you could redesign the Taproot consensus rules =
again today would you prevent spending from a valid P2TR address if a repea=
ted Tapleaf hash was used to prove that a spending path was embedded in a T=
aproot tree? That's the only thing I can think of to attempt to remedy this=
"bug" and it would only be a partial protection as proving a spending path=
exists within a Taproot tree only requires a subset of the Tapleaf hashes.
>=20
> I only point this out because there seems to be a push to find "bugs" and=
"accidental blowups" in the Taproot design currently. No problem with this=
if there are any, they should definitely be highlighted and discussed if t=
hey do exist. The nearest to a possible inferior design decision thus far t=
hat I'm aware of is x-only pubkeys in BIP340 [0].
>=20
I'm actually not certain what Russell's referring to, but if it's indeed
possible to construct TapTrees where the "same" leafhash appears multiple
times at different heights, that's something unintended and which we
could've fixed by changing the Merkle structure. I don't even think
there would've been an efficiency tradeoff.
So I think it's totally reasonable to call such a thing a "bug".
--=20
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--kQxarOc/A3GibG2Z
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmPjqxAACgkQxYjWPOQb
l8E9iAf/XS7c3n9QLm6Kre4hyOLAv4+KZGSofL0fuMsIDReUSTkbGUZjjAiudWMa
8nsxZtnIhR/RrSncdG+xmJp4+q3wFnRtDbtihSoz0UXWZ6j9nT9J4/0ZNxxpo7pS
Zgllp86HkTZK2cWGmx9hhajaabbqAf9hjjqomJ1lMximn5FsUS0vy7P3T1nR2g3v
WTCBsWY8vuyZhSNy5YaUcO5LMiVmsIyWLiuIhE3PeA8LaXsaAnXo6YlqXB98oZ1w
2tizLszZ2PWxyMXunGJ0746XHIviL+aTR3RX6Wb0gIPWwBy0BwfG8PCXgATY5uLr
6+j6FB146S1vH4iaqfps/ODp6LWi7A==
=LChY
-----END PGP SIGNATURE-----
--kQxarOc/A3GibG2Z--
|
