diff options
| author | Russell O'Connor <roconnor@blockstream.io> | 2018-06-01 14:15:32 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-06-01 18:15:54 +0000 |
| commit | 9fe7ca245dfb831cd0cd3e6403384cd3b7d1197f (patch) | |
| tree | b282524eb7a8a040b20ed471c69c7ebba5b7da83 | |
| parent | 9773474b8bc709e43b8f3164c1ed23903478c963 (diff) | |
| download | pi-bitcoindev-9fe7ca245dfb831cd0cd3e6403384cd3b7d1197f.tar.gz pi-bitcoindev-9fe7ca245dfb831cd0cd3e6403384cd3b7d1197f.zip | |
Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme
| -rw-r--r-- | 61/3627fc692bfd6b71b3a5f159f206f8df1ead28 | 226 |
1 files changed, 226 insertions, 0 deletions
diff --git a/61/3627fc692bfd6b71b3a5f159f206f8df1ead28 b/61/3627fc692bfd6b71b3a5f159f206f8df1ead28 new file mode 100644 index 000000000..39db5d87a --- /dev/null +++ b/61/3627fc692bfd6b71b3a5f159f206f8df1ead28 @@ -0,0 +1,226 @@ +Return-Path: <roconnor@blockstream.io> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6B37FE29 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 1 Jun 2018 18:15:53 +0000 (UTC) +Received: by mail-io0-f178.google.com with SMTP id d185-v6so2729173ioe.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <C3ED56D2-CB1F-4DE5-AB43-F826705806FB@xbt.hk> +References: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk> + <CAMZUoKms85DhtS1mN70nq4LSY7QtXym6E4_yvQk5Q0tizkVwEQ@mail.gmail.com> + <C3ED56D2-CB1F-4DE5-AB43-F826705806FB@xbt.hk> +From: "Russell O'Connor" <roconnor@blockstream.io> +Date: Fri, 1 Jun 2018 14:15:32 -0400 +Message-ID: <CAMZUoKmqdT3fte0o-CSppMV125u9zmxheaP549=nqkeVGSryMA@mail.gmail.com> +To: Johnson Lau <jl2012@xbt.hk> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jl2012@xbt.hk> wrote: + +> On 1 Jun 2018, at 11:03 PM, Russell O'Connor <roconnor@blockstream.io> +> 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 + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F= +ri, Jun 1, 2018 at 1:03 PM, Johnson Lau <span dir=3D"ltr"><<a href=3D"ma= +ilto:jl2012@xbt.hk" target=3D"_blank">jl2012@xbt.hk</a>></span> wrote:<b= +r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= +r-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"overflow-= +wrap: break-word;"><div><div class=3D"gmail-h5"><div><blockquote type=3D"ci= +te"><div class=3D"gmail_extra">On 1 Jun 2018, at 11:03 PM, Russell O'Co= +nnor <<a href=3D"mailto:roconnor@blockstream.io" target=3D"_blank">rocon= +nor@blockstream.io</a>> wrote:<br><div class=3D"gmail_quote">On Thu, May= + 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev <span dir=3D"ltr"><<a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit= +coin-dev@lists.linuxfounda<wbr>tion.org</a>></span> wrote:<br><blockquot= +e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= +olid rgb(204,204,204);padding-left:1ex"><br> +=C2=A0 Double SHA256 of the serialization of:<br></blockquote><div><br></di= +v><div>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?<br><br></div><div>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.<br= +></div><div><br></div><div>Can we add CHECKSIGFROMSTACK or do you think tha= +t would go into a separate BIP?<br></div></div></div><div> +</div></blockquote></div><br></div></div><div>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.</div><div><br></div><div>sigversion is a response to Peter= + Todd=E2=80=99s comments on BIP143:=C2=A0<a href=3D"https://petertodd.org/2= +016/segwit-consensus-critical-code-review#bip143-transaction-signature-veri= +fication" target=3D"_blank">https://petertodd.org/<wbr>2016/segwit-consensu= +s-<wbr>critical-code-review#bip143-<wbr>transaction-signature-<wbr>verifica= +tion</a></div><div><br></div><div>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.</div><div><br></div><div>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?</div></div></blockquote><div><br></div><div>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.<br><br></div><blockquote class=3D"gmail_quote" style= +=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= +-left:1ex"><div style=3D"overflow-wrap: break-word;"><div></div><div>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?</div></div></blockquote><div><br></div><div>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.<br></div></div></div></di= +v> + +--0000000000000589c8056d9893c8-- + |