Anthony Towns [ARCHIVE] on Nostr: đź“… Original date posted:2018-11-07 đź“ť Original message: On Wed, Nov 07, 2018 at ...
đź“… Original date posted:2018-11-07
đź“ť Original message:
On Wed, Nov 07, 2018 at 02:26:29AM +0000, Gert-Jaap Glasbergen wrote:
> > Otherwise, if you're happy accepting 652 satoshis, I don't see why you
> > wouldn't be happy accepting an off-chain balance of 652.003 satoshis;
> > you're no worse off, in any event.
> I wouldn’t be worse off when accepting the payment, I agree. I can safely ignore whatever fraction was sent if I don’t care about it anyway. The protocol is however expecting (if not demanding) me to also route payments with fractions, provided they are above the set minimum. In that case I’m also expected to send out fractions. Even though they don’t exist on-chain, if I send a fraction of a satoshi my new balance will be 1 satoshi lower on-chain since everything is rounded down.
But that's fine: suppose you want everything divided up into lots of
1 satoshi, and you see 357.719 satoshis coming in and 355.715 satoshis
going out. Would you have accepted 357 satoshis going in (rounded down)
and 356 satoshis going out (rounded up)? If so, you're set. If not,
reject the HTLC as not having a high enough fee.
Yes, you're still expected to send fractions of a satoshi around, but
that doesn't have to affect your accounting (except occassionally to
your benefit when you end up with a thousand millisatoshis).
I think you can set your fee_base_msat to 2000 msat to make sure every
HTLC you route pays you at least a satoshi, even with losses from
rounding. If you're willing to find yourself having routed payments for
free (after rounding), then setting it to 1000 msat should work too.
> > Everything in open source is configurable by end users: at worst, either
> > by them changing the code, or by choosing which implementation to use…
> Well, yes, in that sense it is. But the argument was made that it’s too complex for average users to understand: I agree there, [...]
Then it's not really a good thing for different implementations to have
as a differentiator...
Cheers,
aj
đź“ť Original message:
On Wed, Nov 07, 2018 at 02:26:29AM +0000, Gert-Jaap Glasbergen wrote:
> > Otherwise, if you're happy accepting 652 satoshis, I don't see why you
> > wouldn't be happy accepting an off-chain balance of 652.003 satoshis;
> > you're no worse off, in any event.
> I wouldn’t be worse off when accepting the payment, I agree. I can safely ignore whatever fraction was sent if I don’t care about it anyway. The protocol is however expecting (if not demanding) me to also route payments with fractions, provided they are above the set minimum. In that case I’m also expected to send out fractions. Even though they don’t exist on-chain, if I send a fraction of a satoshi my new balance will be 1 satoshi lower on-chain since everything is rounded down.
But that's fine: suppose you want everything divided up into lots of
1 satoshi, and you see 357.719 satoshis coming in and 355.715 satoshis
going out. Would you have accepted 357 satoshis going in (rounded down)
and 356 satoshis going out (rounded up)? If so, you're set. If not,
reject the HTLC as not having a high enough fee.
Yes, you're still expected to send fractions of a satoshi around, but
that doesn't have to affect your accounting (except occassionally to
your benefit when you end up with a thousand millisatoshis).
I think you can set your fee_base_msat to 2000 msat to make sure every
HTLC you route pays you at least a satoshi, even with losses from
rounding. If you're willing to find yourself having routed payments for
free (after rounding), then setting it to 1000 msat should work too.
> > Everything in open source is configurable by end users: at worst, either
> > by them changing the code, or by choosing which implementation to use…
> Well, yes, in that sense it is. But the argument was made that it’s too complex for average users to understand: I agree there, [...]
Then it's not really a good thing for different implementations to have
as a differentiator...
Cheers,
aj