rich1.0npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccqhttps://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccqnjumphttps://nostr.ae📅 Original date posted:2017-12-27 📝 Original message: 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? > > > 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 set |funding_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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/f270ce79/attachment.html>