![RIPreason's tweet photo. I am just a layman. But I've spent a lot of time trying to understand this issue. Here's what I think is the most compelling technical pro-Core (increase limits on OP_RETURN) argument:
We should increase the limits on OP_RETURN from 80 bytes to L bytes. This is strictly an improvement over the previous situation, because following this change, any transactions that we see using L bytes in OP_RETURN could have also done the same prior to this change by using fake public key outputs to encode those L bytes. But at least now we're giving them the option of not polluting the UTXO space.
(I use "L" here to represent the maximum number of data that could be encoded by fake public key outputs)
And here are my two counterarguments to this, one more technical and one more contextual.
1. Encoding data in OP_RETURN is cheaper than encoding data using fake public key outputs. I relied on chatGPT for this analysis (see the table below). It claims that encoding 1kb of data using OP_RETURN would use 1036 vBytes, while the cheapest way of encoding the data using fake public key outputs would require 1364 vBytes. This is a significant cost difference, making it cheaper to embed data via OP_RETURN (and the pro-Core crowd loves to bring up incentives). So in fact, there could be "applications" that were formerly uneconomical but made economical with this change.
2. This argument assumes that we can't do anything to prevent embedding data in fake public key outputs in the first place: "we can't do anything about it anyways, let's just try to make the best out of a shitty situation".
Now, I understand that it is theoretically impossible to filter all spam. It doesn't follow that we should therefore do nothing. Here, I have to defer to people much smarter than me. For example, see this thread (which does concede that it is a cat-and-mouse game):
https://t.co/yDZICp5iCZ
Now, getting into the contextual argument:
I can't tell if the above approach will work, but I'm open to trying it, and I also know that Core has been in control while we watched the UTXO set grow from like 4GB to 12GB in less than two years. I'm sure there were all these arguments why nothing could be done. Luke and others thought otherwise (e.g. Luke's PR from 2023: https://t.co/enc97VBZHW). Core had its chance and now I want to give Luke a chance. I find @GrassFedBitcoin 's argument here compelling: they did nothing while UTXO size tripled, and now they suddenly want to make this change to the OP_RETURN limit that has been in place for almost a decade?
The pro-Core crowd in general rubs me the wrong way. I hate reading things like "Bitcoin is a database", which essentially tries to put all applications of Bitcoin on equal footing – as long as the transactor is willing to pay money, it's legit. No. Bitcoin's most important use by far is as sound money. Everything that dilutes this in a significant way can go to hell.
Even Core devs seem to have this "Bitcoin is a database" mindset. Here's a concrete example of that:
https://t.co/eerHFAxZT1
Hence I sense a fundamental philosophical disagreement with Core.
Also, all the gaslighting from the pro-Core side is super annoying, e.g. the constant strawman of "filters don't work (because they don't prevent spam from getting mined)" or "why don't you address it at the consensus level", which is obviously super impractical.
I'm ready to try something new.
Now, I do also see potential issues with Knots, but it's got nothing to do with the FUD spread by pro-Core people (e.g. the CEO of River alluding to Knots as a "poorly maintained forks of Bitcoin (with their own large flaws)" while later in the same post saying "the debate should remain objective and technical" along with a bunch of other misleading stuff [1]).
My main concern with Knots is if, in the dream scenario where the majority of nodes are Knots nodes, the network becomes too volatile/hostile to any development. What if some L2 absolutely needed a feature that Luke was unwilling to cede? For example, I'm running Knots right now on a Start9 server, and the default value for the OP_RETURN limit is 42 bytes. Core is 83 bytes. If I was a developer with an application that relied on 80 bytes of OP_RETURN, suddenly I'm getting "rugged", so to speak. Let's be real, this is messy. On the other hand, maybe the current situation with a relatively stable environment was too good to be true, given Bitcoin's distributed nature. Apparently, it was also too good to be true that Bitcoiners could just sit on their hands and watch number go up. That's probably like people expecting a democracy to work when the majority of citizens are uninformed.
Anyways, we're far from the point of Knots domination. In the meantime...running Knots.
[1] https://t.co/rqbardtiMY](https://pbs.twimg.com/media/GrC0cIxbgAAk8f-.jpg)
Olivia
Online
C #BIP-110
@RIPreason
Formerly an apolitical nerd minding my own business, got political after Bret Weinstein/Evergreen College, James Damore/Google, and BLM/defund the police.
Joined May 2016
158 Following
211 Followers
2.6K Posts
Pinned Tweet
I am just a layman. But I've spent a lot of time trying to understand this issue. Here's what I think is the most compelling technical pro-Core (increase limits on OP_RETURN) argument:
We should increase the limits on OP_RETURN from 80 bytes to L bytes. This is strictly an improvement over the previous situation, because following this change, any transactions that we see using L bytes in OP_RETURN could have also done the same prior to this change by using fake public key outputs to encode those L bytes. But at least now we're giving them the option of not polluting the UTXO space.
(I use "L" here to represent the maximum number of data that could be encoded by fake public key outputs)
And here are my two counterarguments to this, one more technical and one more contextual.
1. Encoding data in OP_RETURN is cheaper than encoding data using fake public key outputs. I relied on chatGPT for this analysis (see the table below). It claims that encoding 1kb of data using OP_RETURN would use 1036 vBytes, while the cheapest way of encoding the data using fake public key outputs would require 1364 vBytes. This is a significant cost difference, making it cheaper to embed data via OP_RETURN (and the pro-Core crowd loves to bring up incentives). So in fact, there could be "applications" that were formerly uneconomical but made economical with this change.
2. This argument assumes that we can't do anything to prevent embedding data in fake public key outputs in the first place: "we can't do anything about it anyways, let's just try to make the best out of a shitty situation".
Now, I understand that it is theoretically impossible to filter all spam. It doesn't follow that we should therefore do nothing. Here, I have to defer to people much smarter than me. For example, see this thread (which does concede that it is a cat-and-mouse game):
https://t.co/yDZICp5iCZ
Now, getting into the contextual argument:
I can't tell if the above approach will work, but I'm open to trying it, and I also know that Core has been in control while we watched the UTXO set grow from like 4GB to 12GB in less than two years. I'm sure there were all these arguments why nothing could be done. Luke and others thought otherwise (e.g. Luke's PR from 2023: https://t.co/enc97VBZHW). Core had its chance and now I want to give Luke a chance. I find @GrassFedBitcoin 's argument here compelling: they did nothing while UTXO size tripled, and now they suddenly want to make this change to the OP_RETURN limit that has been in place for almost a decade?
The pro-Core crowd in general rubs me the wrong way. I hate reading things like "Bitcoin is a database", which essentially tries to put all applications of Bitcoin on equal footing – as long as the transactor is willing to pay money, it's legit. No. Bitcoin's most important use by far is as sound money. Everything that dilutes this in a significant way can go to hell.
Even Core devs seem to have this "Bitcoin is a database" mindset. Here's a concrete example of that:
https://t.co/eerHFAxZT1
Hence I sense a fundamental philosophical disagreement with Core.
Also, all the gaslighting from the pro-Core side is super annoying, e.g. the constant strawman of "filters don't work (because they don't prevent spam from getting mined)" or "why don't you address it at the consensus level", which is obviously super impractical.
I'm ready to try something new.
Now, I do also see potential issues with Knots, but it's got nothing to do with the FUD spread by pro-Core people (e.g. the CEO of River alluding to Knots as a "poorly maintained forks of Bitcoin (with their own large flaws)" while later in the same post saying "the debate should remain objective and technical" along with a bunch of other misleading stuff [1]).
My main concern with Knots is if, in the dream scenario where the majority of nodes are Knots nodes, the network becomes too volatile/hostile to any development. What if some L2 absolutely needed a feature that Luke was unwilling to cede? For example, I'm running Knots right now on a Start9 server, and the default value for the OP_RETURN limit is 42 bytes. Core is 83 bytes. If I was a developer with an application that relied on 80 bytes of OP_RETURN, suddenly I'm getting "rugged", so to speak. Let's be real, this is messy. On the other hand, maybe the current situation with a relatively stable environment was too good to be true, given Bitcoin's distributed nature. Apparently, it was also too good to be true that Bitcoiners could just sit on their hands and watch number go up. That's probably like people expecting a democracy to work when the majority of citizens are uninformed.
Anyways, we're far from the point of Knots domination. In the meantime...running Knots.
[1] https://t.co/rqbardtiMY
![RIPreason's tweet photo. I am just a layman. But I've spent a lot of time trying to understand this issue. Here's what I think is the most compelling technical pro-Core (increase limits on OP_RETURN) argument:
We should increase the limits on OP_RETURN from 80 bytes to L bytes. This is strictly an improvement over the previous situation, because following this change, any transactions that we see using L bytes in OP_RETURN could have also done the same prior to this change by using fake public key outputs to encode those L bytes. But at least now we're giving them the option of not polluting the UTXO space.
(I use "L" here to represent the maximum number of data that could be encoded by fake public key outputs)
And here are my two counterarguments to this, one more technical and one more contextual.
1. Encoding data in OP_RETURN is cheaper than encoding data using fake public key outputs. I relied on chatGPT for this analysis (see the table below). It claims that encoding 1kb of data using OP_RETURN would use 1036 vBytes, while the cheapest way of encoding the data using fake public key outputs would require 1364 vBytes. This is a significant cost difference, making it cheaper to embed data via OP_RETURN (and the pro-Core crowd loves to bring up incentives). So in fact, there could be "applications" that were formerly uneconomical but made economical with this change.
2. This argument assumes that we can't do anything to prevent embedding data in fake public key outputs in the first place: "we can't do anything about it anyways, let's just try to make the best out of a shitty situation".
Now, I understand that it is theoretically impossible to filter all spam. It doesn't follow that we should therefore do nothing. Here, I have to defer to people much smarter than me. For example, see this thread (which does concede that it is a cat-and-mouse game):
https://t.co/yDZICp5iCZ
Now, getting into the contextual argument:
I can't tell if the above approach will work, but I'm open to trying it, and I also know that Core has been in control while we watched the UTXO set grow from like 4GB to 12GB in less than two years. I'm sure there were all these arguments why nothing could be done. Luke and others thought otherwise (e.g. Luke's PR from 2023: https://t.co/enc97VBZHW). Core had its chance and now I want to give Luke a chance. I find @GrassFedBitcoin 's argument here compelling: they did nothing while UTXO size tripled, and now they suddenly want to make this change to the OP_RETURN limit that has been in place for almost a decade?
The pro-Core crowd in general rubs me the wrong way. I hate reading things like "Bitcoin is a database", which essentially tries to put all applications of Bitcoin on equal footing – as long as the transactor is willing to pay money, it's legit. No. Bitcoin's most important use by far is as sound money. Everything that dilutes this in a significant way can go to hell.
Even Core devs seem to have this "Bitcoin is a database" mindset. Here's a concrete example of that:
https://t.co/eerHFAxZT1
Hence I sense a fundamental philosophical disagreement with Core.
Also, all the gaslighting from the pro-Core side is super annoying, e.g. the constant strawman of "filters don't work (because they don't prevent spam from getting mined)" or "why don't you address it at the consensus level", which is obviously super impractical.
I'm ready to try something new.
Now, I do also see potential issues with Knots, but it's got nothing to do with the FUD spread by pro-Core people (e.g. the CEO of River alluding to Knots as a "poorly maintained forks of Bitcoin (with their own large flaws)" while later in the same post saying "the debate should remain objective and technical" along with a bunch of other misleading stuff [1]).
My main concern with Knots is if, in the dream scenario where the majority of nodes are Knots nodes, the network becomes too volatile/hostile to any development. What if some L2 absolutely needed a feature that Luke was unwilling to cede? For example, I'm running Knots right now on a Start9 server, and the default value for the OP_RETURN limit is 42 bytes. Core is 83 bytes. If I was a developer with an application that relied on 80 bytes of OP_RETURN, suddenly I'm getting "rugged", so to speak. Let's be real, this is messy. On the other hand, maybe the current situation with a relatively stable environment was too good to be true, given Bitcoin's distributed nature. Apparently, it was also too good to be true that Bitcoiners could just sit on their hands and watch number go up. That's probably like people expecting a democracy to work when the majority of citizens are uninformed.
Anyways, we're far from the point of Knots domination. In the meantime...running Knots.
[1] https://t.co/rqbardtiMY](https://pbs.twimg.com/media/GrC0iEhaAAIVNM0.png)
At @River we will continue to run Bitcoin Core because it is the only properly maintained Bitcoin node software. The Bitcoin Core dev team is highly competent and dedicated to the long-term success of the network. The current state of the debate around OP_RETURN relay rules is the result of overdramatizing a nuanced technical decision regarding tx standardness rules. Running poorly maintained forks of Bitcoin (with their own large flaws) because of this minor technical debate is an overreaction IMO.
No Bitcoin Core dev wants the blockchain spammed with data because they are the ones forced to deal with the scaling issues and edge cases that follow. However, the reality today is that consensus rules allow transactions with large amounts of data in OP_RETURN, regardless of mempool policy! So, the broader debate here is twofold:
1. People want to put data onchain and they will do so with or without OP_RETURN limits. There is nothing stopping these people from skipping the mempool and submitting nonstandard txs directly to a mining pool today, or using even uglier approaches that bloat the UTXO set (even worse for the network). If we want to actually “fix” this, we would need a consensus fork, not a mempool rule change. The decision to change the standardness rules to allow these txs to be relayed seems reasonable and not a big deal.
2. The divergence between standardness rules and consensus rules: There are many transactions one could make that are valid by consensus rules that cannot be broadcast to the network today because they are “nonstandard”. This does not stop a miner from including the transactions in a block. High divergence between standardness rules and consensus rules leads to complexity in the Bitcoin Core software and causes problems for block relay efficiency when people start sending non-standard transactions direct to miners. Starting to move away from this divergence seems reasonable, but needs to be done carefully. We can likely never fully delete standardness rules but I understand the goal to reduce complexity here.
This debate should remain objective and technical. It’s being blown way out of proportion. Remember, the vast majority of Bitcoin Core devs deeply care about the long-term health of Bitcoin and have dedicated their careers to getting Bitcoin where it is today.
@homegymcoop Those are insanely good numbers, especially considering your bodyweight (probably in the top 1% in most commercial gyms). I'm confident that relative strength trumps muscle for health. Keep up the good work and ignore the haters (not like you need to hear that from me, lol).
@GrassFedBitcoin @Jethroe111 Here's what I'm not convinced about through – suppose 80% of nodes were running BIP-110. Do you think the miners would have still ignored it?
I can't distinguish between "small group get to decide the rules" and "insufficient node support for BIP-110".
@tokidoki77 Epic. 🔥🔥🔥
@tokidoki77 Grats!!!!!
@ProtocolPulseHQ I lol'd when he said "get fucked" (in the original).
@sesi_the_man @KeithMukai I'm embarrassed to say that for the longest time, I actually didn't understand what the purpose of the SeedSigner was (even though I had encountered it)😅
@homegymcoop Game-changing. How well will these work for other purposes, like jumps, changing heights for box squats, stretching/calisthenics, etc.?
@sesi_the_man Thank you!
@AndrewMesmer @sesi_the_man @BTCsessions @CauliStack @SeedSigner Surprising to me also. All things considered, the dice rolling seems more easily verifiable. How can you be certain that all the seed words are represented exactly once in the jar?
@davelund_ What the hell did I just watch 😂
@jimmysong This analysis is over my head. I have a question though – could big miners collude and temporarily favor one chain, while dumping on that chain, and then suddenly switch to the other chain?
@mattkratter https://t.co/Htkdo3lW36
Another PSA for BIP-110ers on start9 + Tor:
The UI can show Tor “inbound OK” while your .onion is dead — you’ll see 0 real peer inbounds. I'm guessing that this could result in BIP-110 nodes being undercounted in statistics.
Grok actually discovered this when I asked it to check my peer connections; I was curious what percentage of them were BIP-110 (currently 5 Core, 4 Knots, 1 Knots + BIP-110).
The fix for me was to restart Tor and Knots.
Another PSA for BIP-110ers on start9 + Tor:
The UI can show Tor “inbound OK” while your .onion is dead — you’ll see 0 real peer inbounds. I'm guessing that this could result in BIP-110 nodes being undercounted in statistics.
Grok actually discovered this when I asked it to check my peer connections; I was curious what percentage of them were BIP-110 (currently 5 Core, 4 Knots, 1 Knots + BIP-110).
The fix for me was to restart Tor and Knots.
This article is claude-slop. I think Simon is overly-reliant on AI because he's just not very technical. In an earlier presentation, he confused "mega" and "kilo" (see screenshot), among other things.
That said, I appreciate his takes for a different perspective, and I'm still glad he's supportive of BIP-110.
This is stupid.
@TheDavidWeck We wear the same brand of socks 😂
I'm guessing the answer is no because it would be super niche, but have you considered making a version that would fit five-toed shoes?
Last Seen Users on Sotwe
Most Popular Users
Elon Musk
@elonmusk
241.6M followers
Barack Obama
@barackobama
119M followers
Cristiano Ronaldo
@cristiano
114.1M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Narendra Modi
@narendramodi
107.2M followers
Rihanna
@rihanna
98.7M followers
NASA
@nasa
92.4M followers
Justin Bieber
@justinbieber
91.8M followers
KATY PERRY
@katyperry
89.8M followers
Taylor Swift
@taylorswift13
83.8M followers
Lady Gaga
@ladygaga
75.3M followers
Virat Kohli
@imvkohli
73.1M followers
Kim Kardashian
@kimkardashian
70.8M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
66.1M followers
Bill Gates
@billgates
65M followers
Selena Gomez
@selenagomez
62.9M followers
The Ellen Show
@theellenshow
62.3M followers
CNN
@cnn
61.8M followers
X
@x
60.7M followers