As a regular Full node operator, how can I block a mining pool?

[d5000]

I read in other topics of this forum that there is a way for regular users (with full Bitcoin nodes) to block mining pools - more precisely: to not accept blocks from certain pools.

That would be an interesting option if the current stalemate regarding Segwit continues. For example, if I'm pro-segwit I could be interested in blocking all mining pools that do not signal it. Obviously, as a single node operator I would not make any difference, but if many users join, it could be an interesting way to pressure the mining pools to follow the interests of the majority of users.

So, how must I proceed if I want to do that? Do I need to know the IP address of the pool or can I block a pool directly for messages it sends, for example because not signalling for Segwit? Would there be code changes required? It would be nice if someone could give me an explanation that a non-programmer could understand. Thanks in advance!

(If this topic belongs to Technical Support, feel free to move it.)

[1714173191]

1714173191

[1714173191]

1714173191

[franky1]

your talking about causing an intentional split.

think long and hard about what you want to do to YOURSELF
you are personally wanting to reject blocks and have a different set of data than the rest of the network.. for segwit.(which solves nothing anyway)

yet cry like a baby when anyone proposes a full node consensus that can actually include real fixes(which could include a practical way to implement segwit) which does not cause an intentional split, purely because of fear it may cause a split.

you are basically asking to amputate your leg to pretend your avoiding getting shot in the foot, but the end result is worse then the fear your concerned about.

i think you have been talking to the wrong people selling you scare stories and overselling segwits possibilities.

[franky1]

it definetly shouldnt be done. but it can be done.

its not about IP addresses.. its just about identifying block version numbers and having a code mechanism that auto rejects blocks that have a certain version number

[d5000]

I have no plans to do this, at least for now. I was interested in the mechanism. Anyway, thank you - will investigate more about the version messages.

The goal is to know more about the relation between miners and full node operators. In an ideal Bitcoin world, miners should not be the only rulers of the network, but other node operators also should have a kind of "democratic" power to vote for and against certain changes. It's simply an implication of the soft fork mechanism.

[franky1]

I have no plans to do this, at least for now. I was interested in the mechanism. Anyway, thank you - will investigate more about the version messages.

The goal is to know more about the relation between miners and full node operators. In an ideal Bitcoin world, miners should not be the only rulers of the network, but other node operators also should have a kind of "democratic" power to vote for and against certain changes. It's simply an implication of the soft fork mechanism.

miners are NOT the rulers.

what you have to understand is blockstream bypassed real consensus.
pools are not stupid enough to produce something that nodes are not prepared for. pools only produce what the nodes will accept. not the other way round. (otherwise what they make is orphaned off and a waste of even trying to make it)

so this is where core has failed with their soft implementation. 60% of pools are undecided because although blockstream allowed the pools to be the sole voters. the pools are still waiting to see what nodes desire.

blockstreams mindset is if segwit activates blockstream will take the glory, if fail they will blame the pools. blockstreams game plan is obvious.
dont blame pools when it was blockstream that decided.

just think about the fake reason blockstream decided that route. and then realise your own reaction. which even contravenes blockstreams fake reason to go that route.

[odolvlobo]

I read in other topics of this forum that there is a way for regular users (with full Bitcoin nodes) to block mining pools - more precisely: to not accept blocks from certain pools.

You can refuse to accept any blocks that don't signal segwit. You will need to modify the code in order to do that. However, be aware that your block chain will be stuck because there are no miners that will build on your self-imposed fork.

Perhaps a workable approach would be to refuse to relay any blocks that don't signal segwit. The effect would be to increase the probably of those blocks being orphaned, albeit only by a tiny amount.

[d5000]

Perhaps a workable approach would be to refuse to relay any blocks that don't signal segwit. The effect would be to increase the probably of those blocks being orphaned, albeit only by a tiny amount.

That second method, I think, was the technique I read. Do you know if that requires code changes?

Now, if we think about that scenario, wouldn't that be a possible sybil attack vector? A person or group interested in "bringing through" a soft fork proposal could possibly spawn thousands of nodes worldwide and then influence the miners' decision by giving them economic incentives to accept the soft fork. Obviously it would not be a real attack because the blockchain would not be affected, but I think that scenario cannot be easily avoided.

[Velkro]

As a regular Full node operator, how can I block a mining pool?

That would be risky, i mean, dangerous precedence.
U have officially no reason to block miners as long as you run official bitcoin code (it handle malicious miners automatically).

So be very carefull what you want to accomplish here, because in reality you could cause very bad things for bitcoin as a whole.

[odolvlobo]

As a regular Full node operator, how can I block a mining pool?

That would be risky, i mean, dangerous precedence.
U have officially no reason to block miners as long as you run official bitcoin code (it handle malicious miners automatically).

So be very carefull what you want to accomplish here, because in reality you could cause very bad things for bitcoin as a whole.

There is no "official bitcoin code".

[unamis76]

There are many custom clients on the network, coded for different features, so this is definitely possible. Given the current situation regarding Bitcoin and scaling, if I knew how to code such, I wouldn't post it publicly (or anywhere, for that matter) and I hope people with knowledge follow the same. Time to come together and not split everyone. Being "picky" is exactly what we don't need right now.

PS: I understood that the OP doesn't necessarily want to do this and was questioning out of curiosity...

[ImHash]

You could do that and get banned as retaliation, honestly I only run a node 6 hours a day in a CNC factory office and never understood anything other than a hot PC even with liquid nitrogen cooling system.
What you trying to do is creating a fork for software version like BU/classic etc. what you could do is to ban IPs running any version other than Core

As a regular Full node operator, how can I block a mining pool?

That would be risky, i mean, dangerous precedence.
U have officially no reason to block miners as long as you run official bitcoin code (it handle malicious miners automatically).

So be very carefull what you want to accomplish here, because in reality you could cause very bad things for bitcoin as a whole.

There is no "official bitcoin code".

Wrong, there is a source reference code that needs consensus to even change a dot in the code.
And for software the Core is the official.

[Jerean]

You can do that but you shouldn't do that.

[mezzomix]

As a regular Full node operator, how can I block a mining pool?

That would be risky, i mean, dangerous precedence.
U have officially no reason to block miners as long as you run official bitcoin code (it handle malicious miners automatically).

So be very carefull what you want to accomplish here, because in reality you could cause very bad things for bitcoin as a whole.

The mechanism is to to withhold a non-segwit block until a segwit block extends this block. If a segwit block with the same height is received, this segwit block is relayed instead of the non-segwit block.

This mechanism makes sense if most nodes would like to change the system but some of the miners are blocking this change.

[d5000]

As discussed with mezzomix in the German subforum, the "sybil attack" scenario would only be a danger if there is indecision among the node operators to accept or not accept a soft fork proposal - that's if the majority of nodes are "apolitical".

If a large majority of the real users that operate a node (above all, service providers and merchants) do support a soft fork change then it should not be too relevant if the opposite side launches a sybil attack spawning thousands of nodes - because they would only be "circlejerking" and distribute blocks in their own "sub-network". (I have to think a bit more thoroughly about it, however, as I'm not completely sure there could not be an incentive to launch that kind of attack).

[DooMAD]

A similar idea was floated in the development and technical subforum back in November, but rather than blocking entire pools, simply ignored individual blocks.  The outcome would be the same, though. 

[dinofelis]

I read in other topics of this forum that there is a way for regular users (with full Bitcoin nodes) to block mining pools - more precisely: to not accept blocks from certain pools.

Non mining nodes have 0 to say about the block chain.  The ONLY thing that non mining nodes can do, is to signal to miners what the MARKET SENTIMENT might be if they do or not do something.  Because miners are sensitive to market sentiment: after all, it are the users on who the miners dump their gains in coin, and it are the users that finance the miners.

But that's it.

I've written already quite some posts about this total misunderstanding of how a proof of work consensus system works, and WHY non mining nodes are totally meaningless (apart for their owners).   Please read this:

https://bitcointalk.org/index.php?topic=1821817.msg18175256#msg18175256

https://bitcointalk.org/index.php?topic=1821817.msg18170595#msg18170595

https://bitcointalk.org/index.php?topic=1821817.msg18178541#msg18178541

https://bitcointalk.org/index.php?topic=1820846.msg18155418#msg18155418

https://bitcointalk.org/index.php?topic=1827198.msg18192654#msg18192654

TL;DR:

A crypto currency is a group of miners making the block chain, and a group of users doing transactions on that block chain against value.  Users need to get their transactions into the block chain by miners, and miners need to obtain transactions from users, and sell their gains to users.    Miners need to communicate well amongst themselves to build the block chain and not get their blocks orphaned.  So a strong miner network, and good network infrastructure by them towards users, is all that is needed.

[dinofelis]

A similar idea was floated in the development and technical subforum back in November, but rather than blocking entire pools, simply ignored individual blocks.  The outcome would be the same, though. 

If a node "blocks" (considers invalid) a single block, and that block is part of what the miners call the main chain, then that node simply stops working.   While the miners continue happily to make the block chain.   Suppose that I don't want to see a specific transaction, and I write node software that considers a given transaction invalid (a soft fork !).  Well, that node will take the block chain until it finds the block with that transaction, and considers that block invalid.  And will never ever hear about another block that follows it, and come to a halt.  Period.  In what way did my node stop that chain to be built ?

You think that if almost all non-mining nodes do that, miners will be obliged ?  Why ?  They connect amongst themselves and continue to make the blocks THEY have a consensus on.  And users (say, exchanges) don't want their nodes to stop, so they connect directly to miner nodes to get the growing chain.  Because the other nodes simply don't send anything any more.  In what way do non-mining nodes interfere ?

Of course, miners may be sensitive to the fact that most non-mining nodes don't want this, and might "vote in the market" if they don't comply to users' wishes.  They might be afraid that the market cap of their coin drops.  So miners will most probably take into account this "market sentiment" signal.  But that's it.