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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D8CD273
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:29:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com
[209.85.215.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40F21A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:29:12 +0000 (UTC)
Received: by lagx9 with SMTP id x9so102016750lag.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 10:29:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=SS5/rIjlozE969RF0v8r3CnlSQnan8OYLJe414GhXl4=;
b=VX7VzCmbl3K9hulcK7ZJ1Vj03isq4AayY4vB7QDqfvkW/xG9K0BlG9E9mmfcvOr+H/
ZJAvaMR64g93JkNLkE3yvZgiGh9VLK0bG2ScMii3F6vYzag/Zw7K4uomp6LcBWHruKGQ
k7AuvdAzss9Md1geOcOCViwHrEXTJioABmeb2yUDHHvahUzhG7Bg1WVfKVarXt87eEqP
sdi+9fWd4Qrv6b5RsSgnV+bgvyZ8HdRxWaBNSytSBuk3nkQzKKeihduQuMX2p8Eh1joc
AGU+63UizsVqOvaiKAWPTa8JTTMwJJ4SnWL4SOydyJ+lKEhS3NL9eOT+0Zbuu6ouM7P0
+p7A==
MIME-Version: 1.0
X-Received: by 10.152.164.193 with SMTP id ys1mr10515978lab.65.1435512550452;
Sun, 28 Jun 2015 10:29:10 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Sun, 28 Jun 2015 10:29:10 -0700 (PDT)
In-Reply-To: <CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@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>
Date: Sun, 28 Jun 2015 13:29:10 -0400
Message-ID: <CABsx9T3PaBcYkXWyn=TmCROn61CGkEYD9qxob6hKGdD3sy-SyQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=001a1133c258a3f6410519974fb6
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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:29:13 -0000
--001a1133c258a3f6410519974fb6
Content-Type: text/plain; charset=UTF-8
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.
Very few of my own personal Bitcoin transactions fit that use-case.
In fact, very few of my own personal dollar transactions fit that use-case
(I suppose if I was addicted to Starbucks I'd have one of their payment
cards that I topped up every once in a while, which would map nicely onto a
payment channel). I suppose I could setup a payment channel with the
grocery store I shop at once a week, but that would be inconvenient (I'd
have to pre-fund it) and bad for my privacy.
I can see how payment channels would work between big financial
institutions as a settlement layer, but isn't that exactly the
centralization concern that is making a lot of people worried about
increasing the max block size?
And if there are only a dozen or two popular hubs, that's much worse
centralization-wise compared to a few thousand fully-validating Bitcoin
nodes.
Don't get me wrong, I think the Lightning Network is a fantastic idea and a
great experiment and will likely be used for all sorts of great payment
innovations (micropayments for bandwidth maybe, or maybe paying workers by
the hour instead of at the end of the month). But I don't think it is a
scaling solution for the types of payments the Bitcoin network is handling
today.
--
--
Gavin Andresen
--001a1133c258a3f6410519974fb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 28, 2015 at 1:12 PM, Mark Friedenbach <span dir=3D"ltr"><<a href=
=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But ultimately, lightn=
ing usefully solves a problem where participants have semi-long lived payme=
nt endpoints.</blockquote></div><br>Very few of my own personal Bitcoin tra=
nsactions fit that use-case.</div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">In fact, very few of my own personal dollar transact=
ions fit that use-case (I suppose if I was addicted to Starbucks I'd ha=
ve one of their payment cards that I topped up every once in a while, which=
would map nicely onto a payment channel). I suppose I could setup a paymen=
t channel with the grocery store I shop at once a week, but that would be i=
nconvenient (I'd have to pre-fund it) and bad for my privacy.</div><div=
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I can see how p=
ayment channels would work between big financial institutions as a settleme=
nt layer, but isn't that exactly the centralization concern that is mak=
ing a lot of people worried about increasing the max block size?<br><br>And=
if there are only a dozen or two popular hubs, that's much worse centr=
alization-wise compared to a few thousand fully-validating Bitcoin nodes.</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Don'=
;t get me wrong, I think the Lightning Network is a fantastic idea and a gr=
eat experiment and will likely be used for all sorts of great payment innov=
ations (micropayments for bandwidth maybe, or maybe paying workers by the h=
our instead of at the end of the month). But I don't think it is a scal=
ing solution for the types of payments the Bitcoin network is handling toda=
y.<br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature">--=
<br>Gavin Andresen<br></div><div class=3D"gmail_signature"><br></div>
</div></div>
--001a1133c258a3f6410519974fb6--
|
