You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's just a field in the protocol with the corresponding channel id (outgoing id for incoming HTLCs and incoming id for outgoing HTLCs), it's currently not copied to the model structure. The idea is to show it in the detailed channel information together with the other HTLC data. I'd need to test a few variants but most importantly I want to see the source or target node name. I think the specific channel id isn't that important because most nodes have just one channel per peer. I have some ideas about the way to show it. Maybe with arrows or another line (like From: <node alias> or To: <node alias> or ⇒ <node alias>, or maybe replace the Incoming: true/false line altogether, never liked it tbh even though I wrote it, etc.)
We have all channels indexed by chanpoint but not id. Maybe adding a second index would be worth it, it should take even less memory because it'd be a uint64->pointer map.
The text was updated successfully, but these errors were encountered:
It's just a field in the protocol with the corresponding channel id (outgoing id for incoming HTLCs and incoming id for outgoing HTLCs), it's currently not copied to the model structure. The idea is to show it in the detailed channel information together with the other HTLC data. I'd need to test a few variants but most importantly I want to see the source or target node name. I think the specific channel id isn't that important because most nodes have just one channel per peer. I have some ideas about the way to show it. Maybe with arrows or another line (like
From: <node alias>
orTo: <node alias>
or⇒ <node alias>
, or maybe replace theIncoming: true/false
line altogether, never liked it tbh even though I wrote it, etc.)We have all channels indexed by chanpoint but not id. Maybe adding a second index would be worth it, it should take even less memory because it'd be a uint64->pointer map.
The text was updated successfully, but these errors were encountered: