Re: [bitcoin-dev] What Lightning Is

From: Hector Chu <hectorchu@gmail•com>
To: Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] What Lightning Is
Date: Sun, 9 Aug 2015 21:14:55 +0100	[thread overview]
Message-ID: <CAAO2FKHyNC6PT+i2pYo88eeb-wdkJdeVjmqzC=PetyF6yO=+Lw@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-skYq84=PtN45FB-dGoY1783Jz7K1T16e2JVGjLazWuyA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3397 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 4643 bytes --]