From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <8cb5c012-e28a-466d-b444-9083bf1a486cn@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
It might be helpful to reflect on how reality has changed since the OP_RETURN behavior was originally rolled out in February 2014.
<= br />
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.

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.

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

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.

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.

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

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.

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.

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.

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

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

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.

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.


--
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/8cb5c012-e28a-466d-b444-9083bf1a486cn%40googlegroups.com.
------=_Part_336785_1725370454.1746453902653-- ------=_Part_336784_1058258725.1746453902653--