Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.112 as permitted sender)
	client-ip=62.13.149.112; envelope-from=pete@petertodd.org;
	helo=outmail149112.authsmtp.co.uk; 
Date: Thu, 7 May 2015 20:05:56 -0400
From: Peter Todd <pete@petertodd.org>
To: Matt Corallo <bitcoin-list@bluematt.me>
Message-ID: <20150508000556.GA16794@savin.petertodd.org>
References: <554BE0E1.5030001@bluematt.me>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe"
Content-Disposition: inline
In-Reply-To: <554BE0E1.5030001@bluematt.me>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Precedence: list


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

On Thu, May 07, 2015 at 10:02:09PM +0000, Matt Corallo wrote:
> 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.
>=20
> 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.
>=20
>  * 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 syste=
m.

It's really important that we remember that we're building security
software: it *must* hold up well even in the face of attack. That means
we need to figure out how it can be attacked, what the cost/profits of
such attacks are, and if the holes can be patched.  Just testing the
software with simulated loads is insufficient.

Also, re: breaking, don't forget that this may not be a malicious act.
For instance, someone can send contradictory transactions to different
parts of the network simultaneously to prevent mempool consistency -
there's no easy way to fix this. There are also cases where miners have
different policy than others, e.g. version disagreements, commercial
contracts for tx mining, etc.

Finally, remember that it's not in miners' incentives in many situations
for their blocks to propagate to more than ~30% of the hashing power.(1)

Personally, I'm really skeptical that we'll ever find a block
propagation latency reduction technique that sucesfully meets all the
above criteria without changing the consensus algorithm itself.


* How do we ensure miners don't cheat and stop validating blocks fully
before building on them? This is a significant moral hazard with larger
blocks if fees don't become significant, and can lead to dangerous
forks. Also, think of the incentives: Why would a miner ever switch from
the longest chain, even if they don't actually have the blocks to back
it up?

* We need a clear understanding of how we expect new full nodes, pruned
or not, to sync up to the blockchain. Obviously 20MB blocks
significantly increases the time and data required to sync. Are we
planning on simply giving up on full validation and trusting others for
copies of UTXO sets? Are we going to rely on UTXO commitments? What
happens if the UTXO set size itself increases greatly?

>  * 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).

A good start would be for those players to commit to the general
principles of these systems; if they can't commit explain why.

For instance I'd be very interested in knowing if services like Coinbase
see legal issues with adopting technologies such as payment channels
between hosted wallet providers, payment processors, etc. I certainly
wouldn't be surprised if they see doing anythign not on-blockchain as a
source of legal uncertainty - based on discussions I've had with
regulatory types in this space it sounds like there's a reasonable
chance protocol details such as requiring that transactions happen on a
public blockchain will be "baked into" regulatory requirements.

>  * 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.

Agreed.

> 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).

FWIW I've got some funding to implement first-seen-safe replace-by-fee.

1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms=
g03200.html

--=20
'peter'[:-1]@petertodd.org
00000000000000000fe0a96ac84aeb2e4e5c246e947cd8e759bd5fb158a16caf

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

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

iQGrBAEBCACVBQJVS/3fXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMWUyNWRiMjI4ZWJhNTU0MzdjM2Y2OTJmZTA0MWFjZDQ1
YjI2M2U3OWZiNzVmZjAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsMFQgAqN4tVj3KQYFvOENngo23ahnM
rYTbA6+kzpkNdpaIkp5VJWlvWHgTlntlRBtVaUahoNoKUhHE6TLyYMMMJDpKqAsf
zeh8sSWIvoTh9NhsMY98eIg8dNiTM/h6tDtw1asQuLlLy+ealRWoEM4dkcdAmt4Z
ZFnhi5aLDt1dnX46XXLknTiekWt+W7Oi3J7TWUoy3XwEoJ+Y1c2ikJKFNxOV3Qbu
DpdUrVbRTtAHhZxTTq/Hy47w5SNEA/wcpwyDp5kIrH+8FAvUkKLo3X7K5qRe2D/i
RCqX8SOPYRgUEAPRN7UEcq2BOmtHntjmTxvpLlH0xZhE55FfxqYdHGYJQwV45w==
=z1xG
-----END PGP SIGNATURE-----

--G4iJoqBmSsgzjUCe--