From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org, adiabat <rx@awsomnet.org>
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Date: Thu, 22 Sep 2016 10:47:03 +0200 [thread overview]
Message-ID: <1530052.vkWv7VPOpL@garp> (raw)
In-Reply-To: <CAKEeUhjisp8qdXDNz3C+pB1MUTfvmHZPmsE-f0DVTxnph6NmMQ@mail.gmail.com>
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!
next prev parent reply other threads:[~2016-09-22 8:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 22:45 [bitcoin-dev] Requesting BIP assignment; Flexible Transactions adiabat
2016-09-22 8:47 ` Tom [this message]
2016-09-22 18:27 ` Peter Todd
2016-09-22 18:37 ` Tom
2016-09-22 19:59 ` Jonas Schnelli
2016-09-22 20:07 ` Tom
2016-09-23 11:55 ` Christian Decker
2016-09-23 13:13 ` Tom
-- strict thread matches above, loose matches on Subject: below --
2016-09-20 17:15 Tom
2016-09-20 21:31 ` Luke Dashjr
2016-09-21 9:32 ` Tom
2016-09-20 21:56 ` Peter Todd
2016-09-21 9:32 ` Tom
2016-09-22 18:26 ` Peter Todd
2016-09-22 18:47 ` Tom
2016-09-21 12:00 ` Andreas Schildbach
2016-09-21 12:58 ` Tom
[not found] ` <CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
2016-09-21 18:01 ` Gregory Maxwell
2016-09-22 8:56 ` Tom
2016-09-22 11:10 ` Christian Decker
2016-09-22 12:09 ` Tom
2016-09-23 11:42 ` Christian Decker
2016-09-23 13:17 ` Tom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1530052.vkWv7VPOpL@garp \
--to=tomz@freedommail.ch \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=rx@awsomnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox