[Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

[Gert-Jaap Glasbergen]

> 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 can see how you can’t make outputs below dust, but not how every transferred value must be multiples of that. My minimum HTLC should be 546 - sure - but then I can also make HTLCs worth 547, 548? I don’t see how the next possible value transfer has to be 2*546. On single hop transfers it can be even possible to make a trustless payment of 1 satoshi, provided the protocol would allow to do this without an HTLC.

> 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, you may as well take as much advantage as possible for the tradeoff you’ve chosen. So in that scenario (you are already departing from on-chain enforcement) msatoshi makes for much broader applicability. However, my argument would be that this departure should be a conscious choice.

Again, I am not advocating mandatory limitations to stay within base layer enforcement, I am advocating _not_ making it mandatory to depart from it.

> With a lot of choice comes great power, with great power comes great
> responsibility... uh I mean complexity :-) I'm all for giving users the
> freedom to chose what they feel comfortable with, but this freedom comes
> at a high cost and the protocol is very complex as it is. So we need to
> find the right configuration options, and I think not too many users
> will care about their unit of transfer, especially when it's handled
> automatically for them.

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. 

Gert-Jaap