[bitcoin-dev] The need for larger blocks

Peter Todd pete at petertodd.org
Fri Jun 26 19:36:30 UTC 2015

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

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

From my article on transaction fees during the CoinWallet.eu flood:

What needs to be done

Transaction fees aren't going away, blocksize increase or not. CoinWallet.eu 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. We've
  done a great job for Bitcoin price charts, let's extend that to transaction

* 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 protocol,
but that doesn't mean we can't give users the tools to deal with them


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/60768123/attachment.sig>

More information about the bitcoin-dev mailing list