From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E29CC268 for ; Tue, 21 Jul 2015 13:04:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148101.authsmtp.com (outmail148101.authsmtp.com [62.13.148.101]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id CFB418B for ; Tue, 21 Jul 2015 13:04:22 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6LD4H3M043744; Tue, 21 Jul 2015 14:04:17 +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 t6LD4DhI048012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jul 2015 14:04:15 +0100 (BST) Date: Tue, 21 Jul 2015 09:04:12 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20150721130412.GA4551@savin.petertodd.org> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: fdc1675e-2fa8-11e5-b397-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAMUEkAYAgsB AmMbWlBeUFl7WGU7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRp9 chpqCmBycw1GeXw+ ZEJgWHAVChApdEB6 RxtJFztXbXphaTUa TRJbfgRJcANIexZF O1F6ACIKLwdSbGoL FQ4vNDcwO3BTJTpg CissFRpLGRxDW3Y/ RhsBVSkvEAUOTiN7 Ixs5LBYAHEtZKEI7 PRM9XhpCFjV6 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-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 13:04:24 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Tim=F3n via bitcoin-dev wro= te: > I still disagree. Using height instead of time may make the > implementation more complex by requiring some additional preparations > but using height is in fact a simpler design. Why relay on clocks that > we know will differ in different computers and places when we have a > universal tick with every block? The Bitcoin protocol fundementally uses time in a consensus-critical manner anyway; miners vote on what time it is via the median time mechanism. Triggering events based on median time is compatable with consensus and gives more human scale predictability as to when events may happen. In addition the median time is guaranteed to be monotonic by the consensus rules. See the version bits proposal for an example of its use: https://gist.github.com/sipa/bf69659f43e763540550#Specification Having said that, in general triggering events without verifying a supermajority of miner support can be very dangerous. Without miner support the chain is insecure, and can be attacked. For instance a blocksize limit increase that a majority of miners choose not to implement raises huge risks of reorg for any miners who attempt to create large blocks, and huge risks of payment reversal for any merchants accepting transactions in such blocks. Note how with BIP102, extending the original Bitcoin chain is inherently an attack on the Garzik chain. For that reason I think BIP102 is extremely poorly designed. I can only conclude that Jeff Garzik is either deliberately trolling us and/or manipulating discussion with a badly designed proposal that he doesn't actually expect to be adopted verbatim, or is incompetent. --=20 'peter'[:-1]@petertodd.org 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1 --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVrkNIXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMTZmNzNkMTE1OWIwYTcwNTJiNDljZjNjYjgyOWZmYTRh NDdiZTM4NjhkYjZiMjkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftPfAf/dDREDW+AFkXfHhtfJeAfWngl oJwCAEmxCAewnv7tR8xOrTo5hXde2Z79Q7P48rNq+5mpWrrX+e4n3ji22nJJUXgn oXdjMS/uEugfNczqAmyA+5iU6UwDnVTPVoYH/HQleQiA9WklklwVg/fajQwq8xnr adLrpIr22ErUQjrDb+rvmg3uSEmnsH54P+SIYcV4kxF3mfte+HVs9we7d8p3J3HR lptpIJzPmKL0O+ak0wKcAkEgkdHtPHLRJnDglKlctDHE5w81iY+CbUch3qTErVZY wq+BevuGcYi5HhSa0qD0mdthf53Qng4UJ93/YDLiPPd1DIoBsShU9Kakgb2SGw== =g6Aw -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--