From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 02 May 2025 03:33:26 -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 1uAnhs-0000ei-O9 for bitcoindev@gnusha.org; Fri, 02 May 2025 03:33:25 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-60212c73868sf1417791eaf.3 for ; Fri, 02 May 2025 03:33:24 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1746181998; cv=pass; d=google.com; s=arc-20240605; b=lacNapqpMItfY41VxH8zs8HTUL0pVP8APw7UGdOLg7z2EWQtTIeoF5XK1qdNER78sq hwqH7Va61rq1hgi/LSlGKrN84ubAMyz/tIfLQRJ9EwupsvltLh/GzI+4gsDb2f1MeQPa 5JH+Ylqv+mf00Cvfg0NatM2bzl4NxFBaa9xGXDCr3ohvFZXwc9L2VPzbjuYXs8eBiwgN kYrjtLHqboprwzYY0g9nE68U1MUq7BeOjYMAtv6hhwjKIZ9O5cqMdh9aK9Vtmx2HpjbF JBxc8A81t7HXSuFGFgDJ5vpCtSUbPbK0A5icEE5nQxPLlEN0ymasnQDokNo3BXiXq4Ot QDgw== 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:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=WAbyIMaO4WDY+xcmTEpxAdobHTx5J6SCD/e40UPxWYg=; fh=cFyLSzVExFgOqOKwl1LLFuNsXg7+RMFBOEy0xmoJaVQ=; b=AV0Px+BjeqAXixhavCpUr4K+J0nX7uvhNeIZ6tk3OC9ctB/aUOUVmBDDtYkck62fss lrlglTAt+Rw/1GH/CAmNYtr0XMD2Y60PpDXb9EwSrvBfqDw2lpxmLQ/FcY8GEuxKANpD Ffc1tKQYrnBrejrnoQ7A+/AguKhUnq0St49qmORXGyGPw2wUEYB6r4mo35J4EvULVTBW YROOgjyjVJjM8DxbfO3Nfok2X6qjz89307oKr05iZHfhGx3WhtqDiJEgbuGQ5Vy6bbnP TW/BKkWRraJjH7N5YqN6CGrmXM4LncEsEGKjgdO/WU8xNIR6442rlqQXQR06SqwPEGDE r8yg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746181998; x=1746786798; 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:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to; bh=WAbyIMaO4WDY+xcmTEpxAdobHTx5J6SCD/e40UPxWYg=; b=cVdlKRLUnRyCatfV+EKvwaxdZA2uyD1ksj6YstwuWzEuCWjp1tZzZjJSFaTx32O1uL 6qrf++XAITJdhT5KuoZVJWiQv1ZC/+p4gryId0P0gtjfB/XHUaTK7bkXC2lNgwfh9w/o SqOUYjrayuwutLZNkJqZJzQfIOKJ5yXLLhxxvc92nl+cf91H3ulg4pP3mSnEmqgBanOO YP+etHQOw/uRCLdD5dHrCg06q/96nEg+E5WR4LjAN+60EEL2i+Xr+zBLRHF6GLraPjhD PNxxJjRs59HUadoCSi2rxLwo4J1iIzlSR/QnFX6OhhJ4BRv0R2OucPoilN/80vALeunF BJ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746181998; x=1746786798; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=WAbyIMaO4WDY+xcmTEpxAdobHTx5J6SCD/e40UPxWYg=; b=tOrxH0rVJs7RXtJSmDBlKaxF/4Yc0cQHLFN7Dzvj+yTFTrqbxIUg0mWLu6vw3Y2Qmy 5tPf+rOsGrJ+wNu61QrEI++pCYE7KEmW7Avlz5QeB7zINxvCk8n55NdchsUKV0joNMz9 vrU2uhj2s2r3Q/XSzAUDbz3f5Ujx/y2u+kox5UTDyWqDH2n8veF8KoiBDaNxmbwOSozO +p8sAovn6My4wzdhvqYQPYBkh3fGrsCYacTlfNklJS9hY/zx/UqtQjTFqSWCQNxv5LiQ NzoCmc+KuNxiHFjxgJyXpvuYGxIx9DVpAeqCV9KQrD0FAi0rpryyHAYYdmGZ3hhUGK4Z 9IaA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUNHD5RQaZNR27mNi+gme3ShPEAvDuOoJgZGvK9tYWH8JNwxgMdt7YhKzv9yBhjatB6AMGulwQjBhmr@gnusha.org X-Gm-Message-State: AOJu0YzqfnrBwIQJ3ya46f8BiiqJd/RdQOluUhpttb3wFllSht4JHwlo K03rzZNLNNd8TTjBOWbClo6bmEF9XsBAKwZdUtfXu4bg0tP05iq+ X-Google-Smtp-Source: AGHT+IHFf6HM3k6zPOd+aAZbT8IYcZbLDO9EB89FdaGMyvLQnzqG8ug74oV2DVHZ8gQFdGBn/cCExA== X-Received: by 2002:a05:6820:1f03:b0:603:f191:a93c with SMTP id 006d021491bc7-607ee836713mr1261202eaf.6.1746181998396; Fri, 02 May 2025 03:33:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGEOVNQIZERYmtvNsYk8bbImtV5+yNljHh7R8SIA6wmkg== Received: by 2002:a4a:b304:0:b0:604:8bd0:c016 with SMTP id 006d021491bc7-607def3c95els456440eaf.2.-pod-prod-01-us; Fri, 02 May 2025 03:33:15 -0700 (PDT) X-Received: by 2002:a05:6808:2f0c:b0:402:292:4417 with SMTP id 5614622812f47-403419aaeb8mr1604220b6e.1.1746181995178; Fri, 02 May 2025 03:33:15 -0700 (PDT) Received: by 2002:a05:6808:14d5:b0:3fa:da36:efcd with SMTP id 5614622812f47-403425cae8cmsb6e; Fri, 2 May 2025 02:51:35 -0700 (PDT) X-Received: by 2002:a05:6808:3319:b0:3f6:65fe:2672 with SMTP id 5614622812f47-403419acf0amr1222220b6e.2.1746179495096; Fri, 02 May 2025 02:51:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1746179495; cv=none; d=google.com; s=arc-20240605; b=VAJInH/ol72AfLIP9TjvchDYHIBaX+Ch8RS3Qat44ddK64uUz1xSBR3nufICSpzKyZ UDWikPO9T6LBeq2ruI0hmM4yZa+5u+X1O8sCDL0/n+hjANNWXqMh7IsctSmwotzVtMlU E3501FutD445/+80I4LAVJBBcVkuaWNAIdWMfDBJAUd0pNdb8INTpcOflAILw8to+M0O zja3zFLpd+5gszJjjRCwcMLl31gATHmZETakoXn9FkLKrjjt4ZKwUSoO+/fQPkmzWnUB kYJlqvAuE6KvIpfEEdJluCv4SYxhRiCCrPQO8wjRekcYWKqIZMkJCjVsFe3NIu0HzLel RmuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date; bh=C3jrK5L91cfv3GgewcamgrY7oxyQvId8MDFETJj8UXQ=; fh=buJUvwPPgdi5Z5zmcvUt6NajLrOVgzwZz6n1oNFrtB8=; b=kRA4c2H1ZDVdmXAUnFeXovoXB1RIkXxtr4ZjNxbe+wB49LfHSqdF+kGbxeX8se85W7 aV0yO/s8ZjPwhW659Xtr6LW/th9OHwt0dLY0B8pCS+xNVzUjz0M9hob708YtPdwKba5b 7rrWASbuAAmF5rNMIrcXl+NeDrQUvJ6KvXpYTXRsqxYh0pXg/v2LgIp2q75h5wJyqEIr ufzRi3Z60ir2+1x1Y2H02ev/HXg32R/bhLq5xqiWma+MQemvu8t9uQT8hKFmYsXaN5O6 snhPVw6T9kcdIx5pf5EHDrH51IRpI779hlT5YD72J5NEhh8WlbVITF3n79eH3JLFCwSR AMDg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-607e7681c00si101269eaf.0.2025.05.02.02.51.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 02:51:34 -0700 (PDT) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uAn3J-000401-2V; Fri, 02 May 2025 19:51:32 +1000 Received: by email (sSMTP sendmail emulation); Fri, 02 May 2025 19:51:27 +1000 Date: Fri, 2 May 2025 19:51:27 +1000 From: Anthony Towns To: Greg Maxwell Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions Message-ID: References: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> X-Spam_score: -0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au 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.8 (/) On Thu, May 01, 2025 at 11:29:35PM -0700, Greg Maxwell wrote: (Yay!) > So on this basis I suggest a principle for these sorts of policy: Relay > rules should admit all transactions which are reliably being mined. > I think node software should adopt this principal as a general rule. Hmm, I don't actually think this is a good rule -- if followed strictly, it prevents ever making relay rules more restrictive, even for cases which are provably harmful for the network. > By general rule I mean that should something like a miner begin mining e.g. > quadratic hashing bloat legacy txn, or using unused > opcode/successcode/version number or whatever by mistake or technical > ignorance there is no need to rush off enabling their relay. A general rule > isn't a suicide pact. Alternatively, if it's a rule with exceptions, then it's those exceptions that are the important factor and should be figured out. For example, the reason mining a "quadratic hashing bloat txn" is bad because it causes delayed block validation on its own, potentially in ways that aren't even sufficiently mitigated by running your node on extremely high end hardware. Transactions like that should really be removed from consensus validity not just prevented at the relay level, and BIP 54's consensus cleanup hopefully does that. Miners have accepted out-of-band relay of spends of unknown segwit versions (which I presume is similar enough to the "unused opcode/successcode/version number or whatever" case), in particular txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 in block 692261 (the taproot exception block). Even though that was not done by mistake or out of technical ignorance, I think doing such things extremely rarely through out of band mechanisms is pretty much fine. (Even if miners do it for profit, rather than as a 0-fee tx where the outputs are a donation to a developer funding group) > But if it were the case that transactions misusing a > particular forward compatibility feature were reliably getting mined then > that feature would just no longer be useful for forward compatibility > regardless of what relay policy says about it and it would be better to > relay them than have the downsides of not doing so. If adopted, a policy like that would be fairly easy to use to hold the network hostage: find a miner who doesn't much care and has perhaps 0.1% of total hashrate, get them to mine txs spending segwit versions 2 through 16, and forward a handful of such transactions to them every day. The transactions are getting mined regularly and reliably (at a rate of about once a week), the transactions aren't immediately damaging the network, the miner is making excess profits, and by your relay argument, the miner is gaining a slight advantage in being able to potentially mine two blocks in a row due to the block relay delays caused by not relaying spends of future segwit versions. The LibreRelay project has already followed pretty much that script for pushing fullrbf relay onto the network, and is proposing to do the same approach for data storage in the annex, so I don't think this is just a hypothetical concern. I'd describe that class of policy as something of a "popularity contest" approach -- it's a policy that says that anything that's sufficiently popular is good/permissable. I think that makes sense as a check/balance approach -- "this think is popular, is there really a good reason why it's not permitted?" -- but not as the first thing we think about. > As Antoine Poinsot points out, the existent rule is entirely ineffectual: > Parties current bypass these rules with other transaction forms (such as > very harmful address stuffing which is impossible to block) or by direct > miner submission, which will continue considering the millions of dollars > miners have received mining transactions with violate the relay rules. > Because of this it will not become effectual with time or tweaking. It is > a dead parrot^policy. This is no surprise, since it's a product of > Bitcoin's anti-censorship properties that *generally* filtering will not > work except on the fringes. As such there isn't practical upside to > keeping filtering beyond what miners currently perform. As a check/balance, I think that argument holds water, and should cause us to ask if your existing policies make sense. I think it's fair to say Bitcoin Core's existing policies (as expressed by its code, and not necessarily matching the policies of various forks of Core) are (in no particular order): 1 limit utxo growth (via block weight constraints, and by avoiding creation of utxos that would be uneconomic to spend) 2 prefer that transaction data be prunable rather than potentially permanent (eg, better to have a 20-32 byte hash in the utxo set and a 160 byte x-of-5 multisig script in the scriptSig or witness, than to have the 160 byte x-of-5 multisig directly in the utxo set; this is the main justification for why witness data should be discounted vs output data) 3 limit block validation time to the ~1s range (on a block whose txs have not been seen before, on reasonable hardware) 4 limit maximum block size growth to ~4GB/week (ie, the worst case from having a 4M weight limit) 5 optimise validation and relay of blocks with txs that we have seen before as much as possible 6 allow anyone to create any sort of scripts they like (via p2sh, p2wsh, p2tr), within the limits of what you can conceivably do with script opcodes, and without causing excessive validation costs 7 encourage people who want to use the blockchain as an anchor for their data to store commitments in the blockchain rather than the actual data 8 allow miners to occassionally generate excess profits by mining non-standard transactions that violate relay rules but comply with consensus rules (There are obviously many other policies, eg the 21M coin limit, but I think the above are the ones most relevant to this discussion) I think all of those policies can be justified (or criticised) on their own merits, independent of their popularity per se, and I think doing that is a better approach than starting with what's popular or not. I think there's perhaps four conclusions you could reasonably draw about the policies above, wrt what's been discussed on this topic: * encouraging data storage people to use commitments (7) didn't really work, and given that could be done via documentation or blog posts where we could provide reasoning, examples and alternatives rather than just a "transaction rejected" which might be more effective anyway. the citrea design also suggests that that policy is interfering with the goal of limiting utxo growth (1). as a result, it probably doesn't make a lot of sense to maintain that policy in code. There's already the obvious incentive pushing people towards commitments instead of raw data, in that doing so reduces the on-chain fees you need to pay. * for (non-commitment) data storage use cases, OP_RETURN limits are probably largely irrelevant in limiting blockchain usage; while OP_RETURN is also prunable, it's not discounted (2), so including data in the witness will still be preferable to the people who wish to publish data in large volumes * people with legitimate concerns about their node being overloaded should probably be concerned more by the "limit maximum block size growth to ~4GB/week" policy (4), rather than commitments vs data (7), complicated scripts (6) or prefering prunable data (2): it doesn't really make much difference if your node is overloaded by spam or by real transactions, either way it's overloaded. I haven't seen any evidence of it being difficult to keep a node operating for that reason, however. * there are two aspects to the "miners generate excess profits from non-standard transactions": * one is that for that to only be "occassional" means that even vaguely legitimate use cases should have a supported way of being exercised via standard transactions without being much more expensive: eg, instead of consolidating 4000 transactions in a 270kvB transaction, you might use consolidate 1333 transactions in each of three 91kvB transactions. That limits the amount of excess profits the miner can generate, in this example the 3kvB of savings would only justify paying about 1.1% higher than the going feerate for standard transactions, eg. * the other is that if you want to disallow this from happening even occassionally, then you want to have relay and consensus rules be the same; but that effectively means that any functionality upgrade needs to be done as a hard fork, which in turn likely has highly centralising effects around the developer team, as running old versions of the software becomes infeasible > Some Bitcoiners are of the opinion that they still want a knob, I think > doing so is a disrespectful placebo[*] I don't agree with that at all: giving people what they ask for, even if it's literally a punch in the face, isn't disrespectful, it's the opposite. (Respecting other people isn't always the highest virtue, of course) > But in this case if there were a knob here I think would make more sense > for it to control mining policy rather than relay policy, since it would > actually have some effect in the mining context (in excluding the txn from > your own blocks) while as a relay only thing it is impotent. Core's mempool/standardness policy covers both relay and mining acceptability. I don't think it makes very much sense to separate them -- beyond making the code more complex, accepting txs into your mempool that you'll still relay but won't mine might block you from accepting other (conflicting) txs that you would mine, eg. About 11 years ago, you wrote: ] [...] Right now I've seen a lot of people ] promoting data storage as a virtuous use, and gearing up to directly ] store data when a commitment would work. ] ] If it turns out that encouraging people to use hashes is a lost cause ] it can always be further relaxed in the future, going the other way is ] much harder. -- https://gnusha.org/pi/bitcoindev/CAAS2fgT6qFHBojoB-teCjF_YAd9TePdQ3+NWnO0dwf9Bv583_Q@mail.gmail.com/ Even if they're fundamentally wrong, I think it's respectful to people who haven't yet given that up as a lost cause to leave them with a knob that gives them at least a chance to continue the fight for sometime longer. Let me offer a principle that will never need any exceptions: people who are a mere 10-15 years behind the thinking of the bitcointalk.org class of 2012 are still the brightest 1% of humanity. Cheers, aj -- 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/aBSVn7nJnrheLy5Z%40erisian.com.au.