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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1XaC1d-0002NI-M0
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Oct 2014 23:12:37 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.213.179 as permitted sender)
client-ip=209.85.213.179; envelope-from=jgarzik@bitpay.com;
helo=mail-ig0-f179.google.com;
Received: from mail-ig0-f179.google.com ([209.85.213.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XaC1c-0004L3-Mj
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Oct 2014 23:12:37 +0000
Received: by mail-ig0-f179.google.com with SMTP id h18so148320igc.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 03 Oct 2014 16:12: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:from:date
:message-id:subject:to:cc:content-type;
bh=hZ7kf9CVXF+JnlYst3p0TAWknlFK0qNTe8RtjXtF4fA=;
b=UWKqEJQjhP1ReCAh0h/3v6YmcLyZL5F5vasyO+BJSs5Pr5Lfa5jiLpmYysogBdawaS
IhY4Psa2UojlOgeWtOyHc8S0Xp7+GlgAquBbisLbNzKYbEQjYEJMtYHjLmbokzL5OsRy
fSXHXImvNSbjI8hTtHqAExrdv83oiduRB7eKcc1oWfoOfNZ6/pfPb0AhhAjRTkXipGJA
Lh2SadXWI91FPRDqYF/SHV3EF2hLf+qaBU3cdlJ+fq9Uf4nRaaRl05lXqA15rrwxHSts
BtmkFnCDPjK6OPKBPYNWJ8ZfJDIm7uMrQjwRIIisBQz6fYByaxsSgzU/G5G3TyEaCo50
86RQ==
X-Gm-Message-State: ALoCoQkm8Eg4Z67zOsoIE8ouS4F2UFmtuOH8FTqcLcFlpbbFddWv1+1rEn4pOH9DmAFaID/Q1OJK
X-Received: by 10.42.62.6 with SMTP id w6mr16166842ich.24.1412377951208; Fri,
03 Oct 2014 16:12:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.153.213 with HTTP; Fri, 3 Oct 2014 16:12:11 -0700 (PDT)
In-Reply-To: <CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com>
References: <20141001130826.GM28710@savin.petertodd.org>
<CABbpET8_FMCcnh0dELnHsYmF+YP05Gz=nZ3SPkLZuqXYV3JUpQ@mail.gmail.com>
<1987325.zKPNeYyO8K@crushinator> <201410031750.27323.luke@dashjr.org>
<CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 3 Oct 2014 19:12:11 -0400
Message-ID: <CAJHLa0NRNEQLqA2E=ysXsKw6hWS-H9X_AFYK4ckC4-_Bk=qbSA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XaC1c-0004L3-Mj
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Flavien Charlon <flavien.charlon@coinprism.com>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
a txout from being spent until an expiration time
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 03 Oct 2014 23:12:37 -0000
RE " It's not like other software where people can choose to skip an
upgrade and things still work just like before."
If you're a minority, sure you can. Still a few nutters out there on
a 0.3.x codebase, including one or two inattentive,
now-inconsequential miners.
There is some headroom built in for just that... less disruptive
upgrades that don't require 100%.
On Fri, Oct 3, 2014 at 4:58 PM, Mike Hearn <mike@plan99.net> wrote:
> Alright. It seems there's no real disagreement about how the opcode behaves.
> Perhaps a time limit would be appropriate to stop people creating outputs
> locked for 100 years .... is bitcoin even likely to exist in 100 years? The
> entire history of computing is not even that old, seems hard to imagine that
> it'd be good for anything beyond wasting space in the database. But this is
> a minor point.
>
> So I guess it's time to start the deployment discussion.
>
> Bitcoin is a consensus system. It works best when everyone is following
> exactly the same rules at the same time. A soft fork works against this
> principle by allowing nodes to think they're following the majority ruleset,
> even if they aren't, effectively downgrading them to something a bit like
> SPV security without them realising.
>
> A hard fork has multiple desirable properties. Most importantly, it means a
> node can detect it's no longer in the consensus because it'll find its own
> chain height has diverged significantly from its peers. Core already has
> code that knows how to detect this condition and log errors about it as well
> as running the alertnotify script i.e. emailing the admin. Ideally it would
> also stop serving work so miners shut down or fail over, but this is easily
> added to the CheckForkWarningConditions() function.
>
> In other words, this gives the cleanest failure we can give, such that any
> procedures a node operator has put in place to alert them of divergence will
> be triggered. Any code which is waiting for confirmations will wait forever
> at this point, thus minimising the risk of loss.
>
> Additionally, forcing old peers to fall behind means SPV clients will pick
> the right chain, and not end up downloading transactions or blocks that are
> about to be doomed at the next re-org. They can easily choose to ignore
> transactions relayed by peers that are too far behind and thus not end up
> accepting transactions that are no longer valid according to the majority (a
> scenario which can cause monetary loss).
>
> I don't think hard forks should be scary. Mechanisms are in place to warn
> people and they can be scheduled with plenty of time in advance. The main
> stated justification for a soft fork is backwards compatibility, but in a
> system like Bitcoin you really don't want to be running behind the consensus
> and it's hard to imagine any node operator deliberately choosing to stay on
> the wrong side of the fork. It's not like other software where people can
> choose to skip an upgrade and things still work just like before.
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
