summaryrefslogtreecommitdiff
path: root/84/f05ee5266652c04b7b9e2035819ad9598185da
blob: 6b5cf6b7e9b72b77f3080ebe42463aa7b356d072 (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
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F6BBCF4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Jun 2018 13:33:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com
	[209.85.128.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9AB72748
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Jun 2018 13:33:48 +0000 (UTC)
Received: by mail-wr0-f169.google.com with SMTP id v13-v6so2767813wrp.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Jun 2018 06:33:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:to:subject:in-reply-to:references:date:message-id:mime-version; 
	bh=LCivLtuBbXWL4/JCoEy9Wm+6W4vqfqGtIb49mpiz50Q=;
	b=GcZO2DUo5eNwyxfb3PSQ7rYfvVcXU6q74MewfpbPXWTKILz8M8vCG+imFcBm5KfCrz
	gckEblwHFXwBqO3ALJdGJJj/xXmHpXo3XDqsAqxl9q9JAHf0tKHIk/xbpZOBp6bi3XdQ
	KNv7ZE7ncB+K/RH7cnKg323PTVaVZZe4jRzoUnXlfi0LUKdH2KApujmxoh89xwEte0rv
	0Gwc+YDlPQIlHLcNZz/y/WC6nV0iVs2dKXSeOl7kf3V6+D/0Mhf9SuKg8W1iBKUs1bQd
	NV6qNXK2mQ/6X2Tn8GkafpEb6aE2RJn4TmgURTdFtwJe9dYSJcPQ2PUZT2dArb6rcbHq
	JvTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:to:subject:in-reply-to:references:date
	:message-id:mime-version;
	bh=LCivLtuBbXWL4/JCoEy9Wm+6W4vqfqGtIb49mpiz50Q=;
	b=iEvZ2GxUYuG45NlFWP7b1R4fl/2Znv46OqdQ7znIC2nsY9wX/n/r637up6gg0xJ6VP
	NaPmqFP6Y6gX+cDj9uenzXQg0thBqHLByaNKTrkBtldAypbR005pqxKS+6+TPnpC2mlV
	AVJJHyvNgVgQEpndGGML5X2jEkZtdOvsNwK3Qm9yn54Rp+cOgVx/xn83yKPUvBkgYE3E
	7xArdDWdxytbEi6tEOrFBSv68GrREIPc9Uj3zOtyuiPssyRgYpn8rszQhTPUC8lHugq8
	GriF2fPKlFDpHRFfO6p0y/Sorsyu3/drVMVYgB0W8IrsfvTg2Br17iRg1qBU1oJ4b+21
	n6jg==
X-Gm-Message-State: APt69E281NiLZeUzh0HLJjQkUqmMpB6y9K/HYAz66inYoUuT56uAAZLV
	K/CiXwxFVKut5Woqd4Hxxj4=
X-Google-Smtp-Source: ADUXVKLmeDQsYfyYqpikYfy05Rn4Fgo6A0YjSJ0Sm2LuI0tgBsG0wZYVPXdAKThp8mps281OBcJ/PA==
X-Received: by 2002:adf:fd88:: with SMTP id
	d8-v6mr3991386wrr.276.1528896827256; 
	Wed, 13 Jun 2018 06:33:47 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
	by smtp.gmail.com with ESMTPSA id
	r75-v6sm3098126wmg.31.2018.06.13.06.33.45
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 13 Jun 2018 06:33:46 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Kulpreet Singh <zapfmann@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Patrick Shirkey <pshirkey@boosthardware.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAN8S4uarZ39BqpmZQqqoof6nDXH7eSuH1rT03ABX2x-Gzc9sXg@mail.gmail.com>
References: <fd403450-cf7f-ce56-79ca-93c77c042289@frankentrikes.com>
	<0cc0a7249708ad26a7cbef702370b234.squirrel@boosthardware.com>
	<CAN8S4uarZ39BqpmZQqqoof6nDXH7eSuH1rT03ABX2x-Gzc9sXg@mail.gmail.com>
Date: Wed, 13 Jun 2018 15:33:33 +0200
Message-ID: <87fu1qdd5e.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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
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 13:33:49 -0000

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