MIME-Version: 1.0
In-Reply-To: <CAOG=w-skYq84=PtN45FB-dGoY1783Jz7K1T16e2JVGjLazWuyA@mail.gmail.com>
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>
From: Hector Chu <hectorchu@gmail.com>
Date: Sun, 9 Aug 2015 21:14:55 +0100
Message-ID: <CAAO2FKHyNC6PT+i2pYo88eeb-wdkJdeVjmqzC=PetyF6yO=+Lw@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=001a11c25f52ea1faf051ce6861b
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] What Lightning Is
Precedence: list

--001a11c25f52ea1faf051ce6861b
Content-Type: text/plain; charset=UTF-8

In the Lightning network it is assumed that the balances can always be
settled on the blockchain if any of the parties along the channel has a
problem. What if the fee on the settlement transactions is not high enough
to enter the blockchain? You can't do replace-by-fee after the fact. Do the
fees always have to assume worst case scenarios on the Bitcoin fee market?

On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Tom, you appear to be misunderstanding how lightning network and
> micropayment hub-and-spoke models in general work.
>
> > But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies).  Nothing requires the
> payment hub to do this.
>
> On the contrary the funds were advanced by the hub on the creation of the
> channel. There is no credit involved. if the funds aren't already available
> for Bob to immediately claim his balance, the payment doesn't go through in
> the first place.
>
> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>>
>> > Don't turn Bitcoin into something uninteresting, please.
>>
>> Consider how Bob will receive money using the Lightning Network.
>>
>> Bob receives a payment by applying a contract to his local payment
>> channel, increasing the amount payable to him when the channel is closed.
>>
>> There are two possible sources of funding for Bob's increased claim.
>> They can appear alone, or in combination:
>>
>>
>> Funding Source (1)
>> A deposit from Bob's payment hub
>>
>> Bob can receive funds, if his payment hub has made a deposit to the
>> channel.  Another name for this is "credit".
>>
>> This credit has no default risk: Bob cannot just take payment hub's
>> deposit. But neither can Bob receive money, unless payment hub has
>> advanced it to the channel (or (2) below applies).  Nothing requires the
>> payment hub to do this.
>>
>> This is a 3rd-party dependency totally absent with plain old bitcoin.
>> It will come with a fee and, in an important way, it is worse than the
>> current banking system.  If a bank will not even open an account for Bob
>> today, why would a payment hub lock up hard bitcoin to allow Bob to be
>> paid through a Poon-Dryja channel?
>>
>>
>> Funding Source (2)
>> Bob's previous spends
>>
>> If Bob has previously spent from the channel, decreasing his claim on
>> its funds (which he could have deposited himself), that claim can be
>> re-increased.
>>
>> To avoid needing credit (1), Bob has an incentive to consolidate
>> spending and income in the same payment channel, just as with today's
>> banks.  This is at odds with the idea that Bob will have accounts with
>> many payment hubs.  It is an incentive for centralization.
>>
>>
>> With Lightning Network, Bob will need a powerful middleman to send and
>> receive money effectively.  *That* is uninteresting to me.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a11c25f52ea1faf051ce6861b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In the Lightning network it is assumed that the balances c=
an always be settled on the blockchain if any of the parties along the chan=
nel has a problem. What if the fee on the settlement transactions is not hi=
gh enough to enter the blockchain? You can&#39;t do replace-by-fee after th=
e fact. Do the fees always have to assume worst case scenarios on the Bitco=
in fee market?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <span dir=3D=
"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Tom, you appear to be =
misunderstanding how lightning network and micropayment hub-and-spoke model=
s in general work.<span class=3D""><br><br>&gt; But neither can Bob receive=
 money, unless payment hub has<br>
advanced it to the channel (or (2) below applies).=C2=A0 Nothing requires t=
he<br>
payment hub to do this.<br><br></span></div>On the contrary the funds were =
advanced by the hub on the creation of the channel. There is no credit invo=
lved. if the funds aren&#39;t already available for Bob to immediately clai=
m his balance, the payment doesn&#39;t go through in the first place.<br></=
div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via=
 bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/4/2015 4:27 AM, =
Pieter Wuille via bitcoin-dev wrote:<br>
<br>
&gt; Don&#39;t turn Bitcoin into something uninteresting, please.<br>
<br>
Consider how Bob will receive money using the Lightning Network.<br>
<br>
Bob receives a payment by applying a contract to his local payment<br>
channel, increasing the amount payable to him when the channel is closed.<b=
r>
<br>
There are two possible sources of funding for Bob&#39;s increased claim.<br=
>
They can appear alone, or in combination:<br>
<br>
<br>
Funding Source (1)<br>
A deposit from Bob&#39;s payment hub<br>
<br>
Bob can receive funds, if his payment hub has made a deposit to the<br>
channel.=C2=A0 Another name for this is &quot;credit&quot;.<br>
<br>
This credit has no default risk: Bob cannot just take payment hub&#39;s<br>
deposit. But neither can Bob receive money, unless payment hub has<br>
advanced it to the channel (or (2) below applies).=C2=A0 Nothing requires t=
he<br>
payment hub to do this.<br>
<br>
This is a 3rd-party dependency totally absent with plain old bitcoin.<br>
It will come with a fee and, in an important way, it is worse than the<br>
current banking system.=C2=A0 If a bank will not even open an account for B=
ob<br>
today, why would a payment hub lock up hard bitcoin to allow Bob to be<br>
paid through a Poon-Dryja channel?<br>
<br>
<br>
Funding Source (2)<br>
Bob&#39;s previous spends<br>
<br>
If Bob has previously spent from the channel, decreasing his claim on<br>
its funds (which he could have deposited himself), that claim can be<br>
re-increased.<br>
<br>
To avoid needing credit (1), Bob has an incentive to consolidate<br>
spending and income in the same payment channel, just as with today&#39;s<b=
r>
banks.=C2=A0 This is at odds with the idea that Bob will have accounts with=
<br>
many payment hubs.=C2=A0 It is an incentive for centralization.<br>
<br>
<br>
With Lightning Network, Bob will need a powerful middleman to send and<br>
receive money effectively.=C2=A0 *That* is uninteresting to me.<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a11c25f52ea1faf051ce6861b--