summaryrefslogtreecommitdiff
path: root/9c/756f6e82ef99cc73943aa143e9ae6fcd73d908
blob: bdfb4e79a0d470899696b0d2f9cff2c64808641a (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
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
120
121
122
123
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C0D4674
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 21 Nov 2015 14:13:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED915134
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 21 Nov 2015 14:13:26 +0000 (UTC)
Received: by wmec201 with SMTP id c201so53816185wme.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 21 Nov 2015 06:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=ILxBGAzB9VgXqU6dMP7Va5Ki+gaB3PKlgostpJAoHMg=;
	b=aQsFs4PGk+FdeW9vQbEjloTGSJAWiu50VHdr+2CqaSdIGfMIrIPrqwCJDq6nBNRr04
	YRnk6E2SpKj5kKuxtOBQwRJnJmT+FoKJVcqArUYDEokPozmLOSrQI/e80bT2BGYLabZC
	mujXdOlM51gaiMAIW6VqWeeyqHvl9OerijydMosBzeBPnBq2rU/L5v/4/TnQEVYZSMp0
	6UgevW1UFua6PNYK0vKUuYOBL4aWf0xoWkOQwh0wJnqEkpZYhUY79WE6R/TfV8thTMxx
	dj4r125GjWhGqsWdAXWhYyJxfK8+kYGMYsQ1q6ulUDQZS89nQ9zd2MKIkAw/+kh1WHwj
	xZXQ==
X-Received: by 10.28.88.5 with SMTP id m5mr6359106wmb.54.1448115205329; Sat,
	21 Nov 2015 06:13:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.61.135 with HTTP; Sat, 21 Nov 2015 06:13:05 -0800 (PST)
From: Btc Drak <btcdrak@gmail.com>
Date: Sat, 21 Nov 2015 14:13:05 +0000
Message-ID: <CADJgMzvzfLky3QOGiuUCyjpvQXom3WXUfxuA5_r7jE2itJwGCw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11441eb8685a5105250d98f3
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
	HTML_MESSAGE, 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
Subject: [bitcoin-dev] BIP68: Relative lock-time through consensus-enforced
	sequence numbers (update)
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: Sat, 21 Nov 2015 14:13:27 -0000

--001a11441eb8685a5105250d98f3
Content-Type: text/plain; charset=UTF-8

As I am sure you are aware, for the last 5 months work has been on-going to
create a relative lock-time proposal using sequence numbers. The
implementation can be found at https://github.com/bitcoin/bitcoin/pull/6312.
The current implementation is "mempool-only" and the soft-fork would be
deployed at a later stage.

Over these months there has been various discussion back and forth to
refine the details.

I have updated the BIP text now according to the details that were
discussed in mid-October[1][2] and have extensively clarified the text.

To recap, the overall picture for relative lock-time is that BIP68
introduces consensus rules using some of the nSequence field, while BIP112
creates a new opcode OP_CHECKSEQUENCEVERIFY (PR #6564) so relative
lock-time can be verified from the Bitcoin scripting language. Ideally we
would soft-fork BIP68, BIP112 (CSV) and 113 (MTP) together. BIP113 has been
deployed in 0.11.2 as mempool policy so miners should be applying this
policy as they deploy version 4 blocks for the ongoing CLTV soft-fork
(currently at 42% at the time of writing).

I am writing this mail to draw your attention to the BIP68 pull-requests
and to request final review at:

BIP68 text - https://github.com/bitcoin/bips/pull/245
BIP68 implementation - https://github.com/bitcoin/bitcoin/pull/6312

Discussion references:
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011357.html
[2] http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444928045.0

--001a11441eb8685a5105250d98f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>As I am sure you are aware, for the last 5 months wor=
k has been on-going to create a relative lock-time proposal using sequence =
numbers. The implementation can be found at=C2=A0<a href=3D"https://github.=
com/bitcoin/bitcoin/pull/6312">https://github.com/bitcoin/bitcoin/pull/6312=
</a>. The current implementation is &quot;mempool-only&quot; and the soft-f=
ork would be deployed at a later stage.</div><div><br></div><div>Over these=
 months there has been various discussion back and forth to refine the deta=
ils.</div><div><br></div><div>I have updated the BIP text now according to =
the details that were discussed in mid-October[1][2] and have extensively c=
larified the text.</div><div><br></div><div>To recap, the overall picture f=
or relative lock-time is that BIP68 introduces consensus rules using some o=
f the nSequence field, while BIP112 creates a new opcode OP_CHECKSEQUENCEVE=
RIFY (PR #6564) so relative lock-time can be verified from the Bitcoin scri=
pting language. Ideally we would soft-fork BIP68, BIP112 (CSV) and 113 (MTP=
) together. BIP113 has been deployed in 0.11.2 as mempool policy so miners =
should be applying this policy as they deploy version 4 blocks for the ongo=
ing CLTV soft-fork (currently at 42% at the time of writing).<br></div><div=
><br></div><div>I am writing this mail to draw your attention to the BIP68 =
pull-requests and to request final review at:</div><div><br></div>BIP68 tex=
t - <a href=3D"https://github.com/bitcoin/bips/pull/245">https://github.com=
/bitcoin/bips/pull/245</a><div>BIP68 implementation - <a href=3D"https://gi=
thub.com/bitcoin/bitcoin/pull/6312">https://github.com/bitcoin/bitcoin/pull=
/6312</a></div><div><br></div><div>Discussion references:</div><div><div>[1=
]=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
015-October/011357.html">https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/2015-October/011357.html</a></div><div>[2]=C2=A0<a href=3D"http://bit=
coinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444928045.0">http://bitcoin=
stats.com/irc/bitcoin-dev/logs/2015/10/15#l1444928045.0</a></div><div><br><=
/div><div><br></div><div><div><br></div></div></div></div>

--001a11441eb8685a5105250d98f3--