Topic: As a regular Full node operator, how can I block a mining pool? (Read 1274 times)

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.

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://bitcointalksearch.org/topic/m.18175256

https://bitcointalksearch.org/topic/m.18170595

https://bitcointalksearch.org/topic/m.18178541

https://bitcointalksearch.org/topic/m.18155418

https://bitcointalksearch.org/topic/m.18192654

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.

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. 

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).

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.

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

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

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.

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...

There is no "official bitcoin code".

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.

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.

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.

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.

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.

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

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.

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.)