path: root/5c/6004bb40478f22ef4079aaeed0febaab6d01c8

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 <bitcoindev+bncBDBNTKFG4EDRB2562LAAMGQE37SLYJA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <aj@erisian.com.au>)
	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 <aj@erisian.com.au>
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
Message-ID: <aBSVn7nJnrheLy5Z@erisian.com.au>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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.