{"type":"rich","version":"1.0","author_name":"npub1pkr4rlu7w6k8h7tqnnqs96y66n6x29fk888z78d75lulqzt4mjhq2v44ql","author_url":"https://nostr.ae/npub1pkr4rlu7w6k8h7tqnnqs96y66n6x29fk888z78d75lulqzt4mjhq2v44ql","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-24\n📝 Original message:\nOn Fri, Dec 29, 2017 at 01:01:03PM -0500, Andy Schroder wrote:\n\u003e Hello,\n\u003e \n\u003e Thanks for all of the discussion on this topic. In general, I don't\n\u003e have a solid opinion formed yet, but I understand all of the points\n\u003e that everyone has made. I think the bottom line is that a limit\n\u003e doesn't hurt right now unless the purchasing power of bitcoin\n\u003e dramatically declines. This limit is like the block size limit in\n\u003e that it is conservative and we need to have some experience in order\n\u003e to determine whether the limit is needed at all. It proved to be\n\u003e very clear over time that a block size limit was needed as one force\n\u003e against centralization. Maybe a limit is needed for lightning\n\u003e channels, maybe it isn't, but we need to first see how the network\n\u003e starts to evolve. My main concern long term is that a large business\n\u003e couldn't operate using lightning, because the channel sizes and\n\u003e payment sizes are too small. What if you're buying an oil rig, a\n\u003e locomotive, a gas turbine, a load of coal, or a herd of cattle.\n\u003e Should a blockchain transaction be used for everyone in the world\n\u003e for these types of purchases? But then again, maybe different types\n\u003e of users will use different kinds of lightning networks.\n\u003e \n\u003e Another reason against accepting large incoming channels yourself\n\u003e would be that you may not want to encourage people paying you to\n\u003e route through one of the super nodes. Super nodes are likely spies\n\u003e or targets of spies and users won't naturally want to deal with\n\u003e those types of actors.\n\u003e \n\u003e Also, the Eclair implementation supports push_msat too.\n\u003e \n\u003e Other than as \"training wheels\", I'm still not sure why we need a\n\u003e payment limit if we have a channel limit. It seems as though the\n\u003e channel limit puts an implicit payment limit in place.\n\ncentralized payments have limits. Is that model flawed or does it\ncreate a situation of check and balances to control situations where\ntransactions go sideways in ways unforseen? \n\n\u003e \n\u003e Andy Schroder\n\u003e \n\u003e On 12/27/2017 03:13 PM, ZmnSCPxj wrote:\n\u003e \u003eGood morning Daniel,\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\u003e-------- Original Message --------\n\u003e \u003e\u003eSubject: Re: [Lightning-dev] General questions about channels\n\u003e \u003e\u003eLocal Time: December 27, 2017 10:30 PM\n\u003e \u003e\u003eUTC Time: December 27, 2017 2:30 PM\n\u003e \u003e\u003eFrom: therealsangaman at gmail.com\n\u003e \u003e\u003eTo: ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e\n\u003e \u003e\u003eAndy Schroder \u003cinfo at andyschroder.com\u003e,\n\u003e \u003e\u003elightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e\u003clightning-dev at lists.linuxfoundation.org\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003eI've only really been getting my hands into LN the past few weeks but\n\u003e \u003e\u003eI thought I'd share my thoughts here.\n\u003e \u003e\u003e\n\u003e \u003e\u003eZmnSCPxj via Lightning-dev\n\u003e \u003e\u003elightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e\u003cmailto:lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e    Perhaps some day, in the LONG TERM, the limits may be increased\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003eI was always under the impression that the channel and payment limits\n\u003e \u003e\u003ewere intended to be training wheels, this is the first I've heard of\n\u003e \u003e\u003ethem intended to stick around long term. I find the channel limit to\n\u003e \u003e\u003ebe particularly restrictive, as it hinders some use cases I'd envision\n\u003e \u003e\u003ewhere large payment channels between two parties are useful and can\n\u003e \u003e\u003ealso be used for routing LN payments. Large payments afaik can be\n\u003e \u003e\u003ebroken up into smaller ones without incurring too much cost or\n\u003e \u003e\u003etrouble,\n\u003e \u003e\n\u003e \u003eSplitting up large payments would require multiple invoices at\n\u003e \u003eleast for now (whether this is troublesome or not may be a matter\n\u003e \u003eof opinion, bit I suspect juggling more than a few invoices would\n\u003e \u003ebe painful as a user experience). Routing larger payments over\n\u003e \u003emultiple routes automatically while using a single invoice, is\n\u003e \u003eharder as multiple routes need to be set up, and each route must\n\u003e \u003ehave different preimages: further it is likely you want the entire\n\u003e \u003elarge payment to be done atomically, which would be harder to\n\u003e \u003earrange.\n\u003e \u003e\n\u003e \u003e\u003ebut that's not the case for creating channels. As the channel\n\u003e \u003e\u003eitself involves only two parties - and in sticking to my general\n\u003e \u003e\u003epolitical/philosophical mantra - there is really no justification for\n\u003e \u003e\u003elimits to be imposed on this. Which brings me to my next point.\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003ePerhaps our definition of \"long term\" is askew. A year after\n\u003e \u003emainnet release, I doubt anyone would feel safe implementing\n\u003e \u003eremoval of the limit; this is my \"long term\".  Five years, I\n\u003e \u003eimagine quite a few will use the nonlimited version and may form a\n\u003e \u003esubnetwork among themselves.  But possibly by then it would be\n\u003e \u003eunlikely that most people using Bitcoin at all would evem be\n\u003e \u003ecapable of putting 150 mBTC in spending money on a hot wallet, in\n\u003e \u003ewhich case whether there is a 167 mBTC limit per channel or not is\n\u003e \u003elargely a moot point. Or perhaps I simply imagine\n\u003e \u003ehyperbitcoinization by then, with people putting entire bitcoins\n\u003e \u003einto hot wallets equivalent to people putting thousands of USD\n\u003e \u003etoday in their back pockets as invitation to be attacked.\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e    There is also again the wisdom, that one should keep most of the\n\u003e \u003e\u003e    funds in\n\u003e \u003e\u003e    cold storage, and only a small amount for spending in hot wallets\n\u003e \u003e\u003e    like\n\u003e \u003e\u003e    Lightning nodes\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003eI think this is a top-down way of thinking that runs counter to the\n\u003e \u003e\u003espirit of bitcoin. The \"wisest\" thing to do in fact may be to simply\n\u003e \u003e\u003ebuy inflation-adjusted treasury bonds and not mess with bitcoin at\n\u003e \u003e\u003eall, much less the experimental lightning network. As advice this is\n\u003e \u003e\u003eperfectly fine to share with others for them to follow on a voluntary\n\u003e \u003e\u003ebasis, but I don't see why this ought to be enforced as a rule on a\n\u003e \u003e\u003eprotocol level.\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003ePossibly.  At the protocol level, a limit encourages the growth of\n\u003e \u003ethe network towards a mesh network rather than more central forms,\n\u003e \u003ehowever.  I merely put this since it is unlikely that most people\n\u003e \u003efollowing this \"wisdom\" would have an incentive to even run\n\u003e \u003esoftware with the limit removed: that is, by the time Lightning\n\u003e \u003ebecomes fully deployed the limit may not even be reached in\n\u003e \u003epractice.\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003eAlso, I personally can't see a reason why a node would reject a large\n\u003e \u003e\u003echannel being made with it, where is the downside or risk? The party\n\u003e \u003e\u003ecommitting funds to the channel is the one risking loss or delay of\n\u003e \u003e\u003efunds.\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003eBut the party committing funds to the channel is known via node\n\u003e \u003egossip, and it is known also who the other end of the channel is.\n\u003e \u003eIf you were to propose opening for example a 5BTC channel to me\n\u003e \u003ewith the funds coming from you, I would consider the possibility\n\u003e \u003ethat I might get attacked in order to get to your funds (and I\n\u003e \u003emight not have the resources to protect against such an attack on\n\u003e \u003emy end, even if you might). Further, putting 5BTC implies that at\n\u003e \u003esome point there is the future possibility, due to routing and so\n\u003e \u003eon, that the channel will have around 5BTC belonging to me, and at\n\u003e \u003esome point before you can spend the entire 5BTC I would want to\n\u003e \u003eclose the channel and commit the funds that I now own into cold\n\u003e \u003estorage (so that the ability to channel 5BTC from you to me is a\n\u003e \u003emoot point).\n\u003e \u003e\n\u003e \u003e\n\u003e \u003eRegards,\n\u003e \u003eZmnSCPxj\n\u003e \n\u003e \n\u003e \n\u003e !DSPAM:5a3fc746296411625131755!\n\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \n\u003e \n\u003e !DSPAM:5a3fc746296411625131755!"}