Bitcoin Forum

Hi Guys
Hoping some of the smarter people here can educate me. I see a lot of mentions of run your own node.  But what is the point of it? If my node never wins a block then what impact can it actually have on bitcoins security?

I see a reason for doing it if you are a merchant and want to see if transactions are sent to you immediately, or if you want to do it for LN. But why run one as a normal bitcoin dude?

if you don't run a node you are not using bitcoin.

A non-mining node allows you to see what consensus rules are in use. If every full node were owned by the miners, they could have changed the consensus rules (like printing more bitcoins, removing the supply cap, reversing transactions etc) without you knowing  it.

If they try to pull any crap like that now, non-mining nodes will reject their shit. Full non-mining nodes still need the hash power though, so blockchain can move forward.

Think it like this way:

Bitcoin = A massive full node network. If somebody tries to cheat this network, he will be ignored.

OP, aside from mindtrust and anullcoin's replies, if you hear or read a post of someone that says that a non-mining node is "not important", then it should be approached with a great amount of cynicism.

I have heard sound arguments from both sides, but my conclusion is that it is only positive and strengthens the network to have as many nodes as possible assuming said nodes are ran by independent parties, not ran in bulk by the same party, as this creates a single point of failure. The more individual parties owning copies of the blockchain and being able to audit it the better, you don't want only a couple of corporations owning the blockchain, what would be the point then?

We may see this in action in September, with the so called BCH Stress Test, so pay attention to that, and we may learn a lot of things. Im going to be following BitPico's effort to collapse BCH's network, let's see how they manage with very few nodes.

The number one reason to run a node is verifying the whole blockchain to make sure that no one is cheating. Lightweight wallets have to trust full nodes in many things and researchers often find attacks against them that are impossible to execute against full nodes. Here's a recent example of such vulnerability: https://bitcointechweekly.com/front/cve-2017-12842-leaf-node-weakness-trusted-merkle-tree-depth-for-safe-tx-inclusion-proofs-without-a-soft-fork/

Aside from strengthening the network which was covered by other posters here, running a full node has some other perks. If you have the full blockchain, you can fork Bitcoin or oppose other forks by staying on the original chain. If only a few big nodes store the blockchain, then the users can't make any decisions about the network rules. Even if miners and businesses would change the rules, the users would still to be able to stay on the old chain. So, even with centralized mining and companies Bitcoin is still decentralized thanks to full nodes.

All full nodes, including non-mining nodes are helpful because the more nodes there are, the easier it is for new users to sync-up to the network. The more nodes available to send transactions to syncing nodes, the faster sync times will be until they hit a bottleneck of CPU or disk writing speed.

Hey cellard. I saw that you were involved in the discussion with anunymint. I followed it too. He makes some strong points but it feels too much like his agenda. I am glad you lean towards the non-mining nodes being important conclusion. I do too. Tor me, bitcoin is supposed to be an open-source, community project. The work involved in running a full node will give you a much better understanding of the underlying hardware and software requirements.

When it scales, there will of course be people who will have no idea of the inner workings. From a user experience point of view too, it needs to be this way for quick on-boarding and adoption. Even then, the group of people that do understand, monitor it and work on it, has to be significant. It can't be a closed group of people who understand everything and decide for others.

A lot of decision making related to technology and economics happens in closed groups because, supposedly, so few understand it. To ensure that this does not happen to bitcoin, this group of people who are involved and care enough to run a non-mining full node, are of vital importance from the community-watchdog perspective.

What is "sound" about the argument from the "non-mining nodes do not matter" side? They always say that because of "Moore's Law", the hardware will keep up to the demands of the network. But what they do not tell everyone is bandwidth growth and latency are more important for data and block propagation.

Larger blocks will demand more latency and more bandwidth to counter node centralization. Both of which grow much slower than "Moore's Law".


BitPico might be another publicity run by the big blockers to deceive everyone that Bitcoin Cash Alibaba nodes are resilient to attacks. Hahaha.

What about TRB nodes? they are non-mining nodes right? so the fact that they are being ran right now does not matter?


This is possible. I actually don't trust BitPico at all, they were supporting SegWit2x hardfork back then, and I have not seen them giving an explanation why they did so. Then they disappeared, and suddenly they are back again. This must be a setup to fail on the stress test so BCashers can then use it as proof of how their network can sustain spam attacks without collapsing. I bet Roger Ver is once again involved.

I would reject this logic.

A full node does nothing to confirm what the consensus rules are (other than the default rules the node software is "shipped" with that is input by the core devs), in fact I am not aware of any Bitcoin implementation that will tell others what specific rules it is following. Most Bitcoin nodes will broadcast the name of the implementation they are running, however this is far from what consensus rules they are following, and can be trivially changed.

What running a full node does do, is ensure you only accept transaction and blocks that follow the rules you choose. However the caveat is that if you are not following the same rules as the economic majority, your node will either accept transactions/blocks that are economically worthless, or will not receive blocks at all. If the major economic players got together and decided to accept transactions/blocks that meet a certain criteria that your node disagrees with, then your node will be doing exactly nothing.

Although the cardinality of node owners i.e. the number of actual human beings who decided to run full nodes and specifically the software/protocol version they support is important, relevance of this issue to security measures is weak.

There is no reason for a person/organisation to run multiple instances of a full node other than availability/fault tolerance concerns which could be addressed by other means as well.

For mining nodes the cardinality of owners is important for security when it is compared to the hashpower that is attached to the nodes.

Really? I thought we cannot change the consensus rules even if we had a full node (as a miner). But, what the heck is a node actually? Is it a wallet with full blockchain history downloaded from the genesis block until now? and how did they could have changed the consensus rules if the full node were owned by the miners?

Why not to add a 'slow' CPU mining option to the full-node software?

It may not offer a practical mining revenue opportunity, however it may improve the overall network mining decentralisation.
Imagine 'CCP-like' hashrate attack:
Malicious ASIC miners prepare to shadowmine.
Honest ASIC miners go offline because of the temporary profitability reasons.
Network security weakens.
Boom!

The Bitcoin network will have additional protection the form of the hashrate of all full nodes with the CPU mining option enabled.

Am I missing something here?

For starters it requires a hard fork to make a major change in bitcoin consensus. That means the benefit of such a change has to be significantly high for it to even be considered by the network.
Additionally when it comes to doing work we have no way of distinguishing what hardware was used to perform that work. In other words someone could build a new ASIC to mine the new "slow CPU mining option" and we would be right back where we started.

First of all, how would consensus work when are 2 different PoW (SHA-256 and other algorithm for CPU) on the network?


Even without ASIC, someone could simply build CPU farm (just like miner build GPU farm). Besides, used CPU/server rack sometimes could be found really cheap on online shop.

No no, I think he means simply adding back the CPU mining capability to Bitcoin Core. It would definitely be super slow and unprofitable (hence 'slow mining' wording), so you would run it without pool (decentralizing hashrate) and in case large parts of the mining network go down, diff will adjust and all the full nodes together could act as sort of a fallback. The issue though is the scales we're talking about. ASICs are not just a bit faster than CPUs, they're orders of magnitude faster. So I'm not sure if even all Bitcoin nodes ran a CPU miner in the background, it would help in any type of attack.
The idea though (decentralizing not only nodes but also hashpower) is currently embodied in the FutureBit Apollo (https://bitcointalk.org/index.php?topic=5314398.0) project.

Because it is more likely that you will win a millions or billions of dollars in a lottery than you solo mine a single block on your CPU. Also, this option is still available, you can call generatetoaddress and mine a block in this way. Also you can connect any CPU mining software, choose SHA-256d as an algorithm and start mining on your CPU. Technically, you can connect your CPU miner to your full node. Practically, you will get nothing, or maybe a single block in your lifetime, if you will be extremely lucky.

In practice, if you want to reintroduce CPU mining option and if you want to get any coins, you can try to do some kind of mining in the Lightning Network. Then, I can imagine that a thousands or millions of CPU miners will mine on some shared N-of-N multisig, expressed as a single taproot address, and maybe will mine some block together. But for most of the time they will get nothing and use a fraction of their computing power to replace LN fees with their blocks. So, it is technically possible to, for example mine a block way easier and instead of receiving 6.25 BTC plus fees, receive one satoshi in LN, because your block will meet around 625,000,000 easier difficulty and another party will accept shares instead of coins.

Currently, changing the mining algorithm from SHA-256d to something different is not needed. All that is needed to decentralize mining, is receiving smaller amounts of coins without having to trust any centralized mining pools. I can imagine people moving single satoshis, millisatoshis, or maybe smaller amounts in decentralized way. The algorithm can be the same, as long as it is not broken.

Nobody needs that. You can connect any miner to your full node, in this way you can replace the old miner with the new miner (and even run them on two machines in parallel to compare them) without changing Bitcoin Core. That situation is way better than rebuilding the Core client, just because you want to make faster miner.

LN has no mining, it's not a blockchain. It's an off-chain transaction method. So you cannot mine 'in the Lightning Network'.

True, you can use a CPU miner and connect it to Core, that's possible.

It is not a setup that exists today, it is just my explanation of what is technically possible and could be done to decentralize mining and to make CPU mining possible. For now, it is just an idea, more work on that is needed to make it real.

Oh, you mean sort of decentralized home mining pool through Lightning 'contracts' in a way? Not 100% sure what you envision, but a lot will be possible through Lightning. Definitely excited for the future!

But they didn't remove the mining capabilities from core, they just removed the command for it. The code still exists.

You are right, they won't. We are talking about millions of hashes per second for CPUs (140 million according to wiki (https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#CPUs.2FAPUs)) compared to hundred tera hashes per second (that's 100 trillion). They can't compare and even if ASICs went down there won't be enough blocks mined to reach the difficulty adjustment.

They did even less than that: there are still commands that allow generating blocks: you have "generatetoaddress", "generatetodescriptor" and "generateblock". They can be used on all networks, including mainnet. But there is a catch: they are building on top of the block they saw when executing command, so if you run "generatexyz" command and a new block will be received during mining, you will mine a block on top of some old block. So, you can mine directly using Bitcoin Core and nothing else, but it is easier to connect external miner, even if it will be some CPU miner, because it is more convenient and you will get less stale blocks in this way, because any miner will take care of calling "getblocktemplate" and updating previous block and other block data correctly.

I agree it's not needed to change SHA-256 and it'd be great to reduce dominance of centralized pool. However, i'm not talking about changing SHA-256, but running 2 algorithm together since i assumed that's what @itel meant.

Running two algorithms together is also possible. You can require SHA-256d with existing difficulty and some new algorithm with some new difficulty. First you rehash all old blocks with some new algorithm, then you include both headers: old nodes see old headers and stay in the network, new nodes see everything.

If SHA-256d will be completely broken, it is possible to force producing blocks with all (or almost all) leading zeros and store new hashes in the same place. For example: if you have 256-bit hashes and it is trivial to produce a hash with 224-bit leading zeros, then you can place the whole previous block hash of the new hashing function in the same field, then you will store both old and new block headers in a compact, 80-byte form.

If we want to solve the issue of mining pools having more power than they should then we should just solve that instead of changing the bitcoin protocol that has nothing to do with mining pool and their issues and add new issues on top of all that.
The solution is also not that hard, we just have to change the pool protocol and how the miner communicates with the pool so that the miner can participate in decision making such as signalling for changes. There are proposals like betterhash (https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki) out there already.

I don't think that is very realistic. L2 protocols are not ever going to have anything similar to PoW-type mining because they rely on the L1 layer. The closest thing to mining on LN we will ever see is someone running a LN node that generates revenue via LN-tx fees in a way that is similar to how PoS miners earn "mining" revenue.

But, contributing power to a pool doesn't pay you on-chain without trusting the pool. I haven't tried this ever, but don't you get pool shares firstly and then you give those for BTC? Wouldn't it be better if you were rewarded every hour, off-chain?

Also, let's not forget that: LN is essentially PoS!  :)

That kind of already exists, actually! NiceHash supports Lightning payments with a pretty low limit, so you could cash out daily if you have enough hashpower.

When you mine via a pool today, the pool will periodically payout your earnings. If someone was earning enough, they could receive their earnings every hour.

I also don't think it would be feasible for pools to offer LN payouts if the pool is obtaining its revenue from block rewards (as opposed to selling hashrate to a third party). The pool would need to consistently by opening new channels, and the miners would likely be consistently closing channels.

