ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-27 📝 Original message: Good morning Andy, > > >> ...
📅 Original date posted:2017-12-27
📝 Original message:
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:
>>
>> - 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.
>
> 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?
You have an off-by-one error. The largest number representable by 32 bits is 2^32 - 1, not 2^32.
>
> 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?
This is not the channel size. This is the payment size limit. The channel size limit is 0.16777215 BTC, or 16777215 satoshi (2^24 - 1).
A single payment can be up to 0.04294967295, but a channel is up to 0.16777215.
>
> Is the max HTLC value the same as the maximum channel size?
No
>
>
>>> Is the optional initial push of millisatoshis during the channel
>>> creation there in order to motivate the other party to be willing to
>>> waste their time with the channel creation in the first place? If not,
>>> what's it for?
>>> It's for the common case where you want to connect to someone and
>>> make a payment immediately. I'm not sure how widely it will be used,
>>> though. It's also the only mechanism for the payer to have zero funds
>>> in channel (ie. below reserve).
>
> Why would you ever want to start up a channel and immediately have zero
> funds in reserve? If you are doing that, why not just make a blockchain
> transaction?
An exchange might support this. You buy for example 100USD worth of BTC and indicate a desire to open a new channel between your node to the exchange's. The exchange opens the channel with your node and specifies the push_msat equivalent of 100USD minus fees to your node. The exchange will want to do this because your new channel goes directly to the exchange and it can earn routing fees from your spending. Presumably you want to do this so that you can spend your 100USD on Lightning for things within a short time frame.
The alternative is to send the money from the exchange onchain to you, then for your node to open a new channel (not necessarily to the exchange, too, so the exchange loses the routing fees) with the onchain funds. This is two onchain transactions (from exchange to you, and from your node to a Lightning channel), unlike the case where the exchange does a single open and reassigns the funds to you via push_msat.
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.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/868f7521/attachment.html>;
📝 Original message:
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:
>>
>> - 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.
>
> 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?
You have an off-by-one error. The largest number representable by 32 bits is 2^32 - 1, not 2^32.
>
> 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?
This is not the channel size. This is the payment size limit. The channel size limit is 0.16777215 BTC, or 16777215 satoshi (2^24 - 1).
A single payment can be up to 0.04294967295, but a channel is up to 0.16777215.
>
> Is the max HTLC value the same as the maximum channel size?
No
>
>
>>> Is the optional initial push of millisatoshis during the channel
>>> creation there in order to motivate the other party to be willing to
>>> waste their time with the channel creation in the first place? If not,
>>> what's it for?
>>> It's for the common case where you want to connect to someone and
>>> make a payment immediately. I'm not sure how widely it will be used,
>>> though. It's also the only mechanism for the payer to have zero funds
>>> in channel (ie. below reserve).
>
> Why would you ever want to start up a channel and immediately have zero
> funds in reserve? If you are doing that, why not just make a blockchain
> transaction?
An exchange might support this. You buy for example 100USD worth of BTC and indicate a desire to open a new channel between your node to the exchange's. The exchange opens the channel with your node and specifies the push_msat equivalent of 100USD minus fees to your node. The exchange will want to do this because your new channel goes directly to the exchange and it can earn routing fees from your spending. Presumably you want to do this so that you can spend your 100USD on Lightning for things within a short time frame.
The alternative is to send the money from the exchange onchain to you, then for your node to open a new channel (not necessarily to the exchange, too, so the exchange loses the routing fees) with the onchain funds. This is two onchain transactions (from exchange to you, and from your node to a Lightning channel), unlike the case where the exchange does a single open and reassigns the funds to you via push_msat.
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.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/868f7521/attachment.html>;