path: root/b7/e09e4cf5025afb55251e57fadd6eaba37fd471

Delivery-date: Tue, 27 May 2025 04:23:16 -0700
Received: from mail-oo1-f58.google.com ([209.85.161.58])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRYHVHZTUGRBGOB23AQMGQEYIDV5KI@googlegroups.com>)
	id 1uJsOo-0001pb-U7
	for bitcoindev@gnusha.org; Tue, 27 May 2025 04:23:16 -0700
Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-60bad575560sf1645064eaf.3
        for <bitcoindev@gnusha.org>; Tue, 27 May 2025 04:23:15 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1748344989; cv=pass;
        d=google.com; s=arc-20240605;
        b=XYYH5ngQYmTHs3ArmI1PWYO0ORvkYrnpiOdDO62VE+f8R0ZOKB7Bb2MmjpWv7QwWiU
         q9tPj70jNar0YTppXRtsJrjoRhF/+b165eEM/X7VMC0N6iezekXtAPQpNkq1X1nfG4Tc
         zMoE8dAH+xW0zSrRSLrUcCiYFMCWpHBH4WUsU2tyOB3kcQFkjkAsgklEa1DbtEiA9MRV
         ruftViq9fXJvnvg1GV00SqhMToOY5+QO1DhN5gPE9I/xTmjHn1a6SH3ezhYXDiUghMX3
         +8MxdbQf947xd8tD3JblNyjxqXOFcgzNrB0cHIpqV597LnVH6CBEtyuPbd+1ZT1VlixK
         aauw==
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:content-disposition:mime-version
         :message-id:subject:to:from:date:feedback-id:sender:dkim-signature;
        bh=I+wuUOE945s8UXbAYv1uDThN/2z9QDgstkpn6diZZ5k=;
        fh=2QogZ2urKlVzPFkPOSUpQiQJSOR8KOPSNd5hoRsNeb0=;
        b=DSMeJZNQlMXg4vyteQmnDCuDYc+UGzseMh3I70923NTck+ouCwqkNz+tWVk8fB9sBQ
         r9th+u9XtqQihlvjMpdEDnKB+7PaDuzmRPehGSgcjstA6ozhZeI+70YXxYJcKR0b+ocS
         pYgIYpuexSKUNyl+0US8dOh6v3J++VkXimfpGNYK91LwIaFvKTU4OzMWOZKuimK8qxF0
         d3+lQXGVspMo9FOILBjmoYOZ4etOp/C6LZq4YEoZBtH/qZcBDZ34HSpPf5Fm6KeU9aEk
         uVKHR3hpdiIcProTvNvW3In+72+t1K+Fg7xwcNO1DcCLDkTGJmlllMe9wkHIpncOEdXT
         DScQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=ZEy4yle+;
       spf=pass (google.com: domain of pete@petertodd.org designates 202.12.124.153 as permitted sender) smtp.mailfrom=pete@petertodd.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1748344989; x=1748949789; 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:content-disposition:mime-version:message-id
         :subject:to:from:date:feedback-id:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=I+wuUOE945s8UXbAYv1uDThN/2z9QDgstkpn6diZZ5k=;
        b=Ef6AkxeyAgTTYwLLCp2921n/tYYSr1E0qCVByPTFGf398/614ycpKREA/LFXVn47RU
         cSRcxQ9DaTtirtw+VbMXJZ9i2MRGX08JFIYC0IJsEHxXJuHwUqZyrvNbabQHtLrVfKXF
         ua94t2zhv4I5ALkpGxXK7plq70/ORk5cjXZH7J+XQGuaA4OQREM6uK2SMMmqUAS4kY3y
         kGI4Scj5BrhSaEe5GDuqFfEyKnFU61ja3t8SdT4Hjrjop1uoBrDAaybS2124Z0Ijg6e4
         3H+PTUXs4KbPBZe+2VghG+Hkkk3vncbPkCHJgwc4fIa/MO+qh4mQwBhvaAcE6YLcFM8U
         DI9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748344989; x=1748949789;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-disposition:mime-version:message-id
         :subject:to:from:date:feedback-id:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=I+wuUOE945s8UXbAYv1uDThN/2z9QDgstkpn6diZZ5k=;
        b=LCqcRomayinB+jzx8HUOTlAV7NHv2aN/7U1uP56A+rHH5xVUGkz5tQW3xlToSyE5lh
         C7rXC3sOdl7a1fdxC0jglyyctK4Q65hqriqMZNyLxnF8QCUcR8EMTflrfmY192gsx7uu
         8jc+AdOv/Nlau1G/7dQ2eJ7qjIC+KSba/lipMKIZHZlCLFYszBCxiMiWnwdkrH+0iy8W
         K7ZB1/OmYzPVyziVOiTsmMvEhiBJ1Tfp2FTMFHSILqZ1tLEvZjhTQo/x3UCK/qvoFb5l
         szonWIdzhc/yDHZnwcM/uDw1XV4qZ5ptYAKg9t7zDwoARRZvFJSn5WAAt24KoidgutDT
         lOHQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVX4oLwch5YC/o+51lULdJWUD+ciOA1UAr02HWEcl+0ddAvg2TwvoJRERwa6a40wREpZVNchF3PCAgE@gnusha.org
X-Gm-Message-State: AOJu0Yz8dU5OrwHR3yEns2RZvtxeA2e5/Lj7ZuFDzhS13rHtzBKRZzlR
	ftLagLx8W1trCtYJwSf3+A+QQC/UQgQT/IfiITehr2HKZaa6jzdR+1Ug
X-Google-Smtp-Source: AGHT+IFCoR3g548RCKknOb9c3A+QpUNz2RhBJuHWW6Lmr4Yk0UZ4fSXIMLMhINKtoqQsAZ3MPCsfug==
X-Received: by 2002:a05:6820:986:b0:60b:d0fa:e974 with SMTP id 006d021491bc7-60bd0faea31mr500751eaf.8.1748344989029;
        Tue, 27 May 2025 04:23:09 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHLAqgeKE4AWmOGa4vhHDotkfC3tmh+f/o+U3JuEOV1yQ==
Received: by 2002:a4a:e9a1:0:b0:606:75d6:45fe with SMTP id 006d021491bc7-60b9f480811ls884920eaf.0.-pod-prod-03-us;
 Tue, 27 May 2025 04:23:05 -0700 (PDT)
X-Received: by 2002:a05:6808:80ac:b0:3fa:8bfd:773f with SMTP id 5614622812f47-40646813dcfmr7589299b6e.2.1748344985231;
        Tue, 27 May 2025 04:23:05 -0700 (PDT)
Received: by 2002:a05:6808:8e6:b0:403:484c:9068 with SMTP id 5614622812f47-404da1b787dmsb6e;
        Tue, 27 May 2025 04:16:34 -0700 (PDT)
X-Received: by 2002:a05:6e02:3081:b0:3dc:8bd3:3cdd with SMTP id e9e14a558f8ab-3dc9b6800f6mr100277795ab.1.1748344594032;
        Tue, 27 May 2025 04:16:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1748344594; cv=none;
        d=google.com; s=arc-20240605;
        b=TMU3XAh0OAqc3Pw+SZXZiEjJP2KOAehRXrw2x6IdNrEzBsBESIhBl9EVXVe4dFE9IC
         FZG9sWXSBCqMOytoB5J5p/xHgsbCq8oXDoK5akqqiNg3G6jwZpskBgoRVjtmw/UC4J3c
         mwsG8PgY2AIOSdGperWiW+bSR3c4w1RUA3+8eccoGlXqcbPDVaW1+TWLYX1Ow3XQb7jI
         wxPO58OAOcdG+k/JM3zrwu2JMRj6+PCl99TmQZQe5jTu0VPL1xDwpH6Ghq0o3ri/XSEa
         vJRtctAUxZIk0lnXqgUjVM6ovBeXOQpQXi+6alB6R26i2rPL2zqRVAPxx0zKkJefSbbB
         cWKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-disposition:mime-version:message-id:subject:to:from:date
         :feedback-id:dkim-signature;
        bh=pgNlgZi5qMe3e5hykadLn54SEInKj6pklB3sFB6IF/4=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=F5yhcz1nGzUN97Otl1XEt183ljnACnZICfeSWXrdxuubnGsVCWnBsQwgUzGarrFjWe
         qe2YoJpggWICCBS7hSaHhS3CaPoxRTSxHF58X7qNuJihcpyZv8hSlck+bCMFNfYG9Y1q
         F7d7jRlls+pju9qCxaL6hqCV1f0Z5Dax9mWn96PfhSsaoeSyjBIML6s31GSu3u1Q+8Eb
         iKZ30U3sNgPoTxI0M/PLnzR+j2cfzyNLTApR1TnALf+M5vr57ikK+v4fP6ROonRinQ8c
         J8B++W5Zjn83LOI+/AmonL0x8xMojKBJgGyOR2635vESYwdcJgaGkAMdNEvEbtUuRrBK
         94cQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=ZEy4yle+;
       spf=pass (google.com: domain of pete@petertodd.org designates 202.12.124.153 as permitted sender) smtp.mailfrom=pete@petertodd.org
