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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <joseph@lightning.network>) id 1YqVZk-0006Zb-IS
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 23:51:32 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of
lightning.network designates 209.85.192.48 as permitted sender)
client-ip=209.85.192.48; envelope-from=joseph@lightning.network;
helo=mail-qg0-f48.google.com;
Received: from mail-qg0-f48.google.com ([209.85.192.48])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqVZj-0007PA-LF
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 23:51:32 +0000
Received: by qgej70 with SMTP id j70so29246255qge.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 16:51:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to;
bh=nDyxq9dB8df7Tr7pXYYtfX5JdE+zy9bpTUOjNLttmwI=;
b=WKWLJHGT1Qux9Xl4NCYzoaUehW+eB7Fua06X5D8GFutSE2lgCsAxqqgcaHURkOdoNW
4NeFtAZQk6MwBL0rmyPelaROSGQ4vk6+w2RWv+/fCpKZk39QmU/c8Qp0BHEC6ZrtzdK6
T5NWTx331UPe1xnysS5x5+xGciw9rPapRYrJygWRlyqpKDmkq9krpsXtLDUC9yvV/3VT
a3ZkeK1eLuZjoZulASWulnT4t5bmT1MJNrQQkQGUZOLTYElQrtiebYdVEstw9+fluP1K
nqG4eVscw3kVsjl+xWED5BHlOtp6H6uNtohMFqrS1EI9KEqV4GKrOuhhf8usuZ/dD4/g
N0NQ==
X-Gm-Message-State: ALoCoQmfL9PcxWgWqorTw/DPzDni+UsrPaFO1a6Of22uFwWVvBlw2Q3s6VuNwtwIV65WPMTPyp8V
X-Received: by 10.55.48.16 with SMTP id w16mr2405774qkw.13.1431041101989;
Thu, 07 May 2015 16:25:01 -0700 (PDT)
Received: from localhost (bolobolo2.torservers.net. [96.47.226.21])
by mx.google.com with ESMTPSA id p35sm2477309qgp.1.2015.05.07.16.25.00
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 07 May 2015 16:25:01 -0700 (PDT)
Date: Thu, 7 May 2015 16:24:35 -0700
From: Joseph Poon <joseph@lightning.network>
To: Matt Corallo <bitcoin-list@bluematt.me>
Message-ID: <20150507232435.GA3550@lightning.network>
References: <554BE0E1.5030001@bluematt.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <554BE0E1.5030001@bluematt.me>
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YqVZj-0007PA-LF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 23:51:32 -0000
Hi Matt,
I agree that starting discussion on how to approach this problem is
necessary and it's difficult taking positions without details on what is
being discussed.
A simple hard 20-megabyte increase will likely create perverse
incentives, perhaps a method can exist with some safe transition. I
think ultimately, the underlying tension with this discussion is about
the relative power of miners. Any transition of blocksize increase will
increase the influence of miners, and it is about understanding the
tradeoffs for each possible approach.
On Thu, May 07, 2015 at 10:02:09PM +0000, Matt Corallo wrote:
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
I think the long-term fee incentive structure needs to be significantly
more granular. We've all seen miners and pools take the path of least
resistance; often they just do whatever the community tells them to
blindly. While this status quo can change in the future, I think
designing sane defaults is a good path for any possible transition.
It seems especially reasonable to maintain fee pressure for normal
transactions during a hard-fork transition. It's possible to do so using
some kind of soft-cap structure. Building in a default soft-cap of 1
megabyte for some far future scheduled fork would seem like a sane thing
to do for bitcoin-core.
It seems also viable to be far more aggressive. What's your (and the
community's) opinion on some kind of coinbase voting protocol for
soft-cap enforcement? It's possible to write in messages to the coinbase
for a enforcible soft-cap that orphans out any transaction which
violates these rules. It seems safest to have the transition has the
first hardforked block be above 1MB, however, the next block default to
an enforced 1MB block. If miners agree to go above this, they must vote
in their coinbase to do so.
There's a separate discussion about this starting on:
CAE-z3OXnjayLUeHBU0hdwU5pKrJ6fpj7YPtGBMQ7hKXG3Sj6hw@mail.gmail.com
I think defaulting some kind of mechanism on reading the coinbase seems
to be a good idea, I think left alone, miners may not do so. That way,
it's possible to have your cake and eat it too, fee pressure will still
exist, while block sizes can increase (provided it's in the miners'
greater interests to do so).
The Lightning Network's security model in the long-term may rely on a
multi-tier soft-cap, but I'm not sure. If 2nd order systemic miner
incentives were not a concern, a system which has an enforced soft-cap
and permits breaching that soft-cap with some agreed upon much higher
fee would work best. LN works without this, but it seems to be more
secure if some kind of miner consensus rule is reached regarding
prioritizing behavior of 2nd-layer consensus states.
No matter how it's done, certain aspects of the security model of
something like Lightning is reliant upon having block-space
availability for transactions to enter into the blockchain in a timely
manner (since "deprecated" channel states become valid again after some
agreed upon block-time).
I think pretty much everyone agrees that the 1MB block cap will
eventually be a problem. While people may disagree with when that will
be and how it'll play out, I think we're all in agreement that
discussion about it is a good idea, especially when it comes to
resolving blocking concerns.
Starting a discussion on how a hypothetical blocksize increase will
occur and the necessary blocking/want-to-have features/tradeoffs seems
to be a great way to approach this problem. The needs for Lightning
Network may be best optimized by being able to prioritizing a large mass
of timeout transactions at once (when a well-connected node stops
communicating).
--
Joseph Poon
|
