Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6B37FE29 for ; Fri, 1 Jun 2018 18:15:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A7560CF for ; Fri, 1 Jun 2018 18:15:53 +0000 (UTC) Received: by mail-io0-f178.google.com with SMTP id d185-v6so2729173ioe.0 for ; Fri, 01 Jun 2018 11:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FxEx4eEPAaOj/Gd9PQ607gDsFB6KWlWzfV2e/pt44f4=; b=b6+pt4lxLQQSVIL7eC06+3fON/657JqYoeRHUMLc9/c3X4Gf/cLQ/LataQ7ufSJLrw OwXUAxJ4DPd6YFZ6CcCu+grnFwL4mevJU1UpPCco72GRXu8BNoCWTQMIUI/YDViSNQkw JbWiIUXjX+5hT8ukceCx603dq+UuHOo/Y/0BM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FxEx4eEPAaOj/Gd9PQ607gDsFB6KWlWzfV2e/pt44f4=; b=RAA5aEdbWJtOk6i1iBtP8ubA2jbaMs/J874YdP+INguVQy9oNEZJgOV+oQ6PR0/DQp +05BZXI9cXNgKOOIAI1qfa6XpEFZIIgliEZ5bvCOnH9JcT0IL516LoBz3fky8kbfeRWO BOvb5AZPtlmAwKHP92r7W0yWKDKIwlR+YSBF69ccOB2Q2Z43k+hH7bMM3IP29DNQExeh SI0aJWH5nPI5DuqYtxUgeOpHsv0djIqv+Azygn2pRpLi7N9wHJVxFinVrg5MkB3+lJxe LBlbO7Xt19YaRkdGgi5OX836JDhk21SZWPMP/TFhcQ5tQkeCEs/RBeeTZp/wyRu7okxZ Mh2g== X-Gm-Message-State: APt69E3Uloercz4nd1uHERr5T5rvGJ3Vt7BtzHU7odNtpvqw4loFJiFz 2ytckMFZG4/Yc+EM7Rjc7/U5jP//YgrsZJORtRLvZl/ZlVg= X-Google-Smtp-Source: ADUXVKLxK9fLB7Kz6AlAH/QszptWcPsFWxmj2U2cWSYgOkP9x6jAZREbwz8rQ+NVGD5STAEJ0DKzehWMU8U66R3Et5I= X-Received: by 2002:a6b:978e:: with SMTP id z136-v6mr12326191iod.60.1527876952615; Fri, 01 Jun 2018 11:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:1253:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 11:15:32 -0700 (PDT) In-Reply-To: References: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk> From: "Russell O'Connor" Date: Fri, 1 Jun 2018 14:15:32 -0400 Message-ID: To: Johnson Lau Content-Type: multipart/alternative; boundary="0000000000000589c8056d9893c8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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 Subject: Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme 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: Fri, 01 Jun 2018 18:15:54 -0000 --0000000000000589c8056d9893c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 1, 2018 at 1:03 PM, Johnson Lau wrote: > On 1 Jun 2018, at 11:03 PM, Russell O'Connor > wrote: > On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> Double SHA256 of the serialization of: >> > > Should we replace the Double SHA256 with a Single SHA256? There is no > possible length extension attack here. Or are we speculating that there = is > a robustness of Double SHA256 in the presence of SHA256 breaking? > > I suggest putting `sigversion` at the beginning instead of the end of the > format. Because its value is constant, the beginning of the SHA-256 > computation could be pre-computed in advance. Furthermore, if we make th= e > `sigversion` exactly 64-bytes long then the entire first block of the > SHA-256 compression function could be pre-computed. > > Can we add CHECKSIGFROMSTACK or do you think that would go into a separat= e > BIP? > > > I think it=E2=80=99s just a tradition to use double SHA256. One reason we= might > want to keep dSHA256 is a blind signature might be done by giving only th= e > single SHA256 hash to the signer. At the same time, a non-Bitcoin signatu= re > scheme might use SHA512-SHA256. So a blind signer could distinguish the > message type without learning the message. > > sigversion is a response to Peter Todd=E2=80=99s comments on BIP143: > https://petertodd.org/2016/segwit-consensus-critical-code-review#bip143- > transaction-signature-verification > > I make it a 0x01000000 at the end of the message because the last 4 bytes > has been the nHashType in the legacy/BIP143 protocol. Since the maximum > legacy nHashType is 0xff, no collision could ever occur. > > Putting a 64-byte constant at the beginning should also work, since a > collision means SHA256 is no longer preimage resistance. I don=E2=80=99t = know much > about SHA256 optimisation. How good it is as we put a 64-byte constant at > the beginning, while we also make the message 64-byte longer? > In theory, having a fixed 64 byte constant at the beginning results in zero overhead for those 64 bytes. An implementation would just start the usual SHA-256 algorithm with a different pre-computed and fixed initial value than SHA-256's standard initial value. The SHA-256 padding counter would also need to start at 64*8 bits rather than starting at 0 bits. In practice, assuming a OpenSSL-like implementation of SHA-256, it should be easy to implement this optimization. One would replace SHA256_Init call with a variant that initializes the SHA256_CTX to this pre-computed value and sets SHA256_CTX's num counter to the appropriate value. Non-optimized implementations can still just add the 64 byte prefix and use any SHA-256 implementation. For CHECKSIGFROMSTACK (CSFS), I think the question is whether we want to > make it as a separate opcode, or combine that with CHECKSIG. If it is a > separate opcode, I think it should be a separate BIP. If it is combined > with CHECKSIG, we could do something like this: If the bit 10 of SIGHASH2 > is set, CHECKSIG will pop one more item from stack, and serialize its > content with the transaction digest. Any thought? > I prefer a different opcode for CHECKSIGFROMSTACK because I dislike opcodes that pop a non-static number of elements off the stack. Popping a dynamic number of stack elements makes it more difficult to validate that a Script pubkey doesn't allow any funny business. --0000000000000589c8056d9893c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 1, 2018 at 1:03 PM, Johnson Lau <jl2012@xbt.hk> wrote:
On 1 Jun 2018, at 11:03 PM, Russell O'Co= nnor <rocon= nor@blockstream.io> wrote:
On Thu, May= 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:

