path: root/30/2e9d77341b521e15ee69cabeddde4de7b3f990

Delivery-date: Tue, 27 May 2025 04:42:32 -0700
Received: from mail-ot1-f60.google.com ([209.85.210.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDF6D753VYARBG6K23AQMGQE4VW3KYY@googlegroups.com>)
	id 1uJshR-0002Ns-Mo
	for bitcoindev@gnusha.org; Tue, 27 May 2025 04:42:31 -0700
Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-72c40592a9asf2099178a34.2
        for <bitcoindev@gnusha.org>; Tue, 27 May 2025 04:42:29 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1748346144; cv=pass;
        d=google.com; s=arc-20240605;
        b=GE76mKZxgcpWvlLb+WPKdYlUnfPrqan5JVJXI3XXuYCNQjox9ECwdOcCUinxY3Y8Pe
         7miaBcdlbNfGTMPmTHovW4ExKbLwOGw023g2AeJThX0Vq7IY1pqqekCqY0CI9ebLSkRu
         q0hRcNNJAyDPHNI9MK+dI/o72qpF5rFxbdf3FlhYwECucfxk5Mg4cK7qTsqfvKhf3bsU
         T8tC2Wd7sDc3o4+LUDZIqQl5pDQyNSbl7laGXu8xghO6q8AVOq8UG7VYyTBSfLxetupN
         dM3zEhnBwSLKreXRjsFJ43npxqPdZhjFb6eeMxKcKYo84AIPtC3x4rTniQHwMOG6wQjm
         hNBQ==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature;
        bh=A+lw9xkzS4JRHwQu6AMlsS6jmpfy/OqqM0wic8rc7lI=;
        fh=8qzRgecAY1lDxBdTGbMxZhZsea2Uu4xO4Ky2IJ1U3Sk=;
        b=bZoK7hCR4DNrDdFaV/IYezJXkpd8BIOizjYcRq9wH+wFr7fUyBfj2k/puWcwJ7O7Bd
         jki+QDw3qPuEjE90y91oU1XKMOSgGNIqBTrR3UvwoWRCEaCez5g6oO1PUp471FrJxvmH
         rpu5j2QkI6SMRNg6KRDTyoE5wiHalm3TrWhd1tzjj28DvfPI36YhJzx+RZLe4F6vdzqF
         XvAeSgdcOelBag+tBjKWxb9tb1qmPA971S2Kj55VXKt/VTIcakA624LLUX/I8OgTnn/4
         EXMAvgUNWj3ZZRHIfewcjWzI9F1z8HionaRnNCs8pdFv3cjhvzWlsweC35lU31GxO3X+
         vV1Q==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@synonym-to.20230601.gappssmtp.com header.s=20230601 header.b=lNYhNIJn;
       spf=none (google.com: john@synonym.to does not designate permitted sender hosts) smtp.mailfrom=john@synonym.to;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1748346144; x=1748950944; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=A+lw9xkzS4JRHwQu6AMlsS6jmpfy/OqqM0wic8rc7lI=;
        b=vMBfER2oZbFpkaq/NRRIr8r3Dopmktu3m28XpAXYhxfOykSvZQFaVorjhKZLCAfbWv
         O6630B40aAn0/NWzKHhNbUHLdAfIws7YYXpoxMi1Ia+XnCReaQWFNGC/EpgnshzZ4Prd
         N14lY/9XgDcNqR2k1jNEMCK5qzWZAFz8Qg1Mwv0ZC4kq5GCGmQq1Xn5oqnXnfnD/z9GN
         4VulqARnHNCgxAaJ0P/S6TfCbcxptscQ641S1dyJDUrFqUVAPpLRjAUR+RM7k3HDnBxo
         SejBVM8ZKQ3ovfygD/FElMb0s526LOGy4uX+XYBrBabWXvwdgmcTbB090TsFA+XRdDVe
         hAGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748346144; x=1748950944;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=A+lw9xkzS4JRHwQu6AMlsS6jmpfy/OqqM0wic8rc7lI=;
        b=i7dpInp1LUqLT45+b3YlrXP49Uif0ZOuS8Ox6EaS9aOaKWsh9/Nuc2b9x/CuHiXPBw
         m+RatHoZpNDTRrcAwBFYskNrUVmCz16ctKEiE6p62Qv8ppSPDBxQPwtyFMlr/VoNDoAR
         zWCBXfIdcNljgCcVMwTCPPvR6UphiXn6ktsEukrtaPUf7qOlMFEao63QyOntlJ6B6KEs
         g4Id1SLvxij1RPrWjPqun525C4bErUOMWDtPo6CeEGrynnFRsHr0DEL0uSYHmwlDwbsj
         JrPu7zWkzDXOpI7BK5R8aYSyv7OhTR+DdvgBV6gPTn5tlGjNGMQ5PHi4XGKKjRkd4OZt
         OkLg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVsbS10IITkSshlbELhys1mLPxlZFWJpTZoibNVd7jULyIDInR7tRGwq7bEesa2orMWjOAF5+UdNCpf@gnusha.org
X-Gm-Message-State: AOJu0Yxyu5ZOIXJNWfH1JdP0drM3f+19O+ra3wfBn11iA7HlPVOTn01O
	BQgjNSzKc5YnJ1DskMweNdLsxjAb66kj2vN9/zc0+awyTKwm1VezpHO5
X-Google-Smtp-Source: AGHT+IHTzUYTuC5EW3qx5R4b+CLClWC/3rRG4Gh3I9r8C66JE5bHlJx1P6zvpKS505yxlfUV2oUe0w==
X-Received: by 2002:a05:6870:e994:b0:2d4:e420:926c with SMTP id 586e51a60fabf-2e861875f2cmr5933793fac.0.1748346142683;
        Tue, 27 May 2025 04:42:22 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcWxyFjq50CqXC006tttuEyKe0XBDjn3khBEs8LxbFUZA==
Received: by 2002:a05:6870:911e:b0:2b8:f3e5:a817 with SMTP id
 586e51a60fabf-2e85fa2eb38ls1028274fac.2.-pod-prod-02-us; Tue, 27 May 2025
 04:42:19 -0700 (PDT)
X-Received: by 2002:a05:6808:11d1:b0:400:b701:33cf with SMTP id 5614622812f47-406467ef69emr6213306b6e.15.1748346139441;
        Tue, 27 May 2025 04:42:19 -0700 (PDT)
Received: by 2002:a05:6808:8e6:b0:403:484c:9068 with SMTP id 5614622812f47-404da1b787dmsb6e;
        Tue, 27 May 2025 04:37:48 -0700 (PDT)
X-Received: by 2002:a05:6808:8009:b0:404:deb8:403d with SMTP id 5614622812f47-4064686c77emr5592536b6e.38.1748345867887;
        Tue, 27 May 2025 04:37:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1748345867; cv=none;
        d=google.com; s=arc-20240605;
        b=UbK6QEqs1jJKmVyEX6zO66nTZavDncjxefK/UJ8MChDiBuPSZeqmN3Hw2UbutZN+73
         cUrd9TP3RPA3NnlwpBAPgSsOwOYjfFqPoOcy0/ZCmw4exK3MXy1HtvXrMZoFNpPir1eq
         qN9RQVdKduNCFuDH5/OIQPKJ+nkGMs2Tfcjk6uc+pcR5oATeJ81SEU9LyLWXiS868Xb6
         VZSc7EAqVw3FknQJ2nxbzJY8guANN9mNMz5Ur5GJMYDeRbr8ZF9RAhnF1I0Hnc0IpaRG
         ZPIt4EQc9sInKsOiOz5Y6ue1h5KLO/7hm91f6z/XmCZKy6wv+PAoSbOzq1fvETmKfePz
         7Ktw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=2lR8E9TRLugsqjwkTpbGyIHVYwHntBq4TV4y3TzVXdg=;
        fh=psWP3UCtCzzPEOUoUzVM9ZZK8adYsTeWDAKCd6L5Zok=;
        b=e5SINTvKQfx6g6pTmkXpxKZBD2qxrdVFNF81DPOyn/8UA1AVKchpH/2Vyi/BHG0eVO
         TBBeQpNfVbKvJJdEpc5q03JrbYe8Eys+dOA/EcmYv09luAMeoGmPDIIP66BHe5DHbaSg
         RwIx4G5XSLxCsH9F4oqohgOnpLi4bROJ8NNhk/txMki8U0uULOF710+5+/e2z92565bJ
         w9q4Jj53pDy+YIUWn+aw5lkMJdod8AZgi8Jwy5jS0D4strqSgTVzo2uH1GHUyhnQ4Zfy
         iiBl/Dv2s6oD/yEy7t92YsPmSyATH4Af6hiKeh1o2iP6CvDckb1QtKOo5sXa/lpSuwdg
         I83Q==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@synonym-to.20230601.gappssmtp.com header.s=20230601 header.b=lNYhNIJn;
       spf=none (google.com: john@synonym.to does not designate permitted sender hosts) smtp.mailfrom=john@synonym.to;
       dara=pass header.i=@googlegroups.com
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com. [2607:f8b0:4864:20::1130])
        by gmr-mx.google.com with ESMTPS id 5614622812f47-404d96dbf7esi2903b6e.0.2025.05.27.04.37.47
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 27 May 2025 04:37:47 -0700 (PDT)
Received-SPF: none (google.com: john@synonym.to does not designate permitted sender hosts) client-ip=2607:f8b0:4864:20::1130;
Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-70e2b601a6bso25147437b3.0
        for <bitcoindev@googlegroups.com>; Tue, 27 May 2025 04:37:47 -0700 (PDT)
