From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ) 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 To: Greg Maxwell Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions Message-ID: References: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 ". 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.