Rather than use an invoice, we could just negotiate the on-Lightning HTLC details directly. The only relevant details are the on-Lightning channel ID, amount, timelock, and hash (or point once PTLCs are deployed)
The invoice spec is open-ended, and there may be future new fields added which affect how payment is done. Ideally the peerswap spec would require that any future unknown fields are simply not allowed. as we cannot predict how those would affect a standard invoice-paying implementation.
A robust peerswap implementation would have to itself parse the invoice, and ignore any unknown fields, just getting the minimal information, just to avoid the possibility that new fields may effect the payment algorithm in unexpected and unknown ways. Then it has to pas on those details to some low-level HTLC-offerring code. This means that the invoice format is not an advantage, and is potentially just a liability.
Rather than use an invoice, we could just negotiate the on-Lightning HTLC details directly. The only relevant details are the on-Lightning channel ID, amount, timelock, and hash (or point once PTLCs are deployed)
The invoice spec is open-ended, and there may be future new fields added which affect how payment is done. Ideally the peerswap spec would require that any future unknown fields are simply not allowed. as we cannot predict how those would affect a standard invoice-paying implementation.
A robust peerswap implementation would have to itself parse the invoice, and ignore any unknown fields, just getting the minimal information, just to avoid the possibility that new fields may effect the payment algorithm in unexpected and unknown ways. Then it has to pas on those details to some low-level HTLC-offerring code. This means that the invoice format is not an advantage, and is potentially just a liability.