path: root/6e/c87f3f2b584c0a5ca11fe7faaa573bfb54a924

Delivery-date: Mon, 05 May 2025 02:27:33 -0700
Received: from mail-qv1-f60.google.com ([209.85.219.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+bncBDBNTKFG4EDRB54I4LAAMGQEI3PIV7Y@googlegroups.com>)
	id 1uBs6k-0007KX-Sv
	for bitcoindev@gnusha.org; Mon, 05 May 2025 02:27:32 -0700
Received: by mail-qv1-f60.google.com with SMTP id 6a1803df08f44-6e8f6443ed5sf103763856d6.1
        for <bitcoindev@gnusha.org>; Mon, 05 May 2025 02:27:31 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746437245; cv=pass;
        d=google.com; s=arc-20240605;
        b=ZoUwFTab4Ah1Pcd3zS81uGprdUoL9Z1CXtevYZ6ayS7bldWl7Y+xkSdCIK1IVf/1MO
         Z/RT3W4a9R8Yb8rNYRQLDl2B4gSQBPikBT+DBgZOa2IojOuP+/qMgk91aIKAyiZy3R58
         1yHA5Ub3LbcDaTnNGRgPuDmEYAqqsxfX4UpAwMpQBzMQltGHY1JWtHDe+LvVN5Vo2Zjr
         pdP+ymif6eQxSNyaLf8Q4YQAi3JFU8j76lajWyvi3MDVBYzgB9G5JHAQ1PlTlerYhGQl
         UwEnWLWU+2kGETCb9hpqv59921qiIovj0uWEQh7fjxTAqkQPaDKskSey3zD0z63EVIXx
         Qpkg==
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-transfer-encoding:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:sender:dkim-signature;
        bh=Yy/NwaqcJVkeAphwSj3v7TBpD0ECn6elv7YEOTQU308=;
        fh=dUJVop0mMBZz0nYHwoufGw3PobXuGyJkIhM0ypkdmJs=;
        b=U0dcgsh0C3VX4f+tw+CBTkqkUA5ZAATom5zzr/cERctePCSYPAKWRAWg/PnlN4BoIu
         Tq5A/IvWurqefm9NV04nnQiUSayOtyzcifJAoIW9BcAS9aiOe72A/n+5j4zE7OQShFUB
         JEYn5BgblQbIoC1TtkgyOcQbIWoqtddE1dCxYrddirCo23DjYW15K8qrj0tIfXplOrrq
         7UvcEmUh4Rk0VjwtuEvWVPePRhaTT5MWrh5GRKKeGvlg91DVJuIKr6iug6O+qQXKGMDV
         VKJlwrWJsKrJlvrWWkhtFULw6sNMzvrhuHKdAPJl6gJ3mWITuMFp0IJywrRsXm/ixOrp
         5UuQ==;
        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=1746437245; x=1747042045; 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-transfer-encoding
         :content-disposition:mime-version:references:message-id:subject:cc
         :to:from:date:sender:from:to:cc:subject:date:message-id:reply-to;
        bh=Yy/NwaqcJVkeAphwSj3v7TBpD0ECn6elv7YEOTQU308=;
        b=cYTl9Kju9nyKxBw3p7EnW2RyLOK2k2xma0IpzfyuVacIW3sx9jjUHjYfSMm4mlA1KV
         3cKmbAlZf+t1Vo6Z+avWg1xTkzNHMknurmjorVILd+cuNsvJyCNPHts8NKAUBQz7CSD4
         8FQ/m+tJo8vZHS2n8raZh2oED3EuQpx4DFkUu5kevorKmTcifIBB63qb8xLvV8k1gTaR
         XzMO8ArSPpLYgD7ZC5ie0nLt1xzG6SYtfwNC6F2Yd25BtnyMEXwrypE/vE5J4Et59NZy
         C/zuBCo9WGpXCZc1srPdpKYPJ6gYKcsrJc2sXgD8+EwvQd0DPq/8XzBgSmntYmc7n1J4
         +xew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746437245; x=1747042045;
        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-transfer-encoding
         :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=Yy/NwaqcJVkeAphwSj3v7TBpD0ECn6elv7YEOTQU308=;
        b=LHAZk/bbEKLasoktcB0o++9BMmKMePAFH8BTokkhreD9fOBfk+0A8J/TDwtqSHHzvW
         3CdMIxPTRiSOxcXRkDMQ2v/kM6OUX+tAac6jrYHmQlNCDUHJL6ZaopXUyleaw9gBr/97
         LxhSJmpo4k6TV1mupA6sJYeqi49UQhrx+VRD83GROAWY546r8/ogMEjBtTtRCamkKDcz
         p4AyPbS/BT1r2EV/JnxSAG4B+WtuLufs5WYzbxvFGGulWaq1NJKK5mYZEY/f2H2UqhB8
         kHc85B7kFFyZ4k0iJNselzUHurWU6xWbR6KOL/fwaaLCi6mfipVZYvO4Q/5xEhedNQbs
         n3TA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWmsSV5T+6ZReQd7Dz3xyHqewAH/s/3GOKIQO/hS3jFCJwSEpVuxl6j88EpRo/OUhvxuLy5GyxK+jqk@gnusha.org
X-Gm-Message-State: AOJu0YwzOgBlO32f7T3VnIDnJaVgs1T3ZNgRygFOFXFRfmIgDJxRApk6
	LPE4Mp5g+l7lfeWwCMXhrjEIweHWW1RayI1goBlCsYg7U/Zfz7QJ
X-Google-Smtp-Source: AGHT+IFk16VIvCMfbwipmAcK7mh6aRv21uokkSWw5ODaa1DWUVYF0rxJHrjggfFQN+t53oq7AdPaCQ==
X-Received: by 2002:ad4:5aac:0:b0:6ed:1095:e9d3 with SMTP id 6a1803df08f44-6f50b2aee26mr219077456d6.14.1746437244407;
        Mon, 05 May 2025 02:27:24 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBE/7k00mF3wy0K9j+1rDlKpeIQu9sLvRsGiSK/S5eACgQ==
Received: by 2002:a05:6214:2021:b0:6f5:eeb:52af with SMTP id
 6a1803df08f44-6f50eeb53fbls147256d6.0.-pod-prod-00-us; Mon, 05 May 2025
 02:27:19 -0700 (PDT)
X-Received: by 2002:a05:620a:414c:b0:7c2:3f1f:1a15 with SMTP id af79cd13be357-7cace99ed1emr2244725485a.8.1746437239331;
        Mon, 05 May 2025 02:27:19 -0700 (PDT)
Received: by 2002:a05:620a:494d:b0:7c5:50d5:7703 with SMTP id af79cd13be357-7cace7f503fms85a;
        Mon, 5 May 2025 02:19:07 -0700 (PDT)
X-Received: by 2002:a05:6122:400a:b0:523:771e:8b81 with SMTP id 71dfb90a1353d-52adedd289fmr8926163e0c.7.1746436747146;
        Mon, 05 May 2025 02:19:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746436747; cv=none;
        d=google.com; s=arc-20240605;
        b=VLuTSd8Xo9+3nssisuEPBkp4lGS1xzXTtizMr4Fz8PmPr4LpeHJPfQ8urLxsaEYqUp
         FGbuJcci4LtHNb4maa2ETXjWm1GrFcXIXJxkP2iNTWE9BnULR/aF7U1rz2FUCaXGJcd0
         RC34AhMyAasotQ0aRDc4JS5sQhlmlSQnHxZlbcPMyJ8L2L9BMVeuGPkr7FiuXbkqxGyW
         ypyfGvRGXN8EI/Pvi6uA+1WxG0y9FwleylR/Sj/HYLPTZJLSIsHPAs6hdN1OEz0of5sL
         mdUzGPSWLWuuHpSmTHxVdZY00tiAmopZtOuLg23V6bRwSDAxqWeCGIwV7hj1ezx3F9j+
         n/GA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date;
        bh=jGuECoPB/SYFoEcTLysskYNLGNGbbltZeUUtVJbvUxU=;
        fh=buJUvwPPgdi5Z5zmcvUt6NajLrOVgzwZz6n1oNFrtB8=;
        b=jId0lPDQZ6avDyiTv3Y4y915VqH7U2jvYrHRNBSOEX/RJQFxEUyb/QN3ozKwJrG2Ir
         NFBzMm1meAz01/CkSOrm2PJreeBOcbUMhTQaXiIPHdkHF3XKPakJIPHHotf82xHiCY5G
         J6mfxm3KukO99Pv+E+gEwZHR4N3dI90s6fn/B/6OFt049FBvYfF2xcbW9CE8XZF5UsZO
         Du33OQJNENULT+/zoxwTcSS9ru1HJ6Nm6pTTRbr8AGpMlvfPZblA9tP3El0QdiTNaXNu
         7C0EvBuHduCbVbT5roMhqFyhpK2j2dJ8AoNl7LVuRT99ljoRw3lGTrpkPuiRHREXXcvC
         wQ/w==;
        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 71dfb90a1353d-52ae41366d1si100957e0c.3.2025.05.05.02.19.06
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 05 May 2025 02:19:06 -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 1uBryW-0004e9-0K;
	Mon, 05 May 2025 19:19:03 +1000
Received: by email (sSMTP sendmail emulation); Mon, 05 May 2025 19:18:57 +1000
Date: Mon, 5 May 2025 19:18:57 +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: <aBiCgRIRikR0MPei@erisian.com.au>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com>
 <aBSVn7nJnrheLy5Z@erisian.com.au>
 <0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn@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 Fri, May 02, 2025 at 10:36:44AM -0700, Greg Maxwell wrote:
> On Friday, May 2, 2025 at 10:33:18=E2=80=AFAM UTC Anthony Towns wrote:
> 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.

Err, the text/plain alternative in your email apparently doesn't include
quote markers for the things you're quoting. :( I guess this is some
Google Groups innovation? I'll fix it manually in the other things where
I'm quoting you quoting me below.

I meant to mention this last email, but had forgotten where to find
the link. Personally, I think Greg's "relay extra transactions via weak
blocks" idea [0] from a year ago is an approach that should be considered
here. The TLDR is that if there are miners out there with different
relay policies than your node that are accepting transactions you'll
reject (eg, lower fee, new tx versions, more complicated dependencies,
...) then once they find a relatively high PoW share, have the network
relay that as a weak compact block, with full round-trips to gather
any transactions that weren't in your mempool and add those txs to your
extra pool to help with block reconstruction in the near future.

[0] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805/1

That approach would also help improve block relay where standardness
policies are made less restrictive, for things like pay2anchor, package
rbf, or soft forks, when many nodes haven't upgraded to support the
new feature.

> Though even if were true, it's not clear to me that reductions in
> permissiveness are particularly interesting.  It's not a one way valve, b=
ut
> kinda.

I believe the Great Consensus Cleanup invalidates some transactions
that would currently be standard: the 2500 executed sig operations
limit is only claimed to avoid making **non-pathalogical** transactions
non-standard; I believe there are some pathalogical transactions that
would be standard today that will be invalid when/if BIP 54 is enforced
on chain.

> At least historically the community hasn't considered it
> particularly appropriate to restrict already accepted transactions, this
> is affirmed when we look at the counter examples.

I believe PR#1718 (0 value outputs are non-standard), PR#2577 (dust
outputs are non-standard) and PR#5000 (execution of undefined NOP opcodes
is non-standard) are examples of doing that. (There might be others,
I didn't look very hard)

https://github.com/bitcoin/bitcoin/pull/1718
https://github.com/bitcoin/bitcoin/pull/2577
https://github.com/bitcoin/bitcoin/pull/5000

(The high-S vs low-S example you gave is a case where an even better
solution was available; but that isn't always possible, obviously)

> So I would say that reductions in relay permissiveness are uncommon and
> exceptional, and if they happen at all will be on some case by case basis
> and justification and so the general principal need not apply.

I don't think promoting general principles where you need to be a top-tier
expert to figure out the exceptions is very helpful: there are plenty
of non-experts with an interest in bitcoin and who wish to be involved
in protecting bitcoin's functionality as decentralised money, who'll
simply be misled by that sort of principle.

I think it is probably sufficient to phrase the principle backwards:
"relay/standardness rules can be made more restrictive, but there better
be a damn good reason for it".

I think that still gets the right message across, without having to
go through a "you're breaking the rules", "the rules have exceptions",
"that's dumb, they shouldn't", "yes they should", cycle.

> My view is that a principle like this is an objective, not an exact
> edict.   "Here is what we're trying to accomplish".  And that absolutely
> can get overridden by circumstance specific exceptions.

Yeah; I think we should be aware that there's a fair number of otherwise
well intentioned bitcoiners out who'll mistake these things for edicts,
however.

> > 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 thing=
s
> > 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)
> Indeed, I don't think one-offs have any relevance to the idea I'm
> suggesting.

Anything that you can do as a one-off, you can automate and repeat. If
you're going to react in some predictable way as soon as someone sets
up the automation, you might as well do it for the one-offs as well.

> > 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 da=
y.
> > 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.

Just to note: if everyone else was in agreement, a 0.1% hashrate miner
would not block a soft fork activation (which usually requires something
like 90%-95% hashrate), and would not cause any meaningful risk of a
chain split even for light clients after activation. So I think under
traditional analysis you wouldn't expect such a miner to be able to
block the introduction of a new segwit version, given everyone else on
the network thinks it's a good idea.

> I don't follow: If someone is doing that then the version numbers are toa=
st
> for forward compatibility use. It doesn't matter what relay does, they're
> already toast.

I don't believe that's true for segwit versions. Any such spends will take
the form of someone sending some funds to an undefined segwit address,
followed by someone spending from that address in an unverified way,
moving whatever funds were there to someone else. Because the spend is
unverified, whoever mines that transaction can steal those funds if they
choose, so will either be doing that and sending the funds to somewhere
they choose (eg the Brink donation address), or will, in general, have
been paid even more in fees (whether in-band or out-of-band) to send
the funds to somewhere specific, purely as theatre.

Adding verification rules on top of such spend attempts doesn't cause any
additional harm -- people wanting to fund miners can already do so more
efficiently by just paying fees, and people wanting to spam the utxo set
if everyone else doesn't comply to their demands can also already do so.

AntPool currently has about 20% hashrate, even ignoring the pools that
mine the same block templates. If its operators want to prevent future
soft forks, do we really want to establish that regularly mining garbage
transactions is a perfectly effective way of doing so?

> The choice you have at that point is to allow their
> non-standard transactions to have collateral harm or not.

If they continue to make such transactions, despite it no longer
transferring value to miners the way it did before, then that probably
serves to spam the utxo set, but if that's their goal, then there are
already plenty of ways to do that. I don't think preventing one particular
way of doing that is worth allowing them to hold upgrade paths hostage
at almost zero cost.

The same argument doesn't necessarily apply to every upgrade method --
segwit versions and OP_SUCCESS are essentially explicit "pay to miner"
in ways other upgrade methods aren't. But I don't think we should be any
more concerned with people losing access to funds they've encumbered via
undefined upgrade methods, any more than we were concerned with people
accepting unconfirmed transactions getting double spent.

> > 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/balanc=
e
> > approach -- "this thing is popular, is there really a good reason why
> > it's not permitted?" -- but not as the first thing we think about.
>
> Mining *policy* is inherently a popularity contest, particularly for
> restrictions since they don't work unless ~everyone does them.  They will
> always be vulnerable to someone convincing miners to ignore them.  Coveri=
ng
> our ears and eyes w/ relay policy doesn't change that!

That's a fine attitude if you're willing to just follow the current
fashion, and defer to others as to what that fashion is and how it will
change in the future. Given the complaints and lawsuits that can result
from trying to set a direction from Bitocin, I can certainly understand
the appeal of that attitude.

But there are plenty of people around who will attempt to influence what's
considered acceptable; the people making the complaints and filing the
lawsuits, in particular. More concretely, both Knots and Libre Relay
are putting themselves out there as taste makers and trend setters in
exactly that way, and are both happy to defend their respective views
on the merits.

> When a fragile tool is the best tool we have ... it's still the best tool
> and we should enjoy its benefits when we can.  But when it doesn't work
> anymore we shouldn't delusionally pine for the old days when it did at a
> cost of creating relay/mining inconsistency.
>
> I'm not speaking in favor of popularity contests but rather in favor of
> acknowledging reality.

Again, the distinction I'm making here is on how the judgement is made; whe=
ther
it's:

  * "well, this is popular, so we should give up and just accept it", or
  * "huh, this is popular, we should reconsider it on its merits"

If we're settling on the former (with the constraint that we only make
rules less restrictive) then I think we're very quickly going to move
to the "relay rules =3D consensus rules" approach [1], and from there to
"whoops, we can't make standardness rules more restrictive (because
that would likely be confiscatory), therefore can't make consensus rules
more strict via a soft fork, but we want to do an upgrade, so time for
a hard fork".

