{"type":"rich","version":"1.0","author_name":"npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","author_url":"https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-18\n📝 Original message:\nAndy Schroder \u003cinfo at AndySchroder.com\u003e writes:\n\u003e What's the rational for using millisatoshis as the units for lightning \n\u003e channels? Aren't you going to loose up to 1/2 of a satoshi when the \n\u003e channel is closed?\n\nYou can lose up to 0.999 satoshi per in-progress payment, yes.  BOLT #3:\n\n    The amounts for each output MUST be rounded down to whole satoshis.\n\n\u003e Is this because it doesn't hurt and you might as well \n\u003e be open to the opportunity for these sub satoshi transactions, because \n\u003e if you aren't, you are giving up the opportunity to get accumulated \n\u003e revenue from many of those small transactions, that could end up being \n\u003e greater than 1/2 of a satoshi?\n\nIn practice, payments of less than a few thousand satoshi are\nimpractical, as they cost more than that to spend.  Channel closing\ncosts dwarf the gains to be made from cheating, however.\n\n\u003e Since millisatoshis is used, is there a maximum channel funding size?\n\nYes, the upper 32 bits must be zero, from BOLT #2:\n\n  - for channels with `chain_hash` identifying the Bitcoin blockchain:\n    - MUST set the four most significant bytes of `amount_msat` to 0.\n\nThis gives a maximum HTLC value of .04294967295 BTC, which, back when\nwe started, was about $10.\n\n\u003e Is the optional initial push of millisatoshis during the channel \n\u003e creation there in order to motivate the other party to be willing to \n\u003e waste their time with the channel creation in the first place? If not, \n\u003e what's it for?\n\nIt's for the common case where you want to connect to someone and\nmake a payment immediately.  I'm not sure how widely it will be used,\nthough.  It's also the only mechanism for the payer to have *zero* funds\nin channel (ie. below reserve).\n\n\u003e In all of the clients that I've looked at, I can't seem to find out how \n\u003e to define the timeout closing out a channel when someone does not \n\u003e cooperate. Is there a fixed value for this as part of the protocol? Or \n\u003e do most clients have a default that they enforce over all channels that \n\u003e they create?\n\nIf there's no in-progress payment, there's no reason to close a channel\nto an unreachable peer, unless you want to abandon the channel and get\nthe funds back.\n\nIf there is, BOLT #2 has you covered:\n\n        https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-8\n\nHope that helps,\nRusty."}