path: root/d3/58ddf1b5ae0a6b9b650c1e7d1d67c44b880b43

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 <bitcoindev+bncBDRYHVHZTUGRBMVW42XQMGQETJSCTQQ@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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: <xms:Opf5Zb4dVDcim1zsKyjIFCa4PlQA6-X3Hae49sb5CfTzCk2nUJSE-Q>
    <xme:Opf5ZQ56p5giiM3YWvqHRqGhfXajLZRSxHMVYGmB1TWS21Ok1T-asvmwVavQtjzcF
    RhfXa2pQfmwtVQJULc>
X-ME-Received: <xmr:Opf5ZSfkPxdFduwy5Fpa5HKLXcNoUmWjJQ5vsy42K8iwXPYBxZmB_cruQ30G>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrledtgdeftdcutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpeffhffvvefukfhfgggtuggjsehgtdorredttdejnecuhfhrohhmpefrvghtvghr
    ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg
    hrnhepjeeigedvjeffieeiledugeekgfeugfehudefjeetiedtvdeiveduieejveeitefg
    necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg
    eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdho
    rhhg
X-ME-Proxy: <xmx:Opf5ZcKaBrjXLPCaJOCxsbD4HM7qOHuVCODcQC5TGz9E6VdOpwJTlA>
    <xmx:Opf5ZfL09WyWVbEXxXQBPymrUgegf9Hr5t0KCuplEUNNHRKx8VKdQg>
    <xmx:Opf5ZVxTyYoMqUDJr3eDpObS76n62qLL7sLtgJoTSwhwM13phe7Wqg>
    <xmx:Opf5ZbK3Cgw6bNBEmkFHSMvPjgD6aVCRGAkK1HRzmCK-Iph_5RLbEA>
    <xmx:Opf5ZX9uHBrKomn9To2qKOEYDWxCoLjqhWdUi1oPeml1Scr73EtIKg>
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 <pete@petertodd.org>
To: Nagaev Boris <bnagaev@gmail.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
Message-ID: <ZfmXNiscjatFOOCX@petertodd.org>
References: <Zfg/6IZyA/iInyMx@petertodd.org>
 <CAFC_Vt7BE866DJGQ9EqA+DroEkDH+4U_72-RpCUfyrLHmtnZ1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="qpQqvMxvNFBvdgMC"
Content-Disposition: inline
In-Reply-To: <CAFC_Vt7BE866DJGQ9EqA+DroEkDH+4U_72-RpCUfyrLHmtnZ1Q@mail.gmail.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <pete@petertodd.org> =
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--