[1] eg, as advocated at https://x.com/0x_orkun/status/1918744573251121575

If we're settling on the latter, then the fundamental thing we're judging
our rules on is still their underlying merits, not their popularity,
and that should be the main thing we spend time discussing/evaluating.

> > 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):
> A number of your examples are consensus rules, not relay policy.  That is
> an entirely different kettle of fish.

At least some of those consensus rules were previously enforced
differently by policy, and could be again. For example the current
4GB/week limit was formerly 1GB/week by consensus, but prior to that was
250MB, 350MB and 750MB by miners sticking with core's default mining
policy.

I don't think core changing the default alone would have any effect there,
but if there were good reasons to reduce that number, then discussing
those reasons with miners, including how they would benefit as a result,
seems to me like it would have a good chance of working out, even without
consensus changes. (At present, I don't think there are good reasons
for such a reduction)

> Consensus rules have force even when some miners or even ~all miners don'=
t
> agree.  So they do not have the problem that they're mooted when some min=
er
> eschews them.
>
> The ones that aren't could be justified or refuted on their own merits bu=
t
> *regardless* of what anyone thinks of them, so long as they're policy the=
y
> are moot if some miners ignore them. And that remains the case unless
> they're turned into consensus rules.

Not every policy needs 100% enforcement to have a meaningful effect. For
example, if 99.9% of miners mine 250kB blocks, and 0.1% of miners mine
4MB blocks, that still limits the block size to 256kB on average.

This might be a rational/incentive-compatible policy for all of those
miners, if fees are a large component of block reward, and the capacity
constraint pushes the average fee paid by transactions up by more than 4x,
and the majority of miners are either taking a long term view themselves
or are in a large pool with signficant constraints on exit.

> There are some like lowS rule in legacy transactions which was always
> intended to become a consensus rule, but just hasn't due to low importanc=
e
> while it's not being broken by miners and due to general dysfunction in
> updating consensus rules which has allowed vulnerabilities in the consens=
us
> protocol to remain for years.

The lowS rule was part of BIP 62 (dealing with malleability) which was
withdrawn around the time segwit was proposed. Part of it was re-proposed
by Matt as part of the Great Consensus Cleanup (push-only scriptSig),
but that wasn't one of them. I wasn't aware there was any particular
interest/need in upgrading lowS to a consensus rule, for instance.

In any event, the "general dysfunction in updating consensus rules"
largely takes the form of "I don't have confidence that we'll be able to
get consensus to agree to this change, which after all, isn't strictly
necessary". That's why the current BIP 54 doesn't include a restriction
on push-only scriptSig, eg -- disabling it isn't strictly necessary to
avoid the DoS attacks that we know about.

But if we aren't able to have the confidence to make standardness rules
more restrictive, I don't see why we should have any expectation of ever
cleaning things up in consensus: if a standardness change is adopted
by the network, it's still possible to get exceptions through in cases
where someone would have lost funds even if it requires paying exhorbitant
fees to a miner to special case your transaction; for a consensus change,
even that's not possible.