Received: from fhigh-b2-smtp.messagingengine.com (fhigh-b2-smtp.messagingengine.com. [202.12.124.153])
        by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-3dca268a201si2738455ab.3.2025.05.27.04.16.33
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 27 May 2025 04:16:33 -0700 (PDT)
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 202.12.124.153 as permitted sender) client-ip=202.12.124.153;
Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46])
	by mailfhigh.stl.internal (Postfix) with ESMTP id 0991725400E8
	for <bitcoindev@googlegroups.com>; Tue, 27 May 2025 07:16:33 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
  by phl-compute-06.internal (MEProxy); Tue, 27 May 2025 07:16:33 -0400
X-ME-Sender: <xms:EJ81aPl7i4JEOgH0JCtqi2-s8zwVp_uOCUiLUG3-lSNvSc90Oaep0g>
    <xme:EJ81aC2bR2aTj5L9t387ZT8UII4EQjaCeCsHWwOM80jgSPPmqpVWh4DcikejF5Wur
    l1OUJMU4AgmqqRLj1g>
X-ME-Received: <xmr:EJ81aFrYw-xms200wiz8-nmha-BJRq0sF3XeHrfSVL41vIwRqHf450Aze70P5gvflCu-XbT1lv3TYje0m9i_1gFRsiuRCEY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvtddvfeculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecunecujfgurhepfffhvffukfggtggusehgtderredttdejnecuhfhrohhmpefrvght
    vghrucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrth
    htvghrnhepueeiieehleelkeeuiefgveevudffuefhgeevleeghfdutdeghfdviefhtefh
    tefgnecuffhomhgrihhnpeguvghlvhhinhhgsghithgtohhinhdrohhrghdpghhithhhuh
    gsrdgtohhmpdhpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptden
    ucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhgpd
    hnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegsihht
    tghoihhnuggvvhesghhoohhglhgvghhrohhuphhsrdgtohhm
X-ME-Proxy: <xmx:EJ81aHlmn4dxekQAfgg_IrCg0sciGObV5CXqpQm8Wg78gnDDCXCejA>
    <xmx:EJ81aN0bv5YwHOXwG57a-cBNXlyaWt8mRRbFYO0eswUC58IDR38pdA>
    <xmx:EJ81aGsHCrnFHvbzFA4uyzUHQ6BcOxonp-XThsigqtHCxNk3fCo4Xg>
    <xmx:EJ81aBXcMN8eq-ZvMBp9wcb2beAqCDi6oVqOJAxLH9t1kslaHScolw>
    <xmx:EJ81aPvPJ5BtW7rcSUJMtyRfjbdfspI7nEwQjA45rxWano7Q9J2S56f0>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 <bitcoindev@googlegroups.com>; Tue, 27 May 2025 07:16:32 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
	id D30839FD96; Tue, 27 May 2025 11:16:28 +0000 (UTC)
