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
|
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 F19612A3A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jul 2019 17:45:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com
[209.85.214.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BD0EFE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jul 2019 17:45:29 +0000 (UTC)
Received: by mail-pl1-f181.google.com with SMTP id c14so15914640plo.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jul 2019 10:45:29 -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=xw2nvw1qGODzFrRkThiwfSyKrkOMykCeE0sD9W/AfIg=;
b=YK93R1haa5cO0EL30TFyid8+NidOhHLanfkbv/mtQsFTPlYbDAuPxKHrpDE08vOsjy
h9bfEogW+WHWM0fTpwgnIG0DPPli4tq4EpA7fWaq4J7QnfPsshrPSuj2VyktBI7WiNGt
YaEtdikpdAJmkGieNBYC456mXGmZ82N/M4HZ4=
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=xw2nvw1qGODzFrRkThiwfSyKrkOMykCeE0sD9W/AfIg=;
b=dl0/HYxcNw6sF0BrLDBTMElbTv3GAvphj4Gndqm+mnx5Ek3J7teBZtH/+gfZHd+yVk
FvHTSF64VDc+AvxCVwqTPUJIi2FCCBzOUkmFRSIst6ytMuilX4eDaBJ8HZFHMzc5zdyg
yJGFXrcY0X5AVZijQo41v++MVO1JSkR9grR5RO5p1Hq15LyyN/r2LbjRZSAeuCcU8vf4
a3SBbLd8Y+SsaJn5iG/jiVVeDShaUC7r1YfBYHU69auDTPwYoq2dCZkf9z92CYQQOqzS
O4bpSlo9483CZp7IktyiYoKmrH9XtD3odGv0Ko1j2VjbpsVGSwlie5Ujt9ARCiLCy3AW
fowA==
X-Gm-Message-State: APjAAAXxHozReUV3BIwufY4LoQE72YORXF/qYS/g6NH2qWYX8KH3Fe/K
aU4B8GKR3+CAMEa2Sk/NsSY/X4U4qwRFLN1XEe7O/KX6
X-Google-Smtp-Source: APXvYqzXDTKvcCCMKLCN8ezaGduUtCr719hbF5gH9N1vdaHQEreCXlSkxWtJZzMza2GzZMn9qzjnMVlob92wW6fgQRo=
X-Received: by 2002:a17:902:44e:: with SMTP id
72mr58113510ple.326.1563558328967;
Fri, 19 Jul 2019 10:45:28 -0700 (PDT)
MIME-Version: 1.0
References: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com>
In-Reply-To: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com>
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Fri, 19 Jul 2019 17:45:17 +0000
Message-ID: <CAAQdECAyQB0E0PxwBOxXoEtQO_HU5b3JGQpsqp_OfB8dOKqiUQ@mail.gmail.com>
To: Mike Brooks <m@ib.tc>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c8b7bd058e0c4a4b"
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: Fri, 19 Jul 2019 19:12:50 +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 17:45:30 -0000
--000000000000c8b7bd058e0c4a4b
Content-Type: text/plain; charset="UTF-8"
Hi,
On Fri, 19 Jul 2019 at 14:00, Mike Brooks via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Giving scripts the ability to refer to data on the blockchain will reduce
> transaction sizes because key material does not have to be repeated in
> every Script.
>
Given that address reuse is discouraged, and as far as I know is
predominantly utilized for customer deposit addresses by exchanges, many of
which have not invested resources in batching withdrawals or consolidating
small UTXOs, I am skeptical that such a feature would actually be utilized
by users for whom a potential use exists, especially as mining fees are
usually pushed onto customers anyway.
Unless extensively utilized such that costs outweigh benefits, this change
would impose an externality on validating nodes:
With this list a newly created script can refer to a specific PUSHDATA that
> was used in any previously confirmed block.
>
This would make pruning impossible, and also relaxes the bounds on
validation costs since it would allow random reads on all historical data
as opposed to just the UTXO set.
Although it would do nothing for block capacity, perhaps this redundancy
might be better addressed as opt-in functionality in the p2p layer? It
might help with IBD, though at least in my experience peer latency (as
opposed to throughput) is the limiting factor, and as far as I can tell
this would increase it. Somewhat relatedly, transaction IDs are another
type of pointer which might benefit from being encoded as a (block height,
offset). However, here too it seems to me like the complexity is
substantial, potentially introducing new DoS vectors, while saving several
bytes per input at most.
Regards,
Yuval
--000000000000c8b7bd058e0c4a4b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, 19 Jul 2019 at 14:00, Mike Brooks via bitcoi=
n-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>> wrote:<br></div><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><p dir=3D"ltr" style=3D"l=
ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:=
11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-v=
ariant-numeric:normal;font-variant-east-asian:normal;vertical-align:baselin=
e;white-space:pre-wrap">Giving scripts the ability to refer to data on the =
blockchain will reduce transaction sizes because key material does not have=
to be repeated in every Script.</span></p></div></blockquote><div><br></di=
v><div>Given that address reuse is discouraged, and as far as I know is pre=
dominantly utilized for customer deposit addresses by exchanges, many of wh=
ich have not invested resources in batching withdrawals or consolidating sm=
all UTXOs, I am skeptical that such a feature would actually be utilized by=
users for whom a potential use exists, especially as mining fees are usual=
ly pushed onto customers anyway.</div><div><br></div><div>Unless extensivel=
y utilized such that costs outweigh benefits, this change would impose an e=
xternality on validating nodes:<br></div><div><br></div><div><div><div clas=
s=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 di=
r=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo=
ttom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);=
background-color:transparent;font-variant-numeric:normal;font-variant-east-=
asian:normal;vertical-align:baseline;white-space:pre-wrap">With this list a=
newly created script can refer to a specific PUSHDATA that was used in any=
previously confirmed block.</span></p></div></blockquote></div><br><div cl=
ass=3D"gmail_quote">This
would make pruning impossible, and also relaxes=20
the bounds on validation costs since it would allow random reads on=20
all historical data as opposed to just the UTXO set.<br></div></div></div><=
div><br></div></div><div class=3D"gmail_quote">Although it would do nothing=
for block capacity, perhaps this redundancy might be better addressed as o=
pt-in functionality in the p2p layer? It might help with IBD, though at lea=
st in my experience peer latency (as opposed to throughput) is the limiting=
factor, and as far as I can tell this would increase it. Somewhat relatedl=
y, transaction IDs are another type of pointer which might benefit from bei=
ng encoded as a (block height, offset). However, here too it seems to me li=
ke the complexity is substantial, potentially introducing new DoS vectors, =
while saving several bytes per input at most.</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote">Regards,</div><div class=3D"gmail_q=
uote">Yuval<br></div></div></div>
--000000000000c8b7bd058e0c4a4b--
|
