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"
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Precedence: list

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!