You very clearly didn't bother to read other mails in this thread. To make it
easy for you, here's a few links:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017147.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017175.html
Matt
> On Aug 13, 2019, at
On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote:
> 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
This conversation went off the rails somewhat. I don't think there's any
immediate 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
removing said code while people still want to use them - the maintenance
On 7/23/19 10:47 AM, Andreas Schildbach via bitcoin-dev wrote:
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
> 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.
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
Hi Justus,
It might be helpful to consult the Rust implementation of BIP158 here:
https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/bip158.rs
It has a cleaner structure than Core or Neutrino, includes server and client
side
and passes Core's test vectors.
Regards,
Tamas
On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote:
> > the DNS seed infrastructure among others can easily direct
> > wallets to those nodes
>
> Last I checked none of the seeds did. But I agree this would be nice to
> have.
It's supported by default in sipa's
On 7/23/19 9:47 AM, Andreas Schildbach via bitcoin-dev wrote:
> BIP 157/158 is not an alternative to BIP 37:
They complement each other pretty well though.
Wallets can save the deterministic GCS filters in the same way as
headers, which means blocks can be re-scanned if necessary (importing
new
On Mon, Jul 22, 2019 at 02:52:10PM -0400, Peter via bitcoin-dev wrote:
> Hi,
>
> I believe two wallets. Andreas' Android Bitcoin wallet and BRD are
> significant users of node_bloom.
>
> Privacy is a matter of individual choice in the current protocol. Why not
> let people provide this network
(Rather than replying individually, I try to address questions and add
my remarks in one post.)
> Finally, regarding alternatives, the filter-generation code for
> BIP 157/158 has been in Bitcoin Core for some time, though the
> P2P serving side of things appears to have lost any champions
>
On Monday 22 July 2019 18:52:10 Peter via bitcoin-dev wrote:
> Privacy is a matter of individual choice in the current protocol. Why not
> let people provide this network service? I don't see why it should be
> end-of-life if it provides value.
It's not EOL, just disabled by default. Anyone can
People are allowed the choice, it's a change of default only.
On Mon, Jul 22, 2019 at 4:41 PM Peter via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
>
> I believe two wallets. Andreas' Android Bitcoin wallet and BRD are
> significant users of node_bloom.
>
> Privacy is a
Hi,
I believe two wallets. Andreas' Android Bitcoin wallet and BRD are
significant users of node_bloom.
Privacy is a matter of individual choice in the current protocol. Why not
let people provide this network service? I don't see why it should be
end-of-life if it provides value.
I believe
On Sunday 21 July 2019 22:56:33 Andreas Schildbach via bitcoin-dev wrote:
> An estimated 10+ million wallets depend on that NODE_BLOOM to be
> updated.
Where do you see this number? I think it would be useful to chart.
> So far, I haven't heard of an alternative, except reading all
>
On Monday 22 July 2019 13:25:25 Jonas Schnelli via bitcoin-dev wrote:
> > I also think as long as we don't have an alternative, we should improve
> > the current filtering for segwit. E.g. testing the scripts themselves
> > and each scriptPubKey spent by any input against the filter would do,
> >
On 7/22/19 12:01 AM, Matt Corallo via bitcoin-dev wrote:
> Finally, regarding alternatives, the filter-generation code for BIP
> 157/158 has been in Bitcoin Core for some time, though the P2P serving
> side of things appears to have lost any champions working on it. I
> presume one of the
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
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.
Hi Andreas
>> well-known DoS vectors
>
> I asked many people, even some "core developers" at meetings, but nobody
> ever was able to explain the DoS vector. I think this is just a myth.
No. They are not a myth [1] [2] [3].
> Yes, you can set an overly blurry filter and thus cause useless
On Mon, Jul 22, 2019 at 12:56:33AM +0200, Andreas Schildbach via bitcoin-dev
wrote:
> An estimated 10+ million wallets depend on that NODE_BLOOM to be
> updated. So far, I haven't heard of an alternative, except reading all
> transactions and full blocks.
Can you specify exactly which wallets
Hey Andreas,
I think maybe some of the comments here were misunderstood - I don't
anticipate that most people will change their defaults, indeed, but
given the general upgrade cycles we've seen on the network over the
entire course of Bitcoin's history, there's little reason to believe
that many
An estimated 10+ million wallets depend on that NODE_BLOOM to be
updated. So far, I haven't heard of an alternative, except reading all
transactions and full blocks.
It goes without saying pulling the rug under that many wallets is a
disastrous idea for the adoption of Bitcoin.
> well-known DoS
Just a quick heads-up for those watching the list who may be using it -
in the next Bitcoin Core release bloom filter serving will be turned off
by default. This has been a long time coming, it's been an option for
many releases and has been a well-known DoS vector for some time.
As other DoS
23 matches
Mail list logo
