<unnamed>

Public Key

npub1auy2ject3577tjhee32hheheld29rs92jgeff4ulvclvwr96g5dsje0edv

Profile Code

nprofile1qqsw7z9fvu9c6009etuuc4tmumulk4z3cz4fyv55670kv0k8pjay2xcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg8ljf0k

Publishing to

relay.primal.net

Last Notes

2023-06-09 12:48:10 UTC

- reply

📅 Original date posted:2017-12-27
📝 Original message:
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, 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.
> If I run a node which refuses the higher limits, then:
>
> 1. The alt-lightning network node cannot channel to me directly to unless
> they accept my channel size limit. (they will have to channel through a node
> that will accept my channel size limit and also accept their increased
> channel size limit, or just never open a channel to me greater than
> 167mBTC).
The parenthetical here is correct. If nodes A and B have huge channels
between each other, they can still be totally compatible with the rest
of the network as long as they don't try exceeding the channel limit
with nodes that won't accept it. In practice, "whales" will quite
easily be able to run their own rules with regards to these limits and
I think that is a good thing.
> 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.
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.
> Yes. Indeed to my knowledge no current LN software implements non-zero
> push_msat
As an aside, I believe push_sat is implemented by LND.
Anyway, I think these limits are fine for LN's baby steps, but overly
restrictive for a mature LN network. Ideally I believe I'd want these
limits to be non-existent or configurable by nodes (and announced to
peers), but maybe I am missing some technical reasons why such an
approach would be challenging. Either way I expect I'll be among the
first to run software with less restrictive limits when LN's training
wheels are ready to come off.
Thanks for the discussion and for your work on LN.
Daniel