X-Gm-Gg: ASbGncsg3kxl2VslDs+X3R2SLgDh4l6liBc3jRkIqDCbe89+gA8cjA5xDDB4nyU7Xcs
	kdSbYKC/WXFueTI3HyaUcCgnIUXsgLH4nSBXO0Dm0HppUSb07DI5kbb84oR5ZeCzVV8/rOzr+Lf
	P4rW9GYTHV5hq7N4ezHOy0N6FXZfdiY85JE3YLeFLpLT2WHVbWHJ3H7M7xP5A7JXQqwQ==
X-Received: by 2002:a05:690c:4b89:b0:6fd:453b:8975 with SMTP id
 00721157ae682-70e2da77bfemr139812097b3.23.1748345867055; Tue, 27 May 2025
 04:37:47 -0700 (PDT)
MIME-Version: 1.0
References: <aDWfDI03I-Rakopb@petertodd.org>
In-Reply-To: <aDWfDI03I-Rakopb@petertodd.org>
From: John Carvalho <john@synonym.to>
Date: Tue, 27 May 2025 12:37:36 +0100
X-Gm-Features: AX0GCFt_RtEHa5QRoGZ6mHOo9NLNStsK3iGYIubtTlwoxzl76ILJiraqx64r2bM
Message-ID: <CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw@mail.gmail.com>
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out
 the garbage(man)