=C2=A0 Double SHA256 of the serialization of:

Should we replace the Double SHA256 with a Single SHA256?=C2=A0 Ther= e is no possible length extension attack here.=C2=A0 Or are we speculating = that there is a robustness of Double SHA256 in the presence of SHA256 break= ing?

I suggest putting `sigversion` at the beginning inst= ead of the end of the format.=C2=A0 Because its value is constant, the begi= nning of the SHA-256 computation could be pre-computed in advance.=C2=A0 Fu= rthermore, if we make the `sigversion` exactly 64-bytes long then the entir= e first block of the SHA-256 compression function could be pre-computed.

Can we add CHECKSIGFROMSTACK or do you think tha= t would go into a separate BIP?

I think it=E2=80=99s just a t= radition to use double SHA256. One reason we might want to keep dSHA256 is = a blind signature might be done by giving only the single SHA256 hash to th= e signer. At the same time, a non-Bitcoin signature scheme might use SHA512= -SHA256. So a blind signer could distinguish the message type without learn= ing the message.

sigversion is a response to Peter= Todd=E2=80=99s comments on BIP143:=C2=A0https://petertodd.org/2016/segwit-consensu= s-critical-code-review#bip143-transaction-signature-verifica= tion

I make it a 0x01000000 at the end of the = message because the last 4 bytes has been the nHashType in the legacy/BIP14= 3 protocol. Since the maximum legacy nHashType is 0xff, no collision could = ever occur.

Putting a 64-byte constant at the begi= nning should also work, since a collision means SHA256 is no longer preimag= e resistance. I don=E2=80=99t know much about SHA256 optimisation. How good= it is as we put a 64-byte constant at the beginning, while we also make th= e message 64-byte longer?

In th= eory, having a fixed 64 byte constant at the beginning results in zero over= head for those 64 bytes.=C2=A0 An implementation would just start the usual= SHA-256 algorithm with a different pre-computed and fixed initial value th= an SHA-256's standard initial value.=C2=A0 The SHA-256 padding counter = would also need to start at 64*8 bits rather than starting at 0 bits.=C2=A0= In practice, assuming a OpenSSL-like implementation of SHA-256, it should = be easy to implement this optimization. One would replace SHA256_Init call = with a variant that initializes the SHA256_CTX to this pre-computed value a= nd sets SHA256_CTX's num counter to the appropriate value.=C2=A0 Non-op= timized implementations can still just add the 64 byte prefix and use any S= HA-256 implementation.

For CH= ECKSIGFROMSTACK (CSFS), I think the question is whether we want to make it = as a separate opcode, or combine that with CHECKSIG. If it is a separate op= code, I think it should be a separate BIP. If it is combined with CHECKSIG,= we could do something like this: If the bit 10 of SIGHASH2 is set, CHECKSI= G will pop one more item from stack, and serialize its content with the tra= nsaction digest. Any thought?

I= prefer a different opcode for CHECKSIGFROMSTACK because I dislike opcodes = that pop a non-static number of elements off the stack.=C2=A0 Popping a dyn= amic number of stack elements makes it more difficult to validate that a Sc= ript pubkey doesn't allow any funny business.
--0000000000000589c8056d9893c8--