What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-09 13:03:26

ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2021-08-15 đź“ť Original message: Good morning lisa, aj, et ...

đź“… 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
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l