diff options
| author | Peter Todd <pete@petertodd.org> | 2013-11-07 15:31:23 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-11-07 20:32:13 +0000 |
| commit | 7361a2f7e7918b073895cf3f4533d1e169a4493e (patch) | |
| tree | d0a6543cb84a42a7f1f9feac4ea901db07cc8884 | |
| parent | 621a5a2f57a06f64677c75bd413585365a61e33d (diff) | |
| download | pi-bitcoindev-7361a2f7e7918b073895cf3f4533d1e169a4493e.tar.gz pi-bitcoindev-7361a2f7e7918b073895cf3f4533d1e169a4493e.zip | |
Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)
| -rw-r--r-- | f3/bc91fdc602211e00cb6fcd717e8c263c83327f | 245 |
1 files changed, 245 insertions, 0 deletions
diff --git a/f3/bc91fdc602211e00cb6fcd717e8c263c83327f b/f3/bc91fdc602211e00cb6fcd717e8c263c83327f new file mode 100644 index 000000000..92b7b3c8e --- /dev/null +++ b/f3/bc91fdc602211e00cb6fcd717e8c263c83327f @@ -0,0 +1,245 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pete@petertodd.org>) id 1VeWFR-0005R8-JT + for bitcoin-development@lists.sourceforge.net; + Thu, 07 Nov 2013 20:32:13 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org + designates 62.13.148.107 as permitted sender) + client-ip=62.13.148.107; envelope-from=pete@petertodd.org; + helo=outmail148107.authsmtp.com; +Received: from outmail148107.authsmtp.com ([62.13.148.107]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1VeWFP-0007Ro-OF for bitcoin-development@lists.sourceforge.net; + Thu, 07 Nov 2013 20:32:13 +0000 +Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) + by punt12.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA7KVVeS097485; + Thu, 7 Nov 2013 20:31:31 GMT +Received: from petertodd.org (petertodd.org [174.129.28.249]) + (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA7KVOx3007816 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Thu, 7 Nov 2013 20:31:26 GMT +Date: Thu, 7 Nov 2013 15:31:23 -0500 +From: Peter Todd <pete@petertodd.org> +To: Michael Gronager <gronager@ceptacle.com> +Message-ID: <20131107203123.GB3805@petertodd.org> +References: <527B9F9B.4060808@ceptacle.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" +Content-Disposition: inline +In-Reply-To: <527B9F9B.4060808@ceptacle.com> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Server-Quench: 93ce76cf-47eb-11e3-b802-002590a15da7 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aAdMdgUUFloCAgsB AmUbWVReU1x7W2Q7 ag1VcwRfa1RMVxto + VEFWR1pVCwQmQ20G fXhhGhpydwJOeXg+ Z0ZmXnMVVUcpIEF7 + ERhJEWpTN3phaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL + NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOTh0 WxAPVTI3AUwATiF7 + JRghIV1UB0cDPw07 N1dpRlIJUVcOEARY BEhGHC5eIREPSicw + RQpAUAZOWCFcRCpH SgEvJVdMBSMaGi1C TFdfQhcUAihZUS5O + U34NGjEsCVUyb14t NWwVMA5wcwAA +X-Authentic-SMTP: 61633532353630.1023:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 174.129.28.249/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: mail-archive.com] +X-Headers-End: 1VeWFP-0007Ro-OF +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] On the optimal block size and why + transaction fees are 8 times too low (or transactions 8 times too big) +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 Nov 2013 20:32:13 -0000 + + +--8GpibOaaTibBMecb +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +> Final conclusions is that the fee currently is too small and that there +> is no need to keep a maximum block size, the fork probability will +> automatically provide an incentive to not let block grows into infinity. + +Your definition of P_fork is inaccurate for a miner with non-negligable +hashing power - a miner will never fork themselves. Taking that into +account we have three outcomes: + +1) The block propagates without any other miner finding a block. +2) During propagation another miner finds a block. (tie) +2.1) You win the tie by finding another block. +2.2) You lose the tie because someone else finds a block. + +We will define t_prop as the time it takes for a block to propagate from +you to 100% of the hashing power, and as a simplifying assumption we +will assume that until t_prop has elapsed, 0% of the hashing power has +the block, and immedately after, 100% has the block. We will also define +t_int, the average interval between blocks. (600 seconds for Bitcoin) +Finally, we will define Q as the probability that you will find the next +block. + +The probabilities of the various outcomes: + +1) 1 - (t_prop/t_int * (1-Q)) +2) t_prop/t_int * (1-Q) +2.1) Q +2.2) 1-Q + +Note that to simplify the equations we have not taking into account +propagation in our calculations for outcomes 2.1 or 2.2 + +Thus we can define P_fork taking into account Q: + +P_fork(Q) =3D (t_prop/t_int * (1-Q))(1-Q) =3D t_pop/t_int * (1-Q)^2 + +Over the range 0 < Q < 0.5 the probability of a fork decreases +approximately linearly as your hashing power increases: + +d/dq P_fork(Q) =3D 2(Q-1) + +Q=3D0 -> d/dq P_fork(Q) =3D -2 +Q=3D1/2 -> d/dq P_fork(Q) =3D -1 + +With our new, more accurate, P_fork(Q) function lets re-calculate the +break-even fee/KB using your original approach: + +t_prop =3D t_0 + \alpha*S +E_fee =3D f*S + +E(Q) =3D Q*(1 - P_fork(Q))*(E_bounty + E_fee) +E(Q) =3D Q*[1 - (t_0 + k*S)/t_int * (1-Q)^2]*(E_B + f*S) + +d/dS E(Q) =3D Q*[ -2fSk/t_int*(1-Q)^2 - f*t_0/t_int*(1-Q)^2 + f - E_b*k/t_i= +nt*(1-Q)^2 ] + +Again, we want to choose the fee so that the more transactions we +include the more we earn, dE/dS > 0 We find the minimum fee to include a +transaction at all by setting S=3D0, thus we get: + +d/dS E(Q, S=3D0) =3D Q*[ f - f*t_0/t_int*(1-Q)^2 - E_b*k/t_int*(1-Q)^2 ] > 0 + +f(1 - t_0/t_int*(1-Q)^2) > E_b*k/t_int*(1-Q)^2 + +f > [E_b*k/t_int(1-Q)^2] / [1 - t_0/t_int*(1-Q)^2] + +f > [E_b*k*(1-Q)^2] / [t_int - t_0*(1-Q)^2] + +With Q=3D0: + +f > E_b*k / (t_int - t_0) ~ E_b*k/t_int + +This is the same result you derived. However lets look at Q !=3D 0: + +df/dQ =3D 2*E_b*k * [t_int*(q-1)] / [t_int - t_0(q-1)^2]^2 + +With negligible latency we get: + +df/dQ, t_0=3D0 =3D 2*E_b*k*(q-1)/t_int + +So what does that mean? Well in the region 0 < q < 1/2, df/dQ is always +negative. In other words, as you get more hashing power, the fee/KB you +can charge and still break even decreases linearly because you will +never orphan yourself. Lets trythe same assumptions as your first +analysis, based on the work by Decker et al + +Based on the work by Decker et al, lets try to calculate break-even +fee/KB for negligible, 10%, 25% and 40% hashing power: + +t_0 =3D 10s +t_int =3D 600s +k =3D 80ms/kB +E_b =3D 25BTC + +Q=3D0 -> f =3D 0.0033 BTC/kB +Q=3D0.1 -> f =3D 0.0027 BTC/kB +Q=3D0.25 -> f =3D 0.0018 BTC/kB +Q=3D0.40 -> f =3D 0.0012 BTC/kB + +Let's assume every miner is directly peered with every other miner, each +of those connections is 1MB/s, and somehow there's no latency at all: + +k =3D 1mS/kB + +Q=3D0 -> f =3D 0.000042 BTC/kB +Q=3D0.1 -> f =3D 0.000034 BTC/kB +Q=3D0.25 -> f =3D 0.000023 BTC/kB +Q=3D0.40 -> f =3D 0.000015 BTC/kB + +Regardless of how you play around with the parameters, being a larger +miner has a significant advantage because you can charge lower fees for +your transactions and therefor earn more money. But it gets even more +ugly when you take into account that maybe a guy with 0.1% hashing power +can't afford the high bandwidth, low-latency, internet connection that +the larger pool has: + +k =3D 10mS/kB, t_0=3D5s, Q=3D0.01 -> 0.000411 BTC/KB +k =3D 1mS/kB, t_0=3D1s, Q=3D0.15 -> 0.000030 BTC/KB + +So the 1% pool has an internet connection capable of 100kB/s to each +peer, taking 5s to reach all the hashing power. The 15% pool can do +1MB/s to each peer, taking 1s to reach all the hashing power. This small +different means that the 1% pool needs to charge 13.7x more per KB for +their transactions to break even! It's a disaster for decentralization. +Businesses live and die on percentage points, let alone orders of +magnitude differences in cost, and I haven't even taken into account +second-order effects like the perverse incentives to publish your blocks +to only a minority of hashing power.(1) + +This problem is inherent to the fundemental design of Bitcoin: +regardless of what the blocksize is, or how fast the network is, the +current Bitcoin consensus protocol rewards larger mining pools with +lower costs per KB to include transactions. It's a fundemental issue. An +unlimited blocksize will make the problem even worse by increasing fixed +costs, but keeping the blocksize at 1MB forever doesn't solve the +underlying problem either as the inflation subsidy becomes less +important and fees more important. + +1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms= +g03200.html + +--=20 +'peter'[:-1]@petertodd.org +00000000000000054eeccf3ac454892457bf4919d78efb275efd2ddd1a920c99 + +--8GpibOaaTibBMecb +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iQEcBAEBCAAGBQJSe/ibAAoJEBmcgzuo5/CFiLAH/Rq/O7J61kSi4WZOM30DA0EI +Hv4jhK3kkT9NGTl2MFgGLtz1eKZC37Y3TNnuVei0Q0muyb2K30fHvk9mAOBXOnbY +bSaPoiV4lG06t0HrMUcOD2ISC7VrB/Gm59ScV3eWW7qFlndkC2NeJvJUMrYg3PRN +R2XhNwTtPXKEEg0sSmoTJ3RRQ8FX3fcXrFiWrXBK2KZWJDtLcK81Ua4npuQdjaON +WI3ozXFsPK+ptDTn8bSouWPYg95FYSMLTA5xoN0tmmrdvz+DzYdhrL6Ium+VYcWS +guFMC+OOHp6nLO0KWT7LEUh0dgpRCk6e0l0syPrpUphjLJHpjKxJEkk9pWbX9Pg= +=7pgc +-----END PGP SIGNATURE----- + +--8GpibOaaTibBMecb-- + + |