rich1.0npub1pkr4rlu7w6k8h7tqnnqs96y66n6x29fk888z78d75lulqzt4mjhq2v44qlhttps://nostr.ae/npub1pkr4rlu7w6k8h7tqnnqs96y66n6x29fk888z78d75lulqzt4mjhq2v44qlnjumphttps://nostr.ae📅 Original date posted:2017-12-24 📝 Original message: On Fri, Dec 29, 2017 at 01:01:03PM -0500, Andy Schroder wrote: > Hello, > > Thanks for all of the discussion on this topic. In general, I don't > have a solid opinion formed yet, but I understand all of the points > that everyone has made. I think the bottom line is that a limit > doesn't hurt right now unless the purchasing power of bitcoin > dramatically declines. This limit is like the block size limit in > that it is conservative and we need to have some experience in order > to determine whether the limit is needed at all. It proved to be > very clear over time that a block size limit was needed as one force > against centralization. Maybe a limit is needed for lightning > channels, maybe it isn't, but we need to first see how the network > starts to evolve. My main concern long term is that a large business > couldn't operate using lightning, because the channel sizes and > payment sizes are too small. What if you're buying an oil rig, a > locomotive, a gas turbine, a load of coal, or a herd of cattle. > Should a blockchain transaction be used for everyone in the world > for these types of purchases? But then again, maybe different types > of users will use different kinds of lightning networks. > > Another reason against accepting large incoming channels yourself > would be that you may not want to encourage people paying you to > route through one of the super nodes. Super nodes are likely spies > or targets of spies and users won't naturally want to deal with > those types of actors. > > Also, the Eclair implementation supports push_msat too. > > Other than as "training wheels", I'm still not sure why we need a > payment limit if we have a channel limit. It seems as though the > channel limit puts an implicit payment limit in place. centralized payments have limits. Is that model flawed or does it create a situation of check and balances to control situations where transactions go sideways in ways unforseen? > > Andy Schroder > > On 12/27/2017 03:13 PM, ZmnSCPxj wrote: > >Good morning Daniel, > > > > > > > >>-------- Original Message -------- > >>Subject: Re: [Lightning-dev] General questions about channels > >>Local Time: December 27, 2017 10:30 PM > >>UTC Time: December 27, 2017 2:30 PM > >>From: therealsangaman at gmail.com > >>To: ZmnSCPxj <ZmnSCPxj at protonmail.com> > >>Andy Schroder <info at andyschroder.com>, > >>lightning-dev at lists.linuxfoundation.org > >><lightning-dev at lists.linuxfoundation.org> > >> > >>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 > >><mailto: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, > > > >Splitting up large payments would require multiple invoices at > >least for now (whether this is troublesome or not may be a matter > >of opinion, bit I suspect juggling more than a few invoices would > >be painful as a user experience). Routing larger payments over > >multiple routes automatically while using a single invoice, is > >harder as multiple routes need to be set up, and each route must > >have different preimages: further it is likely you want the entire > >large payment to be done atomically, which would be harder to > >arrange. > > > >>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. > >> > > > >Perhaps our definition of "long term" is askew. A year after > >mainnet release, I doubt anyone would feel safe implementing > >removal of the limit; this is my "long term". Five years, I > >imagine quite a few will use the nonlimited version and may form a > >subnetwork among themselves. But possibly by then it would be > >unlikely that most people using Bitcoin at all would evem be > >capable of putting 150 mBTC in spending money on a hot wallet, in > >which case whether there is a 167 mBTC limit per channel or not is > >largely a moot point. Or perhaps I simply imagine > >hyperbitcoinization by then, with people putting entire bitcoins > >into hot wallets equivalent to people putting thousands of USD > >today in their back pockets as invitation to be attacked. > > > >> > >> 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. > >> > > > >Possibly. At the protocol level, a limit encourages the growth of > >the network towards a mesh network rather than more central forms, > >however. I merely put this since it is unlikely that most people > >following this "wisdom" would have an incentive to even run > >software with the limit removed: that is, by the time Lightning > >becomes fully deployed the limit may not even be reached in > >practice. > > > >> > >>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. > >> > > > >But the party committing funds to the channel is known via node > >gossip, and it is known also who the other end of the channel is. > >If you were to propose opening for example a 5BTC channel to me > >with the funds coming from you, I would consider the possibility > >that I might get attacked in order to get to your funds (and I > >might not have the resources to protect against such an attack on > >my end, even if you might). Further, putting 5BTC implies that at > >some point there is the future possibility, due to routing and so > >on, that the channel will have around 5BTC belonging to me, and at > >some point before you can spend the entire 5BTC I would want to > >close the channel and commit the funds that I now own into cold > >storage (so that the ability to channel 5BTC from you to me is a > >moot point). > > > > > >Regards, > >ZmnSCPxj > > > > !DSPAM:5a3fc746296411625131755! > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > !DSPAM:5a3fc746296411625131755!