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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
Return-Path: <zapfmann@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DCDA110D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jun 2018 08:40:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com
[209.85.218.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4AB09326
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jun 2018 08:40:31 +0000 (UTC)
Received: by mail-oi0-f42.google.com with SMTP id a141-v6so20352532oii.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jun 2018 01:40:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=b7/q6eMqWwikGX5hX6DOWaPgNhw/GnH1raIGRLurwdI=;
b=N6vIhPBkr6ksfMbeVP5vk0ExnAxnq1+Y7pB7jSXXGVTYUG4mP9XIOBYUgrxUBCF00E
mBzPojSsOZUtnlwyc15DLH3HqqjfsrbQA/7E0f/HMySaCcdliAVv8QLVO3nF5enpoM2x
lvw1d7/L357GEDa5grJ+Czjm+k/QgOvomyYWCXxcN7ZNkVKOJv3Gh8CXb1QqYnUs3NZm
qCd4WAsPb5KC4Vky05hjgf3CS1RPa5AU7FGePPty4gMcDaehuvHWsLnW/kIoxB+uKdvl
pwqalIPGRN8RDLXV9ARX2i8CCN+d66geQ8Cr6GZai5zlLuQrXZ9awuP2JVg5W3tmS7Lh
BLaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=b7/q6eMqWwikGX5hX6DOWaPgNhw/GnH1raIGRLurwdI=;
b=kdWEJo4wZIE0+dU/LE/H4QtJ4Bn/m9MKgskZB8oMNRBOz2qDe+ryvO37lS7crP/5v6
6ofCrWFXNVgo4G7O9wCsmAL/otF9E/RkbL8YTv7vBZIVRhQwRDPz5BzZQUBcXPuXt22v
5X6tByx9aC59hz9wdRzTFdMWi7oWszGGArMVGRvG4yrk/NZf2jiFthzLq/rwX//Nw5Xe
cAZ8I34+uVHHUVlZ53ctmWWzlmJNYlxKB1elk3txF3bzO4pvYQ9wsM8qDM1fD0x6sGFp
COTQRC8j4iH5CaMOUrE3p2JDvxOQogQ/x3zNf4W/f1z7uv4vYghF/28FjHTGW7fFaXde
27FA==
X-Gm-Message-State: APt69E0VZWeeglNQ8Yu3PS/FkP8Goo4MJdDn9dE8/VMCB+NTul7AiVyq
QzU/mihjsIP0jF1a87K27ilAwM8NCd46PyXVdrmWNA==
X-Google-Smtp-Source: ADUXVKIyv8hEc7gz8eq9fpelraRa8wVztDJGjs75ZsRQmQ4KY522qY364ZocLVqGpfn4uZvH7y7IrxOQux9xtZkm/fE=
X-Received: by 2002:aca:ac84:: with SMTP id
v126-v6mr1411712oie.176.1528792830334;
Tue, 12 Jun 2018 01:40:30 -0700 (PDT)
MIME-Version: 1.0
References: <fd403450-cf7f-ce56-79ca-93c77c042289@frankentrikes.com>
<0cc0a7249708ad26a7cbef702370b234.squirrel@boosthardware.com>
In-Reply-To: <0cc0a7249708ad26a7cbef702370b234.squirrel@boosthardware.com>
From: Kulpreet Singh <zapfmann@gmail.com>
Date: Tue, 12 Jun 2018 10:40:18 +0200
Message-ID: <CAN8S4uarZ39BqpmZQqqoof6nDXH7eSuH1rT03ABX2x-Gzc9sXg@mail.gmail.com>
To: Patrick Shirkey <pshirkey@boosthardware.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000967183056e6dd11b"
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: Wed, 13 Jun 2018 12:17:54 +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: Tue, 12 Jun 2018 08:40:32 -0000
--000000000000967183056e6dd11b
Content-Type: text/plain; charset="UTF-8"
Apologies for a noob question.
But if I understand correctly, lightning nodes need to check if a
counterparty is broadcasting an old channel state and in response broadcast
a penalty/justice transaction. Does that mean lightning nodes only need to
watch for transactions that come after the funding transaction? Is that the
only reason lightning needs to run bitcoind with txindex?
If that is the case, and a lightning node only needs to query transactions
broadcast after the funding transaction, then a pruned bitcoind instance
with txindex might be a bit handy.
Also from [1] it seems that indexing pruned nodes is not supported because
it doesn't make sense, not that it was infeasible. Now with the lightning
requirements, does an indexed pruned node start to make sense?
Once again, please forgive my naive understanding of some of the issues
involved and thanks for your patience.
Regards
Kulpreet
[1]
https://bitcoin.stackexchange.com/questions/52889/bitcoin-core-txindex-vs-default-mode-vs-pruned-mode-in-depth#52894
On Thu, 10 May 2018, 14:47 Patrick Shirkey 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 :).
> >
>
> You can already use the "prune" flag to get a snapshot of the blockchain
> but it is incompatible with "txindex" and "rescan" so maybe that is and
> issue for lightning nodes?
>
>
>
>
> --
> Patrick Shirkey
> Boost Hardware
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000967183056e6dd11b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Apologies for a noob question.<div><br></div><div>But if I=
understand correctly, lightning nodes need to check if a counterparty is b=
roadcasting an old channel state and in response broadcast a penalty/justic=
e transaction. Does that mean lightning nodes only need to watch for transa=
ctions that come after the funding transaction? Is that the only reason lig=
htning needs to run bitcoind with txindex?<div><br></div><div>If that is th=
e case, and a lightning node only needs to query transactions broadcast aft=
er the funding transaction, then a pruned bitcoind instance with txindex mi=
ght be a bit handy.</div><div><br></div><div>Also from [1] it seems that in=
dexing pruned nodes is not supported because it doesn't make sense, not=
that it was infeasible. Now with the lightning requirements, does an index=
ed pruned node start to make sense?</div><div><br></div><div>Once again, pl=
ease forgive my naive understanding of some of the issues involved and than=
ks for your patience.</div><div><br></div><div>Regards</div><div>Kulpreet</=
div><div><br></div><div>[1] <a href=3D"https://bitcoin.stackexchange.com/qu=
estions/52889/bitcoin-core-txindex-vs-default-mode-vs-pruned-mode-in-depth#=
52894">https://bitcoin.stackexchange.com/questions/52889/bitcoin-core-txind=
ex-vs-default-mode-vs-pruned-mode-in-depth#52894</a></div><div><br><br><div=
class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 10 May 2018, 14:47 Patrick =
Shirkey via bitcoin-dev, <<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 3/17/18, someone posted on the Lightning-dev list, "Can I try<=
br>
> Lightning without running a fully-fledged bitcoin block chain? (Yubin<=
br>
> Ruan)."=C2=A0 The inquirer was asking because he didn't have =
much space to<br>
> store the entire blockchain on his laptop.<br>
><br>
> I replied:<br>
><br>
> "Developers,<br>
><br>
> On THIS note and slightly off-topic but relevant, why can't chunks=
of<br>
> blockchain peel off the backend periodically and be archived, say on<b=
r>
> minimum of 150 computers across 7 continents?<br>
><br>
> It seems crazy to continue adding on to an increasingly long chain to<=
br>
> infinity if the old chapters (i.e. more than, say, 2 years old) could =
be<br>
> stored in an evenly distributed manner across the planet. The same 150=
<br>
> computers would not need to store every chapter either, just the index=
<br>
> would need to be widely distributed in order to reconnect with a chapt=
er<br>
> if needed. Then maybe it is no longer a limitation in the future for<b=
r>
> people like Yubin. "<br>
><br>
> It was suggested by a couple of lightning developers that I post this<=
br>
> idea on the bitcoin-dev list.=C2=A0 So, here I post :).<br>
><br>
<br>
You can already use the "prune" flag to get a snapshot of the blo=
ckchain<br>
but it is incompatible with "txindex" and "rescan" so m=
aybe that is and<br>
issue for lightning nodes?<br>
<br>
<br>
<br>
<br>
-- <br>
Patrick Shirkey<br>
Boost Hardware<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div></div>
--000000000000967183056e6dd11b--
|
