ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-27 📝 Original message: Good morning Andy, Sent ...
📅 Original date posted:2017-12-27
📝 Original message:
Good morning Andy,
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> -------- Original Message --------
> Subject: Re: [Lightning-dev] General questions about channels
> Local Time: December 27, 2017 2:27 PM
> UTC Time: December 27, 2017 6:27 AM
> From: info at AndySchroder.com
> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Rusty Russell <rusty at rustcorp.com.au>, lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
>
> Andy Schroder
>
> On 12/27/2017 01:06 AM, ZmnSCPxj wrote:
>
>> Good morning Andy,
>>
>>> Andy Schroder
>>>
>>> On 12/27/2017 12:18 AM, Andy Schroder wrote:
>>>
>>>>> Channel closing
>>>>> costs dwarf the gains to be made from cheating, however.
>>>>>
>>>>>> Since millisatoshis is used, is there a maximum channel funding size?
>>>>>
>>>>> Yes, the upper 32 bits must be zero, from BOLT #2:
>>>>>
>>>>> - for channels with `chain_hash` identifying the Bitcoin blockchain:
>>>>> - MUST set the four most significant bytes of `amount_msat` to 0.
>>>>>
>>>>> This gives a maximum HTLC value of .04294967295 BTC, which, back when
>>>>> we started, was about $10.
>>>>
>>>> What's the point of wasting the upper 32 bits? Seems like this is a waste of data?
>>>>
>>>> If you have the lower 32 bits of data to use, and 2^32=4,294,967,296, then you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis, so 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) = 0.04294967296 BTC. That is off by 1 milli satoshi from what you say above. Why is this?
>>>>
>>>> Regardless of the discrepancy of 1 milli satoshi, it still seems like 0.04294967296 BTC is kind of a low maximum channel size for a lot of business applications. Why do you want to limit this when you have those extra 4 bytes set to zero? You think any more is too much to safely have in a hot wallet? You felt keeping it low will encourage decentralization? Something else?
>>
>> Yes, I believe Rusty did indeed consider 42mBTC as a reasonable amount to transfer on Lightning. So that in case of trouble on Lightning, not a lot of money gets lost. At the time he decided this 42mBTC limit, it was about 10 USD only, so Rusty could always just buy you a drink if he somehow causes c-lightning to lose that much.
>>
>> Of course, 42mBTC today is much larger.
>>
>> For myself, I think the channel limit of 167mBTC is good as it encourages decentralization by encouraging people to make many small channels than one large channel. Many small channels helps in keeping your funds resilient against temporary outages of your fellow nodes.
>
> I understand what you are saying about decentralization, but is this really something that will be enforceable? Seems like people will just make an alt-lightning network layer with different limits to get around this, since there isn't really a consensus rule set like on the block chain to motivate them.
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).
2. The alt-lightning network node cannot route through me unless they accept my payment size (HTLC size) limit.
3. I won't route through the alt-lightning network for any value greater than my payment size limit.
Making Lightning software work is difficult, and given the above constraints it will not be as easy as "just remove the limit-checking code" - the alt-lightning network node software is strictly more complicated as it has to check if it is using or creating a channel that has the existing limits imposed or not: indeed, if most of the existing network uses the existing limits, then the alt-lightning node is still practically limited to the 42mBTC limit when routing through the existing network (and the alt-lightning network might not be big enough to find routes through only the alt-lightning nodes - if it has to pass through even one legacy node imposing the 42mBTC limit, then the payment is automatically limited by that node). One might compare the supposedly simple "just change the constant to 2x its value" attempted by 2X, when in reality what happens is the more complicated "change the constant to a variable that has the old value on or before before block N and a new value on or after block N+1", which also failed rather spectacularly due to off-by-one error..
Indeed, such a "whale Lightning network" might be feasible if all the whales channel with each other, but at some point they will have to pay some hoi polloi node imposing the 42mBTC limit. If I am not a whale and will not be able to send or receive large amounts of bitcoin anyway, I have no real incentive to run a whalenode whose expanded capabilities I would not be able to utilize anyway. Further, wise whales will keep most of their money in cold storage and only put small spending amounts on hot wallets, which Lightning nodes most definitely are, since they keep the keys on an online computer; there is still no incentive to run a whalenode either.
So it might be that one day we will remove the limit and find that nobody in practice uses the expanded capacity either.
> It seems like you are making assumptions about the purchasing power of certain cryptocurrencies. Why even bother doing this? You have no idea what the future holds. Why set a limit for any cryptocurrency that might use lightning?
Well, the truth of the matter is that originally, the field was 32-bit and not 64-bit. Rusty decided that the 42mBTC limit this imposed was A-OK since it would limit the risk involved if payments get stuck to about 10USD at the time, and so on.
When Rusty & friends made a "Litening" network node (Lightning on Litecoin) 32-bits was not enough for anything practical, since 0.042LTC is really low in value. So the field was expanded to 64-bit, but for BTC the 42mBTC limit was still imposed by requiring, for BTC only, that the upper 32-bits be 0.
Similar for the channel limit (it was originally 24-bit only, and was expanded for Litening and the original limit re-imposed specifically for BTC).
> Even if you are right about the purchasing power of a particular cryptocurrency, why is a limit needed at all? If I have an high, bi weekly paid salary, and I have a low budget lifestyle, let's say I save 90% of my income. It seems like your assumed limits could require multiple payments and multiple open channels for each bi weekly payment. What if I want to buy a boat, do you expect me to make payments from a lot of different channels? I was kind of under the assumption that the long term goal of lightning was only to have a few on chain payments per human per year.
>
> Or, are you just worried right now because lightning isn't well tested?
Partially this, also. Lightning is still alpha-level to beta-level software and we want to "start soft". Perhaps some day, in the LONG TERM, the limits may be increased (but in practice it will take time before all nodes upgrade to higher limits, and the existing channels will have to be re-consolidated and so on).
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; presumably, rare purchases of boats (which I doubt you would want to buy daily) would be doable on-chain straight from cold storage, even with just "a few on chain payments per human per year" - even really rich people are likely to buy at a rate of one new car and/or one new boat each year because seriously what would you do with it, so that is still "a few on chain transactions per year".
As for salary accumulation - well indeed, perhaps a higher channel limit would be useful here, but again maybe after a few months you might want to withdraw to cold storage - as a hot wallet any unexpected 0-days of Lightning software, the hardware you run on, and the operating system you run on, might lose you several months' worth of salary if you kept it on Lightning. You might prefer to receive your salary once a month, put the first month into Lightning and the succeeding months directly into cold storage, until you need to replenish your Lightning funds for groceries. And so on. Perhaps salary-conversion services (since governments are likely to require your salary be denominated in the local fiat because government) would replenish part of your Lightning funds for you, then forward the rest to your cold storage.
>> A single payment can be up to 0.04294967295, but a channel is up to 0.16777215.
>
> Okay, so why bother making these two amounts different?
Why should they be the same? Should not the channel be able to survive one or two or three 0.042 payments, so the channel limit being 0.167 is just shy of being able to fit 4 max-size payments through it?
If the two limits were the same, then in practice nobody could use the maximum payment limit. One must also factor in the "channel reserve" and the fact that most of the time it is likely that the channel will be in a "halfway" state between the two nodes (i.e. about 83.88mBTC each). So it is sensible to make the channel limit higher than the payment limit, so that in practice many max-size payments will go through.
> <snip push_msat>
>
> Okay, so all this feature is doing is saving the extra step of making an initial payment? Just saving a little time, and not a monumental or required feature?
Yes. Indeed to my knowledge no current LN software implements non-zero push_msat. It might be useful, it might not be. The option is there and is supported, especially since support for it is relatively trivial (one only need adjust the initial commitment transactions).
We are a lot less strict about channel opening message bloat as channel opening is expected to be a rare event, so optimizing these "wasted always 0 bytes" in the channel opening messages is not a high priority. Gossip messages are more likely to be strictly optimized.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/cca71d76/attachment-0001.html>;
📝 Original message:
Good morning Andy,
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> -------- Original Message --------
> Subject: Re: [Lightning-dev] General questions about channels
> Local Time: December 27, 2017 2:27 PM
> UTC Time: December 27, 2017 6:27 AM
> From: info at AndySchroder.com
> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Rusty Russell <rusty at rustcorp.com.au>, lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
>
> Andy Schroder
>
> On 12/27/2017 01:06 AM, ZmnSCPxj wrote:
>
>> Good morning Andy,
>>
>>> Andy Schroder
>>>
>>> On 12/27/2017 12:18 AM, Andy Schroder wrote:
>>>
>>>>> Channel closing
>>>>> costs dwarf the gains to be made from cheating, however.
>>>>>
>>>>>> Since millisatoshis is used, is there a maximum channel funding size?
>>>>>
>>>>> Yes, the upper 32 bits must be zero, from BOLT #2:
>>>>>
>>>>> - for channels with `chain_hash` identifying the Bitcoin blockchain:
>>>>> - MUST set the four most significant bytes of `amount_msat` to 0.
>>>>>
>>>>> This gives a maximum HTLC value of .04294967295 BTC, which, back when
>>>>> we started, was about $10.
>>>>
>>>> What's the point of wasting the upper 32 bits? Seems like this is a waste of data?
>>>>
>>>> If you have the lower 32 bits of data to use, and 2^32=4,294,967,296, then you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis, so 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) = 0.04294967296 BTC. That is off by 1 milli satoshi from what you say above. Why is this?
>>>>
>>>> Regardless of the discrepancy of 1 milli satoshi, it still seems like 0.04294967296 BTC is kind of a low maximum channel size for a lot of business applications. Why do you want to limit this when you have those extra 4 bytes set to zero? You think any more is too much to safely have in a hot wallet? You felt keeping it low will encourage decentralization? Something else?
>>
>> Yes, I believe Rusty did indeed consider 42mBTC as a reasonable amount to transfer on Lightning. So that in case of trouble on Lightning, not a lot of money gets lost. At the time he decided this 42mBTC limit, it was about 10 USD only, so Rusty could always just buy you a drink if he somehow causes c-lightning to lose that much.
>>
>> Of course, 42mBTC today is much larger.
>>
>> For myself, I think the channel limit of 167mBTC is good as it encourages decentralization by encouraging people to make many small channels than one large channel. Many small channels helps in keeping your funds resilient against temporary outages of your fellow nodes.
>
> I understand what you are saying about decentralization, but is this really something that will be enforceable? Seems like people will just make an alt-lightning network layer with different limits to get around this, since there isn't really a consensus rule set like on the block chain to motivate them.
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).
2. The alt-lightning network node cannot route through me unless they accept my payment size (HTLC size) limit.
3. I won't route through the alt-lightning network for any value greater than my payment size limit.
Making Lightning software work is difficult, and given the above constraints it will not be as easy as "just remove the limit-checking code" - the alt-lightning network node software is strictly more complicated as it has to check if it is using or creating a channel that has the existing limits imposed or not: indeed, if most of the existing network uses the existing limits, then the alt-lightning node is still practically limited to the 42mBTC limit when routing through the existing network (and the alt-lightning network might not be big enough to find routes through only the alt-lightning nodes - if it has to pass through even one legacy node imposing the 42mBTC limit, then the payment is automatically limited by that node). One might compare the supposedly simple "just change the constant to 2x its value" attempted by 2X, when in reality what happens is the more complicated "change the constant to a variable that has the old value on or before before block N and a new value on or after block N+1", which also failed rather spectacularly due to off-by-one error..
Indeed, such a "whale Lightning network" might be feasible if all the whales channel with each other, but at some point they will have to pay some hoi polloi node imposing the 42mBTC limit. If I am not a whale and will not be able to send or receive large amounts of bitcoin anyway, I have no real incentive to run a whalenode whose expanded capabilities I would not be able to utilize anyway. Further, wise whales will keep most of their money in cold storage and only put small spending amounts on hot wallets, which Lightning nodes most definitely are, since they keep the keys on an online computer; there is still no incentive to run a whalenode either.
So it might be that one day we will remove the limit and find that nobody in practice uses the expanded capacity either.
> It seems like you are making assumptions about the purchasing power of certain cryptocurrencies. Why even bother doing this? You have no idea what the future holds. Why set a limit for any cryptocurrency that might use lightning?
Well, the truth of the matter is that originally, the field was 32-bit and not 64-bit. Rusty decided that the 42mBTC limit this imposed was A-OK since it would limit the risk involved if payments get stuck to about 10USD at the time, and so on.
When Rusty & friends made a "Litening" network node (Lightning on Litecoin) 32-bits was not enough for anything practical, since 0.042LTC is really low in value. So the field was expanded to 64-bit, but for BTC the 42mBTC limit was still imposed by requiring, for BTC only, that the upper 32-bits be 0.
Similar for the channel limit (it was originally 24-bit only, and was expanded for Litening and the original limit re-imposed specifically for BTC).
> Even if you are right about the purchasing power of a particular cryptocurrency, why is a limit needed at all? If I have an high, bi weekly paid salary, and I have a low budget lifestyle, let's say I save 90% of my income. It seems like your assumed limits could require multiple payments and multiple open channels for each bi weekly payment. What if I want to buy a boat, do you expect me to make payments from a lot of different channels? I was kind of under the assumption that the long term goal of lightning was only to have a few on chain payments per human per year.
>
> Or, are you just worried right now because lightning isn't well tested?
Partially this, also. Lightning is still alpha-level to beta-level software and we want to "start soft". Perhaps some day, in the LONG TERM, the limits may be increased (but in practice it will take time before all nodes upgrade to higher limits, and the existing channels will have to be re-consolidated and so on).
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; presumably, rare purchases of boats (which I doubt you would want to buy daily) would be doable on-chain straight from cold storage, even with just "a few on chain payments per human per year" - even really rich people are likely to buy at a rate of one new car and/or one new boat each year because seriously what would you do with it, so that is still "a few on chain transactions per year".
As for salary accumulation - well indeed, perhaps a higher channel limit would be useful here, but again maybe after a few months you might want to withdraw to cold storage - as a hot wallet any unexpected 0-days of Lightning software, the hardware you run on, and the operating system you run on, might lose you several months' worth of salary if you kept it on Lightning. You might prefer to receive your salary once a month, put the first month into Lightning and the succeeding months directly into cold storage, until you need to replenish your Lightning funds for groceries. And so on. Perhaps salary-conversion services (since governments are likely to require your salary be denominated in the local fiat because government) would replenish part of your Lightning funds for you, then forward the rest to your cold storage.
>> A single payment can be up to 0.04294967295, but a channel is up to 0.16777215.
>
> Okay, so why bother making these two amounts different?
Why should they be the same? Should not the channel be able to survive one or two or three 0.042 payments, so the channel limit being 0.167 is just shy of being able to fit 4 max-size payments through it?
If the two limits were the same, then in practice nobody could use the maximum payment limit. One must also factor in the "channel reserve" and the fact that most of the time it is likely that the channel will be in a "halfway" state between the two nodes (i.e. about 83.88mBTC each). So it is sensible to make the channel limit higher than the payment limit, so that in practice many max-size payments will go through.
> <snip push_msat>
>
> Okay, so all this feature is doing is saving the extra step of making an initial payment? Just saving a little time, and not a monumental or required feature?
Yes. Indeed to my knowledge no current LN software implements non-zero push_msat. It might be useful, it might not be. The option is there and is supported, especially since support for it is relatively trivial (one only need adjust the initial commitment transactions).
We are a lot less strict about channel opening message bloat as channel opening is expected to be a rare event, so optimizing these "wasted always 0 bytes" in the channel opening messages is not a high priority. Gossip messages are more likely to be strictly optimized.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/cca71d76/attachment-0001.html>;