{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-27\n📝 Original message:\nGood morning Andy,\n\n\u003e\n\u003e\n\u003e\u003e Channel closing\n\u003e\u003e costs dwarf the gains to be made from cheating, however.\n\u003e\u003e\n\u003e\u003e\u003e Since millisatoshis is used, is there a maximum channel funding size?\n\u003e\u003e\u003e Yes, the upper 32 bits must be zero, from BOLT #2:\n\u003e\u003e\n\u003e\u003e - for channels with chain_hash identifying the Bitcoin blockchain:\n\u003e\u003e\n\u003e\u003e - MUST set the four most significant bytes of amount_msat to 0.\n\u003e\u003e\n\u003e\u003e This gives a maximum HTLC value of .04294967295 BTC, which, back when\n\u003e\u003e we started, was about $10.\n\u003e\n\u003e What's the point of wasting the upper 32 bits? Seems like this is a\n\u003e waste of data?\n\nThe 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.\n\n\u003e\n\u003e If you have the lower 32 bits of data to use, and 2^32=4,294,967,296,\n\u003e then you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis,\n\u003e so 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) =\n\u003e 0.04294967296 BTC. That is off by 1 milli satoshi from what you say\n\u003e above. Why is this?\n\nYou have an off-by-one error.  The largest number representable by 32 bits is 2^32 - 1, not 2^32.\n\n\u003e\n\u003e Regardless of the discrepancy of 1 milli satoshi, it still seems like\n\u003e 0.04294967296 BTC is kind of a low maximum channel size for a lot of\n\u003e business applications. Why do you want to limit this when you have those\n\u003e extra 4 bytes set to zero? You think any more is too much to safely have\n\u003e in a hot wallet? You felt keeping it low will encourage\n\u003e decentralization? Something else?\n\nThis 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).\n\nA single payment can be up to 0.04294967295, but a channel is up to 0.16777215.\n\n\u003e\n\u003e Is the max HTLC value the same as the maximum channel size?\n\nNo\n\n\u003e\n\u003e\n\u003e\u003e\u003e Is the optional initial push of millisatoshis during the channel\n\u003e\u003e\u003e creation there in order to motivate the other party to be willing to\n\u003e\u003e\u003e waste their time with the channel creation in the first place? If not,\n\u003e\u003e\u003e what's it for?\n\u003e\u003e\u003e It's for the common case where you want to connect to someone and\n\u003e\u003e\u003e make a payment immediately. I'm not sure how widely it will be used,\n\u003e\u003e\u003e though. It's also the only mechanism for the payer to have zero funds\n\u003e\u003e\u003e in channel (ie. below reserve).\n\u003e\n\u003e Why would you ever want to start up a channel and immediately have zero\n\u003e funds in reserve? If you are doing that, why not just make a blockchain\n\u003e transaction?\n\nAn 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.\n\nThe 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.\n\nBoth 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.\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/868f7521/attachment.html\u003e"}