To: Peter Todd <pete@petertodd.org>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="00000000000059cccb06361c7efe"
X-Original-Sender: john@synonym.to
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@synonym-to.20230601.gappssmtp.com header.s=20230601
 header.b=lNYhNIJn;       spf=none (google.com: john@synonym.to does not
 designate permitted sender hosts) smtp.mailfrom=john@synonym.to;
       dara=pass header.i=@googlegroups.com
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.7 (/)

--00000000000059cccb06361c7efe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I noticed your mention of a missing pubkey identity capability.

A censorship-resistant key-based discovery mechanism is available, PKDNS,
at github.com/pubky/pkarr (also /mainline and /pkdns), which essentially
provides public-key domains controlled by the keyholder.

No blockchains, just the largest, oldest, p2p network on earth, Mainline
DHT.

This could be used to dynamically provide or update any endpoint, associate
or disassociate keys, or create revokable account-based sessions, etc.

These links may address peoples' likely counterarguments:
-
https://medium.com/pubky/public-key-domains-censorship-resistance-explained=
-33d0333e6123
- https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb

Maybe this helps you, or others looking for such primitives!

--
John Carvalho
CEO, Synonym.to <http://synonym.to/>



On Tue, May 27, 2025 at 12:23=E2=80=AFPM Peter Todd <pete@petertodd.org> wr=
ote:

