summaryrefslogtreecommitdiff
path: root/b6/00e3d7762a72206c4be9594afa10fb1f3a4bcf
blob: 21f79bf83acc223a707d48c5a0597176022d3d19 (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
182
183
184
185
186
187
188
189
Return-Path: <anthony.j.towns@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CDCC43EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 18:50:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
	[209.85.212.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C84DF1A4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 18:50:34 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so37941985wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 11:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=XEb88SS5KNRU544hu31591gX7NzMQjwnKdMXflqMgGQ=;
	b=lf1kCzaqTF10u9Nj4ZU1pzikIPkuo1PEe8LkfuzrzHHmAv6QIlMpOBsKYoGc3q2vhG
	5HH4jlIhN9ksv/As8lxcveKL+2iF3BG43lfO2SRF+Y6Fmaz5TH9CWgCKhPPlJyrzJ+tm
	pro6MGeaAfdo+ethIRd/ZCTavRaZoqguWv/8ckJWumF61UHx4crncDJBln5lcydZKDtK
	deYQNLLbXF0we8yKJjELPROeBfisVILDFYWXQL013jKKILJ7vFuUxQFJfRDPURMIjctH
	ZSKcAIaozyS5SLL3q+ozzeWGHlzwE3CahTe7ujGmwEt47JRi8SVG7/manV8ryw6gaabg
	0/Ww==
X-Received: by 10.180.75.78 with SMTP id a14mr27339967wiw.43.1439232633374;
	Mon, 10 Aug 2015 11:50:33 -0700 (PDT)
Received: from erisian.com.au ([141.70.72.177])
	by smtp.gmail.com with ESMTPSA id
	uo6sm30730919wjc.1.2015.08.10.11.50.31
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 10 Aug 2015 11:50:32 -0700 (PDT)
Sender: Anthony Towns <anthony.j.towns@gmail.com>
Received: by erisian.com.au (sSMTP sendmail emulation);
	Tue, 11 Aug 2015 02:50:31 +0800
Date: Tue, 11 Aug 2015 02:50:31 +0800
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20150810185031.GA31610@navy>
References: <55C7D234.1040306@bitmarkets.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <55C7D234.1040306@bitmarkets.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, LOTS_OF_MONEY,
	RCVD_IN_DNSWL_LOW 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] Off-chain transactions and miner fees
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Mon, 10 Aug 2015 18:50:35 -0000

On Mon, Aug 10, 2015 at 12:20:36AM +0200, info--- via bitcoin-dev wrote:
> one argument I often read on this mailing list is that it's essential to
> reward miners with transaction fees at some point to secure the network.

That's not a universally held belief. See for example:

 https://en.bitcoin.it/wiki/Funding_network_security#Alternatives
 https://bitcointalk.org/index.php?topic=157141.0

It's also not clear to me what amount of security people actually "want".
In late May, Mike Hearn wrote:

 "Currently the Bitcoin community is being effectively taxed about
  $832,000 per day ... just to support mining! [...]

  We’re not spending so much on mining because we really need it. It’s
  because printing money distorts behaviour."

  -- https://medium.com/@octskyward/hashing-7d04a887acc8

If $832k (25*240 btc/day * $231 USD/btc) is too much, maybe $475k/day
(reward halved, at current price) will still be too much in a year's
time? If bitcoin's price rises at just 19% pa on average (which doesn't
seem like much if you're thinking in startup/VC terms?), then the block
reward will still be worth about $475k/day after it halves again to 6.25
coins per block. So maybe the block reward pays for bitcoin transactions
and fees are effectively zero right up until the day the block reward
goes away entirely?

In any event, the lightning network offers three potential benefits over
on-chain transactions:

 - lower fees
 - shorter confirmation times
 - no ongoing costs once the channel is closed

If you have zero fees, lightning is still interesting for quick
transactions (since they offer better assurance of payment than
zero-confirmation transactions), and also for microtransactions (where
spamming the blockchain and the UTXO db with thousands of transactions
just to move $1 from here to there isn't appealing).

> Off-chain transactions, whether it's Lightning or something else,
> potentially extract fees, which may otherwise be paid to miners, if the
> transactions were actually on-chain.

Every lightning transaction happens through a series of channels (at least
one, but realistically at least two; with any amount of decentralisation,
probably more likely somewhere in the range of three to twenty). Each
of those channels requires at least two blockchain transactions (one or
two to create the channel; one or three to close the channel and spend
the balances).

It's not 100% clear at this point, but keeping a lightning channel open
will probably have (hardware) costs that grow linearly in the number of
transactions [0]; in which case keeping them open forever won't be an
option, and they'll be closed when the cost of keeping it open is less
than the cost of resetting it on the blockchain (only one blockchain
transaction required). So in that case even if lightning is crazy popular,
there'll still be activity on the blockchain at whatever fee rate there
is, just by people trading off storage costs for blockchain fees.

[0] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000057.html

Even if it's not the case, closing a channel eventually is probably
good practice in order to rollover keys. Channels also have a maximum
theoretical number of transactions, but that's likely on the order
of exa-transactions, so is probably irrelevant. Channel profitability
likely varies over time, and since channels lock up bitcoin, closing
less profitable channels so the funds can be used elsewhere is likely
also valuable. 

With all those things together, ballpark max lifetime of a random channel
(IMHO) is somewhere in the range of two weeks to two years. If lightning
is the only thing doing transactions on the blockchain and only using
250B/txn, 8M channels with an average lifetime of 2 weeks would fill
1MB blocks; as would 210M channels with an average lifetime of a year,
or 420M channels with an average lifetime of two years. Those sort
of numbers probably roughly cover lots of Americans having access to
a lightning based point-of-sale network to buy Starbucks, eg, but not
much more than that. (You need at least one channel per customer, plus
one per business, plus something on the order of log(N) hubs to connect
them all; having multiple channels is probably about as good an idea as
having multiple credit cards).

> In this context, wouldn't it be contradictory, maybe even harmful, to
> aim for an environment, where some/many/most transactions are off-chain?

Lightning transactions will have to pay for several things:

 - the blockchain fees for opening/closing the channel
 - the time value of the funds being used to keep the channels open,
   for each channel in the route from payer to payee
 - the maintenance costs of the hardware/software to run a lightning
   channel

By contrast, blockchain transactions just have to pay miners the
blockchain fee for the transaction; there's no other intermediaries
who have to be compensated. At some point, the latter will certainly
be cheaper than the former -- since the lightning network has to pay
for third parties' time value of bitcoin there should certainly be some
"sufficiently large" amount whose time value is higher than the bitcoin
txn fee, even for a very short txn time.

It's all a bit hypothetical though -- not only is lightning still
unimplemented as yet, but I think at present the time value of bitcoin is
effectively zero (ie, afaik people recommend "just buy and hold bitcoin
and wait for the next bubble", rather than "buy bitcoin and put it in
AwesomeBank's Term Deposit product and gain 3% pa"), and most of the
time fees seem to be basically zero too.

I think the general answer is that lightning relies on the blockchain --
if the blockchain doesn't work, neither does lightning. So whatever level
of txn fees it takes to make the blockchain work; whether that's $0/txn,
1c/txn or $50/txn, nodes in the lightning network will pay that fee,
and, presumably, pass it on to the lightning network's end users in the
form of txn fees on the lightning network.

Cheers,
aj