path: root/18/f6b41d309cde16640e8fe113d6ea9a95f616d1

Return-Path: <steven@roose.io>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 10A1AC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Sep 2023 11:44:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id CE62160FEB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Sep 2023 11:44:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CE62160FEB
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=roose.io header.i=@roose.io
 header.a=rsa-sha256 header.s=default header.b=ibRqvlai
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id z8MCGRIeYR9u
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Sep 2023 11:44:10 +0000 (UTC)
Received: from hosted.mailcow.de (hosted.mailcow.de [IPv6:2a00:f820:417::202])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 53AD860FE6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Sep 2023 11:44:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 53AD860FE6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roose.io; s=default;
 t=1696074246; h=from:subject:date:message-id:to:mime-version:content-type;
 bh=H1m5PhqU0GhVRXJ0sQmdGPWTHB1pPqCbGk1pDvbFehk=;
 b=ibRqvlai7W42UgEtQQfrWqM4TaraXgJpbojfLjzHVGsRQeuXEb3OIF6YUb2u9qlnzqXm8T
 Xhlzy0oCTNhKJfuz385jksC4JDB9mJTr1shMv7/tCf95a9fw2tLnm4mpplHHZSvteFyGty
 i88IBS/UFnrmo895Ymfwa8Xcp8vwwElNfG8ekp7QuInRtZlL0Bs7fSwLuVYUDqKrWyZm7I
 fC78qkP7XvMmKVFVATVLLsEi2CFqUtkS3hv/+9RzGfdZg427pmra5DirL8oT4an3L1pgb1
 YZDhj8Mx+0QzK7hxQe47CdSvt9wIG1J8IVRWdJsW2vD2SQpCKfTc0CTu7rtwJA==
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)
 with ESMTPSA id E1C525C0290
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Sep 2023 13:44:05 +0200 (CEST)
Content-Type: multipart/mixed; boundary="------------TrpMYSU683XZbSX5aDS0w6A4"
Message-ID: <e98d76f2-6f2c-9c3a-6a31-bccb34578c31@roose.io>
Date: Sat, 30 Sep 2023 12:44:02 +0100
MIME-Version: 1.0
Content-Language: en-US
From: Steven Roose <steven@roose.io>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailman-Approved-At: Sat, 30 Sep 2023 15:18:41 +0000
Subject: [bitcoin-dev] Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 30 Sep 2023 11:44:13 -0000

This is a multi-part message in MIME format.
--------------TrpMYSU683XZbSX5aDS0w6A4
Content-Type: multipart/alternative;
 boundary="------------nkSfBSgDXyUAJAtGVQ1MHNB0"

--------------nkSfBSgDXyUAJAtGVQ1MHNB0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hey all


The idea of TXHASH has been around for a while, but AFAIK it was never 
formalized. After conversations with Russell, I worked on a 
specification and have been gathering some feedback in the last several 
weeks.

I think the draft is in a state where it's ready for wider feedback and 
at the same time I'm curious about the sentiment in the community about 
this idea.

The full BIP text can be found in the attachment as well as at the 
following link:
https://github.com/bitcoin/bips/pull/1500

I will summarize here in this writing.

*What does the BIP specify?*

  * The concept of a TxFieldSelector, a serialized data structure for
    selecting data inside a transaction.
      o The following global fields are available:
          + version
          + locktime
          + number of inputs
          + number of outputs
          + current input index
          + current input control block
      o For each input, the following fields are available:
          + previous outpoint
          + sequence
          + scriptSig
          + scriptPubkey of spending UTXO
          + value of spending UTXO
          + taproot annex
      o For each output, the following fields are available:
          + scriptPubkey
          + value
      o There is support for selecting inputs and outputs as follows:
          + all in/outputs
          + a single in/output at the same index as the input being executed
          + any number of leading in/outputs up to 2^14 - 1 (16,383)
          + up to 64 individually selected in/outputs (up to 2^16 or 65,536)
      o The empty byte string is supported and functions as a default
        value which commits to everything except the previous outpoints
        and the scriptPubkeys of the spending UTXOs.

  * An opcode OP_TXHASH, enabled only in tapscript, that takes a
    serialized TxFieldSelector from the stack and pushes on the stack a
    hash committing to all the data selected.

  * An opcode OP_CHECKTXHASHVERIFY, enabled in all script contexts, that
    expects a single item on the stack, interpreted as a 32-byte hash
    value concatenated with (at the end) a serialized TxFieldSelector.
    Execution fails is the hash value in the data push doesn't equal the
    calculated hash value based on the TxFieldSelector.

  * A consideration for resource usage trying to address concerns around
    quadratic hashing. A potential caching strategy is outlined so that
    users can't trigger excessive hashing.
      o Individual selection is limited to 64 items.
      o Selecting "all" in/outputs can mostly use the same caches as
        sighash calculations.
      o For prefix hashing, intermediate SHA256 contexts can be stored
        every N items so that at most N-1 items have to be hashed when
        called repeatedly.
      o In non-tapscript contexts, at least 32 witness bytes are
        required and because (given the lack of OP_CAT) subsequent calls
        can only re-enforce the same TxFieldSelector, no additional
        limitations are put in place.
      o In tapscript, because OP_TXHASH doesn't require 32 witness bytes
        and because of a potential addition of operations like OP_CAT,
        the validation budget is decreased by 10 for every OP_TXHASH or
        OP_CHECKTXHASHVERIFY operation.


*What does this achieve?*

  * Since the default TxFieldSelector is functionally equivalent to
    OP_CHECKTEMPLATEVERIFY, with no extra bytes required, this proposal
    is a strict upgrade of BIP-119.

  * The flexibility of selecting transaction fields and in/output
    (ranges), makes this construction way more useful
      o when designing protocols where users want to be able to add fees
        to their transactions without breaking a transaction chain;
      o when designing protocols where users construct transactions
        together, each providing some of their own in- and outputs and
        wanting to enforce conditions only on these in/outputs.

  * OP_TXHASH, together with OP_CHECKSIGFROMSTACK (and maybe OP_CAT*)
    could be used as a replacement for almost arbitrarily complex
    sighash constructions, like SIGHASH_ANYPREVOUT.

  * Apart from being able to enforce specific fields in the transaction
    to have a pre-specified value, equality can also be enforced, which
    can f.e. replace the desire for opcodes like OP_IN_OUT_VALUE.*

  * The same TxFieldSelector construction would function equally well
    with a hypothetical OP_TX opcode that directly pushes the selected
    fields on the stack to enable direct introspection.


*What are still open questions?*

  * Does the proposal sufficiently address concerns around resource
    usage and quadratic hashing?

  * *: Miraculously, once we came up with all possible fields that we
    might consider interesting, we filled exactly 16 spots. There is
    however one thing that I would have liked to be optionally available
    and I am unsure of which side to take in the proposal. This is
    including the TxFieldSelector as part of the hash. Doing so no
    longer makes the hash only represent the value being hashed, but
    also the field selector that was used; this would no longer make it
    possible to proof equality of fields. If a txhash as specified here
    would ever be used as a signature hash, it would definitely have to
    be included, but this could be done after the fact if OP_CAT was
    available. For signature hashes, the hash should ideally be somehow
    tagged, so we might need OP_CAT, or OP_CATSHA256 or something anyway.

      * A solution could be to take an additional bit from each of the
        two "in/output selector" bytes, and assign to this bit "commit
        to total number of in/outputs" (instead of having 2 bits for
        this in the first byte).
          o This would free up 2 bits in the first byte, one of which
            could be used for including the TxFieldSelector in the hash
            and the other one could be left free (OP_SUCCESS) to
            potentially revisit later-on.
          o This would limit the number of selectable leading in/outputs
            to 8,191 and the number of individually selectable
            in/outputs to 32, both of which seem reasonable or maybe
            even more desirable from a resource usage perspective.

  * General feedback of how people feel towards a proposal like this,
    which could either be implemented in a softfork as is, like BIP-119
    or be combined in a single softfork with OP_CHECKSIGFROMSTACK and
    perhaps OP_CAT, OP_TWEAKADD and/or a hypothetical OP_TX.


This work is just an attempt to make some of the ideas that have been 
floating around into a concrete proposal. If there is community 
interest, I would be willing to spend time to adequately formalize this 
BIP and to work on an implementation for Bitcoin Core.


Looking forward to your thoughts

Steven










--------------nkSfBSgDXyUAJAtGVQ1MHNB0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hey all</p>
    <p><br>
    </p>
    <p>The idea of TXHASH has been around for a while, but AFAIK it was
      never formalized. After conversations with Russell, I worked on a
      specification and have been gathering some feedback in the last
      several weeks.</p>
    <p>I think the draft is in a state where it's ready for wider
      feedback and at the same time I'm curious about the sentiment in
      the community about this idea.</p>
    <p>The full BIP text can be found in the attachment as well as at
      the following link:<br>
      <a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bips/pull/1500">https://github.com/bitcoin/bips/pull/1500</a><br>
    </p>
    <p>I will summarize here in this writing.</p>
    <p><b>What does the BIP specify?</b></p>
    <ul>
      <li>The concept of a TxFieldSelector, a serialized data structure
        for selecting data inside a transaction.</li>
      <ul>
        <li>The following global fields are available:</li>
        <ul>
          <li>version</li>
          <li>locktime</li>
          <li>number of inputs</li>
          <li>number of outputs</li>
          <li>current input index</li>
          <li>current input control block</li>
        </ul>
        <li>For each input, the following fields are available:</li>
        <ul>
          <li>previous outpoint</li>
          <li>sequence</li>
          <li>scriptSig</li>
          <li>scriptPubkey of spending UTXO</li>
          <li>value of spending UTXO</li>
          <li>taproot annex</li>
        </ul>
        <li>For each output, the following fields are available:</li>
        <ul>
          <li>scriptPubkey</li>
          <li>value<br>
          </li>
        </ul>
        <li>There is support for selecting inputs and outputs as
          follows:</li>
        <ul>
          <li>all in/outputs<br>
          </li>
          <li>a single in/output at the same index as the input being
            executed</li>
          <li>any number of leading in/outputs up to 2^14 - 1 (16,383)<br>
          </li>
          <li>up to 64 individually selected in/outputs (up to 2^16 or
            65,536)</li>
        </ul>
        <li>The empty byte string is supported and functions as a
          default value which commits to everything except the previous
          outpoints and the scriptPubkeys of the spending UTXOs.<br>
        </li>
      </ul>
    </ul>
    <ul>
      <li>An opcode OP_TXHASH, enabled only in tapscript, that takes a
        serialized TxFieldSelector from the stack and pushes on the
        stack a hash committing to all the data selected.</li>
    </ul>
    <ul>
      <li>An opcode OP_CHECKTXHASHVERIFY, enabled in all script
        contexts, that expects a single item on the stack, interpreted
        as a 32-byte hash value concatenated with (at the end) a
        serialized TxFieldSelector. Execution fails is the hash value in
        the data push doesn't equal the calculated hash value based on
        the TxFieldSelector.</li>
    </ul>
    <ul>
      <li>A consideration for resource usage trying to address concerns
        around quadratic hashing. A potential caching strategy is
        outlined so that users can't trigger excessive hashing.</li>
      <ul>
        <li>Individual selection is limited to 64 items.</li>
        <li>Selecting "all" in/outputs can mostly use the same caches as
          sighash calculations.</li>
        <li>For prefix hashing, intermediate SHA256 contexts can be
          stored every N items so that at most N-1 items have to be
          hashed when called repeatedly.</li>
        <li>In non-tapscript contexts, at least 32 witness bytes are
          required and because (given the lack of OP_CAT) subsequent
          calls can only re-enforce the same TxFieldSelector, no
          additional limitations are put in place.</li>
        <li>In tapscript, because OP_TXHASH doesn't require 32 witness
          bytes and because of a potential addition of operations like
          OP_CAT, the validation budget is decreased by 10 for every
          OP_TXHASH or OP_CHECKTXHASHVERIFY operation.</li>
      </ul>
    </ul>
    <p><br>
    </p>
    <p><b>What does this achieve?</b></p>
    <ul>
      <li>Since the default TxFieldSelector is functionally equivalent
        to OP_CHECKTEMPLATEVERIFY, with no extra bytes required, this
        proposal is a strict upgrade of BIP-119.</li>
    </ul>
    <ul>
      <li>The flexibility of selecting transaction fields and in/output
        (ranges), makes this construction way more useful</li>
      <ul>
        <li>when designing protocols where users want to be able to add
          fees to their transactions without breaking a transaction
          chain;</li>
        <li>when designing protocols where users construct transactions
          together, each providing some of their own in- and outputs and
          wanting to enforce conditions only on these in/outputs.</li>
      </ul>
    </ul>
    <ul>
      <li>OP_TXHASH, together with OP_CHECKSIGFROMSTACK (and maybe
        OP_CAT*) could be used as a replacement for almost arbitrarily
        complex sighash constructions, like SIGHASH_ANYPREVOUT.</li>
    </ul>
    <ul>
      <li>Apart from being able to enforce specific fields in the
        transaction to have a pre-specified value, equality can also be
        enforced, which can f.e. replace the desire for opcodes like
        OP_IN_OUT_VALUE.*</li>
    </ul>
    <ul>
      <li>The same TxFieldSelector construction would function equally
        well with a hypothetical OP_TX opcode that directly pushes the
        selected fields on the stack to enable direct introspection.<br>
      </li>
    </ul>
    <p><br>
    </p>
    <p><b>What are still open questions?</b></p>
    <ul>
      <li>Does the proposal sufficiently address concerns around
        resource usage and quadratic hashing?</li>
    </ul>
    <ul>
      <li>*: Miraculously, once we came up with all possible fields that
        we might consider interesting, we filled exactly 16 spots. There
        is however one thing that I would have liked to be optionally
        available and I am unsure of which side to take in the proposal.
        This is including the TxFieldSelector as part of the hash. Doing
        so no longer makes the hash only represent the value being
        hashed, but also the field selector that was used; this would no
        longer make it possible to proof equality of fields. If a txhash
        as specified here would ever be used as a signature hash, it
        would definitely have to be included, but this could be done
        after the fact if OP_CAT was available. For signature hashes,
        the hash should ideally be somehow tagged, so we might need
        OP_CAT, or OP_CATSHA256 or something anyway.</li>
    </ul>
    <blockquote>
      <ul>
        <li>A solution could be to take an additional bit from each of
          the two "in/output selector" bytes, and assign to this bit
          "commit to total number of in/outputs" (instead of having 2
          bits for this in the first byte).</li>
        <ul>
          <li>This would free up 2 bits in the first byte, one of which
            could be used for including the TxFieldSelector in the hash
            and the other one could be left free (OP_SUCCESS) to
            potentially revisit later-on.</li>
          <li>This would limit the number of selectable leading
            in/outputs to 8,191 and the number of individually
            selectable in/outputs to 32, both of which seem reasonable
            or maybe even more desirable from a resource usage
            perspective.<br>
          </li>
        </ul>
      </ul>
    </blockquote>
    <ul>
      <li>General feedback of how people feel towards a proposal like
        this, which could either be implemented in a softfork as is,
        like BIP-119 or be combined in a single softfork with
        OP_CHECKSIGFROMSTACK and perhaps OP_CAT, OP_TWEAKADD and/or a
        hypothetical OP_TX.</li>
    </ul>
    <p><br>
    </p>
    <p>This work is just an attempt to make some of the ideas that have
      been floating around into a concrete proposal. If there is
      community interest, I would be willing to spend time to adequately
      formalize this BIP and to work on an implementation for Bitcoin
      Core.<br>
    </p>
    <p><br>
    </p>
    <p>Looking forward to your thoughts<br>
    </p>
    <p>Steven<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
  </body>
</html>

--------------nkSfBSgDXyUAJAtGVQ1MHNB0--
--------------TrpMYSU683XZbSX5aDS0w6A4
Content-Type: text/html; charset=UTF-8; name="bip-txhash.mediawiki"
Content-Disposition: attachment; filename="bip-txhash.mediawiki"
Content-Transfer-Encoding: base64

PHByZT4KICBCSVA6IHRiZAogIExheWVyOiBDb25zZW5zdXMgKHNvZnQgZm9yaykKICBUaXRs
ZTogT1BfVFhIQVNIIGFuZCBPUF9DSEVDS1RYSEFTSFZFUklGWQogIEF1dGhvcjogU3RldmVu
IFJvb3NlIDxzdGV2ZW5Acm9vc2UuaW8+CiAgQ29tbWVudHMtVVJJOiBodHRwczovL2dpdGh1
Yi5jb20vYml0Y29pbi9iaXBzL3dpa2kvQ29tbWVudHM6QklQLXRiZAogIFN0YXR1czogRHJh
ZnQKICBUeXBlOiBTdGFuZGFyZHMgVHJhY2sKICBDcmVhdGVkOiAyMDIzLTA5LTAzCiAgTGlj
ZW5zZTogQlNELTMtQ2xhdXNlCjwvcHJlPgoKPT1BYnN0cmFjdD09CgpUaGlzIEJJUCBwcm9w
b3NlcyB0d28gbmV3IG9wY29kZXMsIE9QX0NIRUNLVFhIQVNIVkVSSUZZLCB0byBiZSBhY3Rp
dmF0ZWQKYXMgYSBjaGFuZ2UgdG8gdGhlIHNlbWFudGljcyBvZiBPUF9OT1A0IGluIGxlZ2Fj
eSBzY3JpcHQsIHNlZ3dpdCBhbmQgdGFwc2NyaXB0OwphbmQgT1BfVFhIQVNILCB0byBiZSBh
Y3RpdmF0ZWQgYXMgYSBjaGFuZ2UgdG8gdGhlIHNlbWFudGljcyBvZiBPUF9TVUNDRVNTMTg5
CmluIHRhcHNjcmlwdCBvbmx5LgoKVGhlc2UgbmV3IG9wY29kZXMgYWxsb3cgZm9yIG5vbi1p
bnRlcmFjdGl2ZSBlbmZvcmNlbWVudCBvZiBjZXJ0YWluIHByb3BlcnRpZXMKb2YgdHJhbnNh
Y3Rpb25zIHNwZW5kaW5nIGEgY2VydGFpbiBVVFhPLiBUb2dldGhlciB3aXRoIHNvbWV0aGlu
ZyBsaWtlIApPUF9DSEVDS1NJR0ZST01TVEFDSyAoYW5kIG1heWJlIE9QX0NBVCkgaXQgd291
bGQgYWxzbyBlbmFibGUgdGhlIGVtdWxhdGlvbiBvZgphcmJpdHJhcmlseSBjb21wbGV4IHNp
Z2hhc2ggdHlwZXMuIE1vcmUgb24gdGhlIHVzZSBjYXNlcyBpbiB0aGUgTW90aXZhdGlvbgpz
ZWN0aW9uIG9mIHRoaXMgQklQLgoKCj09U3VtbWFyeT09CgpPUF9DSEVDS1RYSEFTSFZFUklG
WSB1c2VzIG9wY29kZSBPUF9OT1A0ICgweGIzKSBhcyBhIHNvZnQgZm9yayB1cGdyYWRlLgoK
T1BfQ0hFQ0tUWEhBU0hWRVJJRlkgZG9lcyB0aGUgZm9sbG93aW5nOgoKKiBUaGVyZSBpcyBh
dCBsZWFzdCBvbmUgZWxlbWVudCBvbiB0aGUgc3RhY2ssIGZhaWwgb3RoZXJ3aXNlLgoqIFRo
ZSBlbGVtZW50IG9uIHRoZSBzdGFjayBpcyBhdCBsZWFzdCAzMiBieXRlcyBsb25nLCBmYWls
IG90aGVyd2lzZS4KKiBUaGUgZmlyc3QgMzIgYnl0ZXMgYXJlIGludGVycHJldGVkIGFzIHRo
ZSBUeEhhc2ggYW5kIHRoZSByZW1haW5pbmcgc3VmZml4CiAgYnl0ZXMgc3BlY2lmeSB0aGUg
VHhGaWVsZFNlbGVjdG9yLgoqIElmIFZhbGlkYXRlVHhGaWVsZFNlbGVjdG9yIGZhaWxzIGZv
ciB0aGUgcHJvdmlkZWQgVHhGaWVsZFNlbGVjdG9yLCBmYWlsLgoqIFRoZSBhY3R1YWwgVHhI
YXNoIG9mIHRoZSB0cmFuc2FjdGlvbiBhdCB0aGUgY3VycmVudCBpbnB1dCBpbmRleCwgY2Fs
Y3VsYXRlZAogIHVzaW5nIHRoZSBnaXZlbiBUeEZpZWxkU2VsZWN0b3IgbXVzdCBiZSBlcXVh
bCB0byB0aGUgZmlyc3QgMzIgYnl0ZXMgb2YgdGhlCiAgZWxlbWVudCBvbiB0aGUgc3RhY2ss
IGZhaWwgb3RoZXJ3aXNlLgoKCk9QX1RYSEFTSCB1c2VzIHRhcHNjcmlwdCBvcGNvZGUgT1Bf
U1VDQ0VTUzE4OSAoMHhiZCkgYXMgYSBzb2Z0IGZvcmsgdXBncmFkZS4KCk9QX1RYSEFTSCBk
b2VzIHRoZSBmb2xsb3dpbmc6CgoqIFRoZXJlIGlzIGF0IGxlYXN0IG9uZSBlbGVtZW50IG9u
IHRoZSBzdGFjaywgZmFpbCBvdGhlcndpc2UuCiogVGhlIGVsZW1lbnQgaXMgaW50ZXJwcmV0
ZWQgYXMgdGhlIFR4RmllbGRTZWxlY3RvciBhbmQgaXMgcG9wcGVkIG9mZiB0aGUgc3RhY2su
CiogSWYgVmFsaWRhdGVUeEZpZWxkU2VsZWN0b3IgZmFpbHMgZm9yIHRoZSBwcm92aWRlZCBU
eEZpZWxkU2VsZWN0b3IsIGZhaWwuCiogVGhlIDMyLWJ5dGUgVHhIYXNoIG9mIHRoZSB0cmFu
c2FjdGlvbiBhdCB0aGUgY3VycmVudCBpbnB1dCBpbmRleCwKICBjYWxjdWxhdGVkIHVzaW5n
IHRoZSBnaXZlbiBUeEZpZWxkU2VsZWN0b3IgaXMgcHVzaGVkIG9udG8gdGhlIHN0YWNrLgoK
ClRoZSBUeEZpZWxkU2VsZWN0b3IgaGFzIHRoZSBmb2xsb3dpbmcgc2VtYW50aWNzLiBXZSB3
aWxsIGdpdmUgYSBicmllZiBjb25jZXB0dWFsCnN1bW1hcnksIGZvbGxvd2VkIGJ5IGEgcmVm
ZXJlbmNlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBDYWxjdWxhdGVUeEhhc2ggZnVuY3Rpb24u
CgoqIElmIHRoZSBUeEZpZWxkU2VsZWN0b3IgaXMgemVybyBieXRlcyBsb25nLCBpdCBpcyBz
ZXQgZXF1YWwgdG8KICAweGZmfDB4ZjZ8MHgzZnwweDNmLCB0aGUgZGUtZmFjdG8gZGVmYXVs
dCB2YWx1ZSB3aGljaCBtZWFucyBldmVyeXRoaW5nIGV4Y2VwdAogIHRoZSBwcmV2b3V0cyBh
bmQgdGhlIHByZXZvdXQgc2NyaXB0UHVia2V5cy4KKiBUaGUgZmlyc3QgYnl0ZSBvZiB0aGUg
VHhGaWVsZFNlbGVjdG9yIGhhcyBpdHMgOCBiaXRzIGFzc2lnbmVkIGFzIGZvbGxvd3MsCiAg
ZnJvbSBsb3dlc3QgdG8gaGlnaGVzdDoKICAxLiB2ZXJzaW9uCiAgMi4gbG9ja3RpbWUKICAz
LiBuYl9pbnB1dHMKICA0LiBuYl9vdXRwdXRzCiAgNS4gY3VycmVudCBpbnB1dCBpbmRleAog
IDYuIGN1cnJlbnQgaW5wdXQgY29udHJvbCBibG9jayAob25seSBpbiBjYXNlIG9mIHRhcHNj
cmlwdCBzcGVuZCkKICA3LiBpbnB1dHMKICA4LiBvdXRwdXRzCgoqIElmIGVpdGhlciAiaW5w
dXRzIiBvciAib3V0cHV0cyIgaXMgc2V0IHRvIDEsIGV4cGVjdCBhbm90aGVyIGJ5dGUgd2l0
aCBpdHMgOAogIGJpdHMgYXNzaWduaW5nIHRoZSBmb2xsb3dpbmcgdmFyaWFibGVzLCBmcm9t
IGxvd2VzdCB0byBoaWdoZXN0OgogICogU3BlY2lmeWluZyB3aGljaCBmaWVsZHMgb2YgdGhl
IGlucHV0cyB3aWxsIGJlIHNlbGVjdGVkOgogICAgMS4gcHJldm91dHMKICAgIDIuIHNlcXVl
bmNlcwogICAgMy4gc2NyaXB0U2lncwogICAgNC4gcHJldm91dCBzY3JpcHRQdWJrZXlzCiAg
ICA1LiBwcmV2b3V0IHZhbHVlcwogICAgNi4gdGFwcm9vdCBhbm5leGVzIChvbmx5IGluIGNh
c2Ugb2YgdGFwc2NyaXB0IHNwZW5kKQogICogU3BlY2lmeWluZyB3aGljaCBmaWVsZHMgb2Yg
dGhlIG91dHB1dHMgd2lsbCBiZSBzZWxlY3RlZDoKICAgIDcuIHNjcmlwdFB1YmtleXMKICAg
IDguIHZhbHVlcwoKRm9yIGJvdGggaW5wdXRzIGFuZCB0aGVuIG91dHB1dHMsIGRvIHRoZSBm
b2xsb3dpbmc6CgoqIElmIHRoZSAiaW4vb3V0cHV0cyIgZmllbGQgaXMgc2V0IHRvIDEsIGFu
b3RoZXIgYWRkaXRpb25hbCBieXRlIGlzIGV4cGVjdGVkOgogICogVGhlcmUgYXJlIHR3byBl
eGNlcHRpb25hbCB2YWx1ZXM6CiAgICAtIDB4MDAgbWVhbnMgInNlbGVjdCBvbmx5IHRoZSBp
bi9vdXRwdXQgb2YgdGhlIGN1cnJlbnQgaW5wdXQgaW5kZXgiLgogICAgLSAweDNmIG1lYW5z
ICJzZWxlY3QgYWxsIGluL291dHB1dHMiLiAvL1RPRE8oc3RldmVucm9vc2UpIG1ha2UgdGhp
cyAweGZmPwogICogVGhlIGhpZ2hlc3QgYml0IGlzIHRoZSAic3BlY2lmaWNhdGlvbiBtb2Rl
IjoKICAgIC0gU2V0IHRvIDAgaXQgbWVhbnMgInByZWZpeCBtb2RlIi4KICAgIC0gU2V0IHRv
IDEgaXQgbWVhbnMgImluZGl2aWR1YWwgbW9kZSIuCiAgKiBUaGUgc2Vjb25kIGhpZ2hlc3Qg
Yml0IGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhlICJpbmRleCBzaXplIiwgaS5lLiB0aGUgbnVt
YmVyCiAgICBvZiBieXRlcyB3aWxsIGJlIHVzZWQgdG8gcmVwcmVzZW50IGluL291dHB1dCBp
bmRpY2VzLgogICogSW4gInByZWZpeCBtb2RlIiwKICAgIC0gV2l0aCAiaW5kZXggc2l6ZSIg
c2V0IHRvIDAsIHRoZSByZW1haW5pbmcgbG93ZXN0IDYgYml0cyBvZiB0aGUgZmlyc3QgYnl0
ZQogICAgICB3aWxsIGJlIGludGVycHJldGVkIGFzIHRoZSBudW1iZXIgb2YgbGVhZGluZyBp
bi9vdXRwdXRzIHRvIHNlbGVjdC4KICAgIC0gV2l0aCAiaW5kZXggc2l6ZSIgc2V0IHRvIDEs
IHRoZSByZW1haW5pbmcgbG93ZXN0IDYgYml0cyBvZiB0aGUgZmlyc3QgYnl0ZQogICAgICB0
b2dldGhlciB3aXRoIHRoZSA4IGJpdHMgb2YgdGhlIG5leHQgYnl0ZSB3aWxsIGJlIGludGVy
cHJldGVkIGFzIHRoZQogICAgICBudW1iZXIgb2YgbGVhZGluZyBpbi9vdXRwdXRzIHRvIHNl
bGVjdC4KICAqIEluICJpbmRpdmlkdWFsIG1vZGUiLCB0aGUgcmVtYWluaW5nIGxvd2VzdCA2
IGJpdHMgb2YgdGhlIGZpcnN0IGJ5dGUgd2lsbCBiZQogICAgaW50ZXJwcmV0ZWQgYXMgYG5g
LCB0aGUgbnVtYmVyIG9mIGluZGl2aWR1YWwgaW4vb3V0cHV0cyB0byBzZWxlY3QuCiAgICAt
IFdpdGggImluZGV4IHNpemUiIHNldCB0byAwLCBpbnRlcnByZXQgdGhlIGZvbGxvd2luZyBg
bmAgaW5kaXZpZHVhbCBieXRlcwogICAgICBhcyB0aGUgaW5kaWNlcyBvZiBhbiBpbmRpdmlk
dWFsIGluL291dHB1dHMgdG8gc2VsZWN0LgogICAgLSBXaXRoICJpbmRleCBzaXplIiBzZXQg
dG8gMSwgaW50ZXJwcmV0IHRoZSBuZXh0IGBuYCBwYWlycyBvZiB0d28gYnl0ZXMgYXMKICAg
ICAgdGhlIGluZGljZXMgb2YgaW5kaXZpZHVhbCBpbi9vdXRwdXRzIHRvIHNlbGVjdC4KCgpU
aGUgZnVuY3Rpb24gVmFsaWRhdGVUeEZpZWxkU2VsZWN0b3IgaGFzIHRoZSBmb2xsb3dpbmcg
c2VtYW50aWNzLCBpdAplZmZlY3RpdmVseSBjaGVja3MgdGhhdCB0aGUgVHhGaWVsZFNlbGVj
dG9yIHZhbHVlIGlzIHZhbGlkIGFjY29yZGluZyB0bwphYm92ZSBydWxlczoKCiogSWYgdGhl
cmUgYXJlIDAgYnl0ZXMsIGl0IGJlY29tZXMgdGhlIGRlZmF1bHQgb2YgMHhmZnwweGY2fDB4
ZmZ8MHhmZjsgc3VjY2VlZC4KKiBJZiB0aGUgZmlyc3QgYnl0ZSBpcyBleGFjdGx5IDB4MDAs
IHRoZSBTY3JpcHQgZXhlY3V0aW9uIHN1Y2NlZWRzIGltbWVkaWF0ZWx5LgogIC8vVE9ETyhz
dGV2ZW5yb29zZSkgaXMgdGhpcyB2YWx1YWJsZT8gaXQncyB0aGUgb25seSAiZXhjZXB0aW9u
IGNhc2UiIHRoYXQKICBjb3VsZCBwb3RlbnRpYWxseSBiZSBob29rZWQgZm9yIHNvbWUgZnV0
dXJlIHVwZ3JhZGUKKiBJZiBpbiB0aGUgZmlyc3QgYnl0ZSwgImlucHV0cyIgYW5kICJvdXRw
dXRzIiBpcyAwLCBubyBhZGRpdGlvbmFsIGJ5dGVzIGNhbiBiZQogIHByZXNlbnQsIG90aGVy
d2lzZSBmYWlsLgoqIElmIHRoZSAiaW5wdXRzIiBiaXQgaXMgc2V0IHRvIDEsIG9uZSBvZiB0
aGUgbG93ZXN0IDYgYml0cyBpbiB0aGUgc2Vjb25kIGJ5dGUKICBtdXN0IGJlIHNldCB0byAx
LCBvdGhlcndpc2UgZmFpbC4KKiBJZiB0aGUgIm91dHB1dHMiIGJpdCBpcyBzZXQgdG8gMSwg
b25lIG9mIHRoZSBoaWdoZXN0IDIgYml0cyBpbiB0aGUgc2Vjb25kIGJ5dGUKICBtdXN0IGJl
IHNldCB0byAxLCBvdGhlcndpc2UgZmFpbC4KKiBJZiBpbiB0aGUgZmlyc3QgYnl0ZSwgImlu
cHV0cyIgb3IgIm91dHB1dHMiIGlzIDEsIGRvIHRoZSBmb2xsb3dpbmcsIG9uY2UgZm9yCiAg
ZWFjaDoKICAqIEV4cGVjdCBhbiBhZGRpdGlvbmFsIGJ5dGUuCiAgKiBJZiB0aGlzIGJ5dGUg
aXMgZWl0aGVyIDB4MDAgb3IgMHgzZiwgbm8gYWRkaXRpb25hbCBieXRlcyBhcmUgZXhwZWN0
ZWQgZm9yCiAgICB0aGlzIHNlY3Rpb24uCiAgKiBJbnRlcnByZXQgdGhlIHRvcCAyIGJpdHMg
b2YgdGhpcyBieXRlIGFzIHBlciBhYm92ZSwgc2V0dGluZyB0aGUKICAgICJzcGVjaWZpY2F0
aW9uIiBtb2RlIGFuZCAiaW5kZXggc2l6ZSIuCiAgKiBJbiAicHJlZml4IG1vZGUiOgogICAg
KiB3aXRoICJpbmRleCBzaXplIiAwLCBubyBhZGRpdGlvbmFsIGJ5dGVzIGFyZSBleHBlY3Rl
ZCwgb3RoZXJ3aXNlIGZhaWw7CiAgICAqIHdpdGggImluZGV4IHNpemUiIDEsIG9uZSBhZGRp
dGlvbmFsIGJ5dGUgYXJlIGV4cGVjdGVkLCBvdGhlcndpc2UgZmFpbC4KICAqIEluICJpbmRp
dmlkdWFsIG1vZGUiLCBpbnRlcnByZXQgdGhlIGxvd2VzdCA2IGJpdHMgb2YgdGhpcyBieXRl
IGFzIGludGVnZXIgbiwKICAgIHNvIHRoYXQKICAgICogd2l0aCAiaW5kZXggc2l6ZSIgMCwg
biBhZGRpdGlvbmFsIGJ5dGVzIGFyZSBleHBlY3RlZCwgb3RoZXJ3aXNlIGZhaWw7CiAgICAq
IHdpdGggImluZGV4IHNpemUiIDEsIHR3byB0aW1lcyBuIGFkZGl0aW9uYWwgYnl0ZXMgYXJl
IGV4cGVjdGVkLCBvdGhlcndpc2UKICAgICAgZmFpbC4KKiBJZiBhbnkgYWRkaXRpb25hbCBi
eXRlcyBhcmUgcHJlc2VudCBhZnRlciB0aGlzLCBmYWlsLgoKClRoZSByZWNvbW1lbmRlZCBz
dGFuZGFyZG5lc3MgcnVsZXMgYWRkaXRpb25hbGx5OgoKKiBSZWplY3Qgbm9uLWVtcHR5IHB1
c2hlcyBzdGFydGluZyB3aXRoIHRoZSAwIGJ5dGUgcHJlY2VkaW5nIE9QX1RYSEFTSCBhcwog
IFNDUklQVF9FUlJfRElTQ09VUkFHRV9VUEdSQURBQkxFX05PUFMuCgoKPT09UmVzb3VyY2Ug
bGltaXRzPT09CgoqIEZvciBsZWdhY3kgc2NyaXB0cyBhbmQgc2Vnd2l0LCB3ZSBkb24ndCBh
ZGQgYW55IGV4dHJhIHJlc291cmNlIGxpbWl0YXRpb25zLAogIHdpdGggdGhlIGFyZ3VtZW50
YXRpb24gdGhhdCBPUF9DSEVDS1RYSEFTSFZFUklGWSBhbHJlYWR5IHJlcXVpcmVzIHRoZSB1
c2VyIHRvCiAgcHJvdmlkZSBhdCBsZWFzdCAzMiBieXRlcyBvZiBleHRyYSB0cmFuc2FjdGlv
biBzaXplLCBlaXRoZXIgaW4gdGhlIGlucHV0CiAgc2NyaXB0U2lnLCBvciB0aGUgd2l0bmVz
cy4gQWRkaXRpb25hbCBtb3JlIGNvbXBsZXggaGFzaGVzIHJlcXVpcmUgYWRkaXRpb25hbAog
IHdpdG5lc3MgYnl0ZXMuIEdpdmVuIHRoYXQgT1BfQ0FUIGlzIG5vdCBhdmFpbGFibGUgaW4g
dGhpcyBjb250ZXh0LCBpZiBhCiAgbWFsaWNpb3VzIHVzZXIgdHJpZXMgdG8gaW5jcmVhc2Ug
dGhlIG51bWJlciBvZiBUcmFuc2FjdGlvbkhhc2hlcyBiZWluZwogIGNhbGN1bGF0ZWQgYnkg
dXNpbmcgb3Bjb2RlcyBsaWtlIE9QX0RVUCwgdGhlIFR4RmllbGRTZWxlY3RvciBmb3IgYWxs
IHRoZXNlCiAgY2FsY3VsYXRpb25zIGlzIGlkZW50aWNhbCwgc28gdGhlIGNhbGN1bGF0aW9u
IGNhbiBiZSBjYWNoZWQgd2l0aGluIHRoZSBzYW1lCiAgdHJhbnNhY3Rpb24uCgoqIEZvciB0
YXBzY3JpcHQsIHByaW1hcmlseSBtb3RpdmF0ZWQgYnkgdGhlIGNoZWFwZXIgb3Bjb2RlIE9Q
X1RYSEFTSCAodGhhdAogIGRvZXNuJ3QgcmVxdWlyZSBhbiBhZGRpdGlvbmFsIDMyIHdpdG5l
c3MgYnl0ZXMgYmUgcHJvdmlkZWQpIGFuZCB0aGUgcG90ZW50aWFsCiAgZnV0dXJlIGFkZGl0
aW9uIG9mIGJ5dGUgbWFuaXB1bGF0aW9uIG9wY29kZXMgbGlrZSBPUF9DQVQsIGFuIGFkZGl0
aW9uYWwgY29zdAogIGlzIHNwZWNpZmllZCBwZXIgVHJhbnNhY3Rpb25IYXNoIGV4ZWN1dGlv
bi4KICBVc2luZyB0aGUgc2FtZSB2YWxpZGF0aW9uIGJ1ZGdldCAoInNpZ29wcyBidWRnZXQi
KSBpbnRyb2R1Y2VkIGluIEJJUC0wMzQyLAogIGVhY2ggVHJhbnNhY3Rpb25IYXNoIGRlY3Jl
YXNlcyB0aGUgdmFsaWRhdGlvbiBidWRnZXQgYnkgMTAuIAogIFRoZSBmb2xsb3dpbmcgY29u
c2lkZXJhdGlvbnMgc2hvdWxkIGJlIG1hZGU6CgogICogSW4gImluZGl2aWR1YWwgbW9kZSIs
IGEgdXNlciBjYW4gYXQgbW9zdCBoYXNoIDY0IGl0ZW1zIHRvZ2V0aGVyLCB3aGljaCB3ZQog
ICAgZG9uJ3QgY29uc2lkZXIgZXhjZXNzaXZlIGZvciBwb3RlbnRpYWwgcmVwZWF0ZWQgdXNl
LgogICogSW4gInByZWZpeCBtb2RlIiwgYSBjYWNoaW5nIHN0cmF0ZWd5IGNhbiBiZSB1c2Vk
IHdoZXJlIHRoZSBTSEEyNTYgY29udGV4dCBpcwogICAgc3RvcmVkIGV2ZXJ5IE4gaW4vb3V0
cHV0cyBzbyB0aGF0IG11bHRpcGxlIGV4ZWN1dGlvbnMgb2YgdGhlIFRyYW5zYWN0aW9uSGFz
aAogICAgZnVuY3Rpb24gY2FuIHVzZSB0aGUgY2FjaGVzIGFuZCBvbmx5IGhhdmUgdG8gaGFz
aCBhbiBhZGRpdGlvbmFsIE4tMSBpdGVtcyBhdAogICAgbW9zdC4KCiAgSWYgZWl0aGVyIGJ1
ZGdldCByZXF1cmllbWVudCBicmluZ3MgdGhlIGJ1ZGdldCBiZWxvdyB6ZXJvLCB0aGUgc2Ny
aXB0IGZhaWxzCiAgaW1tZWRpYXRlbHkuCgoKPT1Nb3RpdmF0aW9uPT0KClRoaXMgQklQIHNw
ZWNpZmllcyBhIGJhc2ljIHRyYW5zYWN0aW9uIGludHJvc3BlY3Rpb24gcHJpbWl0aXZlIHRo
YXQgaXMgdXNlZnVsCnRvIGVpdGhlciByZWR1Y2UgaW50ZXJhY3Rpdml0eSBpbiBtdWx0aS11
c2VyIHByb3RvY29scyBvciB0byBlbmZvcmNlIHNvbWUgYmFzaWMKY29uc3RyYWludHMgb24g
dHJhbnNhY3Rpb25zLgoKQWRkaXRpb25hbGx5LCB0aGUgY29uc3RydWN0aW9ucyBzcGVjaWZp
ZWQgaW4gdGhpcyBCSVAgY2FuIGxheSB0aGUgZ3JvdW5kd29yayBmb3IKc29tZSBwb3RlbnRp
YWwgZnV0dXJlIHVwZ3JhZGVzOgoqIFRoZSBUeEZpZWxkU2VsZWN0b3IgY29uc3RydWN0aW9u
IHdvdWxkIHdvcmsgd2VsbCB3aXRoIGEgaHlwb3RoZXRpY2FsIG9wY29kZQogIE9QX1RYIHRo
YXQgYWxsb3dzIGZvciBkaXJlY3RseSBpbnRyb3NwZWN0aW5nIHRoZSB0cmFuc2FjdGlvbiBi
eSBwdXR0aW5nIHRoZQogIGZpZWxkcyBzZWxlY3RlZCBvbiB0aGUgc3RhY2sgaW5zdGVhZCBv
ZiBoYXNoaW5nIHRoZW0gdG9nZXRoZXIuCiogVGhlIFRyYW5zYWN0aW9uSGFzaCBvYnRhaW5l
ZCBieSBPUF9UWEhBU0ggY2FuIGJlIGNvbWJpbmVkIHdpdGggYSBoeXBvdGhldGljYWwKICBv
cGNvZGUgT1BfQ0hFQ0tTSUdGUk9NU1RBQ0sgdG8gZWZmZWN0aXZlbHkgY3JlYXRlIGFuIGlu
Y3JlZGlibHkgZmxleGlibGUKICBzaWduYXR1cmUgaGFzaCwgd2hpY2ggd291bGQgZW5hYmxl
IGNvbnN0cnVjdGlvbnMgbGlrZSBTSUdIQVNIX0FOWVBSRVZPVVQuCgo9PT1Db21wYXJpbmcg
d2l0aCBzb21lIGFsdGVybmF0aXZlIHByb3Bvc2Fscz09PQoKKiBUaGlzIHByb3Bvc2FsIHN0
cmljdGx5IHN1cGVyY2VkZXMgQklQLTExOSdzIE9QX0NIRUNLVEVNUExBVEVWRVJJRlksIGFz
IHRoZQogIGRlZmF1bHQgbW9kZSBvZiBvdXIgVHhGaWVsZFNlbGVjdG9yIGlzIGVmZmVjdGl2
ZWx5ICh0aG91Z2ggbm90IGJ5dGUtZm9yLWJ5dGUKICBpZGVudGljYWwpIHRoZSBzYW1lIGFz
IHdoYXQgT1BfQ1RWIGFjb21wbGlzaGVzLCB3aXRob3V0IGNvc3RpbmcgYW55IGFkZGl0aW9u
YWwKICBieXRlcy4gQWRkaXRpb25hbGx5LCB1c2luZyBPUF9DSEVDS1RYSEFTSFZFUklGWSBh
bGxvd3MgZm9yIG1vcmUgZmxleGliaWxpdHkKICB3aGljaCBjYW4gaGVscCBpbiB0aGUgY2Fz
ZSBmb3IKICAqIGVuYWJsaW5nIGFkZGluZyBmZWVzIHRvIGEgdHJhbnNhY3Rpb24gd2l0aG91
dCBicmVha2luZyBhIG11bHRpLXR4IHByb3RvY29sOwogICogbXVsdGktdXNlciBwcm90b2Nv
bHMgd2hlcmUgdXNlcnMgYXJlIG9ubHkgY29uY2VybmVkIGFib3V0IHRoZWlyIG93biBpbnB1
dHMKICAgIGFuZCBvdXRwdXRzLgoKKiBDb25zdHJ1Y3Rpb25zIGxpa2UgT1BfSU5fT1VUX1ZB
TFVFIHVzZWQgd2l0aCBPUF9FUVVBTFZFUklGWSBjYW4gYmUgZW11bGF0ZWQgYnkKICB0d28g
T1BfVFhIQVNIIGluc3RhbmNlcyBieSB1c2luZyB0aGUgVHhGaWVsZFNlbGVjdG9yIHRvIHNl
bGVjdCBhIHNpbmdsZSBpbnB1dAogIHZhbHVlIGZpcnN0IGFuZCBhIHNpbmdsZSBvdXRwdXQg
dmFsdWUgc2Vjb25kIGFuZCBlbmZvcmNpbmcgZXF1YWxpdHkgb24gdGhlCiAgaGFzaGVzLiBO
ZWl0aGVyIG9mIHRoZXNlIGFsdGVybmF0aXZlcyBjYW4gYmUgdXNlZCB0byBlbmZvcmNlIHNt
YWxsIHZhbHVlCiAgZGlmZmVyZW5jaWFscyB3aXRob3V0IHRoZSB1c2Ugb2YgNjQtYml0IGFy
aXRobWV0aWMuCgoqIExpa2UgbWVudGlvbmVkIGFib3ZlLCBTSUdIQVNIX0FOWVBSRVZPVVQg
Y2FuIGJlIGVtdWxhdGVkIHVzaW5nIE9QX1RYSEFTSCB3aGVuCiAgY29tYmluZWQgd2l0aCBP
UF9DSEVDS1NJR0ZST01TVEFDSyBhbmQgT1BfQ0FULgogIGBPUF9EVVAgT1BfVFhIQVNIIE9Q
X0NBVCA8InNvbWVfdGFnIj4gT1BfU1dBUCBPUF9TSEEyNTYgPHB1YmtleT4KICBPUF9DSEVD
S1NJR0ZST01TVEFDS2AgZWZmZWN0aXZlbHkgZW11bGF0ZXMgU0lHSEFTSF9BTllQUkVWT1VU
LgoKCgoKPT1EZXRhaWxlZCBTcGVjaWZpY2F0aW9uPT0KCjxzb3VyY2UgbGFuZz0icnVzdCI+
CndpcAo8L3NvdXJjZT4KCgoKCj09QWNrbm93bGVkZ2VtZW50PT0KCkNyZWRpdCBmb3IgdGhp
cyBwcm9wb3NhbCBtb3N0bHkgZ29lcyB0byBKZXJlbXkgUnViaW4gZm9yIGhpcyB3b3JrIG9u
IEJJUC0xMTkncwpPUF9DSEVDS1RFTVBMQVRFVkVSSUZZIGFuZCB0byBSdXNzZWxsIE8nQ29u
bm9yIGZvciB0aGUgb3JpZ2luYWwgaWRlYSBvZgpPUF9UWEhBU0guCgpBZGRpdGlvbmFsIHRo
YW5rcyB0byBBbmRyZXcgUG9lbHN0cmEsIFJlYXJkZW4gQ29kZSwgUnVzdHkgUnVzc2VsbCBh
bmQKb3RoZXJzIGZvciB0aGVpciBmZWVkYmFjayBvbiB0aGUgc3BlY2lmaWNhdGlvbi4KCg==


--------------TrpMYSU683XZbSX5aDS0w6A4--