Is it possible to restart the blockchain?

[deisik]

I was thinking about the ways to make the blockchain smaller, and the most obvious and simplest solution that I came up with consists in restarting the blockchain one day. For example, we can start with an empty blockchain every year with only initial balances written on it and without any transactions. I think that would make the whole network more reliable, while full nodes easier to maintain

Of course, the previous blockchains should be available at all times as well, whoever may need them. We may have to tie them up into one whole using links or whatever so that we could always trace all transactions back to the genesis block.

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

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

[H1N1]

I was thinking about the ways to make the blockchain smaller, and the most obvious and simplest solution that I came up with consists in restarting the blockchain one day. For example, we can start with an empty blockchain every year with only initial balances written on it and without any transactions. I think that would make the whole network more reliable, while full nodes easier to maintain

Of course, the previous blockchains should be available at all times as well, whoever may need them. We may have to tie them up into one whole using links or whatever so that we could always trace all transactions back to the genesis block. Note that we don't necessarily have to restart with an empty blockchain as we can, for example, save the last 2-3 years of transactions once the blockchain is restarted

Is this a good idea?

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.

[deisik]

I was thinking about the ways to make the blockchain smaller, and the most obvious and simplest solution that I came up with consists in restarting the blockchain one day. For example, we can start with an empty blockchain every year with only initial balances written on it and without any transactions. I think that would make the whole network more reliable, while full nodes easier to maintain

Of course, the previous blockchains should be available at all times as well, whoever may need them. We may have to tie them up into one whole using links or whatever so that we could always trace all transactions back to the genesis block. Note that we don't necessarily have to restart with an empty blockchain as we can, for example, save the last 2-3 years of transactions once the blockchain is restarted

Is this a good idea?

But when you start with initial balance, it means you don't start the blockchain from empty one, it is already filled with balance

It is a matter of convention

You will lose the details about your initial balance where it came from, because the blockchain has start from empty data

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

[HippiePyro]

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

[o_e_l_e_o]

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?

[yusupjatigumilar]

 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 ?

[HandsomePeople]

you can't restart a blockchain, because it requires to hard coding all the unspent outputs in all Bitcoin clients the moment the reset takes place. Having that said, we can just compress the old blocks to reduce blockchain size.

[figmentofmyass]

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?

if it's done on the protocol level, then it basically becomes a hardcoded checkpoint, so it's a strong sign of centralization. once that happens, POW can no longer reorganize the blockchain past the checkpoint, so that throws into question what the consensus algorithm really is---POW or some human-enforced checkpointing scheme?

i know vitalik buterin once said that checkpointing was reasonable if coded below sufficient amount of POW, so there may be a spectrum of opinion about this. stubborn bitcoiners are unlikely to go for this.

[jerrison]

i do not consider it possible to restart a blockchain neither do i consider it possible to restart the entirety of the blockchain technological space. it is not a database system where data acquired can be modified nor deleted or even copied so i am very positive about the impossibilities in restarting a blockchain or any blockchain.

[Lexurdania]

you can't restart a blockchain, because it requires to hard coding all the unspent outputs in all Bitcoin clients the moment the reset takes place. Having that said, we can just compress the old blocks to reduce blockchain size.

I am agree. The decentralized system make transaction data spread around the world and its almost unhackable. I dont think its possible to change transaction data, blockchain is secure system and with decentralized system, its more secure

[deisik]

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?

if it's done on the protocol level, then it basically becomes a hardcoded checkpoint, so it's a strong sign of centralization. once that happens, POW can no longer reorganize the blockchain past the checkpoint, so that throws into question what the consensus algorithm really is---POW or some human-enforced checkpointing scheme?

Is it possible to reorganize the blockchain beyond 1 month or so?

If not, then adding a checkpoint for transactions older than 1 year is not really going to change anything. And let's not forget (well, if I'm not mistaken) that Bitcoin already has this "human-enforced checkpointing scheme" built in, and it had already been used in the past (and maybe not just once)

So taking into account these circumstances your whole point is not very relevant for purely technical and practical reasons. Regarding trusting a third party when downloading the pruned version of the blockchain, I don't see how it is particularly different from trusting a node to download its full version from

[Quickseller]

The most recent block found was block 562554. Perhaps there could be a HF so that the genius block has a block reward matching all of the unspent outputs as of block 500000, and that all subsequent blocks remain unchanged. This would effectively cement the first 500k blocks, but they are realistically not going to change.

Would this result in a decreased ability to "verify" the blockchain and all previous transactions? Yes. However it would also save HDD space when Bitcoin users want to store the entire blockchain, and network resources when new nodes attempt to download the entire blockchain. The drawbacks should be weighed with the benefits when entities decide to support this potential HF to potentially form sufficient consensus for a HF. 

[deisik]

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?

But do you need to actually verify all the past blocks?