> Recently proponents of transaction "filtering" have started sybil attacki=
ng
> Libre Relay nodes by running nodes with their "garbageman" fork=C2=B9. Th=
is fork
> falsely advertise the NODE_LIBRE_RELAY service bit, silently discards
> transactions that would be relayed by real Libre Relay nodes, and does no=
t
> 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 on
>         bitcoin are countered by enough defensive nodes.
>         -Chris Guida
> https://delvingbitcoin.org/t/addressing-community-concerns-and-objections=
-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on=
-op-return-outputs/1697/4
>
> They have also put effort into making the attack more than a simple proof
> of
> concept, e.g. by adding code that attempts to make it more difficult to
> detect
> attacking nodes, by keeping track of transactions received from peers, an=
d
> 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
> review
> 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 transactio=
n
> relaying. In particular, I'll present a defense to sybil attacks that is
> sufficiently powerful that it may even negate the need for preferential
> peering
> techniques like the NODE_LIBRE_RELAY bit.
>
> Note that I don't deserve credit for any of these ideas. I'm just putting
> down
> in writing some ideas from Gregory Maxwell and others.
>
>
> # The Effectiveness of Sybil Attacks on Transaction Relaying
>
> 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
> relevant
> to them.
>
> For a sybil attack to succeed against a non-listing node, every one of th=
e
> N
> outgoing connections must be either a sybil attacking node, or a listenin=
g
> node
> that itself has been defeated by sybil attack. Additionally, Bitcoin Core
> makes
> outgoing IPv4 and IPv6 connections to a diversity of address space, so th=
e
> sybil attacking nodes need to themselves be running on a diverse set of I=
P
> 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, t=
he
> probability of the attack succeeding is q^N.
>
> Against Libre Relay, N=3D4, this means that the attacker needs to be runn=
ing
> ~84%
> of all NODE_LIBRE_RELAY advertising nodes to have an attack success
> probability
> 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
> reason
> for this is that defenders can easily defeat sybil attacks against
> listening
> nodes by simply connecting to ~all listening nodes at once to ensure that
> transaction propagation succeeds. Of course, the attacker can in turn do
> things
> like attempt to exhaust connection slots of Libre Relay nodes, or simply
> DoS
> attack them with packet floods. But those are different types of attack
> than
> 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
> outgoing
> connection is made to a gossiped address to check if a connection can be
> made;
> successful connections are recorded in a table of "tried" addresses. If n=
o
> new
> blocks have been received for 30 minutes, these tried addresses are then
> used
> every 10 minutes to try to find a peer that does know about a new block.
>
> Since this process goes on indefinitely, so long as outgoing connections
> are
> themselves not censored (e.g. by the ISP), the node should eventually fin=
d
> a
> non-sybil attacking node and learn about the true most-work chain. Even i=
n
> normal operation periods of >30minutes between blocks are fairly common, =
so
> this defense will (eventually) work even if a forked chain exists with so=
me
> 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
> forward.
>
>
> # Directionality
>
> A subtlety to the information censorship sybil attack is there are
> actually two
> different simultaneous attacks: the attack on preventing you from learnin=
g
> about new information, and the attack on preventing you from distribute n=
ew
> 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 tha=
t
> 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 =
nodes
> as
> quickly as possible. Also, all nodes have at least some incentive to do
> this as
> Bitcoin will not function properly if miners are getting censored.
>
> These attacks are not the same! The most-work-chain metric is only direct=
ly
> detecting and preventing the first class of attack. It only prevents the
> second
> attack indirectly, by making it easier for honest nodes to learn about ne=
w
> blocks and attempt to themselves propagate that information further.
>
>
> # Most Fees Metric
>
> For transaction relaying, the moral equivalent to the most-work chain
> metric
> are metrics based on the amount of new transaction fees that peers are
> advertising to you. Unfortunately this isn't as straightforward to
> implement as
> the most-work chain metric for a few reasons:
>
> 1) Resolution: differences in chain work are very clear, with even a sing=
le
>    additional block being a very significant difference. For transaction
> relaying,
>    we'd like to be able to successfully relay transaction types that only
> add 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 transactio=
ns
>    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
> you
> advertising the transaction to them. Periodically, you could drop the pee=
r
> 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 wel=
l
> if
> transaction demand is bursty.
>
>
> # Most-Fees Next (Dobule) Block Mempool
>
> With the upcoming cluster mempool functionality that is expected to be
> added to
> Core in the near future, transactions will be stored in memory in cluster=
s
> ordered by fees: essentially the order in which optimal blocks would be
> created. This will make it computationally cheap to determine what the
> optimal
> next block (or blocks) will be by simply iterating through transactions i=
n
> 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 block=
s
> worth of transactions they currently have in their mempool, and advertise
> this
> fact to their peers. Finally, to prevent lying, we can add a mechanism fo=
r
> a
> peer to get a copy of all these transactions to ensure that they're not
> missing
> 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. Basicall=
y,
> through the existing transaction relay mechanisms we can expect mempools
> to be
> relatively consistent between nodes. Thus, to get all transactions that
> your
> peer has for the next block or two that you do not, you just need to
> transfer
> the deltas between their next-block(s) mempool and yours.
>
> Concretely, suppose we do this with the next two blocks worth of
> transactions.
> At worst, each node would need to periodically create a maximum 8MB
> serialized
> "double-block", using up to 8MB of ram. Secondly, to apply this to all
> outgoing
> connections, you'd need to periodically use a set-reconciliation protocol
> to
> download the differences between each of your outgoing peers'
> double-blocks,
> and attempt to add any newly discovered transactions to your mempool. At
> worst
> for 8 peers this would be 64MB of useless data to download, assuming ever=
y
> single transaction was a conflicting double-spend. Not great. But not tha=
t
> bad.
>
> As with the average fees idea, periodically you would drop the peer
> advertising
> 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
> policies
> will have very similar transaction sets; even without active
> synchronization
> long-running mempools across different nodes are already very similar in
> terms
> of total fees. Thus even a small difference in transaction relay policy
> will
> show up as missing transactions. This difference will translate into the
> sybil
> attacking node(s) getting dropped, and honest nodes with policy compatibl=
e
> with
> yours eventually being found.
>
>
> ## Peers With More Liberal Relay Policy
>
> If you apply set reconciliation to a peer with a *more* liberal relay
> policy
> 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
> only
> 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
> already
> connects to additional peers in blocks-only mode. So you'll still get sen=
d
> 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
> is
> only a secondary transaction relay mechanism, with sufficient time delays=
,
> this
> should not impact privacy as under normal operation transactions will hav=
e
> already propagated widely making the set reconciliation data non-sensitiv=
e.
>
>
> # Manual Peering With Known-Honest Friendly Nodes
>
> More of a social solution than a technical solution, we should encourage
> people
> 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
> ways
> 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
> same
> connection string into their bitcoin.conf. This mechanism should use some
> kind
> of node identity to defeat MITM attacks, and also ensure that connection
> limits
> are bypassed for friendly nodes. The existing addnode mechanism doesn't
> quite
> achieve this. Notably, without a node identity mechanism, there's no way
> for
> someone with a static IP address to whitelist a friend's node with a
> non-static
> 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/e9a921c045d64828a5f0de58d8f2=
706848c48fd2?s=3D09
> 3) https://petertodd.org/2016/block-publication-incentives-for-miners
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> --
> 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/aDWfDI03I-Rakopb%40petertodd=
.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/=
CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com.

