path: root/1c/ee377139ba413d047d5f0cf707b1e72796a12c

Return-Path: <brianlockhart@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D37A5D69
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Jun 2018 15:32:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com
	[74.125.82.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 21586466
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Jun 2018 15:32:14 +0000 (UTC)
Received: by mail-ot0-f178.google.com with SMTP id 101-v6so3446559oth.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Jun 2018 08:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:in-reply-to:references:mime-version:date:message-id:subject:to; 
	bh=u+RVc3ii9P1rLIZHAllXe0EdxcySYxASvxvoiu5wOE0=;
	b=ZLLr/spKra7cBxePG5UfNb/7oBfjSQq3cf2dcDuJ8PoPTRHsPXPIwxA3tSQ+XDVN2v
	z8PwbZJriebuFmzqJcbcsSa+6UiKJPmGZqYQI8egfqDVNu7lxf2kxsptUV0NqPx3I2TY
	jCStstIizYjKHMu3l24TYqQ5HsEVnBBNZARsTqVK4N6fXqaCQQdaPT6PWaMDTsBc//Ts
	A8bHGJrYLu8ZYozVhnjdchREEDElSvTqej5dH9kuU+0ujuKrqPQ+eWT/+cdZI2fICBRl
	xR2O38uV0WPfOTZY2LNjBcO5OQR1sl/vW5clYElrVA08qIKD87kRy0codDQ7GzZKVSDb
	YOjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:in-reply-to:references:mime-version:date
	:message-id:subject:to;
	bh=u+RVc3ii9P1rLIZHAllXe0EdxcySYxASvxvoiu5wOE0=;
	b=KRiOc2tdXM2AkZ7GxQIpTJAul5uoIwIwM0GiKdFbff9lQTmz55X5DP0CNRFW+tOwzv
	sSEi9yRdqpVy+afw+ZVRESmyuc+ZE/B2mTJCk3PjUTJ0ISvhVcK2HtxEkGbpqY7x+fVE
	xChyIKIjw7qpwiAf5+yQox5Lzwn/1XKT7NK9OWPyxQX3RdsgzW0GizGmWY+ZthP1zLLK
	KfMwNjDLtpPBqYSV/7rsWzHWTDTqr0+uKEmZWL8TI4OlYDxtJpA5tKaI4aRiDnHse7M6
	QdLWPquBxTWzHhexvX/RZ4oX6OjTYtxhSXaAe1VEhCENAekpkY6hmKZNUb/4yjmNQNOO
	5fMg==
X-Gm-Message-State: APt69E2gGQGIH+Qnw9zhIyA+hfU6g/e7b7q+/pwbGrinwvGgy4BeBkh1
	hOc6Pws03UbUCVMsEhRZrfEkcAqcflNtqc7aCM0=
X-Google-Smtp-Source: ADUXVKLTbiaIMBI75+2D1XJbdEmO/dZP3Wb6dk2iU9DN+fZk/AQ28NOatgjBnP3ZP9CpavgqHPC2h0m+q4XTwjo8cLE=
X-Received: by 2002:a9d:5774:: with SMTP id
	x49-v6mr3207892oti.50.1528903933182; 
	Wed, 13 Jun 2018 08:32:13 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with
	HTTPREST; Wed, 13 Jun 2018 08:32:11 -0700
From: Brian Lockhart <brianlockhart@gmail.com>
In-Reply-To: <87fu1qdd5e.fsf@gmail.com>
References: <fd403450-cf7f-ce56-79ca-93c77c042289@frankentrikes.com>
	<0cc0a7249708ad26a7cbef702370b234.squirrel@boosthardware.com>
	<CAN8S4uarZ39BqpmZQqqoof6nDXH7eSuH1rT03ABX2x-Gzc9sXg@mail.gmail.com>
	<87fu1qdd5e.fsf@gmail.com>
X-Mailer: Airmail (481)
MIME-Version: 1.0
Date: Wed, 13 Jun 2018 08:32:11 -0700
Message-ID: <CAJQ0i9v0T8w4LD13z9AePtgnMdiG7=1pjMFWVXTnCFRVB1bwpw@mail.gmail.com>
To: Kulpreet Singh <zapfmann@gmail.com>,
	Christian Decker <decker.christian@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
	Patrick Shirkey <pshirkey@boosthardware.com>
Content-Type: multipart/alternative; boundary="000000000000d54900056e87afe8"
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, 
	UNPARSEABLE_RELAY 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 15:55:29 +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: Wed, 13 Jun 2018 15:32:14 -0000

--000000000000d54900056e87afe8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Somewhat related question -

In the interest of avoiding running multiple bitcoind full nodes - is there
a method to allow a Lightning node to point to / access a separate
already-existing node, vs. requiring it to have its own dedicated local
instance of bitcoind running?

I.e. if I already have a full bitcoin node running, could I use RPC calls
or something to tell my Lightning node to use that node, instead of
spinning up *another* full node? I=E2=80=99m currently minimizing the netwo=
rk
thrashing by whitelisting my LN bitcoind node to only point to my existing
full node for updates, but if I could just point my whole LN node at it,
that=E2=80=99s save on disk storage etc. etc. etc.


Apologies if this is already in there (or has been added) and I missed it
because I haven=E2=80=99t kept up with release notes=E2=80=A6




On June 13, 2018 at 6:35:49 AM, Christian Decker via bitcoin-dev (
bitcoin-dev@lists.linuxfoundation.org) wrote:

Kulpreet Singh via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> 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?

Yes, Lightning nodes need to monitor the network for transactions that
they need to react to. This is basically tailing the blockchain and
looking for anything suspicious. The `bitcoind` sitting next to the
lightning node however does not need to keep an index of the
transactions, at least for c-lightning, because we just ask for the full
block that then gets scanned for transactions of interest and then we
discard the rest of the block. We never ask for a specific transaction
from `bitcoind` and therefore we don't need to run 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.

Pruned nodes should work, as long as the current blockchain head that
the lightning node has seen does not fall into the pruned range, since
in that case it won't be able to fetch and process the blocks anymore.

> 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?

I don't think we should ever require `-txindex` to run a lightning node
(I know some implementations did in the past), since that'd be a very
onerous requirement to run a lightning node. Tailing the blockchain is
more than sufficient to get the necessary data, and hopefully we can get
our reliance on `bitcoind` down to a minimum in the future.

> Once again, please forgive my naive understanding of some of the issues
> involved and thanks for your patience.

Absolutely no problem, it is a common misconception that `-txindex` is
required to run a lightning node in all cases :-)

Cheers,
Christian
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style>=
</head><body style=3D"word-wrap:break-word;line-break:after-white-space"><d=
iv id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:1=
3px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Somewhat related que=
stion -=C2=A0</div><div id=3D"bloop_customfont" style=3D"font-family:Helvet=
ica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"=
><br></div><div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Aria=
l;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">In the =
interest of avoiding running multiple bitcoind full nodes - is there a meth=
od to allow a Lightning node to point to / access a separate already-existi=
ng node, vs. requiring it to have its own dedicated local instance of bitco=
ind running?</div><div id=3D"bloop_customfont" style=3D"font-family:Helveti=
ca,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">=
<br></div><div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial=
;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I.e. if =
I already have a full bitcoin node running, could I use RPC calls or someth=
ing to tell my Lightning node to use that node, instead of spinning up *ano=
ther* full node? I=E2=80=99m currently minimizing the network thrashing by =
whitelisting my LN bitcoind node to only point to my existing full node for=
 updates, but if I could just point my whole LN node at it, that=E2=80=99s =
save on disk storage etc. etc. etc.</div><div id=3D"bloop_customfont" style=
=3D"font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin=
:0px;line-height:auto"><br></div><div id=3D"bloop_customfont" style=3D"font=
-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;lin=
e-height:auto"><br></div><div id=3D"bloop_customfont" style=3D"font-family:=
Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height=
:auto">Apologies if this is already in there (or has been added) and I miss=
ed it because I haven=E2=80=99t kept up with release notes=E2=80=A6</div><d=
iv id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:1=
3px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id=3D=
"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:13px;colo=
r:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id=3D"b=
loop_sign_1528903494644296192" class=3D"bloop_sign"></div> <br><p class=3D"=
airmail_on">On June 13, 2018 at 6:35:49 AM, Christian Decker via bitcoin-de=
v (<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>) wrote:</p> <blockquote type=3D"cite" class=3D"c=
lean_bq"><span><div><div></div><div>Kulpreet Singh via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt;
<br>writes:
<br>&gt; But if I understand correctly, lightning nodes need to check if a
<br>&gt; counterparty is broadcasting an old channel state and in response
<br>&gt; broadcast a penalty/justice transaction. Does that mean lightning
<br>&gt; nodes only need to watch for transactions that come after the fund=
ing
<br>&gt; transaction? Is that the only reason lightning needs to run bitcoi=
nd
<br>&gt; with txindex?
<br>
<br>Yes, Lightning nodes need to monitor the network for transactions that
<br>they need to react to. This is basically tailing the blockchain and
<br>looking for anything suspicious. The `bitcoind` sitting next to the
<br>lightning node however does not need to keep an index of the
<br>transactions, at least for c-lightning, because we just ask for the ful=
l
<br>block that then gets scanned for transactions of interest and then we
<br>discard the rest of the block. We never ask for a specific transaction
<br>from `bitcoind` and therefore we don&#39;t need to run with `-txindex`.
<br>
<br>&gt; If that is the case, and a lightning node only needs to query
<br>&gt; transactions broadcast after the funding transaction, then a prune=
d
<br>&gt; bitcoind instance with txindex might be a bit handy.
<br>
<br>Pruned nodes should work, as long as the current blockchain head that
<br>the lightning node has seen does not fall into the pruned range, since
<br>in that case it won&#39;t be able to fetch and process the blocks anymo=
re.
<br>
<br>&gt; Also from [1] it seems that indexing pruned nodes is not supported
<br>&gt; because it doesn&#39;t make sense, not that it was infeasible. Now=
 with
<br>&gt; the lightning requirements, does an indexed pruned node start to m=
ake
<br>&gt; sense?
<br>
<br>I don&#39;t think we should ever require `-txindex` to run a lightning =
node
<br>(I know some implementations did in the past), since that&#39;d be a ve=
ry
<br>onerous requirement to run a lightning node. Tailing the blockchain is
<br>more than sufficient to get the necessary data, and hopefully we can ge=
t
<br>our reliance on `bitcoind` down to a minimum in the future.
<br>
<br>&gt; Once again, please forgive my naive understanding of some of the i=
ssues
<br>&gt; involved and thanks for your patience.
<br>
<br>Absolutely no problem, it is a common misconception that `-txindex` is
<br>required to run a lightning node in all cases :-)
<br>
<br>Cheers,
<br>Christian
<br>_______________________________________________
<br>bitcoin-dev mailing list
<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>
<br><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
<br></div></div></span></blockquote></body></html>

--000000000000d54900056e87afe8--