Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary

["Jorge Timón" <jtimon@jtimon.cc>]

On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I would like (and have been asking) those people to take the time to quantify those costs and write up those risks in a careful way.

I agree that having a "minimal hardware requirements" specification
would greatly help with this discussions.

> I believe the costs and risks of 8MB blocks are minimal, and that the benefits of supporting more transaction FAR outweigh those costs and risks, but it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.

These tests by Rusty (strong advocate of IBLT and working on it) seem
to indicate otherwise: http://rusty.ozlabs.org/?p=509

On Thu, Jul 30, 2015 at 2:50 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think the risks of trying to make a controversial change to the network
> FAR outweighs the benefits of a small constant factor that "kicks the can
> down the road".

I think the risks of a controversial deployment in consensus rules
changes, outweigh by far potential benefits of ANY consensus forks, no
matter how amazing the potential benefits may seem. Bitcoin may not
survive a controversial hardfork or go 3 years back in adoption,
nobody knows.

> Let's scale the block size gradually over time, according to technological
> growth.

I agree. Unfortunately, technological and economic growth is very hard
to predict.


On Thu, Jul 30, 2015 at 3:33 PM, Venzen Khaosan <venzen@mail.bihthai.net> wrote:
> 2.  Bitcoin is much more than a payment network. A lot of the
> non-payment features are, arguably, what gives Bitcoin most of its
> value. Yet, the payment functionality is a major design feature and
> all agree that it should scale - subject to axiom 1.

I just explained why I disagree with this point. Bitcoin fees depend
on transaction sizes rather than amounts moved. Even ignoring
script-based signatures and all the other advantages in Bitcoin, that
fact alone makes it extremely competitive with "traditional systems"
for many use cases (say, sending 1000 usd from the US to México).
I agree overall with your other points.
Extremely cheap and instant transactions can be provided by lightning,
but cannot be provided by Bitcoin in-chain alone in the long term (it
can't even provide instant irreversible transactions).

> Since I've maintained your interest up to the final sentence, I say:
> as an insurance against a capacity crisis before layer 2 is deployed,
> why not implement bip100's 2MB blocksize proposals in a testnet?

Of all blocksize proposals, bip102 (the one with the single doubling
to 2MB) is the one I dislike less because it doesn't make any
assumptions about future technological or economic growth (I loved
your Bohr cite).
But it still has something that I dislike from all proposals: the
numbers just seem pulled out of a hat.

But I already created that testnet you propose (and
std::numeric_limits<uint64_t>::max() -1 more testnets for other sizes)
in https://github.com/bitcoin/bitcoin/pull/6382

You can run it with the following runtime options: -chain=sizetest
-blocksize=2000000

Unfortunately, nobody seems interested in running some tests for
several sizes before proposing a concrete size.
As far as I know, nobody has used that branch to test different sizes.