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
|
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 B4D67DA1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Dec 2015 12:32:05 +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 7914811D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Dec 2015 12:32:03 +0000 (UTC)
Received: from mail-io0-f178.google.com ([209.85.223.178]) by
mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id
0MWRTQ-1ZjjM82Cks-00Xn9G for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Dec 2015 13:32:02 +0100
Received: by ioae126 with SMTP id e126so41532744ioa.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Dec 2015 04:32:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.167.9 with SMTP id q9mr29438203ioe.84.1450096321873;
Mon, 14 Dec 2015 04:32:01 -0800 (PST)
Received: by 10.36.49.200 with HTTP; Mon, 14 Dec 2015 04:32:01 -0800 (PST)
Date: Mon, 14 Dec 2015 20:32:01 +0800
X-Gmail-Original-Message-ID: <CALqxMTFY4oAAO4mXVJigEunjPw+q6y3x=zATLEw9ErDcS1RDuw@mail.gmail.com>
Message-ID: <CALqxMTFY4oAAO4mXVJigEunjPw+q6y3x=zATLEw9ErDcS1RDuw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Jonathan Toomim <j@toom.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:PFVMDbq8HlQ+BfEYQ27SftzsawhOmz4zSziBxoay+6y4mQMJR0J
pL5RQMB+Mz00GbMLFaEG5JMoEGTFjNUOFONLWvY11+RfHKV9Eoz2bqdrns2lG627u6YXzXL
pOK803DchfThWzyalnThgro7vJraRFoRbPsJs+w0ogndpUrezVEupECFzg5JxfiAitep1nL
SKupkkFIZF32LRulL0SPQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dVD72ulK3Hg=:oxOoZdvpg6Ry5ab0TjAr7F
1aeMYjCQASI/bSR4K8Gx+jmM8xwVYD6DYOw/6Dq1Dm3pkL6DucWQQGPa05qk94nS92Jmpm42H
mWEEB+WP2+fvXnlyOZm/F/p+CKbCySxS1cUaXZG47QK0+01KCJ6DzUGrlB+FMNtauUyX+LYWF
GgurlLuWdQC5S8BUlGvzKet3yWDIvUB5CMDAH81TEe8ZtJt0GyNR7RkQMItEcfx8hkoF1mz/c
h1tM8gLCW+HYWq7kEzYZXIR1DEG5kd/6ELBoAYCST34WOxquPpfXi3CyV7DkFwqIZ47toBJJI
bw2uTFzdlTyED4IZhqmvykeKR6KswFxX2/kMWS6TWrchDK2acL0Tcc+sKGQlQdAd902CqE2O1
uEvqFkcruUeQQssRAg17bic3w/yQUXchY94R17H9qD/1l6ygFzJWVxEzk6KfZjEsRicFGrig4
+KxdIKnK+BZDepwp8aUowQaitKka1fFYE67mP3q8KGyZ9gpsM/IoWpd+3RpXPYyDLPfsETZqG
uLXmlo418I8Q91+tXnlvQzRC2t4/7vdCSqUN68R4KOP/rXP0LosM9w4hHgix3dCqQRrWXX6B4
72S45AqpDzGlzGP6FvZpJuwyYC18OZ5D+vRfPUWGcr8xAPRld7kHHd3eHfwTFZimSR0wf8BGU
e1N4O0bOrtAbfCeSS+pV8pfGgMMa7bhuOPaiherQ3Jgigf4cgPGjkZyik25+bsSQQcetIWEL3
BrZ9R1OcGCi8H0PM
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: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
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, 14 Dec 2015 12:32:05 -0000
I think people have a variety of sequences in mind, eg some would
prefer to deploy versionBits first, so that subsequent features can be
deployed in parallel (currently soft-fork deployment is necessarily
serialised).
Others think do seg-witness first because scale is more important.
Some want to do seg-witness as a hard-fork (personally I think that
would take a bit longer to deploy & activate - the advantage of
soft-fork is that it's lower risk and we have more experience of it).
I've seen a few people want to do BIP 102 first (straight move to 2MB
and only that) and then do seg-witness and other scaling work later.
That's possible also and before Luke observed that you could do a
seg-witness based block-size increase via soft-fork, people had been
working following the summary from the montreal workshop discussion
posted on this list about a loose plan of action, people had been
working on something like BIP 102 to 2-4-8 kind of space, plus
validation cost accounting.
So I think personally soft-fork seg-witness first, but hey I'm not
writing code at present and I'm very happy for wiser and more code and
deployment detail aware minds to figure out the best deployment
strategy, I wouldnt mind any of the above, just think seg-witness
soft-fork is the safest and fastest. The complexity risk - well on
the plus side it is implemented and it reduces deployment risk, and
it's anyway needed work to have a robust malleability fix which is
needed for a whole range of bitcoin smart-contract, and scaling
features, including for example greenAddress like faster transactions
as used by BitPay?, BitGo and GreenAddress as well as lightning
related proposals and basically any smart-contract use that involves
multiple clauses and dependent transactions. Also re complexity risk
Greg has highlighted that the complexity and overhead difference is
really minor. About knock on code changes needed, a bunch of the next
steps for Bitcoin are going to need code changes, I think our scope to
improve and scale Bitcoin are going to be severely hampered if we
restricted ourselves with the pre-condition that we cant make protocol
improvements. I think people in core would be happy to, and have done
this kind of thing multiple times in the past, to help people for free
on volunteer time integrate and fix up related code in various
languages and FOSS and commercial software that is affected.
As to time-line Luke I saw guestimated by march 2016 on reddit.
Others maybe be more or less conservative. Probably a BIP and testing
are the main thing, and that can be helped by more eyes. The one
advantage of BIP 102 like proposal is simplicity if one had to do a
more emergency hard-fork. Maybe companies and power users, miners and
pool operators could help define some requirements and metrics about
an industry wide service level they are receiving relative to fees.
The other thing which is not protocol related, is that companies can
help themselves and help Bitcoin developers help them, by working to
improve decentralisation with better configurations, more use of
self-hosted and secured full nodes, and decentralisation of policy
control over hashrate. That might even include buying a nominal (to a
reasonably funded startup) amount of mining equipment. Or for power
users to do more of that. Some developers are doing mining.
Blockstream and some employees have a little bit of hashrate. If we
could define some metrics and best practices and measure the
improvements, that would maybe reduce miners concerns about
centralisation risk and allow a bigger block faster, alongside the
IBLT & weak block network protocol improvements.
Adam
On 14 December 2015 at 19:44, Jonathan Toomim via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 1. I think we should limit the sum of the block and witness data to nBloc=
kMaxSize*7/4 per block, for a maximum of 1.75 MB total. I don't like the id=
ea that SegWit would give us 1.75 MB of capacity in the typical case, but w=
e have to have hardware capable of 4 MB in adversarial conditions (i.e. int=
entional multisig). I think a limit to the segwit size allays that concern.
>
> 2. I think that segwit is a substantial change to how Bitcoin works, and =
I very strongly believe that we should not rush this. It changes the block =
structure, it changes the transaction structure, it changes the network pro=
tocol, it changes SPV wallet software, it changes block explorers, and it h=
as changes that affect most other parts of the Bitcoin ecosystem. After we =
decide to implement it, and have a final version of the code that will be m=
erged, we should give developers of other Bitcoin software time to implemen=
t code that supports the new transaction/witness formats.
>
> When you guys say "as soon as possible," what do you mean exactly?
>
> On Dec 10, 2015, at 2:47 PM, jl2012--- via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>
>> It seems the current consensus is to implement Segregated Witness. SW op=
ens many new possibilities but we need a balance between new features and d=
eployment time frame. I'm listing by my priority:
>>
>> 1-2 are about scalability and have highest priority
>>
>> 1. Witness size limit: with SW we should allow a bigger overall block si=
ze. It seems 2MB is considered to be safe for many people. However, the exa=
ct size and growth of block size should be determined based on testing and =
reasonable projection.
>>
>> 2. Deployment time frame: I prefer as soon as possible, even if none of =
the following new features are implemented. This is not only a technical is=
sue but also a response to the community which has been waiting for a scali=
ng solution for years
|
