diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2019-07-27 12:10:03 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-07-27 16:10:08 +0000 |
| commit | 56807692e0ccd4c0b96d724ad146c969dd837f2d (patch) | |
| tree | 7c06509f2fcbfe56d885b419dc2fcf65ba9ad65f | |
| parent | 7e56bf695361e55787c0cbd9bbbed6cdd551371c (diff) | |
| download | pi-bitcoindev-56807692e0ccd4c0b96d724ad146c969dd837f2d.tar.gz pi-bitcoindev-56807692e0ccd4c0b96d724ad146c969dd837f2d.zip | |
Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default
| -rw-r--r-- | 88/99ccd1ba04d4b1d98ef88da6964c525eeff309 | 447 |
1 files changed, 447 insertions, 0 deletions
diff --git a/88/99ccd1ba04d4b1d98ef88da6964c525eeff309 b/88/99ccd1ba04d4b1d98ef88da6964c525eeff309 new file mode 100644 index 000000000..4bae79294 --- /dev/null +++ b/88/99ccd1ba04d4b1d98ef88da6964c525eeff309 @@ -0,0 +1,447 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F1AE7F6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 27 Jul 2019 16:10:08 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mail.bluematt.me (mail.bluematt.me [69.59.18.99]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35668FE + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 27 Jul 2019 16:10:05 +0000 (UTC) +Received: from [192.168.1.67] (unknown [69.59.18.155]) + by mail.bluematt.me (Postfix) with ESMTPSA id 8CA3082CA3; + Sat, 27 Jul 2019 16:10:03 +0000 (UTC) +Content-Type: multipart/alternative; + boundary=Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40 +Mime-Version: 1.0 (1.0) +From: Matt Corallo <lf-lists@mattcorallo.com> +X-Mailer: iPhone Mail (16G77) +In-Reply-To: <0DD0A8C8-374E-4E4F-AB08-C51612A28E16@jonasschnelli.ch> +Date: Sat, 27 Jul 2019 12:10:03 -0400 +Content-Transfer-Encoding: 7bit +Message-Id: <4661BB32-3725-4E10-9698-25CDBA2F7ACB@mattcorallo.com> +References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com> + <qh2qj1$7sg4$1@blaine.gmane.org> <qh76ln$41ag$1@blaine.gmane.org> + <0DD0A8C8-374E-4E4F-AB08-C51612A28E16@jonasschnelli.ch> +To: Jonas Schnelli <dev@jonasschnelli.ch>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, + MIME_QP_LONG_LINE 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, 27 Jul 2019 20:17:43 +0000 +Cc: Andreas Schildbach <andreas@schildbach.de> +Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by + default +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, 27 Jul 2019 16:10:08 -0000 + + +--Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40 +Content-Type: text/plain; + charset=utf-8 +Content-Transfer-Encoding: quoted-printable + +This conversation went off the rails somewhat. I don't think there's any imm= +ediate risk of NODE_BLOOM peers being unavailable. This is a defaults change= +, not a removal of the code to serve BIP 37 peers (nor would I suggest remov= +ing said code while people still want to use them - the maintenance burden i= +sn't much). Looking at historical upgrade cycles, ignoring any other factors= +, there will be a large number of nodes serving NODE_BLOOM for many years. + +Even more importantly, if you need them, run a node or two. As long as no on= +e is exploiting the issues with them such a node isn't *too* expensive. Or d= +on't, I guarantee you chainanalysis or some competitor of theirs will very v= +ery happily serve bloom-filtered clients as long as such clients want to dea= +nonymize themselves. We already see a plurality of nodes on the network are c= +learly not run-of-the-mill Core nodes, many of which are likely deanonimizat= +ion efforts. + +In some cases BIP 137 is a replacement, in some cases, indeed, it is not. I a= +gree at a protocol level we shouldn't be passing judgement about how users w= +ish to interact with the Bitcoin system (aside from not putting our own, per= +sonal, effort into building such things) but that isn't what's happening her= +e. This is an important DoS fix for the average node, and I don't really und= +erstand the argument that this is going to break existing BIP 37 wallets, bu= +t if it makes you feel any better I can run some beefy BIP 37 nodes. + +Matt + +> On Jul 26, 2019, at 06:04, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lis= +ts.linuxfoundation.org> wrote: +>=20 +>=20 +>> 1) It causes way too much traffic for mobile users, and likely even too +>> much traffic for fixed lines in not so developed parts of the world. +>=20 +> Yes. It causes more traffic than BIP37. +> Basic block filters for current last ~7 days (1008 blocks) are about 19MB (= +just the filters). +> On top, you will probably fetch a handful of irrelevant blocks due to the = +FPs and due to true relevant txns. +> A over-the-thumb estimation: ~25MB per week of catch-up. +> If you where offline for a month: ~108MB +>=20 +> Thats certainly more then BIP37 BF (measured 1.6MB total traffic with andr= +oid schildbach wallet restore blockchain for 8 week [7 weeks headers, 1week m= +erkleblocks]). +>=20 +> But lets look at it like this: for an additional, say 25MB per week (maybe= + a bit more), you get the ability to filter blocks without depending on serv= +ing peers who may compromise your financial privacy. +> Also, if you keep the filters, further rescans do consume the same or less= + bandwidth than BF BIP37. +> In other words: you have the chance to potentially increase privacy by con= +suming bandwidth in the range of a single audio podcast per week. +>=20 +> I would say the job of protocol developers is protect users privacy where i= +t=E2=80=99s possible (as a default). +> It=E2=80=99s probably a debatable point wether 25MB per week of traffic is= + worth a potential increase in privacy, though I absolutely think 25MB/week i= +s an acceptable tradeoff. +> Saving traffic is possible by using BIP37 or stratum/electrum=E2=80=A6 but= + developers should make sure users are __warned about the consequences__! +>=20 +> Additionally, it looks like, peer operators are not endless being willing t= +o serve =E2=80=93 for free =E2=80=93 a CPU/disk intense service with no bene= +fits for the network. I would question wether a decentralised form of BIP37 i= +s sustainable in the long run (if SPV wallet provider bootstrap a net range o= +f NODE_BLOOM peers to make it more reliable on the network would be snake-oi= +l). +>=20 +>=20 +>>=20 +>> 2) It filters blocks only. It doesn't address unconfirmed transactions. +>=20 +> Well, unconfirmed transaction are uncertain for various reasons. +>=20 +> BIP158 won't allow you to filter the mempool. +> But as soon as you are connected to the network, you may fetch tx with inv= +/getdata and pick out the relevant ones (causes also traffic). +> Unclear and probably impossible with the current BIP158 specs to fetch tra= +nsactions that are not in active relay and are not in a block (mempool txns,= + at least this is true with the current observed relay tactics). +>=20 +>=20 +>> 3) Afaik, it enforces/encourages address re-use. This stems from the +>> fact that the server decides on the filter and in particular on the +>> false positive rate. On wallets with many addresses, a hardcoded filter +>> will be too blurry and thus each block will be matched. So wallets that +>> follow the "one address per incoming payment" pattern (e.g. HD wallets) +>> at some point will be forced to wrap their key chains back to the +>> beginning. If I'm wrong on this one please let me know. +>=20 +> I=E2=80=99m probably the wrong guy to ask (haven=E2=80=99t made the number= +s) but last time I rescanned a Core wallet (in my dev branch) with block fil= +ters (and a Core wallet has >2000 addresses by default) it fetched a low and= + acceptable amount of false positive blocks. +> (Maybe someone who made the numbers step in here.) +>=20 +> Though, large wallets =E2=80=93 AFAIK =E2=80=93 also operate badly with BI= +P37. +>=20 +>>=20 +>> 4) The filters are not yet committed to the blockchain. Until that +>> happens we'd have to trust a server to provide correct filters. +>=20 +> I wouldn=E2=80=99t say so. It=E2=80=99s on a similar level than BIP37. +> BIP37 is not =E2=80=93 and can not =E2=80=93 be committed to the blockchai= +n. +> You fully trust the peer that it won=E2=80=99t=E2=80=A6 +> a) create fake unconfirmed transactions (would be the same if a BIP158 wal= +let would show you unconfirmed transaction) +> b) lies by omission (you will miss relevant transactions, eventually swipe= + your wallet and loose coins) +>=20 +> IMO, the point b) is true for BIP37 and BIP158 (as long as not commited). +> In both cases, you can reduce the trust by comparing between peers / filte= +r-providers. +>=20 +> b) is conceptually solvable with a soft-fork (commitment) in BIP158 (not w= +ith BIP37). +>=20 +> Additionally, block-filters will, very likely, be useful for other feature= +s (load/rescan an [old] wallet on a prune peer that has the filters construc= +ted). +>=20 +>=20 +>=20 +> There is probably no clear answer like =E2=80=9EX is better than Y=E2=80=9C= +. +>=20 +> Personally I would like to see developers being more honest/transparent to= + users about the implications of the used filtering,... and giving them choi= +ces. +> Imagine a user can choose between =E2=80=9EElectrum / BIP37 / BIP158=E2=80= +=9C depending on his needs for privacy and availability of bandwidth. Eventu= +ally also taking the future usage of this wallet (will he load old private k= +eys, will he receive money daily, etc.) into account. +>=20 +> Plus, full node hardware appliances that run at home (or in a trusted envi= +ronment) are solving many of these issues plus adding a bunch of great featu= +res =E2=80=93 if done right. +>=20 +> /jonas +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + +--Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40 +Content-Type: text/html; + charset=utf-8 +Content-Transfer-Encoding: quoted-printable + +<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= +utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">Thi= +s conversation went off the rails somewhat. I don't think there's any immedi= +ate risk of NODE_BLOOM peers being unavailable. This is a defaults change, n= +ot a removal of the code to serve BIP 37 peers (nor would I suggest removing= + said code while people still want to use them - the maintenance burden isn'= +t much). Looking at historical upgrade cycles, ignoring any other factors, t= +here will be a large number of nodes serving NODE_BLOOM for many years.</div= +><div dir=3D"ltr"><br></div><div dir=3D"ltr">Even more importantly, if you n= +eed them, run a node or two. As long as no one is exploiting the issues with= + them such a node isn't *too* expensive. Or don't, I guarantee you chainanal= +ysis or some competitor of theirs will very very happily serve bloom-filtere= +d clients as long as such clients want to deanonymize themselves. We already= + see a plurality of nodes on the network are clearly not run-of-the-mill Cor= +e nodes, many of which are likely deanonimization efforts.</div><div dir=3D"= +ltr"><br></div><div dir=3D"ltr">In some cases BIP 137 is a replacement, in s= +ome cases, indeed, it is not. I agree at a protocol level we shouldn't be pa= +ssing judgement about how users wish to interact with the Bitcoin system (as= +ide from not putting our own, personal, effort into building such things) bu= +t that isn't what's happening here. This is an important DoS fix for the ave= +rage node, and I don't really understand the argument that this is going to b= +reak existing BIP 37 wallets, but if it makes you feel any better I can run s= +ome beefy BIP 37 nodes.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Mat= +t</div><div dir=3D"ltr"><br>On Jul 26, 2019, at 06:04, Jonas Schnelli via bi= +tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= +in-dev@lists.linuxfoundation.org</a>> wrote:<br><br></div><blockquote typ= +e=3D"cite"><div dir=3D"ltr"><meta http-equiv=3D"Content-Type" content=3D"tex= +t/html; charset=3Dutf-8"><br class=3D""><div><blockquote type=3D"cite" class= +=3D""><div class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family:= + Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; f= +ont-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0= +px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-te= +xt-stroke-width: 0px; text-decoration: none; float: none; display: inline !i= +mportant;" class=3D"">1) It causes way too much traffic for mobile users, an= +d likely even too</span><br style=3D"caret-color: rgb(0, 0, 0); font-family:= + Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; f= +ont-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0= +px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-te= +xt-stroke-width: 0px; text-decoration: none;" class=3D""><span style=3D"care= +t-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: n= +ormal; font-variant-caps: normal; font-weight: normal; letter-spacing: norma= +l; text-align: start; text-indent: 0px; text-transform: none; white-space: n= +ormal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: n= +one; float: none; display: inline !important;" class=3D"">much traffic for f= +ixed lines in not so developed parts of the world.</span><br style=3D"caret-= +color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: no= +rmal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal= +; text-align: start; text-indent: 0px; text-transform: none; white-space: no= +rmal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: no= +ne;" class=3D""></div></blockquote><div><br class=3D""></div><div>Yes. It ca= +uses more traffic than BIP37.</div><div>Basic block filters for current last= + ~7 days (1008 blocks) are about 19MB (just the filters).</div><div>On top, y= +ou will probably fetch a handful of irrelevant blocks due to the FPs and due= + to true relevant txns.</div><div>A over-the-thumb estimation: ~25MB per wee= +k of catch-up.</div><div>If you where offline for a month: ~108MB</div><div>= +<br class=3D""></div><div>Thats certainly more then BIP37 BF (measured 1.6MB= + total traffic with android schildbach wallet restore blockchain for 8 week [= +7 weeks headers, 1week merkleblocks]).</div><div><br class=3D""></div><div>B= +ut lets look at it like this: for an additional, say 25MB per week (maybe a b= +it more), you get the ability to filter blocks without depending on serving p= +eers who may compromise your financial privacy.</div><div>Also, if you keep t= +he filters, further rescans do consume the same or less bandwidth than BF BI= +P37.</div><div>In other words: you have the chance to potentially increase p= +rivacy by consuming bandwidth in the range of a single audio podcast per wee= +k.</div><div><br class=3D""></div><div>I would say the job of protocol devel= +opers is protect users privacy where it=E2=80=99s possible (as a default).</= +div><div>It=E2=80=99s probably a debatable point wether 25MB per week of tra= +ffic is worth a potential increase in privacy, though I absolutely think 25M= +B/week is an acceptable tradeoff.</div><div>Saving traffic is possible by us= +ing BIP37 or stratum/electrum=E2=80=A6 but developers should make sure users= + are __warned about the consequences__!</div><div><br class=3D""></div><div>= +Additionally, it looks like, peer operators are not endless being willing to= + serve =E2=80=93 for free =E2=80=93 a CPU/disk intense service with no benef= +its for the network. I would question wether a decentralised form of BIP37 i= +s sustainable in the long run (if SPV wallet provider bootstrap a net range o= +f NODE_BLOOM peers to make it more reliable on the network would be snake-oi= +l).</div><div><br class=3D""></div><br class=3D""><blockquote type=3D"cite" c= +lass=3D""><div class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-famil= +y: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal= +; font-weight: normal; letter-spacing: normal; text-align: start; text-inden= +t: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webki= +t-text-stroke-width: 0px; text-decoration: none;" class=3D""><span style=3D"= +caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-sty= +le: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: n= +ormal; text-align: start; text-indent: 0px; text-transform: none; white-spac= +e: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoratio= +n: none; float: none; display: inline !important;" class=3D"">2) It filters b= +locks only. It doesn't address unconfirmed transactions.</span><br style=3D"= +caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-sty= +le: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: n= +ormal; text-align: start; text-indent: 0px; text-transform: none; white-spac= +e: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoratio= +n: none;" class=3D""></div></blockquote><div><br class=3D""></div>Well, unco= +nfirmed transaction are uncertain for various reasons.</div><div><br class=3D= +""></div><div>BIP158 won't allow you to filter the mempool.</div><div>But as= + soon as you are connected to the network, you may fetch tx with inv/getdata= + and pick out the relevant ones (causes also traffic).</div><div>Unclear and= + probably impossible with the current BIP158 specs to fetch transactions tha= +t are not in active relay and are not in a block (mempool txns, at least thi= +s is true with the current observed relay tactics).</div><div><div><br class= +=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D= +""><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-si= +ze: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal= +; letter-spacing: normal; text-align: start; text-indent: 0px; text-transfor= +m: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0= +px; text-decoration: none; float: none; display: inline !important;" class=3D= +"">3) Afaik, it enforces/encourages address re-use. This stems from the</spa= +n><br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= + 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; l= +etter-spacing: normal; text-align: start; text-indent: 0px; text-transform: n= +one; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;= + text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0)= +; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-= +caps: normal; font-weight: normal; letter-spacing: normal; text-align: start= +; text-indent: 0px; text-transform: none; white-space: normal; word-spacing:= + 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; di= +splay: inline !important;" class=3D"">fact that the server decides on the fi= +lter and in particular on the</span><br style=3D"caret-color: rgb(0, 0, 0); f= +ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant-cap= +s: normal; font-weight: normal; letter-spacing: normal; text-align: start; t= +ext-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0p= +x; -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span s= +tyle=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; f= +ont-style: normal; font-variant-caps: normal; font-weight: normal; letter-sp= +acing: normal; text-align: start; text-indent: 0px; text-transform: none; wh= +ite-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-d= +ecoration: none; float: none; display: inline !important;" class=3D"">false p= +ositive rate. On wallets with many addresses, a hardcoded filter</span><br s= +tyle=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; f= +ont-style: normal; font-variant-caps: normal; font-weight: normal; letter-sp= +acing: normal; text-align: start; text-indent: 0px; text-transform: none; wh= +ite-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-d= +ecoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-= +family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: n= +ormal; font-weight: normal; letter-spacing: normal; text-align: start; text-= +indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -= +webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: i= +nline !important;" class=3D"">will be too blurry and thus each block will be= + matched. So wallets that</span><br style=3D"caret-color: rgb(0, 0, 0); font= +-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: n= +ormal; font-weight: normal; letter-spacing: normal; text-align: start; text-= +indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -= +webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span styl= +e=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; fon= +t-style: normal; font-variant-caps: normal; font-weight: normal; letter-spac= +ing: normal; text-align: start; text-indent: 0px; text-transform: none; whit= +e-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-dec= +oration: none; float: none; display: inline !important;" class=3D"">follow t= +he "one address per incoming payment" pattern (e.g. HD wallets)</span><br st= +yle=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; f= +ont-style: normal; font-variant-caps: normal; font-weight: normal; letter-sp= +acing: normal; text-align: start; text-indent: 0px; text-transform: none; wh= +ite-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-d= +ecoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-= +family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: n= +ormal; font-weight: normal; letter-spacing: normal; text-align: start; text-= +indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -= +webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: i= +nline !important;" class=3D"">at some point will be forced to wrap their key= + chains back to the</span><br style=3D"caret-color: rgb(0, 0, 0); font-famil= +y: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal= +; font-weight: normal; letter-spacing: normal; text-align: start; text-inden= +t: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webki= +t-text-stroke-width: 0px; text-decoration: none;" class=3D""><span style=3D"= +caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-sty= +le: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: n= +ormal; text-align: start; text-indent: 0px; text-transform: none; white-spac= +e: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoratio= +n: none; float: none; display: inline !important;" class=3D"">beginning. If I= +'m wrong on this one please let me know.</span><br style=3D"caret-color: rgb= +(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font= +-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-ali= +gn: start; text-indent: 0px; text-transform: none; white-space: normal; word= +-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class= +=3D""></div></blockquote><div><br class=3D""></div><div>I=E2=80=99m probably= + the wrong guy to ask (haven=E2=80=99t made the numbers) but last time I res= +canned a Core wallet (in my dev branch) with block filters (and a Core walle= +t has >2000 addresses by default) it fetched a low and acceptable amount o= +f false positive blocks.</div><div>(Maybe someone who made the numbers step i= +n here.)</div><div><br class=3D""></div><div>Though, large wallets =E2=80=93= + AFAIK =E2=80=93 also operate badly with BIP37.</div><br class=3D""><blockqu= +ote type=3D"cite" class=3D""><div class=3D""><br style=3D"caret-color: rgb(0= +, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-v= +ariant-caps: normal; font-weight: normal; letter-spacing: normal; text-align= +: start; text-indent: 0px; text-transform: none; white-space: normal; word-s= +pacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D= +""><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-si= +ze: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal= +; letter-spacing: normal; text-align: start; text-indent: 0px; text-transfor= +m: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0= +px; text-decoration: none; float: none; display: inline !important;" class=3D= +"">4) The filters are not yet committed to the blockchain. Until that</span>= +<br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= +2px; font-style: normal; font-variant-caps: normal; font-weight: normal; let= +ter-spacing: normal; text-align: start; text-indent: 0px; text-transform: no= +ne; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; t= +ext-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); f= +ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant-cap= +s: normal; font-weight: normal; letter-spacing: normal; text-align: start; t= +ext-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0p= +x; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; displ= +ay: inline !important;" class=3D"">happens we'd have to trust a server to pr= +ovide correct filters.</span><br style=3D"caret-color: rgb(0, 0, 0); font-fa= +mily: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: nor= +mal; font-weight: normal; letter-spacing: normal; text-align: start; text-in= +dent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -we= +bkit-text-stroke-width: 0px; text-decoration: none;" class=3D""></div></bloc= +kquote><br class=3D""></div><div>I wouldn=E2=80=99t say so. It=E2=80=99s on a= + similar level than BIP37.</div><div>BIP37 is not =E2=80=93 and can not =E2=80= +=93 be committed to the blockchain.</div><div>You fully trust the peer that i= +t won=E2=80=99t=E2=80=A6</div><div>a) create fake unconfirmed transactions (= +would be the same if a BIP158 wallet would show you unconfirmed transaction)= +</div><div>b) lies by omission (you will miss relevant transactions, eventua= +lly swipe your wallet and loose coins)</div><div><br class=3D""></div><div>I= +MO, the point b) is true for BIP37 and BIP158 (as long as not commited).</di= +v><div>In both cases, you can reduce the trust by comparing between peers / f= +ilter-providers.</div><div><br class=3D""></div><div>b) is conceptually solv= +able with a soft-fork (commitment) in BIP158 (not with BIP37).</div><div><br= + class=3D""></div><div>Additionally, block-filters will, very likely, be use= +ful for other features (load/rescan an [old] wallet on a prune peer that has= + the filters constructed).</div><div><br class=3D""></div><div><br class=3D"= +"></div><div><br class=3D""></div><div>There is probably no clear answer lik= +e =E2=80=9EX is better than Y=E2=80=9C.</div><div><br class=3D""></div><div>= +Personally I would like to see developers being more honest/transparent to u= +sers about the implications of the used filtering,... and giving them choice= +s.</div><div>Imagine a user can choose between =E2=80=9EElectrum / BIP37 / B= +IP158=E2=80=9C depending on his needs for privacy and availability of bandwi= +dth. Eventually also taking the future usage of this wallet (will he load ol= +d private keys, will he receive money daily, etc.) into account.</div><div><= +br class=3D""></div><div>Plus, full node hardware appliances that run at hom= +e (or in a trusted environment) are solving many of these issues plus adding= + a bunch of great features =E2=80=93 if done right.</div><div><br class=3D""= +></div><div>/jonas</div></div></blockquote><blockquote type=3D"cite"><div di= +r=3D"ltr"><span>_______________________________________________</span><br><s= +pan>bitcoin-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@l= +ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><b= +r><span><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoi= +n-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></s= +pan><br></div></blockquote></body></html>= + +--Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40-- + |