path: root/15/be4e5c21b84deb840a294478930c3c53636b80

Delivery-date: Fri, 02 May 2025 12:11:06 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCJNLJPWXAIBBP5R2TAAMGQEPFPZFHI@googlegroups.com>)
	id 1uAvmq-0001JL-Kt
	for bitcoindev@gnusha.org; Fri, 02 May 2025 12:11:06 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e75608f7ddcsf1968320276.3
        for <bitcoindev@gnusha.org>; Fri, 02 May 2025 12:11:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746213059; x=1746817859; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=e8geLSqhwtL8LSjO+0NeBjOs0Hq6oz/fH9P3PKGH/L4=;
        b=hANZSp2A4auijGZB1kcWef9oDL3PkI1I+BZM8iL1DdVogLbHrYYpgtvAE1ebtOSVx6
         VOyUXCE29uY9/7gNDqh72HQT7AkGsXHNcLJS8sb/8dG/JIVacRphzTVtGMHusMxItLp4
         Jao45czKwaVvVOLWS5RiXXucSuKoPqYYtOckzTJRtpa0t4NhNWrGVAJwc7MxvsxH4+jI
         mFVmMv/KDLEFBoztKrxmyk/Ng9/AQaYX/VBfqMZT7nshP2vD8pFI33qx+lfWcxZJBVUn
         KTpe8Mg3xRSv8PcilDbvSfpJZwgoOMWyTndA3jy0Lp9wNZPLrFzerCuMA8aZO6enpfcQ
         ZU/Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746213059; x=1746817859; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=e8geLSqhwtL8LSjO+0NeBjOs0Hq6oz/fH9P3PKGH/L4=;
        b=U9BTUUDgzYYhkdqwTwV6T/rnGL2pLbvVxK7rrQKvVwPYg22sn4s3laofi2O0iWJUIc
         j0Ld9J0qlkb8spLGSNfYy/xnIP6RUvr1308F0sDcpMLYV82BQS9pJ+jT8AIc5nMc1LP8
         Txq1ygw7CPBCSEwzq7Y81x18fpryudw2wph+RAYlqM5Jo3is2miou5/nUAUUk7xqcj6p
         Isyk6UPLIGjMyWZ2BgHiM/e0ywUBR40WnePJwc+na/jg4v/NdjrOGvv301WeZ6dTjXke
         XOlcgaAHRCKufqZtfEGPptxd+HtbJdutWac4r38yDia5P697idDv8xJWsFSe9wbIngr7
         AbCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746213059; x=1746817859;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=e8geLSqhwtL8LSjO+0NeBjOs0Hq6oz/fH9P3PKGH/L4=;
        b=VhLrWoXHlwHeHqVzVx6opMmaAb0wreLp44WlsbW56AapDfRrMq0vUtqjcxB0gBeeMF
         MOgaWgOCeLk45l/GD1BE9ZloSvhBwS7P4Z2le3T5kmVniMhPWSQ4nIfal0+PQLKPD8GW
         qn+jrxAhMKcwrv0XfZFmi1EoPb42hS0F+y0UTWbfwC/8pRd3EDzhndpNH+NqV3AXNMQ3
         h+WtcwohYcAzaBYQY149Jsr2byshBkVJv/1cbcPsfU7d+N4Gs1VK51Oqekx+tlF7dU/C
         J//XolI4be4vNJK7Js4fhgEamp1M5sqQsCUhyl+a1lp/cHuFeIBFaY8f9wXXSp6Xer57
         x2+w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCW0Kt3XKKjCZ47ducSWL55MVALHJIXXUF99pEvoEllmY8EhwrCrhTUkurPuVC+R3sviT8AIcOJrg7LH@gnusha.org
X-Gm-Message-State: AOJu0YxEb+MGh/wvtwwceO373sKifnljHYZdTLoshw//Ful9zpr2SOTF
	YEcgSRDBUFnf5ykQP20y7hBCg6SYKfQ1cUS9FiX9Xwp524//znxB
