Re: [bitcoin-dev] The need for larger blocks

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]

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.

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

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]