Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0D12EA18 for ; Tue, 8 Dec 2015 12:59:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F1B5E5 for ; Tue, 8 Dec 2015 12:59:58 +0000 (UTC) Received: from [10.47.3.193] ([202.83.241.113]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tB8Cxqtx014915 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 8 Dec 2015 04:59:55 -0800 From: Jonathan Toomim X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_C88664F0-95F2-4535-B5EE-2E0FCD98D526"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 8 Dec 2015 20:59:51 +0800 Message-Id: <763601A1-03DE-4B7F-A032-C52E0B6C5AA3@toom.im> To: Bitcoin Dev Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Sonic-CAuth: UmFuZG9tSVZoZakeFQxe1D5nj8o+5G0uEJnTsXo3A19oYbfq44uKw9P03LZVj95nB0bLNLJCrYB9vopjj250imK4o+hItIec X-Sonic-ID: C;Dlhjkqud5RGdoMgxU3XIUw== M;1BHYk6ud5RGdoMgxU3XIUw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Can kick 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, 08 Dec 2015 12:59:59 -0000 --Apple-Mail=_C88664F0-95F2-4535-B5EE-2E0FCD98D526 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am leaning towards supporting a can kick proposal. Features I think = are desirable for this can kick: 0. Block size limit around 2 to 4 MB. Maybe 3 MB? Based on my testnet = data, I think 3 MB should be pretty safe. 1. Hard fork with a consensus mechanisms similar to BIP101 2. Approximately 1 or 2 month delay before activation to allow for = miners to upgrade their infrastructure. 3. Some form of validation cost metric. BIP101's validation cost metric = would be the minimum strictness that I would support, but it would be = nice if there were a good UTXO growth metric too. (I do not know enough = about the different options to evaluate them right now.) I will be working on a few improvements to block propagation (especially = from China) over the next few months, like blocktorrent and = stratum-based GFW penetration. I hope to have these working within a few = months. Depending on how those efforts and others (e.g. IBLTs) go, we = can look at increasing the block size further, and possibly enacting a = long-term scaling roadmap like BIP101. --Apple-Mail=_C88664F0-95F2-4535-B5EE-2E0FCD98D526 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWZtRHAAoJEIEuMk4MG0P1lDoH/iALXkZkbQZfch/ssKqibbOs DhTJN6hKvZA3VTLW6JCBK35IxPNEAln3smnvkwPIN0Ql3peZs+vafb+CVTjFfM8R vTpiqd3mZrgFNul9l0w1JMhhwOuO5jbWFTPcPhQ1CHgPdqnblbj5SbI/240akGBF LmLbTogbh0Ypen2nq0pyZakN0ddu789ujSZAT2fOy5tDQz9DSgT2fg5NNmFPoctV Ci1kBP/v+bFMkNZSDCEsqwSkyLg+hMIDMZ8jgeG75xuAS7efJJgX/2hWNZGRDDwJ KCHAHN0s+l8+DkvkBqxAi4jEYpvMQLRJr8Z47C9luwXB9tMGm1lC0melX+u5Zbg= =3ivj -----END PGP SIGNATURE----- --Apple-Mail=_C88664F0-95F2-4535-B5EE-2E0FCD98D526--