From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 Mar 2024 07:03:38 -0700 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rma41-00068a-Ly for bitcoindev@gnusha.org; Tue, 19 Mar 2024 07:03:38 -0700 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-5a486a8e1fdsf3583906eaf.2 for ; Tue, 19 Mar 2024 07:03:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710857011; cv=pass; d=google.com; s=arc-20160816; b=BuKQod8zfqJobgvOkZ+QNGB1aMw+k5GCFPT6qV5n72SScmOcT7MYTqth2zwbw3oUei 8cbf/JA0575WXcSish8EJVNOiiVWX4Phfwx+5MpbGAdQGW7plQQhbJqvhZOsn8M4s0H1 eDLAsUBnPP/ueJJdH8Zmh5WAgl73k1dplt9ivSmNZY95w6KH4IMHYr2nuwrfmt5n2Vd/ GxR+Pq0lT1PH/k4uGtLb3kzf0Z0qYMIacsqxJ8lkrQnFStV/kXJ9Ja3YFsKcxEX4mHDs HOeMAg9lRJqy1vqV/512ig7p+Rj+JTc6D4FesqyWXJKerlv/12XEWGY1ZjLmtpekOAmR b3sw== 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=81ZlGIHWVvJsZavkXdkR4RWq1LUYCfpde8wftsq27ag=; fh=mgeHBL47U3Jt8LHke+hGB7/mn6x1VD5yWuBS8a5wxSg=; b=tXBsR9Kw1ILm+7NA8omvKWqJHzadF9hgv5FG40yyDSyuHTgCzfZDqO+IbPXHwKFBId xmVkP7L3Jp9pyoHiHPTXJ803xLIRNZS6PJ8iWU0DsoeolPrO+rbtjSC4qGiG8FyUbpdf 3JzhQJyDA6cuLuA2BJfA89NTQVxS6f4kKSQx0VKgfdmG4B3u1OetFhSgXVxgjoNV7cfK zAqm7V/lL4mdNeSz2Znw8L/sBdwywsn3JTTmxtOhR4S3pz+FRQRQOgAGa533ldlT9hYu Ng4XjLIPv+M7xV0J7DfaspQISNavMGPw8jaLj6/eRVV6QcQ+EBs9AZqBH4KD2rpDnV3P TWLQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=qas6Qltd; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.157 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1710857011; x=1711461811; 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=81ZlGIHWVvJsZavkXdkR4RWq1LUYCfpde8wftsq27ag=; b=nxGewKW3Ouy7bvTrEncZE4/Jid07Q6GDz1sBh9RWSyrE0NLL8IYe4pQ1dGlMatn/xW dIxBr57E+Ilrs4Kw5N3/P9dbtZ29+r0LguiEfZ39kgiKweLTPoiqpZ3Ry0nDdBcztx/n i1CN2CVZWUVWGU3iVFM2Y07fcTzzPhRbV25675/TvFY94NPrJvkAla7vVVJOBnljynyP CStjlRA/4rQ4Vc7OFGdPQYzimMGHKqpqTmsO+HLpPsskNzxPa8m8g8i2Bl8Wt+HtgUWf GthxcTxOjDdJPPKKK6ZM2RG2LXDrStfuYD4dbI8exKEKEc7ym/hHhJtrP+W0bvmOTT5A jCEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710857011; x=1711461811; 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=81ZlGIHWVvJsZavkXdkR4RWq1LUYCfpde8wftsq27ag=; b=XdtsqX+8Wc1PGGolMe38Q88BRjhNZYJZzMOB3sZ6sZgGZYVBeYQFXfdd+6N/p9HH3B zC+n3cV0IuA7fJbAx+ZFItq8VQth99sBRJ2tRjUXukk3sDD10DIYfDF8Zp93ENOFpzgD gs8739Ni86os44Yxd/eYI1DPkXVmCDUGGrhp8A5lK8wQoeYlqf7ip6lSy0STcXE4CgBK hwINl1mRFVyD3L4VCXBieiSp6tGvK6AuiAgjtq2JVxruzn2bQfV+Xnea48AH0tNaBpJ/ 6X0tJQzw/nCTENZqFkmQT4ApPHKIBHdWqaOUwHfLtgSZDzdl30/IzH/EKf5NmqTQUTku Mfzw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWdqY4PZREVpGzvIz/Eh7TvwFaClIoqBpHf/q0pMXjg3GfRUsd4qgvbkA28a8Y2vP9wIrQQexAR6+SOIDjhlKPHNibRjZA= X-Gm-Message-State: AOJu0Yxm7yGDhKXdX4DrP1sU5ZGqkFxW5xaV43EJetLoj4sAfkEoYQEH r42nybDHLtfO+QDdPYUq9GgYgKwwdRg/wwM95DvWtGvzqGhwnqak X-Google-Smtp-Source: AGHT+IFaxQSTJCbp4jhRLJzmU63QxICCEhznUJOGpGqXUeUo4AmCVHwH1u9impSre/yoIRztCsaF4w== X-Received: by 2002:a05:6820:2714:b0:5a4:91c1:967b with SMTP id db20-20020a056820271400b005a491c1967bmr7931236oob.1.1710857011366; Tue, 19 Mar 2024 07:03:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a4a:a64b:0:b0:5a4:be52:5f48 with SMTP id j11-20020a4aa64b000000b005a4be525f48ls66891oom.0.-pod-prod-00-us; Tue, 19 Mar 2024 07:03:30 -0700 (PDT) X-Received: by 2002:a05:6830:4424:b0:6e6:7e75:99a with SMTP id q36-20020a056830442400b006e67e75099amr86196otv.1.1710857010622; Tue, 19 Mar 2024 07:03:30 -0700 (PDT) Received: by 2002:a05:6808:1150:b0:3c1:b790:b6ba with SMTP id 5614622812f47-3c25eca4aa3msb6e; Tue, 19 Mar 2024 06:46:36 -0700 (PDT) X-Received: by 2002:a17:902:c206:b0:1dd:7829:6a2b with SMTP id 6-20020a170902c20600b001dd78296a2bmr13501516pll.35.1710855995419; Tue, 19 Mar 2024 06:46:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1710855995; cv=none; d=google.com; s=arc-20160816; b=lFm+CiiqoRDHESOzflxcIdSSVZmJE7vBESVSgPEtVeIq+ccNHTZlZBDoWXhOXlEdSj i6VMg0gKiX5tuoOCtL+1IYbmjtozCt4vwfKHdqWINEWoq5PvcnHNTUNqmaj6+7ZxBsae GHNIOFHpfZCtkj3uW09eONxHiSQihbVaHW7JXWXZVuVdVoZWCp58kMMvSmNNX9+Yw6PG zi6/7rh9EIoQhQa/biKz8jrvezeS7hglgVkz41wKLgMdtD1ERPn7bD2x4Zy3kfRdJNvk ABr0APCKUtbsos4UZ2v2yXg5/wYuYJDFu+JphsQ/LZ9pNCSTd9u7sOgS56R4+9ynpMLR EGbA== 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=CVrEnRbnw+f/QGAtqpaM9e4mtaoGoNVdNmegbA+X83s=; fh=Zedq5pd0qyqVsmfgG+8/Y9cUOZXbXVTvFM2iZX29U/g=; b=d50oo9FX7wcilIIILx9R3SX8vvA1aA9XzEJsS+u4PZCC4A2nqm37KXqz/3XUArAJFj Mpq7eOe+rUn8tsMAYHXpJrON6TA4vDn+XW2HNIiYoyaiQVORKY0jbiN4/IJooLc8VG1Q z7sW0xw7dNlLOYnF9l1Ahb7/ZRDftbIJNk+Kuu2Slo3JIPxn7D9cyGKPu4vGdmnNWHLa BulomcKuOTmqdq3BrYpD1pzhiF31AuayRtraYy+3PXA0gOJQ/NDhBMkdB4Djd/7s7Dvt 1mfBuF7XzTcXV9vDMtT3cmqlCHhmQVgEtw048MoN/WjPIzwJvJADwYPacDUUXCD/8zPf k5Sw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=qas6Qltd; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.157 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from fhigh6-smtp.messagingengine.com (fhigh6-smtp.messagingengine.com. [103.168.172.157]) by gmr-mx.google.com with ESMTPS id w20-20020a170903311400b001def0ac0a35si768340plc.5.2024.03.19.06.46.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Mar 2024 06:46:35 -0700 (PDT) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.157 as permitted sender) client-ip=103.168.172.157; Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 977E711400DF; Tue, 19 Mar 2024 09:46:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 19 Mar 2024 09:46:34 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrledtgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtdorredttdejnecuhfhrohhmpefrvghtvghr ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg hrnhepjeeigedvjeffieeiledugeekgfeugfehudefjeetiedtvdeiveduieejveeitefg necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdho rhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Mar 2024 09:46:33 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 66D0B5F84B; Tue, 19 Mar 2024 13:46:30 +0000 (UTC) Date: Tue, 19 Mar 2024 13:46:30 +0000 From: Peter Todd To: Nagaev Boris Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qpQqvMxvNFBvdgMC" 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=qas6Qltd; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.157 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 (/) --qpQqvMxvNFBvdgMC Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 19, 2024 at 09:37:59AM -0300, Nagaev Boris wrote: > Hi Peter, >=20 > On Mon, Mar 18, 2024 at 10:24=E2=80=AFAM Peter Todd = wrote: > > Rule #6 creates a path dependency: the order in which replacement trans= actions > > are received determines which transactions are ultimately accepted. >=20 > I'd like to share my thoughts regarding RBFR rules and propose something. >=20 > The proposed RBFR rule is also path-dependent. Two transactions can > conflict with each other, but their fee rates can be too close for one > of them to eliminate the other from nodes' mempools. The first > transaction a node sees is kept in its mempool. It's not really fair to say that "the proposed RBFR rule is also path-dependent". What you're describing is a property of Bitcoin Core's mem= pool in general, for all transaction acceptance rules. We've *always* had the property that two essentially identical transactions, differing only in a trivial way, will be accepted on a first seen basis. Achieving consensus requires bandwidth, and since you can generate an essentially infinite numb= er of almost identical transactions, you'll always be able to find cases with = path dependency. > Is it possible to have a rule that is completely path-independent? The > eviction rules are path-independent iff, for each pair of conflicting > transactions A and B, it is always known which of them should be > preferred over the other, and this relation is transitive. Having such > a property would be very beneficial in preventing any attacks on the > mempool. This property of the mempool can also be seen as the eventual > consistency of all the mempools of the nodes. A good property, isn't > it? I'd suggest that you should argue concretely *why* this is a good property.= The RBF Rule #6 issue isn't strong evidence, as it's only related to a specific type of meaningful path dependency, where fees/size differ meaningfully. Yo= u're talking about all forms of path dependency, including trivial differences w= here fees/size are the same and only a txid differs due to a trivial change. > How can we design such a rule system? >=20 > 1. It must align with miners' incentives; otherwise, it simply won't wor= k. > 2. And it must not open the door for DoS attacks on the mempool. >=20 > The naive approach satisfying the first requirement is a simple rule > saying "the higher the fee rate, the more preferential is the > transaction." However it does not specify what to do with two > transactions of the same fee rate and also doesn't prevent DoS > attacks. The former is easy to fix, e.g. preferring the transaction > with lower txid. (Must be formally proven though.) Let's discuss the > latter, which is a stumbling stone here. > > Traditionally, the way of preventing DoS was to reject some > transactions and to stop their broadcasting at this node. What about > deprioritizing them instead? Make two priority queues of transactions > in the node: (1) to process incoming transactions and (2) to > broadcast. When a transaction is double-spent, it is deprioritized in > both queues. If an attacker sends many double-spending transactions to > DoS the mempool, not all of them are broadcast further because by the > time a transaction is ready to be broadcast, its newer version has > already evicted it; the first one is not yet broadcasted. So a node > broadcasts fewer transactions than it receives, which reduces the DoS > effect. And still, the whole system is eventually consistent; just > spammers get their transactions spread slower. >=20 > What are your thoughts on this scheme? So first of all, I'll point out that because you can brute force txid variations, if the rule is lowest txid wins, it wouldn't be hard to do a bi= t of brute forcing to get, say, 2^32 =3D 4 billion different variations. For practical purposes, that's basically infinite bandwidth. OTOH, suppose the rule is that the txid with the most leading zeros wins. T= his fixes the infinite bandwidth problem, as it's a clear PoW with something li= ke 48 possible total replacements at most (assuming a reasonable amount of tot= al PoW). But the mempool consensus problem remains unfixed, as there's essenti= ally infinite variations possible with the same number of leading zeros. Bitcoin doesn't have this issue because it has a minimum PoW, set by the difficulty algorithm. But we can't ask that of transactions in general. So = I think either way we've failed to actually achieve consensus over trivial variations. More broadly, I like the idea of using a bandwidth constrained channel for doing replacements where there are meaningful, but small, differences in th= e size and/or fees paid. But I think we should persue the idea on the basis t= hat it makes economic sense. Not that it'll prevent mempools from being out of consensus. --=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/ZfmXNiscjatFOOCX%40petertodd.org. --qpQqvMxvNFBvdgMC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmX5lzQACgkQLly11TVR Lze78RAAwzDJmjgERASvWoiVrT85/SmE3Frb0SNS6qxqYFfhqke4bjOOyw413HMh ubV4cYbyH7ctAGapp4RmrYdkTOPQEV/k9QZVVP+rlDJexPqyob6MD1fCrxJDrWeZ Cxsg53qKNANFSpXjmdBfbgLysPTRmTa2QPX35WOLwq6wk2gRypz4+vZ7hYPT0zOT HuXu6NxD85hCKMqRX062kN8Z98TrXMQWqQfOss4KO8Oq/qfSjJGOSgQfjVueOv/B 4RZZxGEFtOXLW8fdEhuP0ZTQN6ELJHW8lQchYwSnoB9egslMrMrf9hmDBkosyKXo tAXHpLUXPKyX8NJMfwZnM3m7AiP6PrmFKSBmUyrHGjcN2L5owpSy3U5ns6WmYoTR ixK7XlGsRu+6s2nmjJBmIChae5MzX+vqzasbv/q0UB6pyzLa2nLJD8ytx1SxoWug 25uSvUGmWFCIdC4C/ijsI1yRVoXfGJ9qZMTxQeReMFcMnQ33Xi/BU37jj4LPqOxy Mj1VuLoO0ezlvAgpI0E97B7aIR+RfwXQNszdvBmZ/wtqZwSb14h2yQxmDFPFYwM5 sIZ1nJxWaVVYW/bdfFumnpQIpz8T1u79vM27jcGLVM8k+97i+azM9GLyhB/4X6Bx F5tj9/Kx4w3ExzuqTKUYuJefPQ4x21MmZPfMhSKfVQQ2hyQxz/g= =VzLJ -----END PGP SIGNATURE----- --qpQqvMxvNFBvdgMC--