From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn@googlegroups.com> In-Reply-To: References: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
On Friday, May 2, 2025 at 10:33:18=E2=80=AFAM UTC An= thony Towns wrote:
Hmm, I do= n'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.

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!).

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.

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.

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.

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.

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.


For example, the reason mining a "quadrati= c 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.

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

=C2=A0
Miner= s 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 n= ot
done by mistake or out of technical ignorance, I think doing such thi= ngs
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 hav= e any relevance to the idea I'm suggesting.

If adopted, a policy like that would be fairly e= asy 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 t= he
network, the miner is making excess profits, and by your relay argume= nt,
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.


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.

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.

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

I'd describe tha= t 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/bala= nce
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.

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!

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.

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

As a check/balance, I th= ink 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 n= ot
necessarily matching the policies of various forks of Core) are (in n= o
particular order):

A number of your examples are cons= ensus rules, not relay policy.=C2=A0 That is an entirely different kettle o= f fish.

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.
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.
... and for most of= them making them consensus rules has been considered and rejected.

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.

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

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".

* 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

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

=C2=A0
=C2=A0(6) or prefering prunable dat= a (2):=C2=A0

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.

* 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 mo= re
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 r= ules
be the same; but that effectively means that any functionality
upgrade needs to be done as a hard fork, which in turn likely h= as
highly centralising effects around the developer team, as runni= ng
old versions of the software becomes infeasible

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.

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

I don't agree with t= hat 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)

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!)
=C2=A0
But your point is received.

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

But better still to help them be e= ffectual on it!


=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn%40googlegroups.com.
------=_Part_84815_1930331065.1746207404718-- ------=_Part_84814_783201163.1746207404718--