From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 Oct 2025 00:55:40 -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 1v5g4K-00024X-85 for bitcoindev@gnusha.org; Mon, 06 Oct 2025 00:55:40 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3a5620fde02sf6405129fac.1 for ; Mon, 06 Oct 2025 00:55:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759737334; cv=pass; d=google.com; s=arc-20240605; b=Q6FHPntvAJlsi4awYRM2uaPWPT8FzJk9ltNISIW8sYC6b3nkOFeDPzi3Qqj0G59onz Fa2EHZAmRZ/2sILt5qq1AqaJUmCSDwRnYP1vqCHERIaicvZ0rWskFnWVTqe5tNUY4+E1 r/22v2k0ZLJkGFLnRhTp8zUoaCz0ndhjJuommP/Xt6BtpSjrHhDxOyDr+IxV0u2uuyJX ZsoAwlIZsJYq87LQ84VE2HLNOS5n1kJLP9qvhVyI7lmMnL8cyDC2I0mHGnSGPPiHF5HU Yr38iFrATV2I49mdzu2ouG/qLUMmE+TO6XczjSChXaHUsjOiVcYjDhTG7OOyOVMb4bc7 x8xQ== 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:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=3yIXEIJ21iv+s3FHfZNsN352jWUwKkDoahnIffpn700=; fh=CU01YETSwzrJwbzUS9PLpE+tnf+elQGEjkgwQeBoTbg=; b=W53QgHMMAEu/zqUooauel0+JuKfNHjXHXvCZT2T3mGu58wPzOKjFlCx7E7FoHmoS4H ZzAX1GTWHANr3pUVcWN7vireZ+Oa8N9gME+rL/yvLc5T91FJFCdDGH2IqKSU50cIeaoV NibTs7AdZVyEVw8bZFRUo0lU9NmQWSNTaf2zAdf1u3xUQFnM9slW23PbZ/tBszZXy1uZ iKGektEx23Uplzl+/tc7bwKENADDWuEouOSIPicg1JClqBmj41RhPTvEJzIb+Hurlevo KVaGvCkPVQ3SA305LtMYdCOmMZKFAB/nho44aE7xi+L3MAlr/KDiu45t1Oo7Z5Dx47ly v0OQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1759737334; x=1760342134; 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:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to; bh=3yIXEIJ21iv+s3FHfZNsN352jWUwKkDoahnIffpn700=; b=ORjV8acW53cJSENCi6qPkRysYZMvOZoe59SWlz7ICMD+NIx01CQdNAI5ibL6/2PiiL UEyssQR7NBHEppIDpc7j33auSEcIF8gTx/9eCuiKuc52p0iLPj18sih5LndCwUuGol6D MIHfj4FsD0BqXY5HkhxE1oDR4hFC5EWbAaj1PjNXnpL2iPlZyM+ophASMxsEqNBD4MxY trgv/w0if5Pgy2CGZaGt1wgApYWum1uebepS5VfAbYRIdswCIIzT9xzwOcSSikeCATOW EWuL6xIZwC1wKSULyMU8p1XtkCfkzzmopixgHGFiEq29ggysgmTrAaqoYdwKGou97mP0 cgvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759737334; x=1760342134; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=3yIXEIJ21iv+s3FHfZNsN352jWUwKkDoahnIffpn700=; b=wgkFAR2UtmPbXdM89QLzHdzd5xwqYaQUsETuWkY0IOh2pg9xD7tUHJBsqoch757CBc NwfsrOOSU+5SrFfwp8XpDy00bDARuTHR01BwajYJU/KVl/XWRi0L7RGX5RgKrGyzF/TZ kmRI1Polc6sePVbcOz58O3iOQNfu31ZqjHemCmWarK1jQDLuAf5sumij6r7VUnViPq7N kmhUd8p43wHvO2awK96rfaiqfWkr9Hs96Fj+we2P+aQD+9QmJ20Gc+GkcEIZyh6C47G7 8DGiCuxUiBcAKwBELV83OS4s1cvhFujfpCpEf7BguD4ZK7phjuyI3teidM5MRSp3+q64 pSjQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUV/EZsEG5RQL3bdj8js2DX4bOpG9pdz3goCggZco5rUSjSc4ywHJhBXNZt0CZDGvPBU9Lnq3cbxLCq@gnusha.org X-Gm-Message-State: AOJu0Yz0Zhs2kzbAP2FVAVzSdbjKmi6iNzo9MAHcWxNliJINlmuLL1+e 6k76bDEkWn8mJJCzLbZNLR5feaLUr7zbfdc+sTsTfrmAQs2Di/USN0aF X-Google-Smtp-Source: AGHT+IFDEaqEnq4h0G0SRkvP34ZZu5mQxwkC3cDDtTbQoT742VcMWbMAeYi2mQAaFk0qZHk9TVG2Xg== X-Received: by 2002:a05:6870:8103:b0:31d:8e9f:e42b with SMTP id 586e51a60fabf-3b10283dfd8mr6259852fac.26.1759737333741; Mon, 06 Oct 2025 00:55:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd62YH7R7R1Mr4sMOwQoysitRmmA3QpgnVnWEvkmDRfVjA==" Received: by 2002:a05:6820:8515:b0:63e:1568:cf6a with SMTP id 006d021491bc7-64dfdc22d29ls995545eaf.0.-pod-prod-03-us; Mon, 06 Oct 2025 00:55:28 -0700 (PDT) X-Received: by 2002:a05:6808:f16:b0:43c:27cb:8065 with SMTP id 5614622812f47-43fc1847d85mr5349412b6e.30.1759737328662; Mon, 06 Oct 2025 00:55:28 -0700 (PDT) Received: by 2002:a05:6808:4347:b0:3f9:f009:458e with SMTP id 5614622812f47-43fc073c74dmsb6e; Mon, 6 Oct 2025 00:18:47 -0700 (PDT) X-Received: by 2002:a05:6602:15cb:b0:88d:7956:2e04 with SMTP id ca18e2360f4ac-93b96ae68famr1643471739f.19.1759735126538; Mon, 06 Oct 2025 00:18:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759735126; cv=none; d=google.com; s=arc-20240605; b=KN6rZtYWxmPCOYqjhrk3AdUtn7QXaRsKrsHyIPYznijeoQouuk7fS3BxDQRttpBVNy /4CPTkQwao3r1krXW2yHtn+e2kcBULZnAPJL6ud9K+0YT47PRyc482bSxFWByaAuGKlX L6v2cLDnWhggUrCxJYXI0fHeEAdc6XgiCviDhKUOk1OGePblMvkBXHlVmK3LxUTmZUmC TmOTw/GUJNoM+6qu/QKKQd64uL3KFdW16vBnvjUxPW0dfdstmqqKN4//ZoN4cfiRbVqC AIjRDhzquv0p92CPlAY1eFAnOcewA4yA8ozsrEe5KkrPYk2q1ZvzU48TTazgT01MU9Te MDbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date; bh=gRgKNollvPvVHEQliziLCR2e7MHRtLoRwefgbCGPXrI=; fh=Pr8BdNueWheXDew+ifn/bKM5rzXGO0Gi8K1DjK18d0E=; b=h0nJQsRu+LQF9T0TBusNxJ5kJw0lrIQS190vx+3vNL69W/tLCl73e4LFna1VIfMHEn gz/IJ2J4AzQt21/nT4Nre1ioQbdvX/08X6s3Vp/FtV42SFhJ2i0U6PwznWIzDAHfw3/r bF92fS+c1edkc34MN3u+dgazyBXnSTs5hJA9b/Ox7HgPPJfSFnrZrNST7bWr8pCICTQI kiqR1hJ7fQtOEev9Jp+AZTFEfRPv0Gef4fH3oaPhJeZ4VrOvIMxWirvMHbJQF8OEx8+Z iLkxyyAvENl4v3hcUpQJxif/bI30mFws5KEO7TmRNgEVsDzvKyEEJX8zwznpSaZMJcDi bz5Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id 8926c6da1cb9f-57b5e74bb0esi389083173.0.2025.10.06.00.18.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Oct 2025 00:18:46 -0700 (PDT) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v5fUM-0006kp-1E; Mon, 06 Oct 2025 17:18:43 +1000 Received: by email (sSMTP sendmail emulation); Mon, 06 Oct 2025 17:18:39 +1000 Date: Mon, 6 Oct 2025 17:18:39 +1000 From: Anthony Towns To: Andrew Poelstra Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: X-Spam_score: -0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au 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 (/) On Thu, Sep 25, 2025 at 11:33:29PM +0000, Andrew Poelstra wrote: > Once a transaction is in a block, you need to relay the transaction if > you want to relay a block. You cannot pick and choose which parts of a > block you like and which parts are "abusive". This is what it means for > something to be a consensus system. > > The purpose of the mempool is to approximate the contents of blocks, > both to help individual node operators (who would otherwise get large > quantities of "surprise transactions" with every block) [and...] I think that's too strong a claim. The purpose of your mempool on your node on your PC is whatever you want it to be -- eg, I have a node that has a mempool with an expiry time of 2 years instead of the default 7 days, because I wanted to see if low fee txs eventually got resolved in some way after long high fee periods. For many things, approximating the transactions that an economically rational miner would put in the next block is great: * if you're a miner yourself, you maximise your revenue if you happen to get the next block (since that's how "economically rational" is usually defined) * if you're sending transactions, it helps you predict if/when your tx will be included in a block, and helps you figure out what fee rate you should use * it helps you reconstruct and relay blocks more quickly (and relaying blocks more quickly helps others reconstruct blocks more quickly) * if you're sharing utxos with someone (lightning, or potentially ark or DLC bets), it helps give you advance warning if they're initiating a spend of that utxo in case you need to react to it Even so, "approximate" is doing a chunk of work here: given the possibility of (a) broadcasting double spends, (b) inconsistent propagation, (c) new relay features, (d) some miners not being perfectly economically rational, and (e) software not being bug free, the next block can only be approximated, and we should (and largely do!) still perform these tasks well even when we can't accurately predict the next block. But if our software does degrade gracefully in the face of bad predictions, it seems to me there's plenty of room for a "live and let live" attitude here, not only with respect to accepting whatever silly transactions people are willing to spend fees on, but also allowing people to configure the software they run to match their preferences, even if that's not optimal behaviour when measured by either efficiency or economic metrics. > [...and] to help the > network (which would otherwise have poor propagation properties). One case where approximating the next block doesn't actually add very much value is related to transaction propagation: * if you want to help Bitcoin be good surveillance-free money, then receiving other people's transactions and relaying them without keeping logs of where/when the tx arrived can help improve other Bitcoin users' privacy. That might be to help users avoid miners charging personalised transaction fees, criminals figuring out who to attack/extort, or authoritarian governments attempting to restrict trade or confiscate funds from political opponents, eg. That can benefit both senders, recipients and miners, all of whom might otherwise be subject to unwanted attempts at coercion, if their financial activities couldn't be kept private. For nodes that aren't mining, aren't used for fee estimation, don't need extremely quick tip updates, and don't need advance notice of updates to shared utxos, then exercising some discretion in which transactions they help anonymise doesn't seem very harmful, and running a node that helps to anonymise some transactions seems superior to running a blocks-only node and not doing that for any transactions. As far as "degrade gracefully" goes, as far as I can tell, there are historical reasons to be concerned there, because the difference between Bitcoin's block relay performance pre-2016 and today is significant; with historical relay latency resulting in orphan rates on the order of 10 times higher than today (ie ~1% rather than ~0.1%). However a variety of factors contribute to that difference, including: * compact blocks only relaying a short id for txs that are already present * high-bandwidth compact blocks avoiding a network round-trip if all txs are already present * compact block forwarding prior to full validation of the block * better validation performance * general performance improvements (CPU, memory, disk, networking) Filtering and inconsistent mempools only stops us from avoiding the network round-trip, which as far as I can see gives something on the order of a 0.17% overall cost increase [0], rather than the ~0.9% increase you'd expect from undoing all those improvements. [0] https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3318779164 is how I arrived at that figure Cheers, aj -- 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/aONtT7Jh0M3IXhHd%40erisian.com.au.