Blockstack community thoughts on block size / Bitcoin XT debate

[jude]

Hi Larry,

Would another analogy be to say increasing the block size is like trying to scale a small computer network where each host is increasing its data usage and the number of hosts are increasing by swapping out a 100 megabit hub with 8 ports for a 1 gigabit hub with 24 ports? (recall a hub unlike a switch relays the same data to each port - much like the whole network mines the same blocks)

Yeah, a hub would be a closer analogy. But in both cases, each host’s ARP table needs to grow to accommodate each other host (growing linearly with the number of hosts), and the network capacity needs to grow to accommodate O(n^2) traffic for n hosts in the form of ARP requests/replies. There’s a reason the Internet does not try to behave like a big virtual hub or a big virtual switch

But, the point I was trying to make is that the XT proposal does not try to address this limitation at all. The factor that limits a node’s ability to mine blocks is network bandwidth, because to mine block B, the node will not only need to have fetched all B-1 blocks, but also will need to be able to gather enough candidate transactions for B before it has a chance of solving B’s crypto-puzzle. The transaction volume when B is being mined puts a lower bound on the amount of bandwidth the node must dedicate towards the Bitcoin network at that time–if a node can’t meet this lower bound, it can’t mine B. Making B bigger only increases the upper bound on the transaction volume when B is mined. It does nothing to make the lower bound lower, but can have the unintended side-effect of allowing the transaction volume for B to grow beyond the ability of existing nodes’ network links to handle.

History has shown that increasing the capacity of a system by a linear factor (e.g. bigger block size, more network bandwidth) rarely has the long-term effect of making the system faster. This is how Wirth’s Law came to be . I have a sinking feeling that even if everyone switched to bigger blocksizes and upgraded their bandwidth to accommodate them, we would be back to square one in no time, since we’d just find some other use for any resulting extra capacity.

[jude]

Assuming blocks reach the current 1mb limit, does block size affect cost of registering and/or updating a name?

Yes–the cost of registering and updating would be pegged to the cost of a transaction on whatever blockchain the system uses. I was pointing out that the correctness of the naming and storage protocols are unaffected (provided we get 40 bytes per transaction to play with).

[ryan]

As for questions of if BIP101 / Bitcoin XT solve any scaling issues within Bitcoin - they do not. But neither will any of the actual scaling proposals work effectively without larger blocks. I outlined why this is the case in this post.

Agreed. Just read the post you linked to - https://medium.com/@lopp/de-centralized-block-chain-scaling-268dc5c3a7d0 - and it makes a lot of sense.

[lopp]

Not really true for network bandwidth and for memory. Largely true for computing and storage. Larger blocksize is more dependent on network/memory than disk/computing.

Agreed; bandwidth I believe is more like 17% per year. I think the important thing to note is that you can’t predict the future with an algorithm, however by having a hard cap that is slightly higher than optimal is better than a hard cap that is far lower than can meet market demand. Because a hard cap can be easily decreased with a soft fork or simply by miners voluntarily lowering their configurable soft cap.

[light]

What a block size increase means for Bitcoin:

• potentially lower fees for individual transactions in the short term (but no guarantee of this)
• potentially more transactions per block (also no guarantee; miners can always impose a soft limit)
• potentially greater centralization of mining around better-connected, more competitive miners
• potentially more difficulty running a full node due to increased resource requirements

I, for one, look forward to seeing more transactions fit into each block. This will be great for everyone using bitcoin, regardless of use-case, including those registering blockchain IDs. I therefore support a reasonable block size increase i.e. one that does not dramatically hurt node + miner decentralization. I personally prefer Pieter Wuille’s proposal, but would also support Jeff Garzik’s BIP 102 proposal (though Jeff’s is only a one-time increase, and I think the block size should continually increase with global network bandwidth capacity). Bitcoin XT, I’m not so sold on, but I welcome the debate that their proposal has brought to the fore.

[greg]

[quote=“lopp, post:8, topic:152”]“It would lead to a centralization of the network due to its exponentially increasing block size limit.”

Speculation.[/quote]

That is a fact, not speculation. To deny that is to be disingenuous, and it may be one of the reasons why posts in support of XT are being censored from /r/Bitcoin (not that I think they’re right in censoring them, but I understand why they feel like they have to when you repeatedly make bs statements like this).

The only way it is speculation is if you are assuming we are entering a world where everyone has precisely equal bandwidth.

Also, the limit doubles every two years which is consistent with trends in technological progress.

Again, misleading. Doubling every two years is consistent only up to a point, and then it stops.

There is no wrong or right way

Yes there is. This is computer science. There are right and wrong answers.

Fallacious arguments from authority.

There’s nothing fallacious about their reasoning, and if you know anything about their background you’d know that they’ve not only demonstrated a superior understanding of the subject, but that we wouldn’t be having this conversation if it weren’t for them.

The issue has become more ideological than technical at this point -
coming to a full consensus on any ideological issue within a diverse
group is practically impossible.

That is a completely separate issue from the fact that Bitcoin XT is harmful garbage.

Takeaway

1. No one is against increasing the block size. So stop implying they are.
2. People are against XT and other non-answers to the scaling question. [1] [2]

[lopp]

The only way it is speculation is if you are assuming we are entering a world where everyone has precisely equal bandwidth.

You seem to be assuming that only current node operators continue to operate nodes while those with the least bandwidth drop out. Whereas it seems to me that by supporting more users on-blockchain we’ll have more enterprises and enthusiasts who will join the system and run nodes.

Yes there is. This is computer science. There are right and wrong answers.

Unfortunately it’s not pure computer science. This particular issue is highly ideological. Even recent posts on the development mailing list agree on that. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010463.html

[greg]

You seem to be assuming that only current node operators continue to operate nodes while those with the least bandwidth drop out. Whereas it seems to me that by supporting more users on-blockchain we’ll have more enterprises and enthusiasts who will join the system and run nodes.

That’s a mixture of truth and misleading statements. It is precisely that kind of dialogue that trips so many people up and gets them in trouble.

The only way to deal with it is to take it apart piece by piece:

• “You seem to be assuming that only current node operators continue to operate nodes”

No.

• “while those with the least bandwidth drop out.”

Yes.

• “we’ll have more enterprises”

The percentage of enterprises will likely increase relative to enthusiasts, because only large for-profit enterprises will be able to handle the bandwidth.

That does not mean we will have more enterprises.

• “and enthusiasts who will join the system and run nodes.”

No. Enthusiasts will not be able to handle the bandwidth. Period.

Unfortunately it’s not pure computer science. This particular issue is highly ideological. Even recent posts on the development mailing list agree on that. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010463.html

Yes, this is ideological in the sense of whether you are for or against decentralization.

Once you choose between PayPal and Bitcoin the politics stop and the computer science is all that remains relevant.

[greg]

Those claims are false and have already been disproven.

Looks like I missed that comment. Citation required. I provided mine.

[lopp]

No. Enthusiasts will not be able to handle the bandwidth. Period.

My well connected nodes with over 100 peers use < 10 KB/S downstream and < 150 KB/S upstream on average: https://statoshi.info/dashboard/db/bandwidth-usage

I could easily handle an order of magnitude increase in bandwidth requirements without breaking a sweat on my current residential connection. And next month my residential connection will increase its speeds by an order of magnitude while costing me an extra $10 per month. So I don’t think that the extreme claim that all enthusiasts will be priced out of running nodes holds true.

I’ve posed the question on the dev list in the past: “what is the consensus for an appropriate minimum specification for running a node?” But this doesn’t seem to be a topic that many people are interested in exploring, yet it is often used as an argument for keeping the block size limit at 1 MB.

Yes, this is ideological in the sense of whether you are for or against decentralization.

Small block proponents may think that larger blocks will centralize the network by pricing out individuals from running nodes. Large block proponents may think that larger blocks will decentralize the ecosystem by increasing the number of participants and thus the number of nodes. I think that if demand continues to increase while block sizes remain static, it will centralize the system by forcing more users to transact off-chain through trusted parties. But all of those positions are speculative.

Looks like I missed that comment. Citation required. I provided mine.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010384.html

The claims are invalid; the code doesn’t run in that state.

[drwasho]

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

[greg]

My well connected nodes with over 100 peers use < 10 KB/S downstream and < 150 KB/S upstream on average: https://statoshi.info/dashboard/db/bandwidth-usage

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.

Small block proponents may think that larger blocks will centralize the network by pricing out individuals from running 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.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010384.html

The claims are invalid; the code doesn’t run in that state.

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.

[greg]

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

[greg]

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).

[greg]

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?

[jude]

People have done simulations of this but it’s hard to see what will really happen until it’s tested in the wild.

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

I think it’s natural to conclude that the number of full nodes will decrease, but we might just have to live with that. For scaling, the alternatives to increasing the block size are to hook the blockchain up to off-chain systems (like the lightning network or sidechains), which would arguably lead to more centralization, as fewer people would be directly on the bitcoin blockchain, fees would be really high due to high demand for block space, and only the transaction aggregators could afford such an expensive, low bandwidth system, which makes it a clearing system only.

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.

But we should at least do our best to keep the price of transactions down by increasing the supply of blockchain space.

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.

[greg]

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):

Adam Back Says the Bitcoin Fork Is a Coup

[lopp]

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

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.

this is an excellent article/interview on the reality of Bitcoin XT

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.

[greg]

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.

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.

[digitsu]

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.)