Andy Schroder
On 12/18/2017 01:40 PM, Rusty Russell wrote:
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.
Okay, round down, not regular rounding!
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.
They are impractical even on the lightning network?
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.
What's the point of wasting the upper 32 bits? Seems like this is a
waste of data?
If you have the lower 32 bits of data to use, and 2^32=4,294,967,296,
then you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis,
so 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) =
0.04294967296 BTC. That is off by 1 milli satoshi from what you say
above. Why is this?
Regardless of the discrepancy of 1 milli satoshi, it still seems like
0.04294967296 BTC is kind of a low maximum channel size for a lot of
business applications. Why do you want to limit this when you have those
extra 4 bytes set to zero? You think any more is too much to safely have
in a hot wallet? You felt keeping it low will encourage
decentralization? Something else?
Is the max HTLC value the same as the maximum channel size?
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).
Why would you ever want to start up a channel and immediately have zero
funds in reserve? If you are doing that, why not just make a blockchain
transaction?
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
Okay, so every time you get a new HTLC, your client can change the
timeout that you require for closing the channel, which will control how
long it takes you to abandon the channel and get your funds back when
the peer is unreachable? Or is that set during initial channel creation
only?
Hope that helps,
Rusty.
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
