đź“… Original date posted:2021-08-15
đź“ť Original message:
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
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 15:03:26
in reply to nevent1q…7d5x
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 15:03:26Event JSON
{
"id": "77e1ca12666def10db8450741fc3207a6d9a9f89ae6e71d0075d031daf5bceea",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315806,
"kind": 1,
"tags": [
[
"e",
"9c2d9ebc7daf40e6a14ddb62eed3add34417e7bccd1a15aa0b16d2df92878dde",
"",
"root"
],
[
"e",
"dfa978e7296bfd34d37c40a33280fdb7c6ef89a899b350941ca98532c3e34c00",
"",
"reply"
],
[
"p",
"804770eb58d163d63f0f996fd6bebabe1b8c582a5dd544cf61bba0bc5335720a"
]
],
"content": "📅 Original date posted:2021-08-15\n📝 Original message:\nGood morning lisa, aj, et al.,\n\n\n\u003e 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.\n\u003e\n\u003e It’s also simple to implement and seems rather obvious in retrospect.\n\n\nIt seems simple to implement for *forwarders*, but I think complicates the algorithm described by Pickhardt and Richter?\n\nOn 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).\nThat 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.\nThis somewhat implies a minimum on the possible feerate, which we could say is 1 ppm, maybe.\n\nSo for example, the minimum size could be 1,000,000msat, or 1,000sat.\nIf the payment is much larger than that, use the Pickhardt-Richter algorithm with zerobasefee.\nIf payment is lower than that threshold, just do not split and do try-and-try-until-you-die.\n\nRegards,\nZmnSCPxj",
"sig": "401190a12eb16d2aec619aed339a4348d7a93964f36c87c665c26403cfe0c99abf4185fc7d30761c9aa656530d3d8ba54b85bf40350a2720af09b1bf767af416"
}