From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 03 Jun 2025 14:08:50 -0700 Received: from mail-qt1-f183.google.com ([209.85.160.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uMYsK-0000kl-V4 for bitcoindev@gnusha.org; Tue, 03 Jun 2025 14:08:50 -0700 Received: by mail-qt1-f183.google.com with SMTP id d75a77b69052e-49a4f4021ccsf9098591cf.1 for ; Tue, 03 Jun 2025 14:08:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1748984923; cv=pass; d=google.com; s=arc-20240605; b=VGZAmzRn8l459bc2ZUWLPyEcN1sqoBC8JhdncOIS/yfg0Zl/Vqj1xVmcSXvz0EbGqA gTEPVO1MFdY/DWpTkJzfOj6eKv4mGotsBp7qGeTdAL2mo1WU+ds8Kv0vU4wRVI5TOuYT UsOYlPkueST/PtaTmaPM/wgFpnOLrV2qtzqjLWLes0o8iM5Ahh+2Qktj1xGvPfnv064p engoohCt/3xXB7do2U9E08iwnfYG/r6ocJ49bXHx6Q1YfhP0nN8OuRenShqVZlepp+7J E5wQBVBd4uqPB3XOaWZZ4L/Z871TgqYRiFNkDa35AxyKK2TyEDSwMx4bFctG1ECfeleO TJ4A== 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=yX0Hth2742GU58OPzJVBIs2mHvAHyLDLMHHYHljTQJE=; fh=xO/TjuZ8KWxN02UmEJOZE/DomEgPWaPOFxWfNYn7oFU=; b=WYs9o1UEliAXOoqqlgiTD1OOd6wNRGpqSu9GnfgQ5H7GPQTvQrDzK+UrSxF/7Lw+BI z0KcZPgDFLUechh8knaqsGWDrJ8kY1fTXQbArCe3e74JNtQneUWa9IbDppL7RBxp+WdK SPr0q6Bb0yUztwLi0hgfxNlQve+IIo5cbL/lQvCyTIlCplRcMmau/Mq3bJhx9ZHk1Ej+ F61fLKpmTnWtBoZUhKXVDJ/5nUzaI6I6QdlG3d06lfZLDTSeP/lWDq617eB2BCVcDfzT fVaBKuWhrD5nywkjFFdKm1RhuWlzRuPT9TLM/F+8kPyuWLZiESemUdB/o04TkQtBCEMH tRlw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=Rnmz+gpM; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=Qv5QW+Qy; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.157 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=1748984923; x=1749589723; 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=yX0Hth2742GU58OPzJVBIs2mHvAHyLDLMHHYHljTQJE=; b=RvUX7UI//enfaMbfsIcmQUfhB7EnH/tqRs64qrvgTbjt/GC5LYQvjHcIe6greICzli N6aD9domst+0dhiSdiIBNGSEa47cOX8t9GxE3lkX6oqPURSJIn4dlZUyhlR714CKVL/g OkNHrH1OkI4UMZhI6lQ/yuUouslayznhwlxbsyBmM/bMrKGpx4IXTZR06vKdH3C9+HLe h+rRq9tItCVnLCK5aILcwhSFr9ssQKxk+gH/JM5l0NFGP8+nNVdIYdgEc6MEd/sYKy/i DhslZitCCsqwSJUGY8h9cDXsbLEi6oSr6Gba2ymoxbn3FVlu5XvAEXDOHeaa6kIDkWIk wJGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748984923; x=1749589723; 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=yX0Hth2742GU58OPzJVBIs2mHvAHyLDLMHHYHljTQJE=; b=rTEYwHbA2AQE/tj9/78M9zbWJzy9sLTOStIkaZekv51ZswSlA/x84gz7Z/5j7hbrpf m5bz3ko1Zt9U5aK+5/NwDEHzQmefqUeOYBoYsS7JLSpPMTP32Qu+xJW/qAHDz43b6K7c Eng73nf4wXW/vQJz4v+B+rAk/jvHp2o9UyKG0OLdDhdyOg58J1JX8t8H/LTlPdTdnVQd MojroGpxt9eMQ9BoApkBIY+UC0WOtEeAzcxAu9YFnAF+kHuSIYnVNFs/QVsq7Y19mNVq nWKyFAQGKg9bvubli+PTu6uUtY8p4qjU+niFJ3QZJThYfF2RGF95u5kv+2ThoO8RMOF0 CU6g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCX4DpGSwnjdAb4vvti0SqgbEJwI8YnGnkwZiGS5+THyKDwZilGff2USZqPrIXrF9M9OUadfw+lMNyvz@gnusha.org X-Gm-Message-State: AOJu0YyO7guvsb3tBNAsCT/To4qmPuPm27uI/sN1p3FAm8z/eGFN+rdZ JMA4nAwqaO1izNh2zdRhzqlItsi9fVF04qAeWvBB3Zsmx1/A8/oyhFq7 X-Google-Smtp-Source: AGHT+IHJVkRWhuyBN6zYg26ofjfRIpRqNVQeSN7gG8okzxZIk4EcJvapJ2UVeYS3w8UdBwS0R9yaTA== X-Received: by 2002:a05:622a:1995:b0:4a4:323a:2d76 with SMTP id d75a77b69052e-4a5a58b1b64mr2195921cf.10.1748984922878; Tue, 03 Jun 2025 14:08:42 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfMTofx7Yf+Drvzsb93PkYvR/MvILJv/RHEq45/ZAp3Iw== Received: by 2002:ac8:5059:0:b0:4a4:3182:79af with SMTP id d75a77b69052e-4a432520b37ls109637661cf.2.-pod-prod-07-us; Tue, 03 Jun 2025 14:08:39 -0700 (PDT) X-Received: by 2002:a05:620a:17a5:b0:7c5:5e9f:eb2d with SMTP id af79cd13be357-7d2198ffa9fmr98731585a.44.1748984918982; Tue, 03 Jun 2025 14:08:38 -0700 (PDT) Received: by 2002:a05:620a:27cc:b0:7c5:3b15:3956 with SMTP id af79cd13be357-7d210d61645ms85a; Tue, 3 Jun 2025 13:33:10 -0700 (PDT) X-Received: by 2002:a05:6214:20cf:b0:6f8:e66b:5744 with SMTP id 6a1803df08f44-6faf6f9ea6dmr2806586d6.18.1748982789551; Tue, 03 Jun 2025 13:33:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1748982789; cv=none; d=google.com; s=arc-20240605; b=lB+f/+25vW+4JFJUiP7CULt1n3XREDR1XxslejgigiWfNC7gfvypXZu03sINJgw7Gf gltuSHzYyQSwBB6Zs1hkoMeLO1nt1t9NWHiSkQuTpEofsJ3F0kSsvfWc4EiyceQdPWSa kpvyF6EjzF68yoKaJasnnCOizb24XibDHjC6xfL5Cp8XUClTZM2v+M55gQjUStQTbOyb DMmrh1LgEC0S0cqwJUPyM78A3vuFVh/BPKKt0PqUTexIENeeOhjTmdSBV8OOS/eJ7vTX bgsBgE2kZM33xLEiuCd4Snv4mQ12EgIJibWl35bmxlEKtnex+NAyBCxwuZQABZPK0OAa 9z9g== 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=kQqNMTaxprA0sHyhsNt+u8B8vpBFvNxx8JpHqiWmYhs=; fh=o1SdMVRf/28sBvQbMll4aOHyU8PCEOKtRhGrsxvUFGI=; b=RZsIuaQaV8QVy0L1AgrJdVaw6aOWZJcK3q+FrxmeCUWl4BMiW7PpI0nz70gV6kWkeR lgEcJkpj/dGGVJ1tFDjj1O8pgXxSIo1OdhQEl2Ijy9l2A3L/N8R7t7sVw5VaYbo4rywa +200/DdBg/pff/7VaD6IXu4gwR3LaPR+iIrCzrvRxuO+XhPW1uhLVhWkvbum5qWQholp kMgKVs2YktrFXAKNvgzguU0rflul3TMeYzYdN0qm1IhVN50chQCFrDZ31+VKpWcEUqlm lwpBgoH06C7TyYd52gHgz+lxiSjFhO8xG+nnwQ92EHFl31QvSA58NFc6URuCwql6Tbds MLZQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm2 header.b=Rnmz+gpM; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=Qv5QW+Qy; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.157 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl Received: from fhigh-b6-smtp.messagingengine.com (fhigh-b6-smtp.messagingengine.com. [202.12.124.157]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-6fac6eaa0ffsi5812436d6.6.2025.06.03.13.33.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jun 2025 13:33:09 -0700 (PDT) Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.157 as permitted sender) client-ip=202.12.124.157; Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id D82552540121; Tue, 3 Jun 2025 16:33:08 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 03 Jun 2025 16:33:08 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnegoufhushhpvggtthffohhmrghinhculdegledmnecujfgurhep hffktgggufffjgevvfhfofesrgdtmherhhdtjeenucfhrhhomhepufhjohhrshcurfhroh hvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucggtffrrghtthgv rhhnpedtudelveeivddtvdeufeefjeehvdevkedujeehtefhjefhhfeuvefhvdfftdekge enucffohhmrghinhepphgvthgvrhhtohguugdrohhrghdpghhoohhglhgvrdgtohhmnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhjohhrsh esshhprhhovhhoohhsthdrnhhlpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopehpvghtvgesphgvthgvrhhtohguugdrohhrghdprhgtphhtth hopegsihhttghoihhnuggvvhesghhoohhglhgvghhrohhuphhsrdgtohhm X-ME-Proxy: Feedback-ID: ie5e042df:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 3 Jun 2025 16:33:07 -0400 (EDT) From: Sjors Provoost Message-Id: <024E3F99-20B0-4D86-BCEB-AED508221391@sprovoost.nl> Content-Type: multipart/alternative; boundary="Apple-Mail=_9FC42DDD-39CC-4AD5-9592-25F890367453" 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 22:32:56 +0200 In-Reply-To: Cc: bitcoindev@googlegroups.com To: Peter Todd 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=Rnmz+gpM; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=Qv5QW+Qy; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.157 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=_9FC42DDD-39CC-4AD5-9592-25F890367453 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" After some back-of-the-envelope calculations*, I agree that this pointless. But it does seem that the first-seen rule is quite useful. For an attacking= pool with fraction f, it reduces their success rate from linear with f to = quadratic. Although theoretically that's worse for small pools, it doesn't really matt= er in practice, because the odds of a successful reorg are tiny anyway. Eve= n if the attacking pool allocates 10% of its hash power, which would be ver= y hard to sustain in a competitive environment. * =3D too sloppy to be worth sharing. Someone actually competent at math co= uld do so. The strategy would be to mine an alternate chain for n seconds a= fter each "bad" block (regardless of new blocks coming in). If the pool fin= ds a block, it keeps mining on it until a longer chain appears. Compare thi= s strategy with and without the first-seen rule in place, otherwise assume = instant propagation. Then consider how many sats of transaction fees the ot= her miners should rationally be willing to forgo to avoid the reorg risk. - Sjors > Op 3 jun 2025, om 19:51 heeft Sjors Provoost het vol= gende geschreven: >=20 > They can broadcast an expensive signal, i.e. make a statement, with a sin= gle block even if nobody builds on it. >=20 > More cheaply, and perhaps more effective, they could publish a feed of we= ak blocks on their social media, containing the hash of each rejected block= in a coinbase OP_RETURN. They could mine this block for just a few seconds= or minutes, before resuming to mine on the tip. >=20 > Even a low success rate could serve as a deterrent to other miners agains= t including "bad" transactions. Rationally the attack would have to cost ab= out as much as the extra revenue from censored fees, but risk aversion woul= d probably leverage to this strategy. >=20 > Of course I'd rather not go down this path. >=20 > - Sjors=20 >=20 >> Op 3 jun 2025, om 19:41 heeft Peter Todd het volgen= de geschreven: >>=20 >> On Tue, Jun 03, 2025 at 08:50:34AM +0200, Sjors Provoost wrote: >>> Or people can just spin up more Libre Relay nodes. Both miners and issu= ers of various scam tokens have a monetary incentive to do that. Whereas pr= oponents 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 wi= th 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. >>=20 >> I need to point out that you're being unfair to Ocean here: with their <= 1% hash >> power it's damn near impossible for them to reorg blocks. The reason is = because >> if there are two blocks at the same height, Bitcoin Core accepts the fir= st >> block seen. >>=20 >> Thus if Ocean wants to reorg a "spam" block out, they need to find not j= ust >> one, but two blocks in a row before any other miner finds one. The proba= bility >> of that happening is (very) roughly 1% * 1% =3D 0.01% per attempt. Given= that >> blocks are worth ~$300k these days, you're asking them to spend tens of >> millions of dollars worth of hash power just to reorg out a single block= . >>=20 >> It's not going to happen. >>=20 >> --=20 >> https://petertodd.org 'peter'[:-1]@petertodd.org >=20 > --=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CC0C1719-662E-4571-97EE-4DC504CC4360%40sprovoost.nl. --=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/= 024E3F99-20B0-4D86-BCEB-AED508221391%40sprovoost.nl. --Apple-Mail=_9FC42DDD-39CC-4AD5-9592-25F890367453 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" After some back-of-the-envelop= e calculations*, I agree that this pointless.

But it doe= s seem that the first-seen rule is quite useful. For an attacking pool with= fraction f, it reduces their success rate from linear with f to quadratic.=

Although theoretically that's worse for small pools, it= doesn't really matter in practice, because the odds of a successful reorg = are tiny anyway. Even if the attacking pool allocates 10% of its hash power= , which would be very hard to sustain in a competitive environment.

* =3D too sloppy to be worth sharing. Someone actually co= mpetent at math could do so. The strategy would be to mine an alternate cha= in for n seconds after each "bad" block (regardless of new blocks coming in= ). If the pool finds a block, it keeps mining on it until a longer chain ap= pears. Compare this strategy with and without the first-seen rule in place,= otherwise assume instant propagation. Then consider how many sats of trans= action fees the other miners should rationally be willing to forgo to avoid= the reorg risk.

- Sjors

Op 3 jun 2025, om 19:51 heeft Sjors Provoost &= lt;sjors@sprovoost.nl> het volgende geschreven:

They can broadcast an expensive = signal, i.e. make a statement, with a single block even if nobody builds on= it.

More cheaply, and per= haps more effective, they could publish a feed of weak blocks on their soci= al media, containing the hash of each rejected block in a coinbase OP_RETUR= N. They could mine this block for just a few seconds or minutes, before res= uming to mine on the tip.

= Even a low success rate could serve as a deterrent to other miners against = including "bad" transactions. Rationally the attack would have to cost abou= t as much as the extra revenue from censored fees, but risk aversion would = probably leverage to this strategy.

Of course I'd rather not go down this path.

- Sjors&n= bsp;

Op 3 jun 2025, om 19:41 heeft Pet= er Todd <pete@petertodd.org> het volgende geschreven:

On Tue, = Jun 03, 2025 at 08:50:34AM +0200, Sjors Provoost wrote:
Or people can just spin up more Libre Relay nodes. Both miners an= d issuers of various scam tokens have a monetary incentive to do that. Wher= eas proponents 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 bl= ock 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.

I need to point out that you're being unfair to Ocean here: with thei= r <1% hash
power it's damn near impossible for them to reorg blocks. = The reason is because
if there are two blocks at the same height, Bitcoi= n Core accepts the first
block seen.

Thus if Ocean wants to reorg= a "spam" block out, they need to find not just
one, but two blocks in a= row before any other miner finds one. The probability
of that happening= is (very) roughly 1% * 1% =3D 0.01% per attempt. Given that
blocks are = worth ~$300k these days, you're asking them to spend tens of
millions of= dollars worth of hash power just to reorg out a single block.

It's = not going to happen.

-- <= /span>
https://petertodd.org 'peter'[:-1]@petertodd.org
=
-- 
You received this message because you are subscribed t= o 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.googl= e.com/d/msgid/bitcoindev/CC0C1719-662E-4571-97EE-4DC504CC4360%40sprovoost.n= l.<= /span>

--
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/= 024E3F99-20B0-4D86-BCEB-AED508221391%40sprovoost.nl.
--Apple-Mail=_9FC42DDD-39CC-4AD5-9592-25F890367453--