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
|
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 C70A71E8F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 22:14:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C5B3A203
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 22:14:23 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so3134989wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 15:14:22 -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=ls/uOSZDnlljR6PA2YD0df54NQiHCemzFgGwaT4ZlAU=;
b=LADxV2jCf2WJQ+kLa3Bn5nai5gf3i4OqWf/Ikxu6vFI/5N4nzvF02eJQZXCYHnlcF0
I3o2I2UPchr8nSsJ+H/zmiezVIlj7PlVr7kfdvOC4VE9sReV3flHLH5l/JsfU5vWBxhr
9FuB3Lk8xu9CnBCQFf2PDlhTEGCoHtV/EEjSNDH2X0tpbK7IAN0sjUuoY469eedU+uxO
DRFE1/B4yvMRSnlbr88QpZfygOwuGuyFNmjQvyOmfbu7SnGRnsY9XP2uGl8RYOJ++Qkt
AW5VjWX/nAdlAKti4uKkutXQMDXzr+SaOrO1NPwWdZ0kc4gUNDinSDqti891TBKqO6HC
U0lA==
X-Gm-Message-State: ALoCoQkB/6UqTeIAYF+jDNbZMEwyhgef65z4cYeHtW2A2liW/k46x2qgb1RI31vtlnFDm71vusVY
MIME-Version: 1.0
X-Received: by 10.180.103.72 with SMTP id fu8mr34458741wib.7.1443651262226;
Wed, 30 Sep 2015 15:14:22 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Wed, 30 Sep 2015 15:14:21 -0700 (PDT)
In-Reply-To: <CA+w+GKTf2vnJ0WdrK1HzFwCx154e=BP=kGcZvGYY7cbcijwLSQ@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
<CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
<CADm_WcbJoH27H9ckr5sfmE0gh7YbSjKr1uLse0s3b4GTT+jEAA@mail.gmail.com>
<CA+w+GKS01sVXqNY6a39EjqL8NVO6k1Vq6sd0VZjeqF_tsx7OAA@mail.gmail.com>
<CABm2gDpojk4Sb9eVVcFiaQng+mKs+3iWFu_Ep0h7VC1ip7US5Q@mail.gmail.com>
<CA+w+GKTf2vnJ0WdrK1HzFwCx154e=BP=kGcZvGYY7cbcijwLSQ@mail.gmail.com>
Date: Thu, 1 Oct 2015 00:14:21 +0200
Message-ID: <CABm2gDqAhjd1721XPjjAiev4coveLM0NUE9ng+W2tgswHiW5bg@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: Wed, 30 Sep 2015 22:14:24 -0000
On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn <hearn@vinumeris.com> wrote:
>> Exactly, all those "mini divergences" eventually disappear
>
> A miner that has accepted a newly invalid transaction into its memory pool
> and is trying to mine it, will keep producing invalid blocks forever until
> the owner shuts it down and upgrades. This was happening for weeks after
> P2SH triggered.
>
> For instance, any miner that has modified/bypassed IsStandard() can do this,
> or any miner that accepts direct transaction submission, or any miner that
> runs an old node from before OP_NOPs were made non-standard.
That is correct. But doesn't seem to contradict anything I said.
>> On the other hand, the "single divergence" in the hardfork keeps growing
>> forever (unless all miners evetually upgrade.
>
> Which they do, because they will eventually notice they are burning money.
Assuming it is an uncontroversial hardfork (unlike bip101 in its
current form), miners will eventually upgrade because all users will
eventually upgrade as well.
Softfork-caused forks will live shortly because non-upgraded miners
will build on top of the longest upgraded chain.
In contrast, non-upgraded miners will not build on top of the longest
chain (the upgraded one assuming hashrate majority) and a parallel
chain will be built for some time. This chain can be used to defraud
non-upgraded or SPV users by isolating them and showing them only the
non-upgraded chain, which keeps growing but will eventually be
abandoned.
In the case of a Schism hardfork, some users may never want to
"upgrade" and if there's demand for the "old coins" there will be
miners for the "old chain".
> Sorry Jorge, but I don't think your argument makes sense.
I think my argument makes a lot of sense, it's just that for some
reason you don't think guaranteed eventual consistency has any value
because you are ok with miners abandoning the old rules chain only
eventually (and you don't believe that "eventually" can be far in the
future in practice).
On Wed, Sep 30, 2015 at 9:56 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Adam has said "there is actually consensus", although I just said there
> isn't. Feel free to say what you really mean here Adam - there's consensus
> if you ignore people who don't agree, i.e. the concept of "developer
> consensus" doesn't actually mean anything. This would contradict your prior
> statements about how Bitcoin Core makes decisions, but alright ....
BIP99 doesn't talk about "developer consensus", but rather
"uncontroversial consensus rule changes".
Obviously a patch in which developers steal everybody else's coins
wouldn't be "uncontroversial" even if "developer consensus" is
reached.
We don't need to ignore anyone to consider BIP65 an uncontroversial
softfork: we just need to ignore fallacious and unreasonable
arguments.
As far as I can tell, you are the only person opposing BIP65 (even if
you keep talking about "several people") and I would like to think
that you are aren't being obstinate on purpose only to make your point
about "developer consensus not meaning anything", but you are making
it very hard.
On Wed, Sep 30, 2015 at 11:01 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I coined the term SPV so I know exactly what it means, and bitcoinj
> implements it, as does BreadWallet (the other big SPV implementation).
No, you didn't. "Simplified Payment Verification" is section 8 in the
Bitcoin whitepaper that you like to cite so much.
> I'm going to ignore the rest of the stuff you wrote about "design decisions
> to lack security" or "cheaply avoidable lack of validation". When you have
> sat down and written an SPV implementation by yourself, then shipped it to a
> couple of million users, you might have better insight into basic
> engineering costs. Until then, I find your criticisms of code you think was
> missing due to "stonewalling" and so on to be seriously lacking real world
> experience.
Please study this page carefully and hopefully one day you will stop
using logical fallacies as often as you currently do:
https://en.wikipedia.org/wiki/List_of_fallacies
In this case you manage to combine ad hominem and appeal to authority
(maybe false authority is more accurate?).
Once again, please, stop using fallacies to try to convince people
that you are right. No offense, but being warned publicly about the
use of logical fallacies so often would be extremely embarrassing to
me.
|