> > * encouraging data storage people to use commitments (7) didn't really
> >   work, and given that could be done via documentation or blog posts
> Oh I dunno about that, I've seen first hand quite a few discussions that
> basically went,  "I want magical free file storage!" "It doesn't provide
> that, you can have a commitment to prove your file existed, and that
> doesn't require stuffing the whole file in" "oh but I don't really want a
> commitment, I guess this doesn't do the thing I wanted".

(If you prefer, replace "didn't really work" with "worked for a time,
but that time has passed")

The key argument against using bitcoin for "magical free file storage"
is that it isn't free, or even as cheap as just paying for storage on
S3, not that you have to do ridiculous encoding tricks when your file
size passes various thresholds. In any event, those encoding tricks
have already been standardised and publicised, so I'd expect that the
normal response today to "it doesn't provide that" is "actually it does,
see <url>".

Alternatively, if you believe there's still some potential there, we
could perhaps resurrect ideas like restricting the OP_RETURN pushdata
[2], perhaps to at most 80-bytes (same as now, just allow more of them),
256-bytes (ie, anything that only needs PUSHDATA1), 520-bytes (matching
inscription chunking forced by MAX_SCRIPT_ELEMENT_SIZE), or 4096-bytes
(matching how much data you could stuff contiguously in a taproot control
block via fake merkle leaves).

[2] https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-65671770

> > * 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 (6)

> >   or prefering prunable data (2):

> Well there I don't follow, you flip a switch and then operating a full no=
de
> goes from requiring a terabyte to requiring 30GB.  This is quite importan=
t
> and absolutely makes a difference in ability to run a node.

That's because you somehow tore up my quote and dropped the "rather
than". In full, I wrote:

> > * 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):

