Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6072F898 for ; Sun, 9 Aug 2015 20:15:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F7BEE2 for ; Sun, 9 Aug 2015 20:15:17 +0000 (UTC) Received: by lbbtg9 with SMTP id tg9so47169815lbb.1 for ; Sun, 09 Aug 2015 13:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bGiiCXipoJvt3cerCH3YyUbHGpaDjFcCVn7G1255VNw=; b=M8KBgMqw6KPh0/t2mFIhZf3oh1Cg6Nqy4f3rWM6tfP+cK+xrBEPZcjvXK6Net2AF27 b77CBuIJE5YVbJHX6X16wA/s+JKIpgYMPj1QVLn2gdIdOBLu1zCn/IAJUougxnZ9SQ/t XDUpMI5hqLg5YYabUkafe9mFASsns2DyAKNWqBpLQ/NNEqXiF1+CHJIc5Do6vFJneppJ h/HfJQ2U8YBAgBDCeNGokxNNI/N3lozDD9RPRkSGHAzvT/rmF6PwzGlFiycU8x8X2wtH 2khKZZWPkwpXbkaTj7pT6+rbsO0K4/QIR5oE+U0KstfrOjaxBe45Apfud/HCeqCrZeUb Y01g== X-Received: by 10.112.161.40 with SMTP id xp8mr17218003lbb.71.1439151315097; Sun, 09 Aug 2015 13:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.25 with HTTP; Sun, 9 Aug 2015 13:14:55 -0700 (PDT) In-Reply-To: References: <55C79FF0.8040100@thinlink.com> From: Hector Chu Date: Sun, 9 Aug 2015 21:14:55 +0100 Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary=001a11c25f52ea1faf051ce6861b X-Spam-Status: No, score=-0.3 required=5.0 tests=BAD_CREDIT,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] What Lightning Is X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 20:15:18 -0000 --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
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'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?

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 model= s in general work.

> But neither can Bob receive= money, unless payment hub has
advanced it to the channel (or (2) below applies).=C2=A0 Nothing requires t= he
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 invo= lved. if the funds aren't already available for Bob to immediately clai= m 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.=C2=A0 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).=C2=A0 Nothing requires t= he
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.=C2=A0 If a bank will not even open an account for B= ob
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.=C2=A0 This is at odds with the idea that Bob will have accounts with=
many payment hubs.=C2=A0 It is an incentive for centralization.


With Lightning Network, Bob will need a powerful middleman to send and
receive money effectively.=C2=A0 *That* is uninteresting to me.


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a11c25f52ea1faf051ce6861b--