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
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 776E9AF6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 08:47:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8D3E128
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 08:47:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102])
by mx-out02.mykolab.com (Postfix) with ESMTPS id 7458263480;
Thu, 22 Sep 2016 10:47:05 +0200 (CEST)
From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org, adiabat <rx@awsomnet.org>
Date: Thu, 22 Sep 2016 10:47:03 +0200
Message-ID: <1530052.vkWv7VPOpL@garp>
In-Reply-To: <CAKEeUhjisp8qdXDNz3C+pB1MUTfvmHZPmsE-f0DVTxnph6NmMQ@mail.gmail.com>
References: <CAKEeUhjisp8qdXDNz3C+pB1MUTfvmHZPmsE-f0DVTxnph6NmMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 22 Sep 2016 09:13:33 +0000
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
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: Thu, 22 Sep 2016 08:47:09 -0000
On Wednesday 21 Sep 2016 18:45:55 adiabat via bitcoin-dev wrote:
> Hi-
>
> One concern is that this doesn't seem compatible with Lightning as
> currently written. Most relevant is that non-cooperative channel close
> transactions in Lightning use OP_CHECKSEQUENCEVERIFY, which references the
> sequence field of the txin; if the txin doesn't have a sequence number,
> OP_CHECKSEQUENCEVERIFY can't work.
>
> LockByBlock and LockByTime aren't described and there doesn't seem to be
> code for them in the PR (186). If there's a way to make OP_CLTV and OP_CSV
> work with this new format, please let us know, thanks!
LockByBlock and LockByTime are still TODOs because I didn't have time to go
in-dept into how BIP68 does the encoding.
The intent is that these tags, while loading, will set the sequence integer in
the txin as the old version does. And while saving we do the reverse.
In other words; the lack of sequence number in the saved format doesn't affect
the in-memory format of the transaction. The in-memory version is the one that
script will operate on.
This means that there is no change in how CSV will work before and after on
any level other than serialisation.
Flexible Transactions is definitely meant to support the Lightning Network, so
any problems you find is something we should solve before it ships.
Thanks for your email!
|
