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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 049D21DC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 04:31:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [103.22.144.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9089310F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 04:31:41 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 023D4140771; Fri, 9 Oct 2015 15:31:39 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Peter Todd <pete@petertodd.org>
In-Reply-To: <20151008174120.GA9291@muck>
References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au>
<20151008174120.GA9291@muck>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
(x86_64-pc-linux-gnu)
Date: Fri, 09 Oct 2015 12:08:06 +1030
Message-ID: <87pp0okeip.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
T_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] CHECKSEQUENCEVERIFY - We need more usecases to
motivate the change
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: Fri, 09 Oct 2015 04:31:43 -0000
Peter Todd <pete@petertodd.org> writes:
> On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>> writes:
>> > However I don't think we've done a good job showing why we need to
>> > implement this feature via nSequence.
>>
>> It could be implemented in other ways, but nSequence is the neatest and
>> most straightforward I've seen.
>>
>> - I'm not aware of any other (even vague) proposal for its use? Enlighten?
>
> There's three that immediately come to mind:
>
> Gregory Maxwell has proposed it as a way of discouraging miners from
> reorging chains, by including some of the low-order bits of a previous
> block header in nSequence.
>
> A few people have proposed implementing proof-of-stake blocksize voting
> with nSequence.
Excellent, thanks! It's good to have such ideas as a compass. PoS
voting seems like it won't be a problem in 5 bits.
The "prevbits" idea would want more bits; naively 64 would be good, but
I think there are some tricks we can use to make 32 work OK. We would
have to then split between nLocktime (if available) and multiple
nSequence fields, and it would weaken it for some txs.
There is one easy solution: change the BIP wording from:
-For transactions with an nVersion of 2 or greater,
+For transactions with an nVersion of 2,
And on every tx bump, we decide whether to keep this scheme (mempool
would enforce it always).
Cheers,
Rusty.
|
