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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B7F05E98
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 03:48:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0259F125
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 03:48:30 +0000 (UTC)
Received: from mail-io0-f181.google.com ([209.85.223.181]) by
mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
0LzqsP-1aDh4Y40fb-0154zN for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 04:48:30 +0100
Received: by mail-io0-f181.google.com with SMTP id e126so42255401ioa.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 19:48:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.13.139 with SMTP id 133mr20306224ion.70.1450324109365;
Wed, 16 Dec 2015 19:48:29 -0800 (PST)
Received: by 10.36.49.200 with HTTP; Wed, 16 Dec 2015 19:48:29 -0800 (PST)
In-Reply-To: <CADm_WcYhPqZZ5KQ7DxyFgkk5td4ircrXwArg_guWDPWPtnCxhw@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
<CADm_WcYdAHP95mrxH0CjvxKaV12rXEdBXf-L5QtKHuBL1ndFaQ@mail.gmail.com>
<FC95D096-74AE-4B1C-B11B-1CB718538E7D@gmail.com>
<CADm_WcYhPqZZ5KQ7DxyFgkk5td4ircrXwArg_guWDPWPtnCxhw@mail.gmail.com>
Date: Thu, 17 Dec 2015 04:48:29 +0100
X-Gmail-Original-Message-ID: <CALqxMTEqFR_HzXaBDfU8qe6KR3AJ6BziqtXHn5-dnSQ-eU8yqA@mail.gmail.com>
Message-ID: <CALqxMTEqFR_HzXaBDfU8qe6KR3AJ6BziqtXHn5-dnSQ-eU8yqA@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:VyINXz3PMiYQD2XRXKcIjZ2RJEB/qrAFnpgrZvrWSrnZOHCyyUX
nxfDs1LqC7fBEi4bMc9f91nkQLQtWLUvmRqptYEpbhP1khJcTBqm1ZzO5DhFU3u/HXma1eR
6C9dKk3prsdeCFYQ74KogtY9+/Fx/YfLvwOSKkq6XGb/Bt9H2t8HBMANsiYXkLKbeObIkLJ
SsQlVAJz3UBdJBwehEdwA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:jKAdP0LDvlA=:6HTHhQiECWiYPXtqGYs024
e9nTbGt4g/F2ZSN3GQ21WsEa4OkHsXyZKPe77sBc0/BT42QAQA8Vy4pnoe0psZR3jPUvhxVw2
DIMcYfoohDxFXzuHyEiNBvRWKTIrCF4T51SsK+IpgmShCsv2iUgNPuI8avCgM2YKC2EwM4mOy
fP36aFXeejldZngb8dWVt40ZiWnKP4tMQs9oJmGjZnUO4wEbroGodU6E3PfzGkHtywXW12FFN
WaX5GQyE37G6bwtzIc9sVa1kz+YrM2Zf0C6yCDqe09y3WG46IqK31mOl3A1G6OOPzxgKsrNif
EWfl7K9UOQcMI4Pj/dquRra0lczzWZ/e9Lqt+tyUTb0QgnT3OIp6J1TqraAI0YEjr4z9Ew0u6
dMfnoeyrXf5ZYilnuuAwfW/U24sGbXElSQKFcMZQsUIX9vVEtyP6/sCuQcxAwBIsBdt6t77MN
zsf6Br9KAmZsk9L7+rgzeBHpQeIS9wr2pwFkQiXM9woRLcaKrDh4ANYbbcBJFCdesv80sfKTe
E4OgMyt2/lBOVEcSzOAzlhRIwCRRdNIWSokxRIfFBSb8/cqSF/NKFMian74N/W5c3UZafJ5xA
kT40krPVZmM4jR0W0lBJG8b7Yzz/J0lx2GbEIb7UEp3/B0yaD+WSLZJnpTSdEwbpwuQXpaYSd
GUE+JLgIHkaqnmZ/ESbtvG1A/mk2npKyQPp45MaCGvHLrRLIBWskjNOsFRceHf3lHx6nurZlO
ggV00uFuM5s91X6L
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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
Cc: Jeff Garzik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling
Bitcoin
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, 17 Dec 2015 03:48:31 -0000
There are a range of opinions about input assumptions by different
people. In each case, short of misunderstanding, if we have the same
input assumptions we're going to reach the same conclusions. This is
the way of the world in a meritocracy. The interesting point is to
compare the input assumptions and try to figure out which are more
realistic, pragmatic and achieve the best outcome.
It might be instructive to re-read Greg's roadmap and others to
re-read Jeff's original post (I will).
There is a proposed roadmap and soft-fork block-size increase and code
that Pieter is working on. There has been rationale described for
this approach, and it achieves many useful things both short, mid and
long term for scale and other issues.
There seem to be a range of opinions on the fee market, and one
question is when do we deem it safe to aim to be prepared to support a
fee market.
How elastic is block-size demand? (I think there is evidence of some
elasticity which indicates a partly working fee market already). What
I mean by elasticity of block-size demand is there are off-chain
transactions and people make an economic choice of whether to go on
chain or not, and the vast majority of transactions, all told, are
off-chain. Clearly it is ideal if they all go on chain, scale
permitting.
If we look at the roadmap at high-level:
1) bump (seg-wit or ...)
2) network improvements (IBLT/weak-block/other)
3) longer term dynamic block-size (flexcap)
4) write-cache (lightning)
It would probably be good to see some work on preparing for fee
markets. That has happened somewhat recently in response to the
stress tests. We do have an observed problem that if there is no
incentive to prepare, the improvements dont happen, and so we can
never be ready for a fee market. That's kind of how we got here,
people were talking about fee-estimation and dynamic fees several
years ago before the block-size went from 250kB to 750kB, and then
lost interest as there was another 500kB to play with. There could be
a best practice doc written asking people to prepare. That might
help.
Presumably it's good if we do see the fee market more, for it to come
in gradually. Flexcap probably helps there because the block-size
itself becomes elastic to demand (pay for bigger blocks).
If we want to avoid a fee market for the immediate term, are we more
worried about period 1, or period 2 or 3. Probably 2 is more of a
worry as we're scaling in 1 where in period 2 we're preparing for
scaling and more time has passed for demand to grow. That might for
example argue for seg-wit because it brings us closer to 4) and if we
spread things out we might delay the possibility to do lightning as
there is only so many cycles for forks (hard or soft) in testing,
deployment planning etc so it can be good to have a holistic view.
Also the question of time-frame that is safe for soft-forks or
hard-forks is another input where views seem to vary. I think some
people are more optimistic about being able to avoid people losing
money in fast hard-forks. One lesson on users, is users find failure
modes that testing cant, or do things you would expect them not to do.
Also we're calling hard-forks things that are really soft-forks to SPV
clients, and hard-forks only to full-nodes. If we wanted to make a
real economic choice, we could artificially make an SPV hard-fork,
however that would make upgrade harder.
As I said in an earlier email I think everyone is empathetic to user
requirements, including economic desires - but Bitcoin has inherent
constraints that are complex to improve. Each proposal is trying to
best meet those holistic user requirements. There are no free lunches
and we dont want to economically hurt anyone in total or as a group or
type of use. Not all requirements can be met, they are in a trade
off, so that calls for balance, planning and transparency.
This is also a market, we can discuss protocol tradeoffs without being
melodramatic - would be kind of undesirable if a dramatic or emotive
way to express something as easily or more clearly expressed in
technical constructive words is moving the price around.
Adam
On 17 December 2015 at 03:58, Jeff Garzik via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
>>
>> At least SW *is* a scaling solution (albeit most of the important benefits
>> are long term). The issue of fee events has nothing to do with scaling - it
>> has to do with economics...specifically whether we should be subsidizing
>> transactions, who should pay the bill for it, etc. My own personal opinion
>> is that increasing validation costs works against adoption, not for
>> it...even if it artificially keeps fees low - and we'll have to deal with a
>> fee event sooner or later anyhow. You may disagree with my opinion, but
>> please, let's stop confounding the economic issues with actual scaling.
>
>
> At least on my part, the title of the 1st email was "It's economics & ..."
> and focused on (a) economics and (b) transition issues. There was no
> confounding. There was a list of real problems and risks taken when 1M is
> not lifted in the short term.
>
> Thus "SW is orthogonal" in these emails, because these problems remain
> regardless of SW or no, as the 1st email outlined.
>
> The 2nd email addresses the specific assertion of "no 1M hard fork needed,
> because SW."
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
