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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 902EEACB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:20:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148114.authsmtp.net (outmail148114.authsmtp.net
[62.13.148.114])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C709217A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:20:16 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5RHKEFS090368;
Sat, 27 Jun 2015 18:20:14 +0100 (BST)
Received: from muck (cpe-74-66-142-58.nyc.res.rr.com [74.66.142.58])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5RHKCIj096067
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sat, 27 Jun 2015 18:20:14 +0100 (BST)
Date: Sat, 27 Jun 2015 13:20:11 -0400
From: Peter Todd <pete@petertodd.org>
To: Michael Naber <mickeybob@gmail.com>
Message-ID: <20150627172011.GB18729@muck>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
<1EF70EBC-8BB8-4A93-8591-52B2B0335F6C@petertodd.org>
<CALgxB7usetoaNCObhG36TrdYgKuP4TSPPNkGatvim1oWUMxaeQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
In-Reply-To: <CALgxB7usetoaNCObhG36TrdYgKuP4TSPPNkGatvim1oWUMxaeQ@mail.gmail.com>
X-Server-Quench: c6049de4-1cf0-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAUUEkAaAgsB AmMbWlxeUl17WGc7 bA5PawNDY05MQQBi
T01BRU1TWkFtY2R6 dWdEUhB0dwNBNn9x YEdlECNdXEBzIRN5
X08HQ20bZGY1bX1N U0leagNUcgZDfk5E bwQuUz1vNG8XDSg5
AwQ0PjZ0MThBHWx8 CjkXKkoVWksHVhU7 QggYGjAuBkBNWyJ7
MxwrYnQYG00Sen4z I1ZpfVMdMgN6
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 74.66.142.58/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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:20:17 -0000
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
--=20
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
--wac7ysb48OaltWcw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVjttIXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMDdmYzEzY2UwMjA3MmQ5Y2IyYTZkNTFmYWU0MWZlZmNk
ZTdiM2IyODM4MDNkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxzVwgAiXBxl6bWS4pmRa/6JGG8ang8
ACT0p+IhjRzxRJ+FJrktnFYrDPLRFnFvTS6G7HZS+T2/tgABqLR8jtLRFyYx0GlT
NsBVOBE4prf1yxlXGDOpP6mPfDmGVwbHEb5SPzEFDVp43SQgdlDXbA+tkNEmNgyY
SVAhbKPSeXKl8yskKfOWj5V3GagowYov46apcL6nBbDmK+TFHHBssEORH/41nzaP
vVVVXk8xEHusoGOnuzoGf6D3/QjpgO5tvblCRGt47SNp0vxUF15NArJmvCfW7xWd
NS9lw4SGMqBp1xtzBkEr6IY1QI9kKp0iXnyn8o9N4E3uhVHzdj5WL5BNVWg+tg==
=CTZB
-----END PGP SIGNATURE-----
--wac7ysb48OaltWcw--
|
