Name: John Light

Topic: Bitcoin Full Nodes

Location: London Bitcoin Devs

Date: July 23rd 2018

Video: https://www.youtube.com/watch?v=qzbdNefsA-0

John Light blog post on soft forks and hard forks: https://medium.com/@lightcoin/the-differences-between-a-hard-fork-a-soft-fork-and-a-chain-split-and-what-they-mean-for-the-769273f358c9

Transcript by: Michael Folkson

Intro

My presentation today is going to be about Bitcoin full nodes. Everything you wanted to know and more. There should perhaps be an asterisk because I’m not going to say literally everything but if anyone in the audience has any questions that want to go really deep down the rabbit hole then we’ll see just how far down we can go. I am John Light, co-founder of Bitseed. Our website is bitseed.org if you want to check it out later. I’ll talk a little bit about what we do there at the end of the presentation. That’s my Twitter handle \@lightcoin if you feel like following.

What is a bitcoin full node?

A Bitcoin full node is a computer that runs a fully verifying implementation of the Bitcoin protocol. This means that these full nodes verify that every block created by miners are actually following the rules of the Bitcoin protocol. These are some of the different implementations that exist of the Bitcoin protocol. These all implement the same rules so they can all stay in consensus on what is the current valid version of the blockchain.

There’s Bcoin which is a Javascript implementation, bitcoinj which is a Java implementation, Libbitcoin which is a C++ implementation, btcd which is a Go implementation, I don’t think that’s their logo, that’s just the Go gopher. Bitcoin Core of course which is the most popular implementation of the Bitcoin protocol. Parity also has a Bitcoin implementation in Rust. There are several other full node clients that you can download. These are the most popular ones by language.

This is what Bitcoin full nodes look like when they are running, these are the kinds of nodes that people would run at home. You could also of course just run a Bitcoin full node on your laptop or desktop computer or run one on a server in the cloud. For the people that decide to run dedicated hardware nodes these are usually what they look like. You’ve got them running on a Raspberry Pi or in the case of Bitseed a small ARM board Arduino or a mini-PC. These usually have enough computing power and hard drive space to run a full node. That is an old model of Bitseed in this picture. I just pulled it off the internet. We’ll take a look at what Bitseed looks like today later.

What rules do bitcoin full nodes enforce?

https://en.bitcoin.it/wiki/Protocol_rules

So what are some of the rules that full nodes enforce? These are just some of the rules. A full list of rules, you can find that on this link at the bottom of this slide. That is the Bitcoin wiki protocol rules page. For example some of the rules that full nodes enforce, they make sure every transaction in a block is valid meaning that the sender actually has the money. They are not just printing money out of thin air. The money has not been spent before so they are preventing double spending. The signature actually matches the sender’s public key. Other people can’t spend your money on your behalf. Another example of a rule would be every block has the required amount of work. This keeps the miners honest so that the miners aren’t able to produce arbitrary unlimited amounts of blocks without doing the appropriate amount of work. And every block is equal to or smaller than the max block weight limit or the max block size which is currently 1 million virtual bytes. Bitcoin used to measure block size in terms of bytes and now it is measured in weight units or virtual bytes.

What are the different types of full nodes?

What are the different types of full nodes? There’s actually multiple different types of full nodes. One of those is a pruned, selfish full node. There are archival, selfish full nodes. There are pruned, listening full nodes. Archival, listening full nodes. And perhaps the most important of all of the full nodes the economic full nodes. We will dive into each of these in more detail here.

Pruned selfish full nodes

A pruned selfish full node prunes raw block and undo data by deleting it from disk. Pruned nodes really only keep the data that they are interested in and maybe a little bit extra just to be somewhat useful to the rest of the network. When I say that a full node is selfish I mean that this is a Bitcoin node that does not upload data back to the network. It is only downloading data. In torrenting lingo this would be like a leecher. It is only downloading data, it is not uploading data back to the network. These nodes are only downloading and validating blocks locally. Finally, users of pruned selfish nodes get the benefit of using their own full node because they are fully verifying all of the new blocks that are created by miners. But they are saving hard drive space by deleting data that they are not interested in. They validate the block, throw away what they don’t need and only keep what they need on disk.

(Sjors Provoost added in the YouTube comments afterwards that non-listening nodes just means other nodes can’t connect to them but they still connect to other nodes themselves - outbound. Once connected data flows both ways. In practice of course it’s unlikely such a node connects to a fresh new node so it’s less helpful to new nodes. But “selfish” is probably too strong a description.)

Archival selfish full nodes

Then there are archival selfish full nodes. Like I said a selfish node is one that does not upload data back to the network. But an archival full node specifically stores a complete copy of the Bitcoin blockchain data on disk. It doesn’t delete anything, it actually keeps the entire history of the Bitcoin blockchain on its hard drive. With this complete copy it can make queries against the blockchain to find information pertaining to particular transactions or addresses. If it wants to do more advanced queries then the full node will have to build a full transaction index from all of that data that it has stored on disk. The blockchain is like a raw source of data and then from a transaction index you can build things like block explorers and other kinds of complex querying databases.

