channel-id and min_conf

[lightning]

channel-id and min_conf

[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 [email protected] 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.