MIME-Version: 1.0
References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com>
	<d02da3a7-5afe-4a3f-0ed0-464751a6aff1@thinlink.com>
In-Reply-To: <d02da3a7-5afe-4a3f-0ed0-464751a6aff1@thinlink.com>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Mon, 22 Jul 2019 08:15:49 -0700
Message-ID: <CABLeJxSrie0jpPmb6WsFJZg9esyS8bmug7F=tN2bm2f=FHruKw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary="000000000000cd3be6058e468dd7"
Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by
	default
Precedence: list

--000000000000cd3be6058e468dd7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Has someone built an analysis of how much extra bandwidth CFB uses over
bloom filters?

Obviously an active merchant in an impoverished country paying data rates
per MB will never be able to afford CFB =E2=80=94 so those people are being=
 cut out
of Bitcoin entirely. I suppose the plan is they will rely on custodial
services now?

But if someone receives say, 5 tx a day, how much more bandwidth precisely
will CFB require over bloom?

On Mon, Jul 22, 2019 at 8:10 AM Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 7/20/19 10:46 AM, Matt Corallo via bitcoin-dev wrote:
> > (less trustful and privacy-violating) alternative
> > over the coming years.
>
> The same paper that established the 'privacy-violating' conventional
> wisdom presented mitigations which have seen little exploration.
> https://eprint.iacr.org/2014/763.pdf
>
> Meanwhile we have custodial LN, the L-BTC altcoin and, today, a massive
> push into infrastructure for fully custodial accounts.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000cd3be6058e468dd7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Has someone built an analysis of how much extra band=
width CFB uses over bloom filters?</div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Obviously an active merchant in an impoverished country pa=
ying data rates per MB will never be able to afford CFB =E2=80=94 so those =
people are being cut out of Bitcoin entirely. I suppose the plan is they wi=
ll rely on custodial services now?</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">But if someone receives say, 5 tx a day, how much more bandwidth=
 precisely will CFB require over bloom?</div><div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 22, 2019 at 8:10 AM=
 Tom Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">On 7/20/19 10:46 AM, Matt Corallo via bitc=
oin-dev wrote:<br>
&gt; (less trustful and privacy-violating) alternative<br>
&gt; over the coming years.<br>
<br>
The same paper that established the &#39;privacy-violating&#39; conventiona=
l <br>
wisdom presented mitigations which have seen little exploration. <br>
<a href=3D"https://eprint.iacr.org/2014/763.pdf" rel=3D"noreferrer" target=
=3D"_blank">https://eprint.iacr.org/2014/763.pdf</a><br>
<br>
Meanwhile we have custodial LN, the L-BTC altcoin and, today, a massive <br=
>
push into infrastructure for fully custodial accounts.<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000cd3be6058e468dd7--