Can a node drop a transaction.

[Jet Cash]

I've just been watching a video from Bitcoin University, and he seems to suggest that a node can refuse to support a transaction with illegal content. One way he suggests is to use Bitcoin Knots, but he seems to imply that it would be possible for a core node to help in blocking these transactions. I can see that a node could remove a transaction from the mempool he receives, and not relay it in the modified pool. However, what happens if a miner builds a block containing this transaction? I don't see how he can avoid including this in his stored blockchain.

[Mia Chloe]

However, what happens if a miner builds a block containing this transaction? I don't see how he can avoid including this in his stored blockchain.

A Bitcoin node can actually refuse to relay a transaction with illegal content or even because of low fees ( miners do it all the time) by not adding it to its mempool which actually means he won't be broadcasting it to other nodes it's  kinda like a local choice that limits the propagation of that  transaction.

However it doesn't really prevent a miner from including that same transaction in a block. If a miner receives the transaction through another node and successfully mines a block with it they will broadcast this new block to the network as long as the transaction and the entire block adhere to Bitcoin's consensus rules such as valid signatures and proof of work a node has no choice but to accept and store the block in its copy of the blockchain regardless of the content of the transaction in order to stay in sync with the rest of the network.

[Jet Cash]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with. My guess would be that most nodes and miners won't want the overhead of checking transactions, so it would need to be an automatic check in the core software. Spammer support seems to exerting an influence here, and that is a bit concerning.

[mocacinno]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with. My guess would be that most nodes and miners won't want the overhead of checking transactions, so it would need to be an automatic check in the core software. Spammer support seems to exerting an influence here, and that is a bit concerning.

If somebody would program a node to reject certain blocks, whilst they are valid when it comes to the consensus rules at height X, not much would happen. This node would just receive the next block at height X+ 1 and would not be able to verify said block since he has rejected block at height X (and you need the hash of the block header at height X to verify the block at height X+1). The node would just stop being an active part of the network, it could never sync the chain to the same height as the rest of the network, since no miner would create blocks "especially" for the reprogrammed node, a fork would not happen. As far as i know, such functionality does not exist, it would not make any sense to add it.

If a node would reject an unconfirmed transaction (thus, not put it in it's mempool nor relay it), not much would happen either as long as the node isn't hardcoded to reject blocks containing said transaction. Other nodes would put it in their mempool, it would get included in a block and the node rejecting the unconfirmed transaction could still just verify said block (offcourse, if the transaction was invalid, non-standard or had other problems, it's possible most other nodes would reject it aswell... in this case, it would probably never end up in a block, unless some nodes still accepted it and it got mined by pure luck)

[Charles-Tim]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with.

Miners can decide not to include a transaction into the block they want to mine. I think there was a mining pool that proposed to censor transactions from from specific addresses in the past but nothing like that was later done. I do not think this can lead to a soft fork. Also there is nothing yet like a node to reject a transaction if the transaction is valid. No censorship in bitcoin network, although it is possible.

[Cookdata]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with. My guess would be that most nodes and miners won't want the overhead of checking transactions, so it would need to be an automatic check in the core software. Spammer support seems to exerting an influence here, and that is a bit concerning.

Soft fork depend on which other peers the miner is going to be accepting transactions from. To avoid this kind of problems, a miner that doesn't reject illegal transactions may not filter transaction and that means they are running node with major concensus rules. When a miner with modified rules relay a transaction to them, they may reject it since it doesn't tally with what they have in their end.

The miners/nodes didn't write the rule, it's the influence of concensus.

[LoyceV]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with.

Have you seen fork-observer? It visualizes what happens when 2 blocks fork: one gets ignored. In your scenario, in which certain miners reject a certain transaction, those miners will need 51% of the hashrate to win this.

[philipma1957]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with.

Have you seen fork-observer? It shows what happens block forks: it gets ignored. In your scenario, in which certain miners reject a certain transaction, those miners will need 51% of the hashrate to win this.

What happens is 70% of the nodes decide to only accept tx fees of 3 sats  or more and mining pools decide to put fees in of 0.1 sats or more


do we lower the nodes from 20000 to 6000 and the network is weaker.

nodes are cheap is there an attack point here?

A country could easily do 100,000 new nodes for under 250 each or 25 million to launch the attack.

vs 51% of the hash rate which is billions to attack.

[LoyceV]

What happens is 70% of the nodes decide to only accept tx fees of 3 sats  or more and mining pools decide to put fees in of 0.1 sats or more

You'll only need to connect to one node that accepts your transaction to broadcast it further.

[tbct_mt2]

I've just been watching a video from Bitcoin University, and he seems to suggest that a node can refuse to support a transaction with illegal content. One way he suggests is to use Bitcoin Knots, but he seems to imply that it would be possible for a core node to help in blocking these transactions. I can see that a node could remove a transaction from the mempool he receives, and not relay it in the modified pool. However, what happens if a miner builds a block containing this transaction? I don't see how he can avoid including this in his stored blockchain.

Bitcoin node can refuse Bitcoin transactions but it is more likely if that node is from government and they want to censor Bitcoin transactions by their criteria.

Like these fifteen OFAC-sanctioned transactions missing from blocks.
and Six OFAC-sanctioned transactions missing.

Luckily so far there is no mass successful censorship from Bitcoin nodes and mining pools to seriously censor Bitcoin transactions under government request or regulations.

[Mia Chloe]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with. My guess would be that most nodes and miners won't want the overhead of checking transactions, so it would need to be an automatic check in the core software. Spammer support seems to exerting an influence here, and that is a bit concerning.

A miner's refusal to include a specific transaction and another miner's creation of a block without it does not actually create a soft fork because it's kinda like a normal part of how the bitcoin network operates. A soft fork is actually a network upgrade that introduces a new stricter rule which is backward compatible and requires a majority of miners to adopt.

Actually, in the scenario you are talking about no new rules are being introduced. Instead miners are simply exercising their right to choose which transactions from the mempool to include in their block to maximize how much they get from fees. The only thing is the excluded transaction remains in the mempool waiting for a different miner to include it in a future block which is the reason why if your transaction is blocked by many pools you'll need to rebroadcast so others can see it.

Hope you get it?

[Donneski]

What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with. My guess would be that most nodes and miners won't want the overhead of checking transactions, so it would need to be an automatic check in the core software. Spammer support seems to exerting an influence here, and that is a bit concerning.

I grab what you mean, but that’s not really how it works. The thing is if you refuse a block that’s valid by consensus rules, it doesn’t create a soft fork, instead, it just puts your node on its own little fork that nobody else is going to follow. The rest of the network will keep moving forward on the longest valid chain and your node will simply fall out of sync if it keeps rejecting those blocks.

That’s why filtering really only works at the mempool level. Once something makes it into a block that passes consensus checks, a node has to accept it to stay connected. Anything beyond that would require coordinated rule changes across the majority of the network and as you already hinted, most miners/nodes don’t want the hassle of checking every transaction for content.

I hope you my response is clear enough to help you get a better understanding
 

[pooya87]

Bitcoin works as it is supposed to work meaning all nodes must always follow the chain with the most amount of work. That should answer all your questions already. If a certain miner creates an alternate chain re-mining an existing block to exclude a certain transaction, that miner's chain will only grow if most of the network build on top of it as well.

So the real question should be how much of the hash-power is going to implement this particular form of censorship? The answer is that so far none of it. Miners in certain jurisdictions like USA with invasive censorship laws, have refused to include certain transactions in the past but they don't reject other miners' blocks that contain those transactions because that would isolate THEM.

[Jet Cash]

Isn't Bitcoin Knots an attempt to maintain the primary chain with certain transactions excluded. If most of the mempools don't include those transactions, then the current Bitcoin core that includes those transactions will be bypassed. Or have I misunderstood the utily of Bitcoin Knots?

[mocacinno]

Isn't Bitcoin Knots an attempt to maintain the primary chain with certain transactions excluded. If most of the mempools don't include those transactions, then the current Bitcoin core that includes those transactions will be bypassed. Or have I misunderstood the utily of Bitcoin Knots?

I guess you must have misunderstood... There is no way to remove transactions from blocks without invalidating the block. As soon as you remove a transaction from a block, the merkle tree will change, the block header changes due to the merkle tree change, and the sha256d hash of the block header will no longer be under the current target.

So, no full node can ever chose to exclude transactions from blocks whilst still remaining a full node on the main chain.

You could potentially write a node that has extra rules for rejecting unconfirmed transactions, so those transactions don't end up in your mempool, nor do YOU relay said transactions... But once an other node puts them in their mempool and a miner adds them to a valid block, you basically have to validate said block eventough it contains a transaction your node initially rejected when it was unconfirmed and relayed to you.

[Jet Cash]

I think you may have misunderstood me. I appreciate that once a transaction is confirmed on the blockchain, then it is there forever. My point is that nodes are in control of the mempool, and not the blockchain, and so if a large number of nodes run software that excludes certain transactions, then it will make it harder for those transactions to make it into a confirmed block. Of course a rogue miner who finds a block can add that transaction onto the chain. He is then dependant on other miners building on top of his block.

[stwenhao]

My point is that nodes are in control of the mempool, and not the blockchain, and so if a large number of nodes run software that excludes certain transactions, then it will make it harder for those transactions to make it into a confirmed block.

Yes. But how much more difficult is that? If you assume, that 99% of hashing power is censoring something, and only 1% of hashrate can actually confirm your transactions, then still, it means, that even in such conditions, you can get your transactions confirmed once per 100 blocks on average. Which means around "once per day" in practice, as long as your fees are high enough.

[LoyceV]

My point is that nodes are in control of the mempool, and not the blockchain, and so if a large number of nodes run software that excludes certain transactions, then it will make it harder for those transactions to make it into a confirmed block.

In that scenario, I assume mining pools will try hard to connect to the nodes that don't exclude transactions, simply because they earn from the transaction fees.

[Jet Cash]

I've always wondered about the possibility of a bank or financial institution using a private mempool to fill its blocks. Say a bank finances a solar farm which supplies a large village, but isn't connected to an electricity grid, then the surplus electricity ( assuming there is some ) could be used to run a mining farm. This is already being done in some remote locations. Now the bank could build its own mempool, and only include chosen transactions. These get added to the chain when it finds a block. It may not matter if this takes a week or more in some cases. This possibility could become significant as the block reward decreases. could this lead to other miners rejecting the new block, and continuing to try to build on the previous block?

[DaveF]

So longs as the block is valid and built on top of another valid block miners do not care what TXs, if any are in a block.
There are mining pools that allow you to submit the raw transaction to their pool without it ever being seen anyplace else. So long as it's valid it goes in the next block that pool mines.
Does not matter if it's 1 TX or a block full of them.

-Dave