From: michele terzi <iopoiti@yahoo•it>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] 2 softforks to cut the blockchain and IBD time
Date: Tue, 12 Sep 2017 22:58:35 +0000 (UTC) [thread overview]
Message-ID: <351373080.1326948.1505257115533@mail.yahoo.com> (raw)
In-Reply-To: <351373080.1326948.1505257115533.ref@mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 3015 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 6185 bytes --]
next parent reply other threads:[~2017-09-12 23:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <351373080.1326948.1505257115533.ref@mail.yahoo.com>
2017-09-12 22:58 ` michele terzi [this message]
2017-09-13 9:09 ` Tier Nolan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=351373080.1326948.1505257115533@mail.yahoo.com \
--to=iopoiti@yahoo$(echo .)it \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox