Requesting BIP assignment; Flexible Transactions.

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!

-Tadge

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!

On Thu, Sep 22, 2016 at 10:47:03AM +0200, Tom via bitcoin-dev wrote:

> 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.

CSV uses per-input sequence numbers; you only have a per-tx equivalent.

On Thursday, 22 September 2016 14:27:29 CEST Peter Todd wrote:

> CSV uses per-input sequence numbers; you only have a per-tx equivalent.

I think you misunderstand tagged systems at a very basic level. You think that html can only use a bold tag <b> once in a document? Thats equivalent to what you are saying.

Your comment is rather embarrassing, I have to point out. You may want to read a bit more before you comment more.

Hi Tom

> I think you misunderstand tagged systems at a very basic level.  You think
> that html can only use a bold tag <b> once in a document? Thats equivalent
> to what you are saying.

Would the "additional" segment contain the same amount of nSequence-equivalent token as the number of inputs in the "inputs" segment? What if you only want to add a per-input-token in the additional segment for a certain input (assume last input)? I guess the fundamental difference to html is the possible nesting.

However, I think that should be mentioned/specified in the BIP.

</jonas>

On Thursday, 22 September 2016 21:59:12 CEST Jonas Schnelli via bitcoin-dev wrote:

> Hi Tom
>
> > I think you misunderstand tagged systems at a very basic level.  You
> > think that html can only use a bold tag <b> once in a document? Thats
> > equivalent to what you are saying.
>
> Would the "additional" segment contain the same amount of
> nSequence-equivalent token as the number of inputs in the "inputs"
> segment?

At this point I don't know what it should look like, I have not had time to look deeply into BIP68. Is this what you would suggest it to look like? I rather figured spending limitations would be assigned to an output, not an input.

> However, I think that should be mentioned/specified in the BIP.

It can be, and likely should be. This BIP doesn't pretend to be finished yet.

I welcome any and all discussion about this, it only serves to make the end result stronger!

On Thu, Sep 22, 2016 at 08:37:29PM +0200, Tom via bitcoin-dev wrote:

> On Thursday, 22 September 2016 14:27:29 CEST Peter Todd wrote:
> > CSV uses per-input sequence numbers; you only have a per-tx equivalent.
>
> I think you misunderstand tagged systems at a very basic level.  You think
> that html can only use a bold tag <b> once in a document? Thats equivalent
> to what you are saying.
>
> Your comment is rather embarrassing, I have to point out. You may want to
> read a bit more before you comment more.

Not sure if the comparison to XML and HTML holds: the lack of closing tags makes the meaning of individual tokens ambiguous, like I pointed out before. The use of segments gives at most two levels of nesting, so any relationship among tokens in the same segment has to rely on their relative position, which could result in ambiguities, like whether a tag refers to a single input or the transaction as a whole.

Cheers, Christian

On Friday, 23 September 2016 13:55:50 CEST Christian Decker via bitcoin-dev wrote:

> Not sure if the comparison to XML and HTML holds: the lack of closing
> tags makes the meaning of individual tokens ambiguous, like I pointed
> out before. The use of segments gives at most two levels of nesting,
> so any relationship among tokens in the same segment has to rely on
> their relative position, which could result in ambiguities, like
> whether a tag refers to a single input or the transaction as a whole.

Practically all tagged formats make ordering a requirement, so indeed this is relevant, and not unique.

For instance if you write;
  <div> Some line </br>Another line</br>3rd line</div>
you can get a good idea of how ordering is relevant. You can reuse any item
many times.

Whenever there is a possible confusion the specification specifically explains which order to use.

I'm not sure what you mean with the idea this;

>  The use of segments gives at most two levels of nesting

It looks like you assume there is some opening and closing tags, since otherwise there would be no nesting. Such tags are not intended, nor documented.

> so any relationship among tokens in the same segment has to rely on
> their relative position, which could result in ambiguities, like
> whether a tag refers to a single input or the transaction as a whole.

I quoted parts of the spec in your previous email stating the same thing, but I'll repeat here. Any place that has any sort of possibility to be ambiguous is specified specifically to have an order. This makes writing and parsing easier.

Since you wrote two emails now with the same issue, and I addressed it twice, I would urge you to write out some examples which may be confusing and if you find that the spec is indeed missing requirements then please share it with us. I did this some time ago and it helps understanding the ideas by having actual explicit examples. I am not aware of any sort of ambiguities that the spec allows.

Cheers!