Delivery-date: Wed, 01 Oct 2025 00:38:24 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v3rPr-0000Um-Ul for bitcoindev@gnusha.org; Wed, 01 Oct 2025 00:38:24 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-30cce8fa3b1sf2458374fac.1 for ; Wed, 01 Oct 2025 00:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1759304298; x=1759909098; 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:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=bppl0CZTQSWeZQNOgsRPwG01hJutSPF78MRxroLH4r0=; b=dE0i3o52qhYyCQdHP6zcuSj+KgH1kPn88S4BzU4g7gtHCKP3mBbp33Qeu7ZXR9nTvi Cd/amP4HtJFGDJAj/vaWeXf+WnYjhu4xXNJb4TW7dRXHOSBLn5UthwXuVlZWTkMksdAP lJpFQxpMCODgux9NbX1DCHH46IoEXUECY/4wgkxxdpAJh//2nNbztsQy0mCyuxxQKM/T ZijX3vguqSa1Q/Pgn4AayAUU71mY6yzSe0izn6UhYIhxGRoNWMQBc90a98sp88ZOKrwR NInmoUnPcf4H2f43QOA0SVeo99Sbl8hYnTugRwHIrNHBW55IXe1EsxAq2oiVdOfUIGFO aA6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759304298; x=1759909098; 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:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=bppl0CZTQSWeZQNOgsRPwG01hJutSPF78MRxroLH4r0=; b=ifYKWjUYJpfnevRkqenNYPHyeZvEqM9fPPsyl8C/IGGbluAA8wnVtI1cNGhXG7d0St a7ECCMx+WCuZXuq/h+PXnUREg5BI2TAceA3ovlbriAp5Gaz/8HtuFCJKDQB0LnUe4rN7 Go1Cpwz6NWaCee0A/e8JMQemiutiL3poqoW+x6Umiw6kGemqnzZrgRo2oicWufgM3L74 nzyxgLO0gEmCjBMhhMnFKjySbrykTY6sgyaC/wF13SvyR4oUqqq4vKrbg5Fyw8sbEA5D DkzwfScGhg95nWdKp/fLsv6nPHvt9NG44Dra2crdg0wWSxxM6S72fYkBJ+mEtPbNEBSi zm2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759304298; x=1759909098; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=bppl0CZTQSWeZQNOgsRPwG01hJutSPF78MRxroLH4r0=; b=K5a6Xd4Ok6Frz8NK9EQBMKh2QQBFrdrGSlNG2T9ifqu4HO/Gr1c6Vl1H1mSTzuJCTC jT03VDNRtntqBhxoYK9Z69NwkkFWY2+BkMVgqxDBiAzioJ1XllFZ0Txd0AOMN9jRucpG zOs2bD+kJTwswJdQm2jhOiTvCD8LvYFTiFFiP2hrmIHeLE/wNlTNVvOfKXhdl0ptOEGL fFp5aLxx014cNSd4A/GtKz3rSbCSRKP7zfnXlbmZmba/aEJOuwnUfC8uHna/8DDUW5xP RIoS+b8Me9Ie4UcRnTQN63LTP5J/XNw1MYZNJZSPgkOsGIm2VBw3dYCh0oOrhnHKPsxh q4bA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW3RtOmlaxWN9nRF2U+BJOjYXhY3qUe1DFZhNwN/M3Ufhb8a8LeAyuTrwxnRnCQ/6OhvZl0o9YBDT5G@gnusha.org X-Gm-Message-State: AOJu0Yzd55jpFeZ5S3W0zme7rFlz6ccGrL5p1J4n2pxQODF9x16/LpYL U6thIlG8gMw4nLML2Y/xfauHVmQqG+YmrLRXOTP6GLbRAvLOY0ZiB3ym X-Google-Smtp-Source: AGHT+IGCfXS/ZrL0Ke8e63gjlZ/295BufXzyJT9KQesKq9A5SjpPAU+u/qASCxhpvEEhV8mFoz9P+Q== X-Received: by 2002:a05:6870:6594:b0:314:b6a6:68a1 with SMTP id 586e51a60fabf-39bb6b5e96fmr1463074fac.41.1759304297248; Wed, 01 Oct 2025 00:38:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4r/UjJ+V/SP+sDHk+YUP/QRkAZO0qNxkEyH85umBWieA==" Received: by 2002:a05:6870:5486:b0:31d:8e96:6f5e with SMTP id 586e51a60fabf-35eecc43003ls5263440fac.2.-pod-prod-08-us; Wed, 01 Oct 2025 00:38:12 -0700 (PDT) X-Received: by 2002:a05:6808:6909:b0:43f:95b5:66e with SMTP id 5614622812f47-43fa40c00a9mr1369575b6e.14.1759304292733; Wed, 01 Oct 2025 00:38:12 -0700 (PDT) Received: by 2002:a05:690c:4605:b0:725:2535:e36 with SMTP id 00721157ae682-77f6fad2435ms7b3; Tue, 30 Sep 2025 20:39:33 -0700 (PDT) X-Received: by 2002:a05:690c:8bcf:b0:725:5fb2:52a9 with SMTP id 00721157ae682-77f6f3f453bmr22053397b3.44.1759289972782; Tue, 30 Sep 2025 20:39:32 -0700 (PDT) Date: Tue, 30 Sep 2025 20:39:32 -0700 (PDT) From: Dingocoin To: Bitcoin Development Mailing List Message-Id: <5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n@googlegroups.com> In-Reply-To: <1A33D206-444A-49E7-B1F1-E9FE5F4E32FB@drbonez.dev> References: <8c6bb024-437f-4122-8ae0-f8ed9b9c23e4n@googlegroups.com> <1A33D206-444A-49E7-B1F1-E9FE5F4E32FB@drbonez.dev> Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_55804_515899823.1759289972414" X-Original-Sender: dingocoin.luckydingo@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_55804_515899823.1759289972414 Content-Type: multipart/alternative; boundary="----=_Part_55805_1632057598.1759289972414" ------=_Part_55805_1632057598.1759289972414 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greg ,=20 Policy divergence already exists through client forks and custom patches,= =20 so the question isn't whether filtering should exist but whether it should= =20 be transparent and user-controlled versus opaque and developer-controlled.= =20 This BIP makes existing policy differences explicit rather than hidden,=20 providing transparency where users may unknowingly participate in filtering= =20 through different client implementations. Given that miners increasingly=20 bypass relay networks through direct submission channels, mempool policy is= =20 primarily about local resource management rather than modeling mining=20 behavior, making user-defined policies a tool for node operators to manage= =20 their own resources. While concerns about censorship infrastructure are=20 valid, transparent policy scripting is more aligned with Bitcoin's=20 anti-censorship principles than the current situation of scattered, opaque= =20 policy differences across forks . On Wednesday, October 1, 2025 at 4:32:39=E2=80=AFAM UTC+5:30 Aiden McClella= nd wrote: > Jeremy,=20 > > That's actually really clever. I had wanted the scripts to be able to=20 > manage mempool size, and handle prioritization of higher feerate=20 > transactions (hence the evict() fn and minFeerate part of the api), which= I=20 > don't think could be done with script, and I'm not sure we'd want to add= =20 > opcodes to make that possible, given that it only makes sense in this=20 > context. But maybe that part doesn't need to be part of the dynamic=20 > scripts? Definitely gives me a lot to think about.=20 > > Thanks,=20 > Aiden McClelland=20 > > > On September 30, 2025 3:09:15 PM MDT, jeremy wrote= : > >> Bitcoin already has a built in user defined script language: Bitcoin=20 >> Script. >> >> If you add a couple conditionally verified opcodes (the same ones=20 >> necessary for covenants), you could write whatever filter you like, and= =20 >> we'd learn more about what the best opcodes are for writing covenants. >> >> You would execute the script "pretending" to be input 0. >> >> We would then at least learn something about covenants. >> On Tuesday, September 30, 2025 at 2:22:10=E2=80=AFAM UTC-4 Aiden McClell= and wrote: >> >>> /dev/fd0, >>> >>> I appreciate the comments. A txnotify solution could work, although it= =20 >>> loses a lot of the modularity and sandboxing of what I'm proposing. It= =20 >>> would probably result in a single external binary, running all of the= =20 >>> policy validation logic, rather than a bundle of scripts you can mix an= d=20 >>> match. And it might encourage solutions that involve fetching relay=20 >>> policies over the internet, which is probably not ideal. Ideally, updat= ing=20 >>> policy should require user action.=20 >>> >>> Thanks,=20 >>> Aiden McClelland >>> >>> >>> >>> On September 27, 2025 7:22:28 PM MDT, /dev /fd0 =20 >>> wrote: >>> >>>> Hi Aiden, >>>> >>>> There is an easy solution based on my understanding of [transaction=20 >>>> validation][0] although I have not tested it: >>>> >>>> 1. Add a config option `txnotify` similar to `blocknotify` that=20 >>>> executes commands or script when a new transaction is received from a = peer. >>>> 2. Add a function `ExecuteTxNotify()` that will run the script provide= d=20 >>>> by the user in step 1. Script should either return 'accept' for 'rejec= t'=20 >>>> and function would return true/false accordingly. >>>> 3. Call `ExecuteTxNotify()` in ` AcceptToMemoryPool()` so that rejecte= d=20 >>>> transactions do not enter the mempool. >>>> >>>> [0]: https://bitcoincore.academy/transaction-validation.html >>>> >>>> /dev/fd0 >>>> floppy disk guy >>>> >>>> On Thu, Sep 25, 2025 at 12:00=E2=80=AFAM Aiden McClelland =20 >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'd like to share for discussion a draft BIP to allow for a modular= =20 >>>>> mempool/relay policy: https://github.com/bitcoin/bips/pull/1985 >>>>> >>>>> I think it could potentially reduce conflict within the community=20 >>>>> around relay policy, as an alternative to running lots of different n= ode=20 >>>>> implementations/forks when there are disagreements. >>>>> >>>>> I am working on a reference implementation using Bellard's QuickJS,= =20 >>>>> but it has been almost a decade since I've written C++, so it's slow = going=20 >>>>> and I'm sure doesn't follow best-practices. Once it's working, it can= be=20 >>>>> cleaned up. >>>>> >>>>> Thanks, >>>>> Aiden McClelland >>>>> >>>>> --=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, sen= d=20 >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit=20 >>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-= 6c68c6554f56n%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/= 5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n%40googlegroups.com. ------=_Part_55805_1632057598.1759289972414 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg ,=C2=A0

Policy divergence already exists th= rough client forks and custom patches, so the question isn't whether filter= ing should exist but whether it should be transparent and user-controlled v= ersus opaque and developer-controlled. This BIP makes existing policy diffe= rences explicit rather than hidden, providing transparency where users may = unknowingly participate in filtering through different client implementatio= ns. Given that miners increasingly bypass relay networks through direct sub= mission channels, mempool policy is primarily about local resource manageme= nt rather than modeling mining behavior, making user-defined policies a too= l for node operators to manage their own resources. While concerns about ce= nsorship infrastructure are valid, transparent policy scripting is more ali= gned with Bitcoin's anti-censorship principles than the current situation o= f scattered, opaque policy differences across forks .


On Wednesday, October 1, 2025 at 4:32:39=E2=80=AFAM UTC+5:30 Aiden= McClelland wrote:
Jeremy,

That's actually really cle= ver. I had wanted the scripts to be able to manage mempool size, and handle= prioritization of higher feerate transactions (hence the evict() fn and mi= nFeerate part of the api), which I don't think could be done with scrip= t, and I'm not sure we'd want to add opcodes to make that possible,= given that it only makes sense in this context. But maybe that part doesn&= #39;t need to be part of the dynamic scripts? Definitely gives me a lot to = think about.

Thanks,
Aiden McClelland


