Topic: #Blocksize Survey - page 15. (Read 16152 times)

What is sidechannels btw? Did he mean sidechains?

In fact, even the LN paper states that it needs bigger blocks to operate smoothly.

The OP is arguing that LN itself is centralized, so it's dishonest for Blockstream devs to argue against Bitcoin centralization. One question: what's better - to have a centralized system build on top of a decentralized one or a centralized system built on top of a centralized one? Also, these two kinds of centralization are probably very different, e.g. how costly is it to set up and operate a payment hub as compared to setting up and operating a mining farm of comparable characteristics (can we even compare them)?

Moreover, the OP downplays that Blockstream was created to develop sidechains (a completely different matter which he doesn't discuss at all) in the first place, and they became involved in the LN only very recently. Then he assumes they have a plan to monetize on the LN, but doesn't discuss what was their plan before the advent of the LN (did they plan to monetize of sidechains? How?). He's assuming that Blockstream investors want direct monetization, but that's not neccessarily true, e.g. investors can monetize by using their innovation in business.

This post might seem good at first glance, but if we dig deeper, it's full of baseless assumptions.

Voted for a less popular option since it's more complex but Adam Backs idea of sidechains as an extension of the Bitcoin infrastructure seems like the best long term solution to the problem as it addresses size issues and bandwidth capacity until the technology picks up, combined with a Pieter Wullies idea in the short term for incremental blocksize increases programmed into Bitcoin to ensure that Blocksize is Dynamic and adjusts relative to the capacity the network needs at any time, whether incremental increases can be set up this way would require a D@T discussion.
Else go back to Blockchain compression.

That said I can see Gavins idea of increasing the size to 8MB then implementing sidechains steadily over time to further enhance Bitcoin's capability and options as a viable idea as well but not an 8GB blockchain in the near future.

Interesting summary of the often mentioned accusation against devs that oppose any block size increase:

The Blockstream Business Plan
https://www.reddit.com/r/Bitcoin/comments/3gmkak/the_blockstream_business_plan/

There are two points:
1) Yes, we are assuming no one does 51% attack, but this assumption is based on economics and game theory (e.g. that BTC becomes worthless and hurts miners so it's not rational). Though it doesn't mean there can't be a hostile actor who's dedicated to bring Bitcoin down, and it's an inherent flaw.
2) But this doesn't mean we should do this kind of assumptions about not-yet-implemented features. Those should be as safe as possible (my opinion). In fact, if we don't do it carefully, we worsen 1) by adding incentives for centralization.

This is true, just had a quick look at the last 50 blocks in regards to sizes and found the following:

I agree, we should not fall into this fallacy. If there's anything that Satoshi's example has taught us is that we should judge ideas based on their merits and not on who their proponents are.


Irony intended!  

That's not exactly what I meant. We should assume that, if there's an exploitable part of system, it will likely be used by someone. It doesn't mean it will necessarily be exploited but no way we should push controversial changes and then pray to God and hope nothing bad happens. It's better avoided.

Well I was never saying that bandwidth is no a issue for Chinese miners. I was saying that storage is (almost) no longer a issue, and thus the people that are against the increase have lost a major point. While there won't be almost any decentralization due to storage, with bandwidth it is different.
This is why something like a compromise needs to be used so that we can agree on a increase right now. 2 MB blocks should not cause the problems that you've described.

Additionally I do not understand why we should assume that blocks will be instantly filled. AFAIK 1 MB blocks have been around for a while, and it took a plethora of months before they started becoming full.

---

---

Update:
Ah now I understand. You're trying to see that we should not assume that someone will not exploit this. Aren't we doing the same with 51% attacks (not yet solved)? We just assume that someone won't do a bad thing because of X.

This is called appeal to authority. Gavin has been arguing for the increase, but it's far from being proven safe.

P.S. I'd have more confidence in Gavin if he and Mike didn't plan this XT thing in the first place. They might have had good intentions but by going this way they lost credibility in the eyes of many people here.

It won't as Chinese miners hold majority of the network hashrate, and it's located in China, i.e. they will mathematically win more orphan races than the rest of world. This network fragmentation is one of things that the core devs are concerned of and it has been mentioned on the mailing list several times. Though I should note that the underlying problem is more complicated than what I described here.

If there's any chance the large blocks can be used to attack the network, then we should assume they will be.

The more I research this, the more it worries me. I have voted for a Gavin's proposal since I believe that in order for Bitcoin to achieve a mass adoption we need much bigger blocks in order to process more transactions.

I don't understand this low confidence in Gavin by many, he has been in Bitcoin since the earliest days and if he has proven there is no harm on network if the block size increase than that should be it. More and more it seems to me that Bitcoin is slowly held hostage by the Chinese miners and couple of big stakeholders that are against the change.

Have you considered that maybe the exact opposite will be true? Maybe larger blocks will actually work to the detriment of high latency regions like China, especially if mining pools have members from all over the world.