X-Google-Smtp-Source: AGHT+IHQqX5YbMvD6SnU9wzBDHVKa8NV+0BGNwp+MgpawR2+U+3amnRvmTenvJ0J/siWBlLf+bNJyg==
X-Received: by 2002:a05:6902:218a:b0:e73:17e3:ef4e with SMTP id 3f1490d57ef6-e756566eab5mr5253215276.48.1746213058854;
        Fri, 02 May 2025 12:10:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHGaAPwJGNC9ux3UFcM876mikdKz842uA1KK97jrATjRg==
Received: by 2002:a25:b225:0:b0:e72:6a60:9f92 with SMTP id 3f1490d57ef6-e74d9694c86ls615693276.0.-pod-prod-01-us;
 Fri, 02 May 2025 12:10:55 -0700 (PDT)
X-Received: by 2002:a05:690c:3802:b0:702:591a:6958 with SMTP id 00721157ae682-708cf171460mr59676617b3.22.1746213055631;
        Fri, 02 May 2025 12:10:55 -0700 (PDT)
Received: by 2002:a05:690c:a10:b0:708:1ea1:3cd5 with SMTP id 00721157ae682-708cfde0f15ms7b3;
        Fri, 2 May 2025 10:36:46 -0700 (PDT)
X-Received: by 2002:a05:690c:4c04:b0:702:46ca:dc7b with SMTP id 00721157ae682-708cf03e25amr58974287b3.16.1746207405289;
        Fri, 02 May 2025 10:36:45 -0700 (PDT)
Date: Fri, 2 May 2025 10:36:44 -0700 (PDT)
From: Greg Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn@googlegroups.com>
In-Reply-To: <aBSVn7nJnrheLy5Z@erisian.com.au>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com>
 <aBSVn7nJnrheLy5Z@erisian.com.au>
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_84814_783201163.1746207404718"
X-Original-Sender: gmaxwell@gmail.com
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.5 (/)

------=_Part_84814_783201163.1746207404718
Content-Type: multipart/alternative; 
	boundary="----=_Part_84815_1930331065.1746207404718"

------=_Part_84815_1930331065.1746207404718
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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,=20
it prevents ever making relay rules more restrictive, even for cases=20
which are provably harmful for the network.=20


Not so, deploy the restriction to mining behavior first.  The fact that it=
=20
classically hasn't been separately configurable is an artifact of assuming=
=20
that it's the same (and acknowledging that it needs to be!).

Though even if were true, it's not clear to me that reductions in=20
permissiveness are particularly interesting.  It's not a one way valve, but=
=20
kinda.  At least historically the community hasn't considered it=20
particularly appropriate to restrict already accepted transactions,  this=
=20
is affirmed when we look at the counter examples.

Consider High-S signatures.  There were active attacks this blocked, and=20
yet it was still important to the discussion that third parties could run=
=20
code to automatically convert users High-S signatures to low-S, and then=20
people *did* run nodes that did precisely that for a long time.

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

And it will be critical for any proposal that violates the general=20
principle to explain why it's reasonable to do so.  I mean they should=20
already, because I think it's a good criteria an it's still a good one even=
=20
if no project has said outright that they intend to follow it! :)  So for=
=20
example, if it's violated as part of a credible transition to a new state=
=20
where the behavior is again consistent then fine.

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


Alternatively, if it's a rule with exceptions, then it's those exceptions=
=20
that are the important factor and should be figured out.=20


Exactly.
=20

For example, the reason mining a "quadratic hashing bloat txn" is bad=20
because it causes delayed block validation on its own, potentially in=20
ways that aren't even sufficiently mitigated by running your node on=20
extremely high end hardware. Transactions like that should really be=20
removed from consensus validity not just prevented at the relay level,=20
and BIP 54's consensus cleanup hopefully does that.=20


Indeed.  When I considered this idea the examples I could come up where=20
you'd really want to violated it were mostly ones where the consensus rule=
=20
really needed to be fixed.

=20

