summaryrefslogtreecommitdiff
path: root/9d/8b3753337c15bee917163c41424aa1e6edb069
blob: d3704df5cbee4dba8ca3f921d45bc58f9f5dd5ca (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
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A42741EAE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Sep 2015 05:10:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com
	[209.85.220.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B8F92F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Sep 2015 05:10:05 +0000 (UTC)
Received: by pablk4 with SMTP id lk4so27841459pab.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 22:10:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent
	:mime-version:content-type:content-transfer-encoding;
	bh=Sr3cLtPodAy9brAiQk1EThr9bR6xjfJzvrnyXxMlYwo=;
	b=MibFVHs9wR+bgYtTT4Sg+jtfYsQhYWgaLvk71OgeQ5p3k9+r0vKpwZSwzPDLlZ8wJu
	STDfsnjcMfftRV0J0u4ccXZee/6TTtkZzb6R+Xn39y60j64jSBQsEt95dKzU9dS/xG90
	+lZVTPYidnunM4Y2HeqfB/UQ7jKZWj2zjQGEZPp3uzSUy1Nb4/WEqElZLfOHA8I4bcBg
	f9NH7IPoJ3wioyYcDPxUiztbMIkj7OrNZKPcie3PlXB30+LNMRZAYutMVTpLsMGgdf1G
	s5ZN737uD8UpLM/MqCBlR7oanPNE14fCPI68zcrwGVYYXf3s9jK9go3d/rOxF4LuHuj6
	wIQA==
X-Received: by 10.66.138.11 with SMTP id qm11mr2434535pab.126.1443589805073;
	Tue, 29 Sep 2015 22:10:05 -0700 (PDT)
Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	tb9sm28923363pab.13.2015.09.29.22.10.03
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 29 Sep 2015 22:10:04 -0700 (PDT)
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: "Gregory Maxwell" <gmaxwell@gmail.com>, "Rusty Russell"
	<rusty@rustcorp.com.au>
Date: Wed, 30 Sep 2015 05:09:51 +0000
Message-Id: <em0a6ae99c-b1d5-450f-ab2e-ad085991b9ff@platinum>
In-Reply-To: <ema32ec38f-3384-48e2-9ab3-6064e4c73bde@platinum>
Reply-To: "Eric Lombrozo" <elombrozo@gmail.com>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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>,
	Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.
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 05:10:05 -0000


>While I would like to get some form of explicit acknowledgment from=20
>miners that a new rule is in effect, the truth of the matter is we=20
>still lack a means to determine whether or not miners are actually=20
>enforcing these rules...unless someone happens to mine a block that=20
>breaks the new rule. This is a bit frustrating...but that's just how it=
=20
>is.
>

I should add that hard forks do provide us with a means to determine=20
whether or not miners are enforcing the new rules...but generally=20
speaking they risk far greater disruption if anything fails to go as=20
planned. Between the risk of clients accepting an occasional invalid=20
"confirmation" or two and the risk of a total network partition, the=20
former seems far less serious. I believe the concerns regarding old=20
clients can be remedied to a very large extent by means of a good=20
awareness campaign.


- Eric