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
143
144
145
146
147
148
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 97944305
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:46:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9606A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:45:59 +0000 (UTC)
Received: by igblr2 with SMTP id lr2so40018424igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 10:45:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=VwtCFXo8KN2C8ghmUI1rwteZqc+hFiKb84BEXHMrnno=;
b=lril4ftezLFAysCLOYovTiXgaulprCd11jOn7fVAgSVbSS24+uR1J91uByea275mF4
/eBRn/qBmOxt1XBRwvUB33AJ1zyOEAuJ2ivAtWLpdlPZ6YuTcaLUWjunVsS2/N+whp95
j8yjE+m/wUlFXu4dYz1cio3mnWSD8UJgX9bKJjJ5eURatJ7aXQXM+cquV6mhWRh/qZND
O0QnUg9pyww40F16F39BBwfnoBUUwRwS2BCCwkS2MpdoURaju56err6tEifONR4TrELY
7jnKkFfQF0J1+lTDPbqUsl1PU66cNdWc9R1pO9VE1OAREUsuYAWFduDx7UepJ7b9OYJQ
aCDg==
X-Gm-Message-State: ALoCoQlWPm7rMPw+VzAclMFBUF/lZ81A2iSwAFtnw0ALjaE1AMABJUC0jifZnvHP3fvtN7aZSCtN
MIME-Version: 1.0
X-Received: by 10.43.40.130 with SMTP id tq2mr15034597icb.46.1435513559432;
Sun, 28 Jun 2015 10:45:59 -0700 (PDT)
Received: by 10.107.149.20 with HTTP; Sun, 28 Jun 2015 10:45:58 -0700 (PDT)
X-Originating-IP: [208.54.4.191]
Received: by 10.107.149.20 with HTTP; Sun, 28 Jun 2015 10:45:58 -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 10:45:58 -0700
Message-ID: <CAOG=w-shLgDmRhOgS6btgUX5hf9jhSrAtms8CkLuuNOtgf6ReQ@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec51dd849c7da2f0519978b68
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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:46:00 -0000
--bcaec51dd849c7da2f0519978b68
Content-Type: text/plain; charset=UTF-8
Gavin, do you use a debit card or credit card? Then you do fit that use
case. When you buy a coffee at Starbucks, it is your bank that pays
Starbuck's bank. So it is with micropayment hubs.
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
--bcaec51dd849c7da2f0519978b68
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Gavin, do you use a debit card or credit card? Then you do f=
it that use case. When you buy a coffee at Starbucks, it is your bank that =
pays Starbuck's bank. So it is with micropayment hubs.</p>
<div class=3D"gmail_quot<blockquote class=3D" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">On Sun, 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><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">But ultimately, lightning usefully solves a probl=
em where participants have semi-long lived payment endpoints.</blockquote><=
/div><br>Very few of my own personal Bitcoin transactions fit that use-case=
.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In f=
act, very few of my own personal dollar transactions fit that use-case (I s=
uppose if I was addicted to Starbucks I'd have one of their payment car=
ds that I topped up every once in a while, which would map nicely onto a pa=
yment 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 t=
o 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 payment channels would work =
between big financial institutions as a settlement layer, but isn't tha=
t exactly the centralization concern that is making 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 centralization-wise compared to =
a few thousand fully-validating Bitcoin nodes.</div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">Don't get me wrong, I think th=
e Lightning Network is a fantastic idea and a great experiment and will lik=
ely be used for all sorts of great payment innovations (micropayments for b=
andwidth maybe, or maybe paying workers by the hour instead of at the end o=
f the month). But I don't think it is a scaling solution for the types =
of payments the Bitcoin network is handling today.<br clear=3D"all"><div><b=
r></div>-- <br><div>--<br>Gavin Andresen<br></div><div><br></div>
</div></div>
</div>
--bcaec51dd849c7da2f0519978b68--
|
