{"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/18/2017 01:40 PM, Rusty Russell wrote:\n\u003e Andy Schroder \u003cinfo at AndySchroder.com\u003e writes:\n\u003e\u003e What's the rational for using millisatoshis as the units for lightning\n\u003e\u003e channels? Aren't you going to loose up to 1/2 of a satoshi when the\n\u003e\u003e channel is closed?\n\u003e You can lose up to 0.999 satoshi per in-progress payment, yes.  BOLT #3:\n\u003e\n\u003e      The amounts for each output MUST be rounded down to whole satoshis.\n\nOkay, round down, not regular rounding!\n\n\n\u003e\n\u003e\u003e Is this because it doesn't hurt and you might as well\n\u003e\u003e be open to the opportunity for these sub satoshi transactions, because\n\u003e\u003e if you aren't, you are giving up the opportunity to get accumulated\n\u003e\u003e revenue from many of those small transactions, that could end up being\n\u003e\u003e greater than 1/2 of a satoshi?\n\u003e In practice, payments of less than a few thousand satoshi are\n\u003e impractical, as they cost more than that to spend.\n\nThey are impractical even on the lightning network?\n\n\n\n\n\u003e Channel closing\n\u003e costs dwarf the gains to be made from cheating, however.\n\u003e\n\u003e\u003e Since millisatoshis is used, is there a maximum channel funding size?\n\u003e Yes, the upper 32 bits must be zero, from BOLT #2:\n\u003e\n\u003e    - for channels with `chain_hash` identifying the Bitcoin blockchain:\n\u003e      - MUST set the four most significant bytes of `amount_msat` to 0.\n\u003e\n\u003e This gives a maximum HTLC value of .04294967295 BTC, which, back when\n\u003e we started, was about $10.\n\nWhat's the point of wasting the upper 32 bits? Seems like this is a \nwaste of data?\n\nIf you have the lower 32 bits of data to use, and 2^32=4,294,967,296, \nthen you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis, \nso 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) = \n0.04294967296 BTC. That is off by 1 milli satoshi from what you say \nabove. Why is this?\n\nRegardless of the discrepancy of 1 milli satoshi, it still seems like \n0.04294967296 BTC is kind of a low maximum channel size for a lot of \nbusiness applications. Why do you want to limit this when you have those \nextra 4 bytes set to zero? You think any more is too much to safely have \nin a hot wallet? You felt keeping it low will encourage \ndecentralization? Something else?\n\n\nIs the max HTLC value the same as the maximum channel size?\n\n\n\n\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 willing to\n\u003e\u003e waste their time with the channel creation in the first place? If not,\n\u003e\u003e what's it for?\n\u003e It's for the common case where you want to connect to someone and\n\u003e make a payment immediately.  I'm not sure how widely it will be used,\n\u003e though.  It's also the only mechanism for the payer to have *zero* funds\n\u003e in channel (ie. below reserve).\n\nWhy would you ever want to start up a channel and immediately have zero \nfunds in reserve? If you are doing that, why not just make a blockchain \ntransaction?\n\n\n\u003e\n\u003e\u003e In all of the clients that I've looked at, I can't seem to find out how\n\u003e\u003e to define the timeout closing out a channel when someone does not\n\u003e\u003e cooperate. Is there a fixed value for this as part of the protocol? Or\n\u003e\u003e do most clients have a default that they enforce over all channels that\n\u003e\u003e they create?\n\u003e If there's no in-progress payment, there's no reason to close a channel\n\u003e to an unreachable peer, unless you want to abandon the channel and get\n\u003e the funds back.\n\u003e\n\u003e If there is, BOLT #2 has you covered:\n\u003e\n\u003e          https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-8\n\n\nOkay, so every time you get a new HTLC, your client can change the \ntimeout that you require for closing the channel, which will control how \nlong it takes you to abandon the channel and get your funds back when \nthe peer is unreachable? Or is that set during initial channel creation \nonly?\n\n\n\n\u003e\n\u003e Hope that helps,\n\u003e Rusty.\n\u003e"}