Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-28 📝 Original message: Splitting a single ...
📅 Original date posted:2017-12-28
📝 Original message:
Splitting a single payment into multiple invoices has bad semantic properties. Beyond implementation difficulties it also makes the payment no longer atomic. You can end up in a situation where part of a transaction has gone through but then channel capacity has been exhausted. The. What do you do?
While an annoying (and potentially exploitable) edge case for payments, it also makes it basically impossible in practice to build higher level smart contracts on top of lightning channels as primitives, since those constructs typically use a single HTLC revelation as the decision gate between multiple contingent outcomes.
I had always assumed the protocol limits were training wheels, and would be shocked and dismayed if that were not the case (and would immediately begin work on an alternative fork because such limits would make lightning useless for my intended applications).
On the topic of cold storage, I think perhaps that is less of a settled issue than you take for granted. I think the value proposition of bitcoin is exactly its ability to serve as non custodial collateral and I do not anticipate a future where large portions of the bitcoin monetary base are not held as collateral in smart contract payment channels. Indeed I would consider that a failure mode both worth designing for...
> On Dec 27, 2017, at 12:13 PM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171228/42da9b77/attachment-0001.html>;
📝 Original message:
Splitting a single payment into multiple invoices has bad semantic properties. Beyond implementation difficulties it also makes the payment no longer atomic. You can end up in a situation where part of a transaction has gone through but then channel capacity has been exhausted. The. What do you do?
While an annoying (and potentially exploitable) edge case for payments, it also makes it basically impossible in practice to build higher level smart contracts on top of lightning channels as primitives, since those constructs typically use a single HTLC revelation as the decision gate between multiple contingent outcomes.
I had always assumed the protocol limits were training wheels, and would be shocked and dismayed if that were not the case (and would immediately begin work on an alternative fork because such limits would make lightning useless for my intended applications).
On the topic of cold storage, I think perhaps that is less of a settled issue than you take for granted. I think the value proposition of bitcoin is exactly its ability to serve as non custodial collateral and I do not anticipate a future where large portions of the bitcoin monetary base are not held as collateral in smart contract payment channels. Indeed I would consider that a failure mode both worth designing for...
> On Dec 27, 2017, at 12:13 PM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171228/42da9b77/attachment-0001.html>;