Regardless of whether Chinese miners are helped or hindered by larger blocks, it is the good of the network that we should be concerned with.

My point before about the miner propagation trade-off was precisely this: If a miner sees that a 500k block has a 30% lower orphan rate than a 1MB block, but the 1MB block has only 10% more in BTC value for the miner (reward +fees), he will try to validate smaller blocks. Even if the limit is 1MB.

That is what is happening now:
https://blockchain.info/charts/avg-block-size


So it is reasonable to assume that 8MB blocks will not start appearing until:
-bandwidth improves so that propagation speed is not significantly affected
-Fees become a larger part of the miner reward

Ok, let's talk about bandwidth and centralization. The current situation is that chinese pools combined have close to 60% of network hashrate (already pretty bad, isn't it?). The notable thing about China is that it has relatively poor network connections to the outside world while the intra-China network is better. It basically means that chinese pools propagate blocks faster between themselves than to the rest of world. It probably doesn't matter now but the larger blocks get, the higher will be the disbalance. For the rest of world miners it will mean increasingly higher orphan rates, which will encourage miners to mine on chinese pools, thus worsening centralization.

What I described is an abstract situation which not necessarily exists, but it gives you some food for thought. My position is that it's extremely important to avoid creating incentives for further centralization.

If we have an 8Mb limit, then no way we should assume that "it will be a while before we hit 8mb block sizes filled". If there are any incentives linked to larger blocks, we must assume that they will be used. If 8Mb blocks increase orphan rates for non-Chinese miners, then we should assume that Chinese miners will use this to their profit.

I've been saying this in a numerous amount of threads throughout many months.
8 MB blocks will have almost no impact on decentralization (at least not a noticeable impact). Basically with pruning (which is partially implemented now, and will be fully implemented later) storage is not a concern anymore and it is all up to bandwidth.
Even if we do have full blocks, that's 8MB x 6 x 24 = 1152 MB per day or 34.56GB per month.

I think any solution besides option one is no solution at all. We need a change now and if it is only to stop this spamming. The spam attacks already made enough damage to bitcoin since it's hard to explain to newbies why their transactions doesn't get confirmed.

Id like to point out that just because a blocksize limit increases doesn't mean the block sizes themselves it will be filled.  It will be a while before we hit 8mb block sizes filled on a regular basis and when we do reach it it will mean bitcoin is going mainstream and btc is likely much higher in price.  At that point the miners will be more concerned with the boatload of money they are making and less about hd space and bandwidth costs.   I got my first computer 22 years ago, it ran windows 3.1 and had a 170mb hard drive. The hard drive alone cost several hundred dollars. Today, I can buy flash cards the size of an eraser head that have 100 times the storage for 5 bucks. 22 years from now 1GB blocks will comfortably fit any retail hard drive with enough space for decades.

I wish there was a 'Like' button under posts so that I wouldn't need to create useless posts just to say that I agree with you.

Also, remember that maxblocksize is not the only thing keeping blocks small. Propagating blocks is harder the larger they are.. and in the ultra-competitive Bitcoin mining industry, miners don't want larger blocks if they don't have the bandwidth to propagate them fast enough. (A few milliseconds can mean that another miner propagates a confirmed block first).

Therefore increasing maxblocksize to 8MB does not mean that blocks will be 8MB. Right now most confirmed blocks are not 1MB, even when they could be.

Actual block size will be the result of a miner trade-off between propagation speed and fees. Right now, because fees are small compared to coinbase reward, miners have a strong incentive to go for small blocks, especially in high latency countries (ie: China).

The 1MB maxblocksize is an arbitrary, temporary limit. It should be removed or increased substantially. However that does not mean that we will get larger blocks unless the tech infrastructure improves. The current constraint is not storage. It's bandwidth.

(As @rogerkver recently tweeted "If every 1MB block were always full, it would take over 55 years to fill my new HD." https://twitter.com/rogerkver/status/628596027965083648)

I agree completely. It is not and will never be all or nothing. We both want the same thing: scalability + decentralisation.

My argument is that 8MB maxblocksize next year will not have a significant effect in increasing centralisation, compared to 1MB maxblocksize. However it will have a major positive impact on scalability and tx fees.

Keeping Bitcoin decentralised is important. But how much and at what cost? How many independent nodes do you need to make sure that the network is censorship resistant? 1000? 2000? 5000? 20000?

Will a Bitcoin that is used by 100 million people have more active nodes than one that is used by 1 million? I think so.

Therefore IMHO at this point growth has to be the priority. Reaching critical mass.

Just as there are technical solutions for scalability (Lightning Network, payment channels, off-chain txs...), there may be technical solutions for decentralisation (auto node-running hardware, bots, mining chips in toasters.....).

But none of those solutions will be developed if Bitcoin remains small.