{"type":"rich","version":"1.0","author_name":"npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","author_url":"https://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-27\n📝 Original message:\nAndy Schroder\n\nOn 12/27/2017 12:56 AM, ZmnSCPxj wrote:\n\u003e Good morning Andy,\n\u003e\n\u003e\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         Since millisatoshis is used, is there a maximum channel\n\u003e\u003e         funding size?\n\u003e\u003e         Yes, the upper 32 bits must be zero, from BOLT #2:\n\u003e\u003e\n\u003e\u003e      *\n\u003e\u003e         for channels with |chain_hash| identifying the Bitcoin\n\u003e\u003e         blockchain:\n\u003e\u003e           o MUST set the four most significant bytes of |amount_msat|\n\u003e\u003e             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\u003e\n\u003e\u003e\n\u003e\u003e What's the point of wasting the upper 32 bits? Seems like this is a\n\u003e\u003e waste of data?\n\u003e\n\u003e The specs are intended to eventually support other similar \n\u003e cryptocurrencies, such as Litecoin.  For those currencies, payments of \n\u003e hundreds of whole coins may be practical, and thus the 0.042 limit is \n\u003e not imposed.  For Bitcoin only, the limit is applied.  This simplifies \n\u003e the design of software by only imposing a limit to a large field under \n\u003e certain conditions (i.e. for Bitcoin) while retaining the same format \n\u003e for all coins. Other cryptocurrencies may have different imposed \n\u003e limits when Lightning gets around to those.\n\nIt seems like you are making assumptions about the purchasing power of \ncertain cryptocurrencies. Why even bother doing this? You have no idea \nwhat the future holds. Why set a limit for any cryptocurrency that might \nuse lightning?\n\nEven if you are right about the purchasing power of a particular \ncryptocurrency, why is a limit needed at all? If I have an high, bi \nweekly paid salary, and I have a low budget lifestyle, let's say I save \n90% of my income. It seems like your assumed limits could require \nmultiple payments and multiple open channels for each bi weekly payment. \nWhat if I want to buy a boat, do you expect me to make payments from a \nlot of different channels? I was kind of under the assumption that the \nlong term goal of lightning was only to have a few on chain payments per \nhuman per year.\n\nOr, are you just worried right now because lightning isn't well tested?\n\n\n\n\u003e\n\u003e\u003e\n\u003e\u003e If you have the lower 32 bits of data to use, and 2^32=4,294,967,296,\n\u003e\u003e then you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis,\n\u003e\u003e so 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) =\n\u003e\u003e 0.04294967296 BTC. That is off by 1 milli satoshi from what you say\n\u003e\u003e above. Why is this?\n\u003e\u003e\n\u003e\n\u003e You have an off-by-one error.  The largest number representable by 32 \n\u003e bits is 2^32 - 1, not 2^32.\n\nOkay, thanks for the clarification.\n\n\u003e\n\u003e\u003e\n\u003e\u003e Regardless of the discrepancy of 1 milli satoshi, it still seems like\n\u003e\u003e 0.04294967296 BTC is kind of a low maximum channel size for a lot of\n\u003e\u003e business applications. Why do you want to limit this when you have those\n\u003e\u003e extra 4 bytes set to zero? You think any more is too much to safely have\n\u003e\u003e in a hot wallet? You felt keeping it low will encourage\n\u003e\u003e decentralization? Something else?\n\u003e\u003e\n\u003e\n\u003e This is not the channel size.  This is the payment size limit.  The \n\u003e channel size limit is 0.16777215 BTC, or 16777215 satoshi (2^24 - 1).\n\u003e\n\u003e A single payment can be up to 0.04294967295, but a channel is up to \n\u003e 0.16777215.\n\nOkay, so why bother making these two amounts different?\n\n\u003e\n\u003e\u003e\n\u003e\u003e Is the max HTLC value the same as the maximum channel size?\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e No\n\u003e\n\u003e\u003e\n\u003e\u003e         Is the optional initial push of millisatoshis during the channel\n\u003e\u003e         creation there in order to motivate the other party to be\n\u003e\u003e         willing to\n\u003e\u003e         waste their time with the channel creation in the first\n\u003e\u003e         place? If not,\n\u003e\u003e         what's it for?\n\u003e\u003e         It's for the common case where you want to connect to someone and\n\u003e\u003e         make a payment immediately. I'm not sure how widely it will\n\u003e\u003e         be used,\n\u003e\u003e         though. It's also the only mechanism for the payer to have\n\u003e\u003e         /zero/ funds\n\u003e\u003e         in channel (ie. below reserve).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Why would you ever want to start up a channel and immediately have zero\n\u003e\u003e funds in reserve? If you are doing that, why not just make a blockchain\n\u003e\u003e transaction?\n\u003e\u003e\n\u003e\n\u003e An exchange might support this.  You buy for example 100USD worth of \n\u003e BTC and indicate a desire to open a new channel between your node to \n\u003e the exchange's.  The exchange opens the channel with your node and \n\u003e specifies the push_msat equivalent of 100USD minus fees to your node.  \n\u003e The exchange will want to do this because your new channel goes \n\u003e directly to the exchange and it can earn routing fees from your \n\u003e spending.  Presumably you want to do this so that you can spend your \n\u003e 100USD on Lightning for things within a short time frame.\n\u003e\n\u003e The alternative is to send the money from the exchange onchain to you, \n\u003e then for your node to open a new channel (not necessarily to the \n\u003e exchange, too, so the exchange loses the routing fees) with the \n\u003e onchain funds.  This is two onchain transactions (from exchange to \n\u003e you, and from your node to a Lightning channel), unlike the case where \n\u003e the exchange does a single open and reassigns the funds to you via \n\u003e push_msat.\n\u003e\n\u003e Both you and the exchange would want to do this: the exchange wants \n\u003e this so it can capture your routing fees, you want this so that you do \n\u003e not even touch the chain at all and start out in Lightning in the \n\u003e first place.\n\nOkay, so all this feature is doing is saving the extra step of making an \ninitial payment? Just saving a little time, and not a monumental or \nrequired feature?\n\nThanks,\nAndy Schroder\n\n\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/8e8c3749/attachment.html\u003e"}