path: root/81/b5cfbc9513f41574423287f1e8f6ce56bb0a60

Delivery-date: Mon, 05 May 2025 07:12:16 -0700
Received: from mail-yb1-f191.google.com ([209.85.219.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCJNLJPWXAIBBNMO4PAAMGQEX45TY5Y@googlegroups.com>)
	id 1uBwYJ-00032F-I2
	for bitcoindev@gnusha.org; Mon, 05 May 2025 07:12:16 -0700
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e73305b651bsf1691997276.1
        for <bitcoindev@gnusha.org>; Mon, 05 May 2025 07:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746454329; x=1747059129; 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=JBeSwfMUin8+WM18A3LmkZ0VKt2mguj9rl01E6jxH/E=;
        b=GVGfPM0cUZPButs+V1zqysyWjqSGbnXXHlZOnWRsAzgCaGE+l+TYknAnXOKaWFXsl+
         obE9XrCgxMh5S35rqCNMZouS3pT3h9Tva+IbiykhYnKhRxy+5SlXPWzeSQj5fX+vsQLG
         OSi/9KI3pJeQ59vnmdJpmmGE5IrqLXLmkXmvnkk1fm38GyQnLOHzVEXBurzvInabjAWF
         suds0sJ0TkxGA7O0PDr2Gu8KvtW4PuuGj5fxNn7Zbr4U+qLDpZ6Jx/cpal2xmLC8plxW
         6qFHKlbQCLHu/m5hEgm5pHC3Kt+64nxp+w4P/D36tUc9bA9CYQLP2B1mCwWj2/IrJGq7
         x6wA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746454329; x=1747059129; 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=JBeSwfMUin8+WM18A3LmkZ0VKt2mguj9rl01E6jxH/E=;
        b=P+aDMxsjxV6rsSgR42yfDNLiepm0jiSMOaGFNuJUKYroBgE32YTCQKdIbOqyn0Zc78
         stm5QoHSMBdAg15JOamKRxdiwL19BciyVarmYopuAfLPQ+cIbY3xJqP8Z46HZLpU5Mbn
         BhOSw9hMa1p6YaK3/Y2D/0nhNxZc3IrvmbjDAmwpBlmmP6rqhw0QlWsxrzFb9YHWO66E
         WLm2Tnt67dO9oloz9wr9LZ47BXPiUHqnu/8QAMhD5Rr/vE3LqyaspEKxrQof8WA6cIgq
         LiJdeUyLMi5nkiDeSFuS7BUXtEw26jFZITovtcfHwUZ58KNBPd6BpL+U0Q0vwqGbawN/
         ppKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746454329; x=1747059129;
        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=JBeSwfMUin8+WM18A3LmkZ0VKt2mguj9rl01E6jxH/E=;
        b=X36qBf9uL61VMqI7DW7w2OndU82EQY06SZE4X0xrdnqwQxpAtDUJKLHZVyNyU9c8Mn
         Xrq06+vBQCCyP7LPmhp48f3HipgorDVgaB1XyxugxhttGOX4ykmN2LPDytJXtaGVj2k4
         Xl0+bXzBCRsCEnT5YFmaEOGhqbhSGcUvxyDt00Lpq8VZx+Uf4w2lhP7gTwDcTfIKj4Am
         6wJpo8mQ7UnKBkzUnY9oXckTsitFSTwdsdf66URhZvaGmzev1y4vXQ7V2ef2hHHA41e1
         O+Y82VFKszfNLQl+8FOh1yFdiaj4yiBLXd2RjetdwprerwlIzittaTPhOVOAvXvLZRdb
         UxNA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVreXgI5T0q5U8z33D93Rt6ll9va8M78GANOb5q7Rp6AluYZVaZ7P7PyeG6tow0nF9rR41z/oJYANDg@gnusha.org
X-Gm-Message-State: AOJu0YwnRXm+t5mREwSynXSzjK4RVJo1EbXA+oMcdGqSDWdAuvRWrTJF
	ZbO4PQqmw6ehVqKRk6o9KifUtjMlma+xKG/oO/7Ij+24kYs1Frgj
X-Google-Smtp-Source: AGHT+IF2A3hS3cKqj9jZYZh56L5Dug7rWYWKqfhB+ldZpoLXHAmZZTS/SkuHaT9JO+BNNN8oDtUUPw==
X-Received: by 2002:a05:6902:2508:b0:e73:2a10:3ea4 with SMTP id 3f1490d57ef6-e7571a126d9mr9927205276.4.1746454328580;
        Mon, 05 May 2025 07:12:08 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHXSEXaPqbXuaxLUSzlQMT4hcDNKfGwJdqsdBywRlvauA==
Received: by 2002:a25:2941:0:b0:e74:29b5:5ab2 with SMTP id 3f1490d57ef6-e74dc1e6bf5ls513676276.1.-pod-prod-03-us;
 Mon, 05 May 2025 07:12:04 -0700 (PDT)
X-Received: by 2002:a05:690c:6383:b0:6fb:b2de:a2c3 with SMTP id 00721157ae682-708e11b5ec0mr100834057b3.9.1746454324629;
        Mon, 05 May 2025 07:12:04 -0700 (PDT)
Received: by 2002:a05:690c:a10:b0:708:1ea1:3cd5 with SMTP id 00721157ae682-708cfde0f16ms7b3;
        Mon, 5 May 2025 07:05:04 -0700 (PDT)
X-Received: by 2002:a05:690c:7205:b0:6fd:a226:fb2b with SMTP id 00721157ae682-708e119b2abmr118574177b3.3.1746453903257;
        Mon, 05 May 2025 07:05:03 -0700 (PDT)
Date: Mon, 5 May 2025 07:05:02 -0700 (PDT)
From: Greg Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <8cb5c012-e28a-466d-b444-9083bf1a486cn@googlegroups.com>
In-Reply-To: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_336784_1058258725.1746453902653"
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_336784_1058258725.1746453902653
Content-Type: multipart/alternative; 
	boundary="----=_Part_336785_1725370454.1746453902653"

------=_Part_336785_1725370454.1746453902653
Content-Type: text/plain; charset="UTF-8"

It might be helpful to reflect on how reality has changed since the 
OP_RETURN behavior was originally rolled out in February 2014.

At the time blockfile pruning would not be deployed to the public for 
another year and a half,  so everyone that ran a node was forced to store 
and serve anything that made it into a block.

In 2014 people were proposing protocol additions that would allow basically 
random access to the transactions/txouts over the P2P network, potentially 
outright allowing file trading applications that abused bitcoin nodes as 
their server.  Today there are no such proposals and any would be DOA 
because the abuse potential is well understood.

At the time miners were almost entirely driven by subsidy, fees were fairly 
insignificant.

With the exception of a rare joker block standardness rules were highly 
effective, and short of mining a block yourself or talking a highly 
community connected mining pool operator into it  (or being that operator) 
you couldn't bypass any of them.

Blocks were on average running at 16% of the consensus capacity limit.  
Absent some kind of adhoc non-consensus restriction the cost to dump in 
large amounts of data would have been nothing.  Today the _average_ block 
is essentially full and the costs are considerable.

A minimum feerate of 1s/vb has increased in buying power by a factor of 171 
from Feb 2014 to now.

Users were much more ignorant about what they got out of putting data in, 
it was common to hear things that would better be served with a commitment 
(or something like OTS, which wouldn't be available for another two and a 
half)-- they didn't have much reason to think hard about their application 
because stuffing in data was cheap (or, even free if not for limits).  
Today's data stuffers cases generally do make sense on their own terms even 
if many would agree that they're not an appropriate use of Bitcoin.  There 
are more alternative communications channels than ever now, ipfs, nostr, 
other blockchains.  Stuffing data in is expensive. Those who still do it 
are willing to pay, which also means miners are willing to let them. The 
parties that do it are technically sophisticated or at the very least can 
afford the services of people who are and can and have implemented evasions 
to adhoc restrictions.

Today there are implementations of concepts like assumeutxo, which while 
subject to their own limitations would allow people to bring up fully 
validating nodes without ever downloading or processing spam data (and 
pruining as mentioned is real now and lets you not store it).  While not 
yet completed and deployed it clearly could be, but back then that sort of 
idea was highly theoretical.  Today the highly theoretical thing are stuff 
like ZKPs over the history.

At the time compact blocks as a protocol feature hadn't been conceived and 
earlier block relay improvements were only just being developed--- any 
additional data in blocks slowed their propagation.  Today the extra data 
only slows their propagation when it wasn't well relayed in advance.  So 
the limit back then benefited block propagation, today it hurts it.

At the time the understanding that delays in propagation don't hurt the 
miner that added that data as much as they hurt small miners relative to 
very large miners was less well understood. Eyal&Sirer's paper had only 
been published a couple months before and it contributed to understanding 
of communications delay as a factor in centralization pressure, though even 
today many don't understand it or don't think about it.

At the time, many of us had an understanding that these sorts of limit were 
unstable equilibrium at best-- and wouldn't stand once miners were being 
driven by fees, wouldn't stand if there was significant demand that wasn't 
just confused, ... today we've long since reached that world and found that 
that understanding was correct.

At the time no one had any reason to be concerned that they might be hauled 
before congress or even prosecuted because some state blacklist wasn't also 
a standarness rule or because it wasn't working well enough to block 
transactions.

The limit was somewhat popularly unpopular at the time and became 
extraordinarily unpopular later,  I feel a little irony that for merely 
defending the limit on its merits I was multiply subjected to threats of 
physical violence not too many years ago.  A common thread underlies much 
of the opposition to remove it: a knee jerk reaction to some perception of 
authority, which was largely unaware of or indifferent to the reasoning and 
the same false smears of conflicts of interest and whatnot have been 
deployed.  Fortunately for OP_RETURN it's initial addition added something 
entirely knew so even though it was limited it was more than nothing.  The 
really vigorous attacks on it came only after it was forgotten that it 
wasn't previously unlimited.  Similarly, instead of being based on the 
substance the driver appeared to be parties weaponizing it for other 
purposes.  Back then as a general means to attack the bitcoin project to 
promote forks,  this time because of anger about nft/shitcoin traffic which 
this change actually has little to no bearing on.

I fear at times there is a tendency to look at anything that came before 
you and assuming that it was some kind of holy solution.  But standardness 
limits aren't holy, they're a hack... sometimes a very useful hack. They 
should only exist when their benefits well outweigh their costs. Given the 
history I don't think it was wrong to limit at the time, but it was a very 
different world then.



-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8cb5c012-e28a-466d-b444-9083bf1a486cn%40googlegroups.com.

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

<div>It might be helpful to reflect on how reality has changed since the
 OP_RETURN behavior was originally rolled out in February 2014.</div><div><=
br /></div><div>At
 the time blockfile pruning would not be deployed to the public for=20
another year and a half,=C2=A0 so everyone that ran a node was forced to st=
ore and serve
 anything that made it into a block.</div><div><br /></div><div>In 2014 peo=
ple were proposing protocol additions that would allow basically random acc=
ess to the transactions/txouts over the P2P network, potentially outright a=
llowing file trading applications that abused bitcoin nodes as their server=
.=C2=A0 Today there are no such proposals and any would be DOA because the =
abuse potential is well understood.</div><div><br /></div><div>At the=20
time miners were almost entirely driven by subsidy, fees were fairly
insignificant.</div><div><br /></div><div>With the=20
exception of a rare joker block standardness rules were highly=20
effective, and short of mining a block yourself or talking a highly=20
community connected mining pool operator into it=C2=A0 (or being that opera=
tor) you couldn't bypass any
 of them.</div><div><br /></div><div>Blocks were on average running at 16%
 of the consensus capacity limit.=C2=A0 Absent some kind of adhoc non-conse=
nsus restriction the=20
cost to dump in large amounts of data would have been nothing.=C2=A0 Today=
=20
the _average_ block is essentially full and the costs are considerable.</di=
v><div><br /></div><div>A minimum feerate of 1s/vb has increased in buying =
power by a factor of 171 from Feb 2014 to now.</div><div><br /></div><div>U=
sers
 were much more ignorant about what they got out of putting data in, it=20
was common to hear things that would better be served with a commitment=20
(or something like OTS, which wouldn't be available for another two and a h=
alf)-- they didn't have much=20
reason to think hard about their application because stuffing in data=20
was cheap (or, even free if not for limits).=C2=A0 Today's data stuffers=20
cases generally do make sense on their own terms even if many would=20
agree that they're not an appropriate use of Bitcoin.=C2=A0 There are more=
=20
alternative communications channels than ever now, ipfs, nostr, other=20
blockchains.=C2=A0 Stuffing data in is expensive. Those who still do it are=
=20
willing to pay, which also means miners are willing to let them. The partie=
s that do it are technically sophisticated or at the very least can afford =
the services of people who are and can and have implemented evasions to adh=
oc restrictions.</div><div><br /></div><div>Today
 there are implementations of concepts like assumeutxo, which while=20
subject to their own limitations would allow people to bring up fully=20
validating nodes without ever downloading or processing spam data (and=20
pruining as mentioned is real now and lets you not store it).=C2=A0 While n=
ot
 yet completed and deployed it clearly could be, but back then that sort
 of idea was highly theoretical.=C2=A0 Today the highly theoretical thing a=
re stuff like ZKPs over the history.</div><div><br /></div><div>At the=20
time compact blocks as a protocol feature hadn't been conceived and=20
earlier block relay improvements were only just being developed--- any=20
additional data in blocks slowed their propagation.=C2=A0 Today the extra d=
ata only slows
 their propagation when it wasn't well relayed in advance.=C2=A0 So the lim=
it
 back then benefited block propagation, today it hurts it.</div><div><br />=
</div><div>At the time the understanding that delays in propagation don't h=
urt the miner that added that data as much as they hurt small miners relati=
ve to very large miners was less well understood. Eyal&amp;Sirer's paper ha=
d only been published a couple months before and it contributed to understa=
nding of communications delay as a factor in centralization pressure, thoug=
h even today many don't understand it or don't think about it.</div><div><b=
r /></div><div>At
 the time, many of us had an understanding that these sorts of limit=20
were unstable equilibrium at best-- and wouldn't stand once miners were=20
being driven by fees, wouldn't stand if there was significant demand=20
that wasn't just confused, ... today we've long since reached that world
 and found that that understanding was correct.</div><div><br /></div><div>=
At the time no one had any reason to be concerned that they might be hauled=
 before congress or even prosecuted because some state blacklist wasn't als=
o a standarness rule or because it wasn't working well enough to block tran=
sactions.</div><div><br /></div><div>The limit was somewhat popularly unpop=
ular at the time and became extraordinarily unpopular later,=C2=A0 I feel a=
 little irony that for merely defending the limit on its merits I was multi=
ply subjected to threats of physical violence not too many years ago.=C2=A0=
 A common thread underlies much of the opposition to remove it: a knee jerk=
 reaction to some perception of authority, which was largely unaware of or =
indifferent to the reasoning and the same false smears of conflicts of inte=
rest and whatnot have been deployed.=C2=A0 Fortunately for OP_RETURN it's i=
nitial addition added something entirely knew so even though it was limited=
 it was more than nothing.=C2=A0 The really vigorous attacks on it came onl=
y after it was forgotten that it wasn't previously unlimited.=C2=A0 Similar=
ly, instead of being based on the substance the driver appeared to be parti=
es weaponizing it for other purposes.=C2=A0 Back then as a general means to=
 attack the bitcoin project to promote forks,=C2=A0 this time because of an=
ger about nft/shitcoin traffic which this change actually has little to no =
bearing on.</div><div><br /></div><div>I fear at times there is a tendency =
to look at anything that came before you and assuming that it was some kind=
 of holy solution.=C2=A0 But standardness limits aren't holy, they're a hac=
k... sometimes a very useful hack. They should only exist when their benefi=
ts well outweigh their costs. Given the history I don't think it was wrong =
to limit at the time, but it was a very different world then.</div><div><br=
 /></div><div><br /></div><div><br /></div>

<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/8cb5c012-e28a-466d-b444-9083bf1a486cn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/8cb5c012-e28a-466d-b444-9083bf1a486cn%40googlegroups.com</a>.<br />

------=_Part_336785_1725370454.1746453902653--

------=_Part_336784_1058258725.1746453902653--