From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 19 Aug 2026 06:34:13 -0700 Received: from mail-ot1-f59.google.com ([209.85.210.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwgQn-0001wH-0p for bitcoindev@gnusha.org; Wed, 19 Aug 2026 06:34:13 -0700 Received: by mail-ot1-f59.google.com with SMTP id 46e09a7af769-7eb6429750esf1322134a34.0 for ; Wed, 19 Aug 2026 06:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787146447; x=1787751247; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=dVCMfbgJTGf16pQaDDkUV2tB4F0XGXFBBNJaWS0Ga3E=; b=uT0cUX/iFICdZnxkDdhLZqltaL1XYQu8klF5lJkRTfDb6Np/kzEwxIgFIKTAyXt9da yFEM464gU5/LcB3BVDGPSCP89cNib3XH51j/X65UVfS3Sck2nzmqa5s04ZrasL+j7rf4 20KSCGuDM12u6Akzh69ShaPNehkgeqSyK7pZ7kldYqao1nKReJvU7lHemI+cI751/7TA lF3JLoZW3806Jpmd9U63zCIcnmMtQC7gvNw18CGyqiV3XVkUrF2kpLUonIs1pcLelsy5 VVqZq5zGR5z9/y+eBKNLFAKjtw43DZHcbU80bM7iBU1JojbUPIKahDbacJb4ieuMu4Yh WPug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787146447; x=1787751247; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=dVCMfbgJTGf16pQaDDkUV2tB4F0XGXFBBNJaWS0Ga3E=; b=mqRFU03I2cJWpdoOEHwwqbsjGpPdQAWzshLnlneD+z+6JcADK+4MaS8swxVpQN7TaB hUCT5PJAX0THRb3+GYETDBktLisCd8FInIbOpFwizgIGAt/z/uj+oNcN4leO5jAvhCpP ZryYahVA5RXAJqKwU0sve3oWEhxFYFgLdMq12KloC/wWsENXAxo4QvzUFfnDR6hJL6gV podb/sqS894ZbePahNU5KK2MN3Ot7XWkVELFYzJWDTnLnSSr6yIKe/Rg321B0Kwppbnk eoybBWyL1aiIXx7i/PCb8djti160CWTplN8StSjq1mcbWzbMvv1KQmyg/tq/DiIPQoe0 +NVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787146447; x=1787751247; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :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:content-type; bh=dVCMfbgJTGf16pQaDDkUV2tB4F0XGXFBBNJaWS0Ga3E=; b=D1TRc0HvBZlfc2W5MMocBfKVHG4393QMHMtIGuAVPn3EsL9eZbkLR4WKsR8RV+V3zW J62PlEYtVyv6q7Qx48t/fUG8ASzmH2yF0slWPybGLD8lMXLPYaoWTUWm4yCYAShuUZCE AZ+jVShTr9AWWUrpKrsNTZ/iocTeGRVIvnna9HyQXSSUcuuLU5r9wJGvNzxVMfinGDmc E66tU/RISUZTdrXjtdS/oEepqbwSwXryQkYEmpIArWGYRvPEQ+BglrQjxzu9auKDfkOf VbWkOzeiE1PLCmPHUPLB5Wcx6cfpz+qGr8IMmuJLVVOwXqYd5CzDmAZSjSF7YVGYsI6g X5JA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+RoVWVVzJVg07seKxCRLmQiE6u2YI08Nn20PVb9OQkN2xnyczqcuHTiXxJ12qrGDyLHjMmwmSxKaenDw@gnusha.org X-Gm-Message-State: AOJu0YxSxV6kbsk8PDiR2ZnveY+uLXoGRDc+to3Vi7TtLAH9ArWUAXSo 0EWwmnD12L1OGsMG9W5rdUNuLotnnmBjK92eHp9DBQtfh3bIuLnc0rOo X-Received: by 2002:a4a:e841:0:b0:6a3:e0fb:6f39 with SMTP id 006d021491bc7-6b13c553a2emr4859083eaf.23.1787146446590; Wed, 19 Aug 2026 06:34:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcZ7xPIrGCLDekPiy/y297TdaUyyLo1c8dd4RPFV1GTGQ==" Received: by 2002:a05:6871:2eaa:b0:456:ce3d:ba46 with SMTP id 586e51a60fabf-45e5a17f1bbls3832954fac.0.-pod-prod-06-us; Wed, 19 Aug 2026 06:33:59 -0700 (PDT) X-Received: by 2002:a05:6808:6f91:b0:495:e0a9:8c0 with SMTP id 5614622812f47-4b2bca2ae64mr3437434b6e.11.1787146438930; Wed, 19 Aug 2026 06:33:58 -0700 (PDT) Received: by 2002:a05:690c:8d1b:b0:81e:ee9e:9148 with SMTP id 00721157ae682-844636514cdms7b3; Wed, 19 Aug 2026 06:31:39 -0700 (PDT) X-Received: by 2002:a05:690c:a7c8:b0:815:bc6a:2e48 with SMTP id 00721157ae682-844e001021fmr16912507b3.14.1787146298390; Wed, 19 Aug 2026 06:31:38 -0700 (PDT) Date: Wed, 19 Aug 2026 06:31:37 -0700 (PDT) From: b10c <0xb10c@gmail.com> To: Bitcoin Development Mailing List Message-Id: <2b19cd5e-84aa-4779-b1a6-490cc918cc52n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: [BIP Proposal] Anti-Fee-Sniping with LockTime MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_106286_579734382.1787146297849" X-Original-Sender: 0xB10C@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_106286_579734382.1787146297849 Content-Type: multipart/alternative; boundary="----=_Part_106287_732027895.1787146297849" ------=_Part_106287_732027895.1787146297849 Content-Type: text/plain; charset="UTF-8" Hi nervana21, some comments in random order on the BIP proposal and Anti-Fee-Sniping: - You mention BIP125 a couple of times in Specification. Note that in recent versions of Bitcoin Core, BIP125 signaling is no longer required for a transaction to be replaceable under the default mempool policy. - While the 10%-back-date-rule in Anti-Fee-Sniping is a privacy feature for some people, it is also a privacy leak for others: https://github.com/bitcoin/bitcoin/issues/26526: When fee-bumping a previously not back-date transaction, Bitcoin Core might back-date the replacement. This is fingerprint that you likely back-dated the replacement transaction. There is also https://github.com/bitcoin/bitcoin/issues/26527, which I'm not sure if it's an actual problem or not (haven't had the time to double-check). Maybe documenting some of these edge-cases in the BIP makes sense. This allows potential future/other implementations not to make similar mistakes. - There has been a case where the trying to do Anti-Fee-Sniping 1) wasn't implemented properly in a wallet so it didn't work 2) ended up being a clear fingerprint for this wallet: https://b10c.me/observations/01-locktime-stairs/. By now, this wallet doesn't have much usage anymore (https://mainnet.observer/charts/transactions-not-enforced-locktime/) but this still shows some of it's pitfalls. - Note that currently only around 5% of the transactions set a heigt-based time-lock: https://mainnet.observer/charts/transactions-height-based-locktime/ - growing this anonymity set might be interesting to some wallets, but currently, do don't stick out if you don't do Anti-Fee-Sniping (or use locktime). Best b10c On Tuesday, 18 August 2026 at 11:17:44 UTC+2 nervana21 wrote: > Hello all, > > Anti-fee-sniping with nLockTime has been present in Bitcoin Core since > 2014 and in Electrum since 2017. BIP326 assumes this nLockTime behavior > as the baseline and uses nSequence instead for some taproot spends. > However, the nLockTime rules themselves were never specified in a BIP. > > > https://github.com/nervana21/bips/blob/anti-fee-snipe/bip-anti-fee-sniping-with-locktime.md > > The BIP draft follows Bitcoin Core's DiscourageFeeSniping and > IsCurrentForAntiFeeSniping functions. nLockTime is set to the current tip > height. > With probability 10%, a uniform random integer in 0..99 is subtracted > and the result is clamped at 0. A locktime equal to the tip height > cannot be included in a remine of the tip. An older locktime chosen on > the privacy branch can. nLockTime is set to 0 during initial block > download or when the tip is more than 8 hours old. The policy is not > applied when nLockTime is already set or when any input already has a > preset nSequence. Test vectors are included. > > Constructive criticism is greatly appreciated. > > Cheers, > nervana21 > -- 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/2b19cd5e-84aa-4779-b1a6-490cc918cc52n%40googlegroups.com. ------=_Part_106287_732027895.1787146297849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi nervana21,

some comments in random order= on the BIP proposal and=C2=A0Anti-Fee-Sniping:

- You mention BIP125 a couple of times in Specifi= cation. Note that in recent versions of Bitcoin Core, BIP125=C2=A0signaling= is no longer required for a transaction to be replaceable under the defaul= t mempool policy.
- While the 10%-back-date-rule in=C2=A0An= ti-Fee-Sniping is a privacy feature for some people, it is also a privacy l= eak for others:=C2=A0https://github.com/bitcoin/bitcoin/issues/26526= : When fee-bumping a previously not back-date transaction, Bitcoin Core mig= ht back-date the replacement. This is fingerprint that you likely back-date= d the replacement transaction. There is also=C2=A0https://github.com/bitcoi= n/bitcoin/issues/26527, which I'm not sure if it's an actual problem or not= (haven't had the time to double-check).=C2=A0Maybe documenting some of the= se edge-cases in the BIP makes sense. This allows potential future/other im= plementations not to make similar mistakes.
- There has been a ca= se where the trying to do=C2=A0Anti-Fee-Sniping 1) wasn't implemented= properly in a wallet so it didn't work 2) ended up being a clear fingerpri= nt for this wallet:=C2=A0https://b10c.me/observations/01-locktime-st= airs/. By now, this wallet doesn't have much usage anymore (https://mainnet= .observer/charts/transactions-not-enforced-locktime/) but this still shows = some of it's pitfalls.=C2=A0
- Note that currently only around 5%= of the transactions set a heigt-based time-lock:=C2=A0https://mainnet.obse= rver/charts/transactions-height-based-locktime/ - growing this anonymity set might be interesting to some wallets, but=20 currently, do don't stick out if you don't do=C2=A0Anti-Fee-Sniping (= or use locktime).

