summaryrefslogtreecommitdiff
path: root/a0/5b9c0b4b45489499abb677be5afd49c3b04905
blob: 7cb64dff9f679087cdc3699e035f6df1196954ad (plain)
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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A0CE905
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Mar 2017 02:01:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
	[209.85.213.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D5CCC20F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Mar 2017 02:01:50 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id d188so75411227vka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 19:01:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=fB0wB61hwOsMaQZXSc2aKYnaer7hIXOgEAxdof23MHc=;
	b=KZwD68Wv9rJTnkJqfTgtL97RvHLWoV5jjCzpVKoTYyn6mIO++Z6RzgbCSpSaC2WwBu
	vY8NnWgbapPRSgxAm99zZYaa7vBj4KIOmFtdQGQJdiKLW5DzFSz0FFFgs3WX/TyDCejX
	Q4mwjfK5iounYRmjMJn9gi22FonSx1MfB+rOHE2uDQfZ0gnL6HpCeSmW1Q1iKp5QliDS
	HzTbizfGRDa9VzkXz3/ScN9ABusqQk9PBaOZP/RPjTqLHmjuOYzyw+Re59sKNiHqXpcC
	iwU2PsfYLQ8mW8N6m1q7mgvAhZtXrNuc7Hv9lI8lMrXdeBo1CFFaPP2q5IgfvzrC9D/3
	AHNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=fB0wB61hwOsMaQZXSc2aKYnaer7hIXOgEAxdof23MHc=;
	b=tx9AvHDbRyBipig166vG9MdkZ1ZBIIvvJYnr/hKgRRjlKYFYF+8ORRuYF66pOb9EIy
	+tzOCxvzSHN1ZXMSb9CzvO/nuFIPMog0C4S90sA5MTFJk2z0lGyS1M0Nt8m9ssai7IXD
	p66qfrXWfpYFNfe0ZVUb/nGOkl2DVDzneJ/6GJIeSwj46QhTWKTUx8eDkgC3iIWCwViR
	GMgJYpSyNGYcX6odV20Jhp6aRAYmqH2qZ41Y0isEeEWZIHRCYFrNB02HIQk8DFcTisfm
	AR/ghlFRjFa6hpUydkZepB1+6g45OJB4SsoWJfLu3+vQTqjYZSQOM0uaZKfOPHdP/Ds/
	u0Xg==
X-Gm-Message-State: AFeK/H1koKzTqaXuZXWRFqQEty6WOe1RZbKcMt0ngg2LuUHqwll+9YArlzJunZHiq1zUgc5INcHMmUUBkWHPaw==
X-Received: by 10.31.218.195 with SMTP id r186mr231252vkg.112.1490925709965;
	Thu, 30 Mar 2017 19:01:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Thu, 30 Mar 2017 19:01:49 -0700 (PDT)
In-Reply-To: <61B9AE0D-5A58-4A72-8834-8ED164ED627F@gmail.com>
References: <CALJP9GB2Fds8m9JpaVv0NxGDr579BtR9RMs7-KNSLkK8Mz7LoA@mail.gmail.com>
	<CALJP9GAOgpSAhrrYFPRbGKZXwqZn_oDUmv6B7wcvwxcZufDd0g@mail.gmail.com>
	<CALJP9GDkdxsvOZHJxzx+0pvjWBAkAswZCWXcp=zL7LNMRNfCOg@mail.gmail.com>
	<CALJP9GBk4gG0H+tEJmEiz=0+LAQoe6_sL1Fv-BCJSfmvfY8PRA@mail.gmail.com>
	<CALJP9GDH1xQ-cYc1SN6jejXDA49eiy_OR49XLLWd+=VdNo7ekA@mail.gmail.com>
	<CAFVRnyq07qNappzwEmB_e+xCKPyCzHcWbnTDWCdeWjrsMMioLQ@mail.gmail.com>
	<CAD1TkXsfb7VC7stXV33me1PDem750adpyETg-finKyjnV=Syxg@mail.gmail.com>
	<61B9AE0D-5A58-4A72-8834-8ED164ED627F@gmail.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Thu, 30 Mar 2017 19:01:49 -0700
Message-ID: <CAD1TkXug2qFggztJL=Z7Thzx13E6ga-2Ps9yZFzonn2YjStrcg@mail.gmail.com>
To: Vladimir Zaytsev <vladimir.zaytsev@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c07adbc543f2a054bfd3105
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 31 Mar 2017 02:31:10 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] High fees / centralization
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 31 Mar 2017 02:01:51 -0000

--94eb2c07adbc543f2a054bfd3105
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That would be blockchain sharding.

Would be amazing if someone could figure out how to do it trustlessly.  So
far I'm not convinced it is possible to resolve the conflicts between the
shards and commit transactions between shards.

On Thu, Mar 30, 2017 at 6:39 PM, Vladimir Zaytsev <
vladimir.zaytsev@gmail.com> wrote:

