Is it possible to restart the blockchain? - page 2.

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: squatter on February 12, 2019, 04:17:49 AM

Quote from: deisik on February 12, 2019, 12:11:49 AM

Quote from: squatter on February 11, 2019, 06:01:10 PM

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?

I guess this can be easily controlled

I don't know which specific approach should be used but as I understand the probabilities can be easily calculated. So there likely shouldn't be a lot of human arbitrariness in deciding how much of the blockchain should remain before we prune it.

What is that based on? What are the probabilities?

I don't know what they numerically amount to (if this is your question) but it is the probabilities of someone reorganizing the blockchain beyond the active snapshot of it. I suspect they are infinitesimal if we talk about transactions older than 1 year. In fact, I'm inclined to think that all transactions older than 1 month can be considered practically irreversible

Quote from: squatter on February 12, 2019, 04:17:49 AM

Quote from: deisik on February 12, 2019, 12:11:49 AM

In other words, if leaving 1 year of transactions is enough to make such an attack nearly impossible, it seems like a good trade-off, especially if we consider the exponential growth of the blockchain in the future. Indeed, it may not come at all, but what are we all doing here then?

I think the burden is on you to show why it's so important to free up that storage space. It's not a major problem for scaling. Why is it a good trade-off? What will we gain?

It is not just about storage space as it is also about network bandwidth. I don't think it will be an overall good idea to download the whole blockchain once its size exceeds a few (dozen) gigabytes (given that bandwidth is not going to substantially increase in the foreseeable future, or ever)

So a pruned blockchain is sort of must-have if expect Bitcoin to grow

Quote from: squatter on February 12, 2019, 04:17:49 AM

Quote from: deisik on February 12, 2019, 12:11:49 AM

Further, there seems to be a misunderstanding. The checkpoint which I speak about should only refer to old transactions (say, older than a year), while you seem to mean that it should lock all transactions immediately prior to the checkpoint. This is not how I imagine that

A checkpoint makes all transactions prior to the checkpoint irreversible. If that's not what you mean, maybe you should clarify

That's definitely not what I mean and I have clarified everything in the OP and in the following posts. It is not me who first started to use the term "checkpoint" here, so it is not me either who should be asked for clarification. So I was kinda fooled into using this term (if I used it incorrectly)

But I think you got me pretty well

squatter

legendary

Activity: 1666

Merit: 1196

STOP SNITCHIN'

Quote from: deisik on February 12, 2019, 12:11:49 AM

Quote from: squatter on February 11, 2019, 06:01:10 PM

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?

I guess this can be easily controlled

I don't know which specific approach should be used but as I understand the probabilities can be easily calculated. So there likely shouldn't be a lot of human arbitrariness in deciding how much of the blockchain should remain before we prune it.

What is that based on? What are the probabilities?

Quote from: deisik on February 12, 2019, 12:11:49 AM

In other words, if leaving 1 year of transactions is enough to make such an attack nearly impossible, it seems like a good trade-off, especially if we consider the exponential growth of the blockchain in the future. Indeed, it may not come at all, but what are we all doing here then?

I think the burden is on you to show why it's so important to free up that storage space. It's not a major problem for scaling. Why is it a good trade-off? What will we gain?

Quote from: deisik on February 12, 2019, 12:11:49 AM

Further, there seems to be a misunderstanding. The checkpoint which I speak about should only refer to old transactions (say, older than a year), while you seem to mean that it should lock all transactions immediately prior to the checkpoint. This is not how I imagine that

A checkpoint makes all transactions prior to the checkpoint irreversible. If that's not what you mean, maybe you should clarify.

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: Kakmakr on February 12, 2019, 12:25:27 AM

Also Satoshi's coins and also some early Bitcoiner's coins are still recorded in some of these blocks and will be difficult to track, if it is only visisble in some nodes with the full Blockchain

That's not what I propose

It is not like I suggest we should just cut the long tail of the blockchain. We should, but we should also set incoming balances at the start of the pruned blockchain so that all balances will be intact. Indeed, if you want to trace old balances to the transactions that credited them, you would probably have to walk over all the snapshots until you reach the very first transaction which "initialized" a particular address

thesmallgod

full member

Activity: 1498

Merit: 129

your idea idea is good but i do not think the technology can be restarted. What you are actually saying can be compare to saying a baby which has been born should be reborn.The only solution to this is making idea another project that will work to bridge the gap between the existing blockchain technology. knowing fully well that there are alot of project working to improve the performance or the lag that exist in the technology. most especially the consensus algorithm.

Kakmakr

legendary

Activity: 3542

Merit: 1965

Leading Crypto Sports Betting & Casino Platform

Looking from our competitors point of view now, I would expect some accusations being made by them that we would not be able to boast about Bitcoin's immutability, because we would effectively be removing some of it's transaction history. We will be giving them ammunition against us.

Also Satoshi's coins and also some early Bitcoiner's coins are still recorded in some of these blocks and will be difficult to track, if it is only visisble in some nodes with the full Blockchain. Tongue

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: squatter on February 11, 2019, 06:01:10 PM

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?

I guess this can be easily controlled

I don't know which specific approach should be used but as I understand the probabilities can be easily calculated. So there likely shouldn't be a lot of human arbitrariness in deciding how much of the blockchain should remain before we prune it. In other words, if leaving 1 year of transactions is enough to make such an attack nearly impossible, it seems like a good trade-off, especially if we consider the exponential growth of the blockchain in the future. Indeed, it may not come at all, but what are we all doing here then?

Further, there seems to be a misunderstanding. The checkpoint which I speak about should only refer to old transactions (say, older than a year), while you seem to mean that it should lock all transactions immediately prior to the checkpoint. This is not how I imagine that

squatter

legendary

Activity: 1666

Merit: 1196

STOP SNITCHIN'

Quote from: deisik on February 11, 2019, 03:31:24 PM

Quote from: squatter on February 11, 2019, 03:04:18 PM

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?

Tondya

full member

Activity: 546

Merit: 100

Stake & Vote or Become a IoTeX Delegate!

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!

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: squatter on February 11, 2019, 03:04:18 PM

Quote from: deisik on February 11, 2019, 04:25:26 AM

Quote from: o_e_l_e_o on February 10, 2019, 05:01:55 PM

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

Aligab166

jr. member

Activity: 194

Merit: 1

Quote from: deisik on February 09, 2019, 02:35:44 PM

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.

squatter

legendary

Activity: 1666

Merit: 1196

STOP SNITCHIN'

Quote from: deisik on February 11, 2019, 04:25:26 AM

Quote from: o_e_l_e_o on February 10, 2019, 05:01:55 PM

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.

deisik

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: Quickseller on February 11, 2019, 03:27:09 AM

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)

Julunguul

member

Activity: 473

Merit: 11

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

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: o_e_l_e_o on February 10, 2019, 05:01:55 PM

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

Quickseller

copper member

Activity: 2996

Merit: 2374

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

legendary

Activity: 3514

Merit: 1280

English ⬄ Russian Translation Services

Quote from: figmentofmyass on February 10, 2019, 06:25:26 PM

Quote from: o_e_l_e_o on February 10, 2019, 05:01:55 PM

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

Lexurdania

member

Activity: 840

Merit: 10

Quote from: HandsomePeople on February 10, 2019, 05:24:00 PM

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

jerrison

full member

Activity: 1442

Merit: 106

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.

figmentofmyass

legendary

Activity: 1652

Merit: 1483

Quote from: o_e_l_e_o on February 10, 2019, 05:01:55 PM

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.

HandsomePeople

jr. member

Activity: 266

Merit: 1

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.

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