[Lightning-dev] Minor protocol revisions.

Anthony Towns aj at erisian.com.au
Thu Sep 24 11:54:02 UTC 2015


On Thu, Sep 24, 2015 at 03:17:41PM +0930, Rusty Russell wrote:
> 4) HTLC precision increase, ceiling drop.
> As a secondary effect, 32 bits places a ceiling of 0.04 satoshi
> (currently about $10USD) on each HTLC.

This means keeping the channel balances in 64 bit counters, right?

I was thinking along the following lines:

 - bitcoin txns have absolute fees (currently f = 0.1 mBTC)
 - lightning has percentage fees (call it p)
 - so breakeven point is a transaction amount A, where
   A * p = f; ie A = f/p
 - p should be less than 2%, putting a lower limit on A of 5 mBTC,
   but 0.04 BTC = 40 mBTC, which is well above that.
 - if A = 0.04 BTC, p = f/A = 0.25%, putting a lower limit on lightning
   fees (that's for the entire path, individual hops could be lower)

I probably would have preferred capping out at about 0.1 BTC (~$23),
corresponding to lightning fees of 0.1% matching bitcoin fees of 0.1 mBTC,
but that's quibbling.

Anyway, if you want to send more than $10 via lightning you just do
multiple transactions with different R values [0], the same way you
might use two $20 notes to pay someone $40. Even $1000 would just be
100 transactions, which doesn't seem like too big a deal?

Having a small maximum is probably also useful for routing -- if you want
to send two $10 notes, send them along different routes to avoid draining
any particular channel. That also helps obscure how much is being spent.

A maximum seems pretty helpful for planning how to fund a node too --
if you know no individual transaction will be more than 0.04 BTC, you
can setup your fee schedule in 0.04 BTC increments (or greater), and
not have to worry about "if i got 30 mBTC I'd raise my fee before the
next 30 mBTC came in; but here's 60 mBTC in one hop with just 2x the
lower fee! do I accept it or reject it?"

So, hey, turns out I totally endorse this change. +1.

Cheers,
aj

[0] or just rely on the different S values the R/S method for avoiding
    onion probing would automatically use



More information about the Lightning-dev mailing list