Andy Schroder
On 12/27/2017 12:56 AM, ZmnSCPxj wrote:
Good morning Andy,
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:
o 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?
The specs are intended to eventually support other similar
cryptocurrencies, such as Litecoin. For those currencies, payments of
hundreds of whole coins may be practical, and thus the 0.042 limit is
not imposed. For Bitcoin only, the limit is applied. This simplifies
the design of software by only imposing a limit to a large field under
certain conditions (i.e. for Bitcoin) while retaining the same format
for all coins. Other cryptocurrencies may have different imposed
limits when Lightning gets around to those.
It seems like you are making assumptions about the purchasing power of
certain cryptocurrencies. Why even bother doing this? You have no idea
what the future holds. Why set a limit for any cryptocurrency that might
use lightning?
Even if you are right about the purchasing power of a particular
cryptocurrency, why is a limit needed at all? If I have an high, bi
weekly paid salary, and I have a low budget lifestyle, let's say I save
90% of my income. It seems like your assumed limits could require
multiple payments and multiple open channels for each bi weekly payment.
What if I want to buy a boat, do you expect me to make payments from a
lot of different channels? I was kind of under the assumption that the
long term goal of lightning was only to have a few on chain payments per
human per year.
Or, are you just worried right now because lightning isn't well tested?
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?
You have an off-by-one error. The largest number representable by 32
bits is 2^32 - 1, not 2^32.
Okay, thanks for the clarification.
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?
This is not the channel size. This is the payment size limit. The
channel size limit is 0.16777215 BTC, or 16777215 satoshi (2^24 - 1).
A single payment can be up to 0.04294967295, but a channel is up to
0.16777215.
Okay, so why bother making these two amounts different?
Is the max HTLC value the same as the maximum channel size?
No
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?
An exchange might support this. You buy for example 100USD worth of
BTC and indicate a desire to open a new channel between your node to
the exchange's. The exchange opens the channel with your node and
specifies the push_msat equivalent of 100USD minus fees to your node.
The exchange will want to do this because your new channel goes
directly to the exchange and it can earn routing fees from your
spending. Presumably you want to do this so that you can spend your
100USD on Lightning for things within a short time frame.
The alternative is to send the money from the exchange onchain to you,
then for your node to open a new channel (not necessarily to the
exchange, too, so the exchange loses the routing fees) with the
onchain funds. This is two onchain transactions (from exchange to
you, and from your node to a Lightning channel), unlike the case where
the exchange does a single open and reassigns the funds to you via
push_msat.
Both you and the exchange would want to do this: the exchange wants
this so it can capture your routing fees, you want this so that you do
not even touch the chain at all and start out in Lightning in the
first place.
Okay, so all this feature is doing is saving the extra step of making an
initial payment? Just saving a little time, and not a monumental or
required feature?
Thanks,
Andy Schroder
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
