Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 11
Generated: 17:04:43
I agree with this, everyone should be free to filter and boost what they want... However the solution is to get Core to finish their consensus library so people can implement as many clients and even as many relay networks as they want, safely. Core centralisation is causing too much headache at this point. nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qythwumn8ghj7cnfw33k76twv4ezuum0vd5kzmp0qqst8txpq5epcr88lefxexnyd0254xya7w78sqyurdr3hu3gsw3zh0cwctkas
2025-09-10 12:23:21 from 1 relay(s) 1 replies ↓
Login to reply

Replies (11)

Of course they have, they've always had. This is not something new. What's intriguing to me it is WHY suddenly Bitcoin Core client development centralisation is more important to some people? I'd have thought it to happen related to some consensus change... but it's 'just' about some relay change? Some relay change that it's not having any impact in what is going mined into the blocks! This is not really about some p2p network change. This is just an excuse to use FUD and grab power.
2025-09-10 14:53:28 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
because they have presumed to remove a user-configurable option that impacts spammy transactions on the chain, not just removed it but set such a large default you can now easily jam a small low resolution JPG image into it, and big enough to jam malware binaries into the chain and have them replicate across the network, causing virus checkers to flag errors and interfere with the function of the node. IMO this indicates that there should be a rethink around the subject of mempool filter logic to push it out to user-definable custom filter programs so they are not going to affect users' ability to control what their node relays. it is not clear what is the motivation for this change in mempool policy by core developers but they should just get their hands off the USERS prerogative to filter mempool relaying by making it possible to delegate all filtering to an external executable that accepts new mempool entries and regulates when new blocks will be propagated by the node (so users can set them to not relay a new best block with spam in it, in case within a short time another block that doesn't appears). also, if you thought that client centralization isn't an issue in bitcoin until suddenly now, you obviously haven't read very much of the history of bitcoin's inception or the changes along the way. this has been an issue in some people's minds for a long time. the most recent last time it popped up was because of lightning network being predominantly LND with BTCD running the node client and an improper check that was not in spec that caused nodes to go offline. this was the beginning of the hacks on the datacarrier setting that emerged due to the way taproot was specified, and there was spectacular traffic jams in mempool traffic for months afterwards.
2025-09-10 15:01:30 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
also, making a change that weakens spam protection in bitcoin core is the power grab you are speaking of. which is clearly motivated by enabling non-monetary use of bitcoin chain. idk what the logic is that knots devs allowing users to retain their previously entrenched ability to control certain settings is interpreted by you as meaning that knots is engaged in a power grab. this is completely backwards. core devs have tried to seize power to push something on the network due to their dominant position and the result has been that some 2000-4000 new nodes running knots appeared on the network with contrary settings. do you think people just go out of their way to run a node to support someone else's alleged power grab? i don't think so. the logic that core changing policy in new versions for mempool was used as a crisis to seize power is ridiculous, because they are EXERCISING power to try and change mempool policy contrary to the will of so many people that some started running a node to give the middle finger to them.
2025-09-10 15:06:12 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
Core itself is working on the libbitcoinkernel because they want to get rid of this influence on the network because it brings them nothing but headache... Currently implementing a competing client risks consensus bugs, which is why they have that influence over non consensus matters. As soon as libbitcoinkernel is finalized, everyone can build whatever the fuck they want and stay in consensus.
2025-09-10 15:13:16 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
Sure, that's something known and acknowledged years ago, and Core even started working on a solution as you explained. What amazed me it's that suddenly Core is accused of centralisation as if it's something new that they have provoked?? Nonsense. FUD-based power grab.
2025-09-10 15:17:35 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
"suddenly" lol, whatever, you don't really know what you are talking about. i've been talking about it *myself* for years also. but i guess you don't count any data you don't agree with as valid contrary opinion to yours. you are just a parrot, repeating your hero's mantras.
2025-09-10 15:19:05 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
What are you taking about?? There's no consensus change in Core v30. There has always been several ways to store data in Bitcoin blockchain. Bitcoin is censorship resistant, the point it's you can not avoid my consensus-valid transaction to get mined.
2025-09-10 15:23:36 from 1 relay(s) ↑ Parent Reply
Mate, you could have been talking about it years ago, good for you, but it didn't have the effect in the public discourse that it's having now. This public effect of last weeks it's what I'm talking about. What hero are you talking about, Mr. Peacock?
2025-09-10 15:36:53 from 1 relay(s) ↑ Parent Reply