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
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
|
Return-Path: <dstadulis@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CFBF2258
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 03:36:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com
[209.85.223.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C58AF79
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 03:36:19 +0000 (UTC)
Received: by iow1 with SMTP id 1so77332363iow.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Oct 2015 20:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=Vrup2elBMeasoF/VLxXWSLc1aaYZ5yjiL3MizMSLMuA=;
b=LqEdyirX4a6AeQqeARfysO6wySTF/xHGilZk/5EarD+Br2LzStnV327oc2dkbOY7gP
SCw3WMnFwGw1yfWHszqpi4WC0YjFKLC+YzWX8B+uYjCixEH2/xRWp7/NsAYGKcFNDLmc
506SqtLr6WPoUlA8N8oeRp2PMIFUSIj6Ki5OKcACON328TIYoq9/mWVBdv3Fv7G6wmgv
vLepnyUC0ljDPKhUmvw2YlZ5ooXa19PSrGlHpqc3ebofJC3vs01Pc9N6qPz78dnuseO5
Eu8yE6KNBYxjRFUAh1EVUOcq0/+/gcJtYBpFEhnsiNOl72CfP+FrjltnkR+YdeQBzKIO
iovA==
X-Received: by 10.107.157.80 with SMTP id g77mr7227395ioe.118.1444880179224;
Wed, 14 Oct 2015 20:36:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.30.210 with HTTP; Wed, 14 Oct 2015 20:35:59 -0700 (PDT)
In-Reply-To: <CABaSBazTE5r5Xvw8M3DRF+d-Qd6KXbdW8W1E0DPmw5KzfY1j6w@mail.gmail.com>
References: <561E2B09.3090509@sky-ip.org> <561E7283.2080507@gmail.com>
<CABaSBazTE5r5Xvw8M3DRF+d-Qd6KXbdW8W1E0DPmw5KzfY1j6w@mail.gmail.com>
From: Daniel Stadulis <dstadulis@gmail.com>
Date: Wed, 14 Oct 2015 20:35:59 -0700
Message-ID: <CAHpxFbG2AKsg=SAx_CL2mcJYzOXsZN4iodROLWBEjrXQ8zxFpg@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=001a11407d66d364d605221c616f
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Lightning Network's effect on 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: Thu, 15 Oct 2015 03:36:20 -0000
--001a11407d66d364d605221c616f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It makes economic sense to include a transaction on the Lightning Network,
iff the the fee to include the transaction on the blockchain is more than
than the Time Value of Money of the encumbered funds on the Lightening
Nodes amortized across the number of users pushing funds through a LN node.
Large-value transactions are going to hit the blockchain while smaller,
predictable, closer-to-median transaction-rates transactions will go into
the Lightning Network
Blockchain: Car Purchase, House Purchase, Unexpected Medical Expense
Lightning Network: Utility Bill, Groceries, Rent, Mortgage.
> If transactions happen in a big percent offchain, and they are only
> broadcasted on the mainchain where funds are moved in or out of the
> lightning network, this means there will be less transactions on the
> mainchain
This is optimal because the network has minimized the set of
costs/externalities to the minimum necessary to conduct a series of
transactions
> -> less fees collected by the miners.
=E2=80=9CIt's tough to make predictions, especially about the future.=E2=80=
=9D
The effect on fees is going to be hard to predict.
1.) One part depends on user behavior around the dynamics of bid-side
demand of fees. I.e. If there is a health ratio of
-users who want 1-block- times but are unwilling/unable to bid up the fee
of their transactions to push out other 1-block-confirmation transactions (=
AKA
how firm is that fee support presently and under dynamic conditions)
to
-users who take their transactions off the blockchain to LN
2.) New classes of transactions will be possible that aren't possible today=
.
3.) What market effect will the financial/technical potential of 'instant'
transaction (after a network-joining-intro period) have on Bitcoin's
utility/price/adoption?
It would be elucidating if any blockchain data scientists could study the
effect of the fee market when high-volume exchanges unexpectedly halted
trading.
> What will happen when the block reward will go away?
I believe a more specific question to ask is: What will happen when there
isn't a convincing economic reason for a large majority of hashing power to
be bolstering PoW defense on the main blockchain? Right now we have a
pretty good handle on the amount of hashing power that's pointed at
extending/defending the 'main' chain but don't have as good intel on how
much idle hashing power there is. Idle hashing power becomes more of a
threat in market scenarios where chain-extending PoW is scarce (late-game
Bitcoin).
My humble prediction is that the necessary number of block confirmation
will go up and there were be non negligible mining power idle ready to
defend actors' preferred chain. If this is the scenario that plays out, I
don't think it'll be very concerning; large-value transaction that will be
on the blockchain have more flexible time-settlement tolerance (no one
needs their home-buying escrow to settle in <=3D 1 day) and lower-value
transaction that users want/need to be confirmed quickly will be confirmed
'instantly' over Lightning Network or another Bitcoin-anchored protocol.
P.S. I see lots of concern with respect to fee reduction directed at LN
while today there are already off-chain databases that remove fee
pressure. Like the LN / off-chain databases or not, they will exists.
Daniel Stadulis
On Wed, Oct 14, 2015 at 8:37 AM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Oct 14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > However, the two are also perfect compliments, as LN transactions canno=
t
> take place at all without periodic on-chain transactions.
>
> Additionally, lightning network hot wallets are not an ideal place to
> store large quantities of BTC and users that don't expect to be
> actively using LN should in general prefer confirmed UTXOs for
> long-term cold storage. So far the guess that I have seen floating
> around is that LN usage will at first be restricted to very tiny
> amounts of BTC in tiny hot wallets, since nobody is particularly
> interested in running large hot wallets.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11407d66d364d605221c616f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>It makes economic sense to include a transaction on t=
he Lightning Network, iff the the fee to include the transaction on the blo=
ckchain is more than than the Time Value of Money of the encumbered funds o=
n the Lightening Nodes amortized across the number of users pushing funds t=
hrough a LN node.</div><div><br></div><div>Large-value transactions are goi=
ng to hit the blockchain while smaller, predictable, closer-to-median trans=
action-rates transactions will go into the Lightning Network</div><div><br>=
</div><div>Blockchain: Car Purchase, House Purchase, Unexpected Medical Exp=
ense</div><div>Lightning Network: Utility Bill, Groceries, Rent, Mortgage.<=
/div><div><br></div><div><span style=3D"font-size:12.8px">> If transacti=
ons happen in a big percent offchain, and they are only</span><br style=3D"=
font-size:12.8px"><span style=3D"font-size:12.8px">>=C2=A0</span><span s=
tyle=3D"font-size:12.8px">broadcasted on the mainchain where funds are move=
d in or out of the</span><br style=3D"font-size:12.8px"><span style=3D"font=
-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">lightning n=
etwork, this means there will be less transactions on the</span><br style=
=3D"font-size:12.8px"><span style=3D"font-size:12.8px">>=C2=A0</span><sp=
an style=3D"font-size:12.8px">mainchain</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">This =
is=C2=A0optimal=C2=A0because the network has minimized the set of costs/ext=
ernalities to the minimum necessary to conduct a series of transactions</sp=
an></div><div><span style=3D"font-size:12.8px">></span><span style=3D"fo=
nt-size:12.8px">=C2=A0</span><span style=3D"font-size:12.8px">=C2=A0-> l=
ess fees collected by the miners.</span></div><div><span style=3D"font-size=
:12.8px">=E2=80=9CIt's tough to make predictions, especially about the =
future.=E2=80=9D</span><br></div><div><span style=3D"font-size:12.8px">The =
effect on fees is going to be hard to predict. =C2=A0</span></div><div><spa=
n style=3D"font-size:12.8px">1.) One part depends on user behavior around t=
he dynamics of bid-side demand of fees. I.e. If there is a health ratio of=
=C2=A0</span></div><div><span style=3D"font-size:12.8px">-</span><span styl=
e=3D"font-size:12.8px">users=C2=A0</span><span style=3D"font-size:12.8px">w=
ho want 1-block- times but are unwilling/unable to bid up the fee of their =
transactions to push out other 1-block-confirmation transactions (</span><s=
pan style=3D"font-size:12.8px">AKA how firm is that fee support presently a=
nd under dynamic conditions)</span></div><div><span style=3D"font-size:12.8=
px">to</span></div><div><span style=3D"font-size:12.8px">-users who take th=
eir transactions off the blockchain to LN</span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">2.)=
New classes of transactions will be possible that aren't possible toda=
y.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px">3.) What market effect will the financial/=
technical potential of 'instant' transaction (after a network-joini=
ng-intro period) have on Bitcoin's utility/price/adoption?</span></div>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px">It would be=C2=A0elucidating=C2=A0if any blockchain data =
scientists could study the effect of the fee market when high-volume exchan=
ges=C2=A0unexpectedly halted trading.</span></div><div><span style=3D"font-=
size:12.8px"><br></span></div><div><br></div><div><span style=3D"font-size:=
12.8px">></span><span style=3D"font-size:12.8px">=C2=A0What will happen =
when=C2=A0</span><span style=3D"font-size:12.8px">the block reward will go =
away?=C2=A0</span></div><div><span style=3D"font-size:12.8px">I believe a m=
ore specific question to ask is: What will happen when there isn't a co=
nvincing economic reason for a large majority of hashing power to be bolste=
ring PoW defense on the main blockchain?=C2=A0 Right now we have a pretty g=
ood handle on the amount of hashing power that's pointed at extending/d=
efending the 'main' chain but don't have as good intel on how m=
uch idle hashing power there is.=C2=A0 Idle hashing power becomes more of a=
threat in market scenarios where chain-extending=C2=A0PoW is=C2=A0scarce (=
late-game Bitcoin).</span></div><div><span style=3D"font-size:12.8px"><br><=
/span></div><div><span style=3D"font-size:12.8px">My humble prediction is t=
hat the necessary number of block confirmation will go up and there were be=
non negligible=C2=A0mining power=C2=A0idle ready to defend actors' pre=
ferred chain.=C2=A0 If this is the scenario that plays out, I don't thi=
nk it'll be very concerning; =C2=A0large-value transaction that will be=
on the blockchain have more flexible time-settlement tolerance (no one nee=
ds their home-buying escrow to settle in <=3D 1 day) and lower-value tra=
nsaction that users want/need to be confirmed quickly will be confirmed =
9;instantly' over Lightning Network or another Bitcoin-anchored protoco=
l.</span></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">P.S. I see lots of concern with respect to fee reduction directed at LN=
while today there are already off-chain databases that remove fee pressure=
.=C2=A0 Like the LN / off-chain databases or not, they will exists.<br></di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Daniel St=
adulis</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Wed, Oct 14, 2015 at 8:37 AM, Bryan Bish=
op via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><span class=3D"">On Wed, Oct =
14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> However, the two are also perfect compliments, as LN transactions cann=
ot take place at all without periodic on-chain transactions.<br>
<br>
</span>Additionally, lightning network hot wallets are not an ideal place t=
o<br>
store large quantities of BTC and users that don't expect to be<br>
actively using LN should in general prefer confirmed UTXOs for<br>
long-term cold storage. So far the guess that I have seen floating<br>
around is that LN usage will at first be restricted to very tiny<br>
amounts of BTC in tiny hot wallets, since nobody is particularly<br>
interested in running large hot wallets.<br>
<br>
- Bryan<br>
<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:=
//heybryan.org/</a><br>
<a href=3D"tel:1%20512%20203%200507" value=3D"+15122030507">1 512 203 0507<=
/a><br>
<div class=3D""><div class=3D"h5">_________________________________________=
______<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
</div></div></blockquote></div><br></div></div>
--001a11407d66d364d605221c616f--
|
