We might be screwed. The devs are all more interested in squabbling than discussing. Both sides. What I'd like is a scorecard of previous disputes and who stood where and the outcome. Proof of work. And I'd like them to talk to each other respectfully and publicly, for the purpose of educating plebs.

i do not feel comfortable telling people to run knots until it has better review and release processes in place if you do not want to relay larger op return transactions then run core v29 (the most recent version of core) and do not update to v30 when it is released alternatively you can run v30 with a modified config file i think luke, mechanic, and most core contributors mean well and care about bitcoin long term i want to see more well reviewed bitcoin implementations exist, more choices for node operators is strictly better, this is one of the reasons i have donated my time to build out opensats i think this ‘debate’ has mostly devolved into social attacks and is mostly unproductive i do not think it matters much for the global bitcoin network which client you run, in this specific situation i have said much on this topic in the past, use the search feature if you are curious

I’ve been curious your opinion on the matter. Thank you. 🤝

This is lucid

Indeed!

Fair enough 🫡

Run what you want, but run away from people telling you you’re dumb for running a specific client.

yeah. and if you are smart and not really a fan of anal, you'll run #knots

This is opinion is natural to slightly biased to core. The reason why people are running knots even without the best review is because we feel offended and betrayed.

Who reviews core? Knots is a minor fork of Core.

Lol, remember Bitcoin Classic, Bitcoin Unlimited and Bitcoin Cash. They ultimately lead to the fork in 2017. Back in the day the "Core" argument was that alternatives are dangerous. We've came a long way since then.

> Knots is a minor fork of Core. How do you know, have you reviewed it ?

Cooler heads prevail. Best "NOT TWITTER" explanation I have seen.

The code for the consensus rules should be in a separate library, and that library should be used by all implementations I'm usually all for having a variety of open implementations, but we need to avoid an y chance of a hard fork that is accidentally introduced via an accidental change in consensus code. This happened in March 2013

Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks

Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks

Bitcoin Magazine

Bitcoin Network Shaken By Blockchain Fork

Yesterday, the Bitcoin network experienced one of the most serious hiccups that we have seen in the past four years. Starting from block 225430, the

Well said. The voice of reason.

a 💯 . right now it’s a distraction imho

this is being worked on easier said than done

@ODELL could you be more specific regarding what a "better review and release process" looks like? Or at least what it definitely doesn't look like. How many reviewers would make you feel more comfortable, what is the best release process you've seen in another project etc.

What review and release process would you consider sufficient to recommend Knots or any other implementation?

This only works in the short term. Eventually you will need the security patches for Core 30, 31, 32, 33... They're going to force this eventually. Staying on v29 is a short term solution. We I do agree we need Knots to grow in its governance to be a true competitor to Core.

Or just update to v30 and change the datacarrier limit. Keeps OP_RETURN limits as is.

If that's something you are concerned about, which is another conversation.

Most of the competent bitcoin software engineers review Core in a formal rough consensus review process (look it up). How do you know knots is a minor fork and isn’t introducing a security flaw? Is that based on your ability to review code? If other bitcoin software engineers thought took the time to review knots and decided it had a flaw, how would they stop Luke from publishing an update he wants published?

Wen taproot ? Or am i late ? That’s about where I am 😂

you're talking about long term, but do you think core 30 may cause a short/mid term problem though? we have a precedent with what happened on bsv, when they raised op return to 100kb and i don't understand yet why this huge risk is being taken so lightly. "just don't update your node" won't be helpful, when other people do update and stuff ends up on a block

Good call

I have this exact thought bouncing around in my brain, as such the just don't update line makes no sense to me. not to be a doomer but i don't see how this change doesn't destroy the p2p layer of bitcoin.

Both are open source. Any developer can review Knots. BTW yes I could review Knots code. I am a developer too.

The original point from Odell was about the review release PROCESS. Do you participate in the review release process for knots or are you just another “I could review it if I wanted to”. If you do, great, please explain the process to us and how you would prevent Luke from publishing something he thinks is good but the other knots developers thinks is a security risk.

All it takes is one miner not using OP_RETURN filters for all nodes, including yours, to store illicit material. This is the only argument they should refute or substantiate much better. At this point, and given what's happening, I think influential people are definitely compromised.