NodeId #601
NodeId #601
Conversation
Adds the NodeId interface that can be either a public key or a pair channel id, direction that's more compact. This is used as introduction node for blinded routes. We also use NodeId for the next node to relay a message to. Which is not in the spec but is necessary for us since we have no way to resolve the compact node id to a public key ourselves. It requires a compatible peer that accepts this format.
| @@ -22,14 +23,14 @@ sealed class RouteBlindingEncryptedDataTlv : Tlv { | |||
| } | |||
|
|
|||
| /** Id of the next node. */ | |||
| data class OutgoingNodeId(val nodeId: PublicKey) : RouteBlindingEncryptedDataTlv() { | |||
| data class OutgoingNodeId(val nodeId: NodeId) : RouteBlindingEncryptedDataTlv() { | |||
There was a problem hiding this comment.
You're modifying the official spec TLV here (tag = 4). We need to get agreement on this change at the spec level for that, otherwise we may have painful compatibility issues to handle in the future...I believe that changing the outgoing_node_id TLV to use this new sciddir_or_pubkey makes a lot of sense and should be in the BOLTs, don't you? This is an opportunity to create a small spec PR based on master that:
- extracts the
sciddir_or_pubkeyfrom the offers spec PR - uses it in the
outgoing_node_idTLV field of onion messages / blinded paths - adds or modifies a test vector to use this
I expect that this spec PR would be accepted somewhat quickly, and it would make the offers spec PR slightly smaller in scope. It's also important to create that spec PR before people actually start using offers, this way we can just change the TLV without caring about backwards-compat.
There was a problem hiding this comment.
We can merge that code to both lightning-kmp and eclair though, even before the spec PR gets accepted, because:
- until we ship bolt 12 support in phoenix, we actually will never create such tlv fields
- on the eclair side, we're just adding support for reading this new case, not writing it, so it won't impact other nodes and we can update the code without caring about backwards-compat
But we should still create a spec PR to get wide support for this feature!
| val publicKey = PublicKey(ByteArray(1) { firstByte.toByte() } + bytes(input, 32)) | ||
| return EncodedNodeId.Plain(publicKey) | ||
| } else { | ||
| throw IllegalArgumentException("unexpected first byte: $firstByte") |
There was a problem hiding this comment.
Note that you'll need to be careful when decrypting an onion message and decoding its content to catch that exception.
src/commonTest/kotlin/fr/acinq/lightning/wire/RouteBlindingTestsCommon.kt
Show resolved
Hide resolved
Adds the NodeId interface that can be either a public key or a pair channel id, direction that's more compact. This is used as introduction node for blinded routes. We also use NodeId for the next node to relay a message to. Which is not in the spec but is necessary for us since we have no way to resolve the compact node id to a public key ourselves. It requires a compatible peer that accepts this format.