đź“… Original date posted:2021-08-15
đź“ť Original message:
Good morning Zmn!
That is indeed precisely what we do. We usually quantize the min-cost flow
into minimum shares of, say, 10kSat to 100kSat. This makes the algorithm
run faster and loses very little precision. It also gives a simple way of
dealing with (reasonable) min-htlc-size values.
Cheers,
Stefan
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
schrieb am So., 15. Aug. 2021, 16:03:
> Good morning lisa, aj, et al.,
>
>
> > The result is that micropayments have a different payment regime than
> “non-micropayments”, (which may still incentive almost irrational behavior)
> but at least there’s no *loss* felt by node operators for
> handling/supporting low value payments. 10k micropayments is worth 10sats.
> >
> > It’s also simple to implement and seems rather obvious in retrospect.
>
>
> It seems simple to implement for *forwarders*, but I think complicates the
> algorithm described by Pickhardt and Richter?
>
> On the other hand, the algorithm is targeted towards "large" payments, so
> perhaps the Pickhardt-Richter payment algo can be forced to have some
> minimum split size, and payments below this minimum size are just sent as
> single payments (on the assumption that such micropayments are so small
> that the probability of failure is negligible).
> That is, just have the `pay` command branch based on the payment size, if
> it is below the minimum size, just use the old try-and-try-until-you-die
> algo, otherwise use a variant on the Pickhardt-Richter algo that respects
> this minimum payment size.
> This somewhat implies a minimum on the possible feerate, which we could
> say is 1 ppm, maybe.
>
> So for example, the minimum size could be 1,000,000msat, or 1,000sat.
> If the payment is much larger than that, use the Pickhardt-Richter
> algorithm with zerobasefee.
> If payment is lower than that threshold, just do not split and do
> try-and-try-until-you-die.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210815/df395dd3/attachment-0001.html>;
Stefan Richter [ARCHIVE] /
npub19f…f4wf0
2023-06-09 13:03:26
in reply to nevent1q…jvqc
Author Public Key
npub19fnl48y9j4fk9w0a284mqvszq6fuppelqp2tcxf0s37l95avdtussf4wf0Seen on
wss://relay.nostr.bandPublished at
2023-06-09 13:03:26Event JSON
{
"id": "4af5a97b30372c52e82a941d83cc1cab5942ecb3c975c779227db90a0894f01e",
"pubkey": "2a67fa9c85955362b9fd51ebb032020693c0873f0054bc192f847df2d3ac6af9",
"created_at": 1686315806,
"kind": 1,
"tags": [
[
"e",
"9c2d9ebc7daf40e6a14ddb62eed3add34417e7bccd1a15aa0b16d2df92878dde",
"",
"root"
],
[
"e",
"77e1ca12666def10db8450741fc3207a6d9a9f89ae6e71d0075d031daf5bceea",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-08-15\n📝 Original message:\nGood morning Zmn!\n\nThat is indeed precisely what we do. We usually quantize the min-cost flow\ninto minimum shares of, say, 10kSat to 100kSat. This makes the algorithm\nrun faster and loses very little precision. It also gives a simple way of\ndealing with (reasonable) min-htlc-size values.\n\nCheers,\n Stefan\n\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nschrieb am So., 15. Aug. 2021, 16:03:\n\n\u003e Good morning lisa, aj, et al.,\n\u003e\n\u003e\n\u003e \u003e The result is that micropayments have a different payment regime than\n\u003e “non-micropayments”, (which may still incentive almost irrational behavior)\n\u003e but at least there’s no *loss* felt by node operators for\n\u003e handling/supporting low value payments. 10k micropayments is worth 10sats.\n\u003e \u003e\n\u003e \u003e It’s also simple to implement and seems rather obvious in retrospect.\n\u003e\n\u003e\n\u003e It seems simple to implement for *forwarders*, but I think complicates the\n\u003e algorithm described by Pickhardt and Richter?\n\u003e\n\u003e On the other hand, the algorithm is targeted towards \"large\" payments, so\n\u003e perhaps the Pickhardt-Richter payment algo can be forced to have some\n\u003e minimum split size, and payments below this minimum size are just sent as\n\u003e single payments (on the assumption that such micropayments are so small\n\u003e that the probability of failure is negligible).\n\u003e That is, just have the `pay` command branch based on the payment size, if\n\u003e it is below the minimum size, just use the old try-and-try-until-you-die\n\u003e algo, otherwise use a variant on the Pickhardt-Richter algo that respects\n\u003e this minimum payment size.\n\u003e This somewhat implies a minimum on the possible feerate, which we could\n\u003e say is 1 ppm, maybe.\n\u003e\n\u003e So for example, the minimum size could be 1,000,000msat, or 1,000sat.\n\u003e If the payment is much larger than that, use the Pickhardt-Richter\n\u003e algorithm with zerobasefee.\n\u003e If payment is lower than that threshold, just do not split and do\n\u003e try-and-try-until-you-die.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210815/df395dd3/attachment-0001.html\u003e",
"sig": "9c89dfd0ceee5305fc62807e666bf78258087979a9a7ad3c740f42209f55153bf5aff85ac869898a5f00410edea09ec5f88b71793f4551f1c9a232a4d81cb983"
}