--00000000000059cccb06361c7efe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I noticed your mention of a missing pubkey identity c=
apability.=C2=A0</div><div><br></div><div>A censorship-resistant key-based =
discovery mechanism is available, PKDNS, at <a href=3D"http://github.com/pu=
bky/pkarr">github.com/pubky/pkarr</a> (also /mainline and /pkdns), which es=
sentially provides public-key domains controlled by the keyholder.=C2=A0</d=
iv><div><br></div><div>No blockchains, just the largest, oldest, p2p networ=
k on earth, Mainline DHT.</div><div><br></div><div>This could be used to dy=
namically provide or update any endpoint, associate or disassociate keys, o=
r create revokable account-based sessions, etc.</div><div><br></div><div>Th=
ese links may address peoples&#39; likely counterarguments:</div><div>-=C2=
=A0<a href=3D"https://medium.com/pubky/public-key-domains-censorship-resist=
ance-explained-33d0333e6123">https://medium.com/pubky/public-key-domains-ce=
nsorship-resistance-explained-33d0333e6123</a></div><div>-=C2=A0<a href=3D"=
https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb">ht=
tps://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb</a></=
div><div><br></div><div>Maybe this helps you, or others looking for such pr=
imitives!</div><div>=C2=A0</div><div><div dir=3D"ltr" class=3D"gmail_signat=
ure" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"col=
or:rgb(34,34,34)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"lt=
r" style=3D"color:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div d=
ir=3D"ltr">CEO,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17,8=
5,204)" target=3D"_blank">Synonym.to</a><br><div><font size=3D"1"><br></fon=
t></div><div></div></div></div></div></div></div><br></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Tue, May 27, 2025 at 12:23=E2=80=AFPM Peter Todd &lt;<a href=3D"mailto=
:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">Recently proponents of transaction &=
quot;filtering&quot; have started sybil attacking<br>
Libre Relay nodes by running nodes with their &quot;garbageman&quot; fork=
=C2=B9. This fork<br>
falsely advertise the NODE_LIBRE_RELAY service bit, silently discards<br>
transactions that would be relayed by real Libre Relay nodes, and does not<=
br>
provide any. Additionally, they have made clear that they intend to ramp up=
<br>
this sybil attack with the aim of preventing people people from getting<br>
transactions that they disagree with mined:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The costs will increase even more once Libre Re=
lay=E2=80=99s DoS attacks on<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin are countered by enough defensive nodes=
.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -Chris Guida <a href=3D"https://delvingbitcoin.=
org/t/addressing-community-concerns-and-objections-regarding-my-recent-prop=
osal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4=
" rel=3D"noreferrer" target=3D"_blank">https://delvingbitcoin.org/t/address=
ing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax=
-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4</a><br>
<br>
They have also put effort into making the attack more than a simple proof o=
f<br>
concept, e.g. by adding code that attempts to make it more difficult to det=
ect<br>
attacking nodes, by keeping track of transactions received from peers, and =
then<br>
replying to inv messages with those transactions even when they were<br>
discarded=C2=B2.<br>
<br>
With this attack in mind, I thought this would be a good opportunity to rev=
iew<br>
the math on how effective this type of attack is, as well as some of the<br=
>
mitigations that could be implement to defeat sybil attacks on transaction<=
br>
relaying. In particular, I&#39;ll present a defense to sybil attacks that i=
s<br>
sufficiently powerful that it may even negate the need for preferential pee=
ring<br>
techniques like the NODE_LIBRE_RELAY bit. <br>
<br>
Note that I don&#39;t deserve credit for any of these ideas. I&#39;m just p=
utting down<br>
in writing some ideas from Gregory Maxwell and others.<br>
<br>
<br>
# The Effectiveness of Sybil Attacks on Transaction Relaying <br>
<br>
Non-listening nodes make a certain number of outgoing, transaction relaying=
,<br>
connections to listening nodes. In the case of Bitcoin Core, 8 outgoing<br>
transaction relaying nodes; in the case of Libre Relay, an additional 4<br>
outgoing connections to other Libre Relay nodes to relay transactions relev=
ant<br>
to them.<br>
<br>
For a sybil attack to succeed against a non-listing node, every one of the =
N<br>
outgoing connections must be either a sybil attacking node, or a listening =
node<br>
that itself has been defeated by sybil attack. Additionally, Bitcoin Core m=
akes<br>
outgoing IPv4 and IPv6 connections to a diversity of address space, so the<=
br>
sybil attacking nodes need to themselves be running on a diverse set of IP<=
br>
addresses (this is not that difficult to achieve with VPS providers these<b=
r>
days). Thus if the sybil attacking nodes are a ratio of q to all nodes, the=
<br>
probability of the attack succeeding is q^N.<br>
<br>
Against Libre Relay, N=3D4, this means that the attacker needs to be runnin=
g ~84%<br>
of all NODE_LIBRE_RELAY advertising nodes to have an attack success probabi=
lity<br>
of ~50%. Based on information from my Bitcoin seed node, there appear to be=
<br>
about 15 Libre Relay nodes, so for a 50% attack success probability the<br>
attackers would need to run about 85 attack nodes. If N was increased to 8,=
 the<br>
