ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-27 📝 Original message: Good morning Andy, > Andy ...
📅 Original date posted:2017-12-27
📝 Original message:
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.
>> Is the max HTLC value the same as the maximum channel size?
>
> Okay, so I may have discovered part of this answer to this question in BOLT 2 where it says: "MUST setfunding_satoshis to less than 2^24 satoshi". However, I still don't understand the rational of why max funding_satoshis doesn't equal max amount_msat, or where the values of (2^24)*10^3 and 2^32 milli satoshis came from. Also, why don't you use units of millisatoshis everywhere in the spec? Sometimes it's satoshis and sometimes it's milli satoshis.
This is actually very simple. Everything that touches the chain (opening and closing) uses satoshis. Everything that does not, uses millisatoshis. This is because the chain uses satoshis as the smallest amount. Offchain, we can use millisatoshis, and it is used everywhere offchain.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/e23d2aba/attachment-0001.html>;
📝 Original message:
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.
>> Is the max HTLC value the same as the maximum channel size?
>
> Okay, so I may have discovered part of this answer to this question in BOLT 2 where it says: "MUST setfunding_satoshis to less than 2^24 satoshi". However, I still don't understand the rational of why max funding_satoshis doesn't equal max amount_msat, or where the values of (2^24)*10^3 and 2^32 milli satoshis came from. Also, why don't you use units of millisatoshis everywhere in the spec? Sometimes it's satoshis and sometimes it's milli satoshis.
This is actually very simple. Everything that touches the chain (opening and closing) uses satoshis. Everything that does not, uses millisatoshis. This is because the chain uses satoshis as the smallest amount. Offchain, we can use millisatoshis, and it is used everywhere offchain.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/e23d2aba/attachment-0001.html>;