Why Bitcoin Core should stay the main Bitcoin implementation?

[PepeLapiu]

That really looks good and is exactly what I was wishing I think it has active support from Core devs and thus has some chance to materialize. It seems however still WIP and I either haven't found an ETA.

It's interesting that some Core devs, like the new maintainer "sedited" (aka TheCharlatan), think that this could even be a step towards "solving" disagreements over policy decisions like the "spam" debate. Maybe even PepeLapiu approves it See https://blockspace.media/insight/a-conversation-with-bitcoin-cores-newest-maintainer/

I don't know much about him. So I can't form an opinion. But that he was nominated by maxi hating shitcoiner DEI hire Zhao makes me suspicious of him. And that he was ACK by a bunch of shitcoin devs also makes me nervous about him.

I'm of the opinion that a lot of work would be required to reform and save core. Dare I say too much work?

[d5000]

I'm of the opinion that a lot of work would be required to reform and save core. Dare I say too much work?

In the final "installment" of the sequence of events that would lead to a modular Core, Core would not take care anymore about node policy.

And policy was the essence of the debate.

You could then import libbitcoinkernel into your own node implementation and choose whatever policy you want as a default. So why do you need a "reform" in this situation? Only because you hate the Core devs?

The only problem of this arrangement is that policy default values could lead again to a more diverse policy values landscape, e.g. some sticking with the old OP_RETURN limit, some with some intermediate value, and some with the complete freedom of Core 30. And that, again, would weaken the compact block mechanism.

But it's likely even with libbitcoinkernel a dominant Bitcoin implementation would emerge, and most would use the most proven one with the best maintainers (not the ones with the "best ideology", mind you, but those who technically can guarantee a safe client). As long as the consensus isn't touched I would not care if it's called Core or Knots or whatever.

[PepeLapiu]

I'm of the opinion that a lot of work would be required to reform and save core. Dare I say too much work?

In the final "installment" of the sequence of events that would lead to a modular Core, Core would not take care anymore about node policy.

I don't know what you are talking about. But the idea of a decentralized mempool policy decided by each and every node sounds pretty good to me.

You could then import libbitcoinkernel into your own node implementation and choose whatever policy you want as a default.

Never heard of libbitcoinkernel before. So I'll have to look into that. No clue what you are talking about here.

So why do you need a "reform" in this situation? Only because you hate the Core devs?

Please stop making such reductionist statements. Core pays lip service to "bitcoin as money" while actively promoting spam on chain. They trashed an ordinal filter as "too controversial" yet they still don't think blowing up the op_return filter was too controversial. Even after they lost 25% of their nodes to Knots and caused a reactionary soft fork. They refer to spam as "use cases we have today" and they refer to spammers as "users who need arbitrary data on chain".

And this is why "I need a reform", buddy.

The only problem of this arrangement is that policy default values could lead again to a more diverse policy values landscape, e.g. some sticking with the old OP_RETURN limit, some with some intermediate value, and some with the complete freedom of Core 30. And that, again, would weaken the compact block mechanism.

Yes, freedom and decentralised mempool policy is a messy thing. That's the arguement coretards make: "We need a standardized and centralized mempool policy to save bitcoin."

Are you buying it? I'm not.

But it's likely even with libbitcoinkernel a dominant Bitcoin implementation would emerge, and most would use the most proven one with the best maintainers (not the ones with the "best ideology", mind you, but those who technically can guarantee a safe client). As long as the consensus isn't touched I would not care if it's called Core or Knots or whatever.

Consensus was touched to implement Segwit and Taproot. But it's only now that BIP110 is being implemented that you suddenly don't want to touch consensus?

We are going to fix the bugs and exploits in Segwit and Taproot. With or without you. But please do join us. You'll love being a Knotzi. You'll get to strangle cute puppies like the rest of us Knotzies love to do.

[Dogedegen]

What are your thoughts on this one? I see it as very important and it has been in development for a really long time, I do not know if there is even an estimate to completion.

That really looks good and is exactly what I was wishing I think it has active support from Core devs and thus has some chance to materialize. It seems however still WIP and I either haven't found an ETA.

Things have been happening for that project for a long time, but the pace is sporadic so sometimes many things are happening but other times there is very little activity. This is one of the cases where I wish we could get people who work on Core to communicate more. There are communication ways which would cost them a lot of time, but occasional 1 hour AMA with some volunteer handling question collection would not harm anyone I believe. I would love to get some direct questions from people who work on these without appearing as a random weirdo in their emails if they have some that are public. That would have lower chance of getting an answer.

It's interesting that some Core devs, like the new maintainer "sedited" (aka TheCharlatan), think that this could even be a step towards "solving" disagreements over policy decisions like the "spam" debate. Maybe even PepeLapiu approves it See https://blockspace.media/insight/a-conversation-with-bitcoin-cores-newest-maintainer/

I didn't even know that there was a new maintainer! So it is actually the guy that is working on the kernel that is the maintainer? We are quite lucky then as this makes the chance of our desired project happening much higher! The article even mentions a part about communication that I wrote above.

Sedited says that awareness of this consensus project and its status are low because “we’ve not done a good job at giving incremental updates on how things are progressing. That’s totally on us.”

I really hope to see this happen in some reasonable period of time even if there is no estimate yet.

I am not sure whether I welcome that because I know that many people use this wallet and like it, even if the GUI maybe lacks on some features?

I think there should be definitely some GUI for Core, but the idea as far as I remember was to leave the GUI issue to third-party devs. On the other hand, the Core GUI is well known and maybe if third party devs change it too much it could force people to change workflows. It's however very likely someone would continue to maintain the traditional GUI.

I would hope that it remains part of the project traditionally, and if someone wants to develop a third-party GUI alternative right now nothing prevents them from doing that? How much can it be to keep the GUI maintained even if it does not posses advanced features like Electrum does? It can't be that much in terms of man power?

[d5000]

I didn't even know that there was a new maintainer! So it is actually the guy that is working on the kernel that is the maintainer?

Yes he seems to be the maintainer of the Rust bindings (https://github.com/sedited/rust-bitcoinkernel).

I would hope that it remains part of the project traditionally, and if someone wants to develop a third-party GUI alternative right now nothing prevents them from doing that?

Technically, Sparrow and Electrum can already be used as third party GUIs for Core, using bitcoind as node. There are other third party GUI projects like Specter Desktop.

I don't know what you are talking about.

An increased modularization of the Core project. The devs responsible for consensus issues could then care only about making validation and other core stuff like Bitcoin Script and node to node messaging better.

"Minor" issues like networking optimizations and .... policy would be outsourced to other projects. Of course you can't forbid a Core kernel dev to participate in the policy projects, but ideally they would stay in separate repos.

But the idea of a decentralized mempool policy decided by each and every node sounds pretty good to me.

It's part of the features of Bitcoin Core already since day 1. Surprise!

But I guess what you mean is on node implementation level, i.e. that all node implementations can ship with their own policy while using Core's kernel. Essentially, there is not really a difference between both approaches. Either you override a default in Core or Knots, or you do the same thing downloading another "policy project".

That's the arguement coretards make: "We need a standardized and centralized mempool policy to save bitcoin."

There are subtle differences between the real technical challenge and your reductionist wording. Nobody said it's needed to "save" Bitcoin. But it makes node operation easier and less costly.

As I already noticed some months ago in another thread, I think you and most Knots folks don't really like node operators. At least you propose lots of stuff which would be a headache for them, not only forcing them to download transactions several times, but also incentiving new kinds of fake private and public key techniques and other UTXO set polluting stuff.

Consensus was touched to implement Segwit and Taproot. But it's only now that BIP110 is being implemented that you suddenly don't want to touch consensus?

I have initially had a little bit of hope that from BIP 110 something interesting could emerge, like a really convincing anti spam consensus scheme as an emergency plan B if some new spam wave appeared. But they decided to rush an amateurish "BIP" even if all evidence points to no spam wave threat at all (you know the links I'm referring to, don't play dumb).

But the point that for me was essential to reject BIP 110 energically is the 55% miner consensus. Never a consensus change was attempted with such a low threshold to my knowledge.  This is simply playing with Bitcoin's integrity, with absolutely no urgence at all. It's nuts from a security/technical standpoint.

We are going to fix the bugs and exploits in Segwit and Taproot.

On a separate chain, I imagine. I'd love to gamble a bit with KnotsieCash if he manages a pump just like 2017's BCash pump.

But then you'll face the harsh reality: spam will also be possible on KnotsieCash, not even much more expensive than with Bitcoin (de facto it will be cheaper because KnotsieCash fees will be as low as BCash fees, and friends of illegal content will love that). It has been shown.

[PepeLapiu]

But the idea of a decentralized mempool policy decided by each and every node sounds pretty good to me.

It's part of the features of Bitcoin Core already since day 1. Surprise!

But I guess what you mean is on node implementation level, i.e. that all node implementations can ship with their own policy while using Core's kernel. Essentially, there is not really a difference between both approaches. Either you override a default in Core or Knots, or you do the same thing downloading another "policy project".

Sorry, but computer nerds who might be very good coders, but are still computer nerds none the less, should have no access to mempool and relay policy.

In Knots, there is no such thing as Knots mempool policy. Knots provides us with filters and thought they all have defaults, they are easily configurable in a simple tab.

If you decided to filter out inscriptions or ordinals, your centralized core devs already decided those are two controversial for you to be allowed to play with.

Telling users they can change one small part of their policy by editing .config files is a fucking joke.

That's the arguement coretards make: "We need a standardized and centralized mempool policy to save bitcoin."

There are subtle differences between the real technical challenge and your reductionist wording. Nobody said it's needed to "save" Bitcoin. But it makes node operation easier and less costly.

Yes, of course. Centralized systems are always easier, less messy, and more efficient. But centralization is the cancer of bitcoin, wouldn't you know.

As I already noticed some months ago in another thread, I think you and most Knots folks don't really like node operators. At least you propose lots of stuff which would be a headache for them, not only forcing them to download transactions several times, but also incentiving new kinds of fake private and public key techniques and other UTXO set polluting stuff.

You can be forgiven since you likely never ran Knots. If you did, you would know about the secondary mempool where all your filtered out tx go. A feature core doesn't have, but a good idea for miners. And for node operators who wish to save on bandwidth.

You also don't know how Knots is a great deal easier to install, with a beautiful GUI, and easily accessible filter tab.

but also incentiving new kinds of fake private and public key techniques and other UTXO set polluting stuff.

No idea what you are talking about here.

Consensus was touched to implement Segwit and Taproot. But it's only now that BIP110 is being implemented that you suddenly don't want to touch consensus?

I have initially had a little bit of hope that from BIP 110 something interesting could emerge, like a really convincing anti spam consensus scheme as an emergency plan B if some new spam wave appeared. But they decided to rush an amateurish "BIP" even if all evidence points to no spam wave threat at all.
[/quote]

I think you fail to realize BIP110 is not technically an anti-spam fork. It's about stopping known contiguous data that can occur without a third party such as SlipStream. And unlike previous soft forks, it's only temporary for a year. So if something horrible is to occur due to the new limits, we can rectify it after the year is over. I think it's a very sensitive thing to do. Just imagine the pain we could have saved ourselves if we had done the same with Taproot, as I remind you over 95% of Taproot users are spammers, grifters, and attackers.

For sure, once BIP110 passes, we will have affirmed bitcoin is money, not dickbutts. And other measures can be implemented.

I have a problem with too complex of an update that almost certainly results in unintended consequences. Know what I mean, jelly bean?

(you know the links I'm referring to, don't play dumb).

I'm not playing, I really am dumb. I get by on my looks.
What link? That stupid crying Luke TIFF bullshit piece?

But the point that for me was essential to reject BIP 110 energically is the 55% miner consensus. Never a consensus change was attempted with such a low threshold to my knowledge.  This is simply playing with Bitcoin's integrity, with absolutely no urgence at all. It's nuts from a security/technical standpoint.

What's nuts and wreckless is the Segwit and Taproot upgrades pushed through without a fail safe llike a temporary update, or refusing to fix the bugs and exploits. Even going as far as renaming bugs as features by changing the documentation.

The 55% treshold only applies to the miner activation part of it. And that is only likely to happen if some illicit material gets on chain. Like child p**n or other stuff. It was a compromise to the reactive activation, which was really unworkable in a logical way.

We are going to fix the bugs and exploits in Segwit and Taproot.

On a separate chain, I imagine. I'd love to gamble a bit with KnotsieCash if he manages a pump just like 2017's BCash pump.

But then you'll face the harsh reality: spam will also be possible on KnotsieCash, not even much more expensive than with Bitcoin (de facto it will be cheaper because KnotsieCash fees will be as low as BCash fees, and friends of illegal content will love that). It has been shown.

Back away from the pipe, son. There won't be a hard fork or separate coin. And spam will always exist at some level. Just like mice will always find a way into a barn. And you will keep pretending that barns with cats don't have fewer mice than barns without cats.

And you fail to recognize a state level attack that swamps the chain with illicit and offensive material in continuous form all relayed by the p2p network, without a third party involved, is a serious threat. In fact it's so obvious that I believe it's planned that way.

I have 3 mosquito zapper machines in my backyard. So I can sit and have a coffee or beer without getting swamped with mosquitoes. And of course I understand that the zappers will never completely get rid of all the mosquitoes. And only an idiot would get bit by one mosquito and declare my zappers are failing.

Same with spam on bitcoin. It's always going to be a continuous fight. There will always be spammers crying censorship. There will always be some idiots who will cry that we must cater to spammers by fear that they might use fake pubkeys.

And BTW, ask yourself why core was not worried at all about the UTXO set when they ignored Luke's inscription filter as too controversial.

But when in service of blowing up a spam filter, they suddenly started to care about UTXO bloat and that was not too controversial?