summaryrefslogtreecommitdiff
path: root/18/aa18c43dda9f9d0e20b924c5d8c06186e74118
blob: 2657aa398001e8386aa335ac000f518e90818f53 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1YqPcf-0007RS-G7
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 17:30:09 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.112 as permitted sender)
	client-ip=62.13.148.112; envelope-from=pete@petertodd.org;
	helo=outmail148112.authsmtp.co.uk; 
Received: from outmail148112.authsmtp.co.uk ([62.13.148.112])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1YqPcd-0000wX-8h for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 17:30:09 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t47HU0K4077537;
	Thu, 7 May 2015 18:30:00 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t47HTuHI004317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 7 May 2015 18:29:59 +0100 (BST)
Date: Thu, 7 May 2015 13:29:56 -0400
From: Peter Todd <pete@petertodd.org>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@jtimon.cc>
Message-ID: <20150507172956.GB6033@savin.petertodd.org>
References: <CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
	<CAPWm=eUFe7dKJCLeNACZ4n9vw0Xj9rHVM_RRLSczGXNU-ShR2w@mail.gmail.com>
	<CANEZrP1tCda9EbYgYu5QHN8ZgBCtGP7zRiDaXnq-rWU0ZHR9NQ@mail.gmail.com>
	<CAJHLa0Nrp4QEQqrBu6Tb+dohxX2VhWKMnO40xscZF1OJdfPF-A@mail.gmail.com>
	<CANEZrP0bmh5braGO5OKTNJU9VC_9=_1RDqHMx=aJBxT1w-q8oA@mail.gmail.com>
	<CABm2gDozyxovazcNEjWsRK0KzNJotWTg9X4m3aOfx7Gr_KprxQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8"
Content-Disposition: inline
In-Reply-To: <CABm2gDozyxovazcNEjWsRK0KzNJotWTg9X4m3aOfx7Gr_KprxQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: afedb3a7-f4de-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdgUUFVQNAgsB AmMbWlxeUlR7XGo7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmRRgG fnpbKmBydwFFeXk+ ZEBmX3YVDRIvIRR+
	E0lJQ2lSMHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNDo7 TBNKJjQ9EAUkQS4p IhU9JzYB
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1YqPcd-0000wX-8h
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 17:30:09 -0000


--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Tim=F3n wrote:
> On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen <gavinandresen@gmail.com> =
wrote:
> > I would very much like to find some concrete course of action that we c=
an
> > come to consensus on. Some compromise so we can tell entrepreneurs "THI=
S is
> > how much transaction volume the main Bitcoin blockchain will be able to
> > support over the next eleven years."
>=20
> Mhmm, I hadn't thought about this. This makes sense and actually
> explains the urgency on taking a decision better than anything else
> I've heard.

I've spent a lot of time talking to companies about this, and the
problem is telling them that isn't actually very useful; knowing the
supply side of the equation isn't all that useful if you don't know the
demand side. Problem is we don't really have a good handle on what
Bitcoin will be used for in the future, or even for that matter, what
it's actually being used for right now.

As we saw with Satoshidice before and quite possibly will see with smart
contracts (escrows, futures, etc) it's easy for a relatively small
number of use cases to drive a significant amount of transaction volume.
Yet, as Wladimir and others point out, the fundemental underlying
architecture of the blockchain has inherently poor O(n^2) scaling, so
there's always some level of demand where it breaks, and/or incentivizes
actors in the space to push up against "safety stops" like soft
blocksize limits and get them removed.

Note how the response previously to bumping up against soft policy
limits was highly public calls(1) at the first hint of touble: "Mike
Hearn: Soft block size limit reached, action required by YOU"

1) https://bitcointalk.org/index.php?topic=3D149668.0

--=20
'peter'[:-1]@petertodd.org
000000000000000002761482983864328320badf24d137101fab9a5861a59d30

--z6Eq5LdranGa6ru8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVS6EQXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMjMyMTY0Yzk2ZWFhNmJmN2NiYzNkYzYxZWEwNTU4NDA3
MTViNWE4MWVlOGY2YmUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft81QgAmhNqMZjN1OccAUqhH4fCqOF4
sZsUVoukcbETUw3ZyMPFcxqAxDKTUWrXQI2jqb/AXx8t3jJpnNtpunHhVNHXoAhG
MMovBxUlpgRKuXMijKs3R/Vc+HoYDehph42482902jxlQ48eF28UlAxChMbSfnzZ
FUAbSfbjzBFvubp+g5EociohAWiH77btraHW+eG/HTUphj6Vc5rll0Igc57tfDbr
n22rHOo3/6uV9J+8kllzOzejdPbaOL2oSEvZS4cVRZy3b57ydq0sWJAuIvh2fOLx
HCl+TVlwa+xAl5u2WyGlEuljSXELFj+cJ2RsCZIsuW/mBc1wToiczVujzwyJ/g==
=CaDS
-----END PGP SIGNATURE-----

--z6Eq5LdranGa6ru8--