<unnamed>

Public Key

npub1pkr4rlu7w6k8h7tqnnqs96y66n6x29fk888z78d75lulqzt4mjhq2v44ql

Profile Code

nprofile1qqsqmp63l708dtrml9sfesgzazddfar9z5mrnn30rkl2070sp96aetsprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvu8vtd3

Publishing to

relay.snort.social

Last Notes

2023-06-09 14:48:12 CEST

- reply

📅 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!