Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-27 📝 Original message: Andy Schroder On ...

📅 Original date posted:2017-12-27
📝 Original message:
Andy Schroder

On 12/18/2017 01:40 PM, Rusty Russell wrote:
> 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.

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.
>