path: root/15/077346f2bb1275e1403e038302e1e8711fdc1e

Return-Path: <iopoiti@yahoo.it>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 76F2D8CC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Sep 2017 23:18:50 +0000 (UTC)
X-Greylist: delayed 00:20:08 by SQLgrey-1.7.6
Received: from sonic302-21.consmr.mail.ir2.yahoo.com
	(sonic302-21.consmr.mail.ir2.yahoo.com [87.248.110.84])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8E4C5E5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Sep 2017 23:18:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.it; s=s2048;
	t=1505258327; bh=PW4v4nSFjuCOEVy8g/X6tbCGGnKtiIQolL20AzQU+0U=;
	h=Date:From:Reply-To:To:Subject:References:From:Subject;
	b=sP1bfFqZ6UvifpkTqf8x99ygGu3vxfPW27HOm4Dnrallv2pKdpiA5giRLgmDUv+RGBvgxm0X8fUfJP1r2hHxft0YZXBl7qCgjF875achaiq8GUZ812vFO/bXRBYlHCtGZN34MsBxSYNXpjsUPYnwMXt7BZT7RTcbY1AfGc22QM+d0Y146IQP+qDbsQHlrICrVbjeFzkfqosbLAJ5+kNd2v+T96a02sUsG3PW7xo/6XU9NAx4pngVh+o/cwAw0qF/e5uE8UajA/ylIyHRh0An0smkjHkAnBFLvKBBrLp6LdEdJGuS63sH/1zzwabP2NFLeUawHa+29TAIobYr+ATCHQ==
X-YMail-OSG: tFlBLvAVM1l1AQShbaVKIadRShICvqJaU9dnJKxtRzOHkgRu3diRDf.njC_pLNI
	hYLNhL5G1OmWNHQXGMa.AgrBQhZGGlExVVl0cCaJtw795i8R9f4LPeW1KfnjYoOoD_Yo6XyflCc7
	tOgmJoQ6Z_ttGFP8LXqakyhjazVnFgCEOfxbuDn3hO2fKjvmHfzhUtGI0X4nUu8OKkGoX0ZCjUIP
	czdx7v.IpenRwrgnl.L10mQTLJLJxFwcrJ6iY.nMMETBmS4buJR0fbLdXOXs637Nu7Th3Dwu09iD
	RA0_sP90A4yGWTbENNjZsO_06h7qmZoHFg3izwZRfs9WmDCln07F3RR_p2T9QzTNR3ZLM1w2ygoo
	R5DcpF9xYPPMmJB4qfEyMPBVnjL80atrcS.9q75.bPqVY0NMFciK9PWgL1CwOlHtM2tOSXNjaiPF
	NBI5Qd8YVVMEQxMh9El98.J.PbpXsfwhF
Received: from sonic.gate.mail.ne1.yahoo.com by
	sonic302.consmr.mail.ir2.yahoo.com with HTTP;
	Tue, 12 Sep 2017 23:18:47 +0000
Date: Tue, 12 Sep 2017 22:58:35 +0000 (UTC)
From: michele terzi <iopoiti@yahoo.it>
Reply-To: michele terzi <iopoiti@yahoo.it>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <351373080.1326948.1505257115533@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_1326947_988504158.1505257115531"
References: <351373080.1326948.1505257115533.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.10521 YahooMailNeo Mozilla/5.0 (X11; Ubuntu;
	Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
X-Spam-Status: No, score=1.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FORGED_MUA_MOZILLA,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 13 Sep 2017 08:13:37 +0000
Subject: [bitcoin-dev] 2 softforks to cut the blockchain and IBD time
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 23:18:50 -0000

------=_Part_1326947_988504158.1505257115531
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

the blockchain is 160Gb and this is literally the biggest problem bitcoin h=
as right now. syncing a new node is a nightmare that discourages a lot of p=
eople.
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 w=
ith 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 sugges=
t 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 lea=
st 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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 newge=
nesis |----- y ------| now

while the old chain can be reorged to the genesis block the new chain can b=
e reorged only to the newgenesisblock

cutting the chain has also some other small benefits: without the need to v=
alidate old blocks we can clean old no more usefull consensus code


Cons:=20

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 ex=
isting network
full nodes that went off line prior to the second fork cannot sync back onc=
e they turn back on line again.

if these things are concerning (which for me are not) we can just keep onli=
ne a few archive nodes.
old clients will sync only from archivial nodes with full history and new f=
ull nodes will sync from everywere


Addressing security concerns:

being able to write a new genesis block means that an evil core has the pow=
er to steal/destroy/censor/whatever coins.

this is possible only in theory, but not in practice. right now devs can mi=
sbehave 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 ste=
p (the critical one) is effectively void without the second (which is subst=
antially delayed) this gives the community additional time to test it and t=
hus is actually more secure than a standard softfork.
besides after the first softfork locks in there is no more room for mistake=
s. either the hashes match or they do not so spotting a misbehaviour is tri=
vially simple

kind regards,Michele

------=_Part_1326947_988504158.1505257115531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div style=3D"color:#000; background-color:#fff; f=
ont-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font=
-size:13px"><div id=3D"yui_3_16_0_ym19_1_1505235822221_2803" dir=3D"ltr">th=
e 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 peo=
ple.<br id=3D"yui_3_16_0_ym19_1_1505235822221_3280">this single aspect is w=
hat hurts bitcoin's decentralization the most and it is getting worse by th=
e day.<br id=3D"yui_3_16_0_ym19_1_1505235822221_3281"><br id=3D"yui_3_16_0_=
ym19_1_1505235822221_3282">to solve this problem i propose 2 softfork.<br i=
d=3D"yui_3_16_0_ym19_1_1505235822221_3283"><br id=3D"yui_3_16_0_ym19_1_1505=
235822221_3284">both of them have been partially discussed so you may be al=
ready familiar with them. I'll just try to highlight problems and benefits.=
<br id=3D"yui_3_16_0_ym19_1_1505235822221_3285"><br id=3D"yui_3_16_0_ym19_1=
_1505235822221_3286"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3287">first =
SF)<br id=3D"yui_3_16_0_ym19_1_1505235822221_3288">a snapshot of the UTXO s=
et plus all the relevant info (like OP_RETURNs) is hashed in the coinbase.<=
br id=3D"yui_3_16_0_ym19_1_1505235822221_3289">this can be repeated automat=
ically every given period of x blocks. I suggest 55k blocks (1 year)<br id=
=3D"yui_3_16_0_ym19_1_1505235822221_3290"><br id=3D"yui_3_16_0_ym19_1_15052=
35822221_3291">second SF)<br id=3D"yui_3_16_0_ym19_1_1505235822221_3292">af=
ter a given amount of time the UTXO hash is written in the consensus code.<=
br id=3D"yui_3_16_0_ym19_1_1505235822221_3293">this hash becomes the hash o=
f a new genesis block and all the older blocks are chopped away<br id=3D"yu=
i_3_16_0_ym19_1_1505235822221_3294"><br id=3D"yui_3_16_0_ym19_1_15052358222=
21_3295"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3296">Pros:<br id=3D"yui=
_3_16_0_ym19_1_1505235822221_3297"><br id=3D"yui_3_16_0_ym19_1_150523582222=
1_3298">you gain a much faster syncing for new nodes.<br id=3D"yui_3_16_0_y=
m19_1_1505235822221_3299">full non pruning nodes need a lot less HD space.<=
br id=3D"yui_3_16_0_ym19_1_1505235822221_3300">dropping old history results=
 in more difficult future chainanalysis (at least by small entities)<br id=
=3D"yui_3_16_0_ym19_1_1505235822221_3301">freezing old history in one new g=
enesis block means the chain can no longer be reorged prior to that point<b=
r id=3D"yui_3_16_0_ym19_1_1505235822221_3302"><br id=3D"yui_3_16_0_ym19_1_1=
505235822221_3303">old status<br id=3D"yui_3_16_0_ym19_1_1505235822221_3304=
"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3305">genesis |----- x ------| =
newgenesis |----- y ------| now<br id=3D"yui_3_16_0_ym19_1_1505235822221_33=
06"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3307">new status<br id=3D"yui=
_3_16_0_ym19_1_1505235822221_3308"><br id=3D"yui_3_16_0_ym19_1_150523582222=
1_3309">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; newgenesis |----- y ------| now<br id=3D"yui_3_16_0_ym19_1_1505235822221=
_3310"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3311">while the old chain =
can be reorged to the genesis block the new chain can be reorged only to th=
e newgenesisblock<br id=3D"yui_3_16_0_ym19_1_1505235822221_3312"><br id=3D"=
yui_3_16_0_ym19_1_1505235822221_3313">cutting the chain has also some other=
 small benefits: without the need to validate old blocks we can clean old n=
o more usefull consensus code<br id=3D"yui_3_16_0_ym19_1_1505235822221_3314=
"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3315"><br id=3D"yui_3_16_0_ym19=
_1_1505235822221_3316">Cons: <br id=3D"yui_3_16_0_ym19_1_1505235822221_3317=
"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3318">a small amount of space i=
s consumed on the blockchain<br id=3D"yui_3_16_0_ym19_1_1505235822221_3319"=
>every node needs to perform the calculations<br id=3D"yui_3_16_0_ym19_1_15=
05235822221_3320"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3321">full node=
s with old software can no longer be fired up and sync with the existing ne=
twork<br id=3D"yui_3_16_0_ym19_1_1505235822221_3322">full nodes that went o=
ff line prior to the second fork cannot sync back once they turn back on li=
ne again.<br id=3D"yui_3_16_0_ym19_1_1505235822221_3323"><br id=3D"yui_3_16=
_0_ym19_1_1505235822221_3324">if these things are concerning (which for me =
are not) we can just keep online a few archive nodes.<br id=3D"yui_3_16_0_y=
m19_1_1505235822221_3325">old clients will sync only from archivial nodes w=
ith full history and new full nodes will sync from everywere<br id=3D"yui_3=
_16_0_ym19_1_1505235822221_3326"><br id=3D"yui_3_16_0_ym19_1_1505235822221_=
3327"><br id=3D"yui_3_16_0_ym19_1_1505235822221_3328">Addressing security c=
oncerns:<br id=3D"yui_3_16_0_ym19_1_1505235822221_3329"><br id=3D"yui_3_16_=
0_ym19_1_1505235822221_3330">being able to write a new genesis block means =
that an evil core has the power to steal/destroy/censor/whatever coins.<br =
id=3D"yui_3_16_0_ym19_1_1505235822221_3331"><br id=3D"yui_3_16_0_ym19_1_150=
5235822221_3332">this is possible only in theory, but not in practice. righ=
t now devs can misbehave with every softfork, but the community tests and i=
nspects every new release.<br id=3D"yui_3_16_0_ym19_1_1505235822221_3335"><=
br id=3D"yui_3_16_0_ym19_1_1505235822221_3336">the 2 forks will be tested a=
nd inspected as well so they are no more risky than other softforks.<br id=
=3D"yui_3_16_0_ym19_1_1505235822221_3337"><br id=3D"yui_3_16_0_ym19_1_15052=
35822221_3338">additionally the process is divided into 2 separate steps an=
d the first step (the critical one) is effectively void without the second =
(which is substantially delayed) this gives the community additional time t=
o test it and thus is actually more secure than a standard softfork.</div><=
div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1505235822221_3511"><br></div><div =
dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1505235822221_3530">besides after the f=
irst softfork locks in there is no more room for mistakes. either the hashe=
s match or they do not so spotting a misbehaviour is trivially simple<br></=
div><div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1505235822221_3444"><br></div>=
<div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1505235822221_3453">kind regards,<=
/div><div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1505235822221_3452">Michele<b=
r></div></div></body></html>
------=_Part_1326947_988504158.1505257115531--