Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-01 📝 Original message: Andy Schroder <info at ...
📅 Original date posted:2018-01-01
📝 Original message:
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.
📝 Original message:
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.