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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B4F992119
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jun 2018 15:45:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com
[209.85.217.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9FC6A5D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jun 2018 15:45:57 +0000 (UTC)
Received: by mail-ua0-f174.google.com with SMTP id e8-v6so10836885uam.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 09 Jun 2018 08:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=N/kRs0fANBe+hj2+DHqaFjW6YIiAXE62wFgKsO+C7uY=;
b=ChiOCIJeA4/ONNNcSAH2DR3ZX70IPdYyjGjP8/0EjpOmRQb2fLsABa41BCSr1eO/JD
Gdta9bMA46oTPbyP1KguJUUVsYNSebysl/XxHvUBWhpGkKfIWo2Wc8GFbFaXNQ+VZloB
GHegCgljZ9LOWvNpGcVvS6b2GOAJ5wtnPvEa3mzdHu6ROIr4xVrds5C7ir9R39ihxadX
42L2i3Yq9dlU2HMs1gli3sT6kWMkAeIYzBfhiZxNfbke3o03pHKdtAUQbtWoDGQ+OUM3
HY2XBE2y1c2YO2k0VIRN5+QAQ+SdLaH/5n7Cc48xUnG09PTokP1TJFhrD/JmUPxUlPlm
9TpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=N/kRs0fANBe+hj2+DHqaFjW6YIiAXE62wFgKsO+C7uY=;
b=ZpGjr9ka6DNqWMEXW+4y3GnZay2EQnrH8aCJbFasgHmYw08hw1dwixovLFCx0fe08i
qzx568YEXdFKJpzzgqPDA8KFVRZgSyuib3i6Wegmrin/KHK1sYQoshVxX0L2FZs3npdF
AkbajPLEK8Zt5+wBs4+maaCPx7giPK9rUoxIx/LPnJ1RbiEHvNWC6wfSbQWgnBvV0tp9
EuvReEE5Rj4VNQA741TIsG7lPTCC4BjNa44aOXjDgRZdIorYbwvxZnfXhthbNIZta+2q
X/dgfgDQDFwlW1uS4i2Fm/5GQZEQ77QpIzlsrzLu3K2RfjkvT+tuIBOqxIlJWLCcppxN
I+wg==
X-Gm-Message-State: APt69E3zkeelviSJd3nhIlL86HcrW4bFf2BgHwhdOG7RfqN9Di9yt0GG
1FiKqGl/dIvc3ZYpnZQsw2VX9zyPQ+O3YAbCCoU=
X-Google-Smtp-Source: ADUXVKKTjbfGzzfD6/4vaIwwk4lbo9Hre1gs+I6hQWs07zW2Q5js/q5jmtN1iZOSHey55Aht4EQWCnmPcDuIq5w2bPc=
X-Received: by 2002:a9f:2048:: with SMTP id 66-v6mr6728429uam.76.1528559156670;
Sat, 09 Jun 2018 08:45:56 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 2002:a67:5193:0:0:0:0:0 with HTTP;
Sat, 9 Jun 2018 08:45:54 -0700 (PDT)
In-Reply-To: <CAO3Pvs89_196socS-mxZpciYNO172Fiif=ncSQF0DA9n1g0+fQ@mail.gmail.com>
References: <7E4FA664-BBAF-421F-8C37-D7CE3AA5310A@gmail.com>
<F87D7069-0FDC-4572-B02B-398A2A455935@gmail.com>
<CAAS2fgT716PiP0ucoASxryM9y+s9H2z06Z0ToaP1xT3BozAtNw@mail.gmail.com>
<CADZtCSguto2z6Z9CykymxnCokqo1G=sW0Ov0ht+KcD+KMnYyow@mail.gmail.com>
<CAO3Pvs-YDzfRqmyJ85wTH0ciccjCvkm5stGyP_tVGGna=PMv3A@mail.gmail.com>
<CAO3Pvs9p5COiS_7Jbj1r2iAKTEdXUcnVTRzL27c3=CeuB9WDTQ@mail.gmail.com>
<CAAS2fgSyVi0d_ixp-auRPPzPfFeffN=hsWhWT5=EzDO3O+Ue1g@mail.gmail.com>
<CAO3Pvs_0qCZbRCfL8EJw6gzWjZeXWcJrtg27g_SJ7+PkYTHg6A@mail.gmail.com>
<CAAS2fgTs+aKyiL8Kg_AZk=Mdh6896MEg=KHa6ANAZO7unsGEsg@mail.gmail.com>
<CADZtCShyYbgKk2zsKzQniqDw--XKfYWTk3Hk3o50V=MgT6zeuQ@mail.gmail.com>
<20180602124157.744x7j4u7dqtaa43@email>
<343A3542-3103-42E9-95B7-640DFE958FFA@gmail.com>
<CAAS2fgQDdJpzPR9Ve81hhyqU+MO7Ryy125fzK-iv=sfwwORDCw@mail.gmail.com>
<37BECD1A-7515-4081-85AC-871B9FB57772@gmail.com>
<CAPg+sBjXbwTKW+qbGwJgau-Q2-uJC6N1JH8hH4KThv0Ah3WuqA@mail.gmail.com>
<CAO3Pvs9BQ2Dc9GCuJNxko_34Jx5kSOd8jxYkfpMW2E_1EOBEuQ@mail.gmail.com>
<CAAS2fgRmvqJrtk5n7e9xc-zPpDLCKa2Te_dGCk9xb9OH_AG0nw@mail.gmail.com>
<CAO3Pvs89_196socS-mxZpciYNO172Fiif=ncSQF0DA9n1g0+fQ@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Sat, 9 Jun 2018 15:45:54 +0000
X-Google-Sender-Auth: qUr2471NTbCMkv_8X9Uv3J_voGw
Message-ID: <CAAS2fgTtm0PaE=Z-eRNh_XVA-bvRAO09ijs-Twhf5ZQBNkux=g@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM,
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
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: Sat, 09 Jun 2018 15:45:58 -0000
> So what's the cost in using
> the current filter (as it lets the client verify the filter if they want to,
An example of that cost is you arguing against specifying and
supporting the design that is closer to one that would be softforked,
which increases the time until we can make these filters secure
because it slows convergence on the design of what would get
committed.
>> I don't agree at all, and I can't see why you say so.
>
> Sure it doesn't _have_ to, but from my PoV as "adding more commitments" is
> on the top of every developers wish list for additions to Bitcoin, it would
> make sense to coordinate on an "ultimate" extensible commitment once, rather
> than special case a bunch of distinct commitments. I can see arguments for
> either really.
We have an extensible commitment style via BIP141 already. I don't see
why this in particular demands a new one.
> 1. The current filter format (even moving to prevouts) cannot be committed
> in this fashion as it indexes each of the coinbase output scripts. This
> creates a circular dependency: the commitment is modified by the
> filter,
Great point, but it should probably exclude coinbase OP_RETURN output.
This would exclude the current BIP141 style commitment and likely any
other.
Should I start a new thread on excluding all OP_RETURN outputs from
BIP-158 filters for all transactions? -- they can't be spent, so
including them just pollutes the filters.
> 2. Since the coinbase transaction is the first in a block, it has the
> longest merkle proof path. As a result, it may be several hundred bytes
> (and grows with future capacity increases) to present a proof to the
If 384 bytes is a concern, isn't 3840 bytes (the filter size
difference is in this ballpark) _much_ more of a concern? Path to the
coinbase transaction increases only logarithmically so further
capacity increases are unlikely to matter much, but the filter size
increases linearly and so it should be much more of a concern.
> In regards to the second item above, what do you think of the old Tier Nolan
> proposal [1] to create a "constant" sized proof for future commitments by
> constraining the size of the block and placing the commitments within the
> last few transactions in the block?
I think it's a fairly ugly hack. esp since it requires that mining
template code be able to stuff the block if they just don't know
enough actual transactions-- which means having a pool of spendable
outputs in order to mine, managing private keys, etc... it also
requires downstream software not tinker with the transaction count
(which I wish it didn't but as of today it does). A factor of two
difference in capacity-- if you constrain to get the smallest possible
proof-- is pretty stark, optimal txn selection with this cardinality
constraint would be pretty weird. etc.
If the community considers tree depth for proofs like that to be such
a concern to take on technical debt for that structure, we should
probably be thinking about more drastic (incompatible) changes... but
I don't think it's actually that interesting.
> I don't think its fair to compare those that wish to implement this proposal
> (and actually do the validation) to the legacy SPV software that to my
> knowledge is all but abandoned. The project I work on that seeks to deploy
Yes, maybe it isn't. But then that just means we don't have good information.
When a lot of people were choosing electrum over SPV wallets when
those SPV wallets weren't abandoned, sync time was frequently cited as
an actual reason. BIP158 makes that worse, not better. So while I'm
hopeful, I'm also somewhat sceptical. Certainly things that reduce
the size of the 158 filters make them seem more likely to be a success
to me.
> too difficult to implement "full" validation, as they're bitcoin developers
> with quite a bit of experience.
::shrugs:: Above you're also arguing against fetching down to the
coinbase transaction to save a couple hundred bytes a block, which
makes it impossible to validate a half dozen other things (including
as mentioned in the other threads depth fidelity of returned proofs).
There are a lot of reasons why things don't get implemented other than
experience! :)
|
