Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Neonpool: Reimagining cryptocurrency transaction pools for lightweight clients and IoT devices

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Neonpool claims a 400 MB transaction pool can shrink to 2 MB using Bloom-filter fingerprints while keeping over 99.99% accuracy.

desk verdict Neonpool has a genuinely new target and real datasets, but the Bitcoin variant forgets pull-based relay: storing only hashes means it cannot serve getdata, and the 99.99% claim depends on cherry-picked parameters. read the letter →

arxiv 2412.16217 v2 pith:EQG36RB3 submitted 2024-12-18 cs.CR

Hina Binte Haq , Syed Taha Ali , Asad Salman , Patrick McCorry , Siamak F. Shahandashti This is my paper · ORCID
classification cs.CR
keywords transactionpoolBloomfiltermemoryoptimizationlightweightclientsIoTdevicesBitcoinEthereumdouble-spenddetection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that a cryptocurrency node's transaction pool—the in-memory store of unconfirmed transactions—can be rebuilt with Bloom filters so a node keeps only compact transaction fingerprints instead of full transaction data. If the construction works, the pool's RAM consumption falls by up to two orders of magnitude, for example from 400 MB to 2 MB, while verification and forwarding decisions remain above 99.99% accurate, with no hard fork and no change to consensus rules. The authors implement two variants, one for Bitcoin and one for Ethereum, and benchmark them by replaying about ten million unique transactions per network against a simulated reference pool. The practical stake is that phones, single-board computers, and IoT devices could run transaction verification and propagation themselves instead of depending on full nodes.

What carries the argument

The load-bearing objects are two Bloom filters: `bloomtxFilter`, a probabilistic bit-array membership structure holding transaction fingerprints keyed on the transaction hash, and `dstxFilter`, which records double-spend-relevant tuples so conflicting transactions are dropped. A Bloom filter answers membership queries with a configurable false-positive rate and, in its standard form, no false negatives; the false negatives the paper reports come from its expiry mechanisms. Periodic clearing or decaying filters implement transaction expiry, and when the inserted-transaction counter exceeds the designed capacity, additional filters are instantiated and aged out in order.

What would settle it

Run a Neonpool-BTC node on a Bitcoin testnet, configure it to delete each raw transaction after inserting its hash into the Bloom filter, announce the transaction to a peer, and see whether that peer can obtain the raw bytes. If the requesting peer times out and the transaction never propagates, the forwarding half of the central claim is refuted; if a hidden cache serves the bytes, the memory figure must be re-measured including that cache.

Watch

Extended reading notes

Core claim

On its own terms, the paper claims that the transaction pool's two core jobs—inventory (knowing which transactions have already been seen) and forwarding—can be dissociated, and that the inventory job can be carried almost entirely by probabilistic fingerprints. Each incoming transaction is hashed into a Bloom filter keyed on the transaction hash, and a second filter records double-spend-relevant tuples (input hash plus index in Bitcoin; address plus nonce in Ethereum), so the node never stores complete transactions. The paper reports that this reproduces the pool's decisions with over 99.99% accuracy while cutting memory usage by up to 200x, and that the approach is secure because per-node random salts make Bloom-filter errors independent across the network.

Load-bearing premise

Neonpool's memory savings assume a node can forward transactions while storing only fingerprints and discarding the complete transaction data, yet Bitcoin's relay protocol requires a node that announces a transaction to hand the full raw transaction to any peer that requests it.

Editorial extensions

If this is right

  • A full node could operate its transaction pool in roughly 2 MB instead of hundreds of megabytes, putting transaction verification and propagation within reach of single-board computers and IoT devices.
  • Because Neonpool changes only the node's local pool data structure, it can be deployed without consensus changes and combined with existing light-client techniques such as pruned storage or bandwidth-saving relay.
  • Bloom-filter errors at different nodes are statistically independent because each node salts its filters with a fresh random 128-bit key, so the chance that two nodes drop the same valid transaction is the square of the per-node false-positive rate.
  • The scheme transfers directly to other UTXO-based and account-based cryptocurrencies by changing the double-spend tuple and the expiry parameters.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Extension: Bitcoin's relay protocol is pull-based: a node announces a transaction hash and must later serve the raw transaction to a peer that sends a getdata request. Neonpool as described stores only the hash, so the 2 MB figure would require an unstated raw-transaction cache or a change to relay behaviour to actually propagate transactions.
  • Extension: The 99.99% accuracy figure measures Bloom-filter membership decisions against a simulated pool, not end-to-end delivery on a live network; a testnet deployment that discards raw transactions would show whether peers can retrieve announced transactions at all.
  • Extension: The expiration mechanisms create false negatives, meaning a transaction that has expired can be accepted and re-forwarded later; duplicate rebroadcast traffic is therefore a network-level cost separate from the rejection errors the paper reports.
  • Extension: Because filters keep expired transactions until the next clear or decay, the number of tracked fingerprints can exceed the live pool size, which is why the authors dimension filters at double the observed peak; this retention is part of the memory/accuracy trade-off, not a flaw in the reported savings.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes Neonpool, a transaction-pool design that replaces the map-based mempool/txpool with Bloom filters (a bloomtxFilter for transaction-hash inventory and a dstxFilter for double-spend protection). Two variants are implemented for Bitcoin and Ethereum, and the authors claim a reduction in memory consumption from up to 400 MB to 2 MB while retaining 'over 99.99%' verification and forwarding accuracy, without a hard fork. The paper presents C++ implementations, replay experiments on datasets of 10 million unique Bitcoin and Ethereum transactions, measurements of false-positive/false-negative rates, memory usage, computation time on Raspberry Pi 4 and Jetson Nano, and a security analysis.

Significance. The problem addressed—the growing RAM footprint of cryptocurrency transaction pools—is real and practically important, and the authors contribute substantial artifacts: two novel network datasets, a public C++ implementation, and measurements on low-end hardware. If the core design were correct, it would be a meaningful step toward lightweight full nodes. However, the central claims are not supported by the paper's own experiments and the Bitcoin variant appears to break the relay function it claims to preserve. The contribution is therefore more of a negative or exploratory result unless substantially reframed and reworked.

major comments (4)
  1. [§3.1.1 and §4.6] The Bitcoin variant cannot fulfill the forwarding function it claims to preserve. In Bitcoin's pull-based relay, a node announces a transaction hash via inv and must later serve the raw transaction to peers that request it via getdata. Neonpool-BTC stores only the txHash in bloomtxFilter and discards the full transaction; §4.6 explicitly states that 'Neonpool node operators are not required to store full transactions.' Without a raw-transaction cache or an alternative relay mechanism, a Neonpool-BTC node cannot respond to getdata requests, so it cannot actually propagate the transactions it announces. This is a load-bearing functional gap: the 400 MB-to-2 MB comparison omits the storage that real relay requires.
  2. [§4.3.1, Table 1 and §4.3.2, Table 2] The abstract and §4.6 claim 'over 99.99% accuracy,' but the measured numbers in the paper's own tables contradict this. For Neonpool-BTC with a 1 MB filter and 24-hour clearing, Table 1 reports FPR = 1.94E-03 (0.194% of valid transactions rejected) and FNR = 1.79E-03; even if accuracy is defined as 1 - FPR, this is 99.81%, not 99.99%. With no expiry, the FPR for 1 MB is 7.43E-01 (74.3%). For Neonpool-ETH, Table 2 reports FPR = 8.14E-03 for a 1 MB filter with 24-hour clearing, and the no-expiry FPR is 6.70E-01. The only configurations with FPR near 1e-5 are decay variants, but those have FNR around 0.6%, which the headline claim ignores.
  3. [§4.3.1, §4.3.2, and §4.2] The 'fidelity' figures reported as 99.99% for Bitcoin and 99.999% for Ethereum are computed by looking at FPR alone, omitting the FNR. For example, the text says the 1 MB decay d=128 filter rejects only 0.0009% of valid transactions, but Table 1 shows FNR = 6.06E-03 (0.606%) for that configuration; the accuracy metric defined in §4.2 accounts for both FPR and FNR. The discrepancy between the reported fidelity and the combined error rates must be reconciled before the accuracy claim can be assessed.
  4. [§4.5] The security analysis builds on the premise of 'a Bloom filter accuracy of 99.99% (corresponding to a false positive rate of 0.0001 per Neonpool node),' but the paper's own experiments show that this FPR is not achieved by the configurations that also have acceptable FNR. In addition, the claim that the probability of two nodes erroneously dropping the same transaction is (0.0001)^2 treats the two nodes as if they were the only ones queried; in a network with k peers, the probability that at least one peer drops the transaction is 1-(1-p)^k, which for p=1e-4 and k=8 is approximately 8e-4, not 1e-8. This argument needs to be reworked or removed.
minor comments (6)
  1. [Table 1] The d=256 row for the 1 MB filter reports FPR '7.04E-01/248219', which appears to be a typo for 7.04E-03; the surrounding rows and the FNR column strongly suggest this.
  2. [§5.1] The first paragraph of §5.1 is duplicated verbatim at the start of the section.
  3. [§4.1] The text says the simulations use 'high-level pseudocode described in Algo 2', but Algo 2 is the Neonpool algorithm; the simulation of the mempool/txpool is described by Algo 1.
  4. [Figures 6 and 8] Figure 6's caption says 24-hour expiry, but the Ethereum figure (Fig. 8) is described in the text sometimes as 24-hour and sometimes as 12-hour expiry; please check the captions and the corresponding discussion in §4.3.1 and §4.3.2.
  5. [References] Reference [43] points to a Google Drive link, which is not a stable or archival location for the datasets and code; a repository or digital object identifier would be more appropriate.
  6. [§4.1] The 'Berkeley libbf' library is actually 'libbf' by Mavam (the URL in reference [25] contains spaces); this should be corrected.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: Bloom-filter mathematics and empirical error-rate measurements are external to the claim, and the single self-citation is a data/code pointer, not load-bearing.

full rationale

The paper's central claim is an empirical engineering result: replacing map-based transaction-pool storage with Bloom-filter fingerprints reduces memory from roughly 400 MB to 2 MB while measured ingress FPR/FNR stay below the thresholds that yield 'over 99.99%' accuracy. The Bloom-filter sizing equations (Eqs. 1-3) are standard external results, and the reported accuracy is obtained by replaying captured transaction datasets against a simulated ground-truth mempool/txpool, not by fitting a parameter to force a predetermined conclusion. Filter sizes, expiry intervals, and decay factors are swept and reported as design choices rather than derived from the target claim. The only self-citation, reference [43], is a publicly accessible dataset/code repository pointer and carries no argumentative weight in the derivation. The concern that a Bitcoin node storing only txHashes cannot satisfy getdata requests is a functional correctness or overclaiming issue, not circularity: it does not make the derivation equivalent to its inputs. Therefore the paper shows no significant circularity.

Assumptions & free parameters 6 free parameters · 6 assumptions · 0 invented entities

No new physical or cryptographic entities are introduced; Bloom filters, decaying Bloom filters, and random salts are existing concepts. The key unsupported premise is the ad hoc assumption that forwarding can occur without storing raw transactions.

free parameters (6)
  • Bloom filter bit-array size m = 500 KB, 1 MB, 2 MB
    Chosen by hand to explore memory-accuracy tradeoffs; each size is evaluated in Tables 1 and 2.
  • Number of hash functions k = 7, 14, 28 for BTC; 4, 8, 16 for ETH
    Computed from Eq. 3 given m and n, but the filter sizes are design choices, so k is effectively a design parameter.
  • Design capacity n = 400,000 for Bitcoin; 700,000 for Ethereum
    Set to twice the highest observed transaction pool size, an arbitrary safety margin.
  • Expiry interval h = 48, 24, 12, 6, 3 hours
    Chosen by hand; results are reported for each interval.
  • Decay factor d = 16, 32, 64, 128, 256
    Chosen by hand for decaying filters; higher d lowers FPR but raises FNR.
  • Random 128-bit salt = not specified per filter
    Used for adversarial resilience and to decorrelate false positives across nodes; its exact generation is not detailed.
assumptions (6)
  • standard math Bloom filter false-positive formulas (Eqs. 1-3) hold for the deployed hash functions and datasets.
    Used in §4.3.1 and §4.3.2 to dimension filters; the paper itself notes empirical FPRs exceed the theoretical values.
  • domain assumption Transaction hashes and inputs are distributed such that the Bloom filter's theoretical load assumptions approximately apply.
    Invoked implicitly when dimensioning filters using n and target p; the paper acknowledges real data is 'clumped' (§4.3.1) and empirical FPR is higher.
  • domain assumption The network can tolerate nodes dropping some valid transactions due to false positives.
    Security analysis in §4.5 argues FPs are independent across nodes due to random salts, so network-wide impact is small.
  • ad hoc to paper A node can fulfill the forwarding function without storing raw transaction data.
    Assumed in §3.1.1 and §4.6; this is load-bearing and unsupported for Bitcoin's pull-based relay.
  • domain assumption The simulated map-based mempool/txpool faithfully represents the real Bitcoin Core/Geth transaction pool behavior.
    Used as ground truth in §4.1; the simulation eviction rules are not described or validated.
  • domain assumption Per-node random salts make false positives statistically independent across nodes.
    Asserted in §4.5 and used to claim negligible correlated drops; depends on secure random seed generation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Neonpool: Reimagining cryptocurrency transaction pools for lightweight clients and IoT devices." pith.science (2026). https://pith.science/paper/EQG36RB3

@misc{pith2026241216217,
  author       = {Pith},
  title        = {Pith review of: Neonpool: Reimagining cryptocurrency transaction pools for lightweight clients and IoT devices},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EQG36RB3}},
  note         = {Machine review of arXiv:2412.16217}
}
read the original abstract

The transaction pool plays a critical role in processing and disseminating transactions in cryptocurrency networks. However, increasing transaction loads strain the resources of full node deployments. We present Neonpool, an innovative transaction pool optimization using bloom filter variants, which reduces the memory footprint of the transaction pool to a fraction. Implemented in C++ and benchmarked using a unique Bitcoin and Ethereum dataset, our solution verifies and forwards transactions with over 99.99\% accuracy and does not necessitate a hard fork. Neonpool is ideally suited for lightweight cryptocurrency clients and for resource-constrained devices such as browsers, systems-on-a-chip, mobile or IoT devices.

Figures

Figures reproduced from arXiv: 2412.16217 by the authors.

Figure 1
Figure 1. Transaction pool trends (since 2020) HB Haq, ST Ali, A Salman, P McCorry, SF Shahandashti: Preprint submitted to Elsevier Page 2 of 15 [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. shows the distribution of node components over the hard disk and RAM. Disk storage encompasses raw block data, metadata, and state information like UTXO or Trie. Notably, the UTXO/Trie is partially mirrored in RAM. Additionally, RAM contains essential elements such as the unconfirmed transaction pool, partial state (e.g., UTXO or Trie), block and validation cache, as well as network con￾nections information [PITH_F… view at source ↗
Figure 3
Figure 3. Bloom filter 2.2. Bloom filter A Bloom filter [38] is a probabilistic data structure used to test for set membership. It is particularly efficient with regards to memory usage but with a caveat: it may provide false positive results, i.e., it can report that an element is present in the set when it is not, but it will never produce a false negative. Essentially it is a bit array of size m and k different hash functi… view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Ingress: mempool vs Neonpool-BTC (only (Y)es or (N)o is shown, other implies transaction is dropped.) HB Haq, ST Ali, A Salman, P McCorry, SF Shahandashti: Preprint submitted to Elsevier Page 4 of 15 [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Ingress: txpool vs Neonpool-ETH (only (Y)es or (N)o is shown, other implies transaction is dropped.) Transactions with an invalid or out-of-order nonce or insuf￾ficient funds are rejected. Then, in Ethereum, the txpool is queried to check if a transaction with the same…
Figure 7
Figure 7. Figure 7: Memory usage of mempool and Neonpool-BTC 4.3.2. Neonpool-ETH The highest transaction volumes observed in the Ethereum txpool to date is around 350k. We dimension bloomtxFilter to handle its double i.e. 700k transactions, because Neonpool delays the removal of transacti…
Figure 6
Figure 6. Figure 6: depicts in real-time the number of transactions stored in Neonpool-BTC with 1 MB filters and 24-hour ex￾piry alongside the FPR for 30 days (10 million transactions). We also plot the corresponding number of transactions in the Bitcoin mempool, the ground truth in our e…
Figure 8
Figure 8. Figure 8: Neonpool-ETH: 1 MB, 12 hours expiry We replay transaction events in the Ethereum dataset. First, we run Neonpoool-ETH without any transaction ex￾piry mechanism. Thus transactions accumulate and quickly surpass the filter design capacity. Due to overloading in the filte…
Figure 9
Figure 9. Figure 9: Memory usage of txpool and Neonpool-ETH the insertion average, and the filter reaches a stable state. However, on the flip side, the false negative rate increases. The dstxFilter which prevents double spends, can have implications denoted as 𝐓𝐏𝐚𝐜𝐜𝐨𝐮𝐧𝐭, 𝐓𝐍𝐚𝐜𝐜𝐨𝐮𝐧𝐭, 𝐅𝐏𝐚𝐜𝐜…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Unraveling Ethereum's Mempool: The Impact of Fee Fairness, Transaction Prioritization, and Consensus Efficiency

    cs.CR 2025-06 conditional novelty 4.0 of 10

    Empirical evidence from live Geth and Prysm nodes shows Ethereum's post-EIP-1559 mempool still favors high fees, while high congestion correlates with longer finalization times.

Reference graph

Works this paper leans on

47 extracted references · 47 canonical work pages · cited by 1 Pith paper

  1. [1]

    X., Roman, P.-L., Taïani, F., and Voulgaris, S

    Frey, D., Makkes, M. X., Roman, P.-L., Taïani, F., and Voulgaris, S. Dietcoin: Hardening bitcoin transaction verificationprocessformobiledevices. Proceedingsof the VLDB Endowment (PVLDB), 12(12):1946–1949, 2019

    work page 1946

  2. [2]

    In2020 IEEE Symposium on Security and Privacy (SP), pages 928–

    Bünz,B.,Kiffer,L.,Luu,L.,andZamani,M.Flyclient: Super-light clients for cryptocurrencies. In2020 IEEE Symposium on Security and Privacy (SP), pages 928–

    work page

  3. [3]

    and Bonneau, J

    Kattis, A. and Bonneau, J. Proof of necessary work: Succinct state verification with fairness guarantees. Cryptology ePrint Archive, 2020

    work page 2020

  4. [4]

    P., Andresen, G., Levine, B

    Ozisik, A. P., Andresen, G., Levine, B. N., Tapp, D., Bissias, G., and Katkuri, S. Graphene: Efficient inter- activesetreconciliationappliedtoblockchainpropaga- tion.In ProceedingsoftheACMSpecialInterestGroup on Data Communication, pages 303–317. Springer, 2019

    work page 2019

  5. [5]

    Sketches for blockchains

    Rottenstreich, O. Sketches for blockchains. In2021 International Conference on COMmunication Systems & NETworkS (COMSNETS), pages 254–262. IEEE, 2021

    work page 2021

  6. [6]

    Bit Pay, 2023

    250+companiesandstoresthatacceptcryptocurrency. Bit Pay, 2023. Available at:https://bitpay.com/direc tory

    work page 2023

  7. [7]

    stresstesting

    Baqer, K., Huang, D. Y., McCoy, D., and Weaver, N. Stressingout:Bitcoin“stresstesting”.In International Conference on Financial Cryptography and Data Se- curity, pages 3–18. Springer, 2016

    work page 2016

  8. [8]

    BZIP: A Compact Data Memory System for UTXO-based Blockchains

    Jiang, S., Li, J., Gong, S., Yan, J., Yan, G., Sun, Y., and Li, X. BZIP: A Compact Data Memory System for UTXO-based Blockchains. In2019 IEEE Interna- tionalConferenceonEmbeddedSoftwareandSystems (ICESS), pages 1–8. IEEE, 2019

    work page 2019

Show all 47 references
  1. [9]

    Bitcoin P2P e-cash paper.The Cryptog- raphy Mailing List, 2008

    Nakamoto, S. Bitcoin P2P e-cash paper.The Cryptog- raphy Mailing List, 2008

    2008

  2. [10]

    Transactions Bitcoin, Raw Trans- actions format

    "Transactions Bitcoin, Raw Trans- actions format." Available at: https://developer.bitcoin.org/reference/transactions.html

  3. [11]

    InInternational Conference on Financial Cryptography and Data Security, pages 505–522

    Kiayias,A.,Miller,A.,andZindros,D.Non-interactive proofs of proof-of-work. InInternational Conference on Financial Cryptography and Data Security, pages 505–522. Springer, 2020

    2020

  4. [12]

    ePrint Arch., 2019

    Dryja,T.Utreexo:Adynamichash-basedaccumulator optimized for the Bitcoin UTXO set.IACR Cryptol. ePrint Arch., 2019

    2019

  5. [13]

    Naor,M.andYogev,E.Bloomfiltersinadversarialen- vironments.ACMTransactionsonAlgorithms(TALG) , 15(3):1–30, 2019

    2019

  6. [14]

    Examining Bitcoin mempools Resemblance Using Jaccard Similarity Index,

    Dae-Yong Kim, Meryam Essaid, and Hongtaek Ju, "Examining Bitcoin mempools Resemblance Using Jaccard Similarity Index," in2020 21st Asia-Pacific Network Operations and Management Symposium (APNOMS), IEEE, 2020, pp. 287–290

    2020

  7. [15]

    InProceedings of the 11th ACM Symposium on Cloud Computing, 2020

    Han, Y., Li, C., Li, P., Wu, M., Zhou, D., and Long, F.Shrec:Bandwidth-efficienttransactionrelayinhigh- throughput blockchain systems. InProceedings of the 11th ACM Symposium on Cloud Computing, 2020

    2020

  8. [16]

    Erlay: Efficient transaction relay for bitcoin

    Naumenko, G., Maxwell, G., Wuille, P., Fedorova, A., and Beschastnikh, I. Erlay: Efficient transaction relay for bitcoin. InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Secu- rity, pages 817–831. 2019

    2019

  9. [17]

    Blockchain.com | Charts - Mempool Size (Bytes),

    "Blockchain.com | Charts - Mempool Size (Bytes)," December 2024. Available at:https://www.blockcha in.com/explorer/charts/mempool-size

    2024

  10. [18]

    SoK: Blockchain light clients,

    P. Chatzigiannis,F. Baldimtsi, andK. Chalkias,"SoK: Blockchain light clients," in *Financial Cryptography and Data Security*, Springer, 2022, pp. 615–641

    2022

  11. [19]

    Fighting under-price DoS attack in Ethereum with machine learning techniques,

    Eduardo et al., "Fighting under-price DoS attack in Ethereum with machine learning techniques," *ACM SIGMETRICS Performance Evaluation Review*, vol. 48, no. 4, pp. 24–27, 2021

    2021

  12. [20]

    Contra-*: Mechanisms for Countering Spam At- tacks on Blockchain Memory Pools,

    M. Saad, J. Kim, D. Nyang, and D. Mohaisen, "Contra-*: Mechanisms for Countering Spam At- tacks on Blockchain Memory Pools," *arXiv preprint arXiv:2005.04842*, 2020

    2005 arXiv

  13. [21]

    Anti-Dust: A Method for Identifying and Preventing Blockchain’s Dust Attacks,

    Y. Wang, J. Yang, T. Li, F. Zhu, and X. Zhou, "Anti-Dust: A Method for Identifying and Preventing Blockchain’s Dust Attacks," in *2018 International Conference on Information Systems and Computer Aided Education (ICISCAE)*, IEEE, 2018, pp. 274– 280

    2018

  14. [22]

    Deter: Denial of Ethereum txpool services,

    K. Li, Y. Wang, and Y. Tang, "Deter: Denial of Ethereum txpool services," in *Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security*, ACM, 2021, pp. 1645– 1667

    2021

  15. [23]

    GitHub, 2021

    Bitcoin source code. GitHub, 2021. Available at:http s://github.com/bitcoin/bitcoin/blob/master/src/txm empool.h

    2021

  16. [24]

    GitHub, 2023

    Ethereum, go-ethereum. GitHub, 2023. Available at: https://github.com/ethereum/go- ethereum/blob/m aster/light/txpool.go

    2023

  17. [25]

    Available at:h t tp : //mavam.github.io/libbf

    libbf Bloom filters for C++11. Available at:h t tp : //mavam.github.io/libbf

  18. [26]

    Johoe’s Bitcoin Mempool Size Statistics,

    Jochen Hoenicke, "Johoe’s Bitcoin Mempool Size Statistics," Available at:https://test.jochen- hoeni cke.de/queue/#BTC,all,weight. HB Haq, ST Ali, A Salman, P McCorry, SF Shahandashti:Preprint submitted to Elsevier Page 14 of 15 Neonpool

  19. [27]

    The300MBdefaultmaxmempoolProblem,

    "The300MBdefaultmaxmempoolProblem,"Decem- ber 2017. Available at:https://b10c.me/blog/001-the -300mb-default-maxmempool-problem/

    2017

  20. [28]

    Glassnode Studio - On-Chain Market Intelligence,

    "Glassnode Studio - On-Chain Market Intelligence," December 2024. Available at:https://studio.glass node.com/charts/transactions.TxTypesBreakdownRelat ive?a=ETH&category=&ema=0&mAvg=7&mMedian=0&pScl=lo g&s=1667924083&u=1675700083&zoom=90

    2024

  21. [29]

    Daily Pending Transactions | Ether- scan,

    Etherscan.io, "Daily Pending Transactions | Ether- scan," Ethereum (ETH) Blockchain Explorer, Decem- ber 2024. Available at:https://etherscan.io/dashboa rds/daily-pending-tx

    2024

  22. [30]

    Gremillion,L.L.DesigningaBloomfilterfordifferen- tial file access.Communications of the ACM, 25:600– 604, 1982

    1982

  23. [31]

    Mullin, J. K. A second look at Bloom filters.Commu- nications of the ACM, 26(8):570–571, 1983

    1983

  24. [32]

    On the false-positive rate of Bloom filters.Information Processing Letters, 108(4):210–213, 2008

    Bose, P., Guo, H., Kranakis, E., Maheshwari, A., Morin, P., Morrison, J., Smid, M., and Tang, Y. On the false-positive rate of Bloom filters.Information Processing Letters, 108(4):210–213, 2008

    2008

  25. [33]

    A secure sharding protocol for open blockchains.In Proceedingsofthe2016ACMSIGSAC Conference on Computer and Communications Secu- rity, pages 17–30, 2016

    Luu,L.,Narayanan,V.,Zheng,C.,Baweja,K.,Gilbert, S., and Saxena, P. A secure sharding protocol for open blockchains.In Proceedingsofthe2016ACMSIGSAC Conference on Computer and Communications Secu- rity, pages 17–30, 2016

    2016

  26. [34]

    Zamyatin, A., Avarikioti, Z., Perez, D., and Knotten- belt, W. J. TxChain: Efficient Cryptocurrency Light ClientsviaContingentTransactionAggregation. IACR Cryptol. ePrint Arch., 2020:580

    2020

  27. [35]

    Ethanos: Efficient bootstrapping for full nodes on account-based blockchain

    Kim, J.-Y., Lee, J., Koo, Y., Park, S., and Moon, S.-M. Ethanos: Efficient bootstrapping for full nodes on account-based blockchain. InProceedings of the SixteenthEuropeanConferenceonComputerSystems , pages 99–113, 2021

    2021

  28. [36]

    Ethereum, 2023

    Ethereum nodes and clients. Ethereum, 2023. Avail- able at: https://ethereum.org/en/developers/docs/ nodes-and-clients

    2023

  29. [37]

    GitHub, 2023

    MSVC’simplementationoftheC++StandardLibrary. GitHub, 2023. Available at:https://github.com/micro soft/STL

    2023

  30. [38]

    Bloom, B. H. Space/time trade-offs in hash coding with allowable errors.Communications of the ACM, 13(7):422–426, 1970

    1970

  31. [39]

    The dynamic bloom filters.IEEE Transactions on Knowl- edge and Data Engineering, 22(1):120–133, 2009

    Guo, D., Wu, J., Chen, H., Yuan, Y., and Luo, X. The dynamic bloom filters.IEEE Transactions on Knowl- edge and Data Engineering, 22(1):120–133, 2009

    2009

  32. [40]

    S., Rajagopalan, S., and Zubiri, A

    Beyer, K. S., Rajagopalan, S., and Zubiri, A. System andmethodforgeneratingandusingadynamicbloom filter.GooglePatents,USPatent7,937,428,May2011

  33. [41]

    Ethereum

    Raw Transactions | Ethereum.org. Ethereum. Avail- able: https://ethereum.org/en/developers/docs/tr ansactions

  34. [42]

    Ethereum Transactions Message. devp2p. GitHub. Available: https://github.com/ethereum/devp2p/blo b/master/caps/eth.md#transactions-0x02

  35. [43]

    H. B. Haq, T. Ahmad, A. Buriro, and S. Ullah,Neon- pool: Reimagining Cryptocurrency Transaction Pools for Lightweight Clients and IoT Devices, 2024. [On- line]. Available:https://drive.google.com/drive/fol ders/1KkjPxNI7NvWyqlZ3jlrcCGhYxwUbzXEJ?usp=drive_l ink

    2024

  36. [44]

    Edrax: A cryptocurrency with stateless transaction validation

    Chepurnoy, Alexander, Charalampos Papamanthou, Shravan Srinivasan, and Yupeng Zhang. "Edrax: A cryptocurrency with stateless transaction validation." Cryptology ePrint Archive (2018)

    2018

  37. [45]

    P2P Network—Bitcoin, Inventory Messages

    "P2P Network—Bitcoin, Inventory Messages." April 2021. Available at: https://developer.bitcoin.org/reference/p2p- networking.html

    2021

  38. [46]

    On-demand time-decaying bloom filters for telemarketer detection

    Bianchi,Giuseppe,Nicod’Heureuse,andSaverioNic- colini. "On-demand time-decaying bloom filters for telemarketer detection." ACM SIGCOMM Computer Communication Review 41, no. 5 (2011): 5-12. ACM New York, NY, USA

    2011

  39. [47]

    P2P Network Guide - Bitcoin

    Bitcoin Network Guide. "P2P Network Guide - Bitcoin." May 2020. Available at: https://bitcoin.org/en/p2p-network-guide. HB Haq, ST Ali, A Salman, P McCorry, SF Shahandashti:Preprint submitted to Elsevier Page 15 of 15

    2020

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.