Best
=
b10c
On Tuesday, 18 August 2026 at 11:17:44 UTC+2 nervana21 wrote:
Hello all,

Anti-fee-sniping with nLockTime has been present in Bitcoin Core since
2014 and in Electrum since 2017. BIP326 assumes this nLockTime behavior
as the baseline and uses nSequence instead for some taproot spends.
However, the nLockTime rules themselves were never specified in a BIP.

https://github.com/nervana21/bips/blob/anti-fee-snipe/bip-a= nti-fee-sniping-with-locktime.md

The BIP draft follows Bitcoin Core's DiscourageFeeSniping and
IsCurrentForAntiFeeSniping functions. nLockTime is set to the current t= ip height.
With probability 10%, a uniform random integer in 0..99 is subtracted
and the result is clamped at 0. A locktime equal to the tip height
cannot be included in a remine of the tip. An older locktime chosen on
the privacy branch can. nLockTime is set to 0 during initial block
download or when the tip is more than 8 hours old. The policy is not
applied when nLockTime is already set or when any input already has a
preset nSequence. Test vectors are included.

Constructive criticism is greatly appreciated.

Cheers,
nervana21

--
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/2b19cd5e-84aa-4779-b1a6-490cc918cc52n%40googlegroups.com.
------=_Part_106287_732027895.1787146297849-- ------=_Part_106286_579734382.1787146297849--