attackers would need about 172 nodes to achieve the same success rate.<br>
<br>
Against *listening* nodes a different type of attack is necessary. The reas=
on<br>
for this is that defenders can easily defeat sybil attacks against listenin=
g<br>
nodes by simply connecting to ~all listening nodes at once to ensure that<b=
r>
transaction propagation succeeds. Of course, the attacker can in turn do th=
ings<br>
like attempt to exhaust connection slots of Libre Relay nodes, or simply Do=
S<br>
attack them with packet floods. But those are different types of attack tha=
n<br>
the sybil attack we are discussing here.<br>
<br>
<br>
# Prior Art: Defeating Block Propagation Sybil Attack<br>
<br>
Bitcoin Core already includes a defense against sybil attack for block<br>
propagation: the feeler node system. Basically, every ~2 minutes an outgoin=
g<br>
connection is made to a gossiped address to check if a connection can be ma=
de;<br>
successful connections are recorded in a table of &quot;tried&quot; address=
es. If no new<br>
blocks have been received for 30 minutes, these tried addresses are then us=
ed<br>
every 10 minutes to try to find a peer that does know about a new block. <b=
r>
<br>
Since this process goes on indefinitely, so long as outgoing connections ar=
e<br>
themselves not censored (e.g. by the ISP), the node should eventually find =
a<br>
non-sybil attacking node and learn about the true most-work chain. Even in<=
br>
normal operation periods of &gt;30minutes between blocks are fairly common,=
 so<br>
this defense will (eventually) work even if a forked chain exists with some=
<br>
hash power extending it.<br>
<br>
This approach is relatively straightforward for block propagation, as there=
 is<br>
a clear metric: the most-work chain. Peers that aren&#39;t giving you the m=
ost-work<br>
chain can be ignored, and new peers found.=C2=A0 Proof-of-work&#39;s inhere=
ntly<br>
self-validating property means that doing this is cheap and straight forwar=
d.<br>
<br>
<br>
# Directionality<br>
<br>
A subtlety to the information censorship sybil attack is there are actually=
 two<br>
