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

[jiamijiang]

Will there ever be any monetary incentives to run a full node? Why was this never implemented from the start?

[1714866087]

1714866087

[1714866087]

1714866087

[1714866087]

1714866087

[1714866087]

1714866087

[1714866087]

1714866087

[ranochigo]

No. Full nodes shouldn't be compensated. Unlike POW for the miners, there isn't any trustless way to validate if a full node is contributing (nor any suitable metric to gauge) to the network. Whilst it does help to decentralise the network more, it doesn't offer much more tangible benefits which warrants a compensation.

I don't foresee having a declining node count to be THAT big of a problem given that many volunteer's like me are running full nodes at home still with our old HDD and a Raspberry Pi. The overheads are a lot lower than what others perceive.

[Karartma1]

Will there ever be any monetary incentives to run a full node? Why was this never implemented from the start?

I agree with ranochigo.
The advantages of mining (given the right hardware setup) come in the form of coin rewards. While there are no monetary incentives, running a full node comes with its own benefits. First of all, it increases the security of transactions we perform(good for reliability, privacy and security). I believe this is of the highest importance if you plan to conduct multiple bitcoin txs per day. Secondly, running a node, you contribute to the overall security of bitcoin’s network. With a full node you will always be connected with the latest block chain history sharing that knowledge with your connected peers.
So, no monetary incentives but many benefits!

[BrewMaster]

whenever you think of a change or a new feature, etc. you should mainly think about the dishonest people not the honest ones. in this case rewarding full nodes means any dishonest person can start up hundreds of nodes with very little effort and cost to get all that reward for himself.
now you have to think of a way to prevent this type of fraud. it can only be prevented to some extent and only with a hard fork to change the mining algorithm.
now you are left with a new algorithm that has other flaws in it making it less safe ergo making bitcoin insecure.
and the issues keep on piling on, and for what? to pay people to run full nodes? there are already thousands of them doing it for free.

[bitmover]

The biggest problem is ;
Who would pay them?

Who would control abuses?

There is a delicate economic balance between miners, fees, transactions (which are already expensive), block rewards,  halving etc..

[gmaxwell]

Will there ever be any monetary incentives to run a full node? Why was this never implemented from the start?

Your incentive is that you are more secure and private if you do so.

If there were some other kind of incentive it would just by sybil attacked:  people would spin up thousands of "nodes", which would contribute nothing the network needs-- and would probably not actually be nodes in any case, just to collect the incentive.

[NotATether]

The biggest problem is ;
Who would pay them?

Who would control abuses?

There is a delicate economic balance between miners, fees, transactions (which are already expensive), block rewards,  halving etc..

There are 10987 full nodes according to bitnodes, so even if you pay a small potatoes amount of money like 0.00001BTC, after paying all those nodes you will be out by more than 0.1BTC every period. Nobody's willing to finance that.

Even if some entity which I will call a "creditor" could pay them all, you can't just take any receiving address of a full node for some hypothetical creditor to send rewards to. Full nodes are just private wallets that have the whole blockchain, and there are privacy concerns with sharing one of your addresses to some creditor because the rewards will be broadcasted on the blockchain and everyone will know the address is associated with your node.

Some nodes even have the wallet functionality disabled so there are no bitcoin addresses associated with them to pay to.

[pooya87]

There are 10987 full nodes according to bitnodes,

those are only reachable nodes, the majority of bitcoin nodes (90%) are not reachable or in other words don't accept incoming connections hence they are not listed on sites like bitnodes. take a look here: https://luke.dashjr.org/programs/bitcoin/files/charts/historical.html

[NotATether]

There are 10987 full nodes according to bitnodes,

those are only reachable nodes, the majority of bitcoin nodes (90%) are not reachable or in other words don't accept incoming connections hence they are not listed on sites like bitnodes. take a look here: https://luke.dashjr.org/programs/bitcoin/files/charts/historical.html

There's no point in rewarding a full node that isn't accepting inbound connections anyway. Such an incentive is supposed to be encouraging people to leave more full nodes running for serving connections. If a reward system were to give offline nodes rewards then it would be no different from giving everyone with a wallet free money.

[Carlton Banks]

There are 10987 full nodes according to bitnodes,

those are only reachable nodes, the majority of bitcoin nodes (90%) are not reachable or in other words don't accept incoming connections hence they are not listed on sites like bitnodes. take a look here: https://luke.dashjr.org/programs/bitcoin/files/charts/historical.html

ot: although the number of reachable nodes may increase radically (and rather suddenly) if the NAT-PMP port-forwarding pr is merged into Bitcoin 22.0, although this was also an the 21.0 milestone and got pushed out into 22.0, not sure why

[gmaxwell]

ot: although the number of reachable nodes may increase radically (and rather suddenly) if the NAT-PMP port-forwarding pr is merged into Bitcoin 22.0, although this was also an the 21.0 milestone and got pushed out into 22.0, not sure why

Because contributors are focused on debating which month to drop support for no longer supported mac os versions rather than sticking their neck out working on features which actually do something, and therefore might have bugs that get them blasted by internet assholes.

[odolvlobo]

Will there ever be any monetary incentives to run a full node? Why was this never implemented from the start?

There is nothing preventing a node from charging a fee to access it.

[zeuner]

[...] to pay people to run full nodes? there are already thousands of them doing it for free.

It's indeed practically meaningless for the original Bitcoin network as it kept a reasonable block size. But making a full node incentive part of the economic protocol might help to find proper responses to the block size controversy. It might make it more obvious that too high block sizes make it too expensive to have a healthy level of full node decentralization.

[ranochigo]

Even if you find way to pay full node which are very difficult to abuse and without locking big amount of Bitcoin, it won't solve block size controversy.
Without changing total bitcoin supply, each node only get very small amount of Bitcoin (which already mentioned above) and it won't cover cost of running full node.

Indeed. Bitnode used to implement a lottery system which rewards roughly $10 to a few selected winners once a week/month. There were hundreds of nodes and it was still when the blockchain was still fairly small.

Did it really incentivise that many people to create a Bitcoin Node? Not really, the result was fairly consistent and it didn't really increase the nodes substantially. It was paid for fully by them and it was barely enough to cover a month of fees. If it was any more attractive, I bet someone would've found a way to spoof their nodes and trick their crawler. Don't think anyone really cares about incentivising them/wants to fund it after that.

[pawanjain]

There are 10987 full nodes according to bitnodes, so even if you pay a small potatoes amount of money like 0.00001BTC, after paying all those nodes you will be out by more than 0.1BTC every period. Nobody's willing to finance that.

10987 should be the current number of active full nodes accepting incoming connections. Just imagine how large this number will be when people get to know there are incentives for running a full node. I am quite sure this number would grow 10x times or more if incentivizing full nodes become true. So that would become around 1 BTC or more and obviously nobody would contribute that amount repeatedly.

[aliashraf]

OP has crafted the question thoughtfully:

S/he is not asking whether THERE IS any incentive but if THERE WILL BE  such incentive ever. Obviously other than what @gmaxwell has mentioned almost correctly, securing one's own assets there IS no direct financial incentive for running a bitcoin full-node in the current state of the technology either for bitcoin or for any other POW coin. But this fact doesn't prove anything about the potentials of POW cryptocurrencies in general.

That said, one needs to remain focused on the main agenda of bitcoin and its clone: building/developing a decentralized p2p electronic cash, recognizing how critical it is to have the number of active full-nodes as high as possible to serve this sacred cause: decentralization.

So, I formulate the op's question as follows:
Is there any technical solution for a POW based coin to incentivize installing and maintaining active full-nodes preferably without disrupting the whole bitcoin technology?

As a matter of fact, investigating pooling pressure and mining centralization threats in bitcoin I've become convinced that an affirmative approach to the above question is inevitable in the framework of any solid solution to the core problem of mining centralization.

[pooya87]

As a matter of fact, investigating pooling pressure and mining centralization threats in bitcoin I've become convinced that an affirmative approach to the above question is inevitable in the framework of any solid solution to the core problem of mining centralization.

I don't see how paying full nodes some sort of reward for running could have any effects on mining and mining pools. That just adds an additional reason to centralized another aspect of bitcoin (running a full node) and if we assume there were any centralization in mining the same entities would also run full nodes and take the control in that area also.

[aliashraf]

As a matter of fact, investigating pooling pressure and mining centralization threats in bitcoin I've become convinced that an affirmative approach to the above question is inevitable in the framework of any solid solution to the core problem of mining centralization.

I don't see how paying full nodes some sort of reward for running could have any effects on mining and mining pools. That just adds an additional reason to centralized another aspect of bitcoin (running a full node) and if we assume there were any centralization in mining the same entities would also run full nodes and take the control in that area also.

I didn't suggest that, paying rewards to full-nodes. I'm just reminding the fact that the main incentive behind running a full node was designed to be a strict requirement for participating in mining which is absolutely omitted with the current situation in the scene. If instead of tens of pools we had thousands of miners actively generating their own blocks, i.e. in a truly decentralized mining scene the actual value of running a full node would have been discovered already. Decentralization of mining is the key to this problem.

[zeuner]

[...] to pay people to run full nodes? there are already thousands of them doing it for free.

It's indeed practically meaningless for the original Bitcoin network as it kept a reasonable block size. But making a full node incentive part of the economic protocol might help to find proper responses to the block size controversy. It might make it more obvious that too high block sizes make it too expensive to have a healthy level of full node decentralization.

Even if you find way to pay full node which are very difficult to abuse and without locking big amount of Bitcoin, it won't solve block size controversy.
Without changing total bitcoin supply, each node only get very small amount of Bitcoin (which already mentioned above) and it won't cover cost of running full node.

Yes, the fixed mining reward distorts the incentivization too much to properly investigate appropriate rewards for running a full node. But the same problem applies to transaction fees. It is crucial to solve both issues before the mining reward approaches zero.

[TofuDefi]

As a matter of fact, investigating pooling pressure and mining centralization threats in bitcoin I've become convinced that an affirmative approach to the above question is inevitable in the framework of any solid solution to the core problem of mining centralization.

I don't see how paying full nodes some sort of reward for running could have any effects on mining and mining pools. That just adds an additional reason to centralized another aspect of bitcoin (running a full node) and if we assume there were any centralization in mining the same entities would also run full nodes and take the control in that area also.

I didn't suggest that, paying rewards to full-nodes. I'm just reminding the fact that the main incentive behind running a full node was designed to be a strict requirement for participating in mining which is absolutely omitted with the current situation in the scene. If instead of tens of pools we had thousands of miners actively generating their own blocks, i.e. in a truly decentralized mining scene the actual value of running a full node would have been discovered already. Decentralization of mining is the key to this problem.

Many businesses need full node, not only miners. Payment providers, exchanges, etc. And it's not so expensive to have one.

[ranochigo]

As a matter of fact, investigating pooling pressure and mining centralization threats in bitcoin I've become convinced that an affirmative approach to the above question is inevitable in the framework of any solid solution to the core problem of mining centralization.

I don't see how paying full nodes some sort of reward for running could have any effects on mining and mining pools. That just adds an additional reason to centralized another aspect of bitcoin (running a full node) and if we assume there were any centralization in mining the same entities would also run full nodes and take the control in that area also.

I didn't suggest that, paying rewards to full-nodes. I'm just reminding the fact that the main incentive behind running a full node was designed to be a strict requirement for participating in mining which is absolutely omitted with the current situation in the scene. If instead of tens of pools we had thousands of miners actively generating their own blocks, i.e. in a truly decentralized mining scene the actual value of running a full node would have been discovered already. Decentralization of mining is the key to this problem.

Many businesses need full node, not only miners. Payment providers, exchanges, etc. And it's not so expensive to have one.

How many businesses uses their own full node and not a third party payment processor? How many exchanges are there? I don't think the count would be anywhere near the thousands.

If you're talking about the cost of having a full node, you can't simply estimate it based on the cost of the computer alone. You need to be able to have a interface that can be used to connect to your full node.

SPV clients and pooled mining has diminished the need for a full node.

[TofuDefi]

As a matter of fact, investigating pooling pressure and mining centralization threats in bitcoin I've become convinced that an affirmative approach to the above question is inevitable in the framework of any solid solution to the core problem of mining centralization.

I don't see how paying full nodes some sort of reward for running could have any effects on mining and mining pools. That just adds an additional reason to centralized another aspect of bitcoin (running a full node) and if we assume there were any centralization in mining the same entities would also run full nodes and take the control in that area also.

