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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VnBu5-0002RB-Hf
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Dec 2013 18:38:01 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.80 as permitted sender)
client-ip=62.13.149.80; envelope-from=pete@petertodd.org;
helo=outmail149080.authsmtp.com;
Received: from outmail149080.authsmtp.com ([62.13.149.80])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VnBu4-0001a7-Cu for bitcoin-development@lists.sourceforge.net;
Sun, 01 Dec 2013 18:38:01 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt10.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB1IbrRH051650;
Sun, 1 Dec 2013 18:37:53 GMT
Received: from tilt (ppp-82-84-150-184.cust-adsl.tiscali.it [82.84.150.184]
(may be forged)) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB1Ibn7D039908
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 1 Dec 2013 18:37:51 GMT
Date: Sun, 1 Dec 2013 13:37:49 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131201183748.GA21280@tilt>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
<l7f97u$jdg$1@ger.gmane.org>
<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
<l7fpbn$hf6$1@ger.gmane.org>
<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
<20131201181211.GA20533@tilt>
<31CF9128-4BFA-48E6-9B68-9732E914E6D0@plan99.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <31CF9128-4BFA-48E6-9B68-9732E914E6D0@plan99.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: af60f270-5ab7-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgMUHFAXAgsB AmUbWlxeU1p7XGI7 YwhPZQFDY09OQQRi
VFdMSlVNFUsqcx14 VEAZJhlxfgxGcDBx YURqWj4KCkJ6I0R6
QlNRRD8BeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4lGjk1 WxEEEn0hEEAeDyw1
I1QdEmBUF0IQP0Mu KjMA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 82.84.150.184/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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
X-Headers-End: 1VnBu4-0001a7-Cu
Cc: bitcoin-development@lists.sourceforge.net,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
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: Sun, 01 Dec 2013 18:38:01 -0000
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 01, 2013 at 07:18:07PM +0100, Mike Hearn wrote:
> > Bitcoin is and always will be limited in capacity - transactions may not
> > confirm in a reasonable about of time because of high-demand and/or DoS
> > attacks.
>=20
> I agree in the general case, but I was talking about the mobile wallet ca=
se specifically (i.e. people who are sending money between themselves or ma=
king small purchases of physical things). I think Bitcoin should be able to=
scale to handle these sorts of ordinary every-day transactions. Where I=E2=
=80=99d expect to see transactions falling off the edge is in more speciali=
sed cases like very small single micropayments, or =E2=80=9Coptional=E2=80=
=9D internal transactions like mixing/re/defragmentation of wallets that do=
n=E2=80=99t correspond to an actual payment. Those sorts of transactions wo=
uld I guess be the first to go when faced with a sudden capacity crunch, bu=
t they wouldn=E2=80=99t show up in a mobile wallet UI anyway.
Maybe, maybe not. We have no idea what fees will be because the system's
entire capacity is, and always will be, limited. That's just how
fundementally unscalable systems with huge global state work. What
demand will be for that limited capacity is unknown.
> > re: merchants paying tx fees, child-pays-for-parent is inefficient
>=20
> I know the existing code is, but is that fundamentally the case or just h=
ow the code has been written? I haven=E2=80=99t looked at this issue much b=
ut I know you=E2=80=99ve worked on it, so I=E2=80=99m curious to learn abou=
t why it=E2=80=99s inefficient and whether there are any fixes possible.=09
No, Luke's existing code uses good algorithms with O(n) scaling for n
transactions. The inefficiency is needing a second transaction, bloating
the blockchain and driving up fees.
--=20
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJSm4H8AAoJECSBQD2l8JH7Es0H+wdsrI9A3QZYYdw6EdKFMGLI
bbul2Npa1eT2Wtyr0iS2uXQJZ9/c9JtLRUwSViC/0zZ44KKZLvC3ITc4D+EWNzRF
A+UEdyiUwX6H/KGlIh6Ep3wRVsNH5wnsuX9KXa5enFXHRaxWiMaWPw1QIDHF4RgV
LmZmW47BNW9T8CtLsKiNgZCr0x+VuaIutCsrvbuP1ee9uyjboBlQr9/tNJUoOWfe
yUCFR3VF7soParLZHPVfYtbwyRHq9f1nx0CvVFqYd19SEPcxtTgvWG0BY9NJC5jz
jRYc2+nWKyy77j4IRRpQHvkNwwdyTyhZTjR/QpMu2dfj8syit5HnojO1Z5OAfKY=
=DicT
-----END PGP SIGNATURE-----
--W/nzBZO5zC0uMSeA--
|
