From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 26 Apr 2025 03:57:46 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1u8dE9-0007S0-Qx for bitcoindev@gnusha.org; Sat, 26 Apr 2025 03:57:46 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-60634afce18sf2551640eaf.0 for ; Sat, 26 Apr 2025 03:57:45 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1745665060; cv=pass; d=google.com; s=arc-20240605; b=eq4Rr8RXtnD/p1/yY+gOUdXgitVc8xwf+jwULFAKiLXc2iOJeAeA7sO9DmLRWsgXtk i4Dy0rEXCfTFdVz2IxVoljgZdQ1jD2dfycddcsuF/lQn4DDVjYJbo8m6Dojv5UuBqAHj fxwY3zIMalnlkbxodUbLXEVaI4yRH9cBdxJH8615eSVZpYPlOLJRjNdfX3eTojSPqJp4 MmCB+hpZpDWIVkiJLbVKJlAzhgwfsMA+CSgR3UoHl2auJMEqKmCkW7cuRbA60Z3wspCe 9gA+DeekkhpzfjmBgDuPJU9kKqhkbVN+OBXjwkFjrYwz2SAJAHk/sqxDqLJbNqpx1DBD 7S1A== 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=MKTCdhSKzaxD6j1Ozo4EURMtBWmlBcC+IqsL75Dzgjo=; fh=037MQzzdZ5/wvOfCm7ChEEVh7qlSiG6Xv86bobhkEJU=; b=ALRQUr94KW467RCvHw/1NPteW0saX/sAYU2N2VPZ5ZuoqSbYkKHydYllziXIwiNIuC QqDsgxwERmVVjoNOPy+Q+6hakhejqhOVQEuDHEMow6YRuQqLSK3/euiY5Y+WwZXAlr8F ORy2+b69jTS19r2fA8sEU5uIOjMF4Hhvfkx6gwxXM+wDlqaSE1I2OsrgOYPbbCbdPLfT 3NHnzXiDhZ6IRBjIpsVlO+CO2WxCogInmqW3KrIt2a6tMHzXL9RHlvhfYIxLyF0QQAGx QCzyEzWTIwyEgq7N7RH2NcepvJnX/y+xVaRxzifOiW3OW+HB5U6VDSHiD8MMEJOMX/sx i5Iw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm1 header.b=VYIgVXVa; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=eb3MaZAa; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 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=1745665060; x=1746269860; 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=MKTCdhSKzaxD6j1Ozo4EURMtBWmlBcC+IqsL75Dzgjo=; b=LfkV70dWrz5KYjMTcNRFqCQ8Q/3vT9NPsSJjzE+wYjx0MewutiaApFhQlth0W7pYiV /I4KvDfSZINGtIV1kS7yvpXDNwLBJN9rzfcptkRv8Y8RdUrOx5EvDUTlRLhA0P5V4abR NWLBPZTp+cNgFth59L9e52iWqLKAvEHKCHhLBiMapepnvgBLHRKcBv/RxCtGzytfh0DW R3O7jhw0rCdA8uAN2o5gwm8lWJS+8Hlxsm4zyphcRP2If8asYLEHv98xxiQBxvxBJnGu oZUXkAuSp8mZmqigMi2Z/BFlTIhDbhcWj4XE9CzfVCm1+Fzf+eJk9jf1C3xSqWheW+LC mZkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745665060; x=1746269860; 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=MKTCdhSKzaxD6j1Ozo4EURMtBWmlBcC+IqsL75Dzgjo=; b=VTkpE5fe5pkGbNeagTMhmrkMPyDFCXZuhaIVI++EdSRhGSdKIQ3dvtUqPCGnv9hhXd rSDLs+ulAHz5BfWqt17KUHfbmgPHoMGusANOGpc9dK0U7F0cUg9FsZE2B7b9CI5b3gDR rP06hNgS3G+QN2Z40q8PVI2OQpteYQkfwGRyx1hY/IPNymxE946TBN37x6G+U1t0lo2C 5wI0OB6eKYAaeGRjwiMsTnqXYI7COiW3NE4qxJ7Pyyn+ySBAGvAE/PUU45I7g6UzLHob QUiubjmtyNISNjKFa+dboAL2YWQQ0TELwxmIoOPPPcuvpX+kz/ePXig80/gCKxgVLugL GPlg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCV/AAyddx+w6aOXQqvyNzrn/tk6FMeNWDOVc0dEDtV0lsw5SixmRZBtEQ8sak4Tg7mleTwmhqov2pQ9@gnusha.org X-Gm-Message-State: AOJu0YwuEu59xxN+MTVCCjx5TmpzlBeXUavXXZEFC3S5gHLCTOJyXznH fezlFxdOJtTN+sXhY1naPkpKvN+awND7ggZch9A5ITGaJPBolXe7 X-Google-Smtp-Source: AGHT+IEKzuzarxSHIdRpgh+JTOEjptSCTeJ3tXypfYamWL3pUc7M7oQM7CVZY5M8Jgh24fXoMwl2qw== X-Received: by 2002:a05:6820:c86:b0:606:26bd:409f with SMTP id 006d021491bc7-60658f3b064mr1641073eaf.6.1745665059581; Sat, 26 Apr 2025 03:57:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKH3ZvdezBhOFjbhno+QQez9iz1g6gx9OnIgGnVmmqkDQ== Received: by 2002:a4a:a683:0:b0:603:f12f:5cf with SMTP id 006d021491bc7-606434b435dls816215eaf.1.-pod-prod-05-us; Sat, 26 Apr 2025 03:57:36 -0700 (PDT) X-Received: by 2002:a05:6808:3386:b0:401:e694:3e82 with SMTP id 5614622812f47-401fd70d9f1mr1123413b6e.6.1745665056217; Sat, 26 Apr 2025 03:57:36 -0700 (PDT) Received: by 2002:a05:6808:1d0:b0:3f6:a384:eb6f with SMTP id 5614622812f47-401f2e72ab9msb6e; Sat, 26 Apr 2025 03:53:33 -0700 (PDT) X-Received: by 2002:a17:90b:1c07:b0:2ee:b6c5:1def with SMTP id 98e67ed59e1d1-30a01317a49mr3577568a91.8.1745664812875; Sat, 26 Apr 2025 03:53:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1745664812; cv=none; d=google.com; s=arc-20240605; b=le0pqpLW5f/+YUXh2g4nNVv6ujvcWO8DRqBU4GJ2J/vSHBv/kJpbZslOft4edOL/tD lMFZCdhI6pPF9Kv2sEOT0SMBBMGHLeK+dBAv8kN0dZPpYR14yvomjp3jULTi5QmL9T3C X00YwYnyV6r9gOIrLe+rAssrQX4yT5sc50Gnjsn+g3bnilrh2JyFgAnrCNj6sDVuqUrP mSMplaZC2EBRvBrv13h7vc5nKP1Mt5dSIO+r1GQKUd3CctZAHMNMScs5097UWUfd3X0r uQ3NBr1Dj+moVt372ptKMaJ9eU1woBWmjnXfRreH/d/E9A5IYoEsfQHkrmcx70urmfAJ Wzzw== 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=OJWaKFJJHAs4jPFuy4kcjcY085l/u1ia9k0YPCw31XQ=; fh=ZXVVqYDe2aQ3zBYF9HPbjtuUn/Og0i4ghjhZ3fYEqfM=; b=e+1VVHR98K1sDhM6mOaS4RaUQzO5Vzck+eQ+S8Phf5ISmMKIXa0G6YMP5uUGEKyVgt sV/n3oUpgRUsuqB/yTtCi8oCLBa7zqoUHMY6+id5vr2O+xLT3h68C+YPoMG46cGsxduo TjNAsjhI3k1I/wlSotq1wyy9eVW0Tu/oShBhyuERr2ixCn1/t/R4NzLzijTn+t5/3d6t fFysjfXLH77OgnQSgSNS6bBylfRQpR2DMTglZ9rwAIQdjho0YKT1542Ld+N4MZDM6P4t pyLsRrae/TJSYK6AHv3H+gMYyTg+ZeeYpDO1oiK6S4XKE8xMt3KLPw/N+nbXGZipJgt6 XJ6g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm1 header.b=VYIgVXVa; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=eb3MaZAa; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com. [103.168.172.152]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-309ef037e60si46900a91.1.2025.04.26.03.53.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Apr 2025 03:53:32 -0700 (PDT) Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 as permitted sender) client-ip=103.168.172.152; Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 82783114021F; Sat, 26 Apr 2025 06:53:31 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Sat, 26 Apr 2025 06:53:31 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvheehtdduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdt vdenucfhrhhomhepufhjohhrshcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovh hoohhsthdrnhhlqeenucggtffrrghtthgvrhhnpefgtdeuffekvdfgfeeiveffvdehgedv ffeuffektdeltddtheehffelhfehtdffhfenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhj ohhrshesshhprhhovhhoohhsthdrnhhlpdhnsggprhgtphhtthhopedvpdhmohguvgepsh hmthhpohhuthdprhgtphhtthhopegsihhttghoihhnuggvvhesghhoohhglhgvghhrohhu phhsrdgtohhmpdhrtghpthhtoheplhhukhgvsegurghshhhjrhdrohhrgh X-ME-Proxy: Feedback-ID: ie5e042df:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 26 Apr 2025 06:53:30 -0400 (EDT) From: Sjors Provoost Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions Date: Sat, 26 Apr 2025 12:53:18 +0200 In-Reply-To: <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org> Cc: Luke Dashjr To: bitcoindev@googlegroups.com References: <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Original-Sender: sjors@sprovoost.nl X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm1 header.b=VYIgVXVa; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=eb3MaZAa; spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 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=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Op 26 apr 2025, om 11:50 heeft Luke Dashjr het volgende g= eschreven: > It should be needless to say, but this idea is utter insanity. Disappoint= ing to see positive responses, and not one sensible reply calling it out ye= t. The bugs should be fixed, not the abuse embraced. If attackers continue = to bypass filters, we can go back to a full whitelist approach.=20 >=20 Are you proposing a whitelist of authorised public keys? Or a transaction s= ize increase? Your earlier proposal [0] to whitelist certain script forms is not relevant= here, because the Citrea white paper uses unspendable public keys to encod= e the data that doesn't fit in OP_RETURN. To stop that, you'd have to introduce a rule that only allows spendable pub= lic keys to be put on chain. Afaik, the only way to do that is to require a= signature. That would dramatically increase the size of all output scripts= . And that won't fix "spam" either, because you can still grind the first N b= its of every public key and/signature, maybe encode things in the nonce, et= c. The cost of that would be trivial for a bridge system. And "art" systems mi= ghtly actually like the extra scarcity. As for your earlier proposals (Ordisrespector, etc), they were not useful i= n general, because they rely too heavily on having standardness rules go ag= ainst financial incentives. Only consensus changes can work, but so far you= haven't proposed those. Since "spam" is a cat-and-mouse game, and consensu= s changes take ages to design, implement and roll out, it's also not a viab= le solution. Increasing the OP_RETURN limit reduces harm compared to the two alternative= s: 1. UTXO set bloating with fake public keys 2. Large scale bypassing of the (default) mempool, which leads to a) compact block relay failures (mempool fragmentation) b) centralisation Custom-but-public relay networks like Libre Relay don't cause (2b), but (li= kely) do cause (2a). So it's not good if Bitcoin Core default policy heavil= y incentives such an alternative network. That's one reason why -mempoolful= lrbf is now a default. You're also not specifying what problem you're trying to solve. Nor what "d= amage" is done. If blocks are too big in your opinion, then why not simply = propose a block size decrease (again)? I would not expect meaningful suppor= t for that either, but at least it's simple. - Sjors=20 [0] https://github.com/bitcoin/bitcoin/issues/29187 =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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CEB83B34-6C5B-469E-9914-20940F27EEC0%40sprovoost.nl. --Apple-Mail=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

Op 26= apr 2025, om 11:50 heeft Luke Dashjr <luke@dashjr.org> het volgende = geschreven:

It should be needless to say, but this idea is utter insanity. Disappo= inting to see positive responses, and not one sensible reply calling it out= yet. The bugs should be fixed, not the abuse embraced. If attackers contin= ue to bypass filters, we can go back to a full whitelist approach. 

Are you proposing a whitelist of authorised = public keys? Or a transaction size increase?

= Your earlier proposal [0] to whitelist certain script forms is not relevant= here, because the Citrea white paper uses unspendable public keys to encod= e the data that doesn't fit in OP_RETURN.

To= stop that, you'd have to introduce a rule that only allows spendable publi= c keys to be put on chain. Afaik, the only way to do that is to require a s= ignature. That would dramatically increase the size of all output scripts.<= /div>

And that won't fix "spam" either, because you can = still grind the first N bits of every public key and/signature, maybe encod= e things in the nonce, etc.

The cost of that would= be trivial for a bridge system. And "art" systems mightly actually like th= e extra scarcity.

As for your earlier proposals (O= rdisrespector, etc), they were not useful in general, because they rely too= heavily on having standardness rules go against financial incentives. Only= consensus changes can work, but so far you haven't proposed those. Since "= spam" is a cat-and-mouse game, and consensus changes take ages to design, i= mplement and roll out, it's also not a viable solution.

Increasing the OP_RETURN limit reduces harm compared to the two alter= natives:
1. UTXO set bloating with fake public keys
2. = Large scale bypassing of the (default) mempool, which leads to
&n= bsp;  a) compact block relay failures (mempool fragmentation)
   b) centralisation

Custom-but-public= relay networks like Libre Relay don't cause (2b), but (likely) do cause (2= a). So it's not good if Bitcoin Core default policy heavily incentives such= an alternative network. That's one reason why -mempoolfullrbf is now a def= ault.

You're also not specifying what problem you'= re trying to solve. Nor what "damage" is done. If blocks are too big in you= r opinion, then why not simply propose a block size decrease (again)? I wou= ld not expect meaningful support for that either, but at least it's simple.=

- Sjors 

[0] h= ttps://github.com/bitcoin/bitcoin/issues/29187
 

--
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/= CEB83B34-6C5B-469E-9914-20940F27EEC0%40sprovoost.nl.
--Apple-Mail=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE--