From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Mike Hearn Message-ID: <20131201183748.GA21280@tilt> References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--