Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
> How do i unsubscribe from this email list? Could someone help me please. There’s a link in the footer to the linux list, there you can enter your email to unsubscribe Cheers, Conner -- Sent from my Spaceship On Fri, Nov 9, 2018 at 17:19 alexis petropoulos wrote: > How do i unsubscribe from this email list? Could someone help me please. > > Kindly, > > Alex > -- > *From:* lightning-dev-boun...@lists.linuxfoundation.org < > lightning-dev-boun...@lists.linuxfoundation.org> on behalf of Gert-Jaap > Glasbergen > *Sent:* Monday, November 5, 2018 3:48:56 PM > *To:* lightning-dev@lists.linuxfoundation.org; Rusty Russell > *Subject:* Re: [Lightning-dev] RFC: simplifications and suggestions on > open/accept limits. > > > Op 1 nov. 2018 om 03:38 heeft Rusty Russell het > volgende geschreven: > > > I believe this would render you inoperable in practice; fees are > frequently sub-satoshi, so you would fail everything. The entire > network would have to drop millisatoshis, and the bitcoin maximalist in > me thinks that's unwise :) > > > I can see how not wanting to use millisatoshis makes you less compatible > with other people that do prefer using that unit of account. But in this > case I think it's important to allow the freedom to choose. > > I essentially feel we should be allowed to respect the confines of the layer > we're building upon. There's already a lot of benefits to achieve from second > layer scaling whilst still respecting the limits of the base layer. Staying > within those limits means optimally benefit form the security it offers. > > Essentially by allowing to keep satoshi as the smallest fraction, you ensure > that everything you do off-chain is also valid and enforced by the chain when > you need it to. It comes at trade offs though: it would mean that if someone > routes your payment, you can only pay fees in whole satoshis - essentially > meaning if someone wants to charge a (small) fee, you will be overpaying to > stay within your chosen security parameters. Which is a consequence of your > choice. > > I would be happy to make a further analysis on what consequences allowing this > choice would have for the specification, and come up with a proposal on how to > add support for this. But I guess this discussion is meant to "test the > waters" > to see how much potential such a proposal would have to eventually be > included. > > I guess what I'm searching for is a way to achieve the freedom of choice, > without negatively impacting other clients or users that decide to accept some > level of trust. In my view, this would be possible - but I think working it > out > in a concrete proposal/RFC to the spec would be a logical next step. > > Gert-Jaap > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
How do i unsubscribe from this email list? Could someone help me please. Kindly, Alex From: lightning-dev-boun...@lists.linuxfoundation.org on behalf of Gert-Jaap Glasbergen Sent: Monday, November 5, 2018 3:48:56 PM To: lightning-dev@lists.linuxfoundation.org; Rusty Russell Subject: Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits. Op 1 nov. 2018 om 03:38 heeft Rusty Russell mailto:ru...@rustcorp.com.au>> het volgende geschreven: I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin maximalist in me thinks that's unwise :) I can see how not wanting to use millisatoshis makes you less compatible with other people that do prefer using that unit of account. But in this case I think it's important to allow the freedom to choose. I essentially feel we should be allowed to respect the confines of the layer we're building upon. There's already a lot of benefits to achieve from second layer scaling whilst still respecting the limits of the base layer. Staying within those limits means optimally benefit form the security it offers. Essentially by allowing to keep satoshi as the smallest fraction, you ensure that everything you do off-chain is also valid and enforced by the chain when you need it to. It comes at trade offs though: it would mean that if someone routes your payment, you can only pay fees in whole satoshis - essentially meaning if someone wants to charge a (small) fee, you will be overpaying to stay within your chosen security parameters. Which is a consequence of your choice. I would be happy to make a further analysis on what consequences allowing this choice would have for the specification, and come up with a proposal on how to add support for this. But I guess this discussion is meant to "test the waters" to see how much potential such a proposal would have to eventually be included. I guess what I'm searching for is a way to achieve the freedom of choice, without negatively impacting other clients or users that decide to accept some level of trust. In my view, this would be possible - but I think working it out in a concrete proposal/RFC to the spec would be a logical next step. Gert-Jaap ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
On Wed, Nov 07, 2018 at 02:26:29AM +, Gert-Jaap Glasbergen wrote: > > 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. But that's fine: suppose you want everything divided up into lots of 1 satoshi, and you see 357.719 satoshis coming in and 355.715 satoshis going out. Would you have accepted 357 satoshis going in (rounded down) and 356 satoshis going out (rounded up)? If so, you're set. If not, reject the HTLC as not having a high enough fee. Yes, you're still expected to send fractions of a satoshi around, but that doesn't have to affect your accounting (except occassionally to your benefit when you end up with a thousand millisatoshis). I think you can set your fee_base_msat to 2000 msat to make sure every HTLC you route pays you at least a satoshi, even with losses from rounding. If you're willing to find yourself having routed payments for free (after rounding), then setting it to 1000 msat should work too. > > 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, [...] Then it's not really a good thing for different implementations to have as a differentiator... Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
Hi Rusty, > funding_satoshis > > > c-lightning: must be >= 1000 (after reserve subtracted) > Eclair: must be >= 10 > 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). > The rationale for a relatively high minimal funding_satoshi is to not have tons of unilateral channel closings when there is a network fee spike. We still care as a fundee, because we may have a positive balance and will be annoyed if our funds are delayed. > > > 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). The reasoning is that we do care about remote's commitment tx dust_limit in a dataloss recovery scenario. > > 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 :( Me too! > > > max_htlc_value_in_flight_msat > - > c-lightning: gives U64_MAX, accepts >= 100. > Eclair: gives 50, accepts any. > lnd: gives capacity - reserve, accepts >= 5 * htlc_minimum_msat. > > SUGGESTION: maybe drop it (must be U64_MAX?). Agreed. > > > channel_reserve_satoshis > > > c-lightning: gives 1% (rounded down), accepts <= capacity - 100. > Eclair: gives 1% (?), accepts <= 5% (configurable) > lnd: gives 1%, accepts <= 20% > > SUGGESTION: require it be 1% (rounded down). Agreed. > > > 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?) Why not, given that relay fees make it non-free anyway. > > > to_self_delay > - > > c-lightning: gives 144, accepts <= 2016 > Eclair: gives 144, accepts <= 2000 > lnd: gives 144-2016 (proportional to funding), accepts <= 1 > > SUGGESTION: require it to be <= 2016. Weaker suggestion: make it 2016, > or use lnd's proportional formula. 2016 is sooo long though ;-) Especially given the high number of unilateral close we still see on mainnet. How about <= 1008? > > > 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? We wanted to avoid having a huge commitment tx and a corresponding network fee. Since the funder pays the fee, there is a loose connection between this, funding_satoshis and htlc_minimum_msat. > > > 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? I'm fine with <= 6, but as someone else noted, this would be Bitcoin specific. > Are there any other areas of hidden consensus should illuminate and may > simplify? The two obvious ones are "who should force close when an error happens" and "what is the current feerate" but both are being handled in the new commitment format proposal. I think we should also reconsider the hardcoded maximum funding_satoshis (maybe dig up the "dangerous" flag proposal?). ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
> On 7 Nov 2018, at 12:01, Anthony Towns 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
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
On Tue, Nov 06, 2018 at 10:22:56PM +, Gert-Jaap Glasbergen wrote: > > On 6 Nov 2018, at 14:10, Christian Decker > > 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
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
> On 6 Nov 2018, at 14:10, Christian Decker 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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
Gert-Jaap Glasbergen writes: > Op 1 nov. 2018 om 03:38 heeft Rusty Russell > mailto:ru...@rustcorp.com.au>> het volgende geschreven: >> I believe this would render you inoperable in practice; fees are >> frequently sub-satoshi, so you would fail everything. The entire >> network would have to drop millisatoshis, and the bitcoin maximalist in >> me thinks that's unwise :) > > I can see how not wanting to use millisatoshis makes you less compatible > with other people that do prefer using that unit of account. But in this > case I think it's important to allow the freedom to choose. > > I essentially feel we should be allowed to respect the confines of the layer > we're building upon. There's already a lot of benefits to achieve from second > layer scaling whilst still respecting the limits of the base layer. Staying > within those limits means optimally benefit form the security it offers. > > Essentially by allowing to keep satoshi as the smallest fraction, you ensure > that everything you do off-chain is also valid and enforced by the chain when > you need it to. It comes at trade offs though: it would mean that if someone > routes your payment, you can only pay fees in whole satoshis - essentially > meaning if someone wants to charge a (small) fee, you will be overpaying to > stay within your chosen security parameters. Which is a consequence of your > choice. 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. 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 would be happy to make a further analysis on what consequences allowing this > choice would have for the specification, and come up with a proposal on how to > add support for this. But I guess this discussion is meant to "test the > waters" > to see how much potential such a proposal would have to eventually be > included. > > I guess what I'm searching for is a way to achieve the freedom of choice, > without negatively impacting other clients or users that decide to accept some > level of trust. In my view, this would be possible - but I think working it > out > in a concrete proposal/RFC to the spec would be a logical next step. 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. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
Op 1 nov. 2018 om 03:38 heeft Rusty Russell mailto:ru...@rustcorp.com.au>> het volgende geschreven: I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin maximalist in me thinks that's unwise :) I can see how not wanting to use millisatoshis makes you less compatible with other people that do prefer using that unit of account. But in this case I think it's important to allow the freedom to choose. I essentially feel we should be allowed to respect the confines of the layer we're building upon. There's already a lot of benefits to achieve from second layer scaling whilst still respecting the limits of the base layer. Staying within those limits means optimally benefit form the security it offers. Essentially by allowing to keep satoshi as the smallest fraction, you ensure that everything you do off-chain is also valid and enforced by the chain when you need it to. It comes at trade offs though: it would mean that if someone routes your payment, you can only pay fees in whole satoshis - essentially meaning if someone wants to charge a (small) fee, you will be overpaying to stay within your chosen security parameters. Which is a consequence of your choice. I would be happy to make a further analysis on what consequences allowing this choice would have for the specification, and come up with a proposal on how to add support for this. But I guess this discussion is meant to "test the waters" to see how much potential such a proposal would have to eventually be included. I guess what I'm searching for is a way to achieve the freedom of choice, without negatively impacting other clients or users that decide to accept some level of trust. In my view, this would be possible - but I think working it out in a concrete proposal/RFC to the spec would be a logical next step. Gert-Jaap ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
Gert-Jaap Glasbergen writes: > 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. BTW, that problem is more subtle: non-dust outputs can still be uneconomic to collect. Ideally our definition of "dust" should vary with fees, which makes this "I don't want dust" awkward. > 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. Only incoming HTLCs. You can always refuse to create outgoing HTLCs; this parameter only limits what the peer can offer you. I don't *think* there's any danger in accepting a tiny HTLC, which you'll immediately fail. > 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. Agreed: I was assuming bitcoin. The spec assumes bitcoin in several places because nobody else has done the work, though we leave it open. We should specify it by chain. > 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. I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin maximalist in me thinks that's unwise :) On-chain enforcement is not a panacea. We could do probabilistic payments but they can still be gamed as you can just retry until you get the desired skew :( In practice, bitcoin charges enough that playing such games cannot win. Thanks, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
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 >= 10 > 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 >= 100. > Eclair: gives 50, 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 - 100. > 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 <= 1 > > 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
[Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
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 >= 10 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 >= 100. Eclair: gives 50, 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 - 100. 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 <= 1 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
