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
|
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 A1CCC486
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 05:27:46 +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 2B48CF0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 05:27:46 +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 AD02838A008C;
Sat, 13 May 2017 05:27:00 +0000 (UTC)
X-Hashcash: 1:25:170513:roconnor@blockstream.io::soK0CPpaVDaGp9fD:bINLi
X-Hashcash: 1:25:170513:bitcoin-dev@lists.linuxfoundation.org::lRFE66i=KGv29gul:beiJP
From: Luke Dashjr <luke@dashjr.org>
To: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 13 May 2017 05:26:58 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
References: <201705121922.57445.luke@dashjr.org>
<CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com>
In-Reply-To: <CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com>
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: <201705130526.59467.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 Protocol Discussion <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 05:27:46 -0000
On Saturday 13 May 2017 4:23:41 AM Russell O'Connor wrote:
> I recall chatting about this idea recently and my conclusion was the same
> as Peter Todd's conclusion: this will just encourage miners to false signal
> readiness with undermines both BIP 9 and BIP 8.
I already explained why this isn't the case: If we're comparing MASF to
MASF+CBV, then I agree. But MASF is not necessarily always on the table, so
the comparison where this becomes relevant is MASF+CBV vs UASF.
> I felt that rather than using script system for this construction, it would
> be better to use the transaction version number instead by soft-forking in
> a rule that says when the most significant bits of a transaction version
> are 001 then the transaction can only be included in blocks whose lower 29
> version bits are set at the same position as the lower 29 version bits set
> in the transaction version.
Versionbits change/lose their meaning after the deployment timeout. For this
reason, the timeout must be specified so the check is skipped when that
occurs.
Also, doing it the way you describe would fail to enforce that BIP9 is
actually in use for the block version; you could simply add that as an
additional condition, but it seems pretty hacky since you wouldn't be able to
upgrade versionbits anymore...
> While I think that making use of the transaction version number is superior
> to adding an opcode, because it doesn't interfere with caching of script
> validity
Script validity can still be cached with this: you would always allow the
opcode to succeed at evaluation-time, and simply store the criteria checked
separately. Then it would behave effectively the same as using the transaction
version number.
Luke
|
