What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-09 12:52:39
in reply to nevent1q…qd5p

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-13 📝 Original message: Good morning list, I ...

📅 Original date posted:2018-11-13
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181113/79750e22/attachment.html>;
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l