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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 707BF5AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 May 2017 05:05:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A0B1164
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 May 2017 05:05:53 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian))
id 1dBwaL-0005fN-OB; Sat, 20 May 2017 15:05:51 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Sat, 20 May 2017 15:05:43 +1000
Date: Sat, 20 May 2017 15:05:43 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170520050543.GA4334@erisian.com.au>
References: <201705121922.57445.luke@dashjr.org>
<CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com>
<201705130526.59467.luke@dashjr.org>
<CAMZUoKnjc4ezVm4FeMFA-+=g13E5ZwZCAoAjd_yL89v7qf1gEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMZUoKnjc4ezVm4FeMFA-+=g13E5ZwZCAoAjd_yL89v7qf1gEA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 20 May 2017 12:12:25 +0000
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, 20 May 2017 05:05:54 -0000
On Sat, May 13, 2017 at 01:11:27PM -0400, Russell O'Connor via bitcoin-dev wrote:
> On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr <luke@dashjr.org> wrote:
> > 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.
> To add a timeout a user can optionally bundle a pair of similar transactions.
> One with the transaction version bits set and a second with a locktime set.
> The effect is the same.
Another approach to ensuring the timeout might be to simply use input
height. ie:
* if there is a BIP-9 soft-fork using bit N currently STARTED or
LOCKED_IN phase. since the soft-fork is started, set the height of
the first block after starttime as "S".
* then a transaction is invalid in a block if:
* the soft-fork has not timed out or activated
* the block does not signal bit N
* the transaction nversion does signal bit N (by whatever formula)
* at least one input to the transaction has a height >= S
That's compatible with bit reuse: if a transaction designed to encourage
soft-fork foo with bit 1 does not get mined by the time foo finishes (by
timeout or success), then when soft-fork bar reaches STARTED phase while
reusing bit 1, the old transaction can be mined by either signalling
or non-signalling miners -- because all of the transaction inputs are
prior to bar's block S, the invalidation rule doesn't apply for bar, and
because foo has timed out or activated, it doesn't apply for foo either.
It means you can't directly use a bunch of old coins on their own to
incentivise miner signalling -- you need to include a coin from after
starttime. That doesn't seem terribly onerous though; and should be
easily solvable by just providing a coinjoin API anyway. I think it's
compatible with using bitcoin days destroyed as a weighting measure too,
since only one of the coins needs to be relatively recent.
The above is a "fail-open" timeout rather than "fail-closed" -- if you
signal for foo, but your transaction doesn't get mined because too few
miners are signalling foo, and then foo fails to activate and times out,
your transaction can then be mined by the miners that didn't signal. If
this isn't what you want, double-spending should be fine: provide a double
spend at market rates that doesn't require signalling directly to miners
and their choice becomes "mine this thing now and get the fee directly"
versus "hope no one else mines it now, and that I get the chance to mine
the original higher fee transaction after activation, before anyone else
does", so at least the economically-rational choice should be to mine
the lower-fee double spend immediately. So it should be reasonable to
offer a higher fee for signalling, without risking that non-signalling
miners will be able to claim that high fee eventually.
I'm not sure the incentives about tying user-signalling for a soft-fork
to miner signalling for a soft-fork are entirely sound; but if they are
then just using nversion seems a lot more user-friendly than requiring
script changes to me. In particular, it doesn't require any setup or
teardown costs -- you don't have to get an input with a particular
script encoded that you can then spend to signal, and you don't have to
remember variations on output address when you want to spend a transaction
that was signalling; likewise changes to wallets are pretty simple and
don't have "you lost all your money" results if there's a bug. Well,
the above timeout procedure requires getting a recent coin as "setup",
but that's pretty trivial, at least.
Cheers,
aj
|