Date: Tue, 27 May 2025 11:16:28 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man)
Message-ID: <aDWfDI03I-Rakopb@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="bh1QKAXYPIc7Vf4J"
Content-Disposition: inline
X-Original-Sender: pete@petertodd.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@messagingengine.com header.s=fm1 header.b=ZEy4yle+;       spf=pass
 (google.com: domain of pete@petertodd.org designates 202.12.124.153 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 (/)


--bh1QKAXYPIc7Vf4J
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Recently proponents of transaction "filtering" have started sybil attacking
Libre Relay nodes by running nodes with their "garbageman" fork=C2=B9. This=
 fork
falsely advertise the NODE_LIBRE_RELAY service bit, silently discards
transactions that would be relayed by real Libre Relay nodes, and does not
provide any. Additionally, they have made clear that they intend to ramp up
this sybil attack with the aim of preventing people people from getting
transactions that they disagree with mined:

	The costs will increase even more once Libre Relay=E2=80=99s DoS attacks o=
n
	bitcoin are countered by enough defensive nodes.
	-Chris Guida https://delvingbitcoin.org/t/addressing-community-concerns-an=
d-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardne=
ss-limits-on-op-return-outputs/1697/4

They have also put effort into making the attack more than a simple proof o=
f
concept, e.g. by adding code that attempts to make it more difficult to det=
ect
attacking nodes, by keeping track of transactions received from peers, and =
then
replying to inv messages with those transactions even when they were
discarded=C2=B2.

With this attack in mind, I thought this would be a good opportunity to rev=
iew
the math on how effective this type of attack is, as well as some of the
mitigations that could be implement to defeat sybil attacks on transaction
relaying. In particular, I'll present a defense to sybil attacks that is
sufficiently powerful that it may even negate the need for preferential pee=
ring
techniques like the NODE_LIBRE_RELAY bit.=20

Note that I don't deserve credit for any of these ideas. I'm just putting d=
own
in writing some ideas from Gregory Maxwell and others.


# The Effectiveness of Sybil Attacks on Transaction Relaying=20

Non-listening nodes make a certain number of outgoing, transaction relaying=
,
connections to listening nodes. In the case of Bitcoin Core, 8 outgoing
transaction relaying nodes; in the case of Libre Relay, an additional 4
outgoing connections to other Libre Relay nodes to relay transactions relev=
ant
to them.

For a sybil attack to succeed against a non-listing node, every one of the =
N
outgoing connections must be either a sybil attacking node, or a listening =
node
that itself has been defeated by sybil attack. Additionally, Bitcoin Core m=
akes
outgoing IPv4 and IPv6 connections to a diversity of address space, so the
sybil attacking nodes need to themselves be running on a diverse set of IP
addresses (this is not that difficult to achieve with VPS providers these
days). Thus if the sybil attacking nodes are a ratio of q to all nodes, the
probability of the attack succeeding is q^N.

Against Libre Relay, N=3D4, this means that the attacker needs to be runnin=
g ~84%
of all NODE_LIBRE_RELAY advertising nodes to have an attack success probabi=
lity
of ~50%. Based on information from my Bitcoin seed node, there appear to be
about 15 Libre Relay nodes, so for a 50% attack success probability the
attackers would need to run about 85 attack nodes. If N was increased to 8,=
 the
attackers would need about 172 nodes to achieve the same success rate.

Against *listening* nodes a different type of attack is necessary. The reas=
on
for this is that defenders can easily defeat sybil attacks against listenin=
g
nodes by simply connecting to ~all listening nodes at once to ensure that
transaction propagation succeeds. Of course, the attacker can in turn do th=
ings
like attempt to exhaust connection slots of Libre Relay nodes, or simply Do=
S
attack them with packet floods. But those are different types of attack tha=
n
the sybil attack we are discussing here.


# Prior Art: Defeating Block Propagation Sybil Attack

Bitcoin Core already includes a defense against sybil attack for block
propagation: the feeler node system. Basically, every ~2 minutes an outgoin=
g
connection is made to a gossiped address to check if a connection can be ma=
de;
successful connections are recorded in a table of "tried" addresses. If no =
new
blocks have been received for 30 minutes, these tried addresses are then us=
ed
every 10 minutes to try to find a peer that does know about a new block.=20

Since this process goes on indefinitely, so long as outgoing connections ar=
e
themselves not censored (e.g. by the ISP), the node should eventually find =
a
non-sybil attacking node and learn about the true most-work chain. Even in
normal operation periods of >30minutes between blocks are fairly common, so
this defense will (eventually) work even if a forked chain exists with some
hash power extending it.

This approach is relatively straightforward for block propagation, as there=
 is
a clear metric: the most-work chain. Peers that aren't giving you the most-=
work
chain can be ignored, and new peers found.  Proof-of-work's inherently
self-validating property means that doing this is cheap and straight forwar=
d.


# Directionality

A subtlety to the information censorship sybil attack is there are actually=
 two
different simultaneous attacks: the attack on preventing you from learning
about new information, and the attack on preventing you from distribute new
information to others.

With block propagation, most nodes most directly care about the first class=
 of
attack: they want to learn about the most-work chain, and do not want that
information censored from them.

For miners, in addition to knowing what the most-work chain is, they
(typically=C2=B3) have a strong incentive to get their new blocks to all no=
des as
quickly as possible. Also, all nodes have at least some incentive to do thi=
s as
Bitcoin will not function properly if miners are getting censored.

These attacks are not the same! The most-work-chain metric is only directly
detecting and preventing the first class of attack. It only prevents the se=
cond
attack indirectly, by making it easier for honest nodes to learn about new
blocks and attempt to themselves propagate that information further.


# Most Fees Metric

For transaction relaying, the moral equivalent to the most-work chain metri=
c
are metrics based on the amount of new transaction fees that peers are
advertising to you. Unfortunately this isn't as straightforward to implemen=
t as
the most-work chain metric for a few reasons:

1) Resolution: differences in chain work are very clear, with even a single
   additional block being a very significant difference. For transaction re=
