From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 03 Jun 2025 01:00:52 -0700 Received: from mail-yb1-f191.google.com ([209.85.219.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uMMZm-0008Fi-Fs for bitcoindev@gnusha.org; Tue, 03 Jun 2025 01:00:51 -0700 Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e7dbb4aa3besf7436230276.1 for ; Tue, 03 Jun 2025 01:00:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1748937644; cv=pass; d=google.com; s=arc-20240605; b=NI9Y9+HIW95dgC7EmL3Ai2w70uwOUGEENcMEdC7eCcVMCF21TNiKGmi7q4Z+8rfqjO b8Db0g0oaCqICe655daRFjnPdH+Fl+8W4NKs2vptLSmseH9Qv5Yb5d5TqagG/gycgXsO gA+Ze6k4yRuedZDpn/Wh1DmT8Q//umufnYtyGgbY56l3ea8BGR1Yl6D90bPkq/Itz2hL lJrBRVpocZPPo9AaBOQdJVG0sg56FrOFV59ecrEK/TYTygtnCY//RyM2ckqz4Pjz16MA baoV03Fg1BCBm4Dzu0MMiE+MaiKVYC9ec9kOmjWC5dW5jnclRhYKy1DSe9EyG+YHy9iG RyaQ== 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:message-id:in-reply-to:to :references:date:subject:mime-version:from:feedback-id:sender :dkim-signature; bh=/2lAtF1DXrp/21evIc5NhS4vgSPnFrpxTJbk89ZvmaY=; fh=mzWnpRfk5VJJcsi9WfKYuMVsvtEWsdiku1ft7ZnqHxc=; b=ZrLqZ5rDvqlnkIlf6m9N4IuanFZIvmsV5jfGSyhnwsBVn03joff1HchHKJMkuz0mfF cLdXwaC3FAFxZuNiHMOmgViTwEvzDnMEGKBz7md7Ygv1ZyfibHFOlYiWSUFaeGO8ttwh KIRcmbbNM9A8mUIHhaWkuxnWFjD+o5rfdFSbgElQi+2UkSSuAo6YGW2Yzu8GOpxkD8Ej 1rkFQRKTL5qqQXEKT8FrsOiD62feZ8PSvN1bnffUk7eUoO5VGu0xz56wi82nUwrPw8jY 4ulWcvG4ZUCbj3dfnE2egwg4Odhda+wBZW8UtwGMIoqU6w2JM3gz23sVfcenoMIP33Mn 1uVw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=LonxE7KR; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=SWV0MeVM; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.154 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1748937644; x=1749542444; 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:message-id:in-reply-to:to:references:date:subject :mime-version:from:feedback-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=/2lAtF1DXrp/21evIc5NhS4vgSPnFrpxTJbk89ZvmaY=; b=cmXvZP1CZHFnpW71Acut1f2AFsi0f6oabbHggA+lt4V/dc8T3Ftk/LvSGZHIBdRLlj oKyoz5JXdw2nkQ/sSS7r+I+ptIEWaUJiHXEx2GVGoOkz0QXB8E+D3jGiUIBnx/d2Ryfy jZkDWxAIvZdj2rFe1pa6J4uaRA+uDTPJQYQERd9hsTFNcHiWuMoZcc8P2mmL1vBCf5Hw BM34txiAJGYBrzg5Cy0JokHLtgtf9mfWcr8ut2PB6GAEWwz83dEYkMo7wtrO2CPwbhCo kHOEvLUkFiVnj3W0nW60MJQBObdrREe/oUVz9UZ3DeWCHBZBuVy3/DmJPX7QNwbBSkRw h7bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748937644; x=1749542444; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:message-id:in-reply-to:to:references:date:subject :mime-version:from:feedback-id:x-beenthere:x-gm-message-state:sender :from:to:cc:subject:date:message-id:reply-to; bh=/2lAtF1DXrp/21evIc5NhS4vgSPnFrpxTJbk89ZvmaY=; b=JqMY41X1ftHDo88Y5sjXgtiGUPR9Zen/MkKGKte0EEZzEtVwVZ2wBGuKulurH+Humc rTnqiVZpXcWZYWtkcpUTttV8EYvUjIYYF61SyIQ16LfaOTsqOk//Witb7mHzMpEUHrid Yc/3Nt7Gv0lF9sW60QIJzKrlRWPwzuUY2TErCFlMaSPwCnIsNCuPBaX/I2gXBUwfF0GI PLABJDWSfLBnxEXh0AKkPK9eNA7+CTmX3wVjlzGFacbG77EVm3vlpHa8Cxd58qr4yhoi Wlw14jdjJryiX79bU8HezRB31swnvruHwBZ8gI2QyBVBlZoIptlyZBbULC9D05Gk11k7 3BYw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW7dMND3UEwi86dDwgwEe8Vf3GZamIkc86XUPLaojZblVOTGRGNALtviggZ0ZKMvkHqJnWNQQCfojYF@gnusha.org X-Gm-Message-State: AOJu0YykBI7/yphqlKJP8N22gqjA3sghJP3s1Z/GJz9OcgIhZYZnMkCu r5Ou3DNMiSaoHJgB4VbRbmNsi41ZyZeE7B0koLqBkqYONgbrr18Sd7Cr X-Google-Smtp-Source: AGHT+IHSBSOMHEPzO3hOOpw6OIadzpLKMuyvXABeqSj9q10+Yiix7EseD37CK9aC5OfofO3iR6Qzgw== X-Received: by 2002:a05:6902:6c10:b0:e7d:605d:da20 with SMTP id 3f1490d57ef6-e7f81f4e6eamr18651363276.48.1748937644130; Tue, 03 Jun 2025 01:00:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcJ9jWIq9tJIOMIUFKcxHrQmu0sqMGHhkjsE+GL1G3hOQ== Received: by 2002:a25:b115:0:b0:e7e:17d7:a664 with SMTP id 3f1490d57ef6-e7f6f7f5da3ls5429118276.2.-pod-prod-02-us; Tue, 03 Jun 2025 01:00:38 -0700 (PDT) X-Received: by 2002:a05:690c:fd4:b0:70d:ee83:3733 with SMTP id 00721157ae682-70f97c16c3amr248390497b3.0.1748937638717; Tue, 03 Jun 2025 01:00:38 -0700 (PDT) Received: by 2002:a05:690c:4682:b0:70e:3f3a:2c12 with SMTP id 00721157ae682-70f9801c234ms7b3; Mon, 2 Jun 2025 23:50:48 -0700 (PDT) X-Received: by 2002:a05:6902:1022:b0:e81:30a0:b08a with SMTP id 3f1490d57ef6-e8130a0b730mr12797725276.26.1748933447632; Mon, 02 Jun 2025 23:50:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1748933447; cv=none; d=google.com; s=arc-20240605; b=B/NedvoogKRKQWZEUzPf78q1uXGTDUNzDxOOXvtJlyYkICl3Xpc0G1woZys9i1PO36 tWdx9uU4btprlYV+Uw6HHryr6Cc+CnmryV1XQ+YvCPXRWzKUbjMnG8yORXvrkoaudVVP u4tSszAvkwpUhGzAbDX9ggKl/BYrAItqnOcv5RsoI7Y1za+rEY7vzt4/JROe+qnLj9Zd ObaBTtWFix4tfbaOFEmeMLpBcXMFPNEDw0dwM6Kloc/yq3M6K/mGy7bkOEcX7DOXonrS ncRrTnXl0ZmQzKm4ut4CZBQBOtenWY4tbLMYb/9+aMkTH2A+Ll/VV9PeLvgW+dW4e8L+ eRJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :feedback-id:dkim-signature:dkim-signature; bh=t6R44uWHvVUCbAHGqvS94gZt3WYIR+xoZRdPtH+djg4=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=VlfFdVWk8cS5+nuCspMnRHKz6EBnzQtiBc6YqZVTs2S/XWFKfFut/16p7on9onP5oN Mh+5CQjKpodNivpYYCFwQkCSdDrQ9rCJlVkK1BCJayzXRm1WNnqH2pVlYRsI05GUgTTe efA34GHCdXa5DvmJa4795NzDJixQPbUqhd9ZsBMEGtNCAG02IvZN+C/MI9vGusiaAe4F 3FxGyd9bXSP4oNmgeiVZ4xm+P3Gw0e58visFDupTDe8xR2jY81Lahuw9lSvgc9BanYLS zZDJoo5yG89KHaE+pcZUpyGp7TSxSqZSWBArVHLqP/4bqShZ+KBebQ1QGJEVHka6Xufg A8TA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=LonxE7KR; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=SWV0MeVM; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.154 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl Received: from fhigh-a3-smtp.messagingengine.com (fhigh-a3-smtp.messagingengine.com. [103.168.172.154]) by gmr-mx.google.com with ESMTPS id 3f1490d57ef6-e7f734eabb1si548090276.4.2025.06.02.23.50.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 23:50:47 -0700 (PDT) Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.154 as permitted sender) client-ip=103.168.172.154; Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id C39E61140188 for ; Tue, 3 Jun 2025 02:50:46 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Tue, 03 Jun 2025 02:50:46 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefleekjeculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecufghrlhcuvffnffculddujedmnecujfgurhephfgtggfuffhfvfgjkffosegrtdhm rehhtddvnecuhfhrohhmpefujhhorhhsucfrrhhovhhoohhsthcuoehsjhhorhhssehsph hrohhvohhoshhtrdhnlheqnecuggftrfgrthhtvghrnhepffefuefgkefhffekheejiedv udeugeduteevjedvtdeiieeugeeutefgfeeijefhnecuffhomhgrihhnpehotggvrghnrd ighiiipdhgnhhushhhrgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehsjhhorhhssehsphhrohhvohhoshhtrdhnlhdpnhgspghrtg hpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsghithgtohhinhgu vghvsehgohhoghhlvghgrhhouhhpshdrtghomh X-ME-Proxy: Feedback-ID: ie5e042df:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 3 Jun 2025 02:50:46 -0400 (EDT) From: Sjors Provoost Content-Type: multipart/alternative; boundary="Apple-Mail=_19A902FD-8AEF-489A-BE86-D268D023AC7E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man) Date: Tue, 3 Jun 2025 08:50:34 +0200 References: To: bitcoindev@googlegroups.com In-Reply-To: Message-Id: <4BA2B86E-3E4B-416B-9237-AFD66FC4E37A@sprovoost.nl> X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Original-Sender: sjors@sprovoost.nl X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=LonxE7KR; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=SWV0MeVM; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.154 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl 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.7 (/) --Apple-Mail=_19A902FD-8AEF-489A-BE86-D268D023AC7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > Op 3 jun 2025, om 04:52 heeft Chris Guida het volg= ende geschreven: > Also, please let me know if this list is not the proper venue for this di= scussion. It gets kind of philosophical. More importantly it doesn't contain any numerical analysis as to its effect= iveness. > Spam filtration, conversely, is a rate-limiting of transactions based on = objective criteria, Presence on the OFAC list is an objective criterion. Your distinction betwe= en "objective" and "subjective" seems rather arbitrary. In any case it's no= t relevant for the purpose of censorship resistance. The reality is that there are different groups using Bitcoin and they have = different opinions on which transactions it should include. Governments are one such group and they could decide tomorrow to spin up a = bigger version Garbageman and disrupt the entire mempool. If they perceive = it as an attack on their interest. As a result everyone has to submit trans= actions directly to a handful of, often US based, pools. If we're going down the route of openly innovating attacks against the memp= ool, we should also continue innovating countermeasures, as Peter Todd did. > Garbageman restores the balance. This is extremely vague and avoids the question of effectiveness. What percentage of attempted "spam" transactions are prevented from enterin= g a block? What's the average delay in seconds? You speak of "rate limiting", but delaying propagation doesn't rate limit a= nything. Unless you completely block some percentage of transactions, the s= ame amount of spam ends up in blocks, just a little bit later. The rate, e.= g. gigabytes per months, stays the same. Peter's original email also doesn't answer this: presumably because he's tr= ying to be generous: > 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.=20 "succeed" here just means the transaction doesn't reach a miner in the init= ial broadcast attempt. =20 If the "spammers" use extremely naive software, perhaps they never try agai= n and the sybil attack was successful. But this assumes an adversary who do= esn't adapt, which is not a reasonable assumption. Anyone would understand from their own experience if that if a transaction = doesn't go through, you try again. You don't just accept that you've been r= ate limited. The simplest next move would be for their software to just connect to more = Libre relay peers and broadcast the transaction again. Or people can just spin up more Libre Relay nodes. Both miners and issuers = of various scam tokens have a monetary incentive to do that. Whereas propon= ents of filters are (so far) not willing to invest serious money. E.g. when= I challenged Luke Dashjr in an earlier post to reorg a single block with s= pam, he didn't respond [1]. Worse, Ocean proactively offers "Core" [0] temp= lates. Although running a node is cheap, if this becomes an arms race, the = side that actually spends money has the advantage. But let's say, after all this you find a way to make Garbageman effective, = that it actually causes and sustains an economically meaningful delay betwe= en when a transaction is submitted to Libre Relay network and when its incl= uded in a block. Then all you've achieved is an incentive to submit directl= y to miners, making those miners more profitable. Congrats, you didn't fix = spam, you didn't rate limit anything and you made mining more centralised. - Sjors [0] https://ocean.xyz/docs/templateselection [1] https://gnusha.org/pi/bitcoindev/f348e4bf-ccc4-48e3-9745-ac72b1b131f5@a= pp.fastmail.com/ --=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/= 4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl. --Apple-Mail=_19A902FD-8AEF-489A-BE86-D268D023AC7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"
Op 3 jun 2025, om 04:52 heeft Chris Guida <chrisguida@gmail.co= m> het volgende geschreven:

Also, please let me know if this list is not the proper venu= e for this discussion. It gets kind of philosophical.

=
More importantly it doesn't contain any numerical analysis as to its = effectiveness.

Spam filt= ration, conversely, is a rate-limiting of transactions based on objective c= riteria,

Presence on the OFAC list is an objecti= ve criterion. Your distinction between "objective" and "subjective" seems r= ather arbitrary. In any case it's not relevant for the purpose of censorshi= p resistance.

The reality is that there are differ= ent groups using Bitcoin and they have different opinions on which transact= ions it should include.

Governments are one such g= roup and they could decide tomorrow to spin up a bigger version Garbageman = and disrupt the entire mempool. If they perceive it as an attack on their i= nterest. As a result everyone has to submit transactions directly to a hand= ful of, often US based, pools.

If we're going down= the route of openly innovating attacks against the mempool, we should also= continue innovating countermeasures, as Peter Todd did.

Garbageman restores the balance.

This is extremely vague and avoids = the question of effectiveness.

What percentage of attempted "= spam" transactions are prevented from entering a block? What's the average = delay in seconds?

You speak of "rate limiting", bu= t delaying propagation doesn't rate limit anything. Unless you completely b= lock some percentage of transactions, the same amount of spam ends up in bl= ocks, just a little bit later. The rate, e.g. gigabytes per months, stays t= he same.

Peter's original email also doesn't answe= r this: presumably because he's trying to be generous:

=
For a sybil attack to succeed aga= inst 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. 

"suc= ceed" here just means the transaction doesn't reach a miner in the initial = broadcast attempt.
 
If the "spammers" use extreme= ly naive software, perhaps they never try again and the sybil attack was su= ccessful. But this assumes an adversary who doesn't adapt, which is not a r= easonable assumption.

Anyone would understand from= their own experience if that if a transaction doesn't go through, you try = again. You don't just accept that you've been rate limited.

<= /div>
The simplest next move would be for their software to just connec= t to more Libre relay peers and broadcast the transaction again.
=
Or people can just spin up more Libre Relay nodes. Both mine= rs and issuers of various scam tokens have a monetary incentive to do that.= Whereas proponents of filters are (so far) not willing to invest serious m= oney. E.g. when I challenged Luke Dashjr in an earlier post to reorg a sing= le block with spam, he didn't respond [1]. Worse, Ocean proactively offers = "Core" [0] templates. Although running a node is cheap, if this becomes an = arms race, the side that actually spends money has the advantage.

But let's say, after all this you find a way to make Garbag= eman effective, that it actually causes and sustains an economically meanin= gful delay between when a transaction is submitted to Libre Relay network a= nd when its included in a block. Then all you've achieved is an incentive t= o submit directly to miners, making those miners more profitable. Congrats,= you didn't fix spam, you didn't rate limit anything and you made mining mo= re centralised.

- Sjors


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl.
--Apple-Mail=_19A902FD-8AEF-489A-BE86-D268D023AC7E--