Re: [Lightning-dev] Wumbological local AND global features
Good morning list, > I realized the other day that the wumbo bit should also likely encompass wumbo > payments. What good is a wumbo channel that doesn't also allow wumbo payments? > Naturally if the bit is signalled globally, then this should also signal the > willingness of the node to forward larger payments up to their max_htlc limit > within the channel_update for that link. This certainly is true, but, much of the wumbo payments would be implemented by AMP. If there is no direct path of wumborama nodes from payer to payee, then wumbo payments will have to be done by AMP. It would be nice if we could have AMP merge into intermediate nodes instead of always at the destination --- that way, only the suffix of the path needs to be wumborama. Certainly this would be less of an issue as more nodes signal wumborama; we know from previous user behavior that they will be #reckless and enable wumborama as soon as it is implemented. Regards, ZmnSCPxj > On a similar note, I was reviewing the newer-ish section of the spec > concerning > the optional max_htlc value. I noticed an inconsistency: it states the value > should be below the max capacity of the channel, but makes no reference to the > current (pre wumbo) _max HTLC limit_. As a result, as it reads now, one may > interpret signalling of the optional field as eligibility to route wumbo > payments in a pre-wumbo channel world. > > -- Laolu > > On Tue, Nov 13, 2018 at 3:34 PM Rusty Russell wrote: > >> ZmnSCPxj via Lightning-dev writes: >>> Thus, I propose: >>> >>> * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that >>> the node is willing to wumbo with its counterparty in the connection. >>> * The global feature bit `option_anyone_can_wumbo`, which indicates that >>> the node is willing to wumbo with any node. >> >> I think we need to name `option_anyone_can_wumbo` to `option_wumborama`? >> >> Otherwise, this looks excellent. >> >> Thanks, >> Rusty. >> ___ >> 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] Wumbological local AND global features
I realized the other day that the wumbo bit should also likely encompass wumbo payments. What good is a wumbo channel that doesn't also allow wumbo payments? Naturally if the bit is signalled globally, then this should also signal the willingness of the node to forward larger payments up to their max_htlc limit within the channel_update for that link. On a similar note, I was reviewing the newer-ish section of the spec concerning the optional max_htlc value. I noticed an inconsistency: it states the value should be below the max capacity of the channel, but makes no reference to the current (pre wumbo) _max HTLC limit_. As a result, as it reads now, one may interpret signalling of the optional field as eligibility to route wumbo payments in a pre-wumbo channel world. -- Laolu On Tue, Nov 13, 2018 at 3:34 PM Rusty Russell wrote: > ZmnSCPxj via Lightning-dev > writes: > > Thus, I propose: > > > > * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that > the node is willing to wumbo with its counterparty in the connection. > > * The global feature bit `option_anyone_can_wumbo`, which indicates that > the node is willing to wumbo with any node. > > I think we need to name `option_anyone_can_wumbo` to `option_wumborama`? > > Otherwise, this looks excellent. > > Thanks, > Rusty. > ___ > 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] Wumbological local AND global features
ZmnSCPxj via Lightning-dev writes: > Thus, I propose: > > * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that the > node is willing to wumbo with its counterparty in the connection. > * The global feature bit `option_anyone_can_wumbo`, which indicates that the > node is willing to wumbo with any node. I think we need to name `option_anyone_can_wumbo` to `option_wumborama`? Otherwise, this looks excellent. Thanks, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Wumbological local AND global features
Good morning list, I would like to propose, to make both a wumbo local AND global feature bit. The interpretation is to be as follows: * The local wumbo feature specifically means "I am willing to wumbo with you." * The global wumbo feature means "I am willing to wumbo with anyone". The primary reasoning for limited channel sizes is the risk with new software. Although we are reasonably sure that our software will not lose money that often anymore (we hope...), given the new features for 1.1, we should consider also to allow some more limitation to wumbo. Thus, I suggest that practical software would allow making a whitelist of node pubkeys with which the node owner considers safe to accept making wumbo channels with. And more reckless users may also set another option in the software for being willing to wumbo with any node. Thus, I propose: * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that the node is willing to wumbo with its counterparty in the connection. * The global feature bit `option_anyone_can_wumbo`, which indicates that the node is willing to wumbo with any node. A node: * MUST set the local feature bit `option_i_wumbo_you_wumbo` if it sets the global feature bit `option_anyone_can_wumbo` in its announcement. * MAY clear the global feature bit `option_anyone_can_wumbo` even if it sends a set `option_i_wumbo_you_wumbo` to its peer. * MAY report different values for `option_i_wumbo_you_wumbo` to different nodes. * if it did not set the `option_i_wumbo_you_wumbo` feature bit reported to its counterparty: * MUST respond with an `error` if it receives `open_channel` with `funding_satoshis` value beyond the indicated limit for the chain, Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
