michele terzi [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-12 📝 Original message:the blockchain is 160Gb ...
📅 Original date posted:2017-09-12
📝 Original message:the blockchain is 160Gb and this is literally the biggest problem bitcoin has right now. syncing a new node is a nightmare that discourages a lot of people.
this single aspect is what hurts bitcoin's decentralization the most and it is getting worse by the day.
to solve this problem i propose 2 softfork.
both of them have been partially discussed so you may be already familiar with them. I'll just try to highlight problems and benefits.
first SF)
a snapshot of the UTXO set plus all the relevant info (like OP_RETURNs) is hashed in the coinbase.
this can be repeated automatically every given period of x blocks. I suggest 55k blocks (1 year)
second SF)
after a given amount of time the UTXO hash is written in the consensus code.
this hash becomes the hash of a new genesis block and all the older blocks are chopped away
Pros:
you gain a much faster syncing for new nodes.
full non pruning nodes need a lot less HD space.
dropping old history results in more difficult future chainanalysis (at least by small entities)
freezing old history in one new genesis block means the chain can no longer be reorged prior to that point
old status
genesis |----- x ------| newgenesis |----- y ------| now
new status
newgenesis |----- y ------| now
while the old chain can be reorged to the genesis block the new chain can be reorged only to the newgenesisblock
cutting the chain has also some other small benefits: without the need to validate old blocks we can clean old no more usefull consensus code
Cons:
a small amount of space is consumed on the blockchain
every node needs to perform the calculations
full nodes with old software can no longer be fired up and sync with the existing network
full nodes that went off line prior to the second fork cannot sync back once they turn back on line again.
if these things are concerning (which for me are not) we can just keep online a few archive nodes.
old clients will sync only from archivial nodes with full history and new full nodes will sync from everywere
Addressing security concerns:
being able to write a new genesis block means that an evil core has the power to steal/destroy/censor/whatever coins.
this is possible only in theory, but not in practice. right now devs can misbehave with every softfork, but the community tests and inspects every new release.
the 2 forks will be tested and inspected as well so they are no more risky than other softforks.
additionally the process is divided into 2 separate steps and the first step (the critical one) is effectively void without the second (which is substantially delayed) this gives the community additional time to test it and thus is actually more secure than a standard softfork.
besides after the first softfork locks in there is no more room for mistakes. either the hashes match or they do not so spotting a misbehaviour is trivially simple
kind regards,Michele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170912/07a24423/attachment.html>;
📝 Original message:the blockchain is 160Gb and this is literally the biggest problem bitcoin has right now. syncing a new node is a nightmare that discourages a lot of people.
this single aspect is what hurts bitcoin's decentralization the most and it is getting worse by the day.
to solve this problem i propose 2 softfork.
both of them have been partially discussed so you may be already familiar with them. I'll just try to highlight problems and benefits.
first SF)
a snapshot of the UTXO set plus all the relevant info (like OP_RETURNs) is hashed in the coinbase.
this can be repeated automatically every given period of x blocks. I suggest 55k blocks (1 year)
second SF)
after a given amount of time the UTXO hash is written in the consensus code.
this hash becomes the hash of a new genesis block and all the older blocks are chopped away
Pros:
you gain a much faster syncing for new nodes.
full non pruning nodes need a lot less HD space.
dropping old history results in more difficult future chainanalysis (at least by small entities)
freezing old history in one new genesis block means the chain can no longer be reorged prior to that point
old status
genesis |----- x ------| newgenesis |----- y ------| now
new status
newgenesis |----- y ------| now
while the old chain can be reorged to the genesis block the new chain can be reorged only to the newgenesisblock
cutting the chain has also some other small benefits: without the need to validate old blocks we can clean old no more usefull consensus code
Cons:
a small amount of space is consumed on the blockchain
every node needs to perform the calculations
full nodes with old software can no longer be fired up and sync with the existing network
full nodes that went off line prior to the second fork cannot sync back once they turn back on line again.
if these things are concerning (which for me are not) we can just keep online a few archive nodes.
old clients will sync only from archivial nodes with full history and new full nodes will sync from everywere
Addressing security concerns:
being able to write a new genesis block means that an evil core has the power to steal/destroy/censor/whatever coins.
this is possible only in theory, but not in practice. right now devs can misbehave with every softfork, but the community tests and inspects every new release.
the 2 forks will be tested and inspected as well so they are no more risky than other softforks.
additionally the process is divided into 2 separate steps and the first step (the critical one) is effectively void without the second (which is substantially delayed) this gives the community additional time to test it and thus is actually more secure than a standard softfork.
besides after the first softfork locks in there is no more room for mistakes. either the hashes match or they do not so spotting a misbehaviour is trivially simple
kind regards,Michele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170912/07a24423/attachment.html>;