I didn't suggest that, paying rewards to full-nodes. I'm just reminding the fact that the main incentive behind running a full node was designed to be a strict requirement for participating in mining which is absolutely omitted with the current situation in the scene. If instead of tens of pools we had thousands of miners actively generating their own blocks, i.e. in a truly decentralized mining scene the actual value of running a full node would have been discovered already. Decentralization of mining is the key to this problem.

Many businesses need full node, not only miners. Payment providers, exchanges, etc. And it's not so expensive to have one.

How many businesses uses their own full node and not a third party payment processor? How many exchanges are there? I don't think the count would be anywhere near the thousands.

I think we talk about hundreds and maybe even thousands. There are 372 exchanges listed on coinmarketcap right now and I believe most of them running their own node.

If you're talking about the cost of having a full node, you can't simply estimate it based on the cost of the computer alone. You need to be able to have a interface that can be used to connect to your full node.

SPV clients and pooled mining has diminished the need for a full node.

Any Bitcoin Core wallet is a full node actually. I have one. And also run bitcoind on one of my servers. It uses about 300Gb of disk space, but I'm ok with that. It's affordable. TRON full node consumes much more resources for example.

[ranochigo]

I think we talk about hundreds and maybe even thousands. There are 372 exchanges listed on coinmarketcap right now and I believe most of them running their own node.

I definitely hope they are. Is 372 nodes enough? In the theoretical scenario of 1 CPU 1 Vote, the number of nodes would've be in the tens of thousands. Businesses don't usually run their own node, at least from what I've observed, most are using either coinpayments.net and bitpay. It's way easier to have a service do the payment for you.
 

Any Bitcoin Core wallet is a full node actually. I have one. And also run bitcoind on one of my servers. It uses about 300Gb of disk space, but I'm ok with that. It's affordable. TRON full node consumes much more resources for example.

IMO, disk space and internet bandwidth is scarce for the average joe. When alternatives like Electrum and other SPV wallets exists with little to no synchronization needed, most would choose them over a full node.

When alternatives that are better than running a full node exists, the average user won't run a full node. The tangible benefits is just too little.

[TofuDefi]

I think we talk about hundreds and maybe even thousands. There are 372 exchanges listed on coinmarketcap right now and I believe most of them running their own node.

I definitely hope they are. Is 372 nodes enough? In the theoretical scenario of 1 CPU 1 Vote, the number of nodes would've be in the tens of thousands. Businesses don't usually run their own node, at least from what I've observed, most are using either coinpayments.net and bitpay. It's way easier to have a service do the payment for you.

There are about 10000 nodes, I think it's enough. 1 CPU 1 Vote is about mining, not about full nodes.

If you accept small payments regularly and don't operate with significant amount of BTC then bitpay or coinpayments is ok for you, but if you need to keep a lot of btc and be sure that transactions you observe are real you need a full node, maybe even several of them.

Any Bitcoin Core wallet is a full node actually. I have one. And also run bitcoind on one of my servers. It uses about 300Gb of disk space, but I'm ok with that. It's affordable. TRON full node consumes much more resources for example.

IMO, disk space and internet bandwidth is scarce for the average joe. When alternatives like Electrum and other SPV wallets exists with little to no synchronization needed, most would choose them over a full node.

When alternatives that are better than running a full node exists, the average user won't run a full node. The tangible benefits is just too little.

I agree that for average Joe Electrum can be good enough, but there are still a lot of cases when full node is needed for businesses and even for regular users.

[pooya87]

If you accept small payments regularly and don't operate with significant amount of BTC then bitpay or coinpayments is ok for you, but if you need to keep a lot of btc and be sure that transactions you observe are real you need a full node, maybe even several of them.

I don't think using and preferring payment processors has anything to do with the amount, or at least it is not the biggest reason. It is all about whether the merchant wants to receive bitcoin or fiat while the user still pays in bitcoin. Due to volatility of bitcoin price those who start accepting bitcoin prefer receiving the payment in fiat.

[TofuDefi]

Regular user? If you mean privacy benefit, BIP 157 & 158 are enough for most users. Example wallet which uses it is Wasabi Wallet.

These BIPs are definitely improves privacy for light nodes, but if user's unencrypted transaction goes through third party full node then I think there is still an issue with privacy.

[ranochigo]

These BIPs are definitely improves privacy for light nodes, but if user's unencrypted transaction goes through third party full node then I think there is still an issue with privacy.

Transactions are never encrypted but yes, Electrum does have some privacy concerns. If you do want to protect your privacy, you'll probably be looking at Wasabi Wallet, Samourai Wallet etc. Their built in privacy functions is probably more useful for a user who wants impenetrable privacy.

I think you missed my 1 CPU 1 Vote argument. In the older days, mining requires a full node due to the pools being practically non-existent then and the profitability of a CPU was fairly decent. People are compelled to run a full node to mine because SPV wallets aren't really suitable for mining. Proliferation of ASICs and pools has also resulted in miners joining pools to have less earning varience as well as a higher reliability; they don't have to run full nodes to mine anymore. (Joining a pool would probably distort the 1 CPU 1 Vote ideology anyways, probably would have to run their own nodes)

Ideally, as many nodes as possible is the main goal. I haven't really found many businesses actually running their own full node. It's way easier to have a ready-made integration than to have to build the backend to handle transactions yourself. I'm not talking about those who are primarily dealing with Bitcoin transactions, but those merchants who see Bitcoin as an alternative form of payment and are likely not concerned about the disproportionate cost-benefit that having a full node would bring.

I understand that running a full node isn't all that bad but for a newbie who wants to use Bitcoin immediately and businesses who just wants to accept Bitcoin, is a getting a full node really their first choice?

[ABCbits]

Regular user? If you mean privacy benefit, BIP 157 & 158 are enough for most users. Example wallet which uses it is Wasabi Wallet.

These BIPs are definitely improves privacy for light nodes, but if user's unencrypted transaction goes through third party full node then I think there is still an issue with privacy.

How else would the full node broadcast user's (who use SPV wallet) transaction? If your concern is user's IP, Tor can solve the problem.
I know not everyone understand or use Tor (if it's not integrated and enabled by wallet), but it's more viable option than running full node.

[TofuDefi]

Regular user? If you mean privacy benefit, BIP 157 & 158 are enough for most users. Example wallet which uses it is Wasabi Wallet.

These BIPs are definitely improves privacy for light nodes, but if user's unencrypted transaction goes through third party full node then I think there is still an issue with privacy.

How else would the full node broadcast user's (who use SPV wallet) transaction? If your concern is user's IP, Tor can solve the problem.
I know not everyone understand or use Tor (if it's not integrated and enabled by wallet), but it's more viable option than running full node.

Ok, you're right, BIP 157 & 158  + Tor can solve the issue.

[GGUL]

Ideally, as many nodes as possible is the main goal.

  This is not a constructive or engineering approach. Any system has optimal parameter values, or an optimal range. An unlimited increase in a parameter is usually never required, and often leads to unnecessary costs, and the effect of the increase is close to zero.
 
  Therefore, it is more correct to set the goal in a different way: for Bitcoin to work reliably, the number of full nodes should not be less than a minimum level of N. Next, we need to find out the value of N, and ensure that the number of full nodes does not decrease below this level.

  Now we have ~10 thousand full nodes. It may well turn out that this is already above the minimum level and further increase does not give any profit for the entire system.

  You think that the number of full nodes should be increased. You could use the numbers to show what will improve in the system, and how much.

[ranochigo]

This is not a constructive or engineering approach. Any system has optimal parameter values, or an optimal range. An unlimited increase in a parameter is usually never required, and often leads to unnecessary costs, and the effect of the increase is close to zero.
 
Therefore, it is more correct to set the goal in a different way: for Bitcoin to work reliably, the number of full nodes should not be less than a minimum level of N. Next, we need to find out the value of N, and ensure that the number of full nodes does not decrease below this level.

Now we have ~10 thousand full nodes. It may well turn out that this is already above the minimum level and further increase does not give any profit for the entire system.

You think that the number of full nodes should be increased. You could use the numbers to show what will improve in the system, and how much.

Hmm good point, marginal utility usually decreases. Unfortunately I don't have a computer science degree so I won't be an expert in that area. I would love to see what's the optimum amount.

But the crux is that if you're not running a full node, you can't validate the info that you received and that is thus not ideal. I don't think that there would be an optimum number of nodes to have, having more nodes on the network doesn't decrease the experience for everyone else but it'll improve redundancy. You can have 100 nodes for the network to work but the degree of redundancy would be low. Since they aren't compensated, there shouldn't be any cost borne by anyone else?

[GGUL]

But the crux is that if you're not running a full node, you can't validate the info that you received and that is thus not ideal.

A properly implemented SPV client is as reliable as a full node. I don't know why, but this myth about the unreliability of SPV clients is very common in the Bitcoin community. Even more surprisingly, this myth is spread by Bitcoin developers.

I don't think that there would be an optimum number of nodes to have, having more nodes on the network doesn't decrease the experience for everyone else but it'll improve redundancy. You can have 100 nodes for the network to work but the degree of redundancy would be low. Since they aren't compensated, there shouldn't be any cost borne by anyone else?

The question of whether to use a full node or not is primarily a question of convenience (not even reliability). Each user decides for themselves. How many users decide to launch a full node, so many of them will be.

You decided that there should be as many full nodes as possible, and you should make an effort to increase their number. However, you do not provide any figures confirming this.

If, for example, you decide to compensate the owners of full nodes at the expense of miners, this directly reduces the security of Bitcoin. This raises the question of how optimal a solution would be to increase the number of full nodes by reducing security.

[aliashraf]

A properly implemented SPV client is as reliable as a full node. I don't know why, but this myth about the unreliability of SPV clients is very common in the Bitcoin community. Even more surprisingly, this myth is spread by Bitcoin developers.

This debate is not about reliability. SPVs are simply pure consumers in a network that have no role in consolidating it while this network happens to be in the verge of an alarming centralization situation.
A properly implemented SPV wallet as you've already put it, is reliable enough for the average user of bitcoin as much as bitcoin network is but the million dollar question would be how much is that?

To have a deeper understanding of the importance of full-nodes you need to take another look at User Activated Soft Forks, UASFs, and the role they play in balancing the power relations in bitcoin ecosystem. Without a strong base of full-nodes bitcoin will be left in hands of a dozen of Chinese pools and ASIC manufacturers who are established entities under the ruling of Xi and his party.

Ethereum community doesn't worry about pools they have Buterin and Ethereum Foundation and their weird understanding of governance in cryptocurrency universe, bitcoin is not Ethereum though, Core Devs have no say on the fate of the network, they are not co-ordinated/hired by a central entity, none of them is worshiped as an idol or a rock star, bitcoin is not a project and doesn't have a so-called "road map". In bitcoin, we need full nodes to keep the network safe and secure, in Ethereum all they need and all they got is Buterin and his Foundation, period.

If, for example, you decide to compensate the owners of full nodes at the expense of miners, this directly reduces the security of Bitcoin. This raises the question of how optimal a solution would be to increase the number of full nodes by reducing security.

You've argued the same way above thread, questioning the engineering tabulations and analysis behind the concerns about the number of full nodes.

To be more specific, engineers are not inventors or innovators of mathematical models, they simply use established models. Cryptocurrency is a young field of study and I'm not aware of any textbook touting a related mathematical model to this specific problem but community members have every right to be concerned about the number of full nodes in the network and discuss options to boost this number because as @ranochigo has argued correctly (and you have debunked using a straw-man fallacy) there is no penalty paid for such an increase, forget about rewarding full nodes.

[GGUL]

A properly implemented SPV client is as reliable as a full node. I don't know why, but this myth about the unreliability of SPV clients is very common in the Bitcoin community. Even more surprisingly, this myth is spread by Bitcoin developers.

To have a deeper understanding of the importance of full-nodes you need to take another look at User Activated Soft Forks, UASFs, and the role they play in balancing the power relations in bitcoin ecosystem. Without a strong base of full-nodes bitcoin will be left in hands of a dozen of Chinese pools and ASIC manufacturers who are established entities under the ruling of Xi and his party.

I really want to understand the "importance of full nodes". The problem is that apart from the words about importance, you have nothing else.

Let's assume that we have full nodes in the amount that is sufficient for the full operation of all users and the system. Let it be 5 thousand.
 After that, we will increase the number to 10 thousand. What will we get? The answer I came up with after much thought: NOTHING.

If you want to convince me otherwise, you'd better provide something real, preferably with numbers. Your arguments about UASF and the Chinese pools look ridiculous and unconvincing, and very similar to FUD  .

Ethereum community doesn't worry about pools ...

Surprisingly, as far as I know, no cryptocurrency is worried about the number of full nodes. Only Bitcoin. Maybe it's because all the excitement about it is pointless, and does not bring any benefit.

You've argued the same way above thread, questioning the engineering tabulations and analysis behind the concerns about the number of full nodes.

Where are these ''engineering tabulations and analysis"?  I'd like to see them.

[aliashraf]

A properly implemented SPV client is as reliable as a full node. I don't know why, but this myth about the unreliability of SPV clients is very common in the Bitcoin community. Even more surprisingly, this myth is spread by Bitcoin developers.

To have a deeper understanding of the importance of full-nodes you need to take another look at User Activated Soft Forks, UASFs, and the role they play in balancing the power relations in bitcoin ecosystem. Without a strong base of full-nodes bitcoin will be left in hands of a dozen of Chinese pools and ASIC manufacturers who are established entities under the ruling of Xi and his party.

I really want to understand the "importance of full nodes".

I challenge that claim. You don't try enough I suppose.
Look at the time stamps of my comments and yours, apparently you haven't "wasted" your valuable time reading my post, let alone chewing it, instead you prefer rushing to the KB and rehashing your nonsense argument about the need for numbers. Why don't you give us some magical numbers you got?  

Surprisingly, as far as I know, no cryptocurrency is worried about the number of full nodes. Only Bitcoin. Maybe it's because all the excitement about it is pointless, and does not bring any benefit.

Not surprisingly, the shit coins you are bragging with them, are orders of magnitude behind bitcoin.

[GGUL]

I really want to understand the "importance of full nodes".

I challenge that claim. You don't try enough I suppose.
Look at the time stamps of my comments and yours, apparently you haven't "wasted" your valuable time reading my post, let alone chewing it, instead you prefer rushing to the KB and rehashing your nonsense argument about the need for numbers. Why don't you give us some magical numbers you got?  

I already gave above. NOTHING. Or 0 if translated to numbers. This is how much users will get if they increase the number of full nodes beyond the number that is necessary for the system to function.
I am waiting for a rebuttal, waiting for your numbers, which show how much we will get.

[odolvlobo]

Let's assume that we have full nodes in the amount that is sufficient for the full operation of all users and the system. Let it be 5 thousand.
 After that, we will increase the number to 10 thousand. What will we get? The answer I came up with after much thought: NOTHING.

Without a concrete measure of the value of a node and a way to determine how many are sufficient or if any number is sufficient, it is impossible to say with any certainty that any particular number is sufficient or that any additional nodes provide no value.

It is reasonable to assume that an additional node provides additional benefit simply because it increases the connectivity of the network. It is not reasonable for you to make your claim (that at some point additional nodes provide no benefit) without supporting it.

Here, I'll help you. It could be argued that an additional node provides benefit at a cost, and the point at which the cost exceeds the benefit is where additional nodes no longer provide a benefit. Now, if you wanted to support your claim, you would need to identify the cost and show how it can outweigh the benefit after some number of nodes.

[GGUL]

Let's assume that we have full nodes in the amount that is sufficient for the full operation of all users and the system. Let it be 5 thousand.
 After that, we will increase the number to 10 thousand. What will we get? The answer I came up with after much thought: NOTHING.

Without a concrete measure of the value of a node and a way to determine how many are sufficient or if any number is sufficient, it is impossible to say with any certainty that any particular number is sufficient or that any additional nodes provide no value.

It is reasonable to assume that an additional node provides additional benefit simply because it increases the connectivity of the network. It is not reasonable for you to make your claim (that at some point additional nodes provide no benefit) without supporting it.

Here, I'll help you. It could be argued that an additional node provides benefit at a cost, and the point at which the cost exceeds the benefit is where additional nodes no longer provide a benefit. Now, if you wanted to support your claim, you would need to identify the cost and show how it can outweigh the benefit after some number of nodes.

You didn't read the terms very carefully. I'll help you.
"full nodes in the amount that is sufficient for the full operation of all users and the system"-means that there are no problems connecting to network.  And if there are no problems, adding additional nodes does not increase the ability to connect to the network.

Are you suggesting that it is impossible to estimate the number of full nodes that is sufficient for the network to function?
Now we have ~10 thousand full nodes. ~350 thousand transactions are added to the system every day. That is, on average, through each full node the system receives 35 transactions per day, or 1 transaction per 40 minutes.
And you think that 10 thousand full nodes can't handle it, that there may be problems connecting to the network. So, should we still increase the number of full nodes? Seriously?

[aliashraf]

Let's assume that we have full nodes in the amount that is sufficient for the full operation of all users and the system. Let it be 5 thousand.
 After that, we will increase the number to 10 thousand. What will we get? The answer I came up with after much thought: NOTHING.

Without a concrete measure of the value of a node and a way to determine how many are sufficient or if any number is sufficient, it is impossible to say with any certainty that any particular number is sufficient or that any additional nodes provide no value.

It is reasonable to assume that an additional node provides additional benefit simply because it increases the connectivity of the network. It is not reasonable for you to make your claim (that at some point additional nodes provide no benefit) without supporting it.

Here, I'll help you. It could be argued that an additional node provides benefit at a cost, and the point at which the cost exceeds the benefit is where additional nodes no longer provide a benefit. Now, if you wanted to support your claim, you would need to identify the cost and show how it can outweigh the benefit after some number of nodes.

You didn't read the terms very carefully. I'll help you.
"full nodes in the amount that is sufficient for the full operation of all users and the system"-means that there are no problems connecting to network.  And if there are no problems, adding additional nodes does not increase the ability to connect to the network.

Are you suggesting that it is impossible to estimate the number of full nodes that is sufficient for the network to function?
Now we have ~10 thousand full nodes. ~350 thousand transactions are added to the system every day. That is, on average, through each full node the system receives 35 transactions per day, or 1 transaction per 40 minutes.
And you think that 10 thousand full nodes can't handle it, that there may be problems connecting to the network. So, should we still increase the number of full nodes? Seriously?

It is both void and vague: full operation of all users and the system
There is no such thing in a decentralized p2p system as "full operation" you are an old hand in cryptocurrency, registered here in 2013 according to your profile, and yet you use  such a loose terminology, why?

Network could "function" (your term again) using just ONE full-node, but functioning is not the concern as you already know, being secure and safe is. Security is a not ever ending demand in all monetary systems and a decentralized system bases its security on proper distribution of power. It is what makes bitcoin the most secure in its clone is its checks and balances system that maintains a steady state of equilibrium between three important branches: miners, developers and users where the later group are presented solely by full-nodes (and not spv wallets) the concern discussed in this topic, which you are trying to derail, is the incentive mechanism behind running full-nodes and potentials to improve it.

If you are seriously questioning the philosophy behind the common rhetoric in bitcoin community that assumes an increase in the number of full-nodes is a good index and vice versa, you can start a topic and make your case. I suppose it is pretty off-topic to make this case here.

[The Sceptical Chymist]

There are 10987 full nodes according to bitnodes, so even if you pay a small potatoes amount of money like 0.00001BTC, after paying all those nodes you will be out by more than 0.1BTC every period. Nobody's willing to finance that.

10987 should be the current number of active full nodes accepting incoming connections. Just imagine how large this number will be when people get to know there are incentives for running a full node. I am quite sure this number would grow 10x times or more if incentivizing full nodes become true. So that would become around 1 BTC or more and obviously nobody would contribute that amount repeatedly.

Yeah, and none of that was Satoshi's intention when he created bitcoin anyway.

If you want to be compensated for maintaining a blockchain, proof-of-stake coins are your best option--or by running a masternode for coins like Dash, PIVX, etc.  Bitcoin isn't for that.

My technical knowledge of bitcoin has many gaps, and I appreciate everyone's responses here.  I learn good things in threads like this, even if I can contribute very little.

[Kakmakr]

To be brutally honest... I would rather have a few "pure" volunteers hosting a fully functioning full node, than having 1000s of money farmers running non-productive nodes to reap some kind of monetization. 

We saw what happened during the Bitcoin (BTC) vs Bitcoin Cash fork wars, when people fired up lots of nodes on virtual hosting services (Cloud services) to try and fool the outcome of the fork.

Do we now want people to fire up more of these "fake" nodes ....to just disappear after they received their reward?  Nah, let's stick to what is working for now. 

[zeuner]

Ideally, as many nodes as possible is the main goal.

  This is not a constructive or engineering approach. Any system has optimal parameter values, or an optimal range. An unlimited increase in a parameter is usually never required, and often leads to unnecessary costs, and the effect of the increase is close to zero.
 
  Therefore, it is more correct to set the goal in a different way: for Bitcoin to work reliably, the number of full nodes should not be less than a minimum level of N. Next, we need to find out the value of N, and ensure that the number of full nodes does not decrease below this level.

  Now we have ~10 thousand full nodes. It may well turn out that this is already above the minimum level and further increase does not give any profit for the entire system.

  You think that the number of full nodes should be increased. You could use the numbers to show what will improve in the system, and how much.

Once we are able to define reasonable metrics for the merit of full nodes, they can serve as a basis not only for a more rational discussion about amounts of full nodes, but also for an incentivizaton scheme.

[aliashraf]

To be brutally honest... I would rather have a few "pure" volunteers hosting a fully functioning full node, than having 1000s of money farmers running non-productive nodes to reap some kind of monetization. 

We saw what happened during the Bitcoin (BTC) vs Bitcoin Cash fork wars, when people fired up lots of nodes on virtual hosting services (Cloud services) to try and fool the outcome of the fork.

Do we now want people to fire up more of these "fake" nodes ....to just disappear after they received their reward?  Nah, let's stick to what is working for now. 

Here comes the problem: volunteers, being pure or whatever, don't have a say in the ecosystem, who cares about volunteers being committed to which fork? It is not how bitcoin works.

With most of the full nodes being pushed out of the mining, we are left with an alarming number of full nodes employed in actual use-cases. Above-thread, I've mentioned how important it is to bring back full nodes to mining by decentralizing pools and making it more profitable for miners to build their own blocks from scratch using their own full nodes. Without such an improvement, the problem remains essentially unsolved.

[Wind_FURY]

There are 10987 full nodes according to bitnodes, so even if you pay a small potatoes amount of money like 0.00001BTC, after paying all those nodes you will be out by more than 0.1BTC every period. Nobody's willing to finance that.

10987 should be the current number of active full nodes accepting incoming connections. Just imagine how large this number will be when people get to know there are incentives for running a full node. I am quite sure this number would grow 10x times or more if incentivizing full nodes become true. So that would become around 1 BTC or more and obviously nobody would contribute that amount repeatedly.

Yeah, and none of that was Satoshi's intention when he created bitcoin anyway.

If you want to be compensated for maintaining a blockchain, proof-of-stake coins are your best option--or by running a masternode for coins like Dash, PIVX, etc.  Bitcoin isn't for that.

My technical knowledge of bitcoin has many gaps, and I appreciate everyone's responses here.  I learn good things in threads like this, even if I can contribute very little.

And that is the answer to Will there ever be any monetary incentives to run a full node on bitcoin?

Bitcoin Devs have decided against it, so an altcoin is your only option.

Only corporations will bother running a node as time passes, which is by design once the asics killed the reason for the little guy to run a node.  

You know Kohas797, the choice is for the user. If he/she believes that he/she is incentivized to run a shitcoin's node to receive shitcoin, then OK, run that node. Because you will NEVER get an incentive to run a Bitcoin node. BUT statistics shows there are more actual FULL nodes running in the Bitcoin network than any shitcoin. PLUS, many of those incentivized to run a shitcoin node SELL the shitcoin to BUY Bitcoin.

[zeuner]

There are 10987 full nodes according to bitnodes, so even if you pay a small potatoes amount of money like 0.00001BTC, after paying all those nodes you will be out by more than 0.1BTC every period. Nobody's willing to finance that.

10987 should be the current number of active full nodes accepting incoming connections. Just imagine how large this number will be when people get to know there are incentives for running a full node. I am quite sure this number would grow 10x times or more if incentivizing full nodes become true. So that would become around 1 BTC or more and obviously nobody would contribute that amount repeatedly.

Yeah, and none of that was Satoshi's intention when he created bitcoin anyway.

If you want to be compensated for maintaining a blockchain, proof-of-stake coins are your best option--or by running a masternode for coins like Dash, PIVX, etc.  Bitcoin isn't for that.

My technical knowledge of bitcoin has many gaps, and I appreciate everyone's responses here.  I learn good things in threads like this, even if I can contribute very little.

And that is the answer to Will there ever be any monetary incentives to run a full node on bitcoin?

Bitcoin Devs have decided against it, so an altcoin is your only option.
[...]

No one knows how future protocol change proposals will look like.

The SegWit2x proposal was decided on in favour of full node operators, and against a hard fork. But if a future hard fork proposal will have an effect in favour of full node operators, who knows whether it will receive some traction...

[gmaxwell]

That page is a lie.  It compares inbound reachable Bitcoin nodes to all ethereum nodes.  The vast majority of Bitcoin nodes are not inbound reachable, as there are plenty of inbound reachable ones and being reachable exposes them to some attacks. Total Bitcoin nodes are much larger and ironically 30% of those ethereum "nodes" have fallen out of sync.  So there are 5.6x the number of Bitcoin full nodes as there are in-sync ethereum nodes.

There is also no real capability comparison. Ethereum nodes normally only have SPV-like security-- they blindly trust miners and don't validate the history. There is no exact analogue in Bitcoin.  Their 'archive' nodes do more but also carry a huge amount of cruft too and it's so difficult to run one that even blockchain infrastructure companies have problems doing it.

[gmaxwell]

And what good is a node to the external network , if not inbound reachable.
It might as well not exist, so it does not count in any real sense.  

Pretty much exactly as good as any other node.  Connections can't be initiated in from the internet to them but they connect out and the protocol is symmetric-- it doesn't really matter who called who, it works just the same either way.  (Also some of those that don't accept connections publicly still accept connections privately, e.g. from friends or over tor)

[Wind_FURY]

That page is a lie.  It compares inbound reachable Bitcoin nodes to all ethereum nodes.  The vast majority of Bitcoin nodes are not inbound reachable, as there are plenty of inbound reachable ones and being reachable exposes them to some attacks. Total Bitcoin nodes are much larger and ironically 30% of those ethereum "nodes" have fallen out of sync.  So there are 5.6x the number of Bitcoin full nodes as there are in-sync ethereum nodes.

There is also no real capability comparison. Ethereum nodes normally only have SPV-like security-- they blindly trust miners and don't validate the history. There is no exact analogue in Bitcoin.  Their 'archive' nodes do more but also carry a huge amount of cruft too and it's so difficult to run one that even blockchain infrastructure companies have problems doing it.

Plus they call them "light nodes", which they consider as actual "nodes" in the Ethereum network, but they really don't do anything for the network. Haha. They don't validate and relay transactions/blocks, making sure everything is following consensus rules.

[GGUL]

Are there any studies that show what we get from increasing the number of full nodes?

The functionality seems to be clear. Since the system works smoothly with the current number of full nodes, increasing it will not do anything.

There were complaints about the security of the system. Where we can see what security level is in the current state with the number of ~10 thousand full nodes. What level of security will be at 5 thousand, and what at 20 thousand?

[20kevin20]

There were complaints about the security of the system. Where we can see what security level is in the current state with the number of ~10 thousand full nodes. What level of security will be at 5 thousand, and what at 20 thousand?

Most of the security comes AFAIK when you become a full node yourself. Full nodes cannot be fooled into accepting txs that are not alright, unlike light (SPV) wallets through which you have to blindly trust the information they're giving you..

It's not that we need more full nodes to make Bitcoin more secure, it's just that the more people we have running their own full nodes rather than blindly trusting servers, so the less we have to use trust, the better.

[Filicius]

At this rate, more than incentives there will be disincentives. I have read some news a few days ago, but I think it is old news, about some legislation that could make anyone who runs a node responsible for illegal transactions made via blockchain.

Back to the topic properly said, the incentive of running a node is more about personal satisfaction rather than anything else, it has always been and I suppose that it will always be, unless somebody makes up a way to register and fund it.

[aliashraf]

There were complaints about the security of the system. Where we can see what security level is in the current state with the number of ~10 thousand full nodes. What level of security will be at 5 thousand, and what at 20 thousand?

Most of the security comes AFAIK when you become a full node yourself. Full nodes cannot be fooled into accepting txs that are not alright, unlike light (SPV) wallets through which you have to blindly trust the information they're giving you..

Not a true assertion, as it has been discussed above thread, a properly implemented SPV wallet can protect its user from low-class attacks like what you suggest.

In a nutshell, SPV lets you validate your transactions without having to worry about anybody else’s transactions. It ensures your transactions are in a block, and it provides confirmations (proof of work) that additional blocks are being added to the chain.

If you need more to know how it is possible to do such a verification you should take a look at the concept of Merkle Tree finding out how one can prove that a hash belongs or does not belong to such a tree.
In the bitcoin community, official opposition to SPV wallets is what @gmaxwell mentioned earlier in this thread: SPVs "blindly" follow the chain that are presented to them as the longest/heaviest one, a weak argument, but I'm done arguing with Greg because he becomes mad at me very easily

My opposition to SPV wallets, if it could be called an opposition, is from a different standpoint: I think for some reason, SPV wallets are over-used and it is not good because they don't take part in securing the network while they are pretty much the main user of this security. It is an anomaly by definition.

[GGUL]

At this rate, more than incentives there will be disincentives. I have read some news a few days ago, but I think it is old news, about some legislation that could make anyone who runs a node responsible for illegal transactions made via blockchain.

Well-implemented spv wallet can only be deceived by an attacker-a miner with a 51% hashrate. As we know, such a miner can also deceive full nodes. In this regard, full nodes have no advantage.

Back to the topic properly said, the incentive of running a node is more about personal satisfaction rather than anything else, it has always been and I suppose that it will always be, unless somebody makes up a way to register and fund it.

If this is the case the current topic is meaningless. Why fight to increase the number of full nodes?

My opposition to SPV wallets, if it could be called an opposition, is from a different standpoint: I think for some reason, SPV wallets are over-used and it is not good because they don't take part in securing the network while they are pretty much the main user of this security. It is an anomaly by definition.

Unfortunately, you have not shown how the security of the network depends on the number of full nodes.

[20kevin20]

If you need more to know how it is possible to do such a verification you should take a look at the concept of Merkle Tree finding out how one can prove that a hash belongs or does not belong to such a tree.

I see; thanks for the information. Will look into the concept.

I've read all your posts here multiple times but I don't think I can get to understand something: 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?

[aliashraf]

If you need more to know how it is possible to do such a verification you should take a look at the concept of Merkle Tree finding out how one can prove that a hash belongs or does not belong to such a tree.

I see; thanks for the information. Will look into the concept.

I've read all your posts here multiple times but I don't think I can get to understand something: 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?

To be precisely clear, I don't think running a full node per se has anything to do with the network security e.g for altruistic purposes, etc. as I've already reminded above-thread, only mission critical nodes with a well-defined incentive mechanism, integrated to bitcoin network function that participate in bitcoin relay protocol worth being counted as a security enhancement element.

The fair question would be what kind of full nodes deserve such a credit? I would suggest two different categories as my immediate thoughts:
First and foremost are functions that won't be ever accomplished without a full node: solo mining supporting full-nodes obviously on top of the list but one could consider network analyzers, heavy-duty payment processors, exchanges, second layer protocols, ...

The second group are nodes run by users with special interests in bitcoin security: bitcoin whales, prominent bitcoin figures, researchers and advocates, ...

The mechanism by which the latter group help in "securing" bitcoin is not functional in terms of blockchain technology but is influential as a socioeconomic factor and it is very important to be treated cautiously and not to be exaggerated as an ultimate factor because essentially bitcoin is not a reputation based system.

I contributed to this thread to advocate in favor of decentralization of mining and promoting mining full nodes a topic that I'm working on for a while.

[zeuner]

My opposition to SPV wallets, if it could be called an opposition, is from a different standpoint: I think for some reason, SPV wallets are over-used and it is not good because they don't take part in securing the network while they are pretty much the main user of this security. It is an anomaly by definition.

The first step towards a rational continuation of this discussion would be to define a (maybe theoretical) attack that is made possible by a lack of full nodes. Then it could be assessed how the success chances for this attack are affected by the number of full nodes.

[pooya87]

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

[aliashraf]

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.

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.

[ranochigo]

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.

I think 100+ is an exaggeration, wasn't it close to 30 or so? Even so, the problem will persist for any client that doesn't know the new rules and will still blindly follow the other chain which still follows the older network rules. So the problem wasn't specific to full nodes.

However, my POV is that given that SPV only validates block headers, it still can't be as secure as fully validating nodes and operates under the presumption that the SPV client will not get sybil attacked and the longest difficulty-wise POW chain is valid. I'm not sure how that could be disputed.

But I would like to consider @aliashraf POV as well, have you had a discussion on this on the forum or could you point me to the relevant sources?

[pooya87]

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 100+ is an exaggeration, wasn't it close to 30 or so?

The number depends on the situation and the risk and the amount but you are correct, according to bitcoin.org the number during emergencies is 30.
My logic was this:
Imagine in 2017 if a small number of miners continued building on top of a chain that rejected the SegWit blocks. This invalid minority chain could grow for a day before they gave up on wasting their money. A day is ~144 blocks and small hashrate can not build 100 blocks that fast.

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

[zeuner]

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.

And how exactly would the block explorer work without a full node providing the data?

[Joe_Bauers]

OP has crafted the question thoughtfully:

S/he is not asking whether THERE IS any incentive but if THERE WILL BE  such incentive ever. Obviously other than what @gmaxwell has mentioned almost correctly, securing one's own assets there IS no direct financial incentive for running a bitcoin full-node in the current state of the technology either for bitcoin or for any other POW coin. But this fact doesn't prove anything about the potentials of POW cryptocurrencies in general.

That said, one needs to remain focused on the main agenda of bitcoin and its clone: building/developing a decentralized p2p electronic cash, recognizing how critical it is to have the number of active full-nodes as high as possible to serve this sacred cause: decentralization.

So, I formulate the op's question as follows:
Is there any technical solution for a POW based coin to incentivize installing and maintaining active full-nodes preferably without disrupting the whole bitcoin technology?

As a matter of fact, investigating pooling pressure and mining centralization threats in bitcoin I've become convinced that an affirmative approach to the above question is inevitable in the framework of any solid solution to the core problem of mining centralization.

I actually started working on this a few years ago for a new alt-coin (yes yes, I know) called Poncoin <- Proof of Node. Even came up with a mascot Ponnie the Pinecone lol. Essentially each wallet would have a static (or dynamic) "PON address" that would be hashed with the ip + block to provide key: (ip address + pon address + relayed block = key) That hash would then be added to each relayed block. A certain amount of blocks later, let's say 120, as long as full node was still active, they could redeem a set value. To somewhat alleviate the issue of bad-actors running multiple nodes, a lottery would also be implemented to distribute reward.

There is ABSOLUTELY no reason there shouldn't be a reward for running a full node to answer the initial question, (just ask your local ISP if they think their bandwidth should be free) but I am not as smart as a hair on gmaxwell 's head, so I'm sure there are lots of flaws in my idea. Which is one of the many reasons Poncoin was never done. 

[pooya87]

Essentially each wallet would have a static (or dynamic) "PON address" that would be hashed with the ip + block to provide key: (ip address + pon address + relayed block = key) That hash would then be added to each relayed block. A certain amount of blocks later, let's say 120, as long as full node was still active, they could redeem a set value.

It depends on what you mean by "check if still active", I can write less than 100 lines of code and using about 50 MB of memory and virtually no CPU usage and 0 storage, I can run a fake node that is capable of appearing "active" by accepting incoming connections, relaying the block(s) I want to receive the incentive for.
All it takes is an open socket, keeping a couple of hundreds of headers (<50 kB) and a handful of blocks (<40MB) in memory, not relaying transactions, not verifying anything, not storing anything on disk either.

[Wind_FURY]

If have one question. Who should pay for the monetary incentive for to make users run their own full nodes? The miners? Mining pools? Developers? Exchanges? I believe monetary incentives can be used for political agendas.