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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
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 0C275ACC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 18:58:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DA1AA7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 18:58:57 +0000 (UTC)
Received: from mail-qk0-f178.google.com ([209.85.220.178]) by
mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id
0Ludss-1Z0aYq2Qy0-00zpRn for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 20:58:56 +0200
Received: by qkeo142 with SMTP id o142so84145214qke.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 11:58:55 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.152.72 with SMTP id 69mr15516708qhy.85.1435517935925;
Sun, 28 Jun 2015 11:58:55 -0700 (PDT)
Received: by 10.96.28.39 with HTTP; Sun, 28 Jun 2015 11:58:55 -0700 (PDT)
In-Reply-To: <CALqxMTFv+nLo3phA2HS26F=r5+yGCOh=z8+Kub7GuC_bGVOfXg@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>
<CALqxMTFv+nLo3phA2HS26F=r5+yGCOh=z8+Kub7GuC_bGVOfXg@mail.gmail.com>
Date: Sun, 28 Jun 2015 20:58:55 +0200
Message-ID: <CALqxMTG7+MMN50VH9-Y++B1_DeBXTBKpkeA5dYT1EbVGZ1aYag@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:cuQVTPJ+b1x1C6LzHfcn9opAQ9zVnt74MBhLqRlEw7NlLAeBQvY
cfrl+uRSoTWfCp0TxLr/9XTc/V2X0UCeeGlU8kNVe7NwxZUW1p59NYAnRwlRdT/lAC+yPyw
UApacyVursiewk3ICT4vIcBRPHXTtcGfm9OtatZCWPbG9HFwFhk3rfGwAovPcTgmjF3xtwA
DUU44uVk0WHK+Q8767d2g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:FfNhsXlIr8A=:fW92VdjKLBvdY5FF39hCoA
VXDdguBpvYpcnz6/xUDCsptR96vBlIFDWJGhujxxbAK4PuhTBs9oRqPj7GSCQ4r+iIdpM+3Sc
cjoo7tjIlk3im062PZNecgjijQ+CPO9sUepz8d3FCw4qL9ElaITokXXaVFVZUbPrO/JwP1JDZ
xT4lEOWhkoE1cmvdY1ETQtMwybcNgwCdZMhhyRBvuojLjWxTAXJGyvmxSjTCpG6e8jnSzncWI
ABtwknR+aPPU/yI9rsHdOI5vDoWYcyWqUXFilH0eERVJjNdgPU2OIRk3V3lUgUQYQJ0AI73WJ
1uhcBJdiW2yyIqe9STG+wOfN6SwRng8GWGYagBYg0nV3CA+aCloL6qRjQV9MC21eMCSOKmz3A
MIoWvpfZMaT2+naa40tycMqL9mpbgyaq2wVOXQSduMjGiqRklnVx5cwnlkni10ZxWjdgyO8mm
aceEHXGrncdOHQDNU0Y8DSTA3f9dLKDHHE2UD0yyDOdcJNt9hVVAUmkdijx2kvwo3Q+IGeYyf
OuD/tJSunWcrCztFg6Jy62hmggBG1bQUP12Pm4/XyTzuwMRMIIOx1YZWwT3fgtv/+B9lZQTo3
lBgpqMZQ8ctt4GRFzR/w2AHftnxF1uEw3sqNgSFhtg5pyOAKn8+MV8p/ECIL1+sv70sUICbfD
m+9n96qb81wsT3g7Z3kRj9wUEXcJccD/meNnmzsiBJT1+8g==
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 18:58:58 -0000
This is probably going to sound impolite, but I think it's pertinent.
Gavin, on dwelling on the the fact that you appear to not understand
the basics of the lightning network, I am a little alarmed about this,
given your recent proposals to unilaterally push the network into
quite dangerous areas of game theory, to lobby companies etc.
People are super polite and respectful around here, but this is not
looking good, if you don't mind me saying so. You can't make balanced
or informed trade-offs on block-size schedules stretching into the
future, if you don't understand work that is underway, and has been
for months. Lightning is a major candidate approach the rest of the
technical community sees for Bitcoin to scale.
Lightning allows Bitcoin to scale even without a block-size increase,
and therefore considerably impacts any calculation of how much
block-size is required. In this light you appear to have been
attempting to push through a change without even understanding the
alternatives or greater ecosystem.
Adam
On 28 June 2015 at 19:51, Adam Back <adam@cypherspace.org> wrote:
> 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
|
