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; 
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)
Cc: bitcoin-development@lists.sourceforge.net,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list


--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--