Pruned listening full nodes

Then there are pruned listening full nodes. As I mentioned pruned nodes only keep some of the blockchain data on disk but if it’s a listening full node that means the Bitcoin node is actually uploading or relaying Bitcoin block and transaction data to other peers on the network. Whenever a new peer comes online and it’s like “Hey. Give me the latest blockchain data.” Listening nodes will hear that request and respond by sending the peer some blockchain data. Usually blockchain data that the peer doesn’t already have. Listening nodes can connect to peers over the clearnet, the regular HTTP IPv4 network, over Tor, or both. This would be like a hybrid mode that bridges the clearnet and the Tor network. Hybrid nodes are important because they provide a critical link that passes blockchain data between the clearnet and the Tor network. Otherwise they would be two separate networks partitioned from each other. That would of course cause a split and that is no good. Listening nodes do have the ability to limit the amount of data that they upload per day in order to save bandwidth. If you left it uncapped you could end up uploading many gigabytes worth of data per day. A lot of folks who run full nodes from their residential internet connection, their ISP will impose bandwidth caps, both on downloads and uploads. If you don’t limit the amount of data that you are uploading you can hit that limit pretty quickly. It is not super common but it can happen especially if there are a bunch of new peers joining and they are downloading the entire blockchain from you multiple times throughout the course of the month. Finally because pruned nodes are not stored all of the blockchain data they are unable to upload copies of archival block data that they do not actually have. They are only able to share the data with new peers that they actually have on disk.

Archival listening full nodes

Then there are archival listening nodes. Because these are archival nodes they can upload complete copies of any blockchain data to other peers on the network. They have the full history of the blockchain stored so they can upload that full history if a peer requests it. These nodes are useful, indeed necessary for bootstrapping new full node peers or helping SPV wallets discover the balance of their addresses. Archival listening full nodes are really important for preserving the integrity and the history of the full Bitcoin blockchain. Because they are storing a full copy of the blockchain they are able to serve that full copy to peers and ensure that the Bitcoin blockchain continues to be accessible for anybody that wants a copy which is really important. If we lost that historical data then that would destroy the integrity of the ledger and make it much less likely that people are going to trust that history or even the current UTXO set. By storing a full copy you are able to validate all the way back to the genesis block that the current UTXO set is valid. UTXO just means unspent transaction outputs. Basically the current state of everyone’s balances on the ledger.

Economic full nodes

https://en.bitcoin.it/wiki/Economic_majority

Finally as I mentioned perhaps the most important type of full node is the economic full node. Economic full nodes are full nodes that accept Bitcoin in exchange for value. Instead of just sitting there on the network passing messages back and forth, people who use economic full nodes are actually using their full nodes to verify incoming transactions. Based on the validity of those transactions they are exchanging Bitcoin for goods and services of real value. These are the nodes that actually give Bitcoin monetary value and determine through consensus what is Bitcoin. Last year during the Bitcoin Unlimited thing and SegWit2x there were a lot of questions of if a hard fork happens and there’s a chain split which version of the blockchain is the canonical “Bitcoin”. It is really economic full nodes that determine what is Bitcoin by putting their economic weight behind one chain or the other. Of course miners will then follow the economic majority so that they can make the most amount of money mining. Without full nodes that are willing to accept Bitcoin in exchange for valuable goods and services Bitcoin would basically be worthless. You can read more about this on the economic majority page of the Bitcoin wiki.

http://luke.dashjr.org/programs/bitcoin/files/charts/services.html

This is a screenshot from a program that Bitcoin Core developer Luke Dashjr is running. I put a link to the source at the bottom of the slide here. This shows that based on his last scan of the network there were approximately 79,973 archive nodes, meaning full nodes that are storing a full copy of the blockchain. 9 percent of those or about 7,700 of those archive nodes were listening nodes. 86 or 87 percent were non listening or selfish nodes that were just downloading block data. 9 percent were actually listening nodes that upload data back to the network. I think this is an important chart because there are a lot of people that will go to https://bitnodes.io/nodes/live-map/. You will see something like this pretty often. They will say “It says only 9000 nodes” or on this chart 7,700 nodes. That is not a lot of full nodes. But those are only listening nodes. That is an important metric but it does ignore the tens of thousands more non-listening nodes that are still participating in full validation of the blockchain. Those could be merchants, those could be traders, those could be average users. We don’t know what these people are using their nodes for. But the fact that they are participating in full validation in decentralized consensus is significant. There are about 80,000 of those nodes that Luke Dashjr’s crawler has been able to detect. There could be even more. It is hard to make an exact measurement just due to the decentralized nature of the network. Again this is a bitnodes map. You can generate your own map that looks like this at bitnodes.io. This shows you geographically where all of the full nodes that are listening on the network are located. I should note that I do not believe that this map takes into account listening nodes that are running over Tor. I believe this map is only mapping the clearnet listening node network. If there are listening nodes running over Tor that are serving Tor peers with block data I’m pretty sure that they are not showing up on this map.