Miners have accepted out-of-band relay of spends of unknown=20
segwit versions (which I presume is similar enough to the "unused=20
opcode/successcode/version number or whatever" case), in particular=20
txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41=20
in block 692261 (the taproot exception block). Even though that was not=20
done by mistake or out of technical ignorance, I think doing such things=20
extremely rarely through out of band mechanisms is pretty much fine.=20
(Even if miners do it for profit, rather than as a 0-fee tx where the=20
outputs are a donation to a developer funding group)=20


Indeed, I don't think one-offs have any relevance to the idea I'm=20
suggesting.

If adopted, a policy like that would be fairly easy to use to hold the=20
network hostage: find a miner who doesn't much care and has perhaps=20
0.1% of total hashrate, get them to mine txs spending segwit versions 2=20
through 16, and forward a handful of such transactions to them every day.=
=20
The transactions are getting mined regularly and reliably (at a rate=20
of about once a week), the transactions aren't immediately damaging the=20
network, the miner is making excess profits, and by your relay argument,=20
the miner is gaining a slight advantage in being able to potentially=20
mine two blocks in a row due to the block relay delays caused by not=20
relaying spends of future segwit versions.=20



I don't follow: If someone is doing that then the version numbers are toast=
=20
for forward compatibility use. It doesn't matter what relay does, they're=
=20
already toast.  The choice you have at that point is to allow their=20
non-standard transactions to have collateral harm or not.

Forward compatibility is fragile like that.  In a world where miners were=
=20
behaving adversarial to the network in such a manner additions to consensus=
=20
rules would just cause short lived consensus forks w/ associated disruption=
.

One could, of course, adopt a revised form of my statement that exempts=20
forward compatibility.   I kinda feel like this is missing the point a bit,=
=20
but OTOH, one could switch to allowing them once it was clear that=20
filtering them wasn't providing any value anymore.

I'd describe that class of policy as something of a "popularity contest"=20
approach -- it's a policy that says that anything that's sufficiently=20
popular is good/permissable. I think that makes sense as a check/balance=20
approach -- "this think is popular, is there really a good reason why=20
it's not permitted?" -- but not as the first thing we think about.=20


Mining *policy* is inherently a popularity contest, particularly for=20
restrictions since they don't work unless ~everyone does them.  They will=
=20
always be vulnerable to someone convincing miners to ignore them.  Covering=
=20
our ears and eyes w/ relay policy doesn't change that!

When a fragile tool is the best tool we have ... it's still the best tool=
=20
and we should enjoy its benefits when we can.  But when it doesn't work=20
anymore we shouldn't delusionally pine for the old days when it did at a=20
cost of creating relay/mining inconsistency.

I'm not speaking in favor of popularity contests but rather in favor of=20
acknowledging reality.

As a check/balance, I think that argument holds water, and should cause=20
us to ask if your existing policies make sense. I think it's fair to=20
say Bitcoin Core's existing policies (as expressed by its code, and not=20
necessarily matching the policies of various forks of Core) are (in no=20
particular order):=20


A number of your examples are consensus rules, not relay policy.  That is=
=20
an entirely different kettle of fish.=20

Consensus rules have force even when some miners or even ~all miners don't=
=20
agree.  So they do not have the problem that they're mooted when some miner=
=20
eschews them.

The ones that aren't could be justified or refuted on their own merits but=
=20
*regardless* of what anyone thinks of them, so long as they're policy they=
=20
are moot if some miners ignore them. And that remains the case unless=20
they're turned into consensus rules.
... and for most of them making them consensus rules has been considered=20
and rejected.

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

* encouraging data storage people to use commitments (7) didn't really=20
work, and given that could be done via documentation or blog posts=20


Oh I dunno about that, I've seen first hand quite a few discussions that=20
basically went,  "I want magical free file storage!" "It doesn't provide=20
that, you can have a commitment to prove your file existed, and that=20
doesn't require stuffing the whole file in" "oh but I don't really want a=
=20
commitment, I guess this doesn't do the thing I wanted".

* people with legitimate concerns about their node being overloaded=20
should probably be concerned more by the "limit maximum block size=20
growth to ~4GB/week" policy


Yes, that's what the capacity limit is for.

=20

 (6) or prefering prunable data (2):=20


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

* one is that for that to only be "occassional" means that even=20
vaguely legitimate use cases should have a supported way of=20
being exercised via standard transactions without being much more=20
expensive: eg, instead of consolidating 4000 transactions in a=20
270kvB transaction, you might use consolidate 1333 transactions=20
in each of three 91kvB transactions. That limits the amount of=20
excess profits the miner can generate, in this example the 3kvB=20
of savings would only justify paying about 1.1% higher than the=20
going feerate for standard transactions, eg.=20

