From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 09 Jun 2025 03:54:53 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uOa9U-0005Qt-JL for bitcoindev@gnusha.org; Mon, 09 Jun 2025 03:54:53 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6045ff1afc6sf1503172eaf.0 for ; Mon, 09 Jun 2025 03:54:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749466487; cv=pass; d=google.com; s=arc-20240605; b=Sh+a3bhpmjYn0VTmy4zsxTtUsnnV84gApLUiAy/icIgU8FPr8W8AA1s34OcBn6nlwv zJE47b3UrkBhSBHdZY34xsmfEu45TTp28yNj4It+JfElH+y3ZojwKuHtUgIE1YAsexvs QbtcmFQF0/hT9vMB75hstXCF25ubYqXHFn/+J0yHx5zgDsTDpNQUhBruIAzlkG6fms3r KH+hIbsIuD0SCFzOVQPx3cd1AxTrudan5JEFC66s7ZZ7lJmC0RxmqGYobWsX7qB5DOii cv9jsi6OqMZctlAkdcrhtGcFRP1YwLbA4apq0MQg1E7+7lf2V+YcP3ZZwieFKbV2fvhb u+eg== 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:references:to:cc:in-reply-to:date :subject:mime-version:message-id:from:feedback-id:sender :dkim-signature; bh=F79rkm5IyxxJqEW62tn0y/7fDdCtVFG2oH92zgKDOLg=; fh=EEb3hwourqa6s8zytM6XFOLbPBlVbL3ymfjs/Gzhafs=; b=E8F+7aJerxj6H83J+U9AlyN7/4AtUWKrS06zAL7d3ief77qpbfdHpNZ+ho4BMI++u5 DzuWw1Ip0stIKz87gVlx/7ZwuHvrp67JlJo+JiHiGxt/q4OFzk65ipM+SUfq7ftq8E6/ cW3SQ8/bT6QezFJxQdk3/q2YM7C9MMT9ZEOJxJ4LXGaQoujVOibIeIIpA9zb8uqhLKuU 1xe1vhKXVDB/p4LXUpCIoxip4KcsCg91FljOlIWWuy2cfYt60ichNmrl5Wvu8LpPou1l n3qdme+WN/acGGsN3nYF0FpaqdAohGveTVHKJShGCBIXZH6ZTbuUXYyMJnCdEHvaJz6N L9PQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=teAOvr0e; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=ik2h6XTR; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.156 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=1749466487; x=1750071287; 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:references:to:cc:in-reply-to:date:subject :mime-version:message-id:from:feedback-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=F79rkm5IyxxJqEW62tn0y/7fDdCtVFG2oH92zgKDOLg=; b=apygtxnXUmOfXhvrDDriX21oAQs/X1EjNRECQNSg30cWFhGmtlBtibbqlCQ9fUUhJh nXdxYJgAvxtoCEJi+qSkST+mfsTz4eaXyDN66LWi74z/eJqNDJTl/YxOVoHqa/LLsOyk mX0gCiZLWNTX7cvWCz/S5gQlbsd+k/Z03CedGPbsVEFonzfVChMBnV69Tlza1IHKQ5Aw j+di+PQcwZpUVfe1ySksoOV/E9iatr4cNFb2CYFFqs6d8GFd0jaVfI15m0+BmSzwpCgq 0OqIkNOUEuefW3g/FSn5qu7PqMTg3CtlhJfzn26tXP47uVeDR10saPvsN+oH8ErSCNTP nCeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749466487; x=1750071287; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:references:to:cc:in-reply-to:date:subject :mime-version:message-id:from:feedback-id:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=F79rkm5IyxxJqEW62tn0y/7fDdCtVFG2oH92zgKDOLg=; b=sWhNe8adjUVze592u5CdhMghhLNzD63VrEY0M/4SBLv6U86IfLNjdBkF+UhtLWY3Vp WN7R50gnXxynK8SZg0n+0Li4csAEDAwB6JSRCanEmV1SevZW86mREV7ueGT23jw/RJj+ KCAsvZ1cZlDg261ThYh/4DleWV0w1Ain+9X0Arrc79KF7sfEPaKgWwicQJLsWIAoTPA5 75uFa/f8XEadovMBzwFpdjqg8IKSy8FpAPHHApmDE5gMUSCnJ0w2ABnuZMZ/z8q9jjaM Z6ULEPPDq/a88K1g9n5w7lgHkgE92ZoTn/HWXOwkrhhRY8iyyQTPXKlU2fgTHAdo1Yc9 Kolw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUvMVBYv/d/uLnNPIe+ofPCM5Ox+pHEXylCyCy3yyHLOQJPJdO10wms0oJCygz20AkSEZWAYlQLRPkM@gnusha.org X-Gm-Message-State: AOJu0YxFQ+W9CUgLYVrH0r1PM+BwbNhdyRnIvgd49uzLNtigkgNdiW+k sDSvcz3sDjDhwt8edHGLoN0biLhwNslpKU6oiNwppXJ1RxKHv81sq3Ob X-Google-Smtp-Source: AGHT+IGMwko449/PALAdm3MYBWe1QFTUDejL4BUYuwwdfeW9e5961gzcgam+0XesPkOPMSIdeNfBLA== X-Received: by 2002:a05:6820:190f:b0:610:c3bf:ee3f with SMTP id 006d021491bc7-610c3c05130mr3803789eaf.7.1749466486723; Mon, 09 Jun 2025 03:54:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcm/4tBdS39IY7ZCAtNkeQ+AmjzZ3TpOaQatK7Oz3CUrA== Received: by 2002:a4a:a507:0:b0:60f:195e:84fc with SMTP id 006d021491bc7-60f28336becls334108eaf.0.-pod-prod-04-us; Mon, 09 Jun 2025 03:54:43 -0700 (PDT) X-Received: by 2002:a05:6808:1524:b0:3f6:a476:f7d3 with SMTP id 5614622812f47-409051d5343mr8770439b6e.9.1749466483610; Mon, 09 Jun 2025 03:54:43 -0700 (PDT) Received: by 2002:a05:6808:6482:b0:403:484c:9068 with SMTP id 5614622812f47-408f0257a78msb6e; Thu, 5 Jun 2025 06:29:32 -0700 (PDT) X-Received: by 2002:a05:6830:290a:b0:72b:a196:5221 with SMTP id 46e09a7af769-73869d6a0ebmr5893245a34.8.1749130171459; Thu, 05 Jun 2025 06:29:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749130171; cv=none; d=google.com; s=arc-20240605; b=A1gXzno97GPl5BOHG96qOQQOXYACz4H6DgdKjJppjd5LoXQtE43qkBztXELT+tMNmq k0rWcpnGFmSmJk1OZrYfO10fGEQetSO15vn5yu+/xSI8T4rR8xVtpop8P19O1SUaibcx zCEpHYyuXHvWXXfuwo8JBfX990SOtbNmfeeQrtNSrpEjdHZqmhHIvdtVu7pLyGBsFQD0 oDtsgYgh3k5oKQf2rG0lntOKXB+92DFdAAtuTnDbUweb+Zyui6Q+qTXx2JVrMLbi0Dm2 leSZ73HgTjIkCSDTk3apauLMTC0r0XVd3hKmxpgvWd6XcrxjevrNTGcPxNcZ/FlAM1do GR7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:feedback-id:dkim-signature:dkim-signature; bh=myNYk/Zh7Q1aIgM4wO1yAYmEYwqHKqSfdAGnK4nDmSE=; fh=5bKkyrGFQOxP/asIFkTXgRaOLsmJw/WymtuzDWrpHEQ=; b=ew1YODcLdZcd5orYbS1oqUBKP4UJJQkFh7VdsYwWyAOSQUw+QBa+MY+GBJarLD/e2J ih+FeBz/EJNPHrmzxLi3Eol0oOxP5fQUfwzj2bcY88LOtIQ8KXd/pyh3lSeD+upL5F0P ctKJd6is+0ufDAX+olH8E44bXVYZXsdLvRHHMLD3GyPJ3ZI/rF6oGZpgiDqxkJ4R9rrw sKC4+GDDJuOPfRdh59Pr1XCibeIPQkmwDY3yfk2AnFQcw9qCRo8yGJqY2XPQ0TY1ttS5 Q4zGQ4YXYHHl1QZ3N5hH2vkYv83QT6DTYyQoJ9/uhwZNwyyZ8hcD0fXIFIx4E0+9Cdb/ sskg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=teAOvr0e; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=ik2h6XTR; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.156 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com. [103.168.172.156]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-735af9a48d6si784619a34.3.2025.06.05.06.29.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jun 2025 06:29:30 -0700 (PDT) Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.156 as permitted sender) client-ip=103.168.172.156; Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfhigh.phl.internal (Postfix) with ESMTP id 751611140143; Thu, 5 Jun 2025 09:29:30 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Thu, 05 Jun 2025 09:29:30 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdefieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdtvden ucfhrhhomhepufhjohhrshcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhooh hsthdrnhhlqeenucggtffrrghtthgvrhhnpedvieehheekteefgeehudehieffueetudef heevfeehfedtffffheduheefgfduieenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehsjhhorhhssehsphhrohhvohhoshhtrdhnlhdpnhgspghr tghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheptghhrhhishhguh hiuggrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepsghithgtohhinhguvghvsehgohho ghhlvghgrhhouhhpshdrtghomh X-ME-Proxy: Feedback-ID: ie5e042df:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Jun 2025 09:29:29 -0400 (EDT) From: Sjors Provoost Message-Id: <05CE1FD4-3BE1-4F80-829F-684E20BA73D4@sprovoost.nl> Content-Type: multipart/alternative; boundary="Apple-Mail=_57A5119D-9ED5-41B3-86C0-356D5742439F" 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: Thu, 5 Jun 2025 15:29:17 +0200 In-Reply-To: Cc: bitcoindev@googlegroups.com To: Chris Guida References: <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=teAOvr0e; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=ik2h6XTR; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.156 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=_57A5119D-9ED5-41B3-86C0-356D5742439F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Chris, I'm replying to a few points that matter imo. > Again, as I tried to emphasize in my prior message, the goal is not to ce= nsor; the goal is to rate-limit spam. . The tooling you're building is dual-use at best, and from a miner point of = view it's censorship. >> Then all you've achieved is an incentive to submit directly to miners, m= aking those miners more profitable. Congrats, you didn't fix spam, you didn= 't rate limit anything and you made mining more centralised. >=20 >=20 > Again, if miners are doing this, then they are hostile. If >50% of miners= are hostile, then we need to know right now because Nakamoto Consensus fal= ls apart if >50% of the hashrate is dishonest. Miners are simply following their incentives. It's merely your opinion that= this is "hostile". The people who share your opinion have not presented a = credible way of enforcing it. All they've achieved is collateral damage. > Is your concern that the USG would spin up a bunch of GM nodes that don't= relay transactions from OFAC addresses?=20 No, they would take down the entire mempool by spinning up a million well c= onnected fake nodes that behave in the same way your project does, except t= hey drop *all* transactions. Since there's no financial incentive for users= to run nodes, it'll be hard to counter this attack by merely spinning up m= ore nodes. > >You speak of "rate limiting", but delaying propagation doesn't rate limi= t anything. Unless you completely block some percentage of transactions, th= e same amount of spam ends up in blocks, just a little bit later. The rate,= e.g. gigabytes per months, stays the same. >=20 > Again, this is simply incorrect. Spam does not have inelastic demand. > [...] > If a certain percentage of the hashrate is confirming spam, let's say 20%= , No, 100% will be confirming spam and nothing happens to the fee rate. Elast= icity isn't an issue here. Where does your 20% figure come from? Is that based on your assumption they= are not "hostile" and would just go along with not receiving the extra rev= enue if your sybil nodes block it?=20 But why would 80% of miners throw away fee revenue? They won't, so both tra= nsaction makers and miners will go around your "rate limiting". The thing that is concerning here is that they'll use centralised transacti= on submission services for this, and any miner that doesn't join such servi= ce loses revenue and goes out of business. > >Whereas proponents of filters are (so far) not willing to invest serious= money. >=20 > I wouldn't be so sure about that. You're not providing any evidence to the contrary. And again, Ocean Pool proactively added the "Core" template after they got = pushback from customers for only offering Knots with filtering. After v30 t= hat template will allow unlimited OP_RETURN. Perhaps they'll drop it then, = but so far they haven't put a cent of revenue at risk. > >Or people can just spin up more Libre Relay nodes. >=20 > Who are these people? Altcoiners?? Yeah, right. Anyway, we can just spin = up more GM nodes. This comes back to question of budget. Miners and scammers have budget for = relay infrastructure. You can of course try to outspend them, with your own= money or a rich donor. If you sustain that effort long enough, it may be c= heaper for them to use centralised submission services. Which as others hav= e pointed out is very bad. - Sjors --=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/= 05CE1FD4-3BE1-4F80-829F-684E20BA73D4%40sprovoost.nl. --Apple-Mail=_57A5119D-9ED5-41B3-86C0-356D5742439F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi Chris,

