Will there ever be any monetary incentives to run a full node?

[GGUL]

~
if SPVs are useless for security but properly implemented SPVs are not prone to attacks, then how are full nodes helping secure the blockchain more than SPVs are? Like, if the latter is not that hard to attack, then (putting privacy to the side) why should one choose full node over SPV?

SPV clients aren't useless for security, they just provide lower level of it. There are certain attack vectors that exist only for SPV clients.
For example imagine during the 2017 shenanigans you were running a SPV node and a chain split (or multiple splits) occurred. Your client is not capable of knowing which chain it wants to follow hence you don't know where your transaction ends up in, so you'll have to trust the node you are connecting to and follow what it follows without any say in it. Meanwhile a full node that verifies the entire blockchain knows the difference between each chain and can easily follow what it wants, so it has full control.
There is also the problem with number of confirmation, during the same time a SPV client has to wait for much larger number of confirmation (100+) whereas the full node doesn't.

If a full node can distinguish between a good chain and a bad one, I see no reason why such functionality cannot be added to the SPV client.
It's only a matter of timely updates, just like for full nodes.

You can also reduce the probability of an attack if the SPV client works with more than one full node and duplicates requests to N full nodes.

[gmaxwell]

If a full node can distinguish between a good chain and a bad one, I see no reason why such functionality cannot be added to the SPV client.
It's only a matter of timely updates, just like for full nodes.

Then they would *be* full nodes.  What allows a full node to tell a rule complying node from a rule violating node is that they fetch all the data from all the blocks and apply the rules of the system to make sure the blocks are valid.

You can also reduce the probability of an attack if the SPV client works with more than one full node and duplicates requests to N full nodes.

It's extremely easy for attackers to spin up huge numbers of fake nodes. If "ask more nodes" provided meaningful security bitcoin wouldn't have had mining at all.

[GGUL]

If a full node can distinguish between a good chain and a bad one, I see no reason why such functionality cannot be added to the SPV client.
It's only a matter of timely updates, just like for full nodes.

Then they would *be* full nodes.  What allows a full node to tell a rule complying node from a rule violating node is that they fetch all the data from all the blocks and apply the rules of the system to make sure the blocks are valid.

If it is known how the block number N in one chain will differ from the block number N in another chain, then what prevents the spv-client from downloading this block and checking it. Downloading a single block once every 5 years does not make it a full node.

You can also reduce the probability of an attack if the SPV client works with more than one full node and duplicates requests to N full nodes.

It's extremely easy for attackers to spin up huge numbers of fake nodes. If "ask more nodes" provided meaningful security bitcoin wouldn't have had mining at all.

If it is very easy to create many fake nodes for spv nodes, what prevents you from creating many fake nodes for full nodes? If the spv client connects to 8 full nodes, and the full node connects to 8 full nodes, then the cost of surrounding them with fake full nodes will be the same. I don't see the benefits of a full node.

[ranochigo]

If it is known how the block number N in one chain will differ from the block number N in another chain, then what prevents the spv-client from downloading this block and checking it. Downloading a single block once every 5 years does not make it a full node.

What client downloads a single block once every 5 years? A full node does its own validation of the blockchain. That's why it doesn't have to trust anyone else. SPV clients are completely different. The easiest way to mitigate this is probably by downloading and validating the blockchain. For which you'll probably just make another full node. It doesn't compare block height because it's grossly inaccurate to assume the height to be X at unix time X because of the changing hashpower.

If it is very easy to create many fake nodes for spv nodes, what prevents you from creating many fake nodes for full nodes? If the spv client connects to 8 full nodes, and the full node connects to 8 full nodes, then the cost of surrounding them with fake full nodes will be the same. I don't see the benefits of a full node.

How do you trick a full node? Feed a full node a chain full of transactions that doesn't follow the rules, it'll refuse too accept, no matter how much proof of work it has. SPV clients lack the full blockchain that full nodes has and it thus has to assume that the longest chain is the honest valid chain. It will not specifically check each block for it's validity and thus if you were to feed SPV clients (in the context of sybil attacks) with block headers that doesn't follow the protocol rules, the SPV client will blindly accept them. In contrast, since the full node validates the entire blockchain, it will ensure that each and every block has a valid POW and all of the transactions follows the protocol rules.

The damage that you can potentially do with SPV client is a lot more than what you can do with a full node only.

[GGUL]

If it is known how the block number N in one chain will differ from the block number N in another chain, then what prevents the spv-client from downloading this block and checking it. Downloading a single block once every 5 years does not make it a full node.

