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: i...@andyschroder.com
> To: ZmnSCPxj <zmnsc...@protonmail.com>
> Rusty Russell <ru...@rustcorp.com.au>,
> lightning-dev@lists.linuxfoundation.org
> <lightning-dev@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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