I= 'm replying to a few points that matter imo.

Again, as I tried to emphasize in my prior message, th= e goal is not to censor; the goal is to rate-limit spam= .
.
The tooling you're building is dua= l-use at best, and from a miner point of view it's censorship.
Then all you've achieved is an incentive to 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 more centralised.

Again, if miners are doing this, then they= are hostile. If >50% of miners are hostile, then we need to know <= i>right now because Nakamoto Consensus falls apart if >50% of t= he hashrate is dishonest.

Miners are= simply following their incentives. It's merely your opinion that this is "= hostile". The people who share your opinion have not presented a credible w= ay of enforcing it. All they've achieved is collateral damage.
Is your concern tha= t the USG would spin up a bunch of GM nodes that don't relay transactions f= rom OFAC addresses? 

No, they would t= ake down the entire mempool by spinning up a million well connected fake no= des that behave in the same way your project does, except they drop *all* t= ransactions. Since there's no financial incentive for users to run nodes, i= t'll be hard to counter this attack by merely spinning up more nodes.
=

>You= speak of "rate limiting", but delaying propagation doesn't rate limit anyt= hing. Unless you completely block some percentage of transactions, the same= amount of spam ends up in blocks, just a little bit later. The rate, e.g. = gigabytes per months, stays the same.

Again, this = is simply incorrect. Spam does not have inelastic demand.
[...]
If a certain percentage of the hashrate is confirming spam, let's = say 20%,

No, 100% will be= confirming spam and nothing happens to the fee rate. Elasticity isn't an i= ssue here.

Where does your 20% figure come from? I= s that based on your assumption they are not "hostile" and would just go al= ong with not receiving the extra revenue if your sybil nodes block it? = ;

But why would 80% of miners throw away fee reven= ue? They won't, so both transaction makers and miners will go around your "= rate limiting".

The thing that is concerning here = is that they'll use centralised transaction submission services for this, a= nd any miner that doesn't join such service loses revenue and goes out of b= usiness.

>Whereas proponents of filters are (so far) not willing to invest= serious money.

I wouldn't be so sure about that.<= /div>

You're not providing any evidence to= the contrary.

And again, Ocean Pool proactively a= dded the "Core" template after they got pushback from customers for only of= fering Knots with filtering. After v30 that template will allow unlimited O= P_RETURN. Perhaps they'll drop it then, but so far they haven't put a cent = of revenue at risk.

>Or people can just spin up more Libre Relay nodes.

Who are these people? Altcoiners?? Yeah, right. Anyw= ay, we can just spin up more GM nodes.

This comes back to question of budget. Miners and scammers have budget f= or relay infrastructure. You can of course try to outspend them, with your = own money or a rich donor. If you sustain that effort long enough, it may b= e cheaper for them to use centralised submission services. Which as others = have pointed out is very bad.

- 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/= 05CE1FD4-3BE1-4F80-829F-684E20BA73D4%40sprovoost.nl.
--Apple-Mail=_57A5119D-9ED5-41B3-86C0-356D5742439F--