different simultaneous attacks: the attack on preventing you from learning<=
br>
about new information, and the attack on preventing you from distribute new=
<br>
information to others.<br>
<br>
With block propagation, most nodes most directly care about the first class=
 of<br>
attack: they want to learn about the most-work chain, and do not want that<=
br>
information censored from them.<br>
<br>
For miners, in addition to knowing what the most-work chain is, they<br>
(typically=C2=B3) have a strong incentive to get their new blocks to all no=
des as<br>
quickly as possible. Also, all nodes have at least some incentive to do thi=
s as<br>
Bitcoin will not function properly if miners are getting censored.<br>
<br>
These attacks are not the same! The most-work-chain metric is only directly=
<br>
detecting and preventing the first class of attack. It only prevents the se=
cond<br>
attack indirectly, by making it easier for honest nodes to learn about new<=
br>
blocks and attempt to themselves propagate that information further.<br>
<br>
<br>
# Most Fees Metric<br>
<br>
For transaction relaying, the moral equivalent to the most-work chain metri=
c<br>
are metrics based on the amount of new transaction fees that peers are<br>
advertising to you. Unfortunately this isn&#39;t as straightforward to impl=
ement as<br>
the most-work chain metric for a few reasons:<br>
<br>
1) Resolution: differences in chain work are very clear, with even a single=
<br>
=C2=A0 =C2=A0additional block being a very significant difference. For tran=
saction relaying,<br>
=C2=A0 =C2=A0we&#39;d like to be able to successfully relay transaction typ=
es that only add a<br>
=C2=A0 =C2=A0small % to total fees.<br>
2) Bandwidth: a chain of 80 byte headers is sufficient to prove most-work;<=
br>
=C2=A0 =C2=A0transactions are much larger.<br>
3) Double-spends: mempools are not a consensus. Your peers may have<br>
=C2=A0 =C2=A0transactions that conflict with your transactions, yet in ways=
 that don&#39;t<br>
=C2=A0 =C2=A0constitute a worthwhile RBF replacement (e.g. two different tr=
ansactions<br>
=C2=A0 =C2=A0with the same fees and fee-rate).<br>
<br>
For example, one straight-forward approach would be to simply keep track of=
 a<br>
decaying average of new fees/sec each peer had advertised to you prior to y=
ou<br>
advertising the transaction to them. Periodically, you could drop the peer =
with<br>
the lowest new fees/sec ranking, and then connect to a new peer.<br>
<br>
However, it&#39;s not clear that this approach has sufficient resolution to=
<br>
actually detect censorship of relatively uncommon transaction types.<br>
Additionally, since transaction broadcasting is a one-shot event - we don&#=
39;t<br>
have a mempool synchronization mechanism - this approach may not work well =
if<br>
transaction demand is bursty.<br>
<br>
<br>
# Most-Fees Next (Dobule) Block Mempool<br>
<br>
With the upcoming cluster mempool functionality that is expected to be adde=
d to<br>
Core in the near future, transactions will be stored in memory in clusters<=
br>
ordered by fees: essentially the order in which optimal blocks would be<br>
created. This will make it computationally cheap to determine what the opti=
mal<br>
next block (or blocks) will be by simply iterating through transactions in<=
br>
order, and stopping when N weight worth of transactions have been found.<br=
>
<br>
Thus nodes can cheaply compute the total fees in the top one or two blocks<=
br>
worth of transactions they currently have in their mempool, and advertise t=
his<br>
fact to their peers. Finally, to prevent lying, we can add a mechanism for =
a<br>
peer to get a copy of all these transactions to ensure that they&#39;re not=
 missing<br>
out on anything paying enough fees to get mined soon.<br>
<br>
While beyond the scope of this summary, there are many set-reconciliation<b=
r>
techniques available to do this in a bandwidth efficient manner. Basically,=
<br>
through the existing transaction relay mechanisms we can expect mempools to=
 be<br>
