I just wanted to post my thoughts somewhere and share a relevant anecdote from bitcoin++ last week.
I see the motivations against removing the datacarriersize limit as two-fold:
1. “Arbitrary data is not money and bitcoin definitely is money. The extent to which bitcoin [blockspace] can be used as not money is the extent to which it’s bad at being money because they’re competing over the same resources.” (Mechanic)
2. Noderunner’s right to choose what transactions they may or may not want to relay, i.e. “not on my lawn.”
Regarding point 1, the question to me is what exactly constitutes <arbitrary data>? All data that is not directly related to spending coins? Should all arbitrary data be considered spam? Isn’t spam subjective?
I heard Luke Dashjr’s respond to this last question, “No, there’s an objective difference. Bitcoin’s design allows miners to include up to 95 bytes per block of arbitrary data in the coinbase. That is completely different from spam which is encoding this arbitrary data to look like something it is not to deceive nodes into accepting it. If you submit a JPEG as a transaction it will be rejected by every single node. You have to obfuscate it and make it look like something it’s not to make it accepted.”
Regarding point 2, given that Bitcoin Core is the default client used by the vast majority of nodes on the network, removing the datacarriersize limit, would make it more difficult for Core nodes to *easily* limit the size of the op_return field. I take Greg Maxwell’s point here that there is some “serf thinking” involved in that Bitcoin Core does not give you these rights. The Bitcoin Core client is an open source tool that you can choose to patch, fork, and modify as you see fit. I think the defenders of the op_return limit are interested in the *ease* with which someone can make a decision in one way or another. In any case, I’ll leave my conclusions below my story below which I think is a nice illustration of the debate.
There was a project called GarbageMan presented at the bitcoin++ hackathon that forks a Knots node to impersonate a Libre Relay node by setting the node’s service bit to signal to other Libre Relay nodes that it is also part of the Libre Relay network (bit number 29). These Knots nodes, pretending to be Libre Relay nodes, prioritized Libre connections as their preferred peers. This way the “Garbage Men” could infiltrate the Libre Relay network to intercept transactions the Knots nodes consider spam, and throw them away. (Prez:
https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=2277)
This was an awesome project and clearly a fun jab at Peter Todd, who was one of the judges, the creator of the Libre Relay project, and also who opened the original PR to remove the datacarriersize limit.
Peter Todd’s argument was that filters would be ineffective on the mempool because you could just use services like Libre Relay to get around those filters. GarbageMan is a strike back that filters could be deployed to attack the Libre Relay network as well.
A couple presentations later, another project called MemCooler implemented a parallel straight-to-miner relay (a la Slipstream) over Nostr. Miners announce themselves on Nostr, where transactors can look up, select, and pay specific miners to mine their transactions. (Prez:
https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=3005)
During the Q&A, Peter Todd asked, “why not do an option that just broadcasts the transaction on Nostr and say hey [miners] please go mine it?”
“Uhmm I guess there is no reason not to do that.” Smile, “Just turn Nostr into the mempool.” Peter Todd, emphatically, “Sounds good to me!” then roared, “Let’s go fight GarbageMan!”
(Peter Todd’s Question:
https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=3344)
I’ve read a lot of Gmaxwell’s thinking on this debate from this forum and on reddit, and I think a lot of this boils down to the fact that Bitcoin is built to be censorship resistant. I totally get that policies express preferences in what transactions are relayed and this can increase friction for those transactions, but I don’t think it’s Core’s job to tool for that. I think the way this has played out with Knots forking Core, keeping consensus rules the same, but adding more options around filtering is a perfectly reasonable outcome. Why not have more clients? I understand that if a lot of people end up using clients that have significant changes around peer-to-peer networking and consensus rules, cough btcd, then that would be problematic, but I don’t think the answer to that problem is that we should resign from running modified, patched, forked or alternative clients…
Finally, if the real issue here is the spam, It seems the only way to definitively filter or block this would be through consensus rules changes or through centralized or homogenized block template creation. If block template creation is more distributed then you’re more likely to have people who mine non-standard transactions and it’s more difficult to gain a majority of mining nodes to only accept block templates of certain characteristics.
Bitcoin’s blockspace is a free market. I think people can and will express their political positions through their nodes, but that it is not Bitcoin Core’s job to outfit them with those tools.
bitcoin++ livestreams:
Day 1
Main Stage:
https://www.youtube.com/watch?v=EKQvDfmQkt8Poolin Stage:
https://www.youtube.com/watch?v=nUQlBxWwlaUWorkshop Stage:
https://www.youtube.com/watch?v=J9bRVIXOhm0Day 2
Main Stage:
https://www.youtube.com/watch?v=rsMujxqgHeQPoolin Stage:
https://www.youtube.com/watch?v=F2p_V0svDToWorkshop Stage:
https://www.youtube.com/watch?v=pv429hE3r3UDay 3
Hackathon Presentations:
https://www.youtube.com/watch?v=cLLpmbg4KKk