rich1.0npub1auy2ject3577tjhee32hheheld29rs92jgeff4ulvclvwr96g5dsje0edvhttps://nostr.ae/npub1auy2ject3577tjhee32hheheld29rs92jgeff4ulvclvwr96g5dsje0edvnjumphttps://nostr.ae📅 Original date posted:2017-12-27 📝 Original message: I've only really been getting my hands into LN the past few weeks but I thought I'd share my thoughts here. ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote: > Perhaps some day, in the LONG TERM, the limits may be increased I was always under the impression that the channel and payment limits were intended to be training wheels, this is the first I've heard of them intended to stick around long term. I find the channel limit to be particularly restrictive, as it hinders some use cases I'd envision where large payment channels between two parties are useful and can also be used for routing LN payments. Large payments afaik can be broken up into smaller ones without incurring too much cost or trouble, but that's not the case for creating channels. As the channel itself involves only two parties - and in sticking to my general political/philosophical mantra - there is really no justification for limits to be imposed on this. Which brings me to my next point. > If I run a node which refuses the higher limits, then: > > 1. The alt-lightning network node cannot channel to me directly to unless > they accept my channel size limit. (they will have to channel through a node > that will accept my channel size limit and also accept their increased > channel size limit, or just never open a channel to me greater than > 167mBTC). The parenthetical here is correct. If nodes A and B have huge channels between each other, they can still be totally compatible with the rest of the network as long as they don't try exceeding the channel limit with nodes that won't accept it. In practice, "whales" will quite easily be able to run their own rules with regards to these limits and I think that is a good thing. > There is also again the wisdom, that one should keep most of the funds in > cold storage, and only a small amount for spending in hot wallets like > Lightning nodes I think this is a top-down way of thinking that runs counter to the spirit of bitcoin. The "wisest" thing to do in fact may be to simply buy inflation-adjusted treasury bonds and not mess with bitcoin at all, much less the experimental lightning network. As advice this is perfectly fine to share with others for them to follow on a voluntary basis, but I don't see why this ought to be enforced as a rule on a protocol level. Also, I personally can't see a reason why a node would reject a large channel being made with it, where is the downside or risk? The party committing funds to the channel is the one risking loss or delay of funds. > Yes. Indeed to my knowledge no current LN software implements non-zero > push_msat As an aside, I believe push_sat is implemented by LND. Anyway, I think these limits are fine for LN's baby steps, but overly restrictive for a mature LN network. Ideally I believe I'd want these limits to be non-existent or configurable by nodes (and announced to peers), but maybe I am missing some technical reasons why such an approach would be challenging. Either way I expect I'll be among the first to run software with less restrictive limits when LN's training wheels are ready to come off. Thanks for the discussion and for your work on LN. Daniel