[Lightning-dev] General questions about channels

Andy Schroder info at AndySchroder.com
Sat Dec 30 23:25:49 UTC 2017


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 <info at AndySchroder.com> 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 <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
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev



More information about the Lightning-dev mailing list