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 202D992 for ; Sat, 2 Jul 2016 19:28:00 +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 85101171 for ; Sat, 2 Jul 2016 19:27:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xbt.hk; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type: Mime-Version:Subject; bh=vPQpPyExsGEE1Ojtt0+zDnWfNT9jVj6O/jMavxdbgTE=; b=kHsd R6aagbTvvsXJOqxvPc5SxE7TJurU/2ePkj2ZeCcKCmWsu4BVv67fjfCqbl2Yoe+EdhKGtU/GSlXg0 ITOOVbIF3eTbgGfCLfDHbu5QA1V1H8b/q7q9IR6dbQClPJTIj9+g+h6ixdh58rtS1VwWzMeXTREqv MmvuVWTgs4t2UhcXUm37y0j1x/twFUyGnXeLnZ/V/opNnFqhDhO6sTsByat8nhsUWdwUW8ZwvBuce DUOmt1b5tRWMFhbyqmNbcMmiQls6UQNWsQC6v0knvbhDhbQ5lJH5EkN/QMC5ZoD8eKHgPp1D1S+mO SRdjo3pZ/rxBEGuwHL70UX5XKlC5Ow==; Received: from 119246245241.ctinets.com ([119.246.245.241]:58724 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 1bJQa5-003J1U-UD; Sat, 02 Jul 2016 15:27:58 -0400 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Johnson Lau In-Reply-To: <20160702184350.GA16656@fedora-21-dvm> Date: Sun, 3 Jul 2016 03:20:42 +0800 Message-Id: <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk> References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk> <20160702184350.GA16656@fedora-21-dvm> To: Peter Todd 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 Cc: bitcoin-dev 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: Sat, 02 Jul 2016 19:28:00 -0000 --Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 >>> 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! >>=20 >> 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. >=20 > It will lead to a special case in code that does things with witness > transactions, as we can spend a witness output without a witness. It is trivial to softfork a new rule to require the witness must not be = empty for a witness output. However, does it really make the code = simpler? >=20 > Thus you could summarize the argument for the P2PKH special case as = "We don't > want to make it possible to use 160-bit commitments for multisig, = which _might_ > need 256-bit security. But we do want to special-case pubkeys to save = a few > bytes.=E2=80=9D Actually I would like to see even shorter hash and pubkey to be used. = Storing 1 BTC for a few months does not really require the security = level of P2PKH. >=20 >>> 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 >>=20 >> How could that be? That=E2=80=99d be a hash collision. >=20 > Nope. The problem is it might not be a hash collission, if the actual = bytes > signed can be interpreted in two different ways, by different types of > signature hashes. >=20 > This is the same reason the signmessage functionality prepends the = message > being signed with the "Bitcoin Signed Message:\n" magic string. >=20 In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes = (hashPrevouts) is a hash of all prevouts. (in the case of ANYONECANPAY, = the bytes following would be zero, as you proposed) In the original sig, first 4 bytes in nVersion, next 4 bytes is number = of inputs, and the next 32 bytes is a txid. For a signature to be valid for both schemes, the last 28 bytes of the = hashPrevouts must also be the first 28 bytes of a valid txid. This is = already impossible. And this is just one of the many collisions = required. In such case SHA256 would be insecure and adding a zero after = the nVersion as you suggest would not be helpful at all. --Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8 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 iQGcBAEBCgAGBQJXeBW6AAoJEO6eVSA0viTSoeoL/1xRq3zPc4Q9HMKwNNH/apAw zdxIgmNTCMrX30DYg2Bs0xjBYRmuRegj6vGMHHXHNW1n5PLhR5ejY0jbUJOUAXww M9zu6f7Hm3PTBkIL6U4kPk1090Y0ce6rGDY9DzSfmXwfyl90bbNDyCfHAVPZc2b5 oQM9qPiyj/X86od6EAa3fKp2/yWwpt553MoOlhxKi+m05zkMCUeyya7QYOsApz84 nZWerSXrZokqzOppOknVp8MVbDCHrVAyr++iQIAA02tHRTF01CFM3JvzdUFOUqmL kZdG65UiauUhJo6/O/Njv2/D9Le2nrGlPULY2lesuO4a0JkvvgijgJkTUyUKnLmS 5VCWhYDNX0kmdL5lTIg1mLdZZQIVZ0GLzN3J0J9ua+K63BPafAeJap7SAUPty1+F PTDXQphkRYCY1hve0iz5lMRnkFXvBVhPdwMLpDE489Nb/TYp5dm7Qls+SKcy6ils +o4x3b9ps2f5isF4iJy9sWsyQQCRlDaGK6tJ9e2qZA== =gGIw -----END PGP SIGNATURE----- --Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8--