Posted by nothingmuch
Mar 31, 2026/22:32 UTC
The discussion revolves around implementing a specification for wallet software that addresses both current and potential future issues as cryptocurrency usage scales. The primary goal is to ensure that the implementation is safe and effective, mitigating problems before they exacerbate. One suggested approach involves initially demonstrating a commitment to resolving the issue, which could help in rallying support and resources towards this cause. Additionally, if SIGHASH_NONE becomes problematic with increased adoption, advocating for a narrow policy carve-out could be a solution to consider, specifically targeting the elimination of empty versus 3 vbyte OP_RETURN discrepancies.
Looking at long-term solutions, the integration of implicit aggregation into mempool code is proposed. This integration would simplify wallet implementations by always broadcasting transactions with one input, thereby optimizing blockspace costs and eliminating Denial-of-Service (DoS) concerns associated with transaction replacement logic. However, such changes are complex and could take years to implement, assuming there's sufficient demand and buy-in from relevant stakeholders.
Further examination of the proposed Bitcoin Improvement Proposal (BIP) text reveals some concerns about prohibiting coin aggregation from a single wallet. This restriction might be overly stringent considering existing mechanisms like PR 29415 (-privatebroadcast=1), which can simulate independent party aggregation. In scenarios where -privatebroadcast=1 or Tor daemon is unavailable, the risk of dust attack strategies, where an adversary monitors rebroadcasts of received dust transactions, persists. It's argued that enhancing the rationale in the BIP text to discuss how privatebroadcast alters the threat model could be beneficial. Moreover, issues related to spending dust coins from distinct addresses need addressing, particularly since adversaries can exploit information about the absence of prior transactions involving only one address.
Lastly, the use of third-party aggregators to buffer and batch broadcast transactions could imply coin relationship, similar to the common input ownership heuristic used in clustering data. This method, while potentially complicating data accuracy, could inadvertently enhance user privacy and fungibility by introducing misinformation ("cluster collapse") into clustering analysis, as observed in cases like the MtGoxAndOthers supercluster on wallet explorer sites.
Thread Summary (34 replies)
Jan 25 - May 16, 2026
35 messages
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback