From info at AndySchroder.com Sat Dec 30 23:25:49 2017 From: info at AndySchroder.com (Andy Schroder) Date: Sat, 30 Dec 2017 18:25:49 -0500 Subject: [Lightning-dev] General questions about channels In-Reply-To: <87mv1z3j2d.fsf@gmail.com> References: <5A360843.5060706@AndySchroder.com> <878tdzj2wb.fsf@rustcorp.com.au> <5A432D1E.60902@AndySchroder.com> <5A433685.3050202@AndySchroder.com> <5A433D40.9020805@AndySchroder.com> <0mRpF6YNsI8VWWnlVJIKF1juOXp2EKBFap23S74mi2pljbPGcgnVAFh8kM__EUgzPpNgYBZW5CMP85vto0x1hdDvvksrWBYGTxvMCBtexg8=@protonmail.com> <5A4682DF.6020109@AndySchroder.com> <87mv1z3j2d.fsf@gmail.com> Message-ID: <5A48207D.3010804@AndySchroder.com> Hello Christian, I understand that you have to be in agreement with your direct peers. So you don't really care about what agreements others in your route may have in place? I would think that you would choose not to route through hops that violate your capacity limit. Andy Schroder On 12/30/2017 06:14 PM, Christian Decker wrote: > Hi Andy, > > just one minor point regarding your comparison with the bitcoin block > size: while the bitcoin block size is a consensus critical parameter > that cannot be modified without every participant agreeing, the capacity > limit is not consensus critical and can be changed at any point in > time. It can be negotiated by the two endpoints of a channel and no > other party is involved. > > I quite like the comparison to training wheels, it's there as long as > you don't feel safe, and you can get rid of them once you're confidence > in the system and yourself increases :-) > > Cheers, > Christian > > Andy Schroder writes: >> 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. >> >> 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 >>>> Andy Schroder , >>>> 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 >>>> 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 >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev