Date: Fri, 26 Jun 2015 15:36:30 -0400
From: Peter Todd <pete@petertodd.org>
To: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <20150626193630.GB17829@muck>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
	<CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com>
	<CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com>
	<CADm_WcbQog_UCV=JPHyqTRxKbaGY7jedtHE_D8jJSe_thMg05w@mail.gmail.com>
	<CAPg+sBhrBUSfPdMjbLthLEFD17zBC3LoWf9LvZsOD1Vp0D78BQ@mail.gmail.com>
	<558DA56F.3010703@jrn.me.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9"
Content-Disposition: inline
In-Reply-To: <558DA56F.3010703@jrn.me.uk>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Precedence: list


--gj572EiMnwbLXET9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 26, 2015 at 08:18:07PM +0100, Ross Nicoll wrote:
> I'd argue that at the point where there's consistently more
> transactions than the network can handle, there are two significant
> risks. Firstly, that people don't care enough to pay the transaction
> fees required to get their transaction prioritised over another's,
> and secondly that as transactions start outright failing (which will
> happen with enough transactions backlogged) the network is
> considered unreliable, the currency illiquid, and there's a virtual
> "bank rush" to get into a more usable currency.

The supply and demand fee market means that there is a range of
reliability levels depending on what fee you pay; regardless of how high
demand is if you pay a sufficiently high fee that outbids less
important/lower fee transactions you'll get reliable transaction
confirmaiton.

The perceived lack of reliability is a function of the poor state of
wallet software, not an inherent problem with the system. Fixing that
software is much easier and much less risky than any hard-fork ever will
be.

=46rom my article on transaction fees during the CoinWallet.eu flood:

What needs to be done
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Transaction fees aren't going away, blocksize increase or not. CoinWallet.e=
u is
only spending $5k flooding the network; even an 8MB blocksize increase can =
only
raise the cost of that attack to $40k, which is still very affordable. For
instance an attacker looking to manipulate the Bitcoin price could probably
afford to spend $40k doing it with the right trading strategy; let alone
governments, banks, big businesses, criminal enterprises, etc. to whom $40k=
 is
chump-change. Wallets need to become smarter about fees, as does the rest of
the Bitcoin community.

What we need to do:

* Add fee/KB displays to block explorers.

* Change wallets to calculate and set fees in fee/KB rather than fixed fees=
 regardless of tx size.

* Make websites with easy to understand displays of what the current mempool
  backlog is, and what fee/KB is needed to get to the front of the queue. W=
e've
  done a great job for Bitcoin price charts, let's extend that to transacti=
on
  fees.

* Add the ability to set any fee/KB to wallets, rather than be stuck with
  predefined options that may not be high enough.

* Add support for fee-bumping via (FSS)-RBF to wallets and Bitcoin Core.

Capacity limits are just a fact of life in the design of the Bitcoin protoc=
ol,
but that doesn't mean we can't give users the tools to deal with them
intelligently.

-https://gist.github.com/petertodd/8e87c782bdf342ef18fb

--=20
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

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

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

iQGrBAEBCACVBQJVjam7XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMDdmYzEzY2UwMjA3MmQ5Y2IyYTZkNTFmYWU0MWZlZmNk
ZTdiM2IyODM4MDNkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwPoAf/dUbFztm/OwfokDUhxZKsKfaK
7hUfggmk7HGk45C5cWcv50U2akqH25B8NQdjSlVDyK5X7xVxop4zd3Qvh6GeKTnK
QgZg21TqMZNptxh8EhNFvWhExUjsatlaAh59ZEn+72GUdnVBbpKftuX8BJOHRKg8
KlbM4tCA+JlOFi81bGShEbhZOtGP2GBW9AJwBDDW274+qN9f11be7UX6kvN2xORB
ynN3pSMJ+B/n2bdSvSXwaiDggv3QpvsIAkvEQvAUVxEsVdcDUjLTQYnqfx/TXtD6
cqwMtxHyiLJOEILU9unmk3y8k56g+lLl8K31oTlrsdXcffS8OPK3ZXqkmFyOIg==
=nV/7
-----END PGP SIGNATURE-----

--gj572EiMnwbLXET9--