Bitcoin Forum

ok, so I installed bitcoin core latest version and it downloaded over 80G of chain block. Let's assume, just for the fun of it, there are 1000 bitcoin core users out there. That's ~8T of wasted disk space. and considering bitcoin will live another 7 years and it will grow of couse, that's like ~20T of disk space (1000 users remember?) for what? couldn't be a centerlaize, maybe mirrored, location that the client will ask for the chain block from there? Why do we need to download it?

That's just the basic concept of bitcoin, it's a decentralised ledger, no authority, no banks... All users can (and should) download the full blockchain. If you would use 1 or 2 centralised servers, it wouldn't be a decentralised system ;)

That being said, there are alternatives... If the synchronisation of the blockchain is to much for you: you can use an SPV client.

Examples are: electrum and multibit HD

Well, I look at linux as an example of decentralized system. poeple download it online. I doesn't have 1 or 2 servers but houndreds of independent mirror servers and you can download it from any of them. or is it a bad example?

Also, I might not grasp the subject fully, but where is the blockchain downloaded from?

Hi,

I edited my previous post, but apparently you already quoted it before i saved my edits (i was a bit to slow :) ) .

To answer these questions:
Question 1: the example of comparing bitcoin to linux is not a very good one, that being said, you can actually use an SPV client (like i mentioned above).
This client will connect to a central server that has has been synched. Those SPV clients will only manage your private keys, labels and adresbook. That way you have most of the security of a desktop wallet without having to download all blocks.

Question 2: The blockchain is downloaded from other peers, but not from a centralised server.

The entire purpose of downloading the entire blockchain is to independently verify it and allow for the independent verification of every single block and transaction that occurs later. The only thing that a full node needs to "trust" is the genesis block, the very first block of the blockchain. This is actually hard coded into the software so that there is a defined starting point. After that, the node downloads all of the blocks from its peers. It will check each transaction in the block, and then check the block to ensure that it is valid. Because each block is chained together and transactions are also chained together, it is not possible to start from any point in the blockchain other than the beginning and still maintain trustlessness.

Your example is pretty much what Electrum and other SPV wallets do... it allows you to just connect to one of these "mirrors" and get the bits important to you... ie. the inbound and outbound transactions on your wallet.

Effectively, these SPV systems are "thin clients" onto the Blockchain... connecting to compatible "full nodes" that have the full blockchain. Unsurprisingly, one of the main reasons they came into being is for the very reason you are posting... that is, the storage requirements of the blockchain ;)

It also helps with mobility. Can you imagine putting the full blockchain on a mobile device?  :o

You download the entire blockchain to check for yourself that:

1. nobody created more bitcoins than are allowed
2. that nobody spent a bitcoin not belonging to them
3. that all the other rules of bitcoin were followed. (e.g. difficulty)

You do not. Problem is that you have a wrong mindset. You say
It the same as saying: Why bank vaults need all these security? Just buy a garden shed and put all your valuables in it. Why waste all steel, concrete ect.? 

Eventually they need to find some way to better compress the chain would be nice for a start.

I think no need for that. Even if all blocks will be full, blockchain will grow by 52G per year. And modest 1T hard drive, will be enough for ~20 years. Such HDD costs $50 it's BTC0.1.

Block must be bigger in the future, they will indirectly with SegWit already. Keep in mind that someone new must also be able to download all that data in reasonable time. Its not only about diskspace.

I just moved out to a rural area, and I have the fastest internet available to me. I recently accidentally corrupted my Core Client with a bad re-boot.. So I had to completely re-sync the entire blockchain. This took me literally 56-Hours of leaving my laptop running with exclusively Core Open. It definitely is about being about to get that data in a reasonable time, which currently is constrained and only getting worse.

The block chain should be placed in segments: year by year. So the miner selects the year(s) he wants to download, you can imagine the data load 50 years from now. How do you download tons of Gigabyte?

You mean Terabytes?

Patiently.

According to speedmatters.org, average USA broadband speed is 11.7 Mbps.

If you want to download 3 Terabytes (3,000 Gigabytes) at that speed it would take you about 23.75 days.

Of course if the blocksize stays at 1 megabyte per block, it will take more than 50 years to reach 3 Terabytes.