laying,
   we'd like to be able to successfully relay transaction types that only a=
dd a
   small % to total fees.
2) Bandwidth: a chain of 80 byte headers is sufficient to prove most-work;
   transactions are much larger.
3) Double-spends: mempools are not a consensus. Your peers may have
   transactions that conflict with your transactions, yet in ways that don'=
t
   constitute a worthwhile RBF replacement (e.g. two different transactions
   with the same fees and fee-rate).

For example, one straight-forward approach would be to simply keep track of=
 a
decaying average of new fees/sec each peer had advertised to you prior to y=
ou
advertising the transaction to them. Periodically, you could drop the peer =
with
the lowest new fees/sec ranking, and then connect to a new peer.

However, it's not clear that this approach has sufficient resolution to
actually detect censorship of relatively uncommon transaction types.
Additionally, since transaction broadcasting is a one-shot event - we don't
have a mempool synchronization mechanism - this approach may not work well =
if
transaction demand is bursty.


# Most-Fees Next (Dobule) Block Mempool

With the upcoming cluster mempool functionality that is expected to be adde=
d to
Core in the near future, transactions will be stored in memory in clusters
ordered by fees: essentially the order in which optimal blocks would be
created. This will make it computationally cheap to determine what the opti=
mal
next block (or blocks) will be by simply iterating through transactions in
order, and stopping when N weight worth of transactions have been found.

Thus nodes can cheaply compute the total fees in the top one or two blocks
worth of transactions they currently have in their mempool, and advertise t=
his
fact to their peers. Finally, to prevent lying, we can add a mechanism for =
a
peer to get a copy of all these transactions to ensure that they're not mis=
sing
out on anything paying enough fees to get mined soon.

While beyond the scope of this summary, there are many set-reconciliation
techniques available to do this in a bandwidth efficient manner. Basically,
through the existing transaction relay mechanisms we can expect mempools to=
 be
relatively consistent between nodes. Thus, to get all transactions that you=
r
peer has for the next block or two that you do not, you just need to transf=
er
the deltas between their next-block(s) mempool and yours.

Concretely, suppose we do this with the next two blocks worth of transactio=
ns.
At worst, each node would need to periodically create a maximum 8MB seriali=
zed
"double-block", using up to 8MB of ram. Secondly, to apply this to all outg=
oing
connections, you'd need to periodically use a set-reconciliation protocol t=
o
download the differences between each of your outgoing peers' double-blocks=
,
and attempt to add any newly discovered transactions to your mempool. At wo=
rst
for 8 peers this would be 64MB of useless data to download, assuming every
single transaction was a conflicting double-spend. Not great. But not that =
bad.

As with the average fees idea, periodically you would drop the peer adverti=
sing
the lowest double-block of fees, and then connect to a new peer to see if
they're better.

Now consider what happens if you are sybil attacked. Due to RBF, with
synchronous mempools across different nodes with the same standardness poli=
cies
will have very similar transaction sets; even without active synchronizatio=
n
long-running mempools across different nodes are already very similar in te=
rms
of total fees. Thus even a small difference in transaction relay policy wil=
l
show up as missing transactions. This difference will translate into the sy=
bil
attacking node(s) getting dropped, and honest nodes with policy compatible =
with
yours eventually being found.


