Topic: Is it possible to restart the blockchain? - page 3. (Read 759 times)

 That would be very detrimental to many people, especially for those who currently have large balances in their wallets, besides that it will be detrimental to this, in my opinion, it will again make the price of bitcoin plummet as at the start, why do you think about restarting the blockchain ?

Surely this stops bitcoin being trustless?

If you "restart" the blockchain by taking a "snapshot" at a set time, you lose all the history leading up to that snapshot, meaning you cannot verify it. You therefore have to trust that the snapshot you are downloading is accurate. If you are running a full node, you can verify the entire history of bitcoin yourself and then prune it locally as much as you want. Does a forced global pruning not mean you have to trust a third party to send you an accurate snapshot?

It would be like setting a check point and all nodes must agree on balances. This is similar to the mimblewimble, which makes sure all blocks dont produce invalid coins, thus eliminating the need for the record

It is a matter of convention


No, I didn't mean that initial balances should be lost

The whole point is getting rid of old transactions but definitely not balances that these transactions resulted in. As I see the whole thing right now while taking into account the fact that full nodes don't need to save the whole blockchain data without sacrificing the ability of being a full node, we may want to have two blockchains

The first would be the one which we currently have (let's call it full blockchain), while the other a lightweight version of the first. The lite blockchain could only store initial and final balances as well as a certain number of transactions, say, for the last 2-3 months. That should make our lives easier

But when you start with initial balance, it means you don't start the blockchain from empty one, it is already filled with balance.
You will lose the details about your initial balance where it came from, because the blockchain has start from empty data.

I did in fact mean something like that at first

But if we don't need to propagate the whole blockchain every time a new block is found or a significant chunk of it (as we obviously don't have to do that), then storing only a few recent blocks on the client side should do the trick. And in this case you are right, we don't need to do that at the protocol level as it simply makes no sense then because technically, the blockchain as a continuous whole doesn't even exist at that level, i.e. the rules for how you should store it are not specified there

If this is possible then I would agree with it.
Honestly, I'm not good on the technical aspects of the blockchain but I understand what you mean.
It's actually similar to the financial reporting within the bank where there is a beginning balance and ending balance
and every year all accounts are close into single account name but the history on every transaction is still accessible.

I can see a future where pruned Blockchains will be the norm and you will incentive schemes for people to host full archive nodes to access the whole Blockchain. They can even have different choices for people to run a node based on their own parameters, say for the last 5000 Blocks or the last 2 years or whatever period they want.

Why should we not have the choice, if we are paying for the bandwidth and the storage space?  Most 3rd world countries with less money and bad internet would prefer pruned nodes based on their scenario.

Sounds like sharding, which is planned for Ethereum in the future. Sharding doesn't seem compatible with proof-of-work because the vast majority of nodes won't ever fully validate the blockchain, only the shard to which they belong to. An SPV proof would be possible, and that would provide a decent level of security. Downloading the whole blockchain and then pruning it defeats the purpose, though, so most people would never do it.


That seems to be the biggest risk -- like a torrent with no seeders and only leechers.

in relation to restarting the entire network back to genesis block, while also keeping the current network alive as a separate chain.. this is just creating a non-premined altcoin

many have done this many times, where the rules are pretty much the same. only they change the name of the coin to make it obvious that its not the same chain as the current bitcoin network.

forked chains (that begin at XXXXXX block instead of block zero again) are called forked premined chains.

as for not re-starting a network at zero(genesis) but just deleting some blocks where the funds of an old block is spent was one original vision of 'prunning' but then prunning every block upto current height minus a few hundred blocks became the main vision of prunning where nodes (not the entire network) .. but just some nodes dont archive the whole chain.

.....
knowing that core are ok with prunning.. thus relying on just some UTXO set and knowing that the main irritation of newbies syncing for the first time is not so much about the delay itself but the fact they cant see a final balance untill synced to know if they imported the right wallet.. you might aswell just let nodes grab a UTXO set to atleast give users an upfront 'unverified' balance so people can get on and do things. which then makes sitting around twiddling thumbs a non-issue. thus the initial sync then becomes just a background second afterthought.
much like gaming these days that do small install of a light demo level that people can play with while the main game is in the background downloading. thus people get a initial glimpse/ useful experience upfront and are more happy to let a decade of data download in the background. win win basically.
(i dont mean have this as default/forced feature. but an option box like prunned that can be chosen for those people who nag about having to wait days/weeks before they can do anything with a full node)

The previous blocks wouldn't be stored on your disk though right? If they were then you're still storing the whole blockchain.

Early today I was thinking about the feasibility of partitioning the chain into linkable segments in the following way:

Let's assume at some point in the future the blockchain is 300 GB, a crude (but fine for this quick example) technique would be to split it into 3 parts; each containing 100GB. If you don't want to store the first 200 GB since it's irrelevant to you (but you'd still like to verify transactions yourself) you could just store some type of Merkle hash of all the blocks of the first 100GB and another for the second 100GB.

If one day you decide you want to validate everything since the genesis block you could ask your peers for the blockchains you don't have (the first 200GB) by providing your hashes. To confirm that it's the real deal, you would need to hash each chain you get to see if it matches your hash of that chain.

• I'm not sure of the best way to get the hash in the first place, getting it from other nodes seems risky, so maybe you'd need to download segments of blocks from archival nodes then hash the segment.

Once you've done that you can discard the chain (freeing up many GB of space) and just keep the hash for reference.

I'm pretty sure you could verify the entire chain from start to finish by doing this continually for each segment. If it worked you could save a lot of storage space, though I can imagine some problems that may arise, some off the top of my head would be

• it would take an absurd amount of time to validate the whole chain (even compared to doing it the normal way)
• if all nodes stored part of the full chain, it's possible that sections of the chain could be lost forever
• what determines where the chain is partitioned? What if you hashed 1 block more than anyone else in your partition so now your hash is incompatible with everyone else. You'd need to redo the work

It's probably a very bad idea to do this, but it's fun to think about it  

as figment said, this is "pruning". it already exists and you can also do anything else as you like as long as it is on the individual client sides, there is nothing stopping you from "restarting" anything. but blockchain is an immutable ledger and should always remain intact. because of that no matter how big it gets we need to have it stored somewhere, preferably on thousands of nodes all around the world to keep the network decentralized.


speaking of mass adoption, the average Joe is never going to run a full node whether it is 10 GB or 100 GB. they will use custodian wallets, web wallets, and SPV clients for ease of use so that they don't have to get involved with any kind of complications.

Impossible to restart blockchain because today is the best value and higher quality of blockchain because with best service quality blockchain become more profitable payment at the future, many companies have accepted bitcoin as transaction payment and will be more profitable with speculative price bitcoin and altcoin, always got positive thinking about how bitcoin could be most interested payment by investors.

There's a distinction that the Bitcoin Wiki makes between "full node" and "archival node" which I think is pretty useful:



Archival nodes help the network by bootstrapping full nodes who need to download and validate the entire blockchain. You can prune the chain and even turn listening off and still be a full node -- it just means fully validating.

Yes, I'm talking about full nodes

That is, the nodes which actually support the network and which (if my understanding is correct) have to keep the whole blockchain in their local storage. Thus pruning the blockchain will make the life easier for them as they won't have to keep all this information that they may never need. Well, I don't actually know how much they need but I assume that they don't need it all (for the purposes of processing and propagating transactions)

So if we hope for an explosive growth in Bitcoin mass adoption, we should also understand at which cost it will come. To actually understand what it might look like, recall how it happened in the past when the mempools were congested with an insane number of transactions and you have to pay exorbitant fees to have them confirmed. Now multiply that by 10 (or even by 100). This is not about miners here but hopefully you get the point

Not quite. Light clients in Ethereum are not capable of fully validating a block by themselves. It's the SPV model -- looking up a transaction and validating headers but not validating entire blocks. What the OP is talking about sounds more like fully validating nodes that prune their blockchain to save storage space.

it sounds like you're applying "pruning" at the protocol level. the client removes all transactions from its database which include outputs that are already spent. pruned clients still have the full UTXO set and headers that validate back to the genesis block.

this can already be done at the node/client level---i don't see the value of doing it at the protocol level. you turn on pruning if your resources are limited. if people have the resources to run archival nodes, that's all the better. no need to turn all nodes into pruned nodes though.

If Bitcoin is to evolve, this issue should be addressed

Even if you employ compression, that will likely allow you to squeeze, say, 10x more transactions into the same space as now. But if Bitcoin really grows to the level of fiat payment systems like Visa, MasterCard, etc, that won't be enough (even though it may ease things a lot in the short term). Regarding Lightning Network, it may be a good solution but it is still a solution to the "wrong" problem, i.e. a problem which shouldn't be there in the first place

And as such it will always remain a crutch unless we are going to change the "underlying" (let's call it undies) one day and make it run on bare metal, so to speak. Pruning the blockchain will come naturally then

That would basically be erasing the blockchain and simply starting from the UTXOs. This is what lite wallets on ETH actually do.

I don't really see the need for anything like that. I'm pretty certain that at one day, there will be a new transactional data format that requires way less block space, which means that the blockchain itself isn't growing as 'rapidly' as it was doing before the upgrade, and you can keep the smaller blocks without increasing them, which we will be forced to at one point if nothing changes.

In the very long term, most of the day to day activity will take place on the Lightning Network. I don't see much reason to switch back to the main chain for the average user by that point, which is the whole point of layer 2 at the end of the day.