Do you really think that communication speeds for the average person will still only be 11.7 Mbps 50 years from now?  Doesn't it seem much more likely that faster forms of communication will be developed and implemented over the next few decades?  How fast was electronic communication for the average person 50 years ago (back in 1966)?

If communications in 50 years is 10 times faster than it is today, then it will only take about 2.5 days to download a 3 Terabyte blockchain.

Now, if we increase the blocksize, then we'll need storage space and communications speeds to increase fast enough to keep up.

Danny is right, and that is just the average. 

xfinity runs at least 88 Mbps right now or 8.8 MBps  => 528MB/minute = >31GB/hour => 744GB/day.

AT&T Fiber (GigaPower) 300Mbps = about 2.5TB/day.

In 1980 one was lucky to get 300bps (or 180bps).  No one serious thinks this has peaked.

So now bandwidth is being dismissed by the same flawed arguments as the disk space?  ???

Completely ignoring data caps and low speed restrictions imposed by providers. Completely ignoring that only first world countries have these sorts of high speed infrastructures (the US is hardly the worst performer in the world). Completely ignoring that most people want to run more than just one application that sucks up all their bandwidth. Completely ignoring that while writing a technology cheque way into some mythical rose-tinted future, the only ones that are likely to be able to afford it are corporations, governments and fat cats.

Bitcoin wasn't around in 1980 and has gone from zero to datacenter in a couple of years (let alone 40) due to the resources required to run the system and we are supposed to believe the tech available to the average Joe will be good enough in another 10 when it's struggling now?

Makes my blood boil!    >:(

The short answer is you don't. They could make it a distributed file system but all the people that actually know how it all works are tied up working on schemes to try and screw as much money out of the users rather than improving the protocol.

I don't know why they don't just put the thing on newsgroups and we all use web wallets seeing as the only people that really matter are the miners.

Now?

Always has been.


Nor the best.


So invent a better decentralized system.  Until you do (or someone else does), this is the best we've got.  Might as well calm down and accept it (or abandon bitcoin) or you'll kill yourself over the stress of it all.  Complaining about the way it works isn't going to get it fixed any faster.

I am not dismissing concerns about bandwidth or disk space.  I am merely pointing out that arguments that don't take into account exponential increases in capacity in both bandwidth and storage space with stable or decreasing costs are (a) purposefully avoiding reality, (b) purposefully trying to mislead people, OR (c) trolling.  

If you or anyone wishes to code the "distributed file system" and integrate it with Bitcoin Core and convince people it is a better solution so that a majority if people adopt it, please go ahead.  Is there a technical paper of how this would work in bitcoin and an analysis as to how it would provide the same security that Bitcoin does now?

I am sure that any well-tested code that the people who are complaining about the block chain size (and the like) are willing to commit to Bitcoin Core to decrease the sizes would be more than welcome.  

I think that in the future there wont be one blockchain downloaded for each user as it is today but more like one per household. A family will setup a computer and download the blockchain and keep it up to date while useing other wallets to point to that BC for verification and use. A family shares resources, there is only 1 fridge, 1 stove, 1 safe,  etc. Yes more can be had but typically only 1 per household. Same will happen with businesses and such.

The chain is growing pretty fast and maybe one day we will reach a point where its tough to download but technology is also fast moving. I remember using dialup to downlaod Photoshop years ago.... took 3 days, but it was worth the trouble. Bitcoin is the same, if you want to use it then you'll do whats needed.

I think that's just clutching at a fantasy because you know deep down it's untenable.

Today in my pocket I have a tap & pay debit credit card that I can use in any shop around the world. I choose the product. Tap and wait for the fries. In the future I will still have a tap and pay card and the bitcoin part of it will be in HSBCs datacenter as it transfers funds from my account over to Bank of America account. Why am I going to buy a top of the range PC to tun a single piece of software so that my family have to use another different  piece of awkward software just to send some birthday money?

Am I missing something here? If you don't want to maintain the entire blockchain, you can run in pruned mode, and/or not download the segwit records (when they are in general use).

Full nodes are required to maintain the security of the blockchan. SPVs and online wallets don't do this and full nodes are disappearing as the amount of hardware needed to run one increases (disk space mainly). There are two current views of how to halt the decline.

1) Try to figure out how to make a full node profitable because only money is an incentive, right?
2) Reduce the hardware requirement and make all clients full nodes.  No incentive required and increase the number of nodes by an order of magnitude.

Guess which one all the miners want?

SPV wallets relies on a trusted servers...does that mean it's also not 'decentralized'?

If every node enables pruning, new nodes won't be able to sync the chain on top of the genesis block, they would need to trust a third party to receive an updated chain. Practically if this happens (very unlikely in short-mid term) it will have disastrous implications on decentralization and security.
Afaik there are plans to distribute the block chain data on nodes to address the problem.

However there will still be the need to sync the entire history, which will increasingly uncomfortable in the future.
There is an interesting idea on a "Bitcoin Onchain Pruning" (https://www.scribd.com/document/317130737/Bitcoin-On-Chain-Pruning) solution,but I don't know to what extent it can work.

downloading the full blockchain is nessasary because if anyone tryed to insert a fauls transactuon into the network then every other pc will found it and will say hah nice try :p

true, more like one per household.

Top range computer? You mean a rpi with a multi TB hard drive attached? so less than $100 investment? Sure that means buying the hardware and building it, that means linux and such which isnt something an average person can do however by the time this is needed someone will have created a product that you buy and plug in. Actually, it already exists... its just not cheap.

I will say that one per household may be a stretch but what about ISPs offering them? The internet works by DNS servers but I dont have one in my house, I use theone offered by my ISP. Same with a mail server, I dont use one thats setup in my home but rather one managed by my ISP. This gets us away from decentralization a bit so Im not sure its a good answer but I can see it happening.

Sure. And we'll all use web wallets connected to the full nodes supplied by the miners. You won't have one of those full nodes in your house either. Why you think an ISP is going to offer a full node, I have no idea.

The single ledger on every machine is the trivial,naive solution. They are not even using torrent tech to distribute it so you scream at 8 nodes to give you the data and hope they have decent connections. The real solution is a distributed file system so the ledger is spread around the cloud and you index the blocks as you need them. Then you only need a cache of the latest few once you have done the first bootstrap.

why do not we make a online storage which our software can be linked with i mean like a bootstrap script when we include in our webpage in the same manner we should include this

For one, this would be centralizing the script, where everyone takes information from the same source. This provider could change and edit the information and users will use it.

Server issues?

you can even take that further, and have some kind of mini-societies of people who trust each other all point to one node one of the people in that mini-society owns.

Such as a family and some close friend of that family and family of that family.

Like mother-in-laws and brothers and sisters (who each have their own families).

As long as you trust each other there should be no problem.

Thank you very much for this answer i too had the same question as the thread creator and this helps sum things up for me!

To me, Electrum and the other wallets like it are no different than holding your money on the online exchanges. You don't own your money. Somebody else does. They just let you to control your money as you like.

 The original wallet on the otherside, is the real deal. You actually own your money. (I assume there isn't anything shady in the code)

we need to download the whole bitcoin network because its will also help bitcoin system to verify each and every transaction and nothing can breake the chain and yes its wasting a lot of space

 down loading of whole bitcoin transaction may necessary to validate in case if any transaction re verification etc . but only thing is as you said it occupies more storage on physical drive , but need to concentrate on compressing those files and reducing the so that you can save some disk space.

我来学习看看。

with only under 10 mbps, it needs too long to download chain block :o

just because the basic concept of bitcoin, it's a decentralised ledger, no authority, no banks

It's too big to download it. Sad story using tekcoin i need to sync it manually (can not from bootstrap) and it tooks around 2 weeks to complete it.

In the first place, there is no rationale to store 7 years of history for synced nodes. But how a new node could get into network if all the fullnodes have thrown away all the blocks(except last few ones to handle possible rollbacks)? Bitcoin has no answer for that.

I've developed a proposal to fix the issue and solve some important questions towards better scalability. The paper is just uploaded http://arxiv.org/abs/1603.07926 . I would be happy to get feedback.

Great to see people are working on this. I was beginning to think the "technology is cheap" brigade were winning. It was a bit much for me to take in in one go so I'll need to read it several times but there was once thing that struck a chord with me - the linked list. I think this is a key point to enable breaking the blockchain into resolvable chunks to enable both forward and backward discovery. You only need to find one chunk to be able to construct the whole chain by pregressively downloading the prev/next in the list..

I too have been working in that direction except using a variant of the bitorrent DHT. There are a couple of proposals whereby the DHT conveniently uses   merkle trees! (http://bittorrent.org/beps/bep_0030.html) and an  arbitrary data field (http://bittorrent.org/beps/bep_0044.html) (1K) which I would increase to 1MB (current block size). The protocol would additionally have the prev/next  (linked list) of the blocks so the blockchain would be stored in the DHT and cached throughout the network. This would also work with the current chains without modification because you could just dump the entire chain and let the client use it.

I'm not sure about replication, as yet. The one thing that is lacking is a mechanism to ensure that at least one of each is available at all times so a slight modification of the rarity calculation might be needed.

I hope to see more research in this area.

This paper is a bit of a disappointment, sad to say.  First-- it makes a number of false claims about the capabilities of the existing Bitcoin system, e.g.

"To be rational it is needed to switch to an implementation of the Bitcoin protocol which does not hold the unnecessary data (such an implementation of a full node does not exist to the best of our knowledge)."

The whole reason that Bitcoin has state snapshots, as described in the paper, was because they were introduced to enable strong pruning (a more limited version is described in section 7 of the Bitcoin whitepaper).  Bitcoin has supported operating in a pruned fashion for _years_.


The primary suggestion the paper is making is to bootstrap nodes from state snapshots. The paper describes this as "trustless" but it is _not_, rather it makes the same strong assumption of hashpower honesty that SPV (lite wallet nodes do), implicitly trusting the history of the longest chain to be faithful.

This is not a new idea, its expression spans at least back to 2011:

https://bitcointalk.org/index.php?topic=21995.0

and

https://en.bitcoin.it/wiki/User:DiThi/MTUT

(as is using random tests for data in the mining process,-- though the scheme you suggest is fully delegatable, so long as the miner doesn't mind giving temporary custody of his income to the centralized party holding the world's only copy of the blockchain. :) )

The state commitment proposals face a couple challenges, one is that if you are willing to strongly trust the hashpower-- then why not use the vastly more efficient SPV mode?  The other is that the initial efforts to implement continual state commitments found that the overhead (primarily IO) of maintaining them multiplied the full node operating costs at runtime by several fold.  The costs have made what would otherwise be another option for client security less attractive, supporting a more niche security model would be fine if it were inexpensive.

Alternative designs like mimblewimble try to make bootstrapping more efficient without adding a new form of strong trust towards miners.

turn your point of view...
in a next futures, nearest than 7 years, 20Tb will be like today 20gb or maybe 20Mb..
just look here
http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/
give it time

Platitudes like this are speculative, unhelpful and infuriating.

Now we are being told we need two drives because the block chain gets corrupted. The current blockchain storage isn't fit for purpose and you are in denial.

Will it ever be possible to enable pruning mode without having to download the entire chain the first time?
Isn't 1GB enough to guarantee safety? I mean who (attacker) is ever going to manage to go "1gb back in time?"
Of course full nodes is deal but I think people would use Core wallet more if you could enable pruned without download entire chain first time.

That depends on what you want to do. If you just want to verify a specific transaction, like when you receive a payment, you really only need to download all blocks that include all previous inputs. Then, any inputs that have been spent can be safely pruned.

It reminds me when i first download the qt wallet, it said I need to download the blockchain for many days. LOL

The answer of why: the wallet needs to have full blockchain file for sync, we need to sync the wallet to see more transactions details, but you can still send bitcoin if the wallet is not sync

Dear Greg, it seems you've missed a part of the protocol. Let me provide a quick description of Rollerchain, more precisely, modifications from the Bitcoin.

1. We authenticate the state and include root value into a blockheader. It is an old idea yes, and already implemented in Ethereum (and some other coins) as mentioned in the paper.

2. We then modify a Proof-of-Work function. A miner chooses "k" state snapshot versions out of last "n" a (sufficiently large) network stores collectively. In order to generate a block miner needs to provide proofs of possession for the state snapshots. On a new block arrival a miner updates k+1 states, not one, so full blocks (since minimal value in "k") are also needed.

Thus miners store a distributed database of last "n" full blocks AND state snapshots getting rewards for that activity. A new node could download not just a last snapshot, but from "n" blocks ago (or from somewhere in between). So it is not needed to "strongly trust the hashpower", but "hashpower" and also up to "n" last full blocks("n" considered to be >> than a deepest fork possible, say, 5000-10000 for Bitcoin) . And this is not about SPV, but about getting fullnode-going-from-genesis security(with probability of divergence going down exponentially with "n", see Theorem 2). Full blocks not needed in order to mine could be removed by all the nodes.

If you have concerns about this scheme please let me know, and I will try to formalize/address them.

Authenticated state root in a block header could be useful anyway for better SPVs. On efficient implementation, we're now working on that along with benchmarking. Let's see how it goes.


P.S. However, as PoW function modification is needed it is unlikely Bitcoin can go this way(miners will not throw away their ASICs).

I think Rollerchain (RC) is similar in motivation to SPV but different under the hood.

(If I understood correctly, haven't spent too much time on it)

Assume round 0 is "now" , -1 is last block, -2 the one before that, etc.

Let U_i be UTXO set at round i

SPV stores Delta(U_{-n}, U_{-n+1}), Delta(U_{-n+1}, U_{-n+2}) .. Delta(U_{-1}, U_0)

RC stores: (U_{-n}, Delta(U_{-n}, U_{-n+1}), Delta(U_{-n+1}, U_{-n+2}) .. Delta(U_{-1}, U_0))

Thus, SPV is equivalent (at least in storage complexity) with RC having the additional initial state.
In RC, once a new block (delta) is mined, the state U_{-n} is updated to U_{-n+1} and U_{-n} is discarded.

The difference I think is that SPV does not enforce nodes to store n blocks and its more or less a risk if every node prunes their chain to just 10 blocks (acting "rationally").

RC claims to enforce within the protocol itself that the n blocks be stored.

I understand "why" we have to download it. But oh man, it's awful! I wish I knew I was in for eighty gigs about three years ago, when I got into Armory.

Back then it was only around 30 gigs, doable in a day. There has got to be an easier way. Let's hope that when the blockchain size hits something like 20 T, internet services will also have kept up and evolved at the same rate.

Even for a fullnode, Bitcoin protocol does not enforce nodes to store (any number) of full blocks, so if a new node is able to download blocks since genesis that is the artifact of altruistic behaviour. RC works under stronger assumptions about rationality of network participants. Please note nodes in RC could save more full blocks than required by the protocol, even from genesis (as in Bitcoin), but that's not really needed (as well as in Bitcoin).

I must say that I do not mine and that I do not know much about mining, but I have a question:
Can't the blockchain be imported from a usb medium?
I mean, if I download it and put it on a usb stick (if that is possible), can't I give it to my neighbour so that he does not have to download the blockchain?

You don't have to unless you download the main client. It supports the network to be a node, and you can even self-mine from your wallet (with little to no effect, though.)

At least some clients/miners need to maintain the entire blockchain at all times to reach consensus. Every single transaction matters because it affects the entire history.

Yes, this is possible. Your neighbor's client will read the blockchain and start where it left off.

I know that Bitcoin Core can run in Prune Mode, effectively cutting disk space you will need for storing blockchain data.
But you will still need to download whole blockchain before that. Is there even remote possibility that we won't need to download whole blockchain in the future by using some sort of 'pruning'?

It really hurts to download the 7 years of blockchain on slow and turtle-speed internet connections like in my country. However as an alternative you can use Multibit-HD wallet which is very much compact ans useful since id does not need to download the entire 20GB+ blockchain.

Otherwise the need for the entire block ledger is there since that what is needed to understand the distribution of coins and for new transactions.

I did not miss this.   But unless I am misunderstanding you,  you appear to be conflating two orthogonal changes.

One is the change to the POW which requires the miner to show possession of state snapshot data.  This does nothing to assure users that the data is correct.  It ~may~ increase the odds there are multiple copies of it (though unless I misunderstand it-- your design is trivially delegatable so long as the miners are willing to trust the party storing the data until their coins mature, which users of mining pools already do almost ubiquitously).

The other is that you begin nodes from a state snapshot, not at the tip, but at some point somewhat back. This is also taught in in the citations I provided above.  This also does not prove that the state is correct, in fact it provides no evidence at all that the state is correct except under a strong assumption.

Instead, participants hope that the state is correct without checking under a strong assumption that the majority hashpower would not extend a chain with invalid state updates. This is the SPV security assumption.

It is different and weaker than the normal Bitcoin behavior, trusting a majority hashpower for the soundness of state updates and not merely their sequencing. In practice it is not sufficient to simply take such a strong assumption and not question it's validity-- normally the SPV hashpower assumption is justified by the widespread and economically significant use of full nodes which will not be deceived by dishonest miners; but with full nodes also making a SPV assumption for blocks away from the tip, this argument becomes circular.

The SPV assumption is especially concerning because we have discovered that miners have begun bypassing validation themselves in order to mitigate the negative effects of larger amounts of transaction data on propagation. State sampling proof of work has been argued as a potential improvement for this particular issue, but proposals so far have worsened the generation of progress in the mining function (as the last miner to create a block has a state update advantage) and they still leave plenty of opportunity to optimize by shortcutting the parts of validation that the state updates do not expose.


Perhaps it would be revealing to answer a question:  You are a new node joining the network. I am part of an attacking consortium which has, for several months, had a super majority hashpower at my disposal.  Can I cause you to accept a chain extending the chain from no further than a few months back, otherwise compatible with a 'honest chain' (if it existed)-- meaning containing all the same transactions and ownership except as mentioned-- where I instead have a million extra BTC reassigned from the earliest blocks?

If you see a newly generated block, that means "k" state snapshots in the past (for different heights) are stored by the network, and the guarantee is pretty strong. On delegation, to reach line 15 in the RollerPoW function with a new input (so anything changed in <a_t, a_S, ctr> with fixed <s, a_t>)  you need to recalculate a ticket so you can't fix a_t and outsourcing of ticket calculation doesn't make any sense.


Which assumption?



If "a super majority hashpower" is committed to adversarial behaviour, we got common prefix property (and chain quality also) from the GKL model broken. Light verification is also broken in this case(it assumes common prefix property being hold, see Theorem 2). Full verification is also broken though. Even more, how can you define a desirable bootstrapping procedure outcome if common prefix property isn't held? If it is held, bootstrapping outcome could be simply defined like "a new node is getting chain C such as set (C |_| chains of honest participants) satisfies common prefix property". I'm going to update the paper with a definition like that.

It answered my question of y download the block chain

In Australia most of our ADSL lines cap out at around 300kbps download - so if you want to download the blockchain then you better start 2 and a half days earlier than you actually want it. I wonder if eventually we will move to a centralised archive of transactions up to a certain date and 'reset' the local blockchain (similar to what happens with a web wallet now). As long as you trust the centralised archiver then it could prove to be convenient, albeit at the introduction of additional risk of corruption.

Noob questions, but on the topic to SPV wallets. Is there a way of importing an old wallet (from 2009) into Eletrum with a "wallet.dat" file? ;D

Thanks in advance!

I am very much surprised with the low amount of download speed from Australia. I have read in news in the internet it is considered a developed country. In my country Italy it is very easy to get an ADSL which downloads with 20 MBPS and we can download the whole blockchain in just one day at the worse.

However if you don't want to download the full blockchain, you can use SPV wallets like electrum or Multibit.
Here are their websites:
www.electrum.org
www.multibit.org

I download blockchain bitcoin already 1 month ... I think, blockchain bitcoin will be his gravedigger ... The more people will use it - the longer download and will take up more space on disks

don't be a wuss and take it all
all 40 gigs :)
you can use lightweight clients like mycellium and save yourself the trouble of downloading and syncing
or you can use web based wallets
core wallets are for the hardcore bitcoin enthusiasts,I don't use core since 2014 and have no remorse.

I don't think it's necessary at all.

Here is a quote from the original whitepaper (https://bitcoin.org/bitcoin.pdf):


I just think this is just being shoved under the carpet because it probably conflicts with the devs idea to keep the 1MB blocksize limit in place.

the size is not a problem, but it takes a long time to download because you need to verify every single transaction and that takes a lot of processing power.

Normally I can download 40 gigabyte files in minutes, but downloading and verifying the blockchain takes weeks, if not longer.

I think, if you can download 7 years of chain block, you should do it to support the the decentralized system. Do not fall into the trap of collective irresponsibility! Well, if you cannot download that much data, you still could use the client and do transactions or find an alternative, lightweight client. In the long term, we are advised to find a solution for the big data problem in-before bitcoin network starts a centralization pattern.

I am assuming you are talking about the first method (in bold). Maybe I missed something in the debate but whats the connection with the block size and storing headers?