channel-id and min_conf

[pm47]

    type: 36 (MSG_FUNDING_LOCKED)
    data:
        [8:temporary-channel-id]
        [8:channel-id]
        [32:next-key-offset]
        [33:next-revocation-halfkey]

I have two questions about the channel-id field:

1. A min_conf value of 0 or 1 could lead to each party computing a different channel-id. Easiest way is probably to just enforce a minimum value for min_conf? Yes a MIN_MIN_CONF!
2. If we choose a MIN_MIN_CONF high enough so that the probability of computing a different channel-id is extremely low, why do we even need to specify the channel-id in this message? If we prefer to keep it here, then we need to specify what happens when they are not the same (probably just close the connection). I'd rather remove it, since we still need to handle the general case where we receive messages with unknown channel ids (e.g. in htlc messages).

Cheers,

Pierre

[Roasbeef]

Why would the min_conf attribute have any direct affect on the channel-id? The temporary-channel-id is in place in order to properly de-multiplex updates to pending channels in the scenario that a node attempts to open up several channels at once.

The channel-id on this message is in place so future updates to that channel (htlc adds, settles, etc) are properly targeted in the case of multiple channels open between nodes.

Personally, I'd rather just use the full funding outpoint (txid:value) to identity updates to channels as it's much more stable than a ID based off of a block height or tx offset. However, with the way it's currently specified in the draft spec, I don't see how both sides could ever compute different channel ID's aside from re-orgs.

[pm47]

Why would the min_conf attribute have any direct affect on the channel-id?

Consider the following scenario where min_conf=1:

                                   +---+
                                 --|   | <-- seen by A
                                /  +---+
           +---+      +---+    /  
...  ------|   |------|   |----
           +---+      +---+    \
                                \  +---+
                                 --|   | <-- seen by B
                                   +---+

A and B will compute a different channel-id right?

Personally, I'd rather just use the full funding outpoint (txid:value) to identity updates to channels as it's much more stable than a ID based off of a block height or tx offset.

I still like the short id, because it may cause trouble only if a reorg occurs and min_conf is too low, and in that case the funder may double spend the funding tx which is a far greater concern anyway.

[rustyrussell]

Pierre-Marie Padiou notifications@github.com writes:

Why would the min_conf attribute have any direct affect on the channel-id?

Consider the following scenario where min_conf=1:

                                   +---+
                                 --|   | <-- seen by A
                                /  +---+
           +---+      +---+    /  
...  ------|   |------|   |----
           +---+      +---+    \
                                \  +---+
                               --|   | <-- seen by B
                                 +---+

A and B will compute a different channel-id right?

Personally, I'd rather just use the full funding outpoint (txid:value) to identity updates to channels as it's much more stable than a ID based off of a block height or tx offset.

Well, personally I'd rather remove all of this muxing stuff from the
spec until a later date, but...

I still like the short id, because it may cause trouble only if a reorg occurs and min_conf is too low, and in that case the funder may double spend the funding tx which is a far greater concern anyway.

Yes: invalid channel ID after we consider funding locked is grounds for
panic. The protocol implications are kind of secondary...

Cheers,
Rusty.

[pm47]

Note: Addressed in commit 04cf906 of PR #1 by forcing min_conf=6, and has been included in competing PR #11: will close when either PR gets merged.