Nodes are storage devices that are connected to the internet and store all transaction data right from the start, as a chain of information. This chain of information is known as the blockchain. Nodes send transaction information from the user to the miner and also store the same on the blockchain. They check every transaction, as well as the hash generated by miners to see if the transaction data aligns with the hash generated by the miners.
Nodes confirm that all the data complies with the respective cryptocurrency. Any invalid transaction that doesn’t conform to the respective node will be rejected by the network. Once a transaction is accepted into the blockchain, it cannot be revoked or it’ll be extremely hard and costly to make any changes to the records held by these nodes.
A full node is one that completely validates the transactions and blocks. They help the network by accepting transactions and blocks from other full nodes. It validates those transactions and blocks and further relays them to other full nodes.
How important is it to be running a full node as a user of bitcoin?
It is quite important to run a full node if you’re a user of Bitcoin. There are two ways to find out if you either want to know if a transaction has been confirmed or if you’ve received a payment. One of the ways if to access a block explorer by typing in ‘blockchain.info’, ‘blocktrail.com’, ‘blockcypher.com’ or one of these other blockchain explorers.
These block explorers will tell you that they think, or they want you to think that the transaction has been confirmed. The only way you’ll know that no-one has hacked them is; if there isn’t a bug in their node providing misleading information, if they haven’t decided to directly mislead you, or if your own computer and browser aren’t compromised to display false information.
While using a block explorer, you don’t really know if the transaction has been confirmed. If you then use that information to make decisions, especially expensive decisions – such as letting someone who supposedly just purchased your car, drive off with it – because a block explorer said that they have paid you and there have been three confirmations; you are, thus, delegating the responsibility for validation.
This results in the trust model being broken as you shouldn’t be delegating that responsibility. You should be using your own node that you properly and independently configured to stay within consensus. It should be upgraded to the software version and types of capabilities that you feel comfortable with.
You should ask that node whether you’ve received a payment and it will give you an independent answer based on its own evaluation of the consensus rules.
Can most users currently do that? No. However, people who are running companies need to run their own node, as well as people who are developing and servicing wallets with a lot of money. Most users won’t run nodes, as they are using lightweight wallets, but they do so at a cost to themselves.
The cost is in regards to the certainty of their transactions. That doesn’t mean it isn’t an issue for the rest of the network, if you aren’t running a node.
Not just you, but if more people run nodes for the purpose of checking whether a transaction has been confirmed and base their economic decisions on that, it becomes more meaningful. If you simply run a node on Amazon Web Services where it costs you $15 to set it up, it won’t do anything as it is on an infrastructure that you don’t control.
It won’t really do anything except if you pay for some bandwidth that may help new nodes to bootstrap, but your control over that will be very limited. If you have the ability, it is important for you to run a node on your own internet connection, with your own hardware and in the security of your own home or office. What’s ideal is running a node with a satellite feed. What’s even better is reconciling what’s coming from the satellite with the internet.
By doing so, you would increase the resilience and robustness of yourself and the blockchain network.
Again, not many can do that.
Is it more important to have decentralization among miners, nodes, or both? Why?
It is important to have decentralization in every aspect of Bitcoin. Centralization is a point of weakness, a point of potential failure, corruption, and take-over.
When we talk about decentralization of miners, we need to think of it in four very distinct ways.
First, is the manufacturing of mining hardware, specifically the high-end, cutting-edge 16 to 12 nanometer silicon fabrication of ASICs. Centralization in manufacturing can drive centralization in the other areas.
Next, is the ownership of mining hardware itself or the mining ‘farmers’ or miners who own the mining farms. If only a few organizations own mining equipment and control how it is being used, that results in a problem.
Then there’s the decentralization of mining geography. Even if the mining equipment is owned by a lot of different people or organizations – if it is housed in only a few locations, in terms of the same warehouse or same geographic vicinity – there is a problem. Right now, a very large percentage of the mining equipment (while controlled by many miners), is located primarily in two provinces of China. Geographically, that isn’t good.
Finally, mining pools where multiple miners spread out their gains and smooth out the probability distribution of finding blocks and rewards – require decentralization. Among miners, we need decentralization in manufacturing, ownership, geography and pools. We also need decentralization in nodes and the types of nodes people run.
Nodes used by individuals to run wallets, nodes used by intermediaries for merchant services, nodes used by merchants to run e-commerce websites, nodes used by companies to run wallet infrastructure, and nodes used by exchanges – all of them need to be decentralized. We need as many of those types to run, in as many geographies through as many different types of connections; internet, dial-up, leased line, microwave, satellite, frequency-hopping spread spectrums (FHSS).
Decentralization everywhere is the key here, i.e. decentralization in as many places as possible. These things will, of course, ebb and flow over time. We might see some areas becoming more centralized, then become more decentralized and perhaps revert back to centralization.
These areas won’t all move in the same direction at the same time, which is a good thing. Changes in technology operational models, profitability and supple chains will affect decentralization.
For example, in the manufacture of ASICs, the biggest change that has happened recently is the fact that we finally caught up to Moore’s law and we are right at the front end of that. This slows down the incremental improvements in mining capability and performance, significantly, by orders of magnitude.
That changes the dynamics of the supply chain. Now you can actually ship those chips and it will be obsolete by the time it arrives at its destination, a thousand kilometers away. You can put it on a container ship for two months and it will still be useful hardware after those two shipping months. This changes the ownership of the decentralization of ownership and geographic distribution of mining equipment.
Sometimes we will have external shocks to the system such as a country cracking down on mining. When Venezuela bans mining or requires everybody to apply for a license, that will most probably be a trap. Don’t get a license. They will find you.
But when Venezuela does it, it wouldn’t have a big impact on the whole network. If China was to ban mining or require licenses, that could dramatically change the economics. It would make the centralization of mining an obvious disadvantage. This then would actually lead to decentralization of mining.
Is it possible to run a Lightning node for a few hours a day, like a full node? Does shutting down a Lightning node disrupt Lightning payments?
It is possible to run a Lightning node only part-time. If you want to shut down your node and have outstanding channels that are open, you may use a watchtower to monitor for channel closure if you plan to be offline for longer than the timeout period. This makes sure that the other participant in the channel doesn’t try to cheat by broadcasting a prior state.
One of the interesting innovations in the Lightning protocol, which was developed after the original paper, was a great contribution by Thaddeus Dryja and Olaoluwa Osuntokun. They implemented the ability to give a third-party the role to monitor for cheating in Lightning payment channels.
The only way you can cheat in certain payment channel designs is by re-transmitting a prior state which has been revoked, in order to get a more preferential balance on your side of the channel. For example, you could pretend that you haven’t actually spent some of that money in the channel.
There is a way to protect against that in Lightning.
If you try to do that, the other person being cheated has the opportunity to use a revocation key and transmit a countervailing transaction. While you are waiting to get paid from your cheat transaction in three days due to the timeout period, they can immediately take the money – not just the money that you owe them, but the entire balance of the channel.
It is essentially a scorched-earth policy, where you are punished for trying to cheat by losing everything. To do that, they must be online to catch you cheating without the time-lock period,
When you are waiting for a confirmation. If you are running a Lightning node, part-time, and plan to be offline longer than the timeout period, you will need to transmit those revocation states to a third-party who is running a node, full-time.
If they see someone trying to cheat, they will broadcast the punishment transaction to wipe the channel in your favor, save you from being cheated, and punish the transgressor.
The best part of that function is the innovation which prevents the third-party from knowing what channels you have open or how much money you have in those channels. They will only know if they see a cheat. So you can run a Lightning node part-time.
It is factored into the design, with the ability to invite a third-party to do the enforcement.
How can a non-developers become involved with Lightning right now?
If you have experience in user interface design, you can definitely become involved in Lightning. If you don’t, then you can download some of the existing Lightning wallets and start using them, seeing where they work and don’t work for you.
Today, you can only use them on test-net, but that is okay. You can help with testing and give feedback to the developers. Ultimately, a Lightning wallet should look like a regular Bitcoin wallet. Eventually, it should not be necessary for you to know whether the payment you made was with or without SegWit using Lightning, or on the base blockchain to a regular bitcoin address.
It should not matter. You will basically scan a QR code, click ‘pay,’ and it tells you how long until confirmation and how much it will cost in terms of fees. You may notice that some of your transactions are much faster and cheaper to execute. Those are the Lightning transactions.
Other transactions are slower and a bit more expensive, for example; SegWit transactions. Some are very expensive and slow; those are legacy bitcoin transactions, on a blockchain that is probably congested. If the interface design is good, that is the only indication you should get. Your wallet does not need to tell you how many channels you have open or who you have those channels with, unless you go into some advanced setting.
All of that should be invisible to the end user. It should be usable like a regular Bitcoin wallet.
Not all of the Lightning wallets are like that. Most of them are designed by (and for) developers and engineers. They show a lot of background detail and are not very user friendly. Some examples are Eclair and Zap wallet.
That can be enormously helpful. If you are a graphic designer or user interface designer, even more so!
The white paper emphasizes the need for honest nodes to control the majority of the CPU power. Is there a way for a non-technical person to help secure the Bitcoin network?
No, there isn’t. That aspect, which is the mining function, requires you to have significant processing capability. It is managed entirely by specialised ASIC chips now instead of CPU, which can be difficult to source. At the current level of competition, mining is a viciously competitive game that requires significant investment.
You can dip a toe into this pool, but unless you have $50 million to spare to hire some very technical people, the average non-technical person cannot help secure the network through mining.
They can help secure the network, however, by running a node at home, to validate their own transactions and to see if they have been paid, or to help new nodes bootstrap for example.
Use wallets and other software that align with your own principles. That is very powerful. You can have a great effect just through your choices as a consumer, and by running a node at home. It is also a good learning experience.
Running a node is fundamentally important, whether you’re a user or a miner of a particular decentralized cryptocurrency protocol. The problem is, setting up a node comes with certain concerns related to the costs of continuously running the node, as well as the risk of always being connected to the internet. However, running a node can ensure to you, as a user, that a transaction has been confirmed or if you’ve received payments. As of now, companies, individuals or institutions developing servicing wallets and miners use nodes as they have the resources and the capacity to run nodes. However, we aren’t far from a future where the average user understands the technicality and the functions associated with running a node.
This article is a transcription of Andreas Antonopoulos’ explanation on why it is important to run a node.
About Bank Of Hodlers
Bank of Hodlers is a Blockchain-based firm that provides financial services for your cryptocurrencies in terms of ensuring security against Crypto-theft, providing Crypto credit cards and Crypto-backed loans.