Dear Bitcoin developers,<br /><br />I’d like to propose a modest but meaningful improvement to Bitcoin node software that addresses a real-world user issue involving orphaned or dropped transactions: a local broadcast log for transactions that a node has accepted and attempted to propagate.<br /><br />---<br /><br />**Background**<br /><br />There is currently no robust way for users to prove or verify that a transaction was ever seen, accepted, or propagated by the Bitcoin network — especially in cases where:<br /><br />- the transaction is not mined,<br />- it gets dropped from the mempool (e.g. due to eviction),<br />- or the transaction becomes part of a stale/orphaned block.<br /><br />In such cases, users who possess the private key for an address might find no trace of their transaction on-chain or in the mempool — effectively losing any record that it was ever broadcast. This can result in perceived "disappearance" or "freezing" of funds, and is especially problematic for privacy-focused or air-gapped users who do not maintain full mempool logs.<br /><br />---<br /><br />**Proposal**<br /><br />I propose a new opt-in mechanism called the *Self-Verifiable Transaction Broadcast Log*. When enabled, this feature would:<br /><br />- Record any transaction that a node accepts for broadcast (via P2P or RPC), along with a timestamp and source;<br />- Optionally allow filtering by address or wallet;<br />- Provide a new RPC call (e.g., `getbroadcastedtxs`) to retrieve this information;<br />- Help users and wallets verify that a transaction existed — even if it was later dropped, reorganized, or not confirmed.<br /><br />This does not change any consensus behavior, and the log can be locally managed and purged by the user. It is purely a UX and auditability improvement, similar in spirit to how `debug.log` can assist with debugging but more structured and purpose-built.<br /><br />---<br /><br />**Motivation and Urgency**<br /><br />This proposal stems from a real personal experience: having a valid signed transaction broadcast via a node, but later being unable to locate it anywhere — not in the mempool, not in the blockchain, and not recoverable from most block explorers. I still hold the private key, yet I cannot prove (to myself or anyone else) that the transaction ever existed.<br /><br />This opens the door to transaction censorship or selective orphaning by powerful actors (e.g. mining pools or state actors), without leaving user-verifiable traces.<br /><br />---<br /><br />**Initial BIP Draft**<br /><br />I’ve drafted a preliminary BIP here:<br />&gt; [GitHub Gist / Link to PR - will insert final link here]<br /><br />---<br /><br />**Request for Feedback**<br /><br />Before submitting the BIP as a formal PR or implementation patch, I’d like to ask for early feedback from the community on the following:<br /><br />- Would such a feature add meaningful user transparency and auditability?<br />- Are there concerns about wallet behavior, privacy, or implementation complexity?<br />- Should logs be stored in-memory or disk by default?<br />- Would wallet software (like Core, Specter, Sparrow) benefit from exposing this to users?<br /><br />I look forward to hearing your thoughts and criticisms. If there's interest, I will follow up with a reference implementation for Bitcoin Core (v25+ compatible).<br /><br />Warm regards,  <br />liang  <br /><br />

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com</a>.<br />