path: root/73/2844b7f490f3b1fd784dbde911f3c3d6417b97

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1YqVnt-0003o5-Ot
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 00:06:09 +0000
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; 
Received: from outmail149112.authsmtp.co.uk ([62.13.149.112])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1YqVnr-0005JW-Mc for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 00:06:09 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t48060Pt038787;
	Fri, 8 May 2015 01:06:00 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4805uG2002142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 8 May 2015 01:05:59 +0100 (BST)
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)
X-Server-Quench: 020a95b4-f516-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdgoUFVQNAgsB AmMbW1VeUFt7WWM7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmRRgJ BhtbJRtydwdHfHw+ Z0dgV3EVXEZ6JE94
	EEpJQ2gHY3phaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNDo7 TBNKJjQ9EAUkQS4p
	IhU9JxYmEV8MM18/ NFYnRUlw
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YqVnr-0005JW-Mc
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 00:06:09 -0000


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