From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Matt Corallo 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--