Hi Rusty, I think your suggestion for funding_satoshis makes sense. Making a too small channel ends up being completely consumed by fees and in practice not usable.
As for htlc_minimum_msat I would not feel good about it being dropped. It is the only protection measure I saw in the standard against producing trimmed HTLCs. In my view the safe default is to set it above the dust limit to avoid it to get trimmed, and effectively end up routing trusted in-flight payment, that can't be enforced on-chain. There might be reasons to define this differently per client as per everyone's own views, but I don't think it is a good idea to remove this behavior negotiation entirely, because it would effectively force any client to accept HTLCs of any minimum size. As for minimum_depth, I think this default should be chain-dependant. Given the standard describes the possibility to use different chains, limiting this to a fixed number in the standard seems like a risky choice. Given that it's optional that would mean anyone that wants to enforce a higher value would just stop supplying the field. Your e-mail made me think of another aspect that I wanted to raise. Not sure if this is appropriate in this thread or you suggest me to start a separate one, so feel free to correct me in that. While evaluating the specification, we noticed there is no way to negotiate the desire to not support sub-satoshi payments. You can negotiate not to accept HLTCs or channel balances below 1000 msat, but there's no way to negotiate you only accept multiples of 1000 msat (i.e. only whole satoshis). So even with a minimum of 1000 msat I am still expected to route payments of 1291 msat, which contains a sub- satoshi part. Would it be something to consider? Given the fact that any part below 1000 msat cannot be enforced on-chain, I would prefer giving users the ability to opt out of that. There currently is none. So, either a transaction_min_msat_multiple (set to 1000 for only accepting whole satoshis) or accept_subsatoshi (1/0). The latter seems more useful since you probably wouldn't give the former any other value than either 1 or 1000. Gert-Jaap. On Wed, 2018-10-17 at 13:52 +1030, Rusty Russell wrote: > Hi all, > > Everywhere in the protocol where we negotiate, we've had > problems: what do you do if you can't agree? In most cases, we've > settled on defacto generally-accepted values which aren't mentioned > anywhere in the spec (I've skimmed codebases below, looked at defaults). > I'd like to re-examine these in light of our real-life experience and > see if we can simplify them, or at least make suggestions: > > funding_satoshis > ---------------- > > c-lightning: must be >= 1000 (after reserve subtracted) > Eclair: must be >= 100000 > lnd: any > > SUGGESTION: At 253 satoshi/kSipa, and dust at 546, 1000 is too low to be > sane (one output would always be dust). Eclair seems pessimistic > though; Should we suggest that any channel under 3 x min(our_dust_limit, > their_dust_limit) SHOULD be rejected as too small (ie. min is 546*3). > > > dust_limit_satoshis > ------------------- > > c-lightning: gives 546, accepts any. > Eclair: gives 546 (configurable), accepts >= 546. > lnd: gives 573, accepts any. > > (Note: eclair's check here is overzealous, but friendly). > > SUGGESTION: we have to make this variable in future anyway (IRL it > depends on min_relay_fee, which in turn depends on backlog...). > I'd love to just pick a number :( > > > max_htlc_value_in_flight_msat > ----------------------------- > c-lightning: gives U64_MAX, accepts >= 1000000. > Eclair: gives 5000000000, accepts any. > lnd: gives capacity - reserve, accepts >= 5 * htlc_minimum_msat. > > SUGGESTION: maybe drop it (must be U64_MAX?). > > > channel_reserve_satoshis > ------------------------ > > c-lightning: gives 1% (rounded down), accepts <= capacity - 1000000. > Eclair: gives 1% (?), accepts <= 5% (configurable) > lnd: gives 1%, accepts <= 20% > > SUGGESTION: require it be 1% (rounded down). > > > htlc_minimum_msat > ----------------- > > c-lightning: gives 0, accepts up to 0.1% of channel capacity. > Eclair: gives 1, accepts any. > lnd: gives 1000, accepts any. > > SUGGESTION: maybe drop it (ie. must be 0?) > > > to_self_delay > ------------- > > c-lightning: gives 144, accepts <= 2016 > Eclair: gives 144, accepts <= 2000 > lnd: gives 144-2016 (proportional to funding), accepts <= 10000 > > SUGGESTION: require it to be <= 2016. Weaker suggestion: make it 2016, > or use lnd's proportional formula. > > > max_accepted_htlcs > ------------------ > > c-lightning: gives 483, accepts > 0. > Eclair: gives 30, accepts any. > lnd: gives 483, accepts >= 5 > > SUGGESTION: not sure why Eclair limits. Maybe make it 483? > > > minimum_depth > ------------- > > c-lightning: gives 3, accepts <= 10. > Eclair: gives 3, accepts any. > lnd: gives 3-6 (scaling with funding), accepts any. > > SUGGESTION: This field is only a suggestion anyway; you can always wait > longer before sending funding_locked. Let's limit it to <= 6? > > > Are there any other areas of hidden consensus should illuminate and may > simplify? > > Thanks! > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