* the other is that if you want to disallow this from happening=20
even occassionally, then you want to have relay and consensus rules=20
be the same; but that effectively means that any functionality=20
upgrade needs to be done as a hard fork, which in turn likely has=20
highly centralising effects around the developer team, as running=20
old versions of the software becomes infeasible=20


Right, my view is that one-offs aren't an issue. Relay policy can differ=20
from mining policy for one-offs.  If that weren't my view then I would say=
=20
that there should be no relay policy at all, anything consensus valid=20
should relay.

And you hit on basically the primary example of why relay policy exists--=
=20
because some rules would be overly restrictive as consensus rules.

I don't agree with that at all: giving people what they ask for, even=20
if it's literally a punch in the face, isn't disrespectful, it's the=20
opposite. (Respecting other people isn't always the highest virtue,=20
of course)=20


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

Even if they're fundamentally wrong, I think it's respectful to people who=
=20
haven't yet given that up as a lost cause to leave them with a knob that=20
gives them at least a chance to continue the fight for sometime longer.=20


But better still to help them be effectual on it!


=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/=
0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn%40googlegroups.com.

------=_Part_84815_1930331065.1746207404718
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">On Friday, May 2, 2025 at 10:33:18=E2=80=AFAM UTC An=
thony Towns wrote:<br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hmm, I do=
n't actually think this is a good rule -- if followed strictly,
<br />it prevents ever making relay rules more restrictive, even for cases
<br />which are provably harmful for the network.
<br /></blockquote><div><br /></div><div>Not so, deploy the restriction to =
mining behavior first.=C2=A0 The fact that it classically hasn't been separ=
ately configurable is an artifact of assuming that it's the same (and ackno=
wledging that it needs to be!).</div><div><br /></div><div>Though even if w=
ere true, it's not clear to me that reductions in permissiveness are partic=
ularly interesting.=C2=A0 It's not a one way valve, but kinda.=C2=A0 At lea=
st historically the community hasn't considered it particularly appropriate=
 to restrict already accepted transactions,=C2=A0 this is affirmed when we =
look at the counter examples.</div><div><br /></div><div>Consider High-S si=
gnatures.=C2=A0 There were active attacks this blocked, and yet it was stil=
l important to the discussion that third parties could run code to automati=
cally convert users High-S signatures to low-S, and then people *did* run n=
odes that did precisely that for a long time.</div><div><br /></div><div>So=
 I would say that reductions in relay permissiveness are uncommon and excep=
tional, and if they happen at all will be on some case by case basis and ju=
stification and so the general principal need not apply.</div><div><br /></=
div><div>And it will be critical for any proposal that violates the general=
 principle to explain why it's reasonable to do so.=C2=A0 I mean they shoul=
d already, because I think it's a good criteria an it's still a good one ev=
en if no project has said outright that they intend to follow it! :)=C2=A0 =
So for example, if it's violated as part of a credible transition to a new =
state where the behavior is again consistent then fine.</div><div><br /></d=
iv><div>My view is that a principle like this is an objective, not an exact=
 edict.=C2=A0=C2=A0 "Here is what we're trying to accomplish".=C2=A0 And th=
at absolutely can get overridden by circumstance specific exceptions. <br /=
></div><div><br /></div><div><br /></div><blockquote style=3D"margin: 0px 0=
px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">Alternatively, if it's a rule with exceptions, then it's those exceptions
<br />that are the important factor and should be figured out.
<br /></blockquote><div><br /></div><div>Exactly.</div><div>=C2=A0</div><bl=
ockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;">For example, the reason mining a "quadrati=
c hashing bloat txn" is bad
<br />because it causes delayed block validation on its own, potentially in
<br />ways that aren't even sufficiently mitigated by running your node on
<br />extremely high end hardware. Transactions like that should really be
<br />removed from consensus validity not just prevented at the relay level=
,
<br />and BIP 54's consensus cleanup hopefully does that.
<br /></blockquote><div><br /></div><div>Indeed.=C2=A0 When I considered th=
is idea the examples I could come up where you'd really want to violated it=
 were mostly ones where the consensus rule really needed to be fixed.</div>=
