Topic: Does Bitcoin become more decentralized over time? (Read 710 times)
I am also agree with that (becoming more decentralized). Bitmain, for instance, has seen increasing competition from Canaan Creative due to its “inability to produce a meaningfully superior alternative to the Antminer S9,” the firm said. The closer competition, it continued, has led “Canaan Creative to sell its chips to a broader audience of miners that can effectively compete with Bitmain.”
What about bandwidth? I believe Bitcoin’s bandwidth needs, as a decentralized network, is very underestimated. Rate of growth for bandwidth is slow, and network latency slower, which means that block propagation speeds might not scale at the same rate if average bandwidth among nodes increases.
If block size limit isn't changed, that means bandwidth/latency requirement won't changed much while bandwidth/latency is slowly growing, which means bandwidth/latency problem won't make Bitcoin less decentralized over time (excluding blockchain size and IBD time).
How would you plan to measure decentralization?
I don't. But when i show following hypothetical scenario
1. 6 years ago you moderate VPS or PC to run full node
2. Today you can run full node with Raspberry Pi 4
Some people would agree that cost of running full node (excluding storage size and IBD) is cheaper today and could improve decentralization.
Even if two participants of the Bitcoin protocol appear as different nodes, they might have an out-of-band connection and be ran by the same person.
I agree, but it's out of scope from my question.
What about bandwidth? I believe Bitcoin’s bandwidth needs, as a decentralized network, is very underestimated. Rate of growth for bandwidth is slow, and network latency slower, which means that block propagation speeds might not scale at the same rate if average bandwidth among nodes increases.
That's what i mean. Bitcoin Core used to have one, but AFAIK now it's disabled. The code isn't removed though and can be seen at https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp.
Electrum also have checkpoint, where it's checkpoint can be seen at https://github.com/spesmilo/electrum/blob/master/electrum/checkpoints.json.
Checkpoints exist in both client types (Full and SPV) but for different purposes.Electrum also have checkpoint, where it's checkpoint can be seen at https://github.com/spesmilo/electrum/blob/master/electrum/checkpoints.json.
A full node (ie. bitcoin core) uses checkpoints only for its header sync and it only is enforced for the initial sync to prevent a certain attack. AFAIK this is because ever since full nodes changed to header first sync, they don't download blocks as they go. Instead they first download all block headers and when they do that a malicious node could give them fake headers with low difficulties in early heights. By using checkpoints the node doesn't waste time. Then they start downloading the blocks for those headers. ContextualCheckBlockHeader() is still rejecting any block (header) that is not found among the checkpints (it doesn't seem disabled).
An SPV client (ie. Electrum) has to use checkpoints because from the point of view of the light client all headers of all chains are valid headers (unless they change the difficulty calculation method). For example your client could connect to a shitcoin's ElectrumX node and receive headers from that chain and essentially get stuck on an invalid chain. By using checkpoints the client makes sure that it is always on bitcoin chain not some altcoin's.
What would the hard-coded checkpoint change if every node I connected is malicious?
I think he means when the node is programmed to accept a particular chain up to a certain block, then it's not going to consult any of its peers for blocks up to that point, only beyond that particular block. I don't know if that's what's done in Core (besides the Genesis block of course). That's what i mean. Bitcoin Core used to have one, but AFAIK now it's disabled. The code isn't removed though and can be seen at https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp.
Electrum also have checkpoint, where it's checkpoint can be seen at https://github.com/spesmilo/electrum/blob/master/electrum/checkpoints.json.
(well, as long as you don't choose an RIAA or ISP honeypot disguised as a node).
ISP honeypot? Do you mean a police sting operation?That too but I was referring to ISPs who run their own torrent clients to copyrighted data and scrape IP addresses of their peers, search for the IPs that belong to them and serve those customers cease and desist letters which threaten to terminate their internet access if they don't stop torrenting.
Back on-topic...
You forget about valid alternative chain (usually with far lower mining difficulty), such attack is still possible if ever single node you chose are malicious node and the client doesn't implement hard-coded checkpoint.
What would the hard-coded checkpoint change if every node I connected is malicious?
I think he means when the node is programmed to accept a particular chain up to a certain block, then it's not going to consult any of its peers for blocks up to that point, only beyond that particular block. I don't know if that's what's done in Core (besides the Genesis block of course).
You forget about valid alternative chain (usually with far lower mining difficulty), such attack is still possible if ever single node you chose are malicious node and the client doesn't implement hard-coded checkpoint.
What would the hard-coded checkpoint change if every node I connected is malicious?
In the bitcoin network the problem with doing this is that we don't know which nodes are trustworthy and which are malicious nodes that have a different chain for example.
This is a problem only if you are not running your own node. Right? This is a problem only if you use an SPV like electrum that would show false information. Your node will reject everything that is invalid.(well, as long as you don't choose an RIAA or ISP honeypot disguised as a node).
ISP honeypot? Do you mean a police sting operation? In a P2P network we have to rely on a centralized server to start the connection. Unfortunately there is no other way. For example in Torrent network we use hard coded DHT servers or the trackers to find peers.
But why? Can't there be some hundreds of default nodes that will inform the new nodes for other nodes? Why do you need a centralized server to start the connection?In torrent lore that's actually how things work if there are no central trackers. There are a list of (ordinary) peers hardcoded in a particular software[1] chosen by the developer that a client tries to connect to in order to download a particular torrent.
In the bitcoin network the problem with doing this is that we don't know which nodes are trustworthy and which are malicious nodes that have a different chain for example. Also a difference between bitcoin and BitTorrent is that in bitcoin the trustworthiness of the initial nodes used for bootstrapping is extremely important since money is involved and where it appears to be distributed is totally reliant on what peers tell you, whereas BitTorrent is just about downloading stuff so it doesn't really matter who you choose as the initial peers (well, as long as you don't choose an RIAA or ISP honeypot disguised as a node).
[1]: https://stackoverflow.com/questions/3844502/how-do-bittorrent-magnet-links-work
In a P2P network we have to rely on a centralized server to start the connection. Unfortunately there is no other way. For example in Torrent network we use hard coded DHT servers or the trackers to find peers.
But why? Can't there be some hundreds of default nodes that will inform the new nodes for other nodes? Why do you need a centralized server to start the connection? Even if I remove those vSeeds and then build Bitcoin Core, sooner or later I'll be listed on their address list.
Only if your node is listening for incoming connections and has port 8333 (or 18333 on testnet) open and is a reliable node.Quote
I always thought that vSeeds are the "default" nodes of the network that were chosen by the Bitcoin Core developers.
In a P2P network we have to rely on a centralized server to start the connection. Unfortunately there is no other way. For example in Torrent network we use hard coded DHT servers or the trackers to find peers. If you want the details of how such software works you'll have to look at their code or ask those who wrote and are running such things. But I suppose it is a combination of having a well connected node with a good latency and a large socket backlog to accept any incoming connection while also connecting to other nodes and getting their addr list to check and advertise its own IP.
So they find nodes' IPs whether you have Bitcoin Core or not. Even if I remove those vSeeds and then build Bitcoin Core, sooner or later I'll be listed on their address list. Interesting, I wonder how their code works. So these IP addresses on vSeeds send and receive new IPs continually, but not blocks. I always thought that vSeeds are the "default" nodes of the network that were chosen by the Bitcoin Core developers. Since a full node connects with few nodes, I want to know how it is calculated that there were ~200k nodes running Bitcoin Core.
That's the default behavior since there is no point in connecting to all nodes but we have customized code that connects to other nodes and gathers information. Like the node crawlers that infest the bitcoin network!If you want the details of how such software works you'll have to look at their code or ask those who wrote and are running such things. But I suppose it is a combination of having a well connected node with a good latency and a large socket backlog to accept any incoming connection while also connecting to other nodes and getting their addr list to check and advertise its own IP.
Quote
Since there isn't a database that keeps every IP, the network is decentralized. The *only* thing I see as "database" is the connection count of vSeeds on chainparams.cpp:
If these vSeeds were added before v0.15.0, then they exist on almost every node of the network. Technically, they could count every different IP that connects with them with Bitcoin Core.
These servers only store the IP addresses of the most reliable nodes that are accepting incoming connections not all IPs. Even if they stored the IP addresses of those connecting to them it won't be reliable because just because someone is digging them doesn't mean they are running a bitcoin node such as bitcoin core. You can for example dig them like this: https://toolbox.googleapps.com/apps/dig/ If these vSeeds were added before v0.15.0, then they exist on almost every node of the network. Technically, they could count every different IP that connects with them with Bitcoin Core.
Actually the number of bitcoin full nodes is more volatile than the price itself! It goes up and down with wild swings.
Since a full node connects with few nodes, I want to know how it is calculated that there were ~200k nodes running Bitcoin Core. Since there isn't a database that keeps every IP, the network is decentralized. The *only* thing I see as "database" is the connection count of vSeeds on chainparams.cpp:Code:
vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
vSeeds.emplace_back("dnsseed.bluematt.me"); // Matt Corallo, only supports x9
vSeeds.emplace_back("dnsseed.bitcoin.dashjr.org"); // Luke Dashjr
vSeeds.emplace_back("seed.bitcoinstats.com"); // Christian Decker, supports x1 - xf
vSeeds.emplace_back("seed.bitcoin.jonasschnelli.ch"); // Jonas Schnelli, only supports x1, x5, x9, and xd
vSeeds.emplace_back("seed.btc.petertodd.org"); // Peter Todd, only supports x1, x5, x9, and xd
vSeeds.emplace_back("seed.bitcoin.sprovoost.nl"); // Sjors Provoost
vSeeds.emplace_back("dnsseed.emzy.de"); // Stephan Oeste
vSeeds.emplace_back("seed.bitcoin.wiz.biz"); // Jason MauriceIf these vSeeds were added before v0.15.0, then they exist on almost every node of the network. Technically, they could count every different IP that connects with them with Bitcoin Core.
Some people says raising Bitcoin block size hurt decentralization because it increases cost to run a full node. Bitcoin block size limit remains at 1MB 4 million weight units in past few years, while hardware and internet continue growing. The growth could be higher speed, higher efficiency or lower cost. With that in mind and ignoring other factor (such as blockchain size growth, hashrate distribution and total of full nodes), does Bitcoin become more decentralized over time?
P.S. This is just my shower thought, so obviously it has flaws.
P.S. This is just my shower thought, so obviously it has flaws.
How would you plan to measure decentralization? Even if two participants of the Bitcoin protocol appear as different nodes, they might have an out-of-band connection and be ran by the same person.
I am in a fairly urban area in one of the fastest developing countries of the world where we have good enough internet data capacity and speed to watch a few episodes on Netflix every second day. Yet, it is nowhere near the almost 200 GB plus upload/ download that a Bitcoin full node needs right now.
Any talk of increasing blocksize should first consider the actual internet availability. Only the most affluent of cities have those kind of limits.
Even if better internet reaches everywhere, you still won't solve the issue of Bitcoin being resource intensive. Already, we have calculations about how Bitcoin electricity consumption is equivalent to some Scandinavian country's consumption. Next it'll be about data and how much of it is being consumed by Blockchain ledgers, especially Bitcoin.
From Bitcoin’s viewpoint, does it need to be “solved”? I believe the people who say that it’s “a problem”, don’t truly understand Bitcoin. Or try not to understand that there’s more to Bitcoin, and more to its implications on Banking and Finance’s current condition, than what we see. Maybe energy companies could become the new foundation from which sound, hard money is produced and issued.
I am in a fairly urban area in one of the fastest developing countries of the world where we have good enough internet data capacity and speed to watch a few episodes on Netflix every second day. Yet, it is nowhere near the almost 200 GB plus upload/ download that a Bitcoin full node needs right now.
Any talk of increasing blocksize should first consider the actual internet availability. Only the most affluent of cities have those kind of limits.
Even if better internet reaches everywhere, you still won't solve the issue of Bitcoin being resource intensive. Already, we have calculations about how Bitcoin electricity consumption is equivalent to some Scandinavian country's consumption. Next it'll be about data and how much of it is being consumed by Blockchain ledgers, especially Bitcoin.
Any talk of increasing blocksize should first consider the actual internet availability. Only the most affluent of cities have those kind of limits.
Even if better internet reaches everywhere, you still won't solve the issue of Bitcoin being resource intensive. Already, we have calculations about how Bitcoin electricity consumption is equivalent to some Scandinavian country's consumption. Next it'll be about data and how much of it is being consumed by Blockchain ledgers, especially Bitcoin.
Bitcoin block size limit remains at 1MB 4 million weight units in past few years, while hardware and internet continue growing.
As you might have noticed already, (residential) internet speed does not grow. It is forever fixated at some arbitrary value like 5mbps or 20mbps depending on how benevolent your provider is (*cough* Comcast *cough*).
...
Which is why I mentioned starlink and Project Kuiper earlier.
Yes you have more latency then cable / fios but it's still going to be competition an that is going to force the local providers to step up their game or wonder where all they customers went.
Not to mention the ones they loose to residential 5g.
The days of the crap cable providers although not ending soon, are not going to be forever.
-Dave
Bitcoin block size limit remains at 1MB 4 million weight units in past few years, while hardware and internet continue growing.
As you might have noticed already, (residential) internet speed does not grow. It is forever fixated at some arbitrary value like 5mbps or 20mbps depending on how benevolent your provider is (*cough* Comcast *cough*).
This presents a special problem where as the blockchain grows, nodes running from home starve out and everybody starts moving to cloud servers for hosting nodes. We've probably already optimized the peer discovery so much that it's easy to find multiple nodes to continue downloading blocks from, and I don't think further speed up of the initial sync is possible, especially on artificially crippled residential lines, even if the current ZMQ message channels (at least for block and tx messages) give you Bittorrent magnet links instead.
Some people would like to run Core but they have a crappy 500kbps D-Link instead of a proper router and using one is probably out of the question, so there should be some kind of "lite" sync where each of these nodes verifies only a fraction of those blocks (we're talking around 1% here) and they somehow signal the integrity of all the other blocks. Millions of these "lite" nodes each verifying different blocks should provide the same security strength while being fast to sync.
Now we can't exactly predict size of Bitcoin blockchain but looking at this Statista chart, I think we are not going to reach even 400GB or 500GB in next few years, and data from Ycharts is showing 142.6% Average Growth Rate.
And since we've had an exponential growth in computer storage capacity so far, and there's no reason to expect something dramatic to change in the foreseeable future, I don't believe we're ever going to get into trouble storing blockchain data.
Jump to: