> On 7 Nov 2018, at 12:01, Anthony Towns <a...@erisian.com.au> wrote: > > I don't think it quite makes sense either fwiw.
Glad it’s not just me :) > 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. I agree here, but there’s a provision in place to cope with this. People can define the minimum size of payments / channel balances they are willing to accept, in order to prevent producing dust or trimmed outputs. They can adhere to certain limits within their own control. If fees vary you can accept it’s current temporary nature and leave the channel in place for low tides, or if fees rise more structurally close channels and reopen them with higher limits. The key is that it’s in your control. > 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. If forwarding the payment is optional, then that technically gives me an out to implement my desired behaviour. But, I think it would be highly harmful to the reliability of the network if a client were to simply not route payments that don’t adhere to their (undocumented) requirements. It would be much more sensible for nodes to be made aware of those requirements, to prevent them from trying to route through channels in vain. That’s why I would prefer this to be part of the channel’s properties so everyone is aware. > 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, but that’s no reason to not make the protocol support this choice. The fact that the end user shouldn’t be bothered with the choice doesn’t prohibit the protocol from supporting it. Gert-Jaap. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
