Nostr Web Client

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

nomadshiba⚡ 7mo ago

1:00 no, knots see the tx, and caches it, like core does for filtered txs. it just doesnt add it to the mempool and relay it. so no latency. but if a miner cant get a tx from the network because of the nodes are filtering it, then the miner has to include it manually then the miner gets latency because now nobody on the network has seen that tx before so their block take longer to verify. and in that time another miner with less manually included txs in their block might beat them.

thats all upside down, one of many misinformation these people has been spreading like a virus. (all of the video seems to be filled with them, these are not new "points")

(also even if there was latency (there isnt), bitcoin was never trying to achieve maximum efficiency. thats not the main goal, base layer was never trying to maximize privacy, efficiency, programmability or other stuff, thats not the purpose of the base layer, its purpose is to be a secure decentralized layer, foundation for other layers to fallback on at worse cases)

1:50 point of filters is making it harder to reach a block, make it more expensive, so doing parasite spam txs doesnt go mainstream.

2:00 if you have a miner that big, then you have bigger problems. while your house is burning of course your clothes will be ruined.

2:10 nobody said OP_RETURN is spam, spam use of OP_RETURN is spam, and we can detect it. 42 bytes of OP_RETURN is more than enough for a hash, therefore prove anything on-chain.

3:15 i wonder why companies(not people) who are spamming the chain right now has to go to the miners directly right now, if filters doesnt work. these are all talked about 100 times, pure nonsense, if it made sense, ipfs would have worked.

4:13 thats not worse, thats the point, make it more expensive. as i said, it creates latency for the miner. because when you add txs to your block that nobody on the network has seen before its latency for you, not others. also the fact that you can talk about a miner can guarantee you a block, is itself a problem. if you have a miner is that big, then they can just delay publishing the block themselves, so they can look for the nexy block for a longer time than the rest of the network. problem is the mining centralization.

4:30 talking about free market, lets free the market of node implementations, lets archive core, and have many newer node implementations in the market trying to fill its space.

5:46 thats the point who decides what bitcoin is? well bitcoin core decides it atm. its centralized to a single collective entity something happens or doesnt happen, decided by voting. it works similar to a government, organization or a company. but we can have many node implementations all experimenting with different things in parallel, everything happens at the same time, and the market decides which one they will use. the community/the users decides what happens, what is being filtered, or not, while staying in the frame of the bitcoin consensus. total protocol ossification. real free market of node implementations fighting for being useful good looking and provide an amazing ux to its users. not treating them like free hardware on the aether. bitcoin nodes are not people donating their hardware and internet connection to some people who has a fantasy of being a bitcoin dev. bitcoin nodes are the bitcoin users. and the fact that no node implementation trying to make running and syncing it easier, with a better ux, shows that there is no real competition in this market. we need a software serving to its users, not the other way around.

the fact that bitcoin has an active repo on github called `bitcoin/bitcoin` not archived, is a concern.

the fact that we have to say "dont do it", is the problem.

more about node decentralization of node implementations:

nostr:nevent1qvzqqqqqqypzq3vrtsm0g8vhn0yp9xps7t6ajftz756r6mldm4hnp2nefqrnpunwqyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhkyarr9e4kcetwv3sh5afwvdhk6tcqyqhsjlfzka6w2smxr4h5ulnx58wj0yvnjua2w9wk8xmj3v76fuq52ef4z9x

Reply to this note

Please Login to reply.

Discussion

Momo 7mo ago

The first point you raised is a good food for thought. I'll look deeper into it.

Re "2:10 nobody said OP_RETURN is spam, spam use of OP_RETURN is spam, and we can detect it. 42 bytes of OP_RETURN is more than enough for a hash, therefore prove anything on-chain."

Coinjoin for example is a legitimate use of the network (from my point of view) and it is not relayed when the threshold is set under 42 bytes.

Re "3:15 i wonder why companies(not people) who are spamming the chain right now has to go to the miners directly right now, if filters doesnt work. these are all talked about 100 times, pure nonsense, if it made sense, ipfs would have worked."

They have to go to the miner because most nodes with default settings won't relay their transactions. So they will not be relayed organically. Filters don't work, because they can still pay the miner out-of-band - which they do currently. I don't want this to happen and don't want to encourage this. In fact, it's the benefit of removing the OP_RETURN limit that discourages out-of-band payments and such transactions can be relayed over the chain.

I do not take any issues with people running any other implementation than the Bitcoin node. I'd cautiously say that's a good thing (though atm I haven't thought about its implications for UASF and other consensus changes.)

We are free to refrain from upgrading or turn towards a different node implementation.

nomadshiba⚡ 7mo ago

I wasn't expecting a calm reply, thank you for that :)

> Coinjoin for example is a legitimate use of the network (from my point of view) and it is not relayed when the threshold is set under 42 bytes.

in the note/post i shared at the bottom of my reply i was talking about OP_RETURN can be anything, maybe today we think 42 bytes is fine, maybe tomorrow its 64 or 32. my concern is one implementation decides that. that's bad, and concerning. how many bytes do you need for coin join? I can make it more, i support coinjoin, someone might not. maybe someone believe there is no place of privacy on the base layer and we shouldn't sacrifice other things for privacy. thats for people/users to decide, not a single repo.

> They have to go to the miner because most nodes with default settings won't relay their transactions. So they will not be relayed organically. Filters don't work, because they can still pay the miner out-of-band - which they do currently. I don't want this to happen and don't want to encourage this. In fact, it's the benefit of removing the OP_RETURN limit that discourages out-of-band payments and such transactions can be relayed over the chain.

I mean that's my point going directly to the miner will never be cheaper. because making blocks with never before seen txs on the network always guaranteed to cause latency for the miner.

Make it expensive, painful, so it will never go mainstream, and they will look for other homes.

And again main issue is that a miner can guarantee a block, issue is mining centralization. And there are multiple some experimental solutions for it.

And again I don't wanna make it easier for them. The fact that they directly have to go to the miners is a good sign for me. And the fact that miners can guarantee blocks is what's concerning. I'm concerned about my house is burning, not my clothes are getting dirty because of the smoke.

> I do not take any issues with people running any other implementation than the Bitcoin node. I'd cautiously say that's a good thing (though atm I haven't thought about its implications for UASF and other consensus changes.)

> We are free to refrain from upgrading or turn towards a different node implementation.

Yes that's why I'm trying to implement by own. If I can make it the way I envisioned it, then I will make it public.

At worse case I learn a lot trying to make it.

Again thank you for replying honestly.

Momo 7mo ago

Of course 😊

I'm married to no view and I'm just a curious pleb.

"I mean that's my point going directly to the miner will never be cheaper. because making blocks with never before seen txs on the network always guaranteed to cause latency for the miner."

I had the exact same view and it's even reflected in one of my Nostr posts. The issue I have with it is that at the current climate of things, it reinforces more mining centralization and the extra money goes directly to the pocket of miners with no trace on the blockchain and that's what I wouldn't like to encourage.

I am aware of the solutions to mining centralization, but till they become more widely accepted this is gonna be my view. Although I'm curious to see how developments such as Stratum V2 pan out.