From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 Mar 2024 13:53:05 -0700 Received: from mail-yw1-f184.google.com ([209.85.128.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rn2vo-0003nt-OY for bitcoindev@gnusha.org; Wed, 20 Mar 2024 13:53:05 -0700 Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-60a03635590sf4845057b3.0 for ; Wed, 20 Mar 2024 13:53:04 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710967978; cv=pass; d=google.com; s=arc-20160816; b=yuQaNwNNAM59pPEyQJd0Hlieqpu6HtFkCilgmmzx0CN5aTJlb0XxYxZEKB4qDKg9lT pPnDiWTkrGxGrmWpeneYlnk7SzdsK8Wsc/Nip1K1cdBjThHhqar75QHsKJyfGUIgGcho aKYpriRmKX/FhW/Az1EqvKq4attEN9i9XAC17AlUrUeUPSntMVT2Je7ZnT1pFIjRAhdJ xTCrcLbEjl6Bzt425P9D1J5f5rXRosAtbzlvGg64REQkmG09gq137ktVNro3T2yDwGe8 ccLAtYDD5TMmoXQjvk/Kbb2eFUR/rGzLa8DWuUTRzsc3OzcfxcW8uKGQpGSUdJDsfQUv Juww== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; 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 :feedback-id:sender:dkim-signature; bh=mJm7XUSqzrHO3n9GfOK5IoTiUT+WCkE/CUcC6bA++rQ=; fh=JlIYIVC6i7JqB1CCIHmi6iYqHwNU09nRKufFXIaP2Is=; b=rVX73NpHFOET5PtmgR/1nUpSaHqVENwHHWbVmY89pZD+aCTHaBRaid0osZGpdk3J6S Q5yMqBfqHSUIbcDcG41yAkoZHmIGlvlfauNuml9FpXr+bnWvU3ZmLFwHi3l/VPzSRtLh biFHJ/bSvXIyE/aGo/JYT/WJ/mSQYqKF2Mx7a7B9AQL6v44rPdnooIBS6kVL0Oq1PbqW sYqKQwXfsXOHccUKyo+bkOlLWXE6uYwPRSY6qcyHC46kJjGi+tjH8t8SBvAYeuPwFy+6 +MLRAcjlDg/aFTd6FhUyX4uOvCtl0iWHnjF/n/xUA8qt56IoHu3NUdPRKHZeA6ecI3HJ Jj2g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=iq3zZ7yP; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1710967978; x=1711572778; 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:feedback-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=mJm7XUSqzrHO3n9GfOK5IoTiUT+WCkE/CUcC6bA++rQ=; b=C4wICtDh/5+jAU4HP2PEn0EMJUkXoEu5SxSaegzRsVDBBiOr8ydJle9aR5H4r30zeq OmZ/tSAxGWXDVrJpYEHZ0+137fB9LPzOBbpceTTRAnxmfzc9weWPXj6iH4wg/3kJVVzD FikBVXkWSWX98+YuJNDIpisdhUMsBj/DFy3nPRyhH4B4/+tb5RTp+3YEq8qeFeSZdQtP YD8xM7H8/UEt3nekvhckHTEdpKVWczRX0sHWhCYASCTZBx3ZxxCCFFxl9mOnE1zzwuR9 Z56l6J6bIhPWqD5p6oY4OHLEPudvhKglf4yUZwCyE8Q1FEmnnpz18bKw12HlLcijtiB1 dGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710967978; x=1711572778; 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:feedback-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=mJm7XUSqzrHO3n9GfOK5IoTiUT+WCkE/CUcC6bA++rQ=; b=Wp9f6HaLxYwwEl63tWXEvxZzDDcsjKQoNnRM90L1xfvIivJkw3ea6oU//azD8c4hXw eOTOs8cjpGmNBmf9VUqvgK3E32HOrjg3AXBH2IKpbUpMwnEP2rfdmeqQZtyjTw+y9ViI 5TwBgf1zfGv443Bp6eZ50OcfkuZ6L4SxDILylABRKUIeiVHNoNWsLECsCYd4A00oNiwC e5junH0lGt5iW9ls0kTTc3XZan3RDGqCPiR3HUP1tz8qLjDIBNT2nrUMxu9Fd5WTirka xsiN0m9EEUYGdc9t1usf4TMg4xy2SJO99rRGt7nXIiDm2syNzta0/D8yQs7FLh2aDjht U8OQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCU8DeNw8rc9IgtL5J2yMphCc7nu2HzYiUjpS/9MlH4V8orZ07mdQde2+PbjQsOWa5eUsKJwcuW7wFskZ3IT6PtxuviGinM= X-Gm-Message-State: AOJu0YzAU59OmMjFkIEfmr66SlE2tMb6gmt96evUN5OrFHXRt5blnryY DYObYZLPP5yh1EwA25r7Q/751WZXun0cbpwUrY5BKvi43K2lvDBA X-Google-Smtp-Source: AGHT+IHo5NJvHMFwOZiQyaHb4GePfd4Gu1zGaKLLcTcf6Mod36sQb7pwgc9EjHb6FczObA318kC18g== X-Received: by 2002:a25:84d1:0:b0:dc7:43aa:5c0b with SMTP id x17-20020a2584d1000000b00dc743aa5c0bmr5291261ybm.21.1710967978269; Wed, 20 Mar 2024 13:52:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:df45:0:b0:dcc:4b24:c0e0 with SMTP id w66-20020a25df45000000b00dcc4b24c0e0ls585472ybg.0.-pod-prod-06-us; Wed, 20 Mar 2024 13:52:57 -0700 (PDT) X-Received: by 2002:a81:6d52:0:b0:610:f287:93b5 with SMTP id i79-20020a816d52000000b00610f28793b5mr840803ywc.7.1710967976960; Wed, 20 Mar 2024 13:52:56 -0700 (PDT) Received: by 2002:a05:690c:113:b0:60a:de42:2427 with SMTP id 00721157ae682-60ade422672ms7b3; Tue, 19 Mar 2024 08:04:49 -0700 (PDT) X-Received: by 2002:a0d:d58c:0:b0:609:f49f:5949 with SMTP id x134-20020a0dd58c000000b00609f49f5949mr3207001ywd.21.1710860688309; Tue, 19 Mar 2024 08:04:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1710860688; cv=none; d=google.com; s=arc-20160816; b=j2Bzmzv9qjxJvSvVsRnAg7o/IKcaXEgEfmIOZXcK+hf1C/37iK3DLIhn/FCY07GtRQ O2VnhkPL++laQ9A4uOkUW3zyz36MuO3NTCZoB/y8G5K6WV7z1tlUwzSz1ef0JvYeFHLL i3dVRWOzx1ARvQuV64hsp3iNtG/mL0hHs1P89T4l60dAUJG+eO8+QGtJO/6Gbr+RboXk 14kB3UzhNkK/WlxpmW9eqN8Z8/LU/fpQMaGUfgY6zThA5Cg4cmoc1s1qunNJ4O1pYag9 sNVeKUaWuxfGmu9v2bmjm+3aLMC6TXrN8cTVYMvcHAx3K+YZgO5x2tbYxidCNYWDSHyV tmDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:dkim-signature; bh=7g1kIQXg5/9i1edSgCAz9JVPnhx3dHKi6JowrnOfqTU=; fh=cWdrWsfLtcLnP7jmLztASZAafDq7vZjWduWbTI0UjXc=; b=vZDwY2v9mcrhGXkctrVFXpsFlrNm9nfV1QkeHyCpCvh2Y3BoSulPda7W0lBRx3rDJE dcPNYWOxpxOYzPQE32RwhFOr6taUbMZ70wMFG0FWUzk1kvkb/bL/F4N8jFxKI9ub9KnE FVnfRYAIEvPXliOfVAaP2hWI2G1D/NxUPOi3hn+p6Z504oIdbjAWBhn+CIpHWPD7GTNV iHggyWwLu5+BhYKZLIzojITyNuIW/fdqsLtrhDWaTOdtYJoqyA9H6XBY9LsrMyMA++sM 5CQufIkijoliQ4ztAWTSBvuGkIbzRGQMbW4p4aJ8SgYLR+cRMb6FHSGjX6rUvPi2ay/c HjfQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=iq3zZ7yP; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from fhigh7-smtp.messagingengine.com (fhigh7-smtp.messagingengine.com. [103.168.172.158]) by gmr-mx.google.com with ESMTPS id r126-20020a819a84000000b0060a6050a1c1si1312372ywg.4.2024.03.19.08.04.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Mar 2024 08:04:48 -0700 (PDT) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) client-ip=103.168.172.158; Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id F40F91140112; Tue, 19 Mar 2024 11:04:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 19 Mar 2024 11:04:47 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrledtgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesghdtre ertddtjeenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho uggurdhorhhgqeenucggtffrrghtthgvrhhnpeekvdfggfeuteekudduiedvkeehvdfgle euuedtleeikedvfeeftdfggedvvdegfeenucffohhmrghinheplhhinhhugihfohhunhgu rghtihhonhdrohhrghdpghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv sehpvghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Mar 2024 11:04:46 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id A72FA5F84B; Tue, 19 Mar 2024 15:04:43 +0000 (UTC) Date: Tue, 19 Mar 2024 15:04:43 +0000 From: Peter Todd To: antoine.riard@gmail.com Cc: bitcoindev@googlegroups.com Subject: [bitcoindev] Re: OP_Expire mempool behavior Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sffbIHzw3cDuBla2" Content-Disposition: inline In-Reply-To: X-Original-Sender: pete@petertodd.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=iq3zZ7yP; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org 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 (/) --sffbIHzw3cDuBla2 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (replying manually with a cut-n-paste due to a mailing list delivery issue) > > > > nodes should require higher minimum relay fees for transactions clo= se to > > > their expiration height to ensure we don=E2=80=99t waste bandwidth on= transactions > > > that have no potential to be mined >=20 > I think this concern can be raised on _today_ LN second-stage transaction= s (HTLC-preimage / HTLC-timeout), > when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes wi= ll automatically go to broadcast an > on-chain HTLC-timeout transaction. Probabilistically, we're wasting bandw= idth on transactions that _might_ have > lower odds to be mined. That's not really a comparable situation. If the HTLC-timeout transaction replaces a HTLC-preimage transaction in a mempool, it will do so under ordi= nary BIP125 rules, and is thus "paying for" the bandwidth with a higher fee. Equally, in a replace-by-fee-rate scenario, it would be "paying for" its bandwidth with a higher fee-rate. Either way, something will confirm. In the OP_Expire case, we're talking about a transaction that becomes entir= ely invalid after a point in time. If the transaction isn't mined with reasonab= ly high probability (eg >10%, preferably higher) an attacker may be able to consume bandwidth indefinitely at little to no cost. > > If you already have a need to make such transactions, you can argue tha= t the > > marginal cost to also use up that bandwidth is low. But that's already = the case > > with RBF: we allow any transaction to be replaced with RBF for a (by de= fault) > > 1sat/vB additional cost to "pay for" the bandwidth of that replacement. > > OP_EXPIRE does not change this situation: you're still paying for an ad= ditional > > 1sat/vB cost over the replaced transaction, as eventually one of your > > replacements will get mined. >=20 > I think yes this is indeed more a replacement issue, nothing new introduc= ed by OP_EXPIRE finality time-bounding semantics. > However, I think it's more an issue if we introduce things like altruisti= c re-broadcasting. > =20 > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022= 188.html > =20 > Certainly, the re-broadcast could favor transactions with higher odds of = being mined, which naively should match RBF rules. Similar to what I wrote above, in altruistic re-broadcasting, the attacker doing the replacement cycling attack has already paid for the bandwidth consumed in broadcasting the replaced transaction because they paid fees fo= r the cycling attack. Nothing more needs to be done beyond existing RBF/RBFR rules to avoid DoS attacks. > And by the same way taking time to answer the open questions on this thre= ad from the old mailing list: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022= 224.html >=20 > > Are you claiming that BIP157 doesn't work well? In my experience it doe= s. >=20 > I've not checked recently, though from research memory a while back the n= umbers of BIP157 services offering peers > was in the range of ~10 / 100. >=20 > One can check by collecting nVersions messages from peers with `NODE_COMP= ACT_FILTERS`. I mean, that's still BIP157 working. It's just not supported by every node. It's easy to learn about lots of addrs from the addr distribution mechanism= s, so I don't think that's a serious issue. > > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so = mempool min fees are very consistent across nodes. I just checked four diff= erent long running > nodes I have access to, running a variety of Bitcoin C= ore versions on different platforms and very different places in the world,= and their minfees all agree to well within 1% > In fact, they agree on mi= n fee much *more* closely than the size of their mempools (in terms of # of= transactions). Which makes sense when you think about it, as the > > slope of the supply/demand curve is fairly flat right now. >=20 > See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from= diverging mempool min fees from the ground iirc. https://github.com/bitcoin/bitcoin/issues/28371#issuecomment-1939604817 is = the only actual data I could find in that link. I'm very curious as to what those nodes are actually doing. Possibly some pre-made node distribution is in fact setting non-standard mempool size lim= its. Or these are fake spy nodes with unusual behavior. > > From the point of view of a single node, an attacker can not reuse a UT= XO in a replacement cycling attack. The BIP125 rules, in particular rule #4= , ensure that each > > replacement consumes liquidity because each replacement requires a high= er fee, at least high enough to "pay for" the bandwidth of the replacement.= An attacker trying to > use the same UTXO's to cycle out multiple victim t= ransactions has to pay a higher fee for each victim cycled out. This is bec= ause at each step of the cycle, the attacker had > to broadcast a transacti= on with a higher fee than some other transaction. >=20 > This does not stay true with nVersion=3D3, where a package parent can be = signed with a feerate > under min relay tx fee. See the second test attached in the initial full = report email on replacement > cycling attacks, one can replace the child of the package and the parent = is automatically evicted, > without the "pay for" bandwidth of the replacement fully covered. >=20 > This is correct there is a minimal fee basis for each additional victim c= ycled out, while one can get > a very advantageous scaling effect by RC'ing the child txn. If V3 transactions is such that a child tx can be replaced at a cost that doesn't "pay for" the bandwidth of the parent that is evicted, that is a straight-forward design flaw/bug in V3 transactions. Fixing that should be pretty straight forward, at which point the attacker is again paying "fairl= y" with fees on each cycle. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --=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 on the web visit https://groups.google.com/d/msgid/= bitcoindev/Zfmpi/9y4vFMAUtu%40petertodd.org. --sffbIHzw3cDuBla2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmX5qYkACgkQLly11TVR Lzd7lA//UxIy51duLjJ2V/QKF76QM/hsDacCHOmTfscirc4g+blFRgWq5IpQ8J7n /JK8BbxxqqSWat0fjAc6HmLBQ6rY9+MAeVYD91CwattAMjqe+ns/Hz4Dlk83wl9P q083AdrFqS1n8tXFBAq9wNRP54dHAuv44a8rsYkrMi965CWZvT7Q9L7KA7Zn/jpH qXtK2MuQgS/Dk+7zW78esN0qVf2JsA2cbQiO7Y/ow2l8THTVszgGLXvCPqVRG15Q VZ46ETpl7Yc6Gi0ztOEWpob0ou8Uw2WPyAKZ4EixUgbNyJ/YB6VipYhVrDXsPjP5 VcNdG8xm8XWlbBK9FmegPH0hlBuFokR1cQUeofNN3sJXbvN0sM6QNGdYc8Afl7NM 0qeD3j14WDaMGQfqyVx5ALcrJyH2Y4XRuq9zD9kGEMd7+FioqiUvrMLV4+oG93UI 6lgC319SuDxNaYeFTDTK/IpYeFWjNXSmtzPNKb7Px8S73tGFVd1em2j4iZ7VqnYY sW/KsJPFiMPNXx4pWTAzyM2ZeTwQwqVNwwzj7skUYJK9W0EznZBWhczzx2ZefbFA S/twrbtkpAeJhWKcaTz3g3JSk3igjHPahc4eeZHGSq67tB82QMlxmZaXi4jvBGlZ yK/OIr0hiZd+uMz+MIyZVaCOi/f+YHi6syOG3BD3GcVXvkv0faE= =fz0g -----END PGP SIGNATURE----- --sffbIHzw3cDuBla2--