Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 685128E6 for ; Sun, 9 Aug 2015 22:36:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FFDA14B for ; Sun, 9 Aug 2015 22:36:29 +0000 (UTC) Received: by pdrh1 with SMTP id h1so46143868pdr.0 for ; Sun, 09 Aug 2015 15:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=guTdthlDqJl3fzJ/+wSJ8PddavPtDuJILiaZUKvylvY=; b=OGJhxJB/eWylZ8JF75FDM7zfMMOMAY7t6h6Xu0/bE2TYFuROlHcbsgZKH6TdYV0b3+ /idB3L5h3DPDB4/Gh76UdiO8i3gGSl90TBwt53F2lK1Uxlf9DV/MEUIwhVDQTOrWdKyr g7hRWE6qEBeJZiZIz4fSZlS+FLHhzhB14NwBz7pY36sBXZDYw/soNilOgViPv2RQyrz8 Z4uhKRlxlVThmFVzc4fptgjixeKSFfyRq6NLTGzHwlmH3yPR6Vw0NgElZ3LJty47JuEH knepDBnrkU6Bjca1ys3R3CEVdDhKH3B/ELlkTgiYJyFr7bjrifUSAG6QggiLPmdi3uF4 Or5A== X-Received: by 10.70.134.134 with SMTP id pk6mr27937332pdb.143.1439159789291; Sun, 09 Aug 2015 15:36:29 -0700 (PDT) Received: from [10.45.134.100] (c-67-188-9-126.hsd1.ca.comcast.net. [67.188.9.126]) by smtp.googlemail.com with ESMTPSA id v9sm17535990pdr.96.2015.08.09.15.36.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2015 15:36:28 -0700 (PDT) Message-ID: <55C7D5EC.3000204@gmail.com> Date: Sun, 09 Aug 2015 15:36:28 -0700 From: Patrick Strateman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Bitcoin Dev References: <55C79FF0.8040100@thinlink.com> <55C7CCE5.10208@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040803070508020405080607" 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 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 22:36:30 -0000 This is a multi-part message in MIME format. --------------040803070508020405080607 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the contrary those costs are clearly very low. Both the time value of money and operating expenses will be trivial with even a small volume of transactions. The true cost of operating a hub is clearly in the enhanced risk of loss.= It's clear that risk of loss will be moderated by market forces. The hubs which are better at securing their systems will reduce their risk of loss and obtain a competitive advantage. It's also important to note that the risk of loss is the same whether the hub is doing 1 transaction/second or 1 million transactions/second. At 1 transaction/second the cost (but not necessarily the fees) is going to be quite high. At 1 million transactions/second the cost is going to be very very low. On 08/09/2015 03:03 PM, Hector Chu wrote: > Ok good. We have established it to be a non-trivial cost. > Now, what is the growth complexity of the total cost of the network in > terms of number of connections each hub has to other hubs? And then, > consider a payment channel with many hops in it. The end-to-end users > would have to swallow all the costs of the hubs in the channel. > > On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev > > wrote: > > The costs of operating a hub are as follows: > > Time value of the funds the Hub has locked up in payment channels. > Enhanced risk of loss of control of private keys (the keys > necessarily need to be on an internet connected system). > Operating costs (I expect this will be minimal). > > The hub can charge a fee for it's services to recoup these costs. > > > On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev 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. So no, there is >> no credit advanced by the payment hub to anyone. >> >> Given Mark's previous answer of using CPFP and other tricks to >> pay for the Bitcoin transaction fees, we can assume that Bitcoin >> fees do not play a part in the payment channel balances. >> >> So, the interesting question is what are the costs of running a >> payment hub? The tx fees that a payment hub would have to pay to >> settle its Bitcoin transactions would be passed on as a cost to >> the clients of the payment hub. Also there is a cost to locking >> up funds in a payment channel (time value of money). The lost >> interest or opportunity cost on those funds would need to be paid >> for by its clients as well. And don't forget normal running costs >> such as networking and electricity. >> >> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev >> > > wrote: >> >> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" >> > wrote: >> >> > On the contrary the funds were advanced by the hub on the cr= eation of the channel. >> There is no credit involved. >> >> That's a chuckle.=20 >> >> As I said, nothing requires the hub to advance anything, and >> if it does, Bob can expect to pay for it. >> >> We'll see whether hubs assess a fee for depositing funds, >> whether the fee depends on the amount deposited, and whether >> it depends on the amount of time it stays there. >> >> I predict "all of the above." There is a name for these kinds >> of fees. Can you guess it? >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --------------040803070508020405080607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On the contrary those costs are clearly very low.

Both the time value of money and operating expenses will be trivial with even a small volume of transactions.

The true cost of operating a hub is clearly in the enhanced risk of loss.

It's clear that risk of loss will be moderated by market forces.

The hubs which are better at securing their systems will reduce their risk of loss and obtain a competitive advantage.

It's also important to note that the risk of loss is the same whether the hub is doing 1 transaction/second or 1 million transactions/second.

At 1 transaction/second the cost (but not necessarily the fees) is going to be quite high.

At 1 million transactions/second the cost is going to be very very low.

On 08/09/2015 03:03 PM, Hector Chu wrote:
Ok good. We have established it to be a non-trivial cost.
Now, what is the growth complexity of the total cost of the network in terms of number of connections each hub has to other hubs? And then, consider a payment channel with many hops in it. The end-to-end users would have to swallow all the costs of the hubs in the channel.

On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The costs of operating a hub are as follows:

Time value of the funds the Hub has locked up in payment channels.
Enhanced risk of loss of control of private keys (the keys necessarily need to be on an internet connected system).
Operating costs (I expect this will be minimal).

The hub can charge a fee for it's services to recoup these costs.


On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev 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. So no, there is no credit advanced by the payment hub to anyone.

Given Mark's previous answer of using CPFP and other tricks to pay for the Bitcoin transaction fees, we can assume that Bitcoin fees do not play a part in the payment channel balances.

So, the interesting question is what are the costs of running a payment hub? The tx fees that a payment hub would have to pay to settle its Bitcoin transactions would be passed on as a cost to the clients of the payment hub. Also there is a cost to locking up funds in a payment channel (time value of money). The lost interest or opportunity cost on those funds would need to be paid for by its clients as well. And don't forget normal running costs such as networking and electricity.

On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org> wrote:

> On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved.

That's a chuckle. 

As I said, nothing requires the hub to advance anything, and if it does, Bob can expect to pay for it.

We'll see whether hubs assess a fee for depositing funds, whether the fee depends on the amount deposited, and whether it depends on the amount of time it stays there.

I predict "all of the above." There is a name for these kinds of fees.  Can you guess it?


_______________________________________________
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


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--------------040803070508020405080607--