From: Dustin Dettmer <dustinpaystaxes@gmail.com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Tom Harding <tomh@thinlink.com>
Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default
Date: Mon, 22 Jul 2019 08:15:49 -0700 [thread overview]
Message-ID: <CABLeJxSrie0jpPmb6WsFJZg9esyS8bmug7F=tN2bm2f=FHruKw@mail.gmail.com> (raw)
In-Reply-To: <d02da3a7-5afe-4a3f-0ed0-464751a6aff1@thinlink.com>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
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 — 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
>
[-- Attachment #2: Type: text/html, Size: 1908 bytes --]
next prev parent reply other threads:[~2019-07-22 15:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-20 17:46 [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default Matt Corallo
2019-07-21 22:56 ` Andreas Schildbach
2019-07-22 5:01 ` Matt Corallo
2019-07-22 15:58 ` Justus Ranvier
2019-07-26 7:45 ` Tamas Blummer
2019-07-22 8:32 ` Peter Todd
2019-07-22 13:25 ` Jonas Schnelli
2019-07-22 17:17 ` Luke Dashjr
2019-07-22 17:26 ` Luke Dashjr
2019-07-23 14:47 ` Andreas Schildbach
2019-07-24 13:11 ` Justus Ranvier
2019-07-25 3:04 ` Luke Dashjr
2019-07-26 10:04 ` Jonas Schnelli
2019-07-27 16:10 ` Matt Corallo
2019-07-26 16:48 ` Chris
2019-07-27 19:19 ` Luke Dashjr
2019-07-22 15:04 ` Tom Harding
2019-07-22 15:15 ` Dustin Dettmer [this message]
[not found] ` <FF0175BF-1D1F-4AD4-9B13-99D522DBCD83@bridge21.com>
2019-08-14 15:07 ` Matt Corallo
2019-07-22 18:52 Peter
2019-07-22 20:42 ` Greg Sanders
2019-07-22 21:17 ` Luke Dashjr
2019-07-23 20:36 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABLeJxSrie0jpPmb6WsFJZg9esyS8bmug7F=tN2bm2f=FHruKw@mail.gmail.com' \
--to=dustinpaystaxes@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tomh@thinlink.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox