Do extra hop channels in a BOLT#11 invoice need to exist on chain?

Do extra hop channels in a BOLT#11 invoice need to exist on chain?

According to the BOLT#11 specification, a node may add extra routing information for private channels to an invoice, where they specify the public key of the penultimate hop, along with the short_channel_id.

r (3): data_length variable. One or more entries containing extra routing information for a private route; there may be more than one r field

  • pubkey (264 bits)
  • short_channel_id (64 bits)
  • ...

However, unlike channels announced through a channel_announcement message, there are no signatures to prove that the invoice payee actually owns that channel, or even that it really exists. Technically, it appears that the invoice creator could point to any valid 2-of-2 UTXO on the chain and claim it to be their private channel.

Do existing implementations check whether the transaction referred to by the r field's short_channel_id actually exists on the blockchain and that they are valid 2-of-2 multisig transactions?

If not, could short_channel_id in the invoice r field be re-purposed to refer to some abstract account which the pubkey in the hop information has custody of (Such that the pubkey node unwraps the last onion packet himself and signs any messages with the private key associated with the account)?

A user sending a payment should not need to worry about whether the channel really exists, as long as they receive the payment from the node who owns pubkey.

Otherwise, if there are any potential risks, should the BOLT#11 specification also be modified to include a pair of signatures for the funding transaction which short_channel_id refers to?

http://bit.ly/2Wsi8Fb

Comments

Popular posts from this blog

sendrawtransaction and txn-mempool-conflict

couldn't connect to server: EOF reached (code 1)