As I see it, that simply doesn't make any sense and that's likely the reason why no one is doing this in practice (honestly, I don't know, so bear with me). In this way, there is no real need in blocks older than a certain age (say, 1 month) as far as supporting the network is concerned. Indeed, if you need to do some analysis, you may have to download the entire blockchain (or all the snapshots) but no one is suggesting to erase them for good

[Julunguul]

Well, this kind of thing is really can't be accepted, at least for the blockchain itself, since whole of this connected into Internet, we just can't restart them, just like all the record that Internet has, Data History, Cache and Cookies. Also we know that Blockchain is decentralized right ? Then if you think that it can be restarted, where should the Restart "Button" should available ?

[deisik]

Would this result in a decreased ability to "verify" the blockchain and all previous transactions? Yes. However it would also save HDD space when Bitcoin users want to store the entire blockchain, and network resources when new nodes attempt to download the entire blockchain. The drawbacks should be weighed with the benefits when entities decide to support this potential HF to potentially form sufficient consensus for a HF. 

That's actually another good point

And in that case you won't have to wait a few days until the download of the whole blockchain is finished if you want to run a full node. I saw a lot of people complaining about having to wait for days until they were finally able to run a Bitcoin node. Indeed, you can download a compressed archive of it from somewhere, but it is trusting a third party, which many people vigorously object to. Now imagine if the size of the blockchain gets out of control completely tomorrow. That would be like fees going to insane levels in late 2017 (but with no way back)

[squatter]

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?

But do you need to actually verify all the past blocks?

As I see it, that simply doesn't make any sense and that's likely the reason why no one is doing this in practice (honestly, I don't know, so bear with me). In this way, there is no real need in blocks older than a certain age (say, 1 month) as far as supporting the network is concerned.

That goes against the entire philosophy of proof of work, though.

The point of proof of work is that it is cumulative -- there is a chain of work proven back to the genesis block. If one block is invalid, every block mined on top of it is invalid. This is a basic mechanism to prevent dishonest mining.

What you're suggesting are called "checkpoints", and then pruning the blockchain below the last checkpoint. The early versions of Bitcoin actually included checkpoints to ensure reliability of confirmations. The use of checkpoints has been phased out -- there hasn't been one coded into the protocol since 2014. This is because of what I mentioned earlier: Checkpoints give developers power over Bitcoin's security model because developers can make blocks irreversible when they otherwise would have been reorganized by miners.

[Aligab166]

I was thinking about the ways to make the blockchain smaller, and the most obvious and simplest solution that I came up with consists in restarting the blockchain one day. For example, we can start with an empty blockchain every year with only initial balances written on it and without any transactions. I think that would make the whole network more reliable, while full nodes easier to maintain

Of course, the previous blockchains should be available at all times as well, whoever may need them. We may have to tie them up into one whole using links or whatever so that we could always trace all transactions back to the genesis block. Note that we don't necessarily have to restart with an empty blockchain as we can, for example, save the last 2-3 years of transactions once the blockchain is restarted

Is this a good idea?

I love your imaginative thinking. But how possible would this be? What if in the course of the restart some codes get missing and some information lost? Moreover, creating such a restart mechanism might lead to easy interference by anyone on the blockchain and as such, transactions may be manipulated. It will put the security of the entire blockchain at risk.

[deisik]

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?

But do you need to actually verify all the past blocks?

As I see it, that simply doesn't make any sense and that's likely the reason why no one is doing this in practice (honestly, I don't know, so bear with me). In this way, there is no real need in blocks older than a certain age (say, 1 month) as far as supporting the network is concerned.

That goes against the entire philosophy of proof of work, though.

The point of proof of work is that it is cumulative -- there is a chain of work proven back to the genesis block. If one block is invalid, every block mined on top of it is invalid. This is a basic mechanism to prevent dishonest mining.

What you're suggesting are called "checkpoints", and then pruning the blockchain below the last checkpoint. The early versions of Bitcoin actually included checkpoints to ensure reliability of confirmations. The use of checkpoints has been phased out -- there hasn't been one coded into the protocol since 2014. This is because of what I mentioned earlier: Checkpoints give developers power over Bitcoin's security model because developers can make blocks irreversible when they otherwise would have been reorganized by miners

I understand what you say

And in fact, I'm not arguing with that. But you don't want to understand me. Basically, you are taking a position of a Bitcoin maximalist (extremist) even if Bitcoin itself is a bunch of trade-offs (not even mentioning earlier used checkpoints). I'm not saying that we should set checkpoints every other day but pruning the blockchain after 1 year of transactions (or running a ghost version for those who need it) may be a trade-off that we should have if the size of the blockchain is set to expand dramatically in the coming years. And it should be ready now, not after it actually happens to avoid the situation of late 2017 (with fees). That's my point

[Tondya]

I see your point here, but just think of how many difficulties and messed up chains we might have! besides, not everyone would agree with this solution. Too smart!

[squatter]

That goes against the entire philosophy of proof of work, though.

The point of proof of work is that it is cumulative -- there is a chain of work proven back to the genesis block. If one block is invalid, every block mined on top of it is invalid. This is a basic mechanism to prevent dishonest mining.

What you're suggesting are called "checkpoints", and then pruning the blockchain below the last checkpoint. The early versions of Bitcoin actually included checkpoints to ensure reliability of confirmations. The use of checkpoints has been phased out -- there hasn't been one coded into the protocol since 2014. This is because of what I mentioned earlier: Checkpoints give developers power over Bitcoin's security model because developers can make blocks irreversible when they otherwise would have been reorganized by miners

I understand what you say

And in fact, I'm not arguing with that. But you don't want to understand me. Basically, you are taking a position of a Bitcoin maximalist (extremist) even if Bitcoin itself is a bunch of trade-offs (not even mentioning earlier used checkpoints). I'm not saying that we should set checkpoints every other day but pruning the blockchain after 1 year of transactions (or running a ghost version for those who need it) may be a trade-off that we should have if the size of the blockchain is set to expand dramatically in the coming years.

I think pruning is great. Anyone who doesn't have the storage space for the entire blockchain should do it. However, since storage space is not a critical bottleneck in Bitcoin scaling and isn't a major threat to node decentralization, I think it would be a net loss to implement it at the consensus level. The tradeoff isn't worth it.

I get what you're saying with checkpoints from a practical view. The problem is, once you give developers that control, it's like Pandora's Box. It might begin an endless political controversy. How much proof of work is enough before Bitcoin is ultimately decided by human consensus? Maybe not two days worth of blocks, but how about a month or a year -- is that enough? Does this open up new selfish mining attack vectors where the attacker would release their chain reorg directly before a checkpoint is hard coded?