📅 Original date posted:2021-08-31
📝 Original message:
Am Di., 31. Aug. 2021 um 10:29 Uhr schrieb ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org>:
> 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`.
I have been thinking about your idea (at least what I understood of
it) of using amount*prop_fee + amount*base_fee/min_flow_size, where
min_flow_size is a suitable quantization constant (say, 10k or 100k
sats, may also chosen dynamically), as a component of the cost
function, and I am pretty sure it is great at achieving exactly what
you are proposing here. This is a nicely convex (even linear in this
component) function and so it's easy to find min-cost flows for it. It
solves the problem (that I hadn't thought about before) that you have
pointed out in splitting flows into HTLCs. If you use
min_flow_size=max_htlc_size, it is even optimal (for this
min_flow_size). If you use a smaller min_flow_size, it is still
optimal for channels with base_fee=0 but overestimates the fee for
channels with base_fee>0, and is less accurate the smaller the
min_flow_size and the larger the base_fee. So it will be biased
against channels with larger base_fee. But notice that with min-cost
flows, we are rarely looking for the cheapest solution anyway, because
these solutions (if they include more than one path) will usually
fully saturate the cheapest channels and thus have very low success
probability. So all in all, I believe you found a great practical
solution for this debate. Everybody is free to use any base_fee they
chose, we get a workable cost function, and I conjecture that
economics will convince most people to choose a zero or low base_fee.
Cheers
Stefan
Stefan Richter [ARCHIVE] /
npub19f…f4wf0
2023-06-09 13:03:36
in reply to nevent1q…ejf2
Author Public Key
npub19fnl48y9j4fk9w0a284mqvszq6fuppelqp2tcxf0s37l95avdtussf4wf0Published at
2023-06-09 13:03:36Event JSON
{
"id": "7d7a9d6387bb75209a83afd8d6e3c5361dbc8f1e6e28511dd7f44fdb9892af7d",
"pubkey": "2a67fa9c85955362b9fd51ebb032020693c0873f0054bc192f847df2d3ac6af9",
"created_at": 1686315816,
"kind": 1,
"tags": [
[
"e",
"01d9c9502f49dd38e6e1b40b488725a995f866aed238951b8ee32ae941e02526",
"",
"root"
],
[
"e",
"5e863e44ef6684c18ef3a79e51640b9bbeb098dcf221307c470a69bd7454af82",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-08-31\n📝 Original message:\nAm Di., 31. Aug. 2021 um 10:29 Uhr schrieb ZmnSCPxj via Lightning-dev\n\u003clightning-dev at lists.linuxfoundation.org\u003e:\n\n\u003e 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 \u003e 0` is common, but is biased against `base_fee \u003e 0`, can be a bridge from the current network with `base_fee \u003e 0` and a future with `#zerobasefee`.\n\nI have been thinking about your idea (at least what I understood of\nit) of using amount*prop_fee + amount*base_fee/min_flow_size, where\nmin_flow_size is a suitable quantization constant (say, 10k or 100k\nsats, may also chosen dynamically), as a component of the cost\nfunction, and I am pretty sure it is great at achieving exactly what\nyou are proposing here. This is a nicely convex (even linear in this\ncomponent) function and so it's easy to find min-cost flows for it. It\nsolves the problem (that I hadn't thought about before) that you have\npointed out in splitting flows into HTLCs. If you use\nmin_flow_size=max_htlc_size, it is even optimal (for this\nmin_flow_size). If you use a smaller min_flow_size, it is still\noptimal for channels with base_fee=0 but overestimates the fee for\nchannels with base_fee\u003e0, and is less accurate the smaller the\nmin_flow_size and the larger the base_fee. So it will be biased\nagainst channels with larger base_fee. But notice that with min-cost\nflows, we are rarely looking for the cheapest solution anyway, because\nthese solutions (if they include more than one path) will usually\nfully saturate the cheapest channels and thus have very low success\nprobability. So all in all, I believe you found a great practical\nsolution for this debate. Everybody is free to use any base_fee they\nchose, we get a workable cost function, and I conjecture that\neconomics will convince most people to choose a zero or low base_fee.\n\nCheers\n Stefan",
"sig": "160a40ebb2f62aa3af519542cb7ead756fddc49b9f735222a12a4c6a729d80accb524f89cb458bf58d51ef59d4baefc8c29775cb51d64a3099bedb334d96dc02"
}