A core node add-on store?

[PepeLapiu]

So I've been tinkering with the idea of creating an add-on store for core node runners. This would be a website or app that would allow you to install your chosen filters on your core node.

The problem I want to fix is mempool policy centralisation. For the last 5 years under this current spam attack, core has repeatedly refused to provide the nodes with appropriate filters. When Luke Dashjr proposed a filter for inscriptions, core rejected it. Core decided their nodes (99% of the network) should not be allowed to run this filter.

Same with the op_return filter. A year ago, core decided that their nodes should no longer be allowed to run the op_return data carrier filter.

This is centralisation at it's best and it needs to be fought against.

So I'm thinking of creating an app store for code nodes. Where there would be various add-ons you could install on your core node.

You want to bring back the op_return filter on your core 30 node? No problems, there's an app for that.
You want an ordinal filter on your core node? No problems, there is a app for that.

And each filter would have an explanatory video of what it does. And default setting, why the default, and how you could change it.

Any dev could submit an add-on to the store.

What do you guys think?

[Upgrade00]

How would a third party website or app override changes and updates made on Bitcoin core which nodes use to connect to the network? If that were possible we would have people creating such applications and allowing different features, even potential security risks that were discovered and fixed at an earlier time.

[(BTC)]

When trying to make changes or additions to node running software, especially bitcoin's, the concept of consensus tears a huge hole through your idea.

Upgrade mentioned a good flaw with a core app store being the security risks. Not many people would come together on a consensus to support something that would breed security risks because of third party developers creating apps that very few people would use on a third party website.

You'd be dealing with people of a cypherpunk mindset, and your idea sounds alot like how they view browser extensions. Many people concerned with opsec hate extensions for the security risks, and use as few, or none at all, at all times.

There's also overcomplication. Core is supposed to be software level node running software to keep bitcoin decentralized alongside miners. There's no reason to have an app store for it.

This sounds like something Solana or some other smart contract-centered chain would appeal to.

[Yamane_Keto]

What do you guys think?

Do you mean that your idea is to download a Chrome Web Store extension or Add-ons for Firefox to do something like that

Code:

datacarriersize=80
datacarrier=0
permitbaremultisig=0

It will be difficult to convince them of the need to download this add-on.

[DaveF]

Never going to work.
Nobody who is sane is going to want to have 3rd party things installed on their node if they have any BTC in it.

If some malicious setting comes in, are you going to take responsibility for it if someone looses money?

Just about anything that matters can be changed by putting a line of text in the conf file which you can do by hand anyway.

-Dave

[ertil]

The problem I want to fix is mempool policy centralisation.

Which means, that you want to also make block propagation worse. Because there is a difference between having a few transactions, which are relayed only by some nodes, and between making a completely different block, than everyone else.

If each and every miner would produce a completely different 4 MB block, then block propagation would be terrible, because everyone would need to always download everything.

When Luke Dashjr proposed a filter for inscriptions, core rejected it.

And you know why? Because if transactions won't be relayed in the P2P network, then they would be passed outside of it. Which means, that people will submit them to the biggest mining pools, and smaller ones will never hear about such transactions.

The fact, that things like Slipstream exists at all, is a clear sign, that too many transactions were blocked. Because otherwise, people would just relay them in the P2P network, and they wouldn't need to submit them through such centralized places.

You want to bring back the op_return filter on your core 30 node? No problems, there's an app for that.
You want an ordinal filter on your core node? No problems, there is a app for that.

You can stop relaying any transactions at all, if you want to. There are some nodes, which can only relay blocks. And then, you will block all existing spam. But of course, if more people would do that, then you would need to be a miner, to use the network.

[PepeLapiu]

How would a third party website or app override changes and updates made on Bitcoin core which nodes use to connect to the network? If that were possible we would have people creating such applications and allowing different features, even potential security risks that were discovered and fixed at an earlier time.

First and foremost each filter or add-on would be posted on github, open source, and reviewable by anyone who wishes to do so.

I see 3 different ways this could be implemented:

1- Each add-on would have to decompile the core code, edit it to add the filter, and recompile. This way, you could keep the "Core" label on the box. But it's not a very efficient way to do things.

2- Not touch the core code at all. But instead, we put the filter "on the wire" ahead of the node to intercept all incoming transactions and filter at that level. So say you want to filter large op_returns. All incoming large op_return would be intercepted and blocked ahead of the node. So filtered before the node even sees it.

3- A new implementation client based on core. Maybe branded Core++ ? This implementation would be identical to core, but with the ability to add "filter add-ons".

I tend to prefer the 3rd option. But not sure at the moment.

(blah-blah-bla)

At this point you are not even worth replying to.

Never going to work.
Nobody who is sane is going to want to have 3rd party things installed on their node if they have any BTC in it.

You mean like the confiscation bug in core 30 that was deleting wallets? Like that?

If some malicious setting comes in, are you going to take responsibility for it if someone looses money?
Just about anything that matters can be changed by putting a line of text in the conf file which you can do by hand anyway.
-Dave

Nothing is 100% proof safe. Core 30 deleting wallets is a pretty good example of this. And it's pretty evident when core was warned of this problem before they even launched core 30, and ignored the concerns.

But like everything else in bitcoin,  the filters would be open source, posted on github, and reviewable.

Could a bug or exploit occur? Sure! But are we going to pretend that never happens with holier than thou core software?