summaryrefslogtreecommitdiff
path: root/27/e781bc1a978792b9162eb9a4953971a456e1b0
blob: dbf6a072c4ad46d937771e40ef1690ff1ad34f73 (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
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EBB74721
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 13 May 2017 00:50:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8BD6316D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 13 May 2017 00:50:22 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 7CAE038A0081;
	Sat, 13 May 2017 00:49:35 +0000 (UTC)
X-Hashcash: 1:25:170513:pete@petertodd.org::Eq5jg2GO8aMg+1mk:dz05X
X-Hashcash: 1:25:170513:ZmnSCPxj@protonmail.com::kRfJCP5TR+05d3wy:=xVz
X-Hashcash: 1:25:170513:bitcoin-dev@lists.linuxfoundation.org::tj+871Aon8g8EkYy:sBse
From: Luke Dashjr <luke@dashjr.org>
To: Peter Todd <pete@petertodd.org>,
 ZmnSCPxj <ZmnSCPxj@protonmail.com>
Date: Sat, 13 May 2017 00:49:33 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
References: <201705121922.57445.luke@dashjr.org>
	<20170512222214.GA4462@fedora-23-dvm>
In-Reply-To: <20170512222214.GA4462@fedora-23-dvm>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201705130049.33798.luke@dashjr.org>
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD 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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sat, 13 May 2017 00:50:23 -0000

On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
> nVersion signaling is already technically unenforceable, in the sense that
> we don't have good ways of ensuring miners actually adopt the rules
> they're claiming to signal. Equally, it's users who ultimately adopt
> rules, not miners, and attempting to pay miners to signal certain bits
> will further confuse this point.

This BIP doesn't change that. Enforcement remains primarily by users.

> Quite likely the outcome of users trying to anonymously pay anonymous
> miners to signal certain bits will be the complete breakdown of the
> honesty of the nVersion signalling system, currently enforced only by
> "gentlemans agreement".

You assume users will pay for signalling of softforks prematurely. So long as 
it waits until deployment of the softfork is widespread, this risk is minimal. 
At worst, it creates risks similar to a UASF. So long as UASF is the 
alternative, this way seems strictly better.

> Also, as an aside, this "specification" again shows the inadequacy and
> unreadability of English language specifications. I'd strongly suggest you
> delete it and instead mark the "reference implementation" as the
> specification.

How so?

On Friday 12 May 2017 10:17:30 PM ZmnSCPxj wrote:
> Minor editorial nitpick, this paragraph is repeated, maybe one of these
> should be Testnet?
> 
> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch
> timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).
> 
> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch
> timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).

Fixed, thanks.

Luke