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
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
Return-Path: <nothingmuch@woobling.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 966D228A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jul 2019 22:48:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com
[209.85.214.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC8248B6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jul 2019 22:48:55 +0000 (UTC)
Received: by mail-pl1-f182.google.com with SMTP id c2so16249827plz.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jul 2019 15:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=woobling.org; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=jY0gzjcQy5tpp3BeWgQ99NfmNRgjS6/nzQ/97RrBkEI=;
b=YBz/uf+O1ym/dyZ/+LSM12edlelFDqNHr8N/Md7xZWOYHxjivx223oPxKuyW2Ad2oK
yFUo5UiAMgCSCcp/OXdHdvqUGHJ/KIASmRJAoKM/N++yJArZwtrK/ScdzM9VFN6d/GKv
e/R6t+caRD5QT5ZHv+e2zdlvjtS57u3yEsGWY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=jY0gzjcQy5tpp3BeWgQ99NfmNRgjS6/nzQ/97RrBkEI=;
b=cZ4PrtY5k9YVQkKGBOXHdu5MvFzrPaaPaPzDvFrm1bcZmqukllGnH65oFa7MUwibIn
pj9RIJmUxxlkT3WXw0omQ4+t8YaOK1/2TLZg/oJB0aeusL/fNVKnY+z5wJlPXWpyreMm
ib2kxUroSIHvFC13q122dYzfTm5xfx5l7vUBipwpz/GJGvB7mfP220ZetNo93Cm5VSwD
32DSuGPxTDWzSbM4OAipMspFYNZ1ut9jUq+gh1W58pujMTaydiH6svfeLHExV4Iw/+J4
zAt9ZFnkCLyWZSwL4a9YPqWjoWGhBjsCA7KW21HUAjdpOpx2HGz9DuMAgNSpRK/lyGmr
YGWg==
X-Gm-Message-State: APjAAAVaX2u/bb/9954l+wWkf6SmSIETMbxIx+KA8dVEfILKCfaF3Reu
VrqntdlUq3eDofhj4CmKmy8B9pjpf5DVtP8ncMRXRNFz
X-Google-Smtp-Source: APXvYqyz7MlHYDLqPbsGOlV96lAumT5yc4v/kugmj5fzdaA8WRF3wZnTQNx1sRd1VugCg0JTtY/2gAJTKvqSzqjc5yA=
X-Received: by 2002:a17:902:9f8e:: with SMTP id
g14mr13581707plq.67.1563576535503;
Fri, 19 Jul 2019 15:48:55 -0700 (PDT)
MIME-Version: 1.0
References: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com>
<CAAQdECAyQB0E0PxwBOxXoEtQO_HU5b3JGQpsqp_OfB8dOKqiUQ@mail.gmail.com>
<CALFqKjTHT7XaREK7ewwKKBjrZcty7ueNBMtSLEW7B-o9uwXgmw@mail.gmail.com>
In-Reply-To: <CALFqKjTHT7XaREK7ewwKKBjrZcty7ueNBMtSLEW7B-o9uwXgmw@mail.gmail.com>
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Fri, 19 Jul 2019 22:48:43 +0000
Message-ID: <CAAQdECAxdUvwSo2byukgevZF56gadMN1+P9cvH2wQMCVPrA38Q@mail.gmail.com>
To: Mike Brooks <m@ib.tc>, bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fa678d058e108733"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 20 Jul 2019 03:24:33 +0000
Subject: Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Fri, 19 Jul 2019 22:48:58 -0000
--000000000000fa678d058e108733
Content-Type: text/plain; charset="UTF-8"
Hi,
On Fri, 19 Jul 2019 at 17:49, Mike Brooks <m@ib.tc> wrote:
> Users will adopt whatever the client accepts - this feature would be
> transparent.
>
My skepticism was based in an assumption on my part that most such data is
produced by actors with a track record of neglecting transaction
efficiency. I'd be happy to be proven wrong, but considering say usage
rates of native witness outputs, or the fraction of transactions with more
than 2 outputs so far I see little evidence in support of widespread
adoption of cost saving measures. Assuming this is intended as a new script
version, all fully validating nodes need to commit to keeping all data
indefinitely before they can enforce the rules that make transactions
benefiting from this opcode safe to broadcast.
That said, if successful, the main concern is still that of address reuse -
currently there is no incentive in the protocol to do that, and with BIP32
wallets fewer reasons to do it as well, but this proposal introduces such
an incentive for users which would otherwise generate new addresses
(disregarding the ones that already reuse addresses anyway), and this is
problematic for privacy and fungibility.
Since address reuse has privacy concerns, I think it's important to draw a
distinction between clients accepting and producing such transactions, if
the latter were done transparently that would be very concerning IMO, and
even the former would not be transparent for users who run currently
pruning nodes.
I'm not sure how an O(1) time complexity leads to DoS, that seems like a
> very creative jump.
>
For what it's worth, that was in reference to hypothetical deduplication
only at the p2p layer, similar to compact blocks, but on further reflection
I'd like to retract that, as since both scenarios which I had in mind seem
easily mitigated.
Based on this response, it makes me want to calculate the savings, what
> if it was a staggering reduction in the tree size?
>
Assuming past address reuse rates are predictive this only places an upper
bound on the potential size savings, so personally I would not find that
very compelling. Even if the realized size savings would be substantial,
I'm not convinced the benefits outweigh the downsides (increased validation
costs, monotonically growing unprunable data, and direct incentive for
address reuse), especially when compared to other methods/proposals that
can reduce on chain footprint generally improve privacy while reducing
validation costs for others (e.g. batching, lightning, MAST for
sufficiently large scripts, Schnorr signatures (musig, adaptor signatures),
{tap,graft}root, ).
Regards,
Yuval
--000000000000fa678d058e108733
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi,</div><div><div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Fri, 19 Jul 2019 at 17:49, Mike Brook=
s <<a href=3D"mailto:m@ib.tc">m@ib.tc</a>> wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Users will adopt w=
hatever the client accepts - this feature would be transparent.=C2=A0<br></=
div></blockquote></div><div class=3D"gmail_quote"><br><div class=3D"gmail_q=
uote">My=20
skepticism was based in an assumption on my part that most such data is pro=
duced by actors with a track record of neglecting transaction efficiency. I=
'd be happy to be proven wrong, but considering say usage rates of nati=
ve witness outputs, or the fraction of transactions with more than 2 output=
s so far I see little evidence in support of widespread adoption of cost sa=
ving measures. Assuming this is intended as a new script version, all fully=
validating nodes need to commit to keeping all data indefinitely before th=
ey can enforce the rules that make transactions benefiting from this opcode=
safe to broadcast.</div><div class=3D"gmail_quote"><br></div><div class=3D=
"gmail_quote">That said, if successful, the main concern is still that of a=
ddress reuse - currently there is no incentive in the protocol to do that, =
and with BIP32 wallets fewer reasons to do it as well, but this proposal in=
troduces such an incentive for users which would otherwise generate new add=
resses (disregarding the ones that already reuse addresses anyway), and thi=
s is problematic for privacy and fungibility.<br></div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">Since address reuse has privacy=
concerns, I think it's important to draw a distinction between clients=
accepting and producing such transactions, if the latter were done transpa=
rently that would be very concerning IMO, and even the former would not be =
transparent for users who run currently pruning nodes.<br></div></div></div=
></div><div><div><br><div class=3D"gmail_quote"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I'm =
not sure how an O(1) time complexity leads to DoS, that seems like a very c=
reative jump.</div></blockquote><div><br></div><div class=3D"gmail_quote">F=
or what it's worth, that was in reference to hypothetical deduplication=
only at the p2p layer, similar to compact blocks, but on further reflectio=
n I'd like to retract that, as since both scenarios which I had in mind=
seem easily mitigated.<br></div><div class=3D"gmail_quote"><br></div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr">=C2=A0 Based on this response, it makes me want to calculate =
the savings, what if it was a staggering reduction in the tree size?</div><=
/blockquote></div></div></div></div><div><br><div class=3D"gmail_quote"><di=
v>Assuming past address reuse rates are predictive this only places an uppe=
r bound on the potential size savings, so personally I would not find that =
very compelling. Even if the realized size savings would be substantial, I&=
#39;m not convinced the benefits outweigh the downsides (increased validati=
on costs, monotonically growing unprunable data, and direct incentive for a=
ddress reuse), especially when compared to other methods/proposals that can=
reduce on chain footprint generally improve privacy while reducing validat=
ion costs for others (e.g. batching, lightning, MAST for sufficiently large=
scripts, Schnorr signatures (musig, adaptor signatures), {tap,graft}root, =
).</div><div><br></div><div>Regards,</div><div>Yuval<br></div></div></div><=
/div></div>
--000000000000fa678d058e108733--
|
