ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-31 📝 Original message: Good morning aj and Rene, ...

📅 Original date posted:2021-08-31
📝 Original message:
Good morning aj and Rene,

> On Thu, Aug 26, 2021 at 04:33:23PM +0200, René Pickhardt via Lightning-dev wrote:
>
> > As we thought it was obvious that the function is not linear we only explained
> > in the paper how the jump from f(0)=0 to f(1) = ppm+base_fee breaks convexity.
>
> (This would make more sense to me as "f(0)=0 but f(epsilon)->b as
> epsilon->0, so it's discontinuous")

I as well, "discontinuous" is how I would understand it, and it really needs to be pointed out to me that f(0)=0 and the sudden step to f(1)=1*prop + base is problematic.

>
> > "Do we really want users to solve an NP-hard problem when
> > they wish to find a cheap way of paying each other on the Lightning Network?"
>
> FWIW, my answer to this is "sure, if that's the way it turns out".
>
> Another program which solves an NP-hard problem every time it runs is
> "apt-get install" -- you can simulate 3SAT using Depends: and Conflicts:
> relationships between packages.

Thank you for this, I now understand why functional package managers like Nix and Guix etc. exist.

> I worked on a related project in Debian
> back in the day that did a slightly more complicated variant of that
> problem, namely working out if updating a package in the distro would
> render other packages uninstallable (eg due to providing a different
> library version) -- as it turned out, that even actually managed to hit
> some of the "hard" NP cases every now and then. But it was never really
> that big a deal in practice: you just set an iteration limit and consider
> it to "fail" if things get too complicated, and if it fails too often,
> you re-analyse what's going on manually and add a new heuristic to cope
> with it.
>
> I don't see any reason to think you can't do roughly the same for
> lightning; at worst just consider yourself as routing on log(N) different
> networks: one that routes payments of up to 500msat at (b+0.5ppm), one
> that routes payments of up to 1sat at (b+ppm), one that routes payments
> of up to 2sat at (b+2ppm), one that routes payments of up to 4sat at
> (b+4ppm), etc. Try to choose a route for all the funds; if that fails,
> split it; repeat. In some case that will fail despite there being a
> possible successful multipath route, and in other cases it will choose a
> moderately higher fee path than necessary, but if you're talking a paying
> a 0.2% fee vs a 0.1% fee when the current state of the art is a 1% fee,
> that's fine.

Well, something similar is already done by C-Lightning, and the `pay` algorithm even includes a time limit after which it just fails instead of retrying (roughly equivalent to setting an iteration limit, and actually more practical since it is not the number of CPU iterations that matters, it is real time during which user economic preferences may change).

And for large enough payments, it *still* does not succeed often enough in practice.

I pointed out elsewhere that failure-to-pay has an economic cost.
This economic cost is the difference between the value of the product being bought, minus the value of the bitcoin being used to pay for it.
(remember, economic value is subjective to every economic actor; the economy is simply how the differences in value plays out as actors exchange objects, where each actor has its own subjective valuation of that value.)
We can ask the user explicitly for a numeric amount equivalent to this cost, by the simple question "how much are you willing to pay in order for this transaction to succeed?" i.e. "what is the maximum transaction fee you will accept?"

Thus, failing to deliver imposes an economic cost on users, a cost that Lightning Network, rightfully or not, has implicitly promised to reduce in comparison to onchain transactions.

For myself, I think a variant of Pickhardt-Richter payments can be created which *adapts to* the reality of the current network where `base_fee > 0` is common, but is biased against `base_fee > 0`, can be a bridge from the current network with `base_fee > 0` and a future with `#zerobasefee`.
With C-Lightning and its plugin nature allowing alternate implementations of `pay`, this can be done without requiring an entire new LN implementation.
If popular enough, because it demonstrates actual ability to transfer large funds at low fees, this can force forwarding nodes to learn that `#zerobasefee` earns them more funds (such as if they use a hill-climbing algorithm like I described to discover optimal feerates that gives them maximum earnings).
Then `#zerobasefee` just wins economically.

So I think this really just needs a good implementation somewhere.

Regards,
ZmnSCPxj