summaryrefslogtreecommitdiff
path: root/f2/36a9cee7c1adb89b12d2efaf3c16428a4aefff
blob: e7611d4386d64d24d99ef9e1358d3c0b64675c66 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 80A498A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 May 2018 06:50:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com
	[209.85.216.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F270A685
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 May 2018 06:50:44 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id m16-v6so1256982qtg.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 May 2018 23:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=8rSFE76nfcvERGAH/mQeyNsd5S7RG72BQ5D1tL2shS0=;
	b=DdMS2ZHYqKGunDUwZOuoIsGoPu41T0qwXgocnCu1i3o8J6rp6xChWSeTmW1vvD/plI
	3IUldgKla0t0QRWfvw+xUHPPzdM+PQOAElIybK/8x2J90wg56btaoaEs44Ms+2Fa/hDc
	LhOxuIitBgC52un3s/6bFnTa2JCFVgFwj9lF8AeHi31cxBn3KwAg2nOZalDSBnuxERf+
	Wx/Mn+bWKf1NKteH06MLnpXdRI29+BTQJlXsmERRqP9+8BTxoRrUD2Sk7JWuq0H1tOr3
	NdbJcsSRdFOb0zLsKEtMcZIufWKUWkNpVyoFB8eTbPFCiD1sju0Q9I04wJQNt+BTFFIk
	VFxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=8rSFE76nfcvERGAH/mQeyNsd5S7RG72BQ5D1tL2shS0=;
	b=gX0LnBWhqwfCOY3DOMUEoMfV9mUi8HF3Y8BiTtzhZNnQLxmB0+7xV837KswZQugF8q
	RKP47zZ0bdETByJh0cmHchQ8bLFpmh2XVF+QF4MwjnrQCVxrz8l+p4FKxibFCnAW60QV
	YaUp9DTP6GIPEVX6EuOKAqvY8XmPrVk5FnMu5qfU2pSGdrBYeyt+4XjgKfs2eCYQ8qo1
	kQKNBHGhB4YlAW/XZNY8+4ux7xutsUZ20qLHcvkY4eQQAR7RJXByEcVWcqYqOY7UAzNs
	0iVrFaLcr2TNTof6R5NacQ3iDLoYiVR/MMLBiL1JQjDyy+eFf+stfBDVhCq1gdq84Gn7
	Bn0g==
X-Gm-Message-State: ALKqPwchHjC/QO3xaAc7mT9McrTW1dE+gb0YluggFGbohZ25kDBn8V74
	lkwsw/v4iEFRFOYbEp0DVk6qO/yE90mn7y4Yf6UGmA==
X-Google-Smtp-Source: AB8JxZrgV0ewbI8ko0weWwNwCBN02TuVQGfMXsQ4QYs6qf6KLtcdjXtXG3ut5anL1HaEAvRw1Bbem1/CXDSXym7Q6ZY=
X-Received: by 2002:ac8:35f0:: with SMTP id
	l45-v6mr146109qtb.317.1525935043867; 
	Wed, 09 May 2018 23:50:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.50.92 with HTTP; Wed, 9 May 2018 23:50:43 -0700 (PDT)
In-Reply-To: <fd403450-cf7f-ce56-79ca-93c77c042289@frankentrikes.com>
References: <fd403450-cf7f-ce56-79ca-93c77c042289@frankentrikes.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Wed, 9 May 2018 23:50:43 -0700
Message-ID: <CADZtCSiU8oG1Zpr0tfadiUdQhMY00X5C99bphC86-kFPMaYb3g@mail.gmail.com>
To: Segue <012mistery@frankentrikes.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003d7846056bd47096"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 10 May 2018 12:45:10 +0000
Subject: Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?
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: Thu, 10 May 2018 06:50:45 -0000

--0000000000003d7846056bd47096
Content-Type: text/plain; charset="UTF-8"

That is a good observation that most of the historical data does not need
to be kept around. I believe what you are suggested is already implemented,
however. Bitcoin Core can operate in a pruned mode, where the bulk of the
historical block data is discarded and only the current UTXO set (and a few
recent blocks) are kept. As you note, some nodes on the network need to run
in archive mode to help new nodes get in sync. BIP 159 helps identify these
archive nodes at the gossip layer.

In the case of lightning, some implementations made use of the additional
txindex, which is not compatible with pruned mode.

On Wed, May 9, 2018 at 5:56 PM, Segue via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning
> without running a fully-fledged bitcoin block chain? (Yubin Ruan)."  The
> inquirer was asking because he didn't have much space to store the entire
> blockchain on his laptop.
>
> I replied:
>
> "Developers,
>
> On THIS note and slightly off-topic but relevant, why can't chunks of
> blockchain peel off the backend periodically and be archived, say on
> minimum of 150 computers across 7 continents?
>
> It seems crazy to continue adding on to an increasingly long chain to
> infinity if the old chapters (i.e. more than, say, 2 years old) could be
> stored in an evenly distributed manner across the planet. The same 150
> computers would not need to store every chapter either, just the index
> would need to be widely distributed in order to reconnect with a chapter if
> needed. Then maybe it is no longer a limitation in the future for people
> like Yubin. "
>
> It was suggested by a couple of lightning developers that I post this idea
> on the bitcoin-dev list.  So, here I post :).
>
> Segue
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000003d7846056bd47096
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That is a good observation that most of the historical dat=
a does not need to be kept around. I believe what you are suggested is alre=
ady implemented, however. Bitcoin Core can operate in a pruned mode, where =
the bulk of the historical block data is discarded and only the current UTX=
O set (and a few recent blocks) are kept. As you note, some nodes on the ne=
twork need to run in archive mode to help new nodes get in sync. BIP 159 he=
lps identify these archive nodes at the gossip layer.<div><br></div><div>In=
 the case of lightning, some implementations made use of the additional txi=
ndex, which is not compatible with pruned mode.</div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Wed, May 9, 2018 at 5:56 PM, S=
egue via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3/17/18, s=
omeone posted on the Lightning-dev list, &quot;Can I try Lightning without =
running a fully-fledged bitcoin block chain? (Yubin Ruan).&quot;=C2=A0 The =
inquirer was asking because he didn&#39;t have much space to store the enti=
re blockchain on his laptop.<br>
<br>
I replied:<br>
<br>
&quot;Developers,<br>
<br>
On THIS note and slightly off-topic but relevant, why can&#39;t chunks of b=
lockchain peel off the backend periodically and be archived, say on minimum=
 of 150 computers across 7 continents?<br>
<br>
It seems crazy to continue adding on to an increasingly long chain to infin=
ity if the old chapters (i.e. more than, say, 2 years old) could be stored =
in an evenly distributed manner across the planet. The same 150 computers w=
ould not need to store every chapter either, just the index would need to b=
e widely distributed in order to reconnect with a chapter if needed. Then m=
aybe it is no longer a limitation in the future for people like Yubin. &quo=
t;<br>
<br>
It was suggested by a couple of lightning developers that I post this idea =
on the bitcoin-dev list.=C2=A0 So, here I post :).<br>
<br>
Segue<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</blockquote></div><br></div>

--0000000000003d7846056bd47096--