What are the benefits of running a full node?

So what are the benefits of running a full node? Some of these you could say are objective, others are my own subjective benefits that I would personally say are benefits of running a full node. One of the benefits is trustless validation of interesting transactions. Full nodes protect the privacy of balance lookups. They decentralize validation and block and transaction relaying. And archival nodes in particular preserve the full blockchain and can make it available to new peers on the network. We will dive into each of these individually here.

Trustless validation of interesting transactions

Trustless validation of interesting transactions, what does that mean? It means that no trusted third parties are required for transaction validation. If you are using a wallet, like say Mycelium or blockchain.info, those companies are basically running a full node on your behalf and you are just asking those nodes “Hey these are my addresses. What are my balances?” When those nodes send you a response back with your wallet balances you are trusting explicitly that those full nodes have actually properly validated those balances and the blocks that those balances were included in. You are not doing your own validation, you are outsourcing that validation to a trusted third party. With your own full node you can validate for yourself that a transaction was included in a block that was added to the most difficult valid blockchain. Your full node is checking the proof of work on all of the blocks and it is also checking the validity of all of the transactions and other data that’s included in a block as well. There have been problems in the past where miners weren’t doing full validation and they were only doing SPV validation or spy mining. They actually mined on top of invalid blocks which caused a re-org and caused not only the miners to lose money but anybody who had their transactions included in one of these blocks that got orphaned. That transaction was basically reversed because a valid version of the blockchain overtook that version of history. Anybody that wasn’t doing full validation and was just trusting miners or trusting just the block headers, they had their transactions reversed. And maybe their transactions were included in one of the valid blocks on the valid blockchain or maybe they had to submit their transaction to another block. So full validation basically ensures you don’t have to trust miners to validate the blocks, you can actually validate all of the blocks for yourself.

Protect the privacy of balance lookups

Full nodes also protect the privacy of balance lookups. In addition to not having to trust a third party with block validation you also don’t have to trust a third party with the privacy of your wallet balances. You can look up wallet balances without linking your addresses together. Like I said if you are using a wallet that has a centralized node that is run by a trusted third party your wallet is basically sending all of its addresses to that third party and saying “Hey. Here are the addresses I am interested in. Please send me my balances back.” This is really convenient because you don’t have to run your own full node but it is also really bad for privacy because now that central third party knows all the addresses that you are interested in and can link all those addresses together and say “All of these addresses are owned by the same person.” This can be bad for privacy. For example if one of those addresses was used to donate to Wikileaks or something and another one of the addresses was used to receive your monthly paycheck then it is really obvious to that third party that those two addresses are the same person. The same person that’s getting paid by whatever your employer is also the same person that’s donating to Wikileaks. Unfortunately in society today that can be problematic for someone’s career or even potentially from a legal standpoint. Trusting third parties with the privacy of your addresses is not ideal. Additionally you can look up other address balances without letting a third party know what addresses you are interested in. This is a little bit different. Here I am referring to not just your own wallet addresses but I’m also referring to any address that you might be interested in checking the balance of. Maybe for example you sent a payment to somebody and you wanted to see if the payment got confirmed on their end. Or you want to see how much Bitcoin a particular address has received in donations. Then you could look up that address balance without letting a third party know that you specifically are interested in that address. Again with the Wikileaks example if you want to see how much Bitcoin Wikileaks has received in donations you can just query your own private full node for the balance of Wikileaks’ Bitcoin address and then get that balance back. No third parties will ever need to know that you specifically were interested in Wikileaks’ addresses. Again Wikileaks is just an example. It could be any third party address that you are interested in. Perhaps more politically or legally sensitive or less so. It doesn’t matter.

Decentralize validation + block and transaction relaying

Next, full nodes decentralize validation and block and transaction relaying. That is a lot of big words. Let’s break it down. At a basic level this is a way for you as a full node user to hold miners accountable and keep them honest. As I mentioned earlier there have actually been instances where miners build on top of invalid blocks. Anything could have been happening in those blocks. New Bitcoin could have been created out of thin air. The blocks could have been much bigger than the actual block size limit. They could have been double spending Bitcoins. They could have done all kinds of different bad things in these invalid blocks but because there was a giant network of fully validating full nodes keeping them honest all of those invalid blocks ended up getting orphaned and the miners lost the block rewards that they earned from all of the blocks that they built on top of the invalid blocks. It is important to have this large decentralized network of fully validating nodes in order to hold the miners accountable and keep them honest. Also by having this large network of listening nodes you can prevent censorship by routing the blocks created by miners and transactions created by users. You can imagine on the extreme scale if all the blocks and all the transactions had to go through one node, or just a very small handful of nodes run by a cartel, that one node or that cartel of nodes could very easily censor blocks that were created by say miners that weren’t their friends or censor transactions that are being sent by users that the one master node or cartel nodes don’t like. Or censor transactions that are being sent a user that the master node of cartel of nodes doesn’t like. Because there is this large decentralized network of many thousands of listening nodes the odds of that kind of censorship actually happening are drastically, significantly reduced down to practically zero. As long as you are paying a market rate fee for your transaction it is probably going to get into a block. As long as you are producing valid blocks and you are the first miner to produce that valid block and you can get that block to the majority of the network your block is going to get added to the blockchain. That’s because the network has this large decentralized group of fully validating listening nodes.

Preserve blockchain history

Finally, perhaps the most important role of archival full nodes in particular is preserving the blockchain history. Of course it makes the full blockchain history available to new peers. That’s the day job of an archival listening full node. Then its backup purpose to keep Bitcoin going after a catastrophic failure. Let’s say the galaxy shoots a pulsar or something like that, I’m not an astrophysicist, it shoots some crazy radio waves at earth and knocks out all of our electricity. That would suck. But it is something that the Bitcoin network could recover from because there are thousands of computers that are storing a full copy of the Bitcoin blockchain. You could, once you get electricity and the internet working again, recover by just bringing online one of these archival full nodes that has the most recent copy of the blockchain. Maybe you lose some data in the last couple of days because a backup wasn’t taken or something like that, but you don’t lose everything which is really great. This will be especially useful after more than many decades of blockchain history. If you lose a few years, that was an interesting experiment. It sucks that it failed like that. But if you have decades of history that are being preserved by the blockchain it is really important that you are able to recover from a catastrophic failure like that. Or else civilization melts downs. That is assuming that after decades of its existence Bitcoin is used for significant civilizational infrastructure which I believe it will be.

Size of the blockchain and rate of growth

Q - How big is the full blockchain history now? What’s the rate of growth?

A - What I can do is just show you exactly. We’ll go to blockchain.com. This is a pretty common block explorer. They have some cool charts that show you these kinds of statistics. This is the blockchain size. It grows more or less linearly because there is a cap on the block size limit. The blockchain is only going to grow linearly at most at the size of the max block size. Right now it says the blockchain is about 176 gigabytes in size. It grows at somewhere between 1 megabyte and 2 megabytes every 10 minutes. That’s between 6 and 12 megabytes a hour. I’m bad at math but it is about 150 megabytes per day or something like that. It is probably somewhere around 50 gigabytes per year at this point. But I could be off on that. It is not a crazy growth rate. Last year with the implementation of SegWit the block size changed from 1 megabyte to 4 million weight units. They changed the way they measure blockchain data sizes which comes out to be about 2 to 2 and a half megabytes sized blocks. That’s as big as a block can get. I hope that answers your question.

Potential shortage of listening nodes

Q - You showed the chart with 87 percent of nodes being non-listening. Does that pose a challenge if there are a lot of growth in non-listening nodes in comparison to a small proportion of listening nodes. In terms of getting those nodes to sync up and stay up to the date with the latest state of the blockchain?

A - Yes. Each listening node can support around 100 to 150 slots that non-listening nodes and SPV nodes can plug into to download data from. I don’t know if that’s a fundamental limitation or just a limitation imposed by Bitcoin Core. I imagine you could invent full node software that allows more nodes to get plugged in. But that’s how Bitcoin Core works by default today. If more than 120, 130 non-listening nodes are plugging into a listening node or trying to plug into a listening node you are going to start having some syncing problems for sure. The number of non-listening nodes is kind of capped for being online at any one time by the number of listening nodes that are online at any given time.

UPnP vulnerability

Q - Wladimir, one of the core devs, was talking on Twitter about problems with the Universal Plug and Play (UPnP) library and hence perhaps it is not a good idea for people with not much technical expertise to be set up as a listening node. Do you have any view on that from Bitseed’s perspective? What advice do you provide your users and customers?

A - That’s referring to Wladimir van der Laan, he’s the maintainer of Bitcoin Core. A super smart guy, I respect his opinion a lot about this. We did turn off UPnP for a period of time back when the vulnerabilities in UPnP were first disclosed. We believe that UPnP is basically fine for what it is used for right now. We do have it enabled. UPnP is short for the Universal Plug and Play protocol. What this does is if your router supports the UPnP protocol once you plug in your Bitseed node and put it on your local network it will talk to your router and automatically forward the ports necessary so that Bitcoin becomes a listening full node. If you still for whatever reason feel uncomfortable with using UPnP you can disable it and manually forward those ports. It takes a bit of extra work. You have to log into your router, figure out which IP address your Bitseed is sitting on, forward the ports properly etc. It is totally possible and totally doable. We don’t provide instructions for this because every router is different. Again if you don’t feel comfortable using UPnP for any reason you are free to disable it and forward your ports manually. Another thing that we do is we have Tor running on Bitseed by default. If for whatever reason UPnP doesn’t work, you’ve disabled it, your router doesn’t support it, your node is still going to be listening on the Tor network and supporting other peers that are connecting to you through Tor. We have a few different options for people who don’t want to use UPnP for any reason. But I think it is fine for what it is used for today, especially since we don’t store any secrets on Bitseed. Even if there was some sort of remote code execution vulnerability or anything like that the damage that could be done by a hacker is extremely limited. We feel like the convenience trade-off is worth it at this point.