<div><br /></div><div>=C2=A0</div><blockquote style=3D"margin: 0px 0px 0px =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Miner=
s have accepted out-of-band relay of spends of unknown
<br />segwit versions (which I presume is similar enough to the "unused
<br />opcode/successcode/version number or whatever" case), in particular
<br />txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41
<br />in block 692261 (the taproot exception block). Even though that was n=
ot
<br />done by mistake or out of technical ignorance, I think doing such thi=
ngs
<br />extremely rarely through out of band mechanisms is pretty much fine.
<br />(Even if miners do it for profit, rather than as a 0-fee tx where the
<br />outputs are a donation to a developer funding group)
<br /></blockquote><div><br /></div><div>Indeed, I don't think one-offs hav=
e any relevance to the idea I'm suggesting.</div><div><br /></div><blockquo=
te style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204,=
 204); padding-left: 1ex;">If adopted, a policy like that would be fairly e=
asy to use to hold the
<br />network hostage: find a miner who doesn't much care and has perhaps
<br />0.1% of total hashrate, get them to mine txs spending segwit versions=
 2
<br />through 16, and forward a handful of such transactions to them every =
day.
<br />The transactions are getting mined regularly and reliably (at a rate
<br />of about once a week), the transactions aren't immediately damaging t=
he
<br />network, the miner is making excess profits, and by your relay argume=
nt,
<br />the miner is gaining a slight advantage in being able to potentially
<br />mine two blocks in a row due to the block relay delays caused by not
<br />relaying spends of future segwit versions.
<br /></blockquote><div><br /></div><div><br /></div><div>I don't follow: I=
f someone is doing that then the version numbers are toast for forward comp=
atibility use. It doesn't matter what relay does, they're already toast.=C2=
=A0 The choice you have at that point is to allow their non-standard transa=
ctions to have collateral harm or not.</div><div><br /></div><div>Forward c=
ompatibility is fragile like that.=C2=A0 In a world where miners were behav=
ing adversarial to the network in such a manner additions to consensus rule=
s would just cause short lived consensus forks w/ associated disruption.</d=
iv><div><br /></div><div>One could, of course, adopt a revised form of my s=
tatement that exempts forward compatibility.=C2=A0=C2=A0 I kinda feel like =
this is missing the point a bit, but OTOH, one could switch to allowing the=
m once it was clear that filtering them wasn't providing any value anymore.=
</div><div><br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I'd describe tha=
t class of policy as something of a "popularity contest"
<br />approach -- it's a policy that says that anything that's sufficiently
<br />popular is good/permissable. I think that makes sense as a check/bala=
nce
<br />approach -- "this think is popular, is there really a good reason why
<br />it's not permitted?" -- but not as the first thing we think about.
<br /></blockquote><div><br /></div><div>Mining *policy* is inherently a po=
pularity contest, particularly for restrictions since they don't work unles=
s ~everyone does them.=C2=A0 They will always be vulnerable to someone conv=
incing miners to ignore them.=C2=A0 Covering our ears and eyes w/ relay pol=
icy doesn't change that!</div><div><br /></div><div>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.=C2=A0 But when it doesn't work anymore we shouldn't d=
elusionally pine for the old days when it did at a cost of creating relay/m=
ining inconsistency.</div><div><br /></div><div>I'm not speaking in favor o=
f popularity contests but rather in favor of acknowledging reality.</div><d=
iv><br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left:=
 1px solid rgb(204, 204, 204); padding-left: 1ex;">As a check/balance, I th=
ink that argument holds water, and should cause
<br />us to ask if your existing policies make sense. I think it's fair to
<br />say Bitcoin Core's existing policies (as expressed by its code, and n=
ot
<br />necessarily matching the policies of various forks of Core) are (in n=
o
<br />particular order):
<br /></blockquote><div><br /></div><div>A number of your examples are cons=
ensus rules, not relay policy.=C2=A0 That is an entirely different kettle o=
f fish. <br /></div><div><br /></div><div>Consensus rules have force even w=
hen some miners or even ~all miners don't agree.=C2=A0 So they do not have =
the problem that they're mooted when some miner eschews them.</div><div><br=
 /></div><div>The ones that aren't could be justified or refuted on their o=
wn merits but *regardless* of what anyone thinks of them, so long as they'r=
e policy they are moot if some miners ignore them. And that remains the cas=
e unless they're turned into consensus rules.</div><div>... and for most of=
 them making them consensus rules has been considered and rejected.</div><d=
