[Lightning-dev] General questions about channels

Rusty Russell rusty at rustcorp.com.au
Mon Jan 1 03:00:53 UTC 2018


Andy Schroder <info at AndySchroder.com> writes:

> Andy Schroder
>
> On 12/27/2017 12:56 AM, ZmnSCPxj wrote:
>> Good morning Andy,
>>
>>>
>>>     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:
>>>           o 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?
>>
>> The specs are intended to eventually support other similar 
>> cryptocurrencies, such as Litecoin.  For those currencies, payments of 
>> hundreds of whole coins may be practical, and thus the 0.042 limit is 
>> not imposed.  For Bitcoin only, the limit is applied.  This simplifies 
>> the design of software by only imposing a limit to a large field under 
>> certain conditions (i.e. for Bitcoin) while retaining the same format 
>> for all coins. Other cryptocurrencies may have different imposed 
>> limits when Lightning gets around to those.
>
> 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?

Hi Andy,

        I think I covered this pretty well previously: https://medium.com/@rusty_lightning/bitcoin-lightning-faq-why-the-0-042-bitcoin-limit-2eb48b703f3

> Okay, so why bother making these two amounts different?

Since that's just between peers, it was less critical in restraiing the
network (and far easier to change).  There was also a proposal for a
"dangerous feature bit" which would avoid this limitation.

>> Both you and the exchange would want to do this: the exchange wants 
>> this so it can capture your routing fees, you want this so that you do 
>> not even touch the chain at all and start out in Lightning in the 
>> first place.
>
> 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?

It also allows you to hand *all* the money to the other side (the
initial state is not required to have a reserve).

But basically it had the advantage of being trivial.  If nobody actually
uses it, we'll probably drop it in 1.1.

Cheers,
Rusty.


More information about the Lightning-dev mailing list