admin at bitaps.com [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-09-19 to 2019-10-12
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:21:11

- reply

📅 Original date posted:2019-10-12
📝 Original message:Hi Jonas,
Let's review case when we create filters for part of mempool or whole mempool.
After new block is mined we have to verify what transactions is confirmed from mempool. Mempool filter in design with set of transactions make impossible use it do block filter reconstruction because we have no mapping filter elements with transactions.
This means that we need to download block filter to check what exactly transactions are affected.
Which does not give us advantages in terms of traffic savings.
The idea of draft for mempool transactions filters is make possible to reconstruct correct block filters using unconfirmed tx filters and archive additional savings.
At this moment I am working on Block Batch Filters implementation and have same changes which will be updated in drafts as soon as I complete all tests. Regarding unconfirmed TX filters, I came to the conclusion that the filter
should be the first 6 bytes of the address hash, this takes up a bit more space, but allows to construct block filter.
What do you mean by fingerprinting defence ?
Please let me know what, in your opinion, are the disadvantages of the per tx filter approach?
Why use whole/part mempool is better?
With regards Aleksey
> 12 окт. 2019 г., в 5:40, bitcoin-dev-request at lists.linuxfoundation.org написал(а):
>
> Re: Block Batch Filters for Light Clients (Jonas Schnelli)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191012/2d5f3da2/attachment-0001.html>

2023-06-07 18:21:11

- reply

2023-06-07 18:20:42

- reply

📅 Original date posted:2019-09-28
📝 Original message:Block Batch Filters draft :
https://github.com/bitaps-com/bips/blob/master/bip-block-batch-filters.mediawiki <https://github.com/bitaps-com/bips/blob/master/bip-block-batch-filters.mediawiki>
BIP 157 unlike BIP 37 not allow apply filters to mempool and check zero confirmation transactions.
Light client that refused to use BIP 37 due to privacy leaks can process unconfirmed transactions only one way and this is loading the entire mempool transaction flow.
Mempool Transaction Filters draft:
https://github.com/bitaps-com/bips/blob/master/bip-mempool-transactions-filters.mediawiki <https://github.com/bitaps-com/bips/blob/master/bip-mempool-transactions-filters.mediawiki>
Summary:
- improved Block Batch Filters definition
- unlocked ability to filter unconfirmed transaction for SPV nodes used BIP 157 instead of BIP 37 due privacy leak in BIP 37
- more bandwidth consumption reduced in contrast with block filters and downloading full blocks for affected addresses
- proposal for future consensus layer soft-fork to make block filters commitment one of the block validation rule to protect light nodes from payment hiding attack
> 23 сент. 2019 г., в 15:00, bitcoin-dev-request at lists.linuxfoundation.org написал(а):
>
> Re: Block Batch Filters for Light Clients
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190928/5d399a03/attachment.html>

2023-06-07 18:20:42

- reply

2023-06-07 18:20:41

- reply

📅 Original date posted:2019-09-24
📝 Original message:Last version updated draft
https://github.com/bitaps-com/bips/blob/master/bip-block-batch-filters.mediawiki <https://github.com/bitaps-com/bips/blob/master/bip-block-batch-filters.mediawiki>
Summary changes:
- return back to Golomb coding
- implemented more simple and effective shema
- Total filters size is smaller then BIP 158 at all total estimated savings more than 20% (exactly info will be soon)
- filter is deterministic and could be committed as commitment in coinbase transaction in future
- flexible GCS parameters to to maintain the necessary FPS
- spliting filter for 2 parts: unique elements and duplicated elements
- duplicated elements could be encoded more effective
Open questions:
- Optimal range for batch?
- Why we need sip has instead of just use first 64 bits from pub key/script hash?
- Downloading unique/duplicated elements separately? Just add filter types for these purposes?
Thanks for any feedback or discussions
Aleksey Karpov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190924/5861d2f2/attachment.html>

2023-06-07 18:20:41

- reply

2023-06-07 18:20:40

- reply

📅 Original date posted:2019-09-19
📝 Original message:Hello list,
Here is a link for a draft of a BIP for compact probabilistic block filters alternative of BIP 158
https://docs.google.com/document/d/1jH9tEUyb9w2OZd4-kxfGuyNIIZzmgkEb_z0qSxv80ik/edit?usp=sharing <https://docs.google.com/document/d/1jH9tEUyb9w2OZd4-kxfGuyNIIZzmgkEb_z0qSxv80ik/edit?usp=sharing>
Summary:
- BIP 158 false positive rate is low, we can achieve lower bandwidth with higher false positive rate filter while sync blockchain
- BIP 158 not do not support filter batching by design of used parameters for siphash and Golomb coding optimal parameters
- Alternative compression with delta coding and splitting data to 2 bit string sequences. First for data without prefixes, second one for information about bit length written to first sequence.
Second sequence have a lot of duplicates, compressed with 2 round of Huffman algorithm. (Effectivity about 98% vs Golomb with optimal parameters)
- Block filters batching reduce filter size significantly
- Separation of filters by address type allows lite client not to download redundant information without compromising privacy.
- Lite client filters download strategy: get biggest filter (smallest blocks/size rate) for blocks range, in case positive test -> get medium filters to reduce blocks range -> get block filters for affected range -> download affected blocks over TOR
Implementation (python): https://github.com/bitaps-com/pybtc/blob/bugfix/pybtc/functions/filters.py#L172 <https://github.com/bitaps-com/pybtc/blob/bugfix/pybtc/functions/filters.py#L172>
Exactly information from mainnet about size for separated filters by address types and batch size will be added within few days.
Thanks for any feedback.
Aleksey Karpov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190919/bdd152e6/attachment.html>

2023-06-07 18:20:40

- reply