that is, "they should be concerned with [the capacity limit], rather
than being concerned with [the witness discount and other things]". So
I don't think we're disagreeing.

> Even if they're asking for a punch in the face because click-baiters on
> youtube convince them it would cure their cancer?  I'd rather tell them n=
o
> thanks, get your punch elsewhere if you're that convinced.  (also, have y=
ou
> not punched someone? it hurts!)

I think a lot of people won't be convinced something's stupid until
they've actually tried doing the stupid things themselves, and found it
really doesn't work. For that example, if getting punched in the face now
lets them go get tested to prove/disprove their theory, and, assuming the
punch in the face didn't work, go move on to a real treatment ASAP, then
if it was someone I cared even slightly about, I'd probably be willing
to deal with some hand pain, yes. Hopefully the youtube conspiracy allows
you to wear a boxing glove, though.

> > 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 tha=
t
> > gives them at least a chance to continue the fight for sometime longer.
> But better still to help them be effectual on it!

For me, saying "sorry, this has reached a threshold of popularity, you
have to give up and accept it now" makes me want to oppose it just as a
knee-jerk reaction, even things I otherwise think of as a good idea. I
expect the contrapositive "sorry, your idea isn't popular enough,
you have to give up on it" likewise gets a knee jerk rejection from
many bitcoiners.

For me, arguments of the form "this is actually good for bitcoin because
..." are much more helpful than "sorry, a minority of miners have already
decided this is okay, therefore your opinions just don't matter".

Cheers,
aj

--=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/=
aBiCgRIRikR0MPei%40erisian.com.au.