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 A2372258 for ; Tue, 28 Jun 2016 16:23:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s37.web-hosting.com (s37.web-hosting.com [198.54.114.154]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 012371EA for ; Tue, 28 Jun 2016 16:23:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xbt.hk; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=Kp8jn7FJ7VggEl2P0bWe+SBv5es3xBWpxywgrCJ6qWQ=; b=RNZMwAt4OlkWuc19+7NEB7OhoR 9/ID43z1thskQtGefwkE/7H8xUye5DjMe+Ur7pKboNLFglU9RlX41cUC/+SqpBJ9E7Iqewtl/C9mh YGTvBt2AJQDseOAa0ELSB0RJYB/yPuSEll15YSVGb8s8SGHls2HogL226n/n5HZnf/0jTjAR6bH84 wK3Rxi6H6emIIKiR9zkYxd8bogv6ptQGCVd3Wil5F1TBIPWkn7Vy2r0KkEQSl4FfAta6Gt8zaGBgg +k89txuEdr2CBcDKXnAtMG91n2cgTGHr8e4zp/liI3o7Dy/GBDAcOt+KXeslnpxGa6R7dxoIYBb5M WF33kC0w==; Received: from 119246245241.ctinets.com ([119.246.245.241]:62693 helo=[10.8.8.2]) by server37.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bHvnk-0039AP-MS for bitcoin-dev@lists.linuxfoundation.org; Tue, 28 Jun 2016 12:23:52 -0400 From: Johnson Lau X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 29 Jun 2016 00:22:45 +0800 Message-Id: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk> To: bitcoin-dev Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server37.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server37.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Authenticated-Sender: server37.web-hosting.com: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, T_DKIM_INVALID autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 16:23:54 -0000 --Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for Peter Todd=E2=80=99s detailed report: https://petertodd.org/2016/segwit-consensus-critical-code-review I have the following response. >Since the reserve value is only a single, 32-byte value, we=E2=80=99re = setting ourselves up for the same problem again7. Please note that unlimited space has been reserved after the witness = commitment: block.vtx[0].vout[o].scriptPubKey.size() >=3D 38 Which means anything after 38 bytes has no consensus meaning. Any new = consensus critical commitments/metadata could be put there. Anyway, = there is no efficient way to add a new commitment with softfork. > the fact that we do this has a rather odd result: a transaction = spending a witness output with an unknown version is valid even if the = transaction doesn=E2=80=99t have any witnesses! I don=E2=80=99t see any reason to have such check. We simply leave = unknown witness program as any-one-can-spend without looking at the = witness, as described in BIP141. > Bizzarely segwit has an additonal pay-to-witness-pubkey-hashP2WPKH = that lets you use a 160-bit (20 byte) commitment=E2=80=A6=E2=80=A6 Since ~90% of current transactions are P2PKH, we expect many people will = keep using this type of transaction in the future. P2WPKH gives the same = level of security as P2PKH, and smaller scriptPubKey. >give users the option instead to choose to accept the less secure = 160-bit commitment if their use-case doesn=E2=80=99t need the full = 256-bit security level This is actually discussed on the mailing list. P2WSH with multi-sig is = subject to birthday attack, and therefore 256-bit is used to provide = 128-bit security. P2WPKH is used as single sig and therefore 160-bit is = enough. >Secondly, if you are going to give a 160-bit commitment option, you = don=E2=80=99t need the extra level of indirection in the P2SH case: just = make the segwit redeemScript be: Something wrong here? In P2WPKH, the witness is >The only downside is the serialized witness script is constrained to = 520 bytes max 520 is the original limit. BIP141 tries to mimic the existing behaviour = as much as possible. Anyway, normally nothing in the current scripts = should use a push with more than 75 bytes >we haven=E2=80=99t explicitly ensured that signatures for the new = signature hash can=E2=80=99t be reused for the old signature hash How could that be? That=E2=80=99d be a hash collision. --Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893 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 iQGcBAEBCgAGBQJXcqSVAAoJEO6eVSA0viTS998L/jOkRYqUfR7WmSuoj3y3JQ+o +uLlAegQQVA1gLBloXh8c2PdGF9frn/FCAaiJec/rbXh2/9Pvwpq9QW2TLjGFAjT 5Ht+lTVZGdZHg9fU0jCZs53BRBO8v0v8xnUVpXovXxLiga8OHu5RxhtsGTGZLaq6 N1oNVbO9Z2yCihW+Tc8qTtHn1mjLZ0zc6IIRNbR9aCrH84euXu058HcvAHKcixGK wCZFVS3U+K2EeHSzHyNWaG2pK9egCswAUBcnq6WPUOcknlO7Y1jT8DSI5Xr76h+W baJ7XKlQ2FV6hdeP6S2XiRk3amJ+SG0HX3a/ZJYa4rNeaoC9yzIa7soXvWdC+D2P +Q3XjLKWkc8X06OwownqUDg9Yst4jNQYeDplzySKtf6pWPNHyjKKvxThtw64s3Ve Gv6bpJKRhUrolo4yIlMO1kdxGgOIkNtKQN4/0NdxWhzf9vyFI3ybqIbPGkVx7n7N B2ndc1zWjZ+5xGNu7wRbWbRMEK9dCUaXgov7+bGcnQ== =etKP -----END PGP SIGNATURE----- --Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893--