{"id":"5ff162a1-5759-480f-a7f2-534d293747ee","arxiv_id":"2412.16217","paper_version":2,"verdict":"REJECT","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":6,"one_line_summary":"Neonpool shows Bloom filters can shrink transaction pool memory by roughly 200x, but its 99.99% accuracy claim ignores false negatives and the Bitcoin design cannot answer transaction data requests.","lead":"Neonpool is a proposed redesign of cryptocurrency transaction pools using Bloom filters, cutting memory from hundreds of megabytes to about two megabytes by storing fingerprints instead of full transactions. A generalist would read it because it claims to let smartphones and IoT devices run functional full nodes, but the forwarding design and accuracy claims have serious gaps.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The Bitcoin variant cannot serve getdata requests because it stores only txHashes, so the claimed forwarding function and 99.99% accuracy do not hold for a real Bitcoin node.","rationale":"I read the full manuscript in good faith. The strongest claim is in the abstract and §4.6: Neonpool reduces the transaction pool's local memory consumption by up to two orders of magnitude (400 MB to 2 MB) while still processing unconfirmed transactions with over 99.99% accuracy, without a hard fork, and while retaining verification and forwarding. For this to hold, a Neonpool node must be able to perform the forwarding that a transaction pool performs. The reader's weakest assumption targets exactly this: the Bitcoin protocol requires a node to serve raw transactions after announcing them. I confirmed this in §3.1.1, where the paper says Bitcoin nodes relay the txHash, and in §4.6, where it says operators are not required to store full transactions. There is no description of a raw-transaction cache, an alternative push-based relay, an Erlay-style reconciliation fallback, or any mechanism to satisfy getdata. Therefore, the memory comparison is not apples-to-apples: the paper compares a 400 MB mempool containing raw transactions against a 2 MB Bloom filter containing only hashes, but the Bloom filter alone cannot sustain Bitcoin's actual relay protocol. The accuracy claim is also defined on ingress events only (§4.2), not on successful end-to-end network propagation, so even a perfect filter would not repair the forwarding gap. I also checked whether any passage acknowledges this limitation: §6 mentions a future BIP/EIP but no discussion of getdata handling; the closest is the claim in §4.6 that Neonpool resembles pruned nodes, which is not accurate because pruned nodes retain recent full blocks and can serve those transactions. No machine-checked proofs or shipped implementation of the full P2P integration are provided, so this is an internal functional inconsistency rather than a conflict with external consensus. My proposed test is concrete: replay the dataset with a real P2P getdata exchange and measure what fraction of announced transactions can actually be served. That would settle whether the forwarding function survives. I therefore agree with the reader's weakest assumption, and the verdict should remain REJECT.","tokens_in":21244,"tokens_out":2035,"duration_ms":16770,"concrete_test":"Simulate the complete Bitcoin relay cycle: have a Neonpool-BTC node announce a txHash (inv) to a peer, then have the peer send getdata for that txHash and observe the response. A concrete check is to run the provided Bitcoin dataset replay with a modified Bitcoin Core P2P layer where the mempool is replaced by Neonpool-BTC, and measure the fraction of announced transactions for which the node can serve the raw transaction. If that fraction is zero (because no raw transactions are stored), the forwarding claim fails; if a hidden cache is added, its memory must be included in the reported 400 MB to 2 MB comparison.","verdict_should_be":"REJECT","load_bearing_attack":"The central claim requires that Neonpool-BTC preserve Bitcoin's forwarding function while storing only fingerprints. In Bitcoin's pull-based relay (§3.1.1), a node announces txHash via inv and must later serve the full raw transaction to peers that request it via getdata. Neonpool-BTC stores only txHash in bloomtxFilter and does not store full transactions (§3, §4.6: 'Neonpool node operators are not required to store full transactions'). Therefore a Neonpool-BTC node cannot respond to getdata requests, so it cannot actually propagate transactions it announces. The paper never introduces a raw-transaction cache or alternative relay mechanism; its 'forwarding' is reduced to announcing inv messages with no way to satisfy the resulting requests. Relatedly, the claimed 99.99% accuracy is computed per node from FPR/FNR on ingress events, not end-to-end network propagation, and does not account for this missing data. This functional gap, not the filter error rates, is the load-bearing weakness: without an unstated full-transaction cache, the memory comparison is misleading, because the 2 MB footprint omits the storage actually needed to forward transactions.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":21496,"tokens_out":4850,"duration_ms":41425,"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":[{"comment":"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.","section":"§3.1.1 and §4.6"},{"comment":"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.","section":"§4.3.1, Table 1 and §4.3.2, Table 2"},{"comment":"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.","section":"§4.3.1, §4.3.2, and §4.2"},{"comment":"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.","section":"§4.5"}],"minor_comments":[{"comment":"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.","section":"Table 1"},{"comment":"The first paragraph of §5.1 is duplicated verbatim at the start of the section.","section":"§5.1"},{"comment":"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.","section":"§4.1"},{"comment":"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.","section":"Figures 6 and 8"},{"comment":"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.","section":"References"},{"comment":"The 'Berkeley libbf' library is actually 'libbf' by Mavam (the URL in reference [25] contains spaces); this should be corrected.","section":"§4.1"}],"recommendation":"reject","confidential_remarks":"The manuscript has useful datasets and an honest measurement effort, but the core claims are not defensible. The Bitcoin variant's relay failure is a fundamental design flaw that cannot be patched without introducing a raw-transaction cache, which would invalidate the 2 MB memory claim. The accuracy numbers in Tables 1 and 2 also falsify the 'over 99.99%' statement as written. A substantial redesign and rewrite would be needed, and even then the contribution would be a more limited one."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague, here's the read on Neonpool.\n\nThe genuinely new thing is the target: applying Bloom filters to the transaction pool's inventory to cut RAM, and dissociating inventory from raw-transaction storage. The authors also did real work: two ~10M-transaction datasets, instrumented Bitcoin Core and Geth, public code, and honest reporting of empirical FPR/FNR, including the ugly 60-80% FPR when the filter is allowed to overflow.\n\nThe soft spot is not the error rates; it's the Bitcoin relay design. In Bitcoin, a node announces a txHash and then must serve the raw transaction on getdata. Neonpool-BTC stores only the txHash and says operators are not required to store full transactions. That means the node cannot answer getdata, so it cannot actually propagate anything. The paper never introduces a raw-transaction cache or an alternative relay mechanism. That is a load-bearing gap: the 400MB-to-2MB comparison omits the storage required to perform the forwarding function the paper claims to preserve. The Ethereum variant is less broken because relay is push-based, but it still needs the transaction in memory at the moment of relay, so the memory story is under-specified there too.\n\nThe 99.99% accuracy claim is also overly generous. It only holds for decay settings with a high decay factor; the basic filter without expiry rejects 60-80% of valid transactions, and with 24h clearing a 1MB filter has FPR ~1.9e-3, which is 99.81%, not 99.99%. The decay settings that get FPR down to 1e-5 come with ~0.6% FNR, meaning lots of redundant reprocessing. The paper acknowledges this in the tables but not in the abstract.\n\nOverall: the idea is worth serious discussion, and the datasets could be useful to the community. But as written, the central claim for Bitcoin does not hold up under the actual relay protocol. This needs major revision, not a touch-up. I'd send it to review because the topic is new and the empirical base is real, but a careful referee should push hard on the relay question before the memory numbers are taken seriously.","headline":"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.","tokens_in":22033,"tokens_out":3836,"would_cite":false,"duration_ms":36124,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Neonpool claims a 400 MB transaction pool can shrink to 2 MB using Bloom-filter fingerprints while keeping over 99.99% accuracy.","keywords":["transaction pool","Bloom filter","memory optimization","lightweight clients","IoT devices","Bitcoin","Ethereum","double-spend detection"],"falsifier":"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.","tokens_in":21039,"feed_emoji":"🪙","tokens_out":7609,"duration_ms":66433,"temperature":0.7,"pith_summary":"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.","feed_headline":"Tx-pool memory cut from 400 MB to 2 MB, paper claims","feed_subtitle":"Two Bloom filters replace full transaction storage while keeping 99.99% accuracy, no hard fork needed.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the Bloom filter, the data structure whose space/error trade-off is the basis of Neonpool's memory savings.","marker":"[38]"},{"why":"The C++ Bloom-filter library used to build and benchmark Neonpool-BTC and Neonpool-ETH.","marker":"[25]"},{"why":"Documents the 2015 spam attack that inflated the Bitcoin mempool to roughly 1 GB and crashed memory-constrained nodes, motivating the need for a compact pool.","marker":"[7]"},{"why":"Source for Bitcoin's 300 MB default mempool cap, used as the baseline for the Bitcoin memory comparison.","marker":"[47]"},{"why":"Source for Ethereum's 4,096-transaction default cap and eviction policy, used as the baseline for the Ethereum comparison.","marker":"[24]"},{"why":"Shows how random salt makes Bloom filters resistant to adversarial queries, supporting Neonpool's per-node randomization for security.","marker":"[13]"},{"why":"Reports roughly 99% content similarity across Bitcoin mempools, used to argue that per-node filter errors largely cancel out at the network level.","marker":"[14]"},{"why":"Supplies the taxonomy and light-client security assumptions against which Neonpool positions itself.","marker":"[18]"}],"fun_headline_variants":["Neonpool: 99.99% accurate tx-pool, 200x less memory","Tx-pool memory from 400MB to 2MB using Bloom filters","Lightweight crypto tx-pool for IoT with no hard fork","Bloom-filter tx-pool cuts memory 200x for light clients","Neonpool shrinks tx-pool memory 200x without hard fork"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Neonpool: 99.99% accurate tx-pool, 200x less memory","Tx-pool memory from 400MB to 2MB using Bloom filters","Lightweight crypto tx-pool for IoT with no hard fork","Bloom-filter tx-pool cuts memory 200x for light clients","Neonpool shrinks tx-pool memory 200x without hard fork"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000501,"raw_usage":{"total_tokens":2375,"prompt_tokens":795,"completion_tokens":1580,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":411,"completion_tokens_details":{"reasoning_tokens":1480}},"tokens_in":411,"tokens_out":1580,"duration_ms":9921,"temperature":1.0,"reasoning_tokens":1480,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T13:06:59.074057+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the Bloom filter, the data structure whose space/error trade-off is the basis of Neonpool's memory savings."},{"cited_title":"Available at:h t tp : //mavam.github.io/libbf","cited_arxiv_id":null,"evidence_quote":"The C++ Bloom-filter library used to build and benchmark Neonpool-BTC and Neonpool-ETH."},{"cited_title":"stresstesting","cited_arxiv_id":null,"evidence_quote":"Documents the 2015 spam attack that inflated the Bitcoin mempool to roughly 1 GB and crashed memory-constrained nodes, motivating the need for a compact pool."},{"cited_title":"P2P Network Guide - Bitcoin","cited_arxiv_id":null,"evidence_quote":"Source for Bitcoin's 300 MB default mempool cap, used as the baseline for the Bitcoin memory comparison."},{"cited_title":"GitHub, 2023","cited_arxiv_id":null,"evidence_quote":"Source for Ethereum's 4,096-transaction default cap and eviction policy, used as the baseline for the Ethereum comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows how random salt makes Bloom filters resistant to adversarial queries, supporting Neonpool's per-node randomization for security."},{"cited_title":"Examining Bitcoin mempools Resemblance Using Jaccard Similarity Index,","cited_arxiv_id":null,"evidence_quote":"Reports roughly 99% content similarity across Bitcoin mempools, used to argue that per-node filter errors largely cancel out at the network level."},{"cited_title":"SoK: Blockchain light clients,","cited_arxiv_id":null,"evidence_quote":"Supplies the taxonomy and light-client security assumptions against which Neonpool positions itself."}],"review_version":1}