Replying to Avatar Momo

This short video breaks down why I changed my mind about the OP_RETURN limit—largely thanks to a conversation with nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyv8wumn8ghj7mn0wd68ytnnwpex7an0daehgtnwdsqzpp59a0hkv5ecm45nrckvmu7pnk0sukssvly33u3wwzquy4v037hcsgt75r .

https://youtu.be/dSBxAFV34nE

Avatar
mike 7mo ago đź’¬ 12

Hey nostr:nprofile1qyf8wue69uhh2mtzwfjkctf38g6rsdpcqy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqpqheqkxm37d5h7n8sx2gqdez5sxnu39qrylhxnnd66dxpu4e2ufyysfg47xc

Saw your YouTube video supporting unrestricted OP_RETURN

Your discoveries were already understood and was never the real discussion. We always understood that miners and NFT artists benefited from an unlimited OP_RETURN

Questions:

1. What is the reason to remove the limit on OP_RETURN? And I don’t mean, it doesn’t matter, so you may as well do it anyway. This is misdirection. Why remove the OP_RETURN limit. There is no public answer, which means there is a private answer we are not being told.

2. Why do you want a single “Core” version of Bitcoin running on all nodes and not multiple version for diversity and strength, just as we want multiple mining pools and mining hardware.

3. Why do you want to allow Core developers to be allowed to make decisions without consulting you. Despite nearly 100% rejection of OP_RETURN delimiting, Core pushed through the change anyway.

4. Core developers like Todd and Lopp have consistently patronised node runners by telling us we don’t need to be told what they are doing because we wouldn’t understand. Do you think this is appropriate behaviour. Do you like to be talked down to by others, I don’t.

These are the issues, not the points you raise which we understood from the beginning. We agree it is unlikely spam can never be stopped, but that doesn’t mean we shouldn’t try.

Yes, if some miners can make more money pushing through JPEGs then they will and this will disadvantage miners who don’t.

However Ocean are looking to change the low fee model of Pay Per Share (which is subsidised by Bitmain, the real villain here) to Pay Per Block, which is less reliable income for miners, but a higher income for miners.

If Ocean can tip the balance to miners earning more money on PPB, then they will follow a no JPEG template because it pays more than a PPS template with JPEGs. This is a win for node runners and a win for miners. Nash equilibrium as work inside Bitcoin.

nostr:nevent1qvzqqqqqqypzp0jpvdhrumf0ax0qv5sqmj9fqd8ez2qxflwd8xm456vretj4cjgfqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qqsytxfldgx898xq3uffml5huqa4gql47k90vrnk7xxf96gpve3pjzc3jswjk

Reply to this note

Please Login to reply.

Discussion

Avatar
Benking 7mo ago

🔥🔥

Avatar
Momo 7mo ago

Hi Mike,

Appreciate your comment. Here are the answers I have for your questions:

1. These are the reasons in favor of removing OP_RETURN:

a) It avoids endless debates over byte limits (120, 200, etc.), letting devs focus on more critical improvements.

b) It simplifies the codebase.

c) It reduces incentives for out-of-band miner payments for non-relayed transactions, promoting a more transparent network.

2. I don’t support a single-node implementation approach. While I agree with removing the OP_RETURN cap, anyone can choose to stay on an older version, switch to Knots, or re-enable the function in v30, since it’s gonna be only marked as deprecated, not removed.

That said, I haven’t fully weighed the coordination trade-offs of using different implementations, especially in the context of a UASF. For now, I’m simply stating that I plan to upgrade (only months after the release, not immediately). I'm not advocating that everyone should upgrade.

3. If there were strong technical reasons against this change, Core devs likely would’ve pushed back (based on the environment I know now, as I find most of them honest). The lack of convincing arguments to keep the limit justified the move. Again, migration or opting out of the upgrade is a valid stance for those who disagree. That's what I would have done if I was still in favor of keeping the limit and if Core ever implements something I strongly oppose—like hypothetical tail emissions proposed by our boy Peter Todd —I’d either stop upgrading or switch implementations.

4. I generally disagree with their approach and share your view—they often come off as elitist, which I find abhorrent. I do not vouch for their behavior. I just happen to be in favor of a change they are in favor of too.

Lastly, your point about Ocean is worth pondering. I haven’t dug deep enough to understand how they differ from other miners, and I’m skeptical of their marketing for now. From what I have learned so far, there is no guarantee they can fulfill their mining decentralization claims. But this is a point I'll keep an open mind to.

