From aj at erisian.com.au  Thu Sep 24 11:54:02 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Thu, 24 Sep 2015 21:54:02 +1000
Subject: [Lightning-dev] Minor protocol revisions.
In-Reply-To: <87r3lo2wsi.fsf@rustcorp.com.au>
References: <87r3lo2wsi.fsf@rustcorp.com.au>
Message-ID: <20150924115402.GA7417@navy>

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