Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-22 📝 Original message:On Sunday 21 July 2019 ...
📅 Original date posted:2019-07-22
📝 Original message: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
> transactions and full blocks.
Electrum has a JSON-based protocol that can provide information much more
efficiently.
Currently, this does require nodes that run additional software and/or
indexes, but there are plenty of them available, and there are steps that can
be taken to improve that situation.
> > It is not anticipated that
> > this will result in a significant lack of availability of
> > NODE_BLOOM-enabled nodes in the coming years
>
> Why don't you anticipate that? People almost never change defaults,
> especially if it's not for their own immediate benefit. At the same
> time, release notes in general recommend updating to the latest version.
> I *do* anticipate this will reduce the number of nodes usable by a large
> enough amount so that the feature will become unstable.
Many users run older versions, and do not update immediately. Today, only 42%
of listening nodes are using 0.18.
(If it helps ease the concern, we can keep bloom enabled by default in Knots
longer.)
> I strongly recommend postponing this change until an alternative exists
> and then give developers enough time to implement, test and roll out.
There will be time to do so, since the functionality won't disappear
overnight.
Luke
📝 Original message: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
> transactions and full blocks.
Electrum has a JSON-based protocol that can provide information much more
efficiently.
Currently, this does require nodes that run additional software and/or
indexes, but there are plenty of them available, and there are steps that can
be taken to improve that situation.
> > It is not anticipated that
> > this will result in a significant lack of availability of
> > NODE_BLOOM-enabled nodes in the coming years
>
> Why don't you anticipate that? People almost never change defaults,
> especially if it's not for their own immediate benefit. At the same
> time, release notes in general recommend updating to the latest version.
> I *do* anticipate this will reduce the number of nodes usable by a large
> enough amount so that the feature will become unstable.
Many users run older versions, and do not update immediately. Today, only 42%
of listening nodes are using 0.18.
(If it helps ease the concern, we can keep bloom enabled by default in Knots
longer.)
> I strongly recommend postponing this change until an alternative exists
> and then give developers enough time to implement, test and roll out.
There will be time to do so, since the functionality won't disappear
overnight.
Luke