=
On September 30, 2025 3:09:15 = PM MDT, jeremy <jeremy....@gm= ail.com> wrote:
Bitcoin already has a built in user defined script language: Bitcoin Script= .

If you add a couple conditionally verified opcodes (th= e same ones necessary for covenants), you could write whatever filter you l= ike, and we'd learn more about what the best opcodes are for writing co= venants.

You would execute the script "preten= ding" to be input 0.

We would then at least l= earn something about covenants.
On Tuesday, September 30, 2025 at 2:22:10=E2=80= =AFAM UTC-4 Aiden McClelland wrote:
/dev/fd0,

I appreciate the comm= ents. A txnotify solution could work, although it loses a lot of the modula= rity and sandboxing of what I'm proposing. It would probably result in = a single external binary, running all of the policy validation logic, rathe= r than a bundle of scripts you can mix and match. And it might encourage so= lutions that involve fetching relay policies over the internet, which is pr= obably not ideal. Ideally, updating policy should require user action.
=
Thanks,
Aiden McClelland



On September 27, 2025 7:22:28 PM MDT, /d= ev /fd0 <alice...@gmail.com> wrote:
Hi Aiden,

There is an easy solution bas= ed on my understanding of [transaction validation][0] although I have not t= ested it:

1. Add a config option `txnotify` similar to `blocknotify`= that executes commands or script when a new transaction is received from a= peer.
2. Add a function `ExecuteTxNotify()` that will run the sc= ript provided by the user in step 1. Script should either return 'accep= t' for 'reject' and function would return true/false accordingl= y.
3. Call `ExecuteTxNotify()` in ` AcceptToMemoryPool()` so that rejected transactions do not enter the mempoo= l.

=

= On Thu, Sep 25, 2025 at 12:00=E2=80=AFAM Aiden McClelland <m...@drbonez.dev> wrote:
Hi all,

I'd like t= o share for discussion a draft BIP to allow for a modular mempool/relay pol= icy: https://git= hub.com/bitcoin/bips/pull/1985

I think it could poten= tially reduce conflict within the community around relay policy, as an alte= rnative to running lots of different node implementations/forks when there = are disagreements.

I am working on a reference imp= lementation using Bellard's QuickJS, but it has been almost a decade si= nce I've written C++, so it's slow going and I'm sure doesn'= ;t follow best-practices. Once it's working, it can be cleaned up.

Thanks,
Aiden McClelland

--
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 bitcoindev+...@googlegroups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f5= 6n%40googlegroups.com.

--
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/5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n%40googlegroups.com.
------=_Part_55805_1632057598.1759289972414-- ------=_Part_55804_515899823.1759289972414--