public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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!


  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