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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Return-Path: <benjamin.l.cordes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 17D25B8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:26:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com
[209.85.214.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75D71279
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:26:01 +0000 (UTC)
Received: by obbop1 with SMTP id op1so83582620obb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 10:26:00 -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=Mf/FPsZFB3OfBPbUxRBAutN6RHfKkbw+7WQn8ir8I6g=;
b=wfzpLrN2hu1Gd2hvGivk1liOF6IcC9ntgm5wAU/vG5rzYBY743qAcXfbc0xCk7TzjU
hNsbRPf9dobkzAk5c9ObFk64wmQoCIi3Y3qO/hTBqpOeLrfoPD/wfjtI+j9DP9gjeG78
eHoCMe2O6KvxJkzTrLpD9G4gHafXB2iBWA0gYv7PxI2peWKmXkAIHNRp3WaVl40RBjuk
osV2LSpfzqJ4QoQw6JfN8ti/oTiwfNfkPcWc1V0AwQf2pLvEHMPAyNgmtAcvNVCllJxK
gjLl5kqQCOrx6I30dt1zahalAoSdS651aNGf4iF5aqGI5tLOOy2A9f9sd/K46psZzVsX
OG0A==
MIME-Version: 1.0
X-Received: by 10.182.210.165 with SMTP id mv5mr4128540obc.82.1435425960926;
Sat, 27 Jun 2015 10:26:00 -0700 (PDT)
Received: by 10.202.87.197 with HTTP; Sat, 27 Jun 2015 10:26:00 -0700 (PDT)
In-Reply-To: <20150627172011.GB18729@muck>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
<1EF70EBC-8BB8-4A93-8591-52B2B0335F6C@petertodd.org>
<CALgxB7usetoaNCObhG36TrdYgKuP4TSPPNkGatvim1oWUMxaeQ@mail.gmail.com>
<20150627172011.GB18729@muck>
Date: Sat, 27 Jun 2015 19:26:00 +0200
Message-ID: <CAOoPuRZrV_8XJbCbHMEWAfoKYc+OSQQMuhgESgG2JD2nEHoyvQ@mail.gmail.com>
From: Benjamin <benjamin.l.cordes@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c2489480a4c805198326ee
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: Sat, 27 Jun 2015 17:26:02 -0000
--001a11c2489480a4c805198326ee
Content-Type: text/plain; charset=UTF-8
"Thus we have a fixed capacity system where access is mediated by supply
and demand transaction fees."
There is no supply and demand. That would mean users would be able to adapt
fees and get different quality of service depending on current capacity.
For example if peak load is 10x average load, then at those times fees
would be higher and users would delay transactions to smooth out demand.
On Sat, Jun 27, 2015 at 7:20 PM, Peter Todd <pete@petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber wrote:
> > That test seems like a reasonable suggestion; 840GB is not prohibitive
> > given today's computing costs. What other than the successful result of
> > that test would you want to see before agreeing to increase the block
> size
> > to 8MB?
>
> The two main things you need to show is:
>
> 1) Small, anonymous, miners remain approximately as profitable as large
> miners, regardless of whether they are in the world, and even when
> miners are under attack. Remember I'm talking about mining here, not
> just hashing - the process of selling your hashpower to someone else who
> is actually doing the mining.
>
> As for "approximately as profitable", based on a 10% profit margin, a 5%
> profitability difference between a negligable ~0% hashing power miner
> and a 50% hashing power miner is a good standard here.
>
> The hard part here is basically keeping orphan rates low, as the %5
> profitability different on %10 profit margin implies an orphan rate of
> about 0.5% - roughly what we have right now if not actually a bit lower.
> That also implies blocks propagate across the network in just a few
> seconds in the worst case, where blocks are being generated with
> transactions in them that are not already in mempools - circumventing
> propagation optimization techniques. As we're talking about small
> miners, we can't assume the miners are directly conneted to each other.
> (which itself is dangerous from an attack point of view - if they're
> directly connected they can be DoS attacked)
>
> 2) Medium to long term plan to pay for hashing power. Without scarcity
> of blockchain space there is no reason to think that transaction fees
> won't fall to the marginal cost of including a transaction, which
> doesn't leave anything to pay for proof-of-work security. A proposal
> meeting this criteria will have to be clever if you don't keep the
> blocksize sufficiently limited that transaction fees are non-negligable.
> One possible approach - if probably politically non-viable - would be to
> change the inflation schedule so that the currency is inflated
> indefinitely.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11c2489480a4c805198326ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">"<span style=3D"font-size:12.8000001907349px">Thus we=
have a fixed=C2=A0</span><span style=3D"font-size:12.8000001907349px">capa=
city system where access is mediated by supply and demand=C2=A0</span><span=
style=3D"font-size:12.8000001907349px">transaction fees."</span><div>=
<span style=3D"font-size:12.8000001907349px"><br></span></div><div><span st=
yle=3D"font-size:12.8000001907349px">There is no supply and demand. That wo=
uld mean users would be able to adapt fees and get different quality of ser=
vice depending on current capacity. For example if peak load is 10x average=
load, then at those times fees would be higher and users would delay trans=
actions to smooth out demand.</span></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Sat, Jun 27, 2015 at 7:20 PM, Peter Todd =
<span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blan=
k">pete@petertodd.org</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><span class=3D"">On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber=
wrote:<br>
> That test seems like a reasonable suggestion; 840GB is not prohibitive=
<br>
> given today's computing costs. What other than the successful resu=
lt of<br>
> that test would you want to see before agreeing to increase the block =
size<br>
> to 8MB?<br>
<br>
</span>The two main things you need to show is:<br>
<br>
1) Small, anonymous, miners remain approximately as profitable as large<br>
miners, regardless of whether they are in the world, and even when<br>
miners are under attack. Remember I'm talking about mining here, not<br=
>
just hashing - the process of selling your hashpower to someone else who<br=
>
is actually doing the mining.<br>
<br>
As for "approximately as profitable", based on a 10% profit margi=
n, a 5%<br>
profitability difference between a negligable ~0% hashing power miner<br>
and a 50% hashing power miner is a good standard here.<br>
<br>
The hard part here is basically keeping orphan rates low, as the %5<br>
profitability different on %10 profit margin implies an orphan rate of<br>
about 0.5% - roughly what we have right now if not actually a bit lower.<br=
>
That also implies blocks propagate across the network in just a few<br>
seconds in the worst case, where blocks are being generated with<br>
transactions in them that are not already in mempools - circumventing<br>
propagation optimization techniques. As we're talking about small<br>
miners, we can't assume the miners are directly conneted to each other.=
<br>
(which itself is dangerous from an attack point of view - if they're<br=
>
directly connected they can be DoS attacked)<br>
<br>
2) Medium to long term plan to pay for hashing power. Without scarcity<br>
of blockchain space there is no reason to think that transaction fees<br>
won't fall to the marginal cost of including a transaction, which<br>
doesn't leave anything to pay for proof-of-work security. A proposal<br=
>
meeting this criteria will have to be clever if you don't keep the<br>
blocksize sufficiently limited that transaction fees are non-negligable.<br=
>
One possible approach - if probably politically non-viable - would be to<br=
>
change the inflation schedule so that the currency is inflated<br>
indefinitely.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a11c2489480a4c805198326ee--
|
