1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0141C305
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:51:03 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C7BCA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:51:02 +0000 (UTC)
Received: from mail-qc0-f177.google.com ([209.85.216.177]) by
mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
0MfpSM-1ZNcDx2B52-00NCRO for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 19:51:01 +0200
Received: by qcmc1 with SMTP id c1so38737521qcm.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 10:51:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.22.5 with SMTP id g5mr24399894qkh.45.1435513860782; Sun,
28 Jun 2015 10:51:00 -0700 (PDT)
Received: by 10.96.28.39 with HTTP; Sun, 28 Jun 2015 10:51:00 -0700 (PDT)
In-Reply-To: <CABsx9T3PaBcYkXWyn=TmCROn61CGkEYD9qxob6hKGdD3sy-SyQ@mail.gmail.com>
References: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl>
<CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com>
<CAOoPuRarNoPwLxVqjJ_g4b6HsWJecB-oCdfEjaknKbUnKdnmEg@mail.gmail.com>
<CALqxMTGXcbES5Pwz3cWO+PQK5kmf3rZ_i00=b=PBnO678XuF0A@mail.gmail.com>
<COL131-DS8E3DCDBD1A0F359206781CDAB0@phx.gbl>
<CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com>
<CABsx9T3PaBcYkXWyn=TmCROn61CGkEYD9qxob6hKGdD3sy-SyQ@mail.gmail.com>
Date: Sun, 28 Jun 2015 19:51:00 +0200
Message-ID: <CALqxMTFv+nLo3phA2HS26F=r5+yGCOh=z8+Kub7GuC_bGVOfXg@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:0beh6Zp/IiS8yn4l9+58jox8sVZxzWGdwVb6pPlXbw1Pa7AMV2k
kNuo16Pfj5nKUBtR9w7Ggb3j6/+G14Cf+oYtEZQoXCZhlM5l6Xrgkhco+OpuCXpihK0qpWN
AlT+/tr8MGSYVON34/PIzToANvfzXQLk6v/7Qptg5yofp4vfA+J7hckULs66Ww/iWYlKqru
VWy0zuEPhc6TLISP100cA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:yc/57P9d89g=:IfVeS+fLbBr6ogemn5FWSz
zNAt1VbVO8FzyPDOZArv4mAW0LDN0nOX5Zghb8i9IT2XcdSdEGW7Neh6zy1EnCta0jJHdEMgm
FFGczK/+gucqGNOa74BXZebhlm/Adg1mSRSNlpYfLpd+tOq0HQbOugAL3kDVi9xU52KTPaEiX
7rtHPeK0z06Om6sqpEI1xF18L0FPqkmtWOqdbfWJxHupR6GX+nW5iCJ82Wxj5GzoN7z7c0M9I
nrxgyUUk91IYHYi76mLE6/QmnTUPneQ8ax8d6gie5ho/sSs+pSMLbD0gjYFJ5llgr+PCeKjxu
iuF3KwX9BryErB7L4gAjy8VyYBnO/1g55nuuZxFptL6/FeeQbP28XtNfLMmIQpHpgHRaErRrD
EwlQT32rYwM7chMRKO1eP0HGDvVGIne3Trycv9hfbqTEsRk91pit63ZB1dk9LbasFF91G4qD2
CmYEAzuQ5AOO8XOLn/TTG8LDeOd37dUoXyF6Yv/nRoQG9h1JHOnS+A1Eyfm2fnf5olmx6cR21
rldh9/e00v+c3AGSnV6uwOlieSJa+fjg+BmBGO+mTxPf54dwpaF9cwh7EaI0UZoaO/CHoaMeG
gu992kqZLsTpb3LnqA9D6gsD4Tvze7OvYxBAzI7lcEQ143mMm/Oe753pTUbGsCSJrK4pmprVD
qBkdJJCG5XzdeknQAYLYRmOUjbHY+IEzCqPZBJqdQAAsOeQ==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2015 17:51:03 -0000
On Sun, Jun 28, 2015 at 1:12 PM, Mark Friedenbach <mark@friedenbach.org> wrote:
> But ultimately, lightning usefully solves a problem where participants have semi-long lived payment endpoints.
Recipients do benefit from keeping connections to hubs because if a
hub goes away or a user abandons a hub that tends to generate new
on-chain traffic for balance reclaim, and new channel establishment,
as we understand the limits so far.
On 28 June 2015 at 19:29, Gavin Andresen <gavinandresen@gmail.com> wrote:
> Very few of my own personal Bitcoin transactions fit that use-case.
I believe Mark is talking about the one hop (direct) connections
benefits from being long-lived; the payment destination is not
restricted in the same way. It's more like having a static IP address
with your ISP, that doesnt stop you reaching anywhere on the internet.
Say the Lightning Network has an average fan out of 10, now subject to
capital and rebalancing flows in the network you can pay anyone of a
billion people in 9 hops. Maybe the fanout is lumpy, with some bigger
hubs - that just serves to reduce the number of hops. Maybe there are
some capitalisation limits, that is dealt with by negative fees and
recirculation (more on that below) or failing that recapitalisation
on-chain. Some people assume that the hub will run out of
capitalisation on a given channel, however if people and hubs retain
redundant channels they can be paid to rebalance channels, and even
users can be paid by other users if there is a net flow from some
users, to a given business eg starbucks, where the users just buy new
BTC for USD and spend and dont earn BTC. Rebalancing would work
because the exchange where they buy new BTC would be incentivised to
pay starbucks (or whoever has excess coins on a channel) to send the
coins back to the users topping up by paying them negative fees,
because the fees to do that should be less than using on-chain
transactions.
> But I don't think it is a scaling solution for the types of payments the Bitcoin
> network is handling today.
Actually I think it may well be able to do that very well. We dont
know for sure how it will work until we see the balance and
effectiveness of the network algorithms against usage (eg simulating
from Bitcoin's historic usage say), but there's good reason to see
that BTC can recirculate and rebalance due to the reversible
non-expiring channels and capitalisation requirements can be lower
than simple expectation due higher velocity and redistribution of fees
to anyone with excess liquidity and connectivity heading in the right
direction.
Adam
|