> There must be a way to organize =E2=80=9Cbranches=E2=80=9D of smaller act=
ivity to join
> main tree after they grow. Outsider a bit, I see going circles here, but
> not everything must be accepted in the chain. Good idea as it is, it=E2=
=80=99s just
> too early to record every sight=E2=80=A6.
>
>
>
> On Mar 30, 2017, at 5:52 PM, Jared Lee Richardson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Further, we are very far from the point (in my appraisal) where fees
> are high enough to block home users from using the network.
>
> This depends entirely on the usecase entirely.  Most likely even without =
a
> blocksize increase, home purchases will be large enough to fit on the
> blocksize in the forseeable future.  Microtransactions(<$0.25) on the oth=
er
> hand aren't viable no matter what we try to do - There's just too much da=
ta.
>
> Most likely, transaction fees above $1 per tx will become unappealing for
> many consumers, and above $10 is likely to be niche-level.  It is hard to
> say with any certainty, but average credit card fees give us some
> indications to work with - $1.2 on a $30 transaction, though paid by the
> business and not the consumer.
>
> Without blocksize increases, fees higher than $1/tx are basically
> inevitable, most likely before 2020.  Running a node only costs $10/month
> if that.  If we were going to favor node operational costs that highly in
> the weighting, we'd better have a pretty solid justification with
> mathematical models or examples.
>
> > We should not throw away the core innovation of monetary sovereignty in
> pursuit of supporting 0.1% of the world's daily transactions.
>
> If we can easily have both, why not have both?
>
> An altcoin with both will take Bitcoin's monetary sovereignty crown by
> default.  No crown, no usecases, no Bitcoin.
>
>
>
>

--94eb2c07adbc543f2a054bfd3105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That would be blockchain sharding.<br><br>Would be amazing=
 if someone could figure out how to do it trustlessly.=C2=A0 So far I&#39;m=
 not convinced it is possible to resolve the conflicts between the shards a=
nd commit transactions between shards.</div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Thu, Mar 30, 2017 at 6:39 PM, Vladimir Zaytse=
v <span dir=3D"ltr">&lt;<a href=3D"mailto:vladimir.zaytsev@gmail.com" targe=
t=3D"_blank">vladimir.zaytsev@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>There must be=
 a way to organize =E2=80=9Cbranches=E2=80=9D of smaller activity to join m=
ain tree after they grow. Outsider a bit, I see going circles here, but not=
 everything must be accepted in the chain. Good idea as it is, it=E2=80=99s=
 just too early to record every sight=E2=80=A6.</div><span class=3D""><div>=
<br></div><div><br></div><br><div><blockquote type=3D"cite"><div>On Mar 30,=
 2017, at 5:52 PM, Jared Lee Richardson via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.<wbr>linuxfoundation.org</a>&gt; wrote:</div><br class=3D"m_161036365440=
3453300Apple-interchange-newline"><div><div dir=3D"ltr">&gt;=C2=A0<span sty=
le=3D"font-size:12.8px">Further, we are very far from the point (in my appr=
aisal) where fees are high enough to block home users from using the networ=
k.</span><div><br>This depends entirely on the usecase entirely.=C2=A0 Most=
 likely even without a blocksize increase, home purchases will be large eno=
ugh to fit on the blocksize in the forseeable future.=C2=A0 Microtransactio=
ns(&lt;$0.25) on the other hand aren&#39;t viable no matter what we try to =
do - There&#39;s just too much data.</div><div class=3D"gmail_extra"><br></=
div><div class=3D"gmail_extra">Most likely, transaction fees above $1 per t=
x will become unappealing for many consumers, and above $10 is likely to be=
 niche-level.=C2=A0 It is hard to say with any certainty, but average credi=
t card fees give us some indications to work with - $1.2 on a $30 transacti=
on, though paid by the business and not the consumer.<br><br>Without blocks=
ize increases, fees higher than $1/tx are basically inevitable, most likely=
 before 2020.=C2=A0 Running a node only costs $10/month if that.=C2=A0 If w=
e were going to favor node operational costs that highly in the weighting, =
we&#39;d better have a pretty solid justification with mathematical models =
or examples.</div><div class=3D"gmail_extra"><br>&gt;=C2=A0<span style=3D"f=
ont-size:12.8px">We should not throw away the core innovation of monetary s=
overeignty in pursuit of supporting 0.1% of the world&#39;s daily transacti=
ons.<br></span><br>If we can easily have both, why not have both?<br><br>An=
 altcoin with both will take Bitcoin&#39;s monetary sovereignty crown by de=
fault.=C2=A0 No crown, no usecases, no Bitcoin.</div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra"><br></div></div></div></blockquot=
e></div><br></span></div></blockquote></div><br></div>

--94eb2c07adbc543f2a054bfd3105--