Avatar
SuiGenerisJohn 7mo ago

Love to see this kind of discussion.

Avatar
Jeff 7mo ago

Yep, I know absolutely nothing about it, but I know a good discussion when I see one.

Avatar
SuiGenerisJohn 7mo ago

Reasonable Disagreement is peak human.

Avatar
mike 7mo ago đź’¬ 1

Understood and agree with most of your points, however.

1.

a. We're debating it a lot, which we don't want to do, so we're going to make a change to stop the debate is not a valid argument.

b. Yes, removing code simplifies the codebase. Why is this important? We don't do this generally! Code evolves to become more complex and intricate over time to give greater functionality and ease of use.

c. Potentially yes.

For me this still doesn't answer my question of "Why remove the limit?" The above answers still answer in the "why not remove the limit" framework.

So here's my answer, you don't make changes with unknown and unintended consequences in such a critical code base unless the potential upside FAR outweighs the potential downside. Nobody is describing a potential upside, only "it doesn't matter". There is probably a potential upside, but we don't know it.

Taproot was a prime example of unintended consequences of change. An attempt to combine multiple transactions and scripts into a condensed merkle tree of verifiable branches gave us JPEGs in the first place.

2. I think we mostly have accord

3. I think we mostly agree

4. I think we mostly agree

Ocean mining point.

I agree that Ocean are pushing their rather minor argument to extremes. We are being distracted on both sides by a moot point. However, despite both sides pettiness, I mostly support Oceans long term goals and so support them in the wider picture, while forgiving this petit squabble.

Avatar
Neal 7mo ago

nostr:nprofile1qqstustrdclx6tlfncr9yqxu32grf7gjspj0mnfekadxnq72u4wyjzgpzpmhxue69uhkummnw3ezuamfdejsz9thwden5te0v4jx2m3wdehhxarj9ekxzmnyc65emh nostr:nprofile1qqswswmx4rkj6d7q05dtafhpkqq2z42fc62s37jvtp642m2jkpfxc2cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq35amnwvaz7tmjv4kxz7fwvajhgctvvfujucm0d5hhvvghy06wj

if they just kept the slider, let the node runner move it from 0 to infinite.

make your cage why it’s better to move to X instead of Y.

whatever the particular number is doesn’t matter, it’s just the violation of principle.

i think bitcoin is robust enough and we the network are strong enough to withstand any particular outcomes, but if bitcoin fails, it’s cause we lost grip on the princles.

Avatar
mike 7mo ago

Interesting.

Coders give node runners options based on the code they generate.

Why not pass those decisions down to the node runners in the form of fields or sliders, as you say.

Buried in "Advanced Features" so that the casual node runner doesn't get tempted to play with things they haven't fully considered.

YES!

Avatar
Momo 7mo ago

I agree. They should keep the option. I've heard their reasoning as to why this option does not need to be included, but I don't find them convincing. I'm in favor of keeping the option open.

Avatar
Momo 7mo ago

This comment of yours had escaped my attention for some reason.

I feel the need to clarify my response to two of the above arguments and I think one key response covers them both.

"a. We're debating it a lot, which we don't want to do, so we're going to make a change to stop the debate is not a valid argument."

"Taproot was a prime example of unintended consequences of change. An attempt to combine multiple transactions and scripts into a condensed merkle tree of verifiable branches gave us JPEGs in the first place."

The response I have here is that since it's a policy rule, rather than a consensus rule, it doesn't matter if we make it unlimited.

My biggest concern, too, was unintended consequences (as expressed in my interview with Ziya (https://youtube.com/live/fFYvIsLOsnQ).

But, in fact, if a transaction with a higher OP_RETURN posed a danger, it would be possible to get it into the blockchain even now.

If a higher OP_RETURN proves to be a threat, it needs to be removed on the protocol level and by "threat" I don't mean increased data storage on the blockchain and temporarily higher tx fees, I mean something that breaks the nodes.

Avatar
mike 7mo ago

A good magician distracts you from the real action. If you want to understand what’s going on, focus on where the magician doesn’t want you to look.

Both Core and Ocean want you to focus on OP_RETURN. Instead I suggest we focus on where each side doesn’t want you to look.

For core, this is less known and I don’t believe there is a unified agenda here, but there are individual agendas, some of which are known and public, namely Citrea.

For Ocean, I believe I understand the agenda and it is moving from Pay per Share to Pay per Block