From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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,

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 />
---

**Background**

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:

- the transaction is not mined,
- it gets dropped fr= om the mempool (e.g. due to eviction),
- or the transaction becomes pa= rt of a stale/orphaned block.

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.

---

**Pro= posal**

I propose a new opt-in mechanism called the *Self-Verifi= able Transaction Broadcast Log*. When enabled, this feature would:
- Record any transaction that a node accepts for broadcast (via P2P or R= PC), along with a timestamp and source;
- Optionally allow filtering b= y address or wallet;
- Provide a new RPC call (e.g., `getbroadcastedtx= s`) to retrieve this information;
- Help users and wallets verify that= a transaction existed =E2=80=94 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 U= X and auditability improvement, similar in spirit to how `debug.log` can as= sist 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 =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.

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.

= ---

**Initial BIP Draft**

I=E2=80=99ve drafted a prel= iminary BIP here:
> [GitHub Gist / Link to PR - will insert final l= ink here]

---

**Request for Feedback**

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:
- Would such a feature add meaningful user transparency and auditabilit= y?
- Are there concerns about wallet behavior, privacy, or implementat= ion complexity?
- 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?

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).

Warm regards, =C2=A0=
liang =C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/981ea514-60ee-462b-92f3-4570aa6483b0n%40googlegroups.com.
------=_Part_439893_1523245696.1750067820461-- ------=_Part_439892_137635416.1750067820461--