Bitcoin Core default settings

Q - You talked about the different types of nodes. What’s a Bitcoin Core node by default?

A - That’s a great question. If you have Tor running on your computer at the same time as you are running Bitcoin Core then by default Bitcoin Core is an archival listening node running over Tor. It is storing a full copy of the Bitcoin blockchain. It is doing full validation. And it is uploading data back to peers over the Tor network. If you are not running Tor then by default Bitcoin Core is an archival selfish node. It is only downloading transaction data and block data, it is not uploading anything back to the network. Bitcoin Core, I believe still to this today, has UPnP disabled by default. Even if your router supports UPnP, because Bitcoin Core has it disabled by default your node defaults to just downloading block data and not uploading any data back to the network.

Security implications of opening ports

Q - What other security considerations are there when opening and manually forwarding ports? Should a non-technical user educate themselves on the security implications of doing that?

A - I would say from a layman’s perspective there is not a significant security implication. If there is a vulnerability in Bitcoin Core that can be exploited using malformed transactions or something like that then there’s the potential that opening your ports could cause some problems. But assuming that Bitcoin Core is working properly as expected there aren’t any special security considerations for opening the ports. That said, I always encourage people to not store their life savings on their computers and only keep pocket change in any hot wallets. Whether you are running a full node with ports open or not. I would say just running a full node with ports open, you’re not really exposing yourself to any significant kinds of vulnerabilities that you wouldn’t already be exposing yourself to just by connecting to the internet in general. If any security experts are watching this and want to correct me on that point I welcome any new info on that topic.

Live demo of Bitseed

I said live demo here but then I realized that if I do a live demo I’m going to expose my public IP address and I don’t really want to do that. I’m just going to show you what our UI looks like. This is the UI. This is the main status page. This is an old picture, that’s why it says 0.12 but the UI is essentially the same. It is the status page, it shows you what version of Bitcoin Core you are running, what kind of full node you are running, what is the device block height, how many peers are connected to you. If it is more than 8 it means that your node is listening. If it is 8 or less it means that you are just a selfish node. By default your node will connect to 8 peers at most but once you switch your node into listening mode either automatically or manually your node will start to connect to a lot more peers. It can start serving block and transaction data to those peers. It tells you how many transactions are in your mempool. This is really interesting to watch. During periods of high Bitcoin usage in particular you could start to see 5,000 or 10,000 transactions in your mempool. It shows you your minimum relay fee which means that your node will not relay any transactions that have a fee of less than this amount. It will show you your internal IP address which if you are looking at this status page you already know. Then for troubleshooting purposes will show you your Device ID and your Version as well. If you have a problem you can let us know this information and we will try to help you figure it out.

Bitseed Settings

We also have a Settings page. This is the mobile view of the settings page. It basically looks the same on the desktop. That’s the mobile view. We have a few checkboxes that we created that should make it really easy for non-technical users to set the settings that are perhaps most important to running a full node. For example we have a button that says Auto Update. I think we disable that by default now. We used to have an option where users could run a script that automatically checks for software updates from Bitseed once a week or something like that. We have a Tor Enable button which is pretty self explanatory. You are either running Tor in the background on your full node or you are not. We also have a Tor Only mode. If you have Tor Enable checked but you don’t have Tor Only checked then that means that your node is running as a hybrid Tor, clearnet full node. It is both connecting to nodes on the clearnet side of the Bitcoin network and it is connecting to Bitcoin nodes on the Tor side of the Bitcoin network. Essentially serving as a bridge, passing messages back and forth between the clearnet and the Tor network. As I mentioned earlier this is really important because these are the kinds of nodes that help keep nodes that are connected on the Tor side of the network in sync with the rest of the network that is running over clearnet. If you can run a hybrid node and are willing to run a hybrid node those are super valuable for all of the nodes on both the clearnet and the Tor side of the network. But if you only want to connect over Tor that is ok too. You can just click that Tor only box and then your node will only be connecting to other nodes over Tor. We also have a button to enable or disable UPnP. We just talked about that a little bit earlier. Then this is another setting that I believe that we have disabled now. This is Blockchain Backup Enable. On older versions of Bitseed we were using a relatively low power ARM board. It was basically a Raspberry Pi clone called PC Arduino Nano 3. It would just take forever to validate the blockchain. I would be surprised if it could start from scratch and then catch up to the chain tip and stay caught up nowadays just because the CPU power was so weak. But what we would do is sync the blockchain on another computer and then import it into the devices and then ship the devices. And we would keep a backup of the blockchain so that if for any reason the current active version of the blockchain that the node was using was corrupted it could import the backup copy without having to re-download and re-verify the entire blockchain which would take forever if ever catch up to the blockchain tip. Bitseed now uses a mini PC with a x86 board. It is much faster, it has much more RAM, much more CPU power. I don’t even think we store a blockchain backup anymore because the new Bitseed 3 model is able to download and catch up to the blockchain tip relatively quickly. Pretty much as fast as a normal desktop or laptop computer would be able to. That’s an old setting but it is an option that is available for people that are still running old versions of Bitseed. Then we have Min Relay Tx Fee. I explained this earlier. Basically your node won’t relay any transactions that have a fee that is less than this amount. This is useful for preventing spam. If someone is spamming the network with a bunch of 1 satoshi fee transactions with this setting you can tell your node to just ignore all of those transactions. Those transactions won’t even get relayed. There’s a Daily Upload Limit (MB). As I mentioned earlier some people have bandwidth caps and so it is nice to be able to set an upload limit. This is useful even if you are running your node in the cloud. Maybe you are getting charged for data, bandwidth usage, by your hosting provider. You want to set an upload limit so you don’t end up with a 100,000 dollar AWS bill or something like that. Then there’s Mempool Size Limit (MB) option as well. This helps you limit the amount of mempool data that you are storing. I believe it is stored in RAM. Once you’ve messed with your settings you would click the Update Settings button and then restart Bitcoin so your new settings take effect.

Device Status

Finally we have a Device Status page which will tell you how big your disk size is, how much of that space is used, how much of that space is available, how much RAM is used, how much RAM is free, your CPU load, the uptime of your node, the Mac address and the last backup time. Again Bitseed 3 does not do blockchain backups anymore so you probably wouldn’t see this specific statistic if you are running Bitseed 3. But for older models of Bitseed we would let people know the last time their node did a backup which was approximately once per week.

New web Bitseed interface

I am excited to say that we have a community member is working on a new open source web interface for Bitseed. This is an early version of the new interface. It looks pretty similar. I think one cool thing to point out is that this one has an Electrum tab. One of the projects that this community member is working on is making it easy for Bitseed users to also run an Electrum Personal Server so that they connect their Electrum wallet to their own full node. With that feature turned on a Bitseed user would be able to connect their Electrum mobile or desktop wallet to their own private full node and not have to share any of their transaction data with third parties. Still be able to do full validation, private address lookups, private wallet lookups, private transaction broadcasting. This is really cool. Of course if you are the cool guy and you are the one that is running the full node then you can also share your Electrum server with your friends. They can use your full node as well. I think that is going to be a really cool feature that’s going to bring a lot of value to Bitseed users. Of course this web interface is open source anybody that is running a compatible full node will be able to use this interface as well. That’s all I have got in terms of content. Happy to turn it over to questions if there are any more questions about Bitseed or about full nodes in general.

Q&A

Q - What’s your selling pitch for why someone should buy a Bitseed? You talked about why people should run full nodes, why should someone buy a Bitseed?

A - Bitseed is designed for people like me essentially. I really started working on Bitseed to scratch my own itch. I want to be able to run a full node without having to run it on my desktop and take up a bunch of space on my personal hard drive and take up a bunch of computing resources and bandwidth etc on my own personal computer. But I also don’t want to run it in the cloud because I’m not a systems administrator. I don’t feel like dealing with setting up servers and paying monthly hosting fees and figuring out how to do SSH into the command line on the server and keep it up to date etc. There is a lot of effort that goes into maintaining a full node in the cloud it feels like. Plus then your full node is running on somebody else’s computer instead of your own computer. If you are actually using your full node for full validation or any other kinds of sensitive tasks that full node could end up being compromised by either your host or if you are using a VPS maybe one of your neighbors on the VPS. There are a lot of shenanigans that can happen when you are running software on someone else’s computer. Bitseed is designed to be a full node that runs on a separate a machine, it is not running on your personal PC or laptop, it is running on its own dedicated machine inside your personal firewall. Either in your home or at your office. It is running on dedicated hardware that you are in full control of. This puts Bitseed in what I call the fourth amendment zone. I don’t know if there’s an equivalent in the UK but basically it means that your Bitseed is safe from third party hosts that might want to mess around with your full node. Like I said VPS neighbors, if they start to sniff around on the server, or warrant list searches if it really comes to that. Bitseed in short is a way to easily run your own full node on hardware that you control inside your own network without having to use up any resources on your main work or personal computer. You get all the benefits of a full node plus all the benefits of running a node on your own personal computer.

Q - How performant are the full nodes that are running on Raspberry Pis and similar devices? Are they assisting the network just like all other nodes or are they just for testing and experimenting?

A - They serve both purposes really. They are fully validating blockchain data. If they are listening on the network they are serving that data to other peers. As long as they can keep up with the chain tip they are useful to the network. I believe that Satoshi’s Place, the million dollar homepage for Bitcoin or whatever, that people were playing around with on Lightning and I’m sure still play around with to this day, I’m pretty sure that that website was actually run on a full node that was on a Raspberry Pi. Dozens or maybe hundreds of people were connecting to that node over Lightning and drawing penises and Bitcoin Core logos and other silly stuff on the homepage of the website. You’d be surprised what Raspberry Pis can actually do nowadays.

Q - But at some point with that graph you showed earlier with the size of the blockchain increasing linearly, at some point you are not going to be able to run it on Raspberry Pis unless Raspberry Pis increase at a similar rate?

A - That’s more to do with the hard drive size. Raspberry Pis can plug into any sized hard drive. I’ve never seen a Raspberry Pi with a… setup but I imagine that’s probably possible. Even today you could plug into a 2 terabyte hard drive into a Raspberry Pi and it will work. Where Raspberry Pis start to slow down is if the block size itself gets too big. A Raspberry Pi has a certain amount of processing power, both in terms of RAM as well as CPU. The bigger the block size gets the more processing power you need to validate each block. After a certain size, I’m not sure exactly what size that is, but based on my experience with Raspberry Pis I would imagine that it’s not much bigger than 2 megabytes. After a certain size a Raspberry Pi is not going to be able to keep up with the chain tip. Essentially it is going to take longer to validate a block than it takes a miner to produce a block. That means that the node will start falling behind and it will never be able to catch up. It is always going to be still validating the previous blocks as new blocks are coming in. It is never able to catch up to the chain tip. This is one of the reasons why so many people are so hesitant to raise the block size limit beyond a certain point. It is not just that hard forks are hard. Pretty much every core developer, every Bitcoin developer that is realistic with themselves, knows and accepts and has said that Bitcoin is going to have to hard fork eventually to clean up some existing bugs as well as potentially increase the block size beyond 1 megabyte. That’s not the only reason. What should that block size be if they decide to increase it by way of a hard fork? Or even if it is a soft fork through extension blocks or something like that. You have to be careful once you start excluding nodes from validation because this reduces decentralization of the network and removes some of those benefits that I talked about earlier that decentralization of validation brings to the table. It reduces the number of nodes that are keeping miners honest and in check. Also reduces to a degree the overall censorship resistance properties of the network. Many people are very hesitant to start making changes that will be excluding certain kinds of nodes from participating in full validation.

Q - What do the miners run in terms of full nodes on their side? They are running multiple nodes, what is the type of node that a miner is running?

A - If a miner is being responsible they are running their own full node. It is probably just an archival selfish node in order to preserve bandwidth. But mining pools at the very least are serving blockchain data to the miners that are connected to those pools so that the miners know what they are mining on and stuff like that. Every miner is connected to a full node in one way or another because they need to use that full node to ensure that the block that they are building is valid and that they are building on top of the current, most difficult, valid version of the blockchain. There are maybe a few minor tweaks that they have made to their full nodes to make it optimal for mining purposes but other than that it is an off the shelf piece of software with maybe some small modifications. Then they are running mining software next to the full node which is separate. There are probably a dozen at least different kinds of mining software that miners could use including proprietary versions of software if they develop their own mining software. That mining software will talk to the full node but it will also talk to the miner’s mining hardware and take new transactions, hash them into a block, iterate on a nonce until it finds a header the matches the proof of work. Then it will broadcast that block back out to the network.

Q - What do you think the roadblocks are to more people running a full node? Do you think the excitement around Lightning will incentivize more people to run a Bitcoin full node?

A - Roadblocks, part of it is incentives. I think another part of it is ease of use. At Bitseed we are trying to tackle the ease of use part. Part of that means not just ease of use in terms of running the full node but also ease of use in terms of making that full node useful to the end user. We have a lot of people who buy Bitseeds and they are just happy to connect it to the network and to support the network. But I think a lot of people are hungry to use their full node for more direct personal use in terms of actually using their full node to verify their own transactions and maybe set up a Lightning node and provide liquidity to the Lightning Network. We are tackling both of those common requests in parallel. On the one hand as I mentioned we have a community member that is working on adding Electrum support to Bitseed. So you will be able to connect your Electrum desktop or mobile wallet to your Bitseed node. I think that is going to be a huge win because not only is Electrum a really great wallet by itself, Electrum also supports connecting to a hardware wallet. So once you have Electrum running on your own full node and your desktop or mobile wallet connected directly to your own personal Electrum server you can then use your hardware wallet with your own full node. Today the hardware wallet software does not make it easy, I don’t think it is even an option for you to connect to your own full node just using the default interface for these hardware wallets. But Electrum provides an interface that allows you to connect to your hardware wallet to Electrum. If you are connecting a hardware wallet to Electrum and then Electrum to your own full node, then you can use your hardware wallet with your own full node. Meaning that you are not sending your wallet balances to Trezor or Ledger servers. I think this is a huge win for privacy and security. We are really excited to get that out. We are going to be working with Marco who is the community member that is working on this feature to test this. We will probably have something usable by the end of summer. Then on the incentives and the Lightning side the next thing we are going to start working on after this Electrum feature gets pushed out is Lightning integration. This we will be moving slower on because I’m personally very skeptical of the idea of keeping private keys in a hot wallet online all the time. Especially if it is connecting to other nodes and sending money around unattended. But I understand that people are excited about this and if they are just putting a couple of hundred bucks on the node then there’s not a lot to lose. We are going to look at how we can make it super easy for people to set up their own Lightning node and not just use that node for sending and receiving money on the Lightning Network for their own purposes but also using that node to help route other people’s payments as well and provide liquidity to the network. Maybe earn some satoshis for providing that service as well. In that way people might actually have a direct financial incentive to run their own full node so that they can participate in providing liquidity to the Lightning Network and earning some routing fees in exchange.

Q - Can you talk about the challenges of building a hardware startup? And how Bitseed has evolved since you started it a couple of years ago?

A - I don’t know if I would characterize Bitseed as a startup really. I think of it as an open source project that happens to have a relatively easy monetization mechanism built in which is we sell hardware that’s used to power our software. At this stage of its development I would say it is and has been a side project in the sense that I don’t think that Bitseed revenue at this stage could be enough to sustain say salaries for people who are working on the project. But maybe that could change in the future if we make Bitseed useful for people and generally get more people excited about running their own nodes. But I think something would have to significantly change either in the market or in the software or some kind of combination of these things to make it into an actual business. Today Bitseed hardware sales, they sustain themselves. Meaning that we can continue to order new parts and ship new orders. Then we have enough left over to pay for hosting and some software development but not much more than that. In short I’m not sure that I know what the challenges are for running a hardware startup because I don’t consider Bitseed to be a hardware startup. If we start selling more nodes than we can build by hand which is what we are doing today, then we might start to actually experience some of those challenges like supply chain stuff, dealing with vendors and security and other challenges like that once you have to outsource a bunch of stuff. But we’re not quite there yet.

Q - A couple of process questions. How easy is it if me and a few friends buy Bitseeds for us to be able to discover each other’s nodes and interoperate between our nodes? And also how easy is it to connect remotely to a Bitseed that I leave at home?

A - What do you mean by interoperate?

Q - You discover nodes on the network and perhaps you want to connect to specific nodes on the network rather than just the default ones that you connect to using Bitcoin Core.

A - I see what you mean. What you’d have to do is get your and your friend’s IP addresses on port 8333. You would have to SSH into your nodes and modify your configuration file to connect to those IP addresses so that your node is connecting to those other nodes by default before trying to connect to any other peers. It is relatively easy to do but it does mean you have to go into the command line. Today we don’t support modifying the configuration file from the UI. You have to do that from the command line. That could change in the future but today that is what you would have to do. The default mode of operating Bitseed that we have in mind is that users never have to touch the command line interface. But if you do want to do something complicated like modifying your configuration file you are going to have to use the command line interface which isn’t as scary as it sounds but there is a little bit of a learning curve if you’ve never touched the Terminal before. The second question you asked was about remote nodes. Basically don’t do it. You either can’t do it or you shouldn’t do it. The reason is first off Bitseed does not let you SSH into the node unless you are on the local network. Second, we do have a public status page that you can visit just by going to the public IP address of the node on port 80. That is possible. By just visiting this status page, I showed you what the status page looks like. It shows you what block height you are at and how big the mempool is and things like that. You can monitor your Bitseed remotely and make sure its online and that it is keeping up with the current block height. But you can’t mess around with the settings for security purposes. You can only do that when you are inside the same network as your Bitseed. Then in terms of connecting your wallet to Bitseed, we won’t be able to support that until we support Electrum. Today if you want to do that just using Bitcoin Core it is just not secure. Bitcoin Core does not support HTTPS authenticated or encrypted connections. If you are going to connect for example your Android Bitcoin wallet to your own node the Android wallet has an option where you can connect to a trusted node by just putting in the public IP address of the node. But that connection between the wallet and the node is unauthenticated and unencrypted so it could be easily man in the middled. Of course all of the data that’s being passed between the wallet and the node can be sniffed on the wire by anyone that is watching the network. All of those requests are public and they can be man in the middled. Not good for privacy, not good for security. You really shouldn’t recommend that people do that. Once Bitseed supports Electrum Personal Server you will be able to connect to that server through an authenticated and encrypted connection either using SSL or end to end encryption through the Tor network.

Q - Would the Bitseed need a static IP address for that to work?

A - For the Electrum server to work? If you are using HTTPS yes. If you are using Tor, no. Because Tor does not use IP addresses to route messages.