## Peers With More Liberal Relay Policy

If you apply set reconciliation to a peer with a *more* liberal relay polic=
y
than you, they'll have transactions that you will not accept. For example,
imagine the case of a peer that now accepts a new version number.

One way to deal with this could be to just drop peers that give you
transactions that you consider non-standard. So long as reconciliation is o=
nly
applied to a subset of all transaction relaying peers, this is fine. Indeed=
,
even if this is applied to all transaction relaying peers, Bitcoin Core alr=
eady
connects to additional peers in blocks-only mode. So you'll still get send =
and
receive blocks and maintain consensus.


## Privacy

Tracking what transactions are in mempools is a potential way for attackers=
 to
trace transactions back to their origin. Provided that set-reconciliation i=
s
only a secondary transaction relay mechanism, with sufficient time delays, =
this
should not impact privacy as under normal operation transactions will have
already propagated widely making the set reconciliation data non-sensitive.


# Manual Peering With Known-Honest Friendly Nodes

More of a social solution than a technical solution, we should encourage pe=
ople
to manually peer with other nodes they have a personal relationship with.  =
This
is a powerful technique against sybil attacks for the simple reason that
person-to-person relationships can evaluate honesty in much more powerful w=
ays
than any code could possibly do so.

At the moment, actually doing this is inconvenient. Ideally we would have a
mechanism where node operators could get a simple pubkey@address connection
string from their node to tell to their friends, and equally, import that s=
ame
connection string into their bitcoin.conf. This mechanism should use some k=
ind
of node identity to defeat MITM attacks, and also ensure that connection li=
mits
are bypassed for friendly nodes. The existing addnode mechanism doesn't qui=
te
achieve this. Notably, without a node identity mechanism, there's no way fo=
r
someone with a static IP address to whitelist a friend's node with a non-st=
atic
IP address.


# Footnotes

1) Chris Guida's "garbageman" branch: https://github.com/chrisguida/bitcoin=
/tree/garbageman,
   first presented at the btc++ mempool edition (2025) hackathon
2) https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f=
2706848c48fd2?s=3D09
3) https://petertodd.org/2016/block-publication-incentives-for-miners

--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
aDWfDI03I-Rakopb%40petertodd.org.

--bh1QKAXYPIc7Vf4J
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmg1nv8ACgkQLly11TVR
LzeUSg//dk6vfF+0CXM9WDoctjSJH0LFbEknKsUwGpz/l1ww+ebRQHF/pOaNiF7v
2fDUZa8M3eoi1ueU8Og43ufDqOU3AEDszO+9/L8pfn2XXB/JYhe5a+lVHcyWL/ot
21MK6u57hF0nwl05XsGsrCkcN7cuDV5aseIEFpUNNPtIl/zaPJozd3dTrlUtzZv3
9sEeOYGdNJXZvxc68tQfFdoOpEGcPLf6gZp9mfUOTyssU1lP0thL9uvkRu1vRAHn
dtuHaBCRjiwLr04iA/7nga6e1sCD4BIpBFCWOotxjHpX4zSKh7UerzNF9k/ZgnMJ
M8EVBnbxgxvgNbGalgK+Jue3Zif+ifbPTWYGE5ti1w4m4w60+fNwLVaz1vp4BaFY
V3Z3RIhIlyhLRNEZJUE2dPqkDEA8ki1v/10Q8h4w76zWkOt+ERHfHOwA0sMLe/4b
Y2pbM4TxjGYcIp/lPmsTD6rsLUvgL5jB93sCfUdy6CwcVl96Qi/2aUs1TFjPjxAr
5Guw+W9GhBYsE3MN12M3/DXDy07MmuFA6csQCq7/4TDmVNf8XZVj/Rj8MmHXUnAD
mwxzbtqmNCiRKPy90QXo2bdCFY1kVi+sGccDjJ45/hDjKHnslg1aQ+GK6fBPN2nl
9znwavAS4zRS1CkvG4H1rRO+gGzaBsdT8x79svfsE/PWIP5mO5A=
=jgC/
-----END PGP SIGNATURE-----

--bh1QKAXYPIc7Vf4J--