Blockstack community thoughts on block size / Bitcoin XT debate

I was going to contribute to this debate… but I think I’ll post this instread.

2 Likes

Your well connected nodes work thanks to the hard work of the Bitcoin developers and pioneers.

Thank them for that instead of showing them the finger.

Let’s say that we wanted Bitcoin to match VISA using the block size.

Let’s scale up to half of Visa’s capacity of around 22,000 transactions per second:

10,000 Bitcoin transactions per second requires 1.6 GB blocks and would result in a block chain that grows by 87 TB (Terabytes) per year, consuming storage of 1.5 TB per week.

(The above example does not take into consideration the impossibility of this theoretical scenario due to lag introduced by transaction and block validation - pushing 1.6GB blocks around the network for consensus seeking).

Source: https://www.cryptocoinsnews.com/block-size-bitcoin-not-scale-effectively/ (and similar figures from other places)

Supposing the comment about this scenario being “impossible” (due to block propagation) is incorrect, will you be able to handle >3MB/sec 24/7 (and the hard disk space)? That’s not accounting for the bandwidth required for relaying transactions or upload, or the time to verify all transactions. (I think the math is right: 1600/10 => 160MB/min => 2.7MB/sec, plus overhead. By the time you finish downloading one block, you have to immediately start downloading another. Faster bandwidth needed to account for variation in block time, txns, upload, overhead, etc.)

If so, you are one of the lucky few enthusiasts left with a mini data center at home. Certainly no Bitseed boxes. And you’re pretty much donating a good chunk of money to supporting the network.

Lightning Network can easily handle that sort of TPS rate without needing to reduce the number of full nodes.

Why do you keep framing it this way? Again: nobody is advocating 1MB blocks. People want to optimize the network’s utility without compromising its decentralization.

There are various suggestions for how to do the “right block size”, and how to increase the txn rate without touching the block size.

The claim I made is still valid.

I said: It is actively hostile toward Tor users. Both of those links support that claim.

Bitcoin does not have a Tor blacklist. Bitcoin does not treat Tor users like second class citizens. Bitcoin XT does.

Sorry, made various edits to my previous reply. I have to run now, out of time for this.

Done with a call. Here’s another simple “proof” that the block size cannot be used to scale to VISA level while keeping the network decentralized:

  1. Take the number of existing nodes in the network. 6500 at the moment.
  2. Figure out what the Big-O is for data dissemination (it’s O(n) per node and O(n^2) from entire network’s perspective).
  3. Sit back and imagine (or calculate) what would happen when each of those nodes needs to all of a sudden throw around 1.6GB blocks around the world’s Internet tubes, and somehow distribute and verify all of them in well under 10 minutes.

The more I think about the actual numbers involved the more the mind boggles at the unreality of it all.

Sustaining 6500 nodes would literally require several miracles to happen:

  • Miners and mining pools would have to figure out how to mine on 1.6GB blocks (and be convinced it makes sense).
  • The world’s ISPs would have to not only be OK with their networks being abused like this, they would have to completely redesign their networks to support “hobbyists” who need them to pass around several thousand 1.6GB kidney stones every 10 min (that get exponentially larger over time, and in addition to all of the actual transaction traffic). And they thought Bittorrent was bad.
  • Mini data centers would have to drop in price to $200 a pop and be “simple to use”.
  • Fiber optic connections everywhere for $50/month!
  • At some, point faster-than-light communication to keep up with that exponential function.

And I’m probably missing a bunch of other considerations (disk space, CPU, super-human productivity leaps, etc.).

There is just no way 6500 nodes can support VISA-level txn rates using “large blocks”.

P2P networks don’t work like this.

The only way to scale Bitcoin to VISA levels safely while keeping it decentralized is to work around the block size (like Lightning Network does).

So you say, “OK, I guess these 6500 nodes would not be ‘enthusiasts’, but maybe they’d be businesses/organizations of some sort?”

Alright, fine, what does that mean? What are these businesses? What do they actually do and why on earth are they going to pay all this extra money to run and maintain a mini data center forever?

I guess we just need to have faith that the miracle will occur and these 6500 businesses will figure out a way to replace the 6500 existing nodes, that an equal number of Bitcoin miners will figure out a way to replace the ones who won’t be able to cope with 1.6GB blocks, and that the world’s ISPs will be both willing and capable of handling it all.

