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 19F2F1124 for ; Wed, 23 Dec 2015 15:41:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com [62.13.149.80]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 363FA10D for ; Wed, 23 Dec 2015 15:41:52 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBNFfpPr081267 for ; Wed, 23 Dec 2015 15:41:51 GMT Received: from muck ([72.143.224.85]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBNFficL004100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 23 Dec 2015 15:41:48 GMT Date: Wed, 23 Dec 2015 07:41:43 -0800 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151223154143.GA2295@muck> References: <20151223013119.GA31113@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20151223013119.GA31113@muck> X-Server-Quench: adf6c0ef-a98b-11e5-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktfYVU6ClZ1 UkhIR0JTEQ9sABYF DlAZUAdzcwZYenx0 e05nQXVTW1t7OwIP PDgCTD56ZWdkaWAf HkNfcAoaIVcceExF PwZiBXoFM3gGZy9l WgU4Mz10ZW0GdX0K HAoEdANCV3wGTHYP TREeFjIuGwgJSjsG ZycrJUQRE08NP0l6 Llo9X18DKBIJQgRY EwlTCStYK1AdRi0t CQ5BRgYbETtcRyg0 X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 72.143.224.85/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 Subject: Re: [bitcoin-dev] Segregated witnesses and validationless mining 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: Wed, 23 Dec 2015 15:41:54 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote: > # Easy solution: previous witness data proof >=20 > To return segregated witnesses to the status quo, we need to at least > make having the previous block's witness data be a precondition to > creating a block with transactions; ideally we would make it a > precondition to making any valid block, although going this far may > receive pushback from miners who are currently using validationless > mining techniques. >=20 > We can require blocks to include the previous witness data, hashed with > a different hash function that the commitment in the previous block. > With witness data W, and H(W) the witness commitment in the previous > block, require the current block to include H'(W) >=20 > A possible concrete implementation would be to compute the hash of the > current block's coinbase txouts (unique per miner for obvious reasons!) > as well as the previous block hash. Then recompute the previous block's > witness data merkle tree (and optionally, transaction data merkle tree) > with that hash prepended to the serialized data for each witness. >=20 > This calculation can only be done by a trusted entity with access to all > witness data from the previous block, forcing miners to both publish > their witness data promptly, as well as at least obtain witness data > from other miners. (if not actually validate it!) This returns us to at > least the status quo, if not slightly better. >=20 > This solution is a soft-fork. As the calculation is only done once per > block, it is *not* a change to the PoW algorithm and is thus compatible > with existing miner/hasher setups. (modulo validationless mining > optimizations, which are no longer possible) Note that this fix can be designed to retain the possibility of validationless mining, by allowing empty blocks to be created if the previous witness data proof is omitted. This would achieve the same goal as Gregory Maxwell's blockchain verification flag(1) but with significantly less ability/reason to lie about the status of that flag. 1) [bitcoin-dev] Blockchain verification flag (BIP draft), Gregory Maxwell, Dec 4th 2015, http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011= 853.html --=20 'peter'[:-1]@petertodd.org 000000000000000002c7cfc8455339de54444ac9798cad32cbfbcda77e0f2b09 --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWesC0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMmM3Y2ZjODQ1NTMzOWRlNTQ0NDRhYzk3OThjYWQzMmNi ZmJjZGE3N2UwZjJiMDkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwLDwf/QjiP+rqg5bW4XU924RHUt7sU vl3REP5K6rVbwD07/XTPnTAZIrnGisRSsobqkVXDoeG8xchhO7pdQCsetrHNATv8 7tBV2UUncMfT3FjZwdvlYkLcuSYXIg5Sx8wVTqf2PQq5u4U11lHa9GLGGPE36ubw ZsRz2YLVmeaWDCgCE/O40dAJrajmGjhWFx+U9kOkUkZq6s21LFhmdNCcjVr5ThzU 8GPJOReX5Q0wz1lgdJ5F4Ld5nbpXIiGlkQhFRWWCuwcSLeCfMfxo4lftpvSY5qk+ 53eEB23cxPxhXEt89S6/uMaHT3I70LWYa3iRTG050N2/jy7JXGuhoXDwDq0Ulg== =ijy+ -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc--