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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C09E2B9B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 23:50:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com
[209.85.213.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D872107
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 23:50:37 +0000 (UTC)
Received: by vkca188 with SMTP id a188so33108643vkc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Dec 2015 15:50:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=EkKuSXCbvBkcp8vMDRlpEPZp+DxR73qznS2V3nuha9s=;
b=QMdP/Uy9/HYLbCmFWAGPRVNTzZw3Pb6NJnbRfr+P6x9uokOrJKc0HpffLLDdTxP9GE
kf3hQIuGXujNM3Grnuw4E+XEfUZLjVqJHWuymDE/iz4QgtnIyT4mO+ppeS5WElVnb7Xg
qgcYuPF8wdxhZ+LjNxsMdwzVY+r0I+ABzTdyZUv9e3OhGobvRYbeXp+4I6KJI6P5YXUf
W2ZVLVbKzg0eAFfgA0IgoLOE/n/faEmBblvVN2rca5UbIx7T/RKoOmNeipzBqQRGlrLi
FHe4/e7NrnaRNbrFAFxYrWIKtHtZmeQwkPrXO2hAkAZFfDMkhXz14hkTS/Nl3AMOjKKK
Rm4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=EkKuSXCbvBkcp8vMDRlpEPZp+DxR73qznS2V3nuha9s=;
b=h7KjaTiMo5eNuPaFK3P0XHZidewrbjTO5CWCcJVoEfMJ+CI86llJe9PbDam3v87p0E
fSehemzqmeSrz3jbHdRnVbLE5ZGUWCW5adMu/VE47/ZUpXW2UWkjzglVT1j2WpiwA+e0
tzuQMUdcQQ4iWTrIkGNd/O8Y6DQ0PVPZ8QmlRwY+psxFTfilJsJaO44dhl3TavLGs+Jj
WlRJn9SpuOi03ydB0wDv14Z2Z9gsllZX6OS+pjO5lryCTNlu1KfAblzdb2xsl+rvuyiG
mhMaL+jdv2fRxBOYyn2PmFcvM/ut8tEgPzDS8P7+PgBBHdD3Xj/DYk1Quw6nXqBPMb0Z
PWyQ==
X-Gm-Message-State: ALoCoQke3kgygvW+MRnDqpfh21NixSWaUOXcvzSljeiyM1WwqlFdt2RLbbG7gwQ5H9dDdZ5kobIITXNh9HessewbNVpZtGHy3A==
MIME-Version: 1.0
X-Received: by 10.31.154.213 with SMTP id c204mr2176810vke.38.1449618636233;
Tue, 08 Dec 2015 15:50:36 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Tue, 8 Dec 2015 15:50:35 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Tue, 8 Dec 2015 15:50:35 -0800 (PST)
In-Reply-To: <2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
<20151208110752.GA31180@amethyst.visucore.com>
<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
<CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
<5666FD8D.8050201@openbitcoinprivacyproject.org>
<2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im>
Date: Wed, 9 Dec 2015 00:50:35 +0100
Message-ID: <CABm2gDoUiYb1giLd+=8a-tm+0P0+PLJQpQkffe2DZbN0z887Ww@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Jonathan Toomim <j@toom.im>
Content-Type: multipart/alternative; boundary=001a1140f52cdf739805266ba350
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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] Capacity increases for the Bitcoin system.
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: Tue, 08 Dec 2015 23:50:37 -0000
--001a1140f52cdf739805266ba350
Content-Type: text/plain; charset=UTF-8
On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I also think that a hard fork is better for SegWit, as it reduces the
size of fraud proofs considerably, makes the whole design more elegant and
less kludgey, and is safer for clients who do not upgrade in a timely
fashion.
I agree, although I disagree with the last reason.
> I don't like the idea that SegWit would invalidate the security
assumptions of non-upgraded clients (including SPV wallets). I think that
for these clients, no data is better than invalid data. Better to force
them to upgrade by cutting them off the network than to let them think
they're validating transactions when they're not.
I don't undesrtand. SPV nodes won't think they are validating transactions
with the new version unless they adapt to the new format. They will be
simply unable to receive payments using the new format if it is a softfork
(although as said I agree with making it a hardfork on the simpler design
and smaller fraud proofs grounds alone).
>
> On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > If such a change is going to be deployed via a soft fork instead of a
> > hard fork, then the coinbase is the worst place to put the segwitness
> > merkle root.
> >
> > Instead, put it in the first output of the generation transaction as an
> > OP_RETURN script.
> >
> > This is a better pattern because coinbase space is limited while output
> > space is not. The next time there's a good reason to tie another merkle
> > tree to a block, that proposal can be designated for the second output
> > of the generation transaction.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a1140f52cdf739805266ba350
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</a>> wrote:</p>
<p dir=3D"ltr">> I also think that a hard fork is better for SegWit, as =
it reduces the size of fraud proofs considerably, makes the whole design mo=
re elegant and less kludgey, and is safer for clients who do not upgrade in=
a timely fashion. </p>
<p dir=3D"ltr">I agree, although I disagree with the last reason.</p>
<p dir=3D"ltr">> I don't like the idea that SegWit would invalidate =
the security assumptions of non-upgraded clients (including SPV wallets). I=
think that for these clients, no data is better than invalid data. Better =
to force them to upgrade by cutting them off the network than to let them t=
hink they're validating transactions when they're not.</p>
<p dir=3D"ltr">I don't undesrtand. SPV nodes won't think they are v=
alidating transactions with the new version unless they adapt to the new fo=
rmat. They will be simply unable to receive payments using the new format i=
f it is a softfork (although as said I agree with making it a hardfork on t=
he simpler design and smaller fraud proofs grounds alone). </p>
<p dir=3D"ltr">><br>
> On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev <<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>> wrote:<br>
><br>
> > If such a change is going to be deployed via a soft fork instead =
of a<br>
> > hard fork, then the coinbase is the worst place to put the segwit=
ness<br>
> > merkle root.<br>
> ><br>
> > Instead, put it in the first output of the generation transaction=
as an<br>
> > OP_RETURN script.<br>
> ><br>
> > This is a better pattern because coinbase space is limited while =
output<br>
> > space is not. The next time there's a good reason to tie anot=
her merkle<br>
> > tree to a block, that proposal can be designated for the second o=
utput<br>
> > of the generation transaction.<br>
><br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
</p>
--001a1140f52cdf739805266ba350--
|
