smartledger-bsv 3.2.0 → 3.2.2

package/docs/nchain.md

@@ -1,958 +0,0 @@
-PUSHTX and its Building Blocks
-White Paper
-WP1605
-Created:
-Last updated:
-20/05/2021
-14/12/2021PUSHTX and Its Building Blocks
-Copyright
-Information in this document is subject to change without notice and is furnished under a
-license agreement or nondisclosure agreement. The information may only be used or copied in
-accordance with the terms of those agreements.
-All rights reserved. No part of this publication may be reproduced, stored in a retrieval system,
-or transmitted in any form or any means electronic or mechanical, including photocopying and
-recording for any purpose other than the purchaser’s personal use without the written
-permission of nChain Licensing AG. The names of actual companies and products mentioned in
-this document may be trademarks of their respective owners. nChain Licensing AG accepts no
-responsibility or liability for any errors or inaccuracies that may appear in this documentation.
-Disclaimer
-The information contained herein, such as code, data structures, pseudo-code, etc. is provided
-“as is”, no warranty, express or implied, regarding the merchantability or fitness for purpose of
-the information contained herein, is provided by nChain Licensing AG or any of its group
-companies. Neither nChain Licensing AG, nor any of its group companies, accepts any liability
-for any consequential, incidental, special or indirect damages that may occur through use of the
-information contained herein.
-Authors
-NameTitle
-Wei ZhangPrincipal Researcher
-WP1605
-© nChain Licensing AG
-2 of 25PUSHTX and Its Building Blocks
-Contents
-1PUSHTX and Its Building Blocks ..................................................................................... 4
-1.1Generating the signature in-script ...................................................................... 4
-1.2Constructing the message in-script ....................................................................5
-1.3Example of a PELS .................................................................................................... 8
-1.4Optimisation ................................................................................................................ 12
-2Security Analysis .................................................................................................................. 15
-3Appendix ................................................................................................................................. 18
-WP1605
-© nChain Licensing AG
-3 of 25PUSHTX and Its Building Blocks
-1
-PUSHTX and Its Building Blocks
-The core idea of PUSHTX (originally invented by Y. Chan and D. Kramer at nChain in 2017) is to
-generate a signature in-script on a data element on the stack and call OP_CHECKSIG to verify
-the signature. If it passes, it implies that the message constructed by OP_CHECKSIG is identical
-to the data element pushed to the stack. Therefore, it achieves the effect of pushing the
-current spending transaction to the stack. Since its adoption by sCrypt, STAS token and
-Sensible Contracts, the PUSHTX idea has been widely discussed and tested in practice. The
-purpose of this document is to offer some security insight and optimisations while revisiting
-PUSHTX with an example of a perpetually enforcing locking script. We focus on two most
-important building blocks of PUSHTX, the signature generation and the message construction.
-The size of its spending transaction is intended to be a benchmark for reference. Other
-techniques of pushing transactions to the stack are out of scope of this white paper.
-A perpetually enforcing locking script (PELS) is a locking script that enforces some condition or
-conditions on all future transactions in the spending chain that originates from the output that
-contains this locking script. One example to achieve this is to design a locking script that forces
-the locking script in the spending transaction to be the same as itself. Note that a locking script
-with an enforcement only on the next spending transaction would have a much simpler design.
-PELS are particularly useful for the sender (originator) as they can be ensured that all future
-spending transactions will follow the rules which they set out in the locking script. Any violation
-of the rules would invalidate the transaction in terms of script execution.
-1.1 Generating the signature in-script
-The first building block is to generate the signature for a given message 𝑚. We assume that the
-following script segment is part of a locking script, and the input data can be either in an
-unlocking script or hard coded in the same locking script.
-[sign]:= OP_HASH256 𝑘 −1 OP_MUL 𝑘 −1 𝑟𝑎 OP_ADD 𝑛 OP_MOD 𝑟 [toDER]
-SIGHASH_FLAG OP_CAT
-Input data: 𝑚
-Remarks
-1. The equation for computing 𝑠 in the ECDSA signature is 𝑘 −1 (𝑧 + 𝑟𝑎) 𝑚𝑜𝑑 𝑛, where 𝑧 is
-the double SHA256 of the message 𝑚 to be signed. We write the equation in script as
-(𝑘 −1 𝑧 + 𝑘 −1 𝑟𝑎) 𝑚𝑜𝑑 𝑛 to indicate that 𝑘 −1 and 𝑘 −1 𝑟𝑎 can be precomputed. It would be
-very costly to compute modular inverse 𝑘 −1 𝑚𝑜𝑑 𝑛 in script. As we are not using the
-signature for authenticity, the private key 𝑎 and the ephemeral key 𝑘 can be chosen at
-wish and shown publicly.
-2. The script segment [sign] as part of the locking script needs to fix both the
-ephemeral key 𝑘 and the private key 𝑎. Although anyone can generate a valid signature
-using [sign], the focus is on the input 𝑚. The requirement is that there is only one
-value of 𝑚 that can pass OP_CHECKSIG for any given spending transaction. If the
-private key or the public key is not fixed, then the transaction will be malleable. The
-detail can be found in Section 2. If the ephemeral key 𝑘 is not fixed, then anyone can
-WP1605
-© nChain Licensing AG
-4 of 25PUSHTX and Its Building Blocks
-use a different 𝑘 to create a valid transaction with a different transaction ID, which is
-not desirable in some use cases.
-3. To further optimise the script segment, one can choose small values for 𝑘 and 𝑎 such
-as 1, and they can be the same every time. Note that if 𝑘 = 𝑎 = 1, then 𝑠 = 𝑧 +
-𝐺𝑥 𝑚𝑜𝑑 𝑛, where 𝐺𝑥 is the 𝑥-coordinate of the generator point 𝐺. The compressed
-public key will be 𝐺𝑥 too. The definition of [sign] can be re-written as
-[sign]:= OP_HASH256 𝐺𝑥 OP_ADD 𝑛 OP_MOD 𝐺𝑥 [toDER]
-SIGHASH_FLAG OP_CAT
-4. The script segment [toDER] is to convert the pair (𝑟, 𝑠) to the canonical DER format.
-This is the only format accepted by OP_CHECKSIG. It forces 𝑠 to be in the range
-between 0 and 𝑛/2 to avoid transaction ID malleability. Although this is a policy rule in
-the Bitcoin network, it seems that Bitcoin nodes are unlikely to accept alternatives.
-5. Note that SIGHASH_FLAG in [sign] is compulsory as OP_CHECKSIG expects it. It can
-be used to specify which part of the spending transaction should be pushed to the
-stack. For example, the flag ALL would require all the inputs and outputs to be
-included in the message 𝑚, while SINGLE|ANYONECANPAY would require the input
-corresponding to this locking script and its paired output to be included in 𝑚.
-6. If we extend the script segment to “OP_DUP [sign] < 𝑃𝐾 >” with input 𝑚, the stack
-from bottom to top will look like [𝑚, 𝑆𝑖𝑔, 𝑃𝐾] after its execution. A call to
-OP_CHECKSIGVERIFY will consume the signature and the public key, leaving 𝑚 on the
-top of the stack. If the verification is successful, then one can be convinced that the
-message 𝑚 left on the stack is an accurate representation of the spending transaction.
-1.2 Constructing the message in-script
-The signed message in its serialised format is different from the serialised transaction. The
-latter gives away all the information about the transaction, while the signed message
-unintentionally conceals some information about the transaction in hash values and offers
-some information about the output being spent, i.e., its value and its locking script.
-The message 𝑚 cannot be fully embedded in the locking script as it contains the locking script
-itself and some unknown information on the future spending transaction. Only some of the
-fields can be explicitly enforced in the locking script, e.g., version, sequence number, or
-locktime. The message 𝑚 is either provided in the unlocking script in its entirety or constructed
-in script with some inputs from the unlocking script and instructions from the locking script. We
-will focus on the latter as it is more restrictive from the perspective of a spending transaction.
-Note that the goal of constructing the message is to enforce desired values for some data fields
-in the spending transaction. The table below captures all the data fields in the message and
-whether they should or can be fixed in the locking script. “Optional” is given if it is use-case
-specific.
-WP1605
-© nChain Licensing AG
-5 of 25PUSHTX and Its Building Blocks
-Table 1 - Components of a signed message
-ItemsFixed explicitly in locking script or not
-1Version 4 bytes little endianOptional
-2Hash of input outpoints 32 bytesInfeasible due to circular reference of TxID
-3Hash of input sequence numbers 32
-bytesOptional, recommend “Not” to allow more
-flexibility in spending transaction
-4Input outpoint 32 bytes + 4 bytes in little
-endianInfeasible due to circular reference of TxID
-(although 4 bytes index can be optional)
-5Length of previous locking scriptOptional, recommend “Not” for simplicity
-6Previous locking scriptInfeasible due to circular reference of the
-locking script
-7Value of previous locking script 8 bytes
-(little endian)Optional
-8Sequence number 4 bytes (little endian)Optional
-9Hash of outputs 32 bytesOptional if it is known before hand,
-otherwise, infeasible to be fixed.
-10Locktime 4 bytes in little endianOptional
-11Sighash flag 4 bytes in little endianRecommend being fixed for more
-restrictiveness
-From now on, the data fields in the table will be referred as item 1, 2, 3, etc.
-When it is optional, whether to provide the data in the locking or unlocking script depends on
-use cases. A general rule is that if the data is available or known at the time of creating the
-locking script, then they can be included in the locking script. Another aspect to consider is the
-size of the transaction and its spending transaction. By shifting the data between the locking
-and unlocking script, one can shift some of the transaction fee cost between the senders of the
-two transactions.
-Note that when we say infeasible due to circular references, the granularity is set at date fields.
-For example, partial locking script or even a small part of a transaction ID (e.g., fixing the first
-two bytes of a 32-byte transaction ID and allow iterations through some fields in a serialised
-transaction) can be fixed in the locking script if required.
-As mentioned earlier, although the focus is to construct the message 𝑚, the goal is to use 𝑚 to
-enforce values on different fields in the spending transaction. To enforce the data behind the
-hash values, i.e., item 9, the locking script should be designed to request the pre-image, hash
-WP1605
-© nChain Licensing AG
-6 of 25PUSHTX and Its Building Blocks
-them in-script, and then construct the message to be signed in-script. Taking item 9 as an
-example, to enforce the outputs in the current transaction, we can have
-[outputsRequest]:= OP_DUP OP_HASH256 OP_ROT OP_SWAP OP_CAT <item 10 and
-11> OP_CAT
-Input data: <item 1 to 8> <serialised outputs in current transaction>
-Remarks
-1. The script segment [outputsRequest] takes item 1 to 8 and the serialised outputs
-on the stack to construct item 9, and concatenate with item 10 and 11 to obtain the
-message 𝑚 in-script. By calling [sign] <𝐺𝑥 > OP_CHECKSIGVERIFY after
-[outputsRequest] and passing the verification, one can be convinced that the
-serialised outputs left on the top of the stack is a true representation of the outputs in
-the current transaction.
-2. It is also very useful to leave a copy of <item 1 to 7> on the stack for comparison.
-This can be achieved by modifying the script segment as below.
-[outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <item 8> OP_CAT
-OP_SWAP OP_CAT <item 10 and 11> OP_CAT
-Input data: <item 1 to 7> <serialised outputs in current
-transaction>
-After executing the modified [outputsRequest] on the input data, we can call
-[sign] <𝐺𝑥 > OP_CHECKSIGVERIFY to consume the message. The stack will have the
-current serialised outputs on the top followed by <item 1 to 7>. We will use the
-modified script segment later to enforce the output in a spending transaction.
-3. It is simpler if consecutive items are grouped together as in <item 1 to 7>. They are
-either all in an unlocking script or all fixed in a locking script. However, a more granular
-approach is available at a potential cost of having a more complex script.
-Note that the serialisation format for current outputs is
-a. value of the output 8 bytes (little endian),
-b. length of the locking script,
-c. the locking script, and
-d. concatenate serialised outputs in order if there is more than one output.
-The serialisation format for previous output (item 5 to 7) in a signed message is
-a. length of the locking script,
-b. the locking script, and
-c. value of the output 8 bytes (little endian).
-In the following example, we will compare the previous output with the output in the current
-spending transaction and force them to be identical. The two formats will be useful for
-designing the locking script for the comparison.
-WP1605
-© nChain Licensing AG
-7 of 25PUSHTX and Its Building Blocks
-1.3 Example of a PELS
-Suppose that Alice is a root Certificate Authority (CA) and Bob is a subordinate CA. Alice is going
-to delegate some work to Bob which would require Bob to publish transactions on-chain as
-attestations to certificates. Alice does not want Bob to spend the output on anything else.
-Therefore, Alice is going to force all the subsequent spending transactions to have a fixed
-[P2PKH Bob] locking script and a fixed output value. Bob can spend the output as he can
-generate valid signatures, but he cannot choose any output other than sending the same
-amount to himself. For illustration purpose and simplicity, we ignore OP_RETURN payload
-throughout the example.
-Alice constructs the initial transaction as shown below.
-𝑇𝑥𝐼𝐷0
-Version1Locktime0
-In-count1Out-count1
-Input list
-Output list
-OutpointUnlocking scriptnSeqValueLocking script
-𝑂𝑢𝑡𝑝𝑜𝑖𝑛𝑡𝐴< 𝑆𝑖𝑔𝐴 >
-< 𝑃𝐾𝐴 >FFFFFFFF1000[outputsRequest][sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8
-OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP
-OP_HASH160 <𝐻(𝑃𝐾𝐵 )> OP_EQUALVERIFY OP_CHECKSIG
-Figure 1 - Initial transaction that contains a PELS output
-The script segments are defined as:
-[outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <item 8> OP_CAT OP_SWAP
-OP_CAT <item 10 and 11> OP_CAT
-[sign]:= OP_HASH256 𝐺𝑥 OP_ADD 𝑛 OP_MOD [toDER] SIGHASH_FLAG OP_CAT
-𝐺𝑐𝑜𝑚𝑝𝑟𝑒𝑠𝑠𝑒𝑑
-[toDER]:= [toCanonical][concatenations]
-[toCanonical]1:= OP_DUP 𝑛/2 OP_GREATERTHAN OP_IF 𝑛 OP_SWAP OP_SUB OP_ENDIF
-[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT
-<0220||𝐺𝑥 ||02> OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-Note that “OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8 OP_SPLIT OP_SWAP OP_CAT
-OP_EQUALVERIFY” is to extract the previous output from the signed message (verified and left
-on the top of the stack), then swap the position of the value field and the locking script to form
-the expected current output, and finally compare it with the actual current output provided in
-the unlocking script and its integrity is implied by the integrity of the signed message.
-The length of the locking script is roughly
-1
-This is to make sure that 𝑠 is in the range between 0 and 𝑛/2. If 𝑠 > 𝑛/2, we let 𝑠 = 𝑛 − 𝑠.
-WP1605
-© nChain Licensing AG
-8 of 25PUSHTX and Its Building Blocks
-(7 + 12) + (6 + 32 + 32 + 33) + (6 + 32 + 32) + (11) + (15 + 34) + (14 + 20)
-= 286 = 0𝑥011𝑒.
-Note that these numbers are not meant to be precise, but they should be accurate enough to
-be in the right magnitude. For a more accurate result, please refer to Appendix.
-To spend the transaction, Bob creates the spending transaction as below.
-𝑇𝑥𝐼𝐷1
-Version1Locktime0
-In-count1Out-count1
-Input list
-OutpointUnlocking script
-𝑇𝑥𝐼𝐷0 ||0< 𝑆𝑖𝑔𝐵 >
-< 𝑃𝐾𝐵 >
-< 𝐷𝑎𝑡𝑎1 >
-< 𝐷𝑎𝑡𝑎2 >
-Output list
-nSeq
-FFFFFFFF
-ValueLocking script
-1000[outputsRequest][sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8
-OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP
-OP_HASH160 <H(PK_B)> OP_EQUALVERIFY
-OP_CHECKSIG
-Figure 2 - spending the PELS output
-The unlocking script contains a data element 𝐷𝑎𝑡𝑎1 which represents items 1 to 7 and can be
-written as:
-010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763
-bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044𝑇𝑥𝐼𝐷0 00000
-000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT
-OP_NIP OP_SWAP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP
-OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}e803000000000000
-Table 2 - Data element 𝑑𝑎𝑡𝑎1 explained
-ItemsValue
-1version01000000
-2Hash of input outpoints2268f59280bdb73a24aae224a0b30c1f60b8a3868
-13d63214f86b98261a6b876
-3Hash of input sequence
-numbers3bb13029ce7b1f559ef5e747fcac439f1455a2ec7
-c5f09b72290795e70665044
-4Input outpoint𝑇𝑥𝐼𝐷000000000
-5Length of previous locking script011e
-WP1605
-© nChain Licensing AG
-9 of 25PUSHTX and Its Building Blocks
-6Previous locking script{[outputsRequest] [sign]
-OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT
-OP_NIP OP_SWAP OP_8 OP_SPLIT OP_SWAP
-OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160
-<H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
-7Value of previous locking scripte803000000000000
-The data element 𝐷𝑎𝑡𝑎2 represents the output in 𝑇𝑥𝐼𝐷1 (value || locking script length || locking
-script) and can be written as:
-e803000000000000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP
-<0x68> OP_SPLIT OP_NIP OP_SWAP OP_8 OP_SPLIT OP_SWAP OP_CAT
-OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
-The full script to be executed during the validation of 𝑇𝑥𝐼𝐷1 is
-< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > < 𝐷𝑎𝑡𝑎2 > [outputsRequest] [sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8 OP_SPLIT OP_SWAP OP_CAT
-OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG
-After the first OP_CHECKSIGVERIFY, we will have < 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > < 𝐷𝑎𝑡𝑎2 > on
-the stack (rightmost on the top).
-Table 3 - Stack execution
-StepThe stackTo execute
-1< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > < 𝐷𝑎𝑡𝑎2 >OP_SWAP <0x68>
-2< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎2 > < 𝐷𝑎𝑡𝑎1 > <0x68>OP_SPLIT OP_NIP
-3< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎2 >
-<011e
-{[outputsRequest] [sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8
-OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY
-OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY
-OP_CHECKSIG}
-e803000000000000>OP_SWAP OP_8 OP_SPLIT
-4< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎2 >
-<011e
-{[outputsRequest] [sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8
-OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFYOP_SWAP OP_CAT
-WP1605
-© nChain Licensing AG
-10 of 25PUSHTX and Its Building Blocks
-OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY
-OP_CHECKSIG}
-e803000000000000>
-<e803000000000000>
-<011e
-{[outputsRequest] [sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8
-OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY
-OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY
-OP_CHECKSIG}>
-5< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎2 >
-<011e
-{[outputsRequest] [sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8
-OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY
-OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY
-OP_CHECKSIG}
-e803000000000000>
-<011e
-{[outputsRequest] [sign] OP_CHECKSIGVERIFY
-OP_SWAP <0x68> OP_SPLIT OP_NIP OP_SWAP OP_8
-OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY
-OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY
-OP_CHECKSIG}
-e803000000000000>OP_EQUALVERIFY
-6< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 >OP_DUP OP_HASH160
-<H(PK_B)>
-OP_EQUALVERIFY
-OP_CHECKSIG
-7True
-The size of 𝑇𝑥𝐼𝐷1 is
-𝑣𝑒𝑟𝑠𝑖𝑜𝑛 + 𝑙𝑜𝑐𝑘𝑡𝑖𝑚𝑒 + 𝑖𝑛𝑝𝑢𝑡 + 𝑜𝑢𝑡𝑝𝑢𝑡
-= 4 + 4 + (36 + 72 + 33 + 104 + 287 + 8 + 287 + 8 + 4) + (8 + 287)
-= 1142 bytes.
-Transaction Fee
-Given the current setting, Bob can add his own input to cover the transaction fee. If Alice uses
-SIGHASH_SINGLE|ANYONECANPAY in the script segment [sign], then Bob can add another
-output to collect changes. This effectively makes the enforcement from Alice’s locking script
-perpetual. One can think of this as a node-enforced smart contract between Alice and Bob.
-It is also possible for the locking script to take the transaction fee into consideration. After step
-3, the top element on the stack is the value from the previous output. By adding <𝑇𝑥𝐹𝑒𝑒>
-OP_SUB before the concatenation in step 4, Alice allows Bob to pay the transaction fee from the
-previous output. This will lead to diminishing value of the output over spends, which can act as
-a desired feature as it sets the total number of spends Bob are entitled to.
-WP1605
-© nChain Licensing AG
-11 of 25PUSHTX and Its Building Blocks
-1.4 Optimisation
-As 𝐷𝑎𝑡𝑎1 contains 𝐷𝑎𝑡𝑎2 , we can construct 𝐷𝑎𝑡𝑎2 from 𝐷𝑎𝑡𝑎1 . In other words, we assume that
-the current output is identical to the previous output and use the previous output to construct
-the message. If it passes OP_CHECKSIG, then the two outputs must be identical. The script
-segment of [outputsRequest] can be re-written as:
-[outputsRequest]:= OP_2DUP OP_CAT OP_TOALTSTACK OP_SWAP OP_CAT OP_HASH256
-<item 8> OP_SWAP OP_CAT OP_FROMALTSTACK OP_SWAP OP_CAT OP_CAT <item 10
-and 11> OP_CAT
-Input data: <item 1 to 4> <item 5 and 6> <item 7>
-With this new [outputsRequest], we can update the locking script in 𝑇𝑥𝐼𝐷0 and 𝑇𝑥𝐼𝐷1 as:
-[outputsRequest][sign] OP_CHECKSIGVERIFY OP_DUP OP_HASH160 <H(PK_B)>
-OP_EQUALVERIFY OP_CHECKSIG
-and the unlocking script as:
-< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > < 𝐷𝑎𝑡𝑎2 > < 𝐷𝑎𝑡𝑎3 >
-where 𝐷𝑎𝑡𝑎1 is item 1 to 4:
-010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb
-13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044𝑇𝑥𝐼𝐷000000000
-𝐷𝑎𝑡𝑎2 is item 5 and 6:
-011b{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT
-OP_NIP OP_SWAP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP
-OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
-𝐷𝑎𝑡𝑎3 is item 7: e803000000000000.
-The size of 𝑇𝑥𝐼𝐷1 is 941 bytes. A step-by-step execution is given below, where Step 1 to 5 is
-from [outputsRequest].
-Table 4 - Stack execution with optimisation
-StepThe stacksTo execute
-1< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > < 𝐷𝑎𝑡𝑎2 > < 𝐷𝑎𝑡𝑎3 >OP_2DUP OP_CAT
-OP_TOALTSTACK
-WP1605
-© nChain Licensing AG
-12 of 25PUSHTX and Its Building Blocks
-2< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > < 𝐷𝑎𝑡𝑎2 > < 𝐷𝑎𝑡𝑎3 >
-ALTSTACK: <item 5 to 7>OP_SWAP OP_CAT
-OP_HASH256
-3< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > <item 9>
-ALTSTACK: <item 5 to 7><item 8> OP_SWAP
-OP_CAT
-4< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > <item 8 and 9>
-ALTSTACK: <item 5 to 7>OP_FROMALTSTACK
-OP_SWAP OP_CAT
-5< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > < 𝐷𝑎𝑡𝑎1 > <item 5 to 9>OP_CAT <item 10 and
-11> OP_CAT
-6< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 > <item 1 to 11>[sign]
-OP_CHECKSIGVERIFY
-7< 𝑆𝑖𝑔𝐵 > < 𝑃𝐾𝐵 >OP_DUP OP_HASH160
-<H(PK_B)>
-OP_EQUALVERIFY
-OP_CHECKSIG
-8True
-Further improvement can be made by using the alt stack for storing 𝐺𝑥 and 𝑛. Each of them is
-𝑛
-of size 32 bytes. As 𝐺𝑐𝑜𝑚𝑝𝑟𝑒𝑠𝑠 is 𝐺𝑥 and 2 can be derived from 𝑛, we can use several opcodes to
-reference them from the alt stack. However, it would introduce complications when designing
-the script. For example, a comparison of two versions of [sign] is shown below.
-Before:
-[sign]:= OP_HASH256 𝐺𝑥 OP_ADD 𝑛 OP_MOD [toDER] SIGHASH_FLAG OP_CAT 𝐺𝑥
-[toDER]:= [toCanonical][concatenations]
-[toCanonical]:= OP_DUP 𝑛/2 OP_GREATERTHAN OP_IF 𝑛 OP_SWAP OP_SUB OP_ENDIF
-[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT
-<0220||G_x> OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-WP1605
-© nChain Licensing AG
-13 of 25PUSHTX and Its Building Blocks
-After:
-[sign]:= OP_HASH256 𝐺𝑥 OP_DUP OP_TOALTSTACK OP_ADD 𝑛 OP_DUP OP_TOALTSTACK
-OP_MOD [toDER] SIGHASH_FLAG OP_CAT OP_FROMALTSTACK
-[toDER]:= [toCanonical][concatenations]
-[toCanonical]:= OP_DUP OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_2 OP_DIV
-OP_GREATERTHAN OP_IF OP_FROMALTSTACK OP_SWAP OP_SUB OP_ENDIF
-[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT
-<0220> OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_CAT OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT
-We added 15 opcodes and removed two instances of 𝐺𝑥 and two instances of 𝑛. The total saving
-is (32 × 2 + 32 × 2) − 15 = 113 bytes. Therefore, the size of the spending transaction 𝑇𝑥𝐼𝐷1 can
-be further reduced to 828 bytes.
-It is safe to say that with all available optimisations, the size of a spending transaction can be
-around 1KB.
-Note that any example scripts shown above are not meant to be used in mainnet transactions.
-They are written for illustration purpose. Some simplifications are implicitly assumed. For
-example, reversing endianness is omitted. For a more practical and comprehensive guide,
-please refer to Appendix.
-WP1605
-© nChain Licensing AG
-14 of 25PUSHTX and Its Building Blocks
-2
-Security Analysis
-In this section, we offer some security proofs and analysis around PUSHTX. This is considered a
-formal approach to PUSHTX and some of the insights we described in the previous section.
-First of all, we notice that there are effectively two signatures in the script execution. One is
-created by PUSHTX technique, the other one is provided in the unlocking script for P2PKH. The
-first signature provides data integrity and enables enforcement on the spending transaction,
-while the second provides authenticity and ensure that only the intended recipient can create
-the spending transaction2.
-Claim 1:
-If (𝑟, 𝑠) is a valid ECDSA signature with respect to a public key 𝑃 on the messages 𝑚,
-then it is computationally infeasible to construct 𝑚 ′ such that 𝑚 ′ ≠ 𝑚 and (𝑟, 𝑠) is
-still valid on 𝑚 ′ with respect to 𝑃, assuming that the cryptographic hash function
-used is pre-image resistant and collision resistant.
-Proof:
-let 𝑧 = ℎ𝑎𝑠ℎ(𝑚) and 𝑧 ′ = ℎ𝑎𝑠ℎ(𝑚 ′) for some 𝑚 ′.
-Let 𝑢 = 𝑧𝑠 −1 𝑚𝑜𝑑 𝑛 , 𝑢′ = 𝑧 ′ 𝑠 −1 𝑚𝑜𝑑 𝑛, 𝑣 = 𝑟𝑠 −1 𝑚𝑜𝑑 𝑛, and 𝑅 = 𝑘𝐺 where
-𝑅𝑥 = 𝑟 𝑚𝑜𝑑 𝑛.
-Also let 𝑅′ denote the points such that 𝑅′ ≠ 𝑅 and 𝑅𝑥′ = 𝑟 𝑚𝑜𝑑 𝑛.
-Note that3 𝑅′ can either be −𝑅 or one of the two points, (𝑥, ±𝑦),
-where 𝑥 = 𝑅𝑥 + 𝑛 if 𝑅𝑥 < 𝑛 and 𝑥 = 𝑅𝑥 − 𝑛 if 𝑅𝑥 > 𝑛.
-So, from the signature verification, we have [𝑢𝐺 + 𝑣𝑃]𝑥 = [𝑢′ 𝐺 + 𝑣𝑃]𝑥 = 𝑟 𝑚𝑜𝑑 𝑛.
-There are two cases to consider.
-Case 1: 𝑢𝐺 + 𝑣𝑃 = 𝑢′ 𝐺 + 𝑣𝑃 = 𝑅
- 𝑢 = 𝑢′ 𝑚𝑜𝑑 𝑛
- 𝑧 = 𝑧 ′ 𝑚𝑜𝑑 𝑛
- 𝑚 = 𝑚 ′ under the assumption that the hash function is collision
-resistant.
-Case 2: 𝑢𝐺 + 𝑣𝑃 = 𝑅 and 𝑢′ 𝐺 + 𝑣𝑃 = 𝑅′
- 𝑢′ 𝐺 = 𝑅′ − 𝑣𝑃
- Given that the message 𝑚, the public 𝑃, and the value 𝑟 are all fixed,
-there are maximum three different values that 𝑢′ can take, each of which
-corresponds to a value of 𝑅′.
-In some use cases where authenticity is not required and it is desired to have anyone
-being able to create a spending transaction, the script segment P2PKH can be omitted.
-However, any implications and risks should be analysed and assessed before such
-approach.
-3
-On secp256k1 curve, the group order 𝑛 is less than the curve modulo 𝑝, but they are of
-the same bit length. Therefore, an equation 𝑥 = 𝑎 𝑚𝑜𝑑 𝑛 will have maximum two solutions
-for 𝑥 ∈ [0, 𝑝 − 1]. The maximum number of solutions can only be achieved when 𝑎 ∈ [0, 𝑝 −
-𝑛).
-2
-WP1605
-© nChain Licensing AG
-15 of 25PUSHTX and Its Building Blocks
- 𝑧 ′ = 𝑢′ 𝑠 also has maximum three values.
- Finding 𝑚 ′ such that ℎ𝑎𝑠ℎ(𝑚 ′ ) = 𝑧 ′ where 𝑧 ′ can only be one of the three
-fixed values is computationally infeasible assuming that the hash
-function is pre-image resistant.
-Therefore, we can conclude that it is computationally infeasible to find 𝑚 ′ such that
-𝑚 ′ ≠ 𝑚 and (𝑟, 𝑠) is still valid on 𝑚 ′ with respect to 𝑃.
-Note that Claim 1 implies that PUSHTX technic is secure to use if we assume that double
-SHA256 is preimage resistant and collision resistant. Moreover, it implies that the data integrity
-is preserved even when we sacrifice authenticity in ECDSA by making both the private key and
-the ephemeral key available to the public.
-Claim 2:
-Public key 𝑃 must be fixed in the locking script.
-Reasoning:
-Suppose 𝑃 is not fixed and (𝑟, 𝑠) is a valid signature with respect to 𝑃 on 𝑚.
-Let 𝑧 ′ = ℎ𝑎𝑠ℎ(𝑚 ′ ). 𝑢′ = 𝑧 ′ 𝑠 −1 , and 𝑣 = 𝑟𝑠 −1
-We want to find 𝑃′ such that 𝑢′ 𝐺 + 𝑣𝑃 ′ = 𝑅
-𝑃 ′ = 𝑣 −1 (𝑅 − 𝑢′ 𝐺)
-Now (𝑟, 𝑠) is valid with respect to 𝑃 ′ on 𝑚′.
-Therefore 𝑃 must be fixed in the locking script.
-Claim 3:
-𝑘 should be fixed in the locking script.
-Reasoning:
-Suppose (𝑟, 𝑠) is a valid signature generated in the locking script with respect to 𝑃
-on 𝑚.
-Suppose 𝑘 is not fixed in the locking script and is provided in the unlocking script.
-Then an adversary can:
-1.intercept the spending transaction, and
-2.replace 𝑘 with 𝑘′ in the unlocking script.
-Then (𝑟 ′ , 𝑠 ′ ) generated in the locking script will be a valid signature with respect to
-𝑃 on 𝑚.
-Transaction will still be valid, but the transaction ID is changed.
-Claim 4:
-Sighash flag should be fixed in the locking script.
-Reasoning:
-Suppose (𝑟, 𝑠) is a valid signature generated in the locking script with respect to 𝑃
-on 𝑚.
-Suppose sighash flag is not fixed in the locking script and is provided in the
-unlocking script.
-1.
-WP1605
-Intercept the spending transaction
-© nChain Licensing AG
-16 of 25PUSHTX and Its Building Blocks
-2.Change the sighash flag
-3.Update the message 𝑚 accordingly to 𝑚 ′.
-In some use case, this would invalidate the transaction. E.g., the locking script
-expects multiple inputs and outputs with sighash flag “ALL”; changing the flag to
-anything else would invalidate the script execution.
-In others, this would change the transaction ID without invalidating the transaction.
-E.g., the locking script only enforces conditions on the outputs of its spending
-transaction; adding or removing “ANYONECANPAY” would not invalidate the
-transaction, but will change the transaction ID.
-WP1605
-© nChain Licensing AG
-17 of 25PUSHTX and Its Building Blocks
-3
-Appendix
-All implementations have been tested on regtest on Bitcoin SV v1.0.8. Please be warned that the
-scripts below are for testing purpose only. Any attempt of using them on mainnet should
-undergo thorough testing and rigorous reviews.
-The result shows that a spending transaction is of size 1415 bytes. The overhead is mainly
-coming from reversing endianness. A 32-byte string would require 124 bytes of opcodes to
-reverse its endianness. We need to reverse endianness twice in the locking script. The locking
-script appears both in the unlocking script and the output in the spending transaction.
-Therefore, the total overhead from endianness in our implementation is over 500 bytes. We did
-not use Alt Stack to store 𝐺𝑥 and 𝑛 in our current implementation for simplicity. This would save
-us about 200 bytes in total.
-We present two example locking scripts first and explain what they do. We then present two
-transactions with one spending the other using the second locking script, demonstrating that
-the locking script works and can be spent as expected.
-Locking Script 1 (LS1) – generateSig and checkSig
-"aa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f51
-7f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b0
-2070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeff
-ffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafefff
-fffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafe
-ffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517
-f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f
-517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbba
-c55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279
-be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac"
-Input: serialised transaction message for signing as in Section 1.2
-The locking script takes the message 𝑚, and
-1. double SHA256 on 𝑚 to obtain 𝑧,
-2. reverse endianness of 𝑧,
-3. add 0x00 to ensure 𝑧 is not interpreted as a negative number,
-4. call OP_BIN2NUM to have minimal encoding on 𝑧 (would take care the case when step
-3 introduces redundancy),
-5. compute 𝑠 = 𝑧 + 𝐺𝑥 𝑚𝑜𝑑 𝑛,
-6. convert 𝑠 to 𝑛 − 𝑠 if 𝑠 > 𝑛/2,
-7. obtain length of 𝑠,
-8. reverse endianness of 𝑠 (32 bytes),
-9. reverse one more byte if the length of 𝑠 is greater than 32,
-10. compute the total length of a DER signature (0x24 + 𝑙𝑒𝑛𝑔𝑡ℎ 𝑜𝑓 𝑠),
-11. add DER prefix 0x30,
-12. concatenate 𝑟 = 𝐺𝑥 ,
-WP1605
-© nChain Licensing AG
-18 of 25PUSHTX and Its Building Blocks
-13. concatenate 𝑠,
-14. concatenate sighash flag “ALL”,
-15. push compressed public key 𝐺𝑥 , and
-16. call OP_CHECKSIG.
-Note that in step 7 to 9, we have assumed that the length of 𝑠 is either 32 or 33 bytes. However,
-𝑠 may be shorter than that. Some care should be taken to pad 𝑠 using OP_NUM2BIN if it is too
-short.
-Locking Script 2 (LS2) – constructMsg + LS1 + P2PKH
-"6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f
-517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f5
-17f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce95
-62a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafefffffffffffff
-fffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffff
-ffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafefffffffffff
-fffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f51
-7f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517
-f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce
-870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcb
-bac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196
-d454941c45d1b3a323f1433bd688ac"
-Input: <𝑆𝑖𝑔> <𝑃𝐾> <Item 1 to 4> <Item 5 and 6> <Item 7>
-The locking script takes a pair of signature and public key, and item 1 to 7 as in the table in
-Section 1.2 in three PUSHDATA operations, and
-1.
-take the previous value and work out the new output value (subtracting a fixed
-transaction fee),
-2. take the previous locking script as the new locking script for the new output,
-3. concatenate the new output value and new locking script to obtain the new output,
-4. double SHA256 the new output to obtain the hash of outputs (item 9),
-5. push sequence number (item 8),
-6. concatenate to get message string (item 1 to 9),
-7. push locktime and sigahash flag (item 10 and 11),
-8. concatenate to obtain the message to be signed 𝑚,
-9. call LS1 with OP_CHECKSIGVERIFY, and
-10. call P2PKH to check 𝑆𝑖𝑔 with respect to 𝑃𝐾.
-Transaction 0 – genesis transaction
-{
-"txid":
-"88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
-"hash":
-"88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
-"version": 1,
-"size": 730,
-"locktime": 0,
-WP1605
-© nChain Licensing AG
-19 of 25PUSHTX and Its Building Blocks
-"vin": [
-{
-"txid":
-"52685bdbaae5c76887c23cee699bc48f293192a313c19b9fad4c77b993655df5",
-"vout": 0,
-"scriptSig": {
-"asm":
-"3044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
-02201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a5[ALL|
-FORKID]
-0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
-"hex":
-"473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817
-9802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a5412
-10279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798"
-},
-"sequence": 4294967295
-}
-],
-"vout": [
-{
-"value": 49.99999388,
-"n": 0,
-"scriptPubKey": {
-"asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT
-OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT
-0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM
-9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD
-414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD
-OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00
-2 OP_DIV OP_GREATERTHAN OP_IF
-414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00
-OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF
-WP1605
-© nChain Licensing AG
-20 of 25PUSHTX and Its Building Blocks
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE
-OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT
-022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT
-0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
-OP_CHECKSIGVERIFY OP_DUP OP_HASH160
-751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
-"hex":
-"6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f
-517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f5
-17f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce95
-62a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafefffffffffffff
-fffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffff
-ffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafefffffffffff
-fffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f51
-7f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517
-f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce
-870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcb
-bac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196
-d454941c45d1b3a323f1433bd688ac",
-"type": "nonstandard"
-}
-}
-],
-"hex":
-"0100000001f55d6593b9774cad9f9bc113a39231298fc49b69ee3cc28768c7e5aadb5b68
-52000000006a473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f
-2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9
-f25900a541210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f
-81798ffffffff019cef052a01000000fd32026e810200029458807c7eaa04ffffffff7c7e
-7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f5
-17f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f51
-7f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8
-165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5
-ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5e
-d2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08
-c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b51
-7f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517
-f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e
-WP1605
-© nChain Licensing AG
-21 of 25PUSHTX and Its Building Blocks
-7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e6882760124930130
-7c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179
-8027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959
-f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac0000000
-0"
-}
-Transaction 1 – spending transaction
-{
-"txid":
-"c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8",
-"hash":
-"c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8",
-"version": 1,
-"size": 1415,
-"locktime": 0,
-"vin": [
-{
-"txid":
-"88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
-"vout": 0,
-"scriptSig": {
-"asm":
-"3044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
-0220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed34[ALL|
-FORKID]
-0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
-01000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13
-bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8
-bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b98800000000
-fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517
-f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f
-517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b8
-7ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffff
-ffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafefffffffff
-fffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffff
-ffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f5
-17f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f51
-7f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06
-295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667e
-f9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e81
-99196d454941c45d1b3a323f1433bd688ac 9cef052a01000000",
-"hex":
-"473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817
-980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed34412
-10279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817984c6801
-WP1605
-© nChain Licensing AG
-22 of 25PUSHTX and Its Building Blocks
-000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13bb
-13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8bc
-b75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b988000000004d3502fd32026
-e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f51
-7f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517
-f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562
-a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafefffffffffffffff
-fffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffff
-ffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafefffffffffffff
-fffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f
-517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f5
-17f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7
-e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce87
-0b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbba
-c55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d4
-54941c45d1b3a323f1433bd688ac089cef052a01000000"
-},
-"sequence": 4294967295
-}
-],
-"vout": [
-{
-"value": 49.99998876,
-"n": 0,
-"scriptPubKey": {
-"asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT
-OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT
-0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM
-9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD
-414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD
-OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00
-2 OP_DIV OP_GREATERTHAN OP_IF
-414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00
-OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-WP1605
-© nChain Licensing AG
-23 of 25PUSHTX and Its Building Blocks
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1
-OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
-OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE
-OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT
-022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802
-OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT
-0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
-OP_CHECKSIGVERIFY OP_DUP OP_HASH160
-751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
-"hex":
-"6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f
-517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f5
-17f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce95
-62a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafefffffffffffff
-fffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffff
-ffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafefffffffffff
-fffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f51
-7f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517
-f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce
-870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcb
-bac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196
-d454941c45d1b3a323f1433bd688ac",
-"type": "nonstandard"
-}
-}
-],
-"hex":
-"010000000134ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b9
-8800000000fd1503473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d
-959f2815b16f817980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf506
-35800219ed3441210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815
-b16f817984c6801000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32
-d22bcc051ce13bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665
-04434ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b988000000
-004d3502fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e08000000004100000
-07eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f
-517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7
-c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-WP1605
-© nChain Licensing AG
-24 of 25PUSHTX and Its Building Blocks
-7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9
-b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafe
-ffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafef
-fffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaeba
-feffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f5
-17f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f51
-7f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcb
-bac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e2102
-79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a9147
-51e76e8199196d454941c45d1b3a323f1433bd688ac089cef052a01000000ffffffff019c
-ed052a01000000fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e08000000004
-10000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f51
-7f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7
-e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e
-7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2
-ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dc
-aebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dca
-ebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6
-dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517
-f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f
-517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7
-c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c
-7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667
-ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e0141
-7e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad7
-6a914751e76e8199196d454941c45d1b3a323f1433bd688ac00000000"
-}
-WP1605
-© nChain Licensing AG
-25 of 25