Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 192.241.179.72 as permitted sender)
	client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
	helo=mail.bluematt.me; 
Message-ID: <554BE0E1.5030001@bluematt.me>
Date: Thu, 07 May 2015 22:02:09 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: [Bitcoin-development] Block Size Increase Requirements
Precedence: list

OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
with committing to this right now, but think we should eventually", but
not much "I'd be comfortable with committing to this when I see X". In
the interest of ignoring debate and pushing people towards a consensus
at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
second.

Personally, there are several things that worry me significantly about
committing to a blocksize increase, which I'd like to see resolved
before I'd consider supporting a blocksize increase commitment.

 * Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today. I'd expect to see these not only implemented but
being used in production (though I dont particularly care about them
being all that stable). I'd want to see measurements of how they perform
both in production and in the face of high packet loss (eg across the
GFW or in the case of small/moderate DoS). In addition, I'd expect to
see analysis of how these systems perform in the worst-case, not just
packet-loss-wise, but in the face of miners attempting to break the system.

 * I'd very much like to see someone working on better scaling
technology, both in terms of development and in terms of getting
traction in the marketplace. I know StrawPay is working on development,
though its not obvious to me how far they are from their website, but I
dont know of any commitments by large players (either SPV wallets,
centralized wallet services, payment processors, or any others) to
support such a system (to be fair, its probably too early for such
players to commit to anything, since anything doesnt exist in public).

 * I'd like to see some better conclusions to the discussion around
long-term incentives within the system. If we're just building Bitcoin
to work in five years, great, but if we want it all to keep working as
subsidy drops significantly, I'd like a better answer than "we'll deal
with it when we get there" or "it will happen, all the predictions based
on people's behavior today say so" (which are hopefully invalid thanks
to the previous point). Ideally, I'd love to see some real free pressure
already on the network starting to develop when we commit to hardforking
in a year. Not just full blocks with some fees because wallets are
including far greater fees than they really need to, but software which
properly handles fees across the ecosystem, smart fee increases when
transactions arent confirming (eg replace-by-fee, which could be limited
to increase-in-fees-only for those worried about double-spends).

I probably forgot one or two and certainly dont want to back myself into
a corner on committing to something here, but those are a few things I
see today as big blockers on larger blocks.

Luckily, people have been making progress on building the software
needed in all of the above for a while now, but I think they're all
very, very immature today.

On 05/07/15 19:13, Jeff Garzik wrote:> On Thu, May 7, 2015 at 3:03 PM,
Matt Corallo <bitcoin-list@bluematt.me
> <mailto:bitcoin-list@bluematt.me>> wrote:
-snip-
>> If, instead, there had been an intro on the list as "I think we should
>> do the blocksize increase soon, what do people think?", the response
>> could likely have focused much more around creating a specific list of
>> things we should do before we (the technical community) think we are
>> prepared for a blocksize increase.
>
> Agreed, but that is water under the bridge at this point.  You - rightly
> - opened the topic here and now we're discussing it.
>
> Mike and Gavin are due the benefit of doubt because making a change to a
> leaderless automaton powered by leaderless open source software is
> breaking new ground.  I don't focus so much on how we got to this point,
> but rather, where we go from here.