relatively consistent between nodes. Thus, to get all transactions that you=
r<br>
peer has for the next block or two that you do not, you just need to transf=
er<br>
the deltas between their next-block(s) mempool and yours.<br>
<br>
Concretely, suppose we do this with the next two blocks worth of transactio=
ns.<br>
At worst, each node would need to periodically create a maximum 8MB seriali=
zed<br>
&quot;double-block&quot;, using up to 8MB of ram. Secondly, to apply this t=
o all outgoing<br>
connections, you&#39;d need to periodically use a set-reconciliation protoc=
ol to<br>
download the differences between each of your outgoing peers&#39; double-bl=
ocks,<br>
and attempt to add any newly discovered transactions to your mempool. At wo=
rst<br>
for 8 peers this would be 64MB of useless data to download, assuming every<=
br>
single transaction was a conflicting double-spend. Not great. But not that =
bad.<br>
<br>
As with the average fees idea, periodically you would drop the peer adverti=
sing<br>
the lowest double-block of fees, and then connect to a new peer to see if<b=
r>
they&#39;re better.<br>
<br>
Now consider what happens if you are sybil attacked. Due to RBF, with<br>
synchronous mempools across different nodes with the same standardness poli=
cies<br>
will have very similar transaction sets; even without active synchronizatio=
n<br>
long-running mempools across different nodes are already very similar in te=
rms<br>
of total fees. Thus even a small difference in transaction relay policy wil=
l<br>
show up as missing transactions. This difference will translate into the sy=
bil<br>
attacking node(s) getting dropped, and honest nodes with policy compatible =
with<br>
yours eventually being found.<br>
<br>
<br>
## Peers With More Liberal Relay Policy<br>
<br>
If you apply set reconciliation to a peer with a *more* liberal relay polic=
y<br>
than you, they&#39;ll have transactions that you will not accept. For examp=
le,<br>
imagine the case of a peer that now accepts a new version number.<br>
<br>
One way to deal with this could be to just drop peers that give you<br>
transactions that you consider non-standard. So long as reconciliation is o=
nly<br>
applied to a subset of all transaction relaying peers, this is fine. Indeed=
,<br>
even if this is applied to all transaction relaying peers, Bitcoin Core alr=
eady<br>
connects to additional peers in blocks-only mode. So you&#39;ll still get s=
end and<br>
receive blocks and maintain consensus.<br>
<br>
<br>
## Privacy<br>
<br>
Tracking what transactions are in mempools is a potential way for attackers=
 to<br>
trace transactions back to their origin. Provided that set-reconciliation i=
s<br>
only a secondary transaction relay mechanism, with sufficient time delays, =
this<br>
should not impact privacy as under normal operation transactions will have<=
br>
already propagated widely making the set reconciliation data non-sensitive.=
<br>
<br>
<br>
# Manual Peering With Known-Honest Friendly Nodes<br>
<br>
More of a social solution than a technical solution, we should encourage pe=
ople<br>
to manually peer with other nodes they have a personal relationship with.=
=C2=A0 This<br>
is a powerful technique against sybil attacks for the simple reason that<br=
>
person-to-person relationships can evaluate honesty in much more powerful w=
ays<br>
than any code could possibly do so.<br>
<br>
At the moment, actually doing this is inconvenient. Ideally we would have a=
<br>
mechanism where node operators could get a simple pubkey@address connection=
<br>
string from their node to tell to their friends, and equally, import that s=
ame<br>
connection string into their bitcoin.conf. This mechanism should use some k=
ind<br>
of node identity to defeat MITM attacks, and also ensure that connection li=
mits<br>
are bypassed for friendly nodes. The existing addnode mechanism doesn&#39;t=
 quite<br>
achieve this. Notably, without a node identity mechanism, there&#39;s no wa=
y for<br>
someone with a static IP address to whitelist a friend&#39;s node with a no=
n-static<br>
IP address.<br>
<br>
<br>
# Footnotes<br>
<br>
1) Chris Guida&#39;s &quot;garbageman&quot; branch: <a href=3D"https://gith=
ub.com/chrisguida/bitcoin/tree/garbageman" rel=3D"noreferrer" target=3D"_bl=
ank">https://github.com/chrisguida/bitcoin/tree/garbageman</a>,<br>
=C2=A0 =C2=A0first presented at the btc++ mempool edition (2025) hackathon<=
br>
2) <a href=3D"https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828=
a5f0de58d8f2706848c48fd2?s=3D09" rel=3D"noreferrer" target=3D"_blank">https=
://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f2706848c=
48fd2?s=3D09</a><br>
3) <a href=3D"https://petertodd.org/2016/block-publication-incentives-for-m=
iners" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2016/bloc=
k-publication-incentives-for-miners</a><br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/aDWfDI03I-Rakopb%40petertodd.org" rel=3D"noreferrer" target=3D"_=
blank">https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40pete=
rtodd.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.g=
mail.com</a>.<br />

--00000000000059cccb06361c7efe--