> What if instead of trying to decide up front which subset of elements will
> be most useful to include in the filters, and the size tradeoff, we let
the
> full-node decide which subsets of elements it serves filters for?
This is already the case. The current "track" is to add new service bits
(w
Hi Y'all,
The script finished a few days ago with the following results:
reg-filter-prev-script total size: 161236078 bytes
reg-filter-prev-script avg: 16123.6078 bytes
reg-filter-prev-script median: 16584 bytes
reg-filter-prev-script max: 59480 bytes
Compared to
Our wetware memory is faulty at details, but a rendering that provides
features at which it isn't faulty makes it a decent backup in situations
where technology has been used to hide important differences from us. Some
of us may recall being in a situation where something seems off, and we
start t
In the thread "Revisting BIP 125 RBF policy" @
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html
and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015797.html
I propose replacing rule 3 with a rule that instead demands that the
replacement packag
Hi all,
Most light wallets will want to download the minimum amount of data required to
operate, which means they would ideally download the smallest possible filters
containing the subset of elements they need.
What if instead of trying to decide up front which subset of elements will be
most u
