References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
	<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
	<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
	<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
	<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
	<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
	<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
	<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
	<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
	<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
	<55C79FF0.8040100@thinlink.com>
	<CAOG=w-skYq84=PtN45FB-dGoY1783Jz7K1T16e2JVGjLazWuyA@mail.gmail.com>
	<CALJP9GDMgqn2VeR4y4RVxqJ_iW57hExwXBHNSkxo+-AK+7Zb6g@mail.gmail.com>
	<CAAO2FKHu_BVcR-zH-0oRb0v6L_tyuncvUd2fOboKJ9HaKHrVrQ@mail.gmail.com>
From: Tom Harding <tomh@thinlink.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <55C803D6.7070706@thinlink.com>
Date: Sun, 9 Aug 2015 18:52:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAAO2FKHu_BVcR-zH-0oRb0v6L_tyuncvUd2fOboKJ9HaKHrVrQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] What Lightning Is
Precedence: list

On 8/9/2015 2:45 PM, Hector Chu wrote:
> Tom, my understanding is that the money that is debited from a payment
> hub is simultaneously credited from either another payment hub or the
> person making the payment, so that the net funds flow at a payment hub
> always sums to zero.

That describes the steady-state dynamics.  I refer to the hub funding
required to initiate and maintain the ability to receive payments.

If Bob opens a channel at his hub, doesn't use it for spending, and
Alice sends 1 BTC to the channel, her payment can only be applied if the
hub has funded the channel with at least 1 BTC.

Yes, the hub receives an offsetting payment (from Alice, ultimately) in
another channel.  But to make this work, it must subject 1 BTC to shared
control with Bob and forfeit the use of that money for other purposes
(opportunity cost) while the channel is open.  The opportunity cost is
likened to gold lease rates in the LN paper.  I would be surprised if
the rates charged to consumers for BTC credit aren't much closer to
today's BTC borrowing rates.  We'll see.

Burying this cost in general fees might not work very well, because
different Bobs may want different maximum payment amounts, and channels
open for different lengths of time.