path: root/54/d9977c01bb8742fcc84e8b7781f07137aeb659

Delivery-date: Tue, 17 Jun 2025 15:36:52 -0700
Received: from mail-yw1-f192.google.com ([209.85.128.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCW5ZCHFDEIPTW6HYIDBUBENYXXGS@googlegroups.com>)
	id 1uRevD-0005P7-Na
	for bitcoindev@gnusha.org; Tue, 17 Jun 2025 15:36:52 -0700
Received: by mail-yw1-f192.google.com with SMTP id 00721157ae682-71102417325sf6934787b3.2
        for <bitcoindev@gnusha.org>; Tue, 17 Jun 2025 15:36:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750199806; x=1750804606; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/2Tb/UbkPQNipkKAPQ5+Z+oISk522U38k1npRIP68cQ=;
        b=mAAvEOURstOX9sNtKBMrEcPwhSR2LInsq+Np80fZbxhjTXhy9HLWfAXnCtFZckgpSR
         6vynjnO9k11I3/rVR3dHMmozgFO6t/7Qb8X1Tbt2zbDtjZPzSJrZA/giEoBDdt7hc6VD
         PPwdcPqlBt0Hf++ORmIdZBLDMXncjQoONpgqlh4FdFa6KSJPeo5N0NPt9uen7lyLb6MJ
         cIWnDlje3rU9sxV9D87LKkjF/Q2dxYg8WSIWlG8OakYtICVqt9e3xKjCPVXbS+6jgJq3
         5T305CFeBz2oCd83s6Do9717gKoWs15EARL4w+gGw92yqRP0Qp0XZeCdxVdHqGxGvNWj
         tyBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750199806; x=1750804606; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/2Tb/UbkPQNipkKAPQ5+Z+oISk522U38k1npRIP68cQ=;
        b=F4esAAqO+CmWDejytexKUKrVyH70nabmTeNDZhtI16gzPoLKPuAA6SkaQ9Bfj+GSy1
         5pkfegZJ/6yTbLP833pS4jY6jSCaFYq8/7PLOYdWPGm6OJnlBp1tQmaohH8RJDAILsUl
         cunoig/L7GEHW4J0dM2KrbL+U0EGvot+iuw9dwSo5l5uZjIJc94qGlbi7IhIJgLhh/X8
         zHppuzSV67NaWTMKw78m66sBI7YsqdGjSlPhvCDtVbHnziaZlTebOTzvc3p+5JpXQp5E
         P9KIQ8mB9Sjwpspxd7pmetSunds1kUqq8m0Kt8xg2WR+PM3leec8ui3tyZ1AdxIOqDpM
         xJog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750199806; x=1750804606;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=/2Tb/UbkPQNipkKAPQ5+Z+oISk522U38k1npRIP68cQ=;
        b=phde0jR0S6OlHgzZkEe0rfdbTFfQa47QnT5nNmvv9XjGy9HUncs8oaXNdouYEq9XO2
         RxpT9IN2CtMhMDTg5XZuYMFhdg54cfpK/iAsQq6q9l9q3+r68kl6dKAZPA+wR+6WlHCg
         ifqOzMeoA8mUBMMxH2OF/zhNGqDNwW1BtjEWcaOntCoTKNH1gtlZke7PpQQ3JjNKG2f/
         sfpvLGEI6sKEvrDeYUycQLCDpIteAxFE8poUVSjy3hi1fDNru1bkRk7Jcbc3RWDQbdPu
         FlELY61tgiTBWXuHcDI2ielE8Pxu/0CO9WtGCYfMrrSyJPLrbz1VQ7T9ZIZw51w/nAhf
         6Svw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWBXb9WCRAqY3mqc46GzyTvAdbvIYCi/i+oQC2D/qgXqpbbVduUgElNlANCyjjnN+wmMWQeDMj07BTB@gnusha.org
X-Gm-Message-State: AOJu0YxRP8pRkKzLL2qCBCt5lBasZBthjMBUkLw08rp7R3gUjDdBTqeD
	divV7QEz1NIN2va36+IPV/9DlqtFmdRBE8IzJevdmLW5LzgFA792H5LG
X-Google-Smtp-Source: AGHT+IGbJPt9G5nEQ8JQMML5VNVoSh+dkASIjij2+MpTFmmdgBmAWkty6REQjweGNDg7z/S//hkmsw==
X-Received: by 2002:a05:690c:ed6:b0:70e:7613:e365 with SMTP id 00721157ae682-7117538be15mr96548907b3.3.1750199805814;
        Tue, 17 Jun 2025 15:36:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeJeO0x4bIIWloy51IUhBQXqmsqBMkLAmsa3UPtfW9crw==
Received: by 2002:a5b:5c9:0:b0:e7d:801a:4dd6 with SMTP id 3f1490d57ef6-e8229065b06ls3864574276.0.-pod-prod-05-us;
 Tue, 17 Jun 2025 15:36:41 -0700 (PDT)
X-Received: by 2002:a05:690c:6085:b0:710:a3d4:ed39 with SMTP id 00721157ae682-71175462e17mr238600137b3.35.1750199801549;
        Tue, 17 Jun 2025 15:36:41 -0700 (PDT)
Received: by 2002:a05:690c:3149:b0:711:63b1:720 with SMTP id 00721157ae682-71163b129c5ms7b3;
        Mon, 16 Jun 2025 02:57:02 -0700 (PDT)
X-Received: by 2002:a05:690c:1d:b0:6fb:1e5a:fcdd with SMTP id 00721157ae682-7117541c670mr104698277b3.17.1750067821379;
        Mon, 16 Jun 2025 02:57:01 -0700 (PDT)
Date: Mon, 16 Jun 2025 02:57:00 -0700 (PDT)
From: wang wang <wang2704ca@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <981ea514-60ee-462b-92f3-4570aa6483b0n@googlegroups.com>
Subject: [bitcoindev] Proposal: Self-Verifiable Transaction Broadcast Log for
 Enhanced User Transparency
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_439892_137635416.1750067820461"
X-Original-Sender: wang2704ca@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_439892_137635416.1750067820461
Content-Type: multipart/alternative; 
	boundary="----=_Part_439893_1523245696.1750067820461"

------=_Part_439893_1523245696.1750067820461
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Bitcoin developers,

I=E2=80=99d like to propose a modest but meaningful improvement to Bitcoin =
node=20
software that addresses a real-world user issue involving orphaned or=20
dropped transactions: a local broadcast log for transactions that a node=20
has accepted and attempted to propagate.

---

**Background**

There is currently no robust way for users to prove or verify that a=20
transaction was ever seen, accepted, or propagated by the Bitcoin network =
=E2=80=94=20
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=
=20
no trace of their transaction on-chain or in the mempool =E2=80=94 effectiv=
ely=20
losing any record that it was ever broadcast. This can result in perceived=
=20
"disappearance" or "freezing" of funds, and is especially problematic for=
=20
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=20
Broadcast Log*. When enabled, this feature would:

- Record any transaction that a node accepts for broadcast (via P2P or=20
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=20
information;
- Help users and wallets verify that a transaction existed =E2=80=94 even i=
f it was=20
later dropped, reorganized, or not confirmed.

This does not change any consensus behavior, and the log can be locally=20
managed and purged by the user. It is purely a UX and auditability=20
improvement, similar in spirit to how `debug.log` can assist with debugging=
=20
but more structured and purpose-built.

---

**Motivation and Urgency**

This proposal stems from a real personal experience: having a valid signed=
=20
transaction broadcast via a node, but later being unable to locate it=20
anywhere =E2=80=94 not in the mempool, not in the blockchain, and not recov=
erable=20
from most block explorers. I still hold the private key, yet I cannot prove=
=20
(to myself or anyone else) that the transaction ever existed.

This opens the door to transaction censorship or selective orphaning by=20
powerful actors (e.g. mining pools or state actors), without leaving=20
user-verifiable traces.

---

**Initial BIP Draft**

I=E2=80=99ve 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=E2=80=
=99d like=20
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=20
complexity?
- Should logs be stored in-memory or disk by default?
- Would wallet software (like Core, Specter, Sparrow) benefit from exposing=
=20
this to users?

I look forward to hearing your thoughts and criticisms. If there's=20
interest, I will follow up with a reference implementation for Bitcoin Core=
=20
(v25+ compatible).

Warm regards, =20
liang =20

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com.

------=_Part_439893_1523245696.1750067820461
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Bitcoin developers,<br /><br />I=E2=80=99d like to propose a modest bu=
t meaningful improvement to Bitcoin node software that addresses a real-wor=
ld 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 r=
obust way for users to prove or verify that a transaction was ever seen, ac=
cepted, or propagated by the Bitcoin network =E2=80=94 especially in cases =
where:<br /><br />- the transaction is not mined,<br />- it gets dropped fr=
om the mempool (e.g. due to eviction),<br />- or the transaction becomes pa=
rt of a stale/orphaned block.<br /><br />In such cases, users who possess t=
he private key for an address might find no trace of their transaction on-c=
hain or in the mempool =E2=80=94 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 u=
sers who do not maintain full mempool logs.<br /><br />---<br /><br />**Pro=
posal**<br /><br />I propose a new opt-in mechanism called the *Self-Verifi=
able Transaction Broadcast Log*. When enabled, this feature would:<br /><br=
 />- Record any transaction that a node accepts for broadcast (via P2P or R=
PC), along with a timestamp and source;<br />- Optionally allow filtering b=
y address or wallet;<br />- Provide a new RPC call (e.g., `getbroadcastedtx=
s`) to retrieve this information;<br />- Help users and wallets verify that=
 a transaction existed =E2=80=94 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 U=
X and auditability improvement, similar in spirit to how `debug.log` can as=
sist with debugging but more structured and purpose-built.<br /><br />---<b=
r /><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 =E2=80=94 not in the me=
mpool, 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 els=
e) that the transaction ever existed.<br /><br />This opens the door to tra=
nsaction 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=E2=80=99ve drafted a prel=
iminary BIP here:<br />&gt; [GitHub Gist / Link to PR - will insert final l=
ink here]<br /><br />---<br /><br />**Request for Feedback**<br /><br />Bef=
ore submitting the BIP as a formal PR or implementation patch, I=E2=80=99d =
like to ask for early feedback from the community on the following:<br /><b=
r />- Would such a feature add meaningful user transparency and auditabilit=
y?<br />- Are there concerns about wallet behavior, privacy, or implementat=
ion complexity?<br />- Should logs be stored in-memory or disk by default?<=
br />- Would wallet software (like Core, Specter, Sparrow) benefit from exp=
osing 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 impleme=
ntation for Bitcoin Core (v25+ compatible).<br /><br />Warm regards, =C2=A0=
<br />liang =C2=A0<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 e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com</a>.<br />

------=_Part_439893_1523245696.1750067820461--

------=_Part_439892_137635416.1750067820461--