Currently, route randomization means that sometimes we do not take the direct route.
However, it should be remembered that route randomization is intended to prevent third parties from learning all of our payments.
And if a one-channel route exists that is viable, we should instead consider paying it so that none of our payment information to the payee node is even leaked to intermediaries.
Thus, for this particular case (a route exists that is direct between payer to payee, and is viable for paying), route randomization is hurtful.
--
One might argue, that perhaps we might not want to let the payee node know that we are in fact directly connected, so using an alternate route will at least obscure this.
One can also argue that the payee probably already knows where we live in order to deliver their goods to us, but at least we can prevent the payee from having an idea of where our node is on LN.
In addition, this is viable only if we regularly transact with the payee anyway. For one-off purchases, being directly connected to the payee is largely immaterial.
--
I can implement this now with current payalgo.
However, we will need to change the payalgo almost completely in order to support ZKCP-preserving multipath payments anyway, so I wonder if I should instead defer this particular subfeature to the new payalgo.
Currently, route randomization means that sometimes we do not take the direct route.
However, it should be remembered that route randomization is intended to prevent third parties from learning all of our payments.
And if a one-channel route exists that is viable, we should instead consider paying it so that none of our payment information to the payee node is even leaked to intermediaries.
Thus, for this particular case (a route exists that is direct between payer to payee, and is viable for paying), route randomization is hurtful.
--
One might argue, that perhaps we might not want to let the payee node know that we are in fact directly connected, so using an alternate route will at least obscure this.
One can also argue that the payee probably already knows where we live in order to deliver their goods to us, but at least we can prevent the payee from having an idea of where our node is on LN.
In addition, this is viable only if we regularly transact with the payee anyway. For one-off purchases, being directly connected to the payee is largely immaterial.
--
I can implement this now with current payalgo.
However, we will need to change the payalgo almost completely in order to support ZKCP-preserving multipath payments anyway, so I wonder if I should instead defer this particular subfeature to the new payalgo.