I am not sure what the payment structure is for most pools today, however there are many payment structures that depend on the pool's performance over periods longer than one hour.   

From an earnings perspective somewhat, but not from a governance perspective.

If you have a single LN channel open with a large capacity amount, you are not going to earn any revenue, because there would be no routes going through your node. Going a step further, if you have a small number of channels open with a lot of capacity, your node may not get much traffic, depending on the network topology. If you have many channels open, with a fairly small amount of capacity, you may earn more than the person with larger capacity if your open channels are well placed within the network, such that many people route payments through your node.

PoS nodes also can choose which transactions to confirm. With LN, it is not possible to choose which transactions to allow (other than by amount of the tx and the amount the participants are paying your node).

Despite this not being foolproof, it would be interesting to submit a BIP for adding metadata such as the device used within the GetBlockTemplate RPC, obviously with small size limits.

That would be similar to looking at the output address of the block reward to try to figure out how many miners are mining. It would be trivial for a miner to change the metadata for every block they find.

I don't think any "ASIC resistant" algorithm would be desirable to implement. All it would do would be to make it more difficult to develop ASICs, and there is always the risk that the person advocating for a particular algorithm has already done some research on how to create ASICs for that algorithm.

So far based on what I've seen ASIC resistant meant you can't use bitcoin SHA256d ASICs to mine that algorithm but creation of an application-specific integrated circuit (ie. ASIC) is very well possible. Even those that tried using more memory with memory expensive algorithms ended up having ASICs.
The only working solution so far seems to have been changing the algorithm every now and then!

P.S. Do we even want an ASIC resistant algorithm? After all ASICs with their huge hashrate are providing the security.

No, we don't need that. Pools were created to reward miners more often for a fraction of their power. Many coins were created just because mining difficulty on Bitcoin was too high and it was easier to mine some altcoin and exchange it for Bitcoin. So, there is no need to change the mining algorithm, as long as it is not broken. The only problem is getting a fraction of the block reward in decentralized way, so that running a full node and mining N times easier block would result in getting N times smaller reward. So far, people solved that problem by creating centralized pools and mining altcoins, but I believe there is a solution that could work directly on Bitcoin.

While i agree with your statement, very few ASIC-resistant perform good enough. For example, developing Ethash ASIC took long time and it's efficiency isn't very big against GPU (if you compare efficiency between GPU and ASIC with different ASIC-resistant algorithm). RandomX also looks promising, but time will tell how well it perform.


As long as there's multiple competitor on SHA-256 ASIC, i would say no.

Right. ASIC resistant algorithms have only delayed the creation of ASICs.

I don't think having a high hashrate is necessarily something that provides security. If the hashrate is 1000 hashes per second, an attacker will need 500, or 50% of the hashrate to reliably attack the network. If the network hashrate is 100k hashes per second, an attacker would still need 50.01% of the network hashrate to attack.

What I believe provides more security is the value of the miners compared to the value of the miners if there was no bitcoin, and the R&D cost of developing the miners. If there is a high cost to develop the miners, and if the miners are valuable, the cost of attacking the network will be very high.

The argument against ASICs is that ASICs will lead to there being fewer people mining because of the high cost of ASICs. So there is the risk that a small number of miners could potentially team up to attack the network. Without ASICs, the mining process would be something closer to "one person, one vote". I think if there were no ASIC (or GPU) mining, it would still be possible for an attacker to spin up 100k VPS on GCS or AWS to attack the network.

To be fair the first bitcoin ASIC wasn't as good as they are today either. For example a single ASIC unit back in 2012-2013 was only working with 0.1 to 0.3 GHS speed.

Also you have to keep issues of altcoins in mind, for example in case of Ethereum the incentive to work on an ASIC was very little and instead the manufacturers were constantly discouraged from making such an investment since this centralized altcoin has always been threatening to change PoW algorithm, they even had a difficulty bomb that ensured it.
So it is understandable that nobody wanted to dedicate valuable resources to creating Ethash ASIC for many years.

P.S. AFAIK ether miners are still computing a single round of Keccak256 (ie. SHA3-256) and this hash algorithm is designed in a way to have a computation cost that is roughly the same as SHA256. We compute a double SHA256 in bitcoin.