Andy Schroder <[email protected]> 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.
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
