michele terzi via bitcoin-dev
2017-09-12 22:58:35 UTC
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.
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)
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
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
genesis |----- x ------| newgenesis |----- y ------| now
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 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
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