summaryrefslogtreecommitdiff
path: root/6b/069fc521563d5831c22e3698067921e6d21fd0
blob: 5362fb07633e9320bc8ec43b5a8d4ea22e53c8dd (plain)
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
Return-Path: <michabailey@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 587B81281
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Oct 2015 06:13:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
	[209.85.223.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CDDD7102
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Oct 2015 06:13:24 +0000 (UTC)
Received: by iofh134 with SMTP id h134so11673470iof.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 06 Oct 2015 23:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=5Ye5Bpkd+TBi++oCMhr09Ime28K5MMUOLfeOM5pzDXY=;
	b=Kkvyzr7JaCbjKu8sc0t0iryg6peKaFuOBYC4+tH6xOPHlmeDyN9RKMgYbIsCCxYFVL
	scHOLhZBlyJIEo59hoFru07vea35s/s1h88LagDGG3/ssunpa9MbRIjxOPSQOH5+nufz
	zDlzPUvq4H9senveuwy8e4boNIm4mMnQO0e+1t4uay/soH/TySzJmeiyrCU3VTNe128k
	aglcJ9W6JHB9jObWUL+a4SldvhXs9uk2zY90rgHHagRrEmIKUR4bT1REX9jFF7xnlk/9
	qtQatnx+BKX2RhlTlK3n829v/8sHdX5+vMx8uMQ0q9/ts1Dq8ZeDgRQIJ4n7G36Jg5hu
	JI7Q==
MIME-Version: 1.0
X-Received: by 10.107.9.222 with SMTP id 91mr43320077ioj.107.1444198404215;
	Tue, 06 Oct 2015 23:13:24 -0700 (PDT)
Received: by 10.79.37.68 with HTTP; Tue, 6 Oct 2015 23:13:23 -0700 (PDT)
In-Reply-To: <CA+w+GKRjURkV40iG=6RLhFyQ-t2G_YAinKk7Os_8zK4+hyYJaw@mail.gmail.com>
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
	<BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
	<CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com>
	<CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
	<CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com>
	<CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
	<CA+w+GKS-AZGBSwuN1dgEs6wa-R=jHE0fmfmQ0TL9Cw9b6L71UQ@mail.gmail.com>
	<CABm2gDpgpRg9U5ToNM98pQgz8VRwT8o817zrpJgOj06PwySk_Q@mail.gmail.com>
	<CA+w+GKRjURkV40iG=6RLhFyQ-t2G_YAinKk7Os_8zK4+hyYJaw@mail.gmail.com>
Date: Wed, 7 Oct 2015 09:13:23 +0300
Message-ID: <CAAmoQf3o5OLhtcsh4OZ_cp52vf__L7oxow+7CFx7WKQoEHCpFw@mail.gmail.com>
From: Micha Bailey <michabailey@gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a113eba38de733f05217da4d2
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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Wed, 07 Oct 2015 06:13:25 -0000

--001a113eba38de733f05217da4d2
Content-Type: text/plain; charset=UTF-8

On Monday, October 5, 2015, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As Greg explained to you repeatedly, a softfork won't cause a
>> non-upgraded full node to start accepting blocks that create more
>> subsidy than is valid.
>>
>
> It was an example. Adam Back's extension blocks proposal would, in fact,
> allow for a soft forking change that creates more subsidy than is valid (or
> does anything else) by hiding one block inside another.
>

Maybe I'm missing something, but wouldn't this turn into a hard fork the
moment you try to spend an output created in one of these extension blocks?
So sure, the block that contains the extension would be considered valid,
but unupgraded validators will not update the UTXO set accordingly, meaning
that those new TXOs can't be spent because, according to their rules, they
don't exist.

>
>

--001a113eba38de733f05217da4d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, October 5, 2015, Mike Hearn via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
As Greg explained to you repeatedly, a softfork won&#39;t cause a<br>
non-upgraded full node to start accepting blocks that create more<br>
subsidy than is valid.<br></blockquote><div><br></div><div>It was an exampl=
e. Adam Back&#39;s extension blocks proposal would, in fact, allow for a so=
ft forking change that creates more subsidy than is valid (or does anything=
 else) by hiding one block inside another.</div></div></div></div></blockqu=
ote><div><br></div><div>Maybe I&#39;m missing something, but wouldn&#39;t t=
his turn into a hard fork the moment you try to spend an output created in =
one of these extension blocks? So sure, the block that contains the extensi=
on would be considered valid, but unupgraded validators will not update the=
 UTXO set accordingly, meaning that those new TXOs can&#39;t be spent becau=
se, according to their rules, they don&#39;t exist.</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><br></div></div></div>
</blockquote>

--001a113eba38de733f05217da4d2--