Bitcoin XT’s vision for a decentralized future is cheap, it only costs about 20 miracles, so why doesn’t everyone just get with the program?

Good to know about the simulations! Do you know where I can find them?

An important consequence of lightening networks, side chains, etc. is that miners who don’t care about other miners’ transactions don’t have to package them into blocks (kind of like how routers that don’t care about other networks’ hosts don’t have to know about their hosts’ IP addresses). Fundamentally, this is what has to happen for Bitcoin to scale–a full node’s minimum required bandwidth must grow sub-linearly with the number of in-flight transactions. The million dollar question is, how do we do this without removing the desirable properties of the system?

One thing I’m looking forward to learning by watching Blockstack-powered applications evolve is how their security, cost, and latency needs will vary for each of their transactions. I would not be surprised to find a high amount of variance in these parameters. If this proves true, then I suspect that the solution to Bitcoin’s scalability will come from exploiting their differences to limit the number of nodes that need to process a given transaction.

For example, perhaps a Bitcoin 2.0 node would maintain blockchain for each difficulty level the protocol supports, such that blockchains with easier proofs of work are mined by a smaller disjoint subsets of nodes (where blockchain membership is deterministic). There would be k different blockchains of the kth hardest difficulty level, with no overlap between their transactions, and they would mine in “resonance” with the (k-1)th blockchains of the (k-1)th difficulty level (i.e. each kth-hardest blockchain mines N blocks for every M blocks the (k-1)th blockchain mines). Applications would select the security/latency/cost trade-off for a transaction, send it to the appropriate blockchain, and thus limit the transaction’s visibility to a deterministic subset of the network. I don’t know if this is the right solution, but it illustrates a potential Bitcoin variant that does scale, since each full node only needs to be aware of O(log n) transactions in the average case, and applications get the security/latency/cost trade-off they actually need.

Agreed, but again, I think Wirth’s Law applies. Bitcoin still has a lot of growth potential, and I think we can expect that any increase in supply will be quickly consumed. This is in part why I’m less than enthusiastic about any solution that does not address Bitcoin’s fundamental scalability limitation–even if we could make block sizes unlimited and give every miner who wanted it a 10Gbps symmetric link, the world would still find a way to use all of its capacity.

Although more verbose, this is an excellent article/interview on the reality of Bitcoin XT (which is not to be confused with a desire for larger block sizes):

http://spectrum.ieee.org/tech-talk/computing/networks/the-bitcoin-for-is-a-coup

Neither does XT unless the node is under attack. And users who want to run XT but disagree with the resource prioritization logic can disable it with the “disableippro” switch.

You made a lot of statements with which I agree regarding system scalability, so I assume you didn’t read the original post that I linked in my first comment: https://medium.com/@lopp/de-centralized-block-chain-scaling-268dc5c3a7d0

Yes, Lightning Network will be essential. Yes, larger blocks will be essential to support it. Bitcoin Core devs should continue working on actual scalability solutions, because larger block sizes are not a scalability solution.

It’s not possible to have a coup unless there is a group that has a monopoly on governance of something. Let me be completely clear on this: Bitcoin Core developers do not have a monopoly on the Bitcoin protocol. They, like any other implementation developer, can only suggest changes to the rest of the ecosystem and try to convince the ecosystem to adopt them.

Gavin and Mike are using the same mechanism that Bitcoin Core developers use, they’re just doing it in a different implementation. Sorry if that offends anyone, but it’s a free market.

1 Like

If they had forked Bitcoin like everyone else it wouldn’t be a problem.

Instead, they chose to attack Bitcoin (both the network, the currency, and the users).

They deceive the community by pretending this is about block size (when everyone on core supports safe block size increases), make bullshit assertions about there being an impending crisis (when there isn’t), release a fundamentally broken piece of software, implement a blacklisting mechanism, and suggest we throw Bitcoin into chaos all so that we can make Mike Hearn “Bitcoin Dictator”.

So yes, this is a free market, and Bitcoin is allowed to defend itself from this attack.

That’s where bitcoin is going to, (in response to the Washington potato) if we don’t sort out this identity crisis, (this coup to turn Bitcoin into HearnCoin.)

2 Likes