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
|
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 E9897BD9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 15:33:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
[209.85.212.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A3A0FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 15:33:32 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so120394264wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 08:33:31 -0700 (PDT)
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=l5a10SVUgc+1nxTDxykQxlXLS+JkJYoqqct+/64Vqsg=;
b=PJeMIPe0fsbAoCOS8zvOA8QoG1Vli2QgMhIXcbGJLtet+jmJf6GG0Hkosqp4fzGo3l
JiGBk1L3yO3rrwTwz8w81sr1j6nqePGhJ1cc9xuUzQXF1xvaPRmKiXQXcB8FbC+Tm30l
AXQk/jz6koz790B4y8aOIurFSNqsHMt2AJJykr8K/7cP5gLB7yhv/5IQzOm1fZgcHBYV
YydiepmyjuSlejomwyjgfrnmG9uO9aPj63kTol6rxJObLF7h20ayRnQhz/UKnxFTM1le
6r5L1ovIEr73teeMEU3dDM/90mQD9OqefoPmE4YtWHUg8f7nw/1YnLDcbenXJbX1jyPi
9CGQ==
X-Gm-Message-State: ALoCoQmzqh3tSVhytdwdjA0tXz9MsMK3Q0Suw9nM4c/sIJoFGJjfhcImAY12EYkMhLC5l6Ovs6UP
MIME-Version: 1.0
X-Received: by 10.194.77.240 with SMTP id v16mr29884939wjw.109.1444059210989;
Mon, 05 Oct 2015 08:33:30 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Mon, 5 Oct 2015 08:33:30 -0700 (PDT)
In-Reply-To: <CA+w+GKS-AZGBSwuN1dgEs6wa-R=jHE0fmfmQ0TL9Cw9b6L71UQ@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>
Date: Mon, 5 Oct 2015 17:33:30 +0200
Message-ID: <CABm2gDpgpRg9U5ToNM98pQgz8VRwT8o817zrpJgOj06PwySk_Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Mon, 05 Oct 2015 15:33:33 -0000
On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> Hi Jorge,
>
> I'm glad we seem to be reaching agreement that hard forks aren't so bad
> really and can even have advantages. It seems the remaining area of
> disagreement is this rollout specifically.
>>
>> a non-upgraded full node and an upgraded full will converge on what they
>> see: "the most-work valid chain" will be the same for both.
>
> Indeed it will, but the point of fully verifying is to not converge with the
> miner majority, if something goes wrong and they aren't following the same
> rules as you. Defining "work" as "converge with miner majority" is fine for
> SPV wallets and a correct or at least reasonable definition. But not for
> fully verifying nodes, where non-convergence is an explicit design goal!
> That's the only thing that stops miners awarding themselves infinite free
> money!
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's only the new rule (in this case, BIP65) that they won't validate.
That's very different security from an SPV node, and as Greg also
explained, SPV nodes could be much more secure than bitcoinj nodes
(they could, for example, validate the coinbase transaction of every
block).
If a non-upgraded node it's not a "full node" for you, that's fine,
but it is for everyone else. So please stop confusing other people.
Assuming the majority of the hashrate upgraded, there's almost no risk
for non-upgraded full nodes.
>> Are you going to produce a bip65 hardfork alternative to try to convince
>> people of its advantages over bip65 (it is not clear to me how you include a
>> new script operand via hardfork)?
>
> No, I'm focused on the block size issue right now. I don't think there's
> much point in improving the block chain protocol if most users are going to
> be unable to use it. But the modification is simple, right? You just replace
> this bit:
>
> CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode
>
> with this
>
> CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)
>
> and that's it. The section upgrade and testing plan only says TBD so that
> part doesn't even need to change at all, as it's not written yet.
Thanks, I wasn't aware that there was room for new opcodes that
weren't noops already.
Can you give an example of an attack in which a non-upgraded full node
wallet is defrauded with BIP65 but could not with the hardfork
alternative (that nobody seems to be willing to implement)?
Please, don't assume 0 confirmation transactions or similar
unreasonable assumptions (ie see section 11 "Calculations" of the
Bitcoin whitepaper).
|
