* [bitcoindev] Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency
@ 2025-06-16 9:57 wang wang
2025-07-29 22:55 ` Murch
0 siblings, 1 reply; 2+ messages in thread
From: wang wang @ 2025-06-16 9:57 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3620 bytes --]
Dear Bitcoin developers,
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.
---
**Background**
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:
- the transaction is not mined,
- it gets dropped from the mempool (e.g. due to eviction),
- or the transaction becomes part of a stale/orphaned block.
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.
---
**Proposal**
I propose a new opt-in mechanism called the *Self-Verifiable Transaction
Broadcast Log*. When enabled, this feature would:
- Record any transaction that a node accepts for broadcast (via P2P or
RPC), along with a timestamp and source;
- Optionally allow filtering by address or wallet;
- Provide a new RPC call (e.g., `getbroadcastedtxs`) to retrieve this
information;
- Help users and wallets verify that a transaction existed — even if it was
later dropped, reorganized, or not confirmed.
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.
---
**Motivation and Urgency**
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.
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.
---
**Initial BIP Draft**
I’ve drafted a preliminary BIP here:
> [GitHub Gist / Link to PR - will insert final link here]
---
**Request for Feedback**
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:
- Would such a feature add meaningful user transparency and auditability?
- Are there concerns about wallet behavior, privacy, or implementation
complexity?
- Should logs be stored in-memory or disk by default?
- Would wallet software (like Core, Specter, Sparrow) benefit from exposing
this to users?
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).
Warm regards,
liang
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4072 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoindev] Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency
2025-06-16 9:57 [bitcoindev] Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency wang wang
@ 2025-07-29 22:55 ` Murch
0 siblings, 0 replies; 2+ messages in thread
From: Murch @ 2025-07-29 22:55 UTC (permalink / raw)
To: bitcoindev
Hello Liang,
It would make more sense to me if this were proposed as a feature
request to a specific software project, rather than a BIP, but node
implementations already have logging for transaction relay and
transaction evaluation. However, in the long-term only confirmed
transactions are relevant to the shared state of the network. Keeping
information about unconfirmed transactions indefinitely is impractical
and not useful to most nodes.
I’m not sure I fully understand your motivation. If your transaction was
valid, but you cannot find any record of it, how do you know that it was
valid? How did you know to look for it? If your own node presents it to
you, your node has a copy of it that you can retrieve or rebroadcast.
Were you the sender or recipient of this transaction? Is it possible
that someone created a payment to you that they later rescinded by
replacing the transaction?
If you have further questions, this topic might be a better fit for
e.g., https://bitcoin.stackexchange.com instead of this mailing list.
Murch
On 2025-06-16 02:57, wang wang wrote:
> Dear Bitcoin developers,
>
> 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.
>
> ---
>
> **Background**
>
> 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:
>
> - the transaction is not mined,
> - it gets dropped from the mempool (e.g. due to eviction),
> - or the transaction becomes part of a stale/orphaned block.
>
> 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.
>
> ---
>
> **Proposal**
>
> I propose a new opt-in mechanism called the *Self-Verifiable
> Transaction Broadcast Log*. When enabled, this feature would:
>
> - Record any transaction that a node accepts for broadcast (via P2P or
> RPC), along with a timestamp and source;
> - Optionally allow filtering by address or wallet;
> - Provide a new RPC call (e.g., `getbroadcastedtxs`) to retrieve this
> information;
> - Help users and wallets verify that a transaction existed — even if
> it was later dropped, reorganized, or not confirmed.
>
> 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.
>
> ---
>
> **Motivation and Urgency**
>
> 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.
>
> 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.
>
> ---
>
> **Initial BIP Draft**
>
> I’ve drafted a preliminary BIP here:
> > [GitHub Gist / Link to PR - will insert final link here]
>
> ---
>
> **Request for Feedback**
>
> 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:
>
> - Would such a feature add meaningful user transparency and auditability?
> - Are there concerns about wallet behavior, privacy, or implementation
> complexity?
> - Should logs be stored in-memory or disk by default?
> - Would wallet software (like Core, Specter, Sparrow) benefit from
> exposing this to users?
>
> 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).
>
> Warm regards,
> liang
>
> --
> You received this message because you are subscribed to the Google
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b7f915b6-a4a4-4c8d-811a-70cfdb761565%40murch.one.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-07-29 23:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-06-16 9:57 [bitcoindev] Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency wang wang
2025-07-29 22:55 ` Murch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox