rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 Original date posted:2017-12-18 📝 Original message: Andy Schroder <info at AndySchroder.com> writes: > What's the rational for using millisatoshis as the units for lightning > channels? Aren't you going to loose up to 1/2 of a satoshi when the > channel is closed? You can lose up to 0.999 satoshi per in-progress payment, yes. BOLT #3: The amounts for each output MUST be rounded down to whole satoshis. > Is this because it doesn't hurt and you might as well > be open to the opportunity for these sub satoshi transactions, because > if you aren't, you are giving up the opportunity to get accumulated > revenue from many of those small transactions, that could end up being > greater than 1/2 of a satoshi? In practice, payments of less than a few thousand satoshi are impractical, as they cost more than that to spend. 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. > Is the optional initial push of millisatoshis during the channel > creation there in order to motivate the other party to be willing to > waste their time with the channel creation in the first place? If not, > what's it for? It's for the common case where you want to connect to someone and make a payment immediately. I'm not sure how widely it will be used, though. It's also the only mechanism for the payer to have *zero* funds in channel (ie. below reserve). > In all of the clients that I've looked at, I can't seem to find out how > to define the timeout closing out a channel when someone does not > cooperate. Is there a fixed value for this as part of the protocol? Or > do most clients have a default that they enforce over all channels that > they create? If there's no in-progress payment, there's no reason to close a channel to an unreachable peer, unless you want to abandon the channel and get the funds back. If there is, BOLT #2 has you covered: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-8 Hope that helps, Rusty.