From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 29 Jul 2025 16:27:04 -0700 Received: from mail-oo1-f61.google.com ([209.85.161.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ugtiq-0007BM-77 for bitcoindev@gnusha.org; Tue, 29 Jul 2025 16:27:04 -0700 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-6195f7f9ad7sf348786eaf.1 for ; Tue, 29 Jul 2025 16:27:04 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1753831618; cv=pass; d=google.com; s=arc-20240605; b=VEYyl55C7Qbx0potQ266k7R3Wh05KC8AJcxXFsfRWtvB0PJEg22UJk+e3mer5P8zJE PDd5ves0yjPdDfy2+UvD1xSd0MIzAj4VXSOh2OMJMX50moGH2ckoyGarUsPgbnU0lETo vpeQH81J30uFNaKKo6xkWByMJPBWlKvQgGwOI/UZIGWIDMNgt8nkaScccfc1aBkZQQLw hz3Na4C69NHkqRWeiMwE2MXg6rhEbdCo2/Q32C76BL/nckjydxBhtZkbdxR2QnK67nZd iXQajS92KRJ70RlS50V9CGC0D5+s+Wf5w8qFihkSbTLgL6SvtwWF24rIwbEEead0ETfu RCYw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=Tf4Xoww7Ecgkfn1t184TqGTcf60tiNIn0xLuu+m7PeM=; fh=s2TQ5TfcIxxwSCpEOupEUVtCHKPTC0YtNMvUysxXPm0=; b=GRkzZnjeecy3PlxE/J7pdka8COXa/WWZ2TKOF/kLGGk7WYtlA3/6/P/sJJKhozjC0h rDgtozW6VX1SDNc4oCrSBSH0EU2HzAlS+zNU+af1bxAHSXRcFlM1Ayzcva/lrrOwzW8h B5MU3QWCVf+Vhbany754YuDuEqh1RTTsiGAjIUZ9zuopZyt2BWkc4wtZ1I3azhC505IV mHHwm8OnGgDt9mUiFP1mJB2ivxJJDEaOm3hmHBLjGY9IgrbEBtDZVcaLF/puHt8/9rMF 1t9w7a2aaMB7CaKtGQmZmWXCB4sRNUOAEskg1HfRO5VtWSboOR3YJ+/hwBZTTJ1zRaH+ QY/w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=L8NtU4WM; spf=pass (google.com: domain of murch@murch.one designates 185.26.156.114 as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1753831618; x=1754436418; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=Tf4Xoww7Ecgkfn1t184TqGTcf60tiNIn0xLuu+m7PeM=; b=MVyKWcWu1XK9NrqwygAmKsUtW98keCi6w/p5rGTEnTe83D4oPSMBcZLsoejW5XBQzm kbVS8S2vjZVPwhxGklXN2hry0VCWf4N3a/yNWuW84DFWKVSmlYR2DfrJGOm6EgG76wS5 k2MnaV0lJQ08qotetoL8IBSpcrrY7ozkja7ZaRf0H42M/Ag6qBH7BFAVPIc9b+X2o50Y Js6ozb+tWlqhQTNiiH/Epr/RRkaLu4skAzriELUnbd2Yz1QOoqBCl0elZ59BuGdeZaGI iD4a0OPCeQASsStQjnFiVC2LNdQz/fZZmY/wEYNmi50SGoSfjtM6qsovieuSgNOPhj1i Eu9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753831618; x=1754436418; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=Tf4Xoww7Ecgkfn1t184TqGTcf60tiNIn0xLuu+m7PeM=; b=feezeZs2/QpCqcV3GInVreQxs8xRx3BEQ2BHSQGw1y3KeQUqduuyoPKE94tvwrc+sA 3gD+7ha4VvM1uYN8IojiBTbxPN2V2ashIOKcGmGLyUnmUTodrayLs3sr0n/+jvX9uhBN VkIznjEgUuWLqkrlAqB2JU8T9xc2hjqR7fterghym4qGXev5NP90hBoF/y2rb8xfZlcm pFVkiv4ernS5UvSqzooU8iHkrlVXW1ilk5pkIWQwv19psYxdll2qy6KKC5CU/Tnwvl4c wsluPK2jTIzuuy4WKWb3LwZZpLKUU7mk5tbHXJouX02eTYwPZAROy2ByFZw6GvCRMfQd 33TA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVle/jPfNwWWzRiBkxzl5zAI0xRyPjwCddnfDfxcw+PedwqbupbqNPFEwBBKTllpvvlbPKNMdj1FDBx@gnusha.org X-Gm-Message-State: AOJu0YzTxbsdUm5+Ks5vMKJyGgyQA3abWX2qsWmVaYRHMuROtr3sCE7G /MpuZBU8lVcW2qvzRd31KT6XQJ5sbPjygVr/StXwLHbXQkq+yWzYP4E+ X-Google-Smtp-Source: AGHT+IHOPAc6UsIOHEyZBVGHjXjV+qNiCPJGhMMXE4u0TIWToKXUr/7m3VSKy5kf4PjHTfR7sEg42Q== X-Received: by 2002:a05:6870:1583:b0:2ff:96c6:f712 with SMTP id 586e51a60fabf-30785c3cad0mr794740fac.26.1753831618036; Tue, 29 Jul 2025 16:26:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc2sHEPG7LrZQm0RHy7Rga5DQNm5LBOafi+IvN8mA7opQ== Received: by 2002:a05:6871:8114:b0:2e9:9a5a:7609 with SMTP id 586e51a60fabf-306ddbc34a5ls3865173fac.1.-pod-prod-01-us; Tue, 29 Jul 2025 16:26:55 -0700 (PDT) X-Received: by 2002:a05:6808:1a04:b0:404:ed0d:79e5 with SMTP id 5614622812f47-4319b81f2camr935302b6e.30.1753831614934; Tue, 29 Jul 2025 16:26:54 -0700 (PDT) Received: by 2002:a50:d558:0:b0:615:6763:fc63 with SMTP id 4fb4d7f45d1cf-61587262245msa12; Tue, 29 Jul 2025 15:55:45 -0700 (PDT) X-Received: by 2002:a17:907:3d03:b0:ae6:d48e:f18d with SMTP id a640c23a62f3a-af7b502040dmr633730566b.12.1753829742815; Tue, 29 Jul 2025 15:55:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1753829742; cv=none; d=google.com; s=arc-20240605; b=jrc7BvchkiVXWgPvAWdcKYskutRLQSHHnxQ8Qy0tmpogKvFofD8KD5wPhCEaFZk9A+ Cti3BRAa18hqIRxcO9U/zenWt3WOfnUhWWTTv0rBKHvKk+JN6k3hrkj3tY2ANJ9hJcsS C8UYzT8Vs7dSBjgCixEfgodt8qiypmnCNTPp8sfdhbyr0DwJ3myjAnMkBqk8UTuqsTwQ +89iLGFb1WeNmmg/NsTccHP0xPaJUaZ0nXqFvbcb0hUU6NYW2hKCQX4aItmo9iax00BJ TaxYL4GDV3n//dRqT22pDsq+RPdJcV9ymTwZG1WHSDNNItBwKwV8njF49vVuMLh/HjrY Q2Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id; bh=ygoPuQhPu6u6jwyiZ7sBvDcwTrr7B2Ml0UHGPl5bGHM=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=e06TV+XfEQs6gnR2sFUFC+HaGk+2hXxlPt+ePCJqLxnNj30LAb5HkngHztbmisROJD +0pp3aWg74+4E4IJbCHP2zkSOc/s1voO0drzDcl/qI7D2OUp423gfhiqd3DJzBq7UneL cHKlcWuRkYGJC+052UOHdI3wIptLse6zUT+x8PLScuOJ3AMWMyQEv5+ovGIV8bD/Kr9C AIvOh1ZfpaarQejsoecf7qNodKt5p3uyiPjZ4JosY45KJrzOE5lEPc6b31KekuhZPFyP hFT/dVf4x+1cYX9W04aYtNp9OFTRYPUjxMcE0byhEVOH9ITT1iVft8JhHru0fee4lThn pqCw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=L8NtU4WM; spf=pass (google.com: domain of murch@murch.one designates 185.26.156.114 as permitted sender) smtp.mailfrom=murch@murch.one Received: from mailgate02.uberspace.is (mailgate02.uberspace.is. [185.26.156.114]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-af6358b5b62si20795366b.1.2025.07.29.15.55.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Jul 2025 15:55:42 -0700 (PDT) Received-SPF: pass (google.com: domain of murch@murch.one designates 185.26.156.114 as permitted sender) client-ip=185.26.156.114; Received: from mailgate01.uberspace.is (mailgate01.uberspace.is [IPv6:2001:1a50:11:0:c83f:a8ff:fea6:c8da]) by mailgate02.uberspace.is (Postfix) with ESMTPS id 7B7FC1801A1 for ; Wed, 30 Jul 2025 00:55:42 +0200 (CEST) Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by mailgate01.uberspace.is (Postfix) with ESMTPS id 66F2960195 for ; Wed, 30 Jul 2025 00:55:42 +0200 (CEST) Received: (qmail 19790 invoked by uid 989); 29 Jul 2025 22:55:42 -0000 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA; Wed, 30 Jul 2025 00:55:42 +0200 Message-ID: Date: Tue, 29 Jul 2025 15:55:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bitcoindev] Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency To: bitcoindev@googlegroups.com References: <981ea514-60ee-462b-92f3-4570aa6483b0n@googlegroups.com> Content-Language: en-US From: Murch In-Reply-To: <981ea514-60ee-462b-92f3-4570aa6483b0n@googlegroups.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-3) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.09 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=L8NtU4WM; spf=pass (google.com: domain of murch@murch.one designates 185.26.156.114 as permitted sender) smtp.mailfrom=murch@murch.one 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.8 (/) Hello Liang, It would make more sense to me if this were proposed as a feature=20 request to a specific software project, rather than a BIP, but node=20 implementations already have logging for transaction relay and=20 transaction evaluation. However, in the long-term only confirmed=20 transactions are relevant to the shared state of the network. Keeping=20 information about unconfirmed transactions indefinitely is impractical=20 and not useful to most nodes. I=E2=80=99m not sure I fully understand your motivation. If your transactio= n was=20 valid, but you cannot find any record of it, how do you know that it was=20 valid? How did you know to look for it? If your own node presents it to=20 you, your node has a copy of it that you can retrieve or rebroadcast.=20 Were you the sender or recipient of this transaction? Is it possible=20 that someone created a payment to you that they later rescinded by=20 replacing the transaction? If you have further questions, this topic might be a better fit for=20 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=E2=80=99d like to propose a modest but meaningful improvement to Bitcoi= n=20 > node software that addresses a real-world user issue involving=20 > orphaned or dropped transactions: a local broadcast log for=20 > 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=20 > transaction was ever seen, accepted, or propagated by the Bitcoin=20 > network =E2=80=94 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=20 > find no trace of their transaction on-chain or in the mempool =E2=80=94= =20 > effectively losing any record that it was ever broadcast. This can=20 > result in perceived "disappearance" or "freezing" of funds, and is=20 > especially problematic for privacy-focused or air-gapped users who do=20 > not maintain full mempool logs. > > --- > > **Proposal** > > I propose a new opt-in mechanism called the *Self-Verifiable=20 > Transaction 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= if=20 > it was later dropped, reorganized, or not confirmed. > > This does not change any consensus behavior, and the log can be=20 > locally managed and purged by the user. It is purely a UX and=20 > auditability improvement, similar in spirit to how `debug.log` can=20 > assist with debugging but more structured and purpose-built. > > --- > > **Motivation and Urgency** > > This proposal stems from a real personal experience: having a valid=20 > signed transaction broadcast via a node, but later being unable to=20 > locate it anywhere =E2=80=94 not in the mempool, not in the blockchain, a= nd=20 > not recoverable from most block explorers. I still hold the private=20 > key, yet I cannot prove (to myself or anyone else) that the=20 > transaction ever existed. > > This opens the door to transaction censorship or selective orphaning=20 > by powerful actors (e.g. mining pools or state actors), without=20 > leaving 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=20 > 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=20 > complexity? > - Should logs be stored in-memory or disk by default? > - Would wallet software (like Core, Specter, Sparrow) benefit from=20 > exposing 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=20 > Core (v25+ compatible). > > Warm regards, > liang > > --=20 > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/981ea514-60ee-462b-92f3-4570= aa6483b0n%40googlegroups.com=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/= b7f915b6-a4a4-4c8d-811a-70cfdb761565%40murch.one.