{"type":"rich","version":"1.0","author_name":"npub1auy2ject3577tjhee32hheheld29rs92jgeff4ulvclvwr96g5dsje0edv","author_url":"https://nostr.ae/npub1auy2ject3577tjhee32hheheld29rs92jgeff4ulvclvwr96g5dsje0edv","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-27\n📝 Original message:\nI've only really been getting my hands into LN the past few weeks but\nI thought I'd share my thoughts here.\n\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Perhaps some day, in the LONG TERM, the limits may be increased\n\nI was always under the impression that the channel and payment limits\nwere intended to be training wheels, this is the first I've heard of\nthem intended to stick around long term. I find the channel limit to\nbe particularly restrictive, as it hinders some use cases I'd envision\nwhere large payment channels between two parties are useful and can\nalso be used for routing LN payments. Large payments afaik can be\nbroken up into smaller ones without incurring too much cost or\ntrouble, but that's not the case for creating channels. As the channel\nitself involves only two parties - and in sticking to my general\npolitical/philosophical mantra - there is really no justification for\nlimits to be imposed on this. Which brings me to my next point.\n\n\u003e If I run a node which refuses the higher limits, then:\n\u003e\n\u003e 1. The alt-lightning network node cannot channel to me directly to unless\n\u003e they accept my channel size limit. (they will have to channel through a node\n\u003e that will accept my channel size limit and also accept their increased\n\u003e channel size limit, or just never open a channel to me greater than\n\u003e 167mBTC).\n\nThe parenthetical here is correct. If nodes A and B have huge channels\nbetween each other, they can still be totally compatible with the rest\nof the network as long as they don't try exceeding the channel limit\nwith nodes that won't accept it. In practice, \"whales\" will quite\neasily be able to run their own rules with regards to these limits and\nI think that is a good thing.\n\n\u003e There is also again the wisdom, that one should keep most of the funds in\n\u003e cold storage, and only a small amount for spending in hot wallets like\n\u003e Lightning nodes\n\nI think this is a top-down way of thinking that runs counter to the\nspirit of bitcoin. The \"wisest\" thing to do in fact may be to simply\nbuy inflation-adjusted treasury bonds and not mess with bitcoin at\nall, much less the experimental lightning network. As advice this is\nperfectly fine to share with others for them to follow on a voluntary\nbasis, but I don't see why this ought to be enforced as a rule on a\nprotocol level.\n\nAlso, I personally can't see a reason why a node would reject a large\nchannel being made with it, where is the downside or risk? The party\ncommitting funds to the channel is the one risking loss or delay of\nfunds.\n\n\u003e Yes.  Indeed to my knowledge no current LN software implements non-zero\n\u003e push_msat\n\nAs an aside, I believe push_sat is implemented by LND.\n\nAnyway, I think these limits are fine for LN's baby steps, but overly\nrestrictive for a mature LN network. Ideally I believe I'd want these\nlimits to be non-existent or configurable by nodes (and announced to\npeers), but maybe I am missing some technical reasons why such an\napproach would be challenging. Either way I expect I'll be among the\nfirst to run software with less restrictive limits when LN's training\nwheels are ready to come off.\n\nThanks for the discussion and for your work on LN.\n\nDaniel"}