Good morning Matt and all,
> Please be careful accepting the faulty premise that the proposed algorithm is
> “optimal”. It is optimal under a specific heuristic used to approximate what
> the user wants. In reality, there are a ton of different things to balance,
> from CLTV to feed to estimated failure probability calculated from node
> online percentages at-open liquidity, and even fees.
It may be possible to translate all these "things to balance" to a single unit,
the millisatoshi.
* CLTV-delta
- The total CLTV-delta time is the worst-case amount of time that your
outgoing payment will be stalled.
- We can compute the expected nominal rate of return if the funds were
instead put in a random Bitcoin-denominated investment, getting back a
conversion ratio from time units to percentage of your funds.
This is what C-Lightning already does via the `riskfactor` parameter.
* Node failure probablity
- Can be multiplied with channel failure probability (the one based on the
channel capacity).
- As I pointed out elsewhere, we can ask the user "up to how much are you
willing to pay in fees?", and that amount is the cost of failure (because
economics; see my other mail); the failure probability times the cost of
failure is the effective cost of this path.
* Fees
- Are already denominated in millisatoshi.
One unit to rule them all....
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
