Bitcoin Forum
November 11, 2025, 02:53:03 PM *
News: Latest Bitcoin Core release: 30.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Core dev Murch deciding policy?  (Read 24 times)
PepeLapiu (OP)
Member
**
Offline Offline

Activity: 159
Merit: 65


View Profile
Today at 10:34:34 AM
 #1

So in the following video you can watch Murch (core dev) explain the core side of the current spam war. I invite you to watch it before you keep reading:

https://www.youtube.com/live/3BFgoQawG7Q

While you watch or listen, I invite you to pay attention to how many times Murch talks about policy, not code. How often he explains what the core policy is, or should be.

It's important to understand that these core devs get on the core team based on their coding skills, not based on their politics or policy skills.

It's important also to understand that bitcoin is decentralized far more than other cryptos. Now when I say decentralized, I don't mean the miners as over 80% of the mining is controlled by just a handful of mining pools.

I don't mean code maintenance either as a handful of core devs decide what should get into 80% of the nodes code.

The only part of bitcoin that is still truly decentralized is the nodes. As there are over 25,000 nodes on the network, operated for free by individual bitcoiners.

The main job of these 25,000 nodes is to ensure that users and miners behave. IE no double spend, you own the coin you spend, miners are being honest, and so on....

Without the nodes, bitcoin would be a highly institutionalized and corporate controlled network. We don't want this.

We don't want the miners to decide what they can mine without consequences. We don't want the core devs to decide how nodes should operate without consequences. What we want is more power to the nodes to keep the network decentralized.

But every time Murch talks about core policy, he is basically telling you how you should operate your node, how you will be told to operate your node.

I don't think cors should emphasize on policy so much. They are coders, not policy enforcers. The devs should be  giving the tools for the nodes to decide policy on our own. Each and everyone of us should be able to decide what is acceptable in a block, and what is not acceptable in a block.

We should be provided with more filter, user configurable filters. Not be forced to apply whatever policy core decided is acceptable.

Join the fight, run a Knots node:
https://bitcoinknots.org/

Bitcoin is not a dickbutt jpeg repository.
Join the fight against turning bitcoin into spamware.
BitcoinKnotsForum.com
DaveF
Legendary
*
Offline Offline

Activity: 4018
Merit: 6925



View Profile WWW
Today at 12:04:57 PM
 #2

VS the policy of knots which is whatever Luke wants.

I'll stick with Core since I might want to send my coins someplace one day that Luke disagrees with.

How luke operates: https://bitcointalk.org/index.php?topic=816578.0

-Dave

This space for rent.
PepeLapiu (OP)
Member
**
Offline Offline

Activity: 159
Merit: 65


View Profile
Today at 02:09:08 PM
 #3

VS the policy of knots which is whatever Luke wants.

That's incorrect. Knots allows you to decide for yourself if you want to filter out spam or not. In fact there is a tab included for it. He doesn't tell you to filter anything. He just gives you the tools to decide for yourself what you want to put in your mempool and relay to others.

Quote
I'll stick with Core since I might want to send my coins someplace one day that Luke disagrees with.

That would imply that filters are a form of financial censorship.

Filters have been in place since day one. The op_return filter has been in place for 11 years, alongside other filters.

Nobody ever complained about censorship until about 7 months ago when filters suddenly became a form of censorship.

How did that happen? Did the magic smoke escape the filters?

Bitcoin is not a dickbutt jpeg repository.
Join the fight against turning bitcoin into spamware.
BitcoinKnotsForum.com
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!