iv><br /></div><div>There are some like lowS rule in legacy transactions wh=
ich was always intended to become a consensus rule, but just hasn't due to =
low importance while it's not being broken by miners and due to general dys=
function in updating consensus rules which has allowed vulnerabilities in t=
he consensus protocol to remain for years.</div><div><br /></div><blockquot=
e style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;">* encouraging data storage people to use commitme=
nts (7) didn't really
<br />   work, and given that could be done via documentation or blog posts
<br />   </blockquote><div><br /></div><div>Oh I dunno about that, I've see=
n first hand quite a few discussions that basically went,=C2=A0 "I want mag=
ical free file storage!" "It doesn't provide that, you can have a commitmen=
t to prove your file existed, and that doesn't require stuffing the whole f=
ile in" "oh but I don't really want a commitment, I guess this doesn't do t=
he thing I wanted".</div><div><br /></div><blockquote style=3D"margin: 0px =
0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex=
;">* people with legitimate concerns about their node being overloaded
<br />   should probably be concerned more by the "limit maximum block size
<br />   growth to ~4GB/week" policy</blockquote><div><br /></div><div>Yes,=
 that's what the capacity limit is for.</div><div><br /></div><div>=C2=A0</=
div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;">=C2=A0(6) or prefering prunable dat=
a (2):=C2=A0</blockquote><div><br /></div><div>Well there I don't follow, y=
ou flip a switch and then operating a full node goes from requiring a terab=
yte to requiring 30GB.=C2=A0 This is quite important and absolutely makes a=
 difference in ability to run a node.</div><div><br /></div><blockquote sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;">* one is that for that to only be "occassional" means =
that even
<br />      vaguely legitimate use cases should have a supported way of
<br />      being exercised via standard transactions without being much mo=
re
<br />      expensive: eg, instead of consolidating 4000 transactions in a
<br />      270kvB transaction, you might use consolidate 1333 transactions
<br />      in each of three 91kvB transactions. That limits the amount of
<br />      excess profits the miner can generate, in this example the 3kvB
<br />      of savings would only justify paying about 1.1% higher than the
<br />      going feerate for standard transactions, eg.
<br />
<br />    * the other is that if you want to disallow this from happening
<br />      even occassionally, then you want to have relay and consensus r=
ules
<br />      be the same; but that effectively means that any functionality
<br />      upgrade needs to be done as a hard fork, which in turn likely h=
as
<br />      highly centralising effects around the developer team, as runni=
ng
<br />      old versions of the software becomes infeasible
<br /></blockquote><div><br /></div><div>Right, my view is that one-offs ar=
en't an issue. Relay policy can differ from mining policy for one-offs.=C2=
=A0 If that weren't my view then I would say that there should be no relay =
policy at all, anything consensus valid should relay.</div><div><br /></div=
><div>And you hit on basically the primary example of why relay policy exis=
ts-- because some rules would be overly restrictive as consensus rules.</di=
v><div><br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I don't agree with t=
hat at all: giving people what they ask for, even
<br />if it's literally a punch in the face, isn't disrespectful, it's the
<br />opposite. (Respecting other people isn't always the highest virtue,
<br />of course)
<br /></blockquote><div><br /></div><div>Even if they're asking for a punch=
 in the face because click-baiters on youtube convince them it would cure t=
heir cancer?=C2=A0 I'd rather tell them no thanks, get your punch elsewhere=
 if you're that convinced.=C2=A0 (also, have you not punched someone? it hu=
rts!)</div><div>=C2=A0</div><div>But your point is received.</div><div><br =
/></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px so=
lid rgb(204, 204, 204); padding-left: 1ex;">Even if they're fundamentally w=
rong, I think it's respectful to people who
<br />haven't yet given that up as a lost cause to leave them with a knob t=
hat
<br />gives them at least a chance to continue the fight for sometime longe=
r.
<br /></blockquote><div><br /></div><div>But better still to help them be e=
ffectual on it!</div><div><br /></div><div><br /></div><div>=C2=A0</div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn%40googlegroups.com</a>.<br />

------=_Part_84815_1930331065.1746207404718--

------=_Part_84814_783201163.1746207404718--