Andy Schroder [ARCHIVE] on Nostr: š Original date posted:2017-12-27 š Original message: Andy Schroder On ...
š
Original date posted:2017-12-27
š Original message:
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?
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?
>
>>
>> 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.
Okay, thanks for the clarification.
>
>>
>> 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.
Okay, so why bother making these two amounts different?
>
>>
>> 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.
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?
Thanks,
Andy Schroder
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/8e8c3749/attachment.html>;
š Original message:
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?
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?
>
>>
>> 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.
Okay, thanks for the clarification.
>
>>
>> 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.
Okay, so why bother making these two amounts different?
>
>>
>> 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.
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?
Thanks,
Andy Schroder
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/8e8c3749/attachment.html>;