Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-06 📝 Original message: On Tue, Nov 06, 2018 at ...
📅 Original date posted:2018-11-06
📝 Original message:
On Tue, Nov 06, 2018 at 10:22:56PM +0000, Gert-Jaap Glasbergen wrote:
> > On 6 Nov 2018, at 14:10, Christian Decker <decker.christian at gmail.com> wrote:
> > It should be pointed out here that the dust rules actually prevent us
> > from creating an output that is smaller than the dust limit (546
> > satoshis on Bitcoin). By the same logic we would be forced to treat the
> > dust limit as our atomic unit, and have transferred values and fees
> > always be multiples of that dust limit.
> I don’t follow the logic behind this.
I don't think it quite makes sense either fwiw.
> > 546 satoshis is by no means a tiny amount anymore, i.e., 546'000 times
> > the current minimum fee and value transferred. I think we will have to
> > deal with values that are not representable / enforceable on-chain
> > anyway, so we might as well make things more flexible by keeping
> > msatoshis.
> I can see how this makes sense. If you deviate from the realms of what is possible to enforce on chain,
What's enforcable on chain will vary though -- as fees rise, even if the
network will still relay your 546 satoshi output, it may no longer be
economical to claim it, so you might as well save fees by not including
it in the first place.
But equally, if you're able to cope with fees rising _at all_ then
you're already okay with losing a few dozen satoshis here and there, so
how much difference does it make if you're losing them because fees
rose, or because there was a small HTLC that you could've claimed in
theory (or off-chain) but just can't claim on-chain?
> Again, I am not advocating mandatory limitations to stay within base layer enforcement, I am advocating _not_ making it mandatory to depart from it.
That seems like it adds a lot of routing complexity for every node
(what is the current dust level? does it vary per node/channel? can I
get a path that accepts my microtransaction HTLC? do I pay enough less
in fees that it's better to bump it up to the dust level?), and routing
is already complex enough...
You could already get something like this behaviour by setting a high
"fee_base_msat" and a low "fee_proportional_millionths" so it's just
not economical to send small transactions via your channel, and a
corresponding "htlc_maximum_msat" to make sure you aren't too cheap at
the top end.
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 would not envision this to be even configurable by end users. I am just advocating the options in the protocol so that an implementation can choose what security level it prefers.
Everything in open source is configurable by end users: at worst, either
by them changing the code, or by choosing which implementation to use...
Cheers,
aj
📝 Original message:
On Tue, Nov 06, 2018 at 10:22:56PM +0000, Gert-Jaap Glasbergen wrote:
> > On 6 Nov 2018, at 14:10, Christian Decker <decker.christian at gmail.com> wrote:
> > It should be pointed out here that the dust rules actually prevent us
> > from creating an output that is smaller than the dust limit (546
> > satoshis on Bitcoin). By the same logic we would be forced to treat the
> > dust limit as our atomic unit, and have transferred values and fees
> > always be multiples of that dust limit.
> I don’t follow the logic behind this.
I don't think it quite makes sense either fwiw.
> > 546 satoshis is by no means a tiny amount anymore, i.e., 546'000 times
> > the current minimum fee and value transferred. I think we will have to
> > deal with values that are not representable / enforceable on-chain
> > anyway, so we might as well make things more flexible by keeping
> > msatoshis.
> I can see how this makes sense. If you deviate from the realms of what is possible to enforce on chain,
What's enforcable on chain will vary though -- as fees rise, even if the
network will still relay your 546 satoshi output, it may no longer be
economical to claim it, so you might as well save fees by not including
it in the first place.
But equally, if you're able to cope with fees rising _at all_ then
you're already okay with losing a few dozen satoshis here and there, so
how much difference does it make if you're losing them because fees
rose, or because there was a small HTLC that you could've claimed in
theory (or off-chain) but just can't claim on-chain?
> Again, I am not advocating mandatory limitations to stay within base layer enforcement, I am advocating _not_ making it mandatory to depart from it.
That seems like it adds a lot of routing complexity for every node
(what is the current dust level? does it vary per node/channel? can I
get a path that accepts my microtransaction HTLC? do I pay enough less
in fees that it's better to bump it up to the dust level?), and routing
is already complex enough...
You could already get something like this behaviour by setting a high
"fee_base_msat" and a low "fee_proportional_millionths" so it's just
not economical to send small transactions via your channel, and a
corresponding "htlc_maximum_msat" to make sure you aren't too cheap at
the top end.
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 would not envision this to be even configurable by end users. I am just advocating the options in the protocol so that an implementation can choose what security level it prefers.
Everything in open source is configurable by end users: at worst, either
by them changing the code, or by choosing which implementation to use...
Cheers,
aj