On Tue, Nov 06, 2018 at 10:22:56PM +0000, Gert-Jaap Glasbergen wrote: > > On 6 Nov 2018, at 14:10, Christian Decker <decker.christ...@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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
