deisik (OP)
Legendary
Offline
Activity: 3486
Merit: 1280
English ⬄ Russian Translation Services
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 07: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?
|
|
|
|
BitcoinGirl.Club
Legendary
Offline
Activity: 2870
Merit: 2760
Bitcoingirl 2 is downloading 💓
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 07:48:05 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?
You are talking about another Blockchain which will connect the old blockchains. 😊 The current blockchain will be always a lighter one but when you add old year's blockchains then it becomes the usual one.
|
|
|
|
deisik (OP)
Legendary
Offline
Activity: 3486
Merit: 1280
English ⬄ Russian Translation Services
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 07:53:40 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?
You are talking about another Blockchain which will connect the old blockchains. The current blockchain will be always a lighter one but when you add old year's blockchains then it becomes the usual one Well, I actually didn't mean like we should literally link them together (like one after another into one big file). It should be more like having a few separate blockchains on your hard disk. Each of these "closed" or "locked" blockchains would provide an entry and exit point (sort of) that would allow some application to run over a chain of transactions starting from the very first block and ending with the most recent one (or in the opposite direction) The point is to remove information which is not required for current operation
|
|
|
|
kryptqnick
Legendary
Offline
Activity: 3192
Merit: 1397
Join the world-leading crypto sportsbook NOW!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 08:02:56 PM |
|
Okay, but is it really restarting it if the old one remains? It's more like just making a new one. The main problem with this idea, I think, is to make people abandon the old one and switch to the new one. How to avoid stuff like another Bitcoin blahblahblah version appearing? And if we do it regularly, then some people will use blockchain #1 (probably the majority), others #2, #3 etc. This will split the community into small parts, and it'll just be confusing. Oh, and what about the prices? Wouldn't we technically just have different cryptocurrencies and thus each of them will have its own marketcap and price? I think it can have significant negative impact.
|
|
|
|
cryptoXgames
Newbie
Offline
Activity: 10
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 08:05:51 PM |
|
It doesnt make any sense at all, sure would be easy to run a node, but why to have another blockchain without important things? Something i do love at blockchain is the thing to check all transactions and when were made, sounds like the old story of the pizza, something to record not to hide or compact.
If you wanna to collect some information about the size and volumes each year its another history..
|
|
|
|
deisik (OP)
Legendary
Offline
Activity: 3486
Merit: 1280
English ⬄ Russian Translation Services
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 08:15:27 PM |
|
Okay, but is it really restarting it if the old one remains? It's more like just making a new one. The main problem with this idea, I think, is to make people abandon the old one and switch to the new one. How to avoid stuff like another Bitcoin blahblahblah version appearing? And if we do it regularly, then some people will use blockchain #1 (probably the majority), others #2, #3 etc. This will split the community into small parts, and it'll just be confusing. Oh, and what about the prices? Wouldn't we technically just have different cryptocurrencies and thus each of them will have its own marketcap and price? I think it can have significant negative impact What you describe is an engineering problem You will likely find a lot of other technical issues if you start digging further and deeper. But this topic is not about such things, I'm more concerned with the idea itself taken on its own merits (and probably shortcomings). All in all, I think it is a good idea to keep the blockchain size to a minimum, and one way to actually get there is to reset or restart the blockchain regularly, say, every 2-3 years (terminology is a matter of convention here)
|
|
|
|
1Referee
Legendary
Offline
Activity: 2170
Merit: 1427
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 08:31:37 PM |
|
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.
|
|
|
|
cryptomaster420
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 256
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 08:46:14 PM |
|
That would basically be erasing the blockchain and simply starting from the UTXOs. This is what lite wallets on ETH actually do.
|
|
|
|
deisik (OP)
Legendary
Offline
Activity: 3486
Merit: 1280
English ⬄ Russian Translation Services
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 09:00:02 PM |
|
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 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
|
|
|
|
figmentofmyass
Legendary
Offline
Activity: 1652
Merit: 1483
|
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.
|
|
|
|
squatter
Legendary
Offline
Activity: 1666
Merit: 1196
STOP SNITCHIN'
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2019, 10:42:53 PM |
|
That would basically be erasing the blockchain and simply starting from the UTXOs. This is what lite wallets on ETH actually do.
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.
|
|
|
|
deisik (OP)
Legendary
Offline
Activity: 3486
Merit: 1280
English ⬄ Russian Translation Services
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 01:11:58 AM |
|
That would basically be erasing the blockchain and simply starting from the UTXOs. This is what lite wallets on ETH actually do.
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 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
|
|
|
|
squatter
Legendary
Offline
Activity: 1666
Merit: 1196
STOP SNITCHIN'
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 01:33:34 AM |
|
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 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. There's a distinction that the Bitcoin Wiki makes between "full node" and "archival node" which I think is pretty useful: What makes a full node? Full nodes download every block and transaction and check them against Bitcoin's consensus rules. Archival Nodes A subset of full nodes also accept incoming connections and upload old blocks to other peers on the network. This happens if the software is run with -listen=1 as is default. Contrary to some popular misconceptions, being an archival node is not necessary to being a full node. 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.
|
|
|
|
xabre
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 01:36:36 AM |
|
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.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3542
Merit: 10778
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 04:06:13 AM |
|
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. So if we hope for an explosive growth in Bitcoin mass adoption, we should also understand at which cost it will come.
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.
|
|
|
|
c_atlas
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 140
Merit: 56
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 04:47:13 AM |
|
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.
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 ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
franky1
Legendary
Offline
Activity: 4312
Merit: 4633
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 05:21:25 AM |
|
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)
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
squatter
Legendary
Offline
Activity: 1666
Merit: 1196
STOP SNITCHIN'
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 05:33:49 AM |
|
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. 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. if all nodes stored part of the full chain, it's possible that sections of the chain could be lost forever That seems to be the biggest risk -- like a torrent with no seeders and only leechers.
|
|
|
|
Kakmakr
Legendary
Offline
Activity: 3514
Merit: 1963
Leading Crypto Sports Betting & Casino Platform
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 06:25:22 AM |
|
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.
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
Natalim
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2019, 06:41:34 AM |
|
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.
|
|
|
|
|