What client downloads a single block once every 5 years? A full node does its own validation of the blockchain. That's why it doesn't have to trust anyone else. SPV clients are completely different. The easiest way to mitigate this is probably by downloading and validating the blockchain. For which you'll probably just make another full node. It doesn't compare block height because it's grossly inaccurate to assume the height to be X at unix time X because of the changing hashpower.

If there is no possibility now, it doesn't mean that it can't be done.
If there is information in the blockchain that can be used to determine which of the chains you need, you can always get this information from the full node without downloading the entire chain from the very beginning. A chain of block headers ensures that this information is correct.

It will not specifically check each block for it's validity and thus if you were to feed SPV clients (in the context of sybil attacks) with block headers that doesn't follow the protocol rules, the SPV client will blindly accept them.

To feed the spv client a fake chain of block headers in real time, the attacker must have ~50% of the hashrate power.

[ranochigo]

If there is no possibility now, it doesn't mean that it can't be done.
If there is information in the blockchain that can be used to determine which of the chains you need, you can always get this information from the full node without downloading the entire chain from the very beginning.

I don't like to fantasize about things so I'll prefer if there is at least a proof of concept that is available.

What information are you trying to get from the blockchain??? How would you know if the full node you're referring to is telling the truth???

To feed the spv client a fake chain of block headers in real time, the attacker must have ~50% of the hashrate power.

OR, be the only source of information that the SPV wallet have. You'll in effect be able to feed the SPV client whatever you need, and you probably wouldn't need that much hashpower at all. The lack of information makes it seems like you're the 100% of the network and you are the (only) person who has the longest chain, proof of work wise. I think I can't make my point about sybil attacks clearer than it already is.

You really have to explain your points clearly, I'm having a lot of difficulty trying to understand what you're trying to say. I don't think Bitcoin is meant to be operated when you have to trust someone.

[GGUL]

If there is no possibility now, it doesn't mean that it can't be done.
If there is information in the blockchain that can be used to determine which of the chains you need, you can always get this information from the full node without downloading the entire chain from the very beginning.

I don't like to fantasize about things so I'll prefer if there is at least a proof of concept that is available.

What information are you trying to get from the blockchain??? How would you know if the full node you're referring to is telling the truth???

This information will be located in a block. This block will have a header that only miners can make. And the miners who make this header check the block for correctness. A non-mining full node will not be able to make a header for a block with incorrect information.

To feed the spv client a fake chain of block headers in real time, the attacker must have ~50% of the hashrate power.

OR, be the only source of information that the SPV wallet have.

This is not enough. To create a fake block header, you need to find the hash of this block with the appropriate hash rate. If you don't have the mining capacity, you can't do it.

[aliashraf]

I challenge this claim of you. I tried it out but couldn't find a single reason for an SPV wallet to wait for more confirmations just because of using SPV technology. Please elaborate.

In the top situation when a split has happened, the full node is well aware of the existence of the other chain (it may be 1 block to whatever number) but it will not tell the SPV client so SPV client doesn't know there is a split. The full node is only following one chain (Node A the red chain, Node B the blue chain where circles represent blocks).
* If the SPV client is connected to Node A and its tx is included in a red block it will think that its tx is confirmed without any issue.

The bottom situation is what happens next and there are 2 circumstances:
Under normal circumstance, the assumption is that the stale chain is not going to grow that big so a smaller number of confirmation is enough. It usually is one or two blocks though.

In any other time (like 2017 example assuming there were higher risk of chain split) each of those red/blue chains can grow a lot longer than normal since Node A and Node B may be following different consensus rules, and more importantly Node A and Node B will not switch to the other chain even if it is the "longest".
* So now the same SPV client above thinks its tx is confirmed in the red block while connected to Node A with a chain that doesn't grow and doesn't reorg while the rest of the network is building on top of blue chain with the green blocks and SPV client's tx may have been double spent already without it knowing.

I think your assessment falls short of justifying the claim I challenged. Chain splits are either intentional (because of a hard fork) or unintentional for the latter type of splits there is no difference between full nodes and SPV wallets but in the case of hard forks, waiting for more confirmations does not help an SPV wallet to get rid of the forked chain.

Obviously SPV technology is not designed to help nodes deciding about the consensus rule changes, and they are not useful in the network for dealing with such events, so I do strongly agree with your general hesitance about giving too much credit to this technology but underrating it and asserting that users of SPV wallets need 100 confirmations for securely relying on their wallets, is too much.

[aliashraf]

You can also reduce the probability of an attack if the SPV client works with more than one full node and duplicates requests to N full nodes.

It's extremely easy for attackers to spin up huge numbers of fake nodes. If "ask more nodes" provided meaningful security bitcoin wouldn't have had mining at all.

With all due respects, promoting fake nodes is not that much effective in getting innocent participants sybil-attacked because once it becomes viral that such a threat actually exists a mitigation strategy is easily adoptable:
Users can in turn install n>1 nodes (starting with 2) on different network segments, making a static connection between them mandatory. It is mathematically provable that for the attacker to "surround" all n nodes, hiding the actual longest chain from the user this way, grows exponentially harder with n.

[PrimeNumber7]

I challenge this claim of you. I tried it out but couldn't find a single reason for an SPV wallet to wait for more confirmations just because of using SPV technology. Please elaborate.

In the top situation when a split has happened, the full node is well aware of the existence of the other chain (it may be 1 block to whatever number) but it will not tell the SPV client so SPV client doesn't know there is a split. The full node is only following one chain (Node A the red chain, Node B the blue chain where circles represent blocks).
* If the SPV client is connected to Node A and its tx is included in a red block it will think that its tx is confirmed without any issue.

<>

I believe you are referring to a Sybil attack. I don't think this is a problem unique to SPV clients solely because it is a SPV client. You might argue that SPV clients tend to have certain behaviors that are different than full node clients that might make them more vulnerable to a Sybil attack.

[ranochigo]

This information will be located in a block. This block will have a header that only miners can make. And the miners who make this header check the block for correctness. A non-mining full node will not be able to make a header for a block with incorrect information.

Then you have to assume that the information is only located within the honest chain. What stops someone from isolating you from the rest of the network and build a rogue chain with similar information and thereby tricking your node? The block header will have transparent information and it is not possible to implement such a system without some degree of reliance on a third party.

This is not enough. To create a fake block header, you need to find the hash of this block with the appropriate hash rate. If you don't have the mining capacity, you can't do it.

If a SPV wallet doesn't implement checkpoints, it would theoretically be fairly easy to trick the SPV wallet by building an alternative chain. Since that chain is the only chain the client will see, it is assumed to be the longest valid chain. With a checkpoint system, the attacker will have to build the chain after the checkpoint which is significantly more difficult but will not require anywhere near 50% of the network's hashpower.

You see, the reason why 51% attack works is because it can generate valid blocks faster than the rest of the network. You don't need anywhere near 51% of the hashpower if you have all the time in the world. I can probably generate a block with enough POW in a few days if I purchase enough hashpower. I don't need to worry about someone else generating the block before me because the client won't be able to see it.

[gmaxwell]

If there is no possibility now, it doesn't mean that it can't be done.
If there is information in the blockchain that can be used to determine which of the chains you need, you can always get this information from the full node without downloading the entire chain from the very beginning.

It would be nice if it were true, but it is not.  In the Bitcoin protocol you cannot verify the transactions in a block without the transactions each of those transactions is spending the output from (to obtain their amounts, heights, and scriptpubkeys), along with _all_ transactions between those transactions and the current block to verify that the outputs being spent weren't already spent by another block.

A block can easily be invalid in a way which I cannot convince you that the block is invalid without sending you most of the blockchain (or with other similarly currently non-pratical approaches).  Some types of invalidity can be efficiently be shown, yes, but an attacker just wouldn't use one of those.

A chain of block headers ensures that this information is correct.

No, all the headers show is that proof of work was applied.  This is the SPV security assumption: that if there is proof of work the blocks will also be valid, because miners would not have chosen to throw away work on blocks that nodes will ignore.  This assumption is only plausible so long as a significant portion of economically important users are not using SPV.

[GGUL]

This information will be located in a block. This block will have a header that only miners can make. And the miners who make this header check the block for correctness. A non-mining full node will not be able to make a header for a block with incorrect information.

Then you have to assume that the information is only located within the honest chain. What stops someone from isolating you from the rest of the network and build a rogue chain with similar information and thereby tricking your node? The block header will have transparent information and it is not possible to implement such a system without some degree of reliance on a third party.

Lack of mining capacity.
Let's fix the fact that a non-mining node cannot deceive the spv client. So I don't have to go back to it.

This is not enough. To create a fake block header, you need to find the hash of this block with the appropriate hash rate. If you don't have the mining capacity, you can't do it.

If a SPV wallet doesn't implement checkpoints, it would theoretically be fairly easy to trick the SPV wallet by building an alternative chain. Since that chain is the only chain the client will see, it is assumed to be the longest valid chain. With a checkpoint system, the attacker will have to build the chain after the checkpoint which is significantly more difficult but will not require anywhere near 50% of the network's hashpower.

What does "easy" mean? If the attacker has 10% of the capacity, then he will create 6 blocks in 10 hours. During this time, he will lose more than half a million dollars. At the same time, the spv client should not guess anything. There is no setting that the spv client should work with a single full node. I already wrote above about a well-implemented spv client. So, if the spv client works with a wide pool of full nodes, then this attack loses all meaning.

Note that if a full node only works with such an attacker and no one else, then the attacker can similarly deceive this full node by preparing a fake block chain for it. The only difference is that the blocks should look correct. And this attack does not cost by the fact that the full node checks the block, but by the fact that the full node connects to many full nodes and learns about the existence of other chains.

As you can see, there is not much difference between a full node and spv clients.

If there is no possibility now, it doesn't mean that it can't be done.
If there is information in the blockchain that can be used to determine which of the chains you need, you can always get this information from the full node without downloading the entire chain from the very beginning.

It would be nice if it were true, but it is not.  In the Bitcoin protocol you cannot verify the transactions in a block without the transactions each of those transactions is spending the output from (to obtain their amounts, heights, and scriptpubkeys), along with _all_ transactions between those transactions and the current block to verify that the outputs being spent weren't already spent by another block.

A block can easily be invalid in a way which I cannot convince you that the block is invalid without sending you most of the blockchain (or with other similarly currently non-pratical approaches).  Some types of invalidity can be efficiently be shown, yes, but an attacker just wouldn't use one of those.

So you don't need to check the entire block, you don't need to check transactions. This block contains information that can be used to determine which chain this block belongs to. It is enough to get this information.

A chain of block headers ensures that this information is correct.

No, all the headers show is that proof of work was applied.  This is the SPV security assumption: that if there is proof of work the blocks will also be valid, because miners would not have chosen to throw away work on blocks that nodes will ignore.  This assumption is only plausible so long as a significant portion of economically important users are not using SPV.

What does "significant portion" mean? Now, according to various estimates, from 50-100 thousand users use full nodes. And there are about 10 million users in total. That is, less than 1% of users use. Is this still a "significant portion" or not?
I would like to learn more about the dependence of spv clients on the number of full node users.

To be honest, it is doubtful. Let's take an extreme case, we have 20 miners, there are no non-mining full nodes, all work through the spv client, which are connected to the miners. And spv clients duplicate requests to different miners. How can I cheat the spv client? The only answer I came up with was only having more than 50% of the mining capacity in one hand.
Conclusion, non-mining full nodes do not add much protection.

[TofuDefi]

If a SPV wallet doesn't implement checkpoints, it would theoretically be fairly easy to trick the SPV wallet by building an alternative chain. Since that chain is the only chain the client will see, it is assumed to be the longest valid chain. With a checkpoint system, the attacker will have to build the chain after the checkpoint which is significantly more difficult but will not require anywhere near 50% of the network's hashpower.

You see, the reason why 51% attack works is because it can generate valid blocks faster than the rest of the network. You don't need anywhere near 51% of the hashpower if you have all the time in the world. I can probably generate a block with enough POW in a few days if I purchase enough hashpower. I don't need to worry about someone else generating the block before me because the client won't be able to see it.

51% attack is about receiving coins on a wrong chain, not sending. So even if you will be able to isolate SPV wallet owner on a wrong chain how it will help to attack him?

[PrimeNumber7]

If a SPV wallet doesn't implement checkpoints, it would theoretically be fairly easy to trick the SPV wallet by building an alternative chain. Since that chain is the only chain the client will see, it is assumed to be the longest valid chain. With a checkpoint system, the attacker will have to build the chain after the checkpoint which is significantly more difficult but will not require anywhere near 50% of the network's hashpower.

You see, the reason why 51% attack works is because it can generate valid blocks faster than the rest of the network. You don't need anywhere near 51% of the hashpower if you have all the time in the world. I can probably generate a block with enough POW in a few days if I purchase enough hashpower. I don't need to worry about someone else generating the block before me because the client won't be able to see it.

51% attack is about receiving coins on a wrong chain, not sending. So even if you will be able to isolate SPV wallet owner on a wrong chain how it will help to attack him?

It could trick them into believing they received coins via an invalid transaction.

[TofuDefi]

If a SPV wallet doesn't implement checkpoints, it would theoretically be fairly easy to trick the SPV wallet by building an alternative chain. Since that chain is the only chain the client will see, it is assumed to be the longest valid chain. With a checkpoint system, the attacker will have to build the chain after the checkpoint which is significantly more difficult but will not require anywhere near 50% of the network's hashpower.

You see, the reason why 51% attack works is because it can generate valid blocks faster than the rest of the network. You don't need anywhere near 51% of the hashpower if you have all the time in the world. I can probably generate a block with enough POW in a few days if I purchase enough hashpower. I don't need to worry about someone else generating the block before me because the client won't be able to see it.

51% attack is about receiving coins on a wrong chain, not sending. So even if you will be able to isolate SPV wallet owner on a wrong chain how it will help to attack him?

It could trick them into believing they received coins via an invalid transaction.

Well, this is something very unlikely to happen. If we talk about regular user, transaction can be very easily checked on any block explorer which is hard to fake. Big players usually use more subtle tech than just SPV wallet/node.

[PrimeNumber7]

If a SPV wallet doesn't implement checkpoints, it would theoretically be fairly easy to trick the SPV wallet by building an alternative chain. Since that chain is the only chain the client will see, it is assumed to be the longest valid chain. With a checkpoint system, the attacker will have to build the chain after the checkpoint which is significantly more difficult but will not require anywhere near 50% of the network's hashpower.

You see, the reason why 51% attack works is because it can generate valid blocks faster than the rest of the network. You don't need anywhere near 51% of the hashpower if you have all the time in the world. I can probably generate a block with enough POW in a few days if I purchase enough hashpower. I don't need to worry about someone else generating the block before me because the client won't be able to see it.

51% attack is about receiving coins on a wrong chain, not sending. So even if you will be able to isolate SPV wallet owner on a wrong chain how it will help to attack him?

It could trick them into believing they received coins via an invalid transaction.

Well, this is something very unlikely to happen. If we talk about regular user, transaction can be very easily checked on any block explorer which is hard to fake. Big players usually use more subtle tech than just SPV wallet/node.

I was describing the risk to using a SPV client. Using a block explorer may be one way to mitigate that risk. However as ETF said, it is atypical for someone to check a block explorer if it doesn’t appear that anything is wrong.

[BrewMaster]

I was describing the risk to using a SPV client. Using a block explorer may be one way to mitigate that risk. However as ETF said, it is atypical for someone to check a block explorer if it doesn’t appear that anything is wrong.

to be fair checking a transaction on a centralized block explorer is still risky. you are not just nullifying your privacy you are also trusting that website to not have any issues or not be malicious. it may be malicious and give false information or it simply may be severely buggy, for example the explorer called blockchain.info (now changed to .com) has always been popular and has always been very buggy!

[PrimeNumber7]

I was describing the risk to using a SPV client. Using a block explorer may be one way to mitigate that risk. However as ETF said, it is atypical for someone to check a block explorer if it doesn’t appear that anything is wrong.

to be fair checking a transaction on a centralized block explorer is still risky. you are not just nullifying your privacy you are also trusting that website to not have any issues or not be malicious. it may be malicious and give false information or it simply may be severely buggy, for example the explorer called blockchain.info (now changed to .com) has always been popular and has always been very buggy!

Using a block explorer in addition to a SPV client will incrementally increase security. If it is being buggy, it would give a false indication that you should not rely upon a transaction that the SPV client is saying was received. At worst, you would have the same security as relying on a SPV client alone.

You are correct in saying that using a block explorer may result in reduced privacy, but this is something you would need to weigh with the potential impact on security.

[GGUL]

The security of using the spv-client can easily be raised to a full-node if you teach the spv-client to work through a wide pool of full-nodes.

But... I think that such functionality is not added because the probability that a miner with more than 25% of the hashrate power will attack the spv-client, creating fake block headers and spending half a million dollars on it, is almost 0. (Attacking the spv client with less hashrate power is pointless - too much time to create blocks). There is no guarantee that such an attack will be successful.

In general, it is time to stop using the expressions "the spv client requires trust", "the spv client is vulnerable", "an attacker can easily deceive the spv client" ,etc as untrue.

If someone wants to prove the opposite, then they must present a real attack scheme for the spv-client, which will be easier than attacking a full-node. Otherwise, it will be just words.