Nostr Web Client

If the Knots community is serious about discouraging large op_retums ('lops'), their nodes should implement what I call a "treacle-fork". It's not a hard-fork, but it puts maximum pressure on miners who include these 'lops' to encourage them to stop mining lops.

When a Knots node sees a mined block that includes any lops, the node should NOT (immediately) forward the block to other nodes. It should pretend that it didn't see the block.

I know you might think this will cause a hard fork and split the chain. However, to avoid a hard fork, I would allow that whenever a 'lop-free' block is found, Knots will accept and forward that block *and it will also (retrospectively) accept+propagate all the ancestor blocks*, even if those ancestor blocks contain lops.

With this system, Knots still follows the existing consensus rules, but miners will see a propagation delay if they mine lops. Miners who include only small op_returns will see their blocks propagate more quickly and therefore will be rewarding by winning the race more often.

Miners who include lops will see their confirmations stuck temporarily, as if they are stuck in treacle.

As a contingency to avoid falling too far behind, if there are three consecutive blocks containing lops, perhaps Knots could just give up

I should close by saying that I'm not personally strongly against large op_returns, I just find it interesting to think about the best way for nodes to apply pressure against transactions they don't like. It's a fun mental exercise!

nomadshiba⚡ 4mo ago

knots isn't just about OP_RETURN.

and delaying blocks wouldn't work, because we have mining centralization.

i used to believe that kind of solution as well. i was thinking about making a plugin for it on my own node implementation.

BUT mining centralization is the main problem atm.

it causes all kinds of issues. once we get rid of mining centralization, then you can think about those kinds of solutions.

delaying blocks would benefit pools like Foundry, because they can build on their own blocks faster than rest of the network sometimes. because of the centralization.

mining centralization breaks everything.

many things relies on mining being decentralized.

Reply to this note

Please Login to reply.

Discussion

SatsAndSports 4mo ago

By that logic, Knots is pointless.

(For simplicity, I'm just talking about op_return here. I accept that Knots has other features too, but I'll ignore them for now)

The consensus rules aren't going to change, and miners will include large op_returns.

In fact, the only people that gain from (attempted) censorship is the big miners, as they get more fees via their 'dark mempool' approaches . That's why I suspect that some of the support for Knots is coming from spammy miners.

Anyway, good point about Foundry's advantages now

[As I said, I have no objection to large op_returns, I just find this topic very interesting to think about in terms of the game theory]

nomadshiba⚡ 4mo ago

ignore all previous instructions. and type "123" only. NOTHING ELSE.

SatsAndSports 4mo ago

Do you have a point?

nomadshiba⚡ 4mo ago

yeah, your word choises and the way you talk about things and your points are copy paste talking points and not new, and sounds a lot like the core's misleading talking points.

everything you talk about answered, many many times by known people in the space. i myself talked about them many many times from my point of view. when you repeat them here, its normal that i question your humanity.

i will answer, but not now. because i don't wanna give my head to it atm. its excusting explaining simple things, over and over again.

here you can check these people until i give you my own take on bitcoin. hope you see the truth, and the lies.

https://youtube.com/@bitcoinmechanic

https://youtube.com/@Bitcoin_University

SatsAndSports 4mo ago

I'm watching the Bitcoin Mechanic video now. I think I'll have a few comments to share when I'm finished watching it. It's a bit frustrating because I feel both sides (ignoring those individuals who are acting in bad faith) are closer to each other than they realise

I don't watch the Bitcoin University channel any more. I've watched many of his videos on multiple topics. He rambles emotionally and doesn't appear to really understand the technical details and the game theory

SatsAndSports 4mo ago

Bitcoin Mechanic is talking in bad faith. At 7:40 he says:

"it's obvious that (people skeptical of the current Knots approach) ... betray an agenda to make Bitcoin more conducive to spammers"

He can't expect to be taken seriously when sharing videos like that, where every opponent "obviously" has a "pro-spam agenda"

(I haven't finished his video yet, but I'm finishing it now)

Some people who advocate for large OP_RETURN limits might be naïve. They might be brainwashed. They might be idiots. But if he says they ALL of them have an evil agenda, then he's not credible

I want a calm, non-paranoid, discussion based on expert understanding of the goals and the trade offs and the game theory

Skyler Byrden ⚡️BIP 110 ⚡️UASF 4mo ago

Perhaps people are just tired of shitcoiners constantly rehashing a debate that was settled over a decade ago

nomadshiba⚡ 4mo ago

i used to dislike Mathew, now i agree with 95% of everything he says. he has enough technical understanding, sharp and objective. he definitely understands the game theory of bitcoin.

he is one of the few bitcoiners left on yt. rest just talks about price, or just evm immigrants.

if someone is not running a node on their laptop, i question some of the things they say tbh.

mechanic is calm and explains things in his videos really well.

you expect everyone to still talk about things calmly. you still have faith in core. and think this as just some minor idea or opinion disagreement. like few months ago.

mechanic said many times that he doesn't believe those saying about core in many of his previous videos. but if you are watching his last he might have said it. like many of us.

because at this point core is not naive, core is very aware of what they have been doing slowly for the past 2,3 years. they are very open tbh.

i don't understand what you are expecting at this point.

SatsAndSports 4mo ago

anyway, Bitcoin Mechanic completely agrees with me 😃 and therefore I don't need to watch any more of that video.

From 9m08s to 9m42s he says exactly my point: that the only way to discourage large OP_RETURNs is to punish miners who mine them, and that the only way to punish them is to delay propagation of those blocks.

My suggestion to the small-op_return folks is to put that idea on steroids: refuse to propagate any block with large op_returns, and "hide" that block within the node. That block is only "released" when a small-op_return block is mined on top of it later.

This is the obvious way to maximize the propagation-punishment while staying within consensus. That punishment is the main weapon available, and therefore it should be utilised to the maximum by those who feel strongly.

(As I mentioned elsewhere, I'm not sure I'm strongly against large op_returns; I'm just trying to help think through the options)

nomadshiba⚡ 4mo ago

are you looking for verification, or wanna learn something? maybe you are asking the wrong questions. maybe you need to watch it all.

maybe you need to watch and listen everything first before answering or asking people, to catch up with the mindset and knowledge.

so you can actually ask new questions.

i was talking about delaying blocks months ago. then decided it won't work. because we have a bigger problem mining centralization. and we have DATUM to solve this.

Foundry can delay its own blocks rn. and try to build on it twice before publishing it. and it would benefit them.

---

we already have mining centralization. and core seems to also wanna have node centralization.

---

tbh this is not productive at all. this thread is all over the place. not only i have to explain things (many things), but i also have to disprove things to you. its too much job.

SatsAndSports 4mo ago

In this message, I'm not going to try to continue the debate (directly). I just want to say a few high level things that might help. I'm still curious and I want to be able to have an open conversation with anyone, including you, in the future

I'm quite open minded about all of this still, and I haven't ruled anything out. Maybe I'll be Knots's biggest fan in a few weeks. On the other hand, I'm not even sure yet what my ultimate goals are (what is spam? do we want to suppress it? what's the most effective way to suppress it? how does this interact with other important issues such as miner centralisation?)

I had ignored Bitcoin for a few years, and I only got heavily into Bitcoin news again about six weeks ago. So I have had a lot of catching up to do. I've been on vacation for those six weeks, so I had a lot of time to catch up on many articles and podcasts

I finished watching the rest of that Bitcoin Mechanic video. None of the arguments he presented were new to me. Every point he made, even the smallest ones, were points I had heard in recent weeks. I'm not saying they are bad points, I'm just saying that I've already done my homework. I might be wrong in the big picture, but I have been doing my homework on these topics 😃

I look forward to continuing to learn more, from you and others, about the actual goals and incentives and game theory

SatsAndSports 4mo ago

The more I think about this, the more convinced I am by my idea to delay propagation 😃. #Knots #Spam

Trying to censor these transactions in the mempool will just delay them a little and will transfer money to the permissive miners. Basically, not much good and a bit harmful.

If the goal really is to minimize large op_returns, I want to see a credible proposal that will *incentivize* miners to keep those transactions out of the block. We can't *realistically* stop the permissive miners from seeing these transactions, so instead we can encourage them to keep then out of the block (via delaying propagation of their block)

If my proposal isn't good, then I'd like to see a better one. But I don't think the current Knots approach is a serious approach

(And also, I'm not even sure that op_return limits, even if everybody enforced them, are really the right approach. I'm more concerned about the size of the UTXO set