{"type":"rich","version":"1.0","author_name":"npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","author_url":"https://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-29\n📝 Original message:\nHello,\n\nThanks for all of the discussion on this topic. In general, I don't have \na solid opinion formed yet, but I understand all of the points that \neveryone has made. I think the bottom line is that a limit doesn't hurt \nright now unless the purchasing power of bitcoin dramatically declines. \nThis limit is like the block size limit in that it is conservative and \nwe need to have some experience in order to determine whether the limit \nis needed at all. It proved to be very clear over time that a block size \nlimit was needed as one force against centralization. Maybe a limit is \nneeded for lightning channels, maybe it isn't, but we need to first see \nhow the network starts to evolve. My main concern long term is that a \nlarge business couldn't operate using lightning, because the channel \nsizes and payment sizes are too small. What if you're buying an oil rig, \na locomotive, a gas turbine, a load of coal, or a herd of cattle. Should \na blockchain transaction be used for everyone in the world for these \ntypes of purchases? But then again, maybe different types of users will \nuse different kinds of lightning networks.\n\nAnother reason against accepting large incoming channels yourself would \nbe that you may not want to encourage people paying you to route through \none of the super nodes. Super nodes are likely spies or targets of spies \nand users won't naturally want to deal with those types of actors.\n\nAlso, the Eclair implementation supports push_msat too.\n\nOther than as \"training wheels\", I'm still not sure why we need a \npayment limit if we have a channel limit. It seems as though the channel \nlimit puts an implicit payment limit in place.\n\nAndy Schroder\n\nOn 12/27/2017 03:13 PM, ZmnSCPxj wrote:\n\u003e Good morning Daniel,\n\u003e\n\u003e\n\u003e\n\u003e\u003e -------- Original Message --------\n\u003e\u003e Subject: Re: [Lightning-dev] General questions about channels\n\u003e\u003e Local Time: December 27, 2017 10:30 PM\n\u003e\u003e UTC Time: December 27, 2017 2:30 PM\n\u003e\u003e From: therealsangaman at gmail.com\n\u003e\u003e To: ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e\n\u003e\u003e Andy Schroder \u003cinfo at andyschroder.com\u003e, \n\u003e\u003e lightning-dev at lists.linuxfoundation.org \n\u003e\u003e \u003clightning-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e\n\u003e\u003e I've only really been getting my hands into LN the past few weeks but\n\u003e\u003e I thought I'd share my thoughts here.\n\u003e\u003e\n\u003e\u003e ZmnSCPxj via Lightning-dev lightning-dev at lists.linuxfoundation.org \n\u003e\u003e \u003cmailto:lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e     Perhaps some day, in the LONG TERM, the limits may be increased\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e I was always under the impression that the channel and payment limits\n\u003e\u003e were intended to be training wheels, this is the first I've heard of\n\u003e\u003e them intended to stick around long term. I find the channel limit to\n\u003e\u003e be particularly restrictive, as it hinders some use cases I'd envision\n\u003e\u003e where large payment channels between two parties are useful and can\n\u003e\u003e also be used for routing LN payments. Large payments afaik can be\n\u003e\u003e broken up into smaller ones without incurring too much cost or\n\u003e\u003e trouble,\n\u003e\n\u003e Splitting up large payments would require multiple invoices at least \n\u003e for now (whether this is troublesome or not may be a matter of \n\u003e opinion, bit I suspect juggling more than a few invoices would be \n\u003e painful as a user experience). Routing larger payments over multiple \n\u003e routes automatically while using a single invoice, is harder as \n\u003e multiple routes need to be set up, and each route must have different \n\u003e preimages: further it is likely you want the entire large payment to \n\u003e be done atomically, which would be harder to arrange.\n\u003e\n\u003e\u003e but that's not the case for creating channels. As the channel\n\u003e\u003e itself involves only two parties - and in sticking to my general\n\u003e\u003e political/philosophical mantra - there is really no justification for\n\u003e\u003e limits to be imposed on this. Which brings me to my next point.\n\u003e\u003e\n\u003e\n\u003e Perhaps our definition of \"long term\" is askew. A year after mainnet \n\u003e release, I doubt anyone would feel safe implementing removal of the \n\u003e limit; this is my \"long term\".  Five years, I imagine quite a few will \n\u003e use the nonlimited version and may form a subnetwork among \n\u003e themselves.  But possibly by then it would be unlikely that most \n\u003e people using Bitcoin at all would evem be capable of putting 150 mBTC \n\u003e in spending money on a hot wallet, in which case whether there is a \n\u003e 167 mBTC limit per channel or not is largely a moot point. Or perhaps \n\u003e I simply imagine hyperbitcoinization by then, with people putting \n\u003e entire bitcoins into hot wallets equivalent to people putting \n\u003e thousands of USD today in their back pockets as invitation to be attacked.\n\u003e\n\u003e\u003e\n\u003e\u003e     There is also again the wisdom, that one should keep most of the\n\u003e\u003e     funds in\n\u003e\u003e     cold storage, and only a small amount for spending in hot wallets\n\u003e\u003e     like\n\u003e\u003e     Lightning nodes\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e I think this is a top-down way of thinking that runs counter to the\n\u003e\u003e spirit of bitcoin. The \"wisest\" thing to do in fact may be to simply\n\u003e\u003e buy inflation-adjusted treasury bonds and not mess with bitcoin at\n\u003e\u003e all, much less the experimental lightning network. As advice this is\n\u003e\u003e perfectly fine to share with others for them to follow on a voluntary\n\u003e\u003e basis, but I don't see why this ought to be enforced as a rule on a\n\u003e\u003e protocol level.\n\u003e\u003e\n\u003e\n\u003e Possibly.  At the protocol level, a limit encourages the growth of the \n\u003e network towards a mesh network rather than more central forms, \n\u003e however.  I merely put this since it is unlikely that most people \n\u003e following this \"wisdom\" would have an incentive to even run software \n\u003e with the limit removed: that is, by the time Lightning becomes fully \n\u003e deployed the limit may not even be reached in practice.\n\u003e\n\u003e\u003e\n\u003e\u003e Also, I personally can't see a reason why a node would reject a large\n\u003e\u003e channel being made with it, where is the downside or risk? The party\n\u003e\u003e committing funds to the channel is the one risking loss or delay of\n\u003e\u003e funds.\n\u003e\u003e\n\u003e\n\u003e But the party committing funds to the channel is known via node \n\u003e gossip, and it is known also who the other end of the channel is. If \n\u003e you were to propose opening for example a 5BTC channel to me with the \n\u003e funds coming from you, I would consider the possibility that I might \n\u003e get attacked in order to get to your funds (and I might not have the \n\u003e resources to protect against such an attack on my end, even if you \n\u003e might). Further, putting 5BTC implies that at some point there is the \n\u003e future possibility, due to routing and so on, that the channel will \n\u003e have around 5BTC belonging to me, and at some point before you can \n\u003e spend the entire 5BTC I would want to close the channel and commit the \n\u003e funds that I now own into cold storage (so that the ability to channel \n\u003e 5BTC from you to me is a moot point).\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171229/b0cc58a4/attachment.html\u003e"}