51 Node attack

[Qosmos_81]

Hi everyone

I know what a 51 % miner attack is, but does a 51 % node attack exists?
If i understand it correct nodes check transactions if thy are valid. if some node doesnt follow the rules , it got kicked from the network.
But if some party owns 51 % of the nodes, can they change the rules ? can they accept false transactions? Or Can they only make a hardfork because they dont follow the rules anymore?

thank you in advance
Qosmos

[ranochigo]

No they cannot.

The nodes can do whatever they want, accepting invalid transactions, accepting blocks with thousands of block regards, etc. However, as you've mentioned, nodes enforces the rules themselves. No matter how many nodes an attacker controls, the set of rules that each node enforces cannot be changed. They will not accept any invalid blocks, transactions, messages, etc and they will be kicked after hitting the ban limit for the nodes.

The miners also cannot dictate the rules directly nor can they violate any rules if they want it to be accepted by the nodes.

[BlackHatCoiner]

If i understand it correct nodes check transactions if thy are valid. if some node doesnt follow the rules , it got kicked from the network.

A node that doesn't accept the consensus rules is simply not accepted from other nodes. Just like a Litecoin node isn't accepted from a Bitcoin node. They both follow different rules.

But if some party owns 51 % of the nodes, can they change the rules ? can they accept false transactions?

There's hereby a possible misunderstanding of how a node works. If you're running a Bitcoin node, you are following some hard-coded consensus rules and at the same time, you're receiving blocks. The blocks you're receiving aren't “gulped” from your node. It verifies every single block it receives to see if it's valid according to the consensus rules it follows.

The entire Bitcoin network is made up of nodes making their own decisions, but they each make the same decisions as one another. That being said, a 51% node attack doesn't hold water.

Or Can they only make a hardfork because they dont follow the rules anymore?

A hard fork can be created from anyone. You don't have to be the owner of those 51%.

[Qosmos_81]

Thank you guys
I understand it clearly now.

[pooya87]

The only type of attack that one can perform by controlling a large number of nodes (not necessarily 51% of them but juts a large number) is Sybil attack. In this attack the attacker fills the network with their own nodes and could connect to your node and fill all its connection slots to effectively cut it off from the rest of the network. Then they can prevent your node from broadcasting transactions, seeing new blocks, etc.

The worst thing that can happen is if Sybil attack is combined with some mining power. The attacker, after isolating the victim's node, could perform a double spend while cutting that node off from seeing the double spent transaction and mine a block to contain an invalid tx (already spent) that pays that node's operator.

[ranochigo]

The only type of attack that one can perform by controlling a large number of nodes (not necessarily 51% of them but juts a large number) is Sybil attack. In this attack the attacker fills the network with their own nodes and could connect to your node and fill all its connection slots to effectively cut it off from the rest of the network. Then they can prevent your node from broadcasting transactions, seeing new blocks, etc.

The worst thing that can happen is if Sybil attack is combined with some mining power. The attacker, after isolating the victim's node, could perform a double spend while cutting that node off from seeing the double spent transaction and mine a block to contain an invalid tx (already spent) that pays that node's operator.

These attack should probably work better with MITM attacks and the attacker can possibly restrict the peers that they can connect to. It is usually quite targeted and specific as well, instead of it being a general attack as that'll be quite impractical given both the financial limitation as well as Bitcoin Core's node connection policy (IIRC it restricts the number of connections to each subnets). A single connection to a non-attacker controlled node will render this attack ineffective as well.

Both of them are possible but the scope of the attack is quite limited as well and doesn't make much sense financially.

[pooya87]

These attack should probably work better with MITM attacks and the attacker can possibly restrict the peers that they can connect to. It is usually quite targeted and specific as well, instead of it being a general attack as that'll be quite impractical given both the financial limitation as well as Bitcoin Core's node connection policy (IIRC it restricts the number of connections to each subnets). A single connection to a non-attacker controlled node will render this attack ineffective as well.

Both of them are possible but the scope of the attack is quite limited as well and doesn't make much sense financially.

You are right, this is a weak and limited type of attack and there are ways to fight it that are already implemented in bitcoin core. This is also a bigger concern for those who may accept 0-confirmation transactions but at the same time those have more serious things to worry about rather than Sybil attack.
P.S. There is a list here: https://en.bitcoin.it/wiki/Weaknesses

[PrimeNumber7]

The only type of attack that one can perform by controlling a large number of nodes (not necessarily 51% of them but juts a large number) is Sybil attack. In this attack the attacker fills the network with their own nodes and could connect to your node and fill all its connection slots to effectively cut it off from the rest of the network. Then they can prevent your node from broadcasting transactions, seeing new blocks, etc.

The worst thing that can happen is if Sybil attack is combined with some mining power. The attacker, after isolating the victim's node, could perform a double spend while cutting that node off from seeing the double spent transaction and mine a block to contain an invalid tx (already spent) that pays that node's operator.

The best way to prevent a Sybil attack is to have at least one node whose identity is not public. In order to execute a Sybil attack, the attacker needs to know about all of your nodes and cut them off from the rest of the network accordingly. If you have one node that is secret, the attacker has no way to know to cut off that node, and you can be aware of the attack attempt.

A Sybil attack also does not need to have mining power if the victim is willing to accept 0/conf transactions.

[ranochigo]

The best way to prevent a Sybil attack is to have at least one node whose identity is not public. In order to execute a Sybil attack, the attacker needs to know about all of your nodes and cut them off from the rest of the network accordingly. If you have one node that is secret, the attacker has no way to know to cut off that node, and you can be aware of the attack attempt.

Not exactly. It does nothing if the attacker is actively listening to your connections, ie. a public wifi of some sorts. I'm not sure if this is the case but it wouldn't work if Bitcoin Core will tell the peers about the nodes you know about upon receiving a getaddr message. Trying to connect through another type of network or using some form of secure communication would reduce the chances of a successful MITM.

Implementing anchors.dat does help with the situation somewhat by mitigating the possibility of eclipse attack.

[PrimeNumber7]

The best way to prevent a Sybil attack is to have at least one node whose identity is not public. In order to execute a Sybil attack, the attacker needs to know about all of your nodes and cut them off from the rest of the network accordingly. If you have one node that is secret, the attacker has no way to know to cut off that node, and you can be aware of the attack attempt.

Not exactly. It does nothing if the attacker is actively listening to your connections, ie. a public wifi of some sorts. I'm not sure if this is the case but it wouldn't work if Bitcoin Core will tell the peers about the nodes you know about upon receiving a getaddr message. Trying to connect through another type of network or using some form of secure communication would reduce the chances of a successful MITM.

If the attacker knows of your connections, you do not have a secret node. The attacker knows of all the nodes you are using. If you are using public wifi, you could connect to your home computer (that is also a node), which connects (not via a node) to another node on a VPS that only you are aware of. The attacker might be able to Sybil your home computer node, but would not be able to Sybil your VPS node, and you can be alerted of the attack and act accordingly.

[ranochigo]

If the attacker knows of your connections, you do not have a secret node. The attacker knows of all the nodes you are using.

It is quite hard to prevent any leakage of the connections that you have. Getaddr does have privacy measures but if a person is determined enough, they can still achieve it though with much more difficulty. As I've mentioned in my previous post, without a MITM, it would be fairly hard for an adversary to execute a sybil attack that affects the security to that extent. Something like this would require a (relatively large) amount of resources with different IP ranges, and a huge number of nodes it to be even possible, not regarding the feasibility.

Having a secret or a trusted node can be a solution but it is definitely not necessary or doable for most, unless the final node that you're connecting to is definitely not getting sybil'ed, then you're safe. If it isn't then you're just wasting your resources. The counter against such attacks is the cost and the features of Bitcoin Core.

If you are using public wifi, you could connect to your home computer (that is also a node), which connects (not via a node) to another node on a VPS that only you are aware of. The attacker might be able to Sybil your home computer node, but would not be able to Sybil your VPS node, and you can be alerted of the attack and act accordingly.

Connections between nodes are not encrypted. Packets can be dropped by the adversary and there is simply no way to detect something like this happening if the attacker can intercept the packets.

[PrimeNumber7]

If the attacker knows of your connections, you do not have a secret node. The attacker knows of all the nodes you are using.

It is quite hard to prevent any leakage of the connections that you have. Getaddr does have privacy measures but if a person is determined enough, they can still achieve it though with much more difficulty. As I've mentioned in my previous post, without a MITM, it would be fairly hard for an adversary to execute a sybil attack that affects the security to that extent. Something like this would require a (relatively large) amount of resources with different IP ranges, and a huge number of nodes it to be even possible, not regarding the feasibility.

Having a secret or a trusted node can be a solution but it is definitely not necessary or doable for most, unless the final node that you're connecting to is definitely not getting sybil'ed, then you're safe. If it isn't then you're just wasting your resources. The counter against such attacks is the cost and the features of Bitcoin Core.

If you are using public wifi, you could connect to your home computer (that is also a node), which connects (not via a node) to another node on a VPS that only you are aware of. The attacker might be able to Sybil your home computer node, but would not be able to Sybil your VPS node, and you can be alerted of the attack and act accordingly.

Connections between nodes are not encrypted. Packets can be dropped by the adversary and there is simply no way to detect something like this happening if the attacker can intercept the packets.

If you are using a secret node, you could wait for an affirmative response from the secret node before accepting the transaction.

I may have been unclear in my previous posts. A setup would be as follows:
*Someone is running a node on a public WiFi network -- this is potentially vulnerable to a Sybil
*Your computer on the public WiFi network connects to your home computer via an encrypted connection -- your home computer is running a full node and is vulnerable to a Sybil if an attacker is attempting to attack you specifically, although this type of Sybil is more difficult to pull off.
*Your home computer has an encrypted connection to a VPS (or other computer on a different network) via an encrypted connection that will relay block/transaction information to your laptop via software other than bitcoin software. An attacker trying to specifically attack you will have no way to know they need to Sybil the node running on the VPS.

[ranochigo]

I may have been unclear in my previous posts. A setup would be as follows:
*Someone is running a node on a public WiFi network -- this is potentially vulnerable to a Sybil
*Your computer on the public WiFi network connects to your home computer via an encrypted connection -- your home computer is running a full node and is vulnerable to a Sybil if an attacker is attempting to attack you specifically, although this type of Sybil is more difficult to pull off.
*Your home computer has an encrypted connection to a VPS (or other computer on a different network) via an encrypted connection that will relay block/transaction information to your laptop via software other than bitcoin software. An attacker trying to specifically attack you will have no way to know they need to Sybil the node running on the VPS.

Are you guarding against MITM attacks specifically? IMO Sybil or Eclipse attacks are not cheap nor that great of a concern. It should be better to make Bitcoin Core use Tor instead of complicating things by chaining multiple nodes and probably incur much more costs as well. If it is a targeted attack, then you're just reducing the probability of the attacker influencing the nodes which Bitcoin Core should connect to. The attacker has to figure out your onion address and the nodes for which you're connected to for a successful eclipse attack which could be quite difficult.

There are safeguards against eclipse attack implemented in Bitcoin Core. Having a secure connection between your node and the other nodes would defeat MITM and the safeguards would do the rest.

[PrimeNumber7]

I may have been unclear in my previous posts. A setup would be as follows:
*Someone is running a node on a public WiFi network -- this is potentially vulnerable to a Sybil
*Your computer on the public WiFi network connects to your home computer via an encrypted connection -- your home computer is running a full node and is vulnerable to a Sybil if an attacker is attempting to attack you specifically, although this type of Sybil is more difficult to pull off.
*Your home computer has an encrypted connection to a VPS (or other computer on a different network) via an encrypted connection that will relay block/transaction information to your laptop via software other than bitcoin software. An attacker trying to specifically attack you will have no way to know they need to Sybil the node running on the VPS.

Are you guarding against MITM attacks specifically? IMO Sybil or Eclipse attacks are not cheap nor that great of a concern. It should be better to make Bitcoin Core use Tor instead of complicating things by chaining multiple nodes and probably incur much more costs as well. If it is a targeted attack, then you're just reducing the probability of the attacker influencing the nodes which Bitcoin Core should connect to. The attacker has to figure out your onion address and the nodes for which you're connected to for a successful eclipse attack which could be quite difficult.

There are safeguards against eclipse attack implemented in Bitcoin Core. Having a secure connection between your node and the other nodes would defeat MITM and the safeguards would do the rest.

Using SSL would prevent any MTIM attack with the setup I describe. Using TOR is slow, and is not scalable for the entire network. TOR would also increase the chances of a successful Sybil attack, as an attacker could create many malicious nodes. Also, .onion addresses are subject to timing attacks that can lead to de-anonymization.

Being on a public WiFi means the WiFi provider can impersonate any IP address or domain so long as SSL is not being used to authenticate. SSL is (very incrementally) slower than unencrypted communications, and the majority of nodes are not running on a potentially malicious ISP, so nodes will probably not be willing to connect via SSL on any large scale.

[seoincorporation]

...
Using SSL would prevent any MTIM attack with the setup I describe. Using TOR is slow, and is not scalable for the entire network. TOR would also increase the chances of a successful Sybil attack, as an attacker could create many malicious nodes. Also, .onion addresses are subject to timing attacks that can lead to de-anonymization.

Being on a public WiFi means the WiFi provider can impersonate any IP address or domain so long as SSL is not being used to authenticate. SSL is (very incrementally) slower than unencrypted communications, and the majority of nodes are not running on a potentially malicious ISP, so nodes will probably not be willing to connect via SSL on any large scale.

I know SSL looks secure, but we can't trust it at all... I remember some years ago when I was learning about the MITM attack there was a tool called SSLstip that allow us to attack even if the users were on a secure socket layer. I will leave this link for those who want to learn more about this tool.

https://tools.kali.org/information-gathering/sslstrip

And about the topic, if 51 Node attack would be possible, then anyone could kill bitcoin with virtual machines  The only ones who can do this kind of attack are the miners and not the ones who have a node.

[PrimeNumber7]

...
Using SSL would prevent any MTIM attack with the setup I describe. Using TOR is slow, and is not scalable for the entire network. TOR would also increase the chances of a successful Sybil attack, as an attacker could create many malicious nodes. Also, .onion addresses are subject to timing attacks that can lead to de-anonymization.

Being on a public WiFi means the WiFi provider can impersonate any IP address or domain so long as SSL is not being used to authenticate. SSL is (very incrementally) slower than unencrypted communications, and the majority of nodes are not running on a potentially malicious ISP, so nodes will probably not be willing to connect via SSL on any large scale.

I know SSL looks secure, but we can't trust it at all... I remember some years ago when I was learning about the MITM attack there was a tool called SSLstip that allow us to attack even if the users were on a secure socket layer. I will leave this link for those who want to learn more about this tool.

https://tools.kali.org/information-gathering/sslstrip

And about the topic, if 51 Node attack would be possible, then anyone could kill bitcoin with virtual machines  The only ones who can do this kind of attack are the miners and not the ones who have a node.

My reading on this attack makes me believe that an SSLstrip attack would not work against the setup I am proposing.

The connection between your public WiFi laptop and your home computer would be initiated via SSL, and if the information being relayed back from your home computer to your public WiFi laptop is not returned via SSL, you will know there is a problem and that you may be the subject of a MITM attack. A SSLstrip attack needs both of the above to not be true.

Detecting a MTIM attack is just as good as preventing it because you will know not to trust anything you receive via the internet.