Electronic Document Signature

Abstract

According to a first aspect, there is provided a computer-implemented method for cryptographically linking multiple documents having multiple electronic signature requirements via a sequence of blockchain transactions, the method comprising: calculating document signature data that satisfies a first signature requirement for a pre-existing document, the first signature requirement being defined in a blockchain transaction that includes or references the pre-existing document; the document signature data signing a portion of a linking transaction that includes or references a supplemental document, the linking transaction including an input for validating a usable output of the blockchain transaction, whereby the document signature cryptographically links the supplemental document to the pre-existing document; the signed portion including multiple outputs of the linking transaction; a first output of the multiple signed outputs is usable and associated with the pre-existing document; the signed portion defining a second signature requirement for the pre-existing document; and a second output of the multiple signed outputs is usable and associated with the supplemental document, the signed portion defining the signature requirement for the supplemental document.

Description

[Technical Field]

[0001] The present disclosure relates to electronic document signing, and in particular to systems and methods for applying cryptographically verifiable digital signatures to multiple interrelated documents having multiple signature requirements that change over time, and for robustly recording those signatures. [Background technology]

[0002] An actor's signature is often required to approve a document or as confirmation of agreement or receipt. Traditionally, a hard copy of the document is signed and, if necessary, sent by mail or electronically. Recently, electronic signatures, or e-signatures, have become more popular. Electronic signatures allow parties to sign documents electronically without the need to obtain a hard copy of the document.

[0003] There are many different types of signatures that can be loosely described as "electronic." These include scanned images of an entity's signature, handwritten signatures generated on a tablet or other electronic writing device, typed names, video signatures, and checkboxes that an entity checks to indicate consent. Such signatures may include additional information, such as a timestamp indicating when the actor provided the signature and / or the location of the party at the time of signing.

[0004] In contrast, digital signatures, which utilize modern cryptographic principles, are much more reliable and secure. A digital signature is a cryptographic mechanism for employing electronic signatures, and unless otherwise indicated, references herein to electronic signatures, document signatures, etc. refer to digital signatures in this sense. The presence of a valid signature confers upon receipt of a signed document assurance that the document was sent by a known sender and was not altered in transit. As such, digital signatures are frequently used when detection of forgery or tampering is important.

[0005] Digital signature schemes use the private and public keys of the parties involved to sign a document and validate the signature, with the two keys cryptographically linked. The private key is used to generate a signature that can be verified by anyone who possesses the corresponding public key. The signature is typically generated based on a cryptographic hash of the document being signed. If the document is altered after it has been signed, it will no longer match the cryptographic hash of the signature, and therefore the signature will become invalid with respect to the altered document.

[0006] It is virtually impossible to forge a signature without access to the signer's private key. Digital signatures can therefore provide non-repudiation: a signer cannot successfully claim that they did not provide the signature while still claiming that their private key is secret. Either the private key is no longer secret and the signature was provided by a third party with access to the private key, or the signer provided their own signature. Summary of the Invention

[0007] The strong cryptographic mechanisms underpinning digital signatures arguably make them more secure than traditional document signatures. However, a barrier to the more widespread use of digital signatures for document signing is the lack of an equally robust system for tracking and recording electronic signatures applied to documents.

[0008] This is exacerbated if the signature requirements for a document change during its validity period and / or the document needs to be amended or updated. For example, the parties authorized to sign a document may change at different points in the document's validity period. Who is authorized may depend on several factors. For example, there may be a sequential list of parties allowed to sign, and a party may only sign a document if the previous party in the list has already signed. As another example, a party may only be allowed to sign if they or another party has performed a specific task.

[0009] This becomes even more complicated when multiple signed documents need to be linked. For example, when a particular party applies a signature to a primary document, it may depend on one or more supporting documents. Such supporting documents may not necessarily exist at the time the primary document was created, so there needs to be the ability to link different documents at different points in time; that is, not limited to linking documents by the time they were created.

[0010] It is therefore desirable to provide document signing techniques that can facilitate more complex signature requirements. In particular, it is desirable to provide systems and methods for applying cryptographically verifiable digital signatures to multiple interrelated documents that may have been created at different times, may change over time, and may have multiple signature requirements that must be satisfied by multiple parties in a specific order. Furthermore, it is desirable to provide a system for robustly recording the same in a manner that ensures consistency among all parties.

[0011] This disclosure recognizes that a blockchain data structure provides an ideal framework for implementing the above requirements. A blockchain provides a continuous record of transactions, and each new blockchain transaction is recorded on the blockchain, contingent on certain requirements being met. Here, the continuous nature of the blockchain data structure is utilized to add new signature requirements to existing documents that must be met in a specific order. Document signing requirements are defined in the spendable outputs of a blockchain transaction, and multiple documents can be linked together in a cryptographically verifiable manner by linking transactions with multiple spendable outputs while simultaneously defining new signature requirements.

[0012] According to certain aspects disclosed herein, there is provided a computer-implemented method for cryptographically linking multiple documents having multiple electronic signature requirements via a sequence of blockchain transactions, the method comprising: calculating document signature data that satisfies first signature requirements for the existing document, the first signature requirements being defined in a blockchain transaction that includes or references the existing document; the document signature data signs the portion of the link transaction that includes or references a supplemental document, the link transaction including an input for effectively using the spendable output of the blockchain transaction, whereby the document signature cryptographically links the supplemental document to the existing document; the signed portion includes a plurality of outputs of the link transaction; a first output of the plurality of signed outputs is usable and associated with the pre-existing document, the signed portion defining a second signature requirement for the pre-existing document; A method is provided wherein a second output of the plurality of signed outputs is available and associated with the supplemental document, and the signed portion defines signature requirements for the supplemental document.

[0013] According to a second aspect disclosed herein, there is provided a blockchain link transaction, the link transaction being embodied on a computer-readable medium and including an input for effectively using a usable output of a blockchain transaction that includes or references an existing document, and a plurality of outputs; document signature data signs the portion of the link transaction that includes or references a supplemental document, whereby the document signature cryptographically links the supplemental document to the existing document; the signed portion includes a plurality of outputs of the link transaction; a first output of the plurality of signed outputs is usable and associated with the pre-existing document, the signed portion defining a second signature requirement for the pre-existing document; A second output of the plurality of signed outputs is available and associated with the supplemental document, and a link transaction is provided in which the signed portion defines signature requirements for the supplemental document.

[0014] The framework also facilitates modifying the content or state of a document in a verifiable manner. For example, embodiments of the present invention permit state modification through a state flag included in a signed transaction. In this context, the sequential nature of the blockchain data structure is leveraged as a way to define and satisfy complex document signing requirements, as well as provide an immutable and consistent record of the complete history of changes to the content and / or state of a signed document.

[0015] The technology implementation leverages the transaction validation mechanism used to secure the blockchain to provide additional document signature validation capabilities, where document signatures take the form of transaction signatures for transaction validation, particularly validation of spending relationships between transactions. This has the advantage that the existing work performed by nodes to validate blockchain transactions also serves to validate document signature requirements. [Brief explanation of the drawings]

[0016] To facilitate an understanding of embodiments of the present disclosure, and to show how such embodiments may be carried into effect, reference is made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] 1 shows a schematic diagram of some examples of transactions recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a simplified mock-up of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 2 is a schematic block diagram of specific node software for processing transactions. [Figure 5] FIG. 1 is a schematic diagram of a generic link transaction. [Figure 6] 1 illustrates an exemplary import / export process. [Figure 7] A diagram of a bill of lading. [Figure 8] 1 illustrates an exemplary sequence of use of a bill of lading in an import / export transaction. [Figure 9] 1 illustrates an exemplary sequence for the use of a letter of credit in an import / export transaction. [Figure 10] 1 illustrates schematically how changes to a document are validated both on and off the blockchain. [Figure 11] 1 shows a schematic diagram of a set of transactions for linking documents. DETAILED DESCRIPTION OF THE INVENTION

[0017] Exemplary System Overview A blockchain refers to a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter also referred to as a "blockchain network"). A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction, except for so-called "coinbase transactions," points to the preceding transaction in the sequence. The sequence may span one or more blocks, tracing back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are generated through a process known as "mining." "Mining" involves multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on the presentation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Notably, a blockchain may be pruned at some nodes, and block publication can be achieved through the publication of only the block header.

[0018] Transactions in a blockchain can be used for one or more of the following purposes: carrying digital assets (i.e., multiple digital tokens), ordering a set of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or chronologically ordering index pointers. A blockchain can also be used to place additional functionality on top of it. For example, a blockchain protocol may allow additional user data or indexes to be stored in the data within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction. Thus, more complex data can be incorporated. For example, this could be used to store electronic documents, or audio or video data, within the blockchain.

[0019] Nodes (sometimes called "miners") in the blockchain network perform a distributed transaction registration and validation process, described in detail below. Briefly, during this process, nodes validate transactions, insert them into a block template, and attempt to identify a valid proof-of-work solution for it. Once a valid solution is found, the new block is propagated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network for propagation. Nodes receiving the transaction compete to find a proof-of-work solution and include the validated transaction in a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or included in a block. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) therefore remains registered and indexed at each node in the blockchain network as an immutable public record.

[0020] Nodes that successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that generates a new quantity of digital assets, or tokens. Detection and rejection of invalid transactions is performed by competing nodes, who act as agents of the network and are incentivized to report and prevent illicit activity. Widespread publication of information allows users to continuously audit node performance. By simply publishing block headers, participants can guarantee the ongoing integrity of the blockchain.

[0021] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset derivable from the preceding transaction sequence. A spendable output is sometimes called a UTXO (unspent transaction output). An output may further include a locking script that specifies conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input in a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the pointed-to output's locking script. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input including a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0022] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlock script meets all of one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another, previous, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction) (but may register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0023] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances rather than by referencing back to the UTXO of a previous transaction in the sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain.

[0024] 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled to other blockchain nodes 104.

[0025] Each blockchain node 104 includes a peer computing device, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or other devices such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0026] A blockchain 150 includes a chain of blocks of data 151, each copy of which is maintained at each of multiple nodes 104 in a decentralized or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing an amount of a digital asset as an asset. In this example, the output is cryptographically locked to user 103 (requiring that user's signature or other solution to unlock it and thereby redeem or spend it). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0027] Each block 151 also contains a block pointer 155 that points back to an earlier block 151 in the chain, defining a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a preceding transaction.

[0028] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 across the network 106. Each blockchain node 104 is configured to generate blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is sometimes referred to as a "mempool." This term, as used herein, is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated to not accept other transactions that attempt to use the same output.

[0029] For a given current transaction 152j, the inputs (or each of them) contain a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist when the current transaction 152j was created or sent to the network 106, but a previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to something that precedes in the logical sequence linked by a pointer, and not necessarily to the time of creation or transmission in the chronological order. Thus, it does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0030] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may have multiple inputs and combine amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0031] According to a Bitcoin-like output-based transaction protocol, when an entity 103, such as an individual user or an organization, wants to act on a new transaction 152j (either manually or through an automated process used by a party), the acting entity sends the new transaction from its computer terminal 102 to a recipient. The acting party or recipient eventually sends this transaction to one or more blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but in principle other user terminals are also possible). In some examples, it is not excluded that the party 103 acting on the new transaction 152j can send the transaction directly to one or more blockchain nodes 104 rather than to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such output-based transaction protocols, this may involve checking that a cryptographic signature or other authentication of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152j that the new transaction assigns, which condition typically includes at least checking that the cryptographic signature or other authentication in the input of new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i, or may be simply fixed in the blockchain node protocol, or a combination thereof.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0032] In an output-based model, the definition of whether a given allocated output (e.g., UTXO) is allocated (e.g., spent) is whether it has already been validly redeemed by an input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated to change). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because of the defined order of transactions, account balances have a single, defined state at a time.

[0033] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process called mining, which is underpinned by a "proof-of-work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. This typically involves looking for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0034] A first blockchain node 104 that solves the puzzle notifies the network 106 and provides its solution as a proof. This solution can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the hash output satisfies the conditions). The first blockchain node 104 propagates the block upon agreement of a threshold of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. The new block 151n is also assigned a block pointer 155, pointing to the previously created block 151n-1 in the chain. The significant amount of effort required to generate the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0035] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be solving the puzzle based on different snapshots of the pool of unpublished transactions 154, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, in the order in which the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to produce blocks from the newly defined ordered pool of unpublished transactions 154. There is also a protocol for resolving possible "forks," which occur when two blockchain nodes 104 solve the puzzle within a very short time of each other, causing inconsistent views of the blockchain to propagate between the nodes 104. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both branches.

[0036] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional, approved amount of a digital asset in a new special type of transaction that distributes an additional defined amount of the digital asset (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof-of-work signals that the node that constructed the new block intends to follow protocol rules so that this special transaction can later be redeemed. Blockchain protocol rules may require this special transaction to expire, e.g., 100 blocks, before it can be redeemed. A regular (non-generating) transaction 152 often specifies an additional transaction fee in one of its outputs, further rewarding the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is usually called a "mining fee" and will be explained later.

[0037] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0038] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform one or more respective roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any operation attributed to a blockchain node 104 may be performed by software executing on the processing unit of each computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0039] Also connected to the network 101 are computing devices 102 for each of a number of parties 103 that act as consumer users. These users can interact with the blockchain network but do not participate in validating transactions and constructing blocks. Some of these users or agents may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0040] Some or all of the parties 103 may be coupled as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called "clients") can be said to be part of the system that includes the blockchain network 106. However, these users are not blockchain nodes 104 because they do not perform the required role of a blockchain node. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby coupling (i.e., communicating) with the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 can exist and participate in the system 100, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as "first party" and "second party," respectively.

[0041] Each party's 103 computing device 102 includes a respective processing unit that includes one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's 103 computing device 102 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may include one or more memory units that use one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on each party's 103 computing device 102 stores software, including a respective instance of at least one client application 105, configured to operate on the processing unit. It will be understood that any actions attributed to a party 103 given herein may be performed using software executing on the processing unit of each party's 102 computing device. Each party's 103 computing device 102 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing device 102 of a given party 103 may include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0042] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk, for example a CD or DVD ROM, or removable optical drive.

[0043] The client application 105 has at least a "wallet" functionality, which has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling the amounts defined among the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to that party.

[0044] NOTE: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in two or more different application suites, interfacing, for example, via an API, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

[0045] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part, through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used for all nodes 104 in the network 106.

[0046] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 with the best connection to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0047] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of the blockchain maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the network 106.

[0048] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, the blockchain nodes 104 begin competing to solve a proof-of-work puzzle for the latest version of their respective pools of transactions, including the new transaction 152. (Note that other blockchain nodes 104 attempt to solve the puzzle based on different pools 154 of transactions, but whoever comes first defines the set of transactions included in the latest block 151.) Eventually, the blockchain nodes 104 will solve the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 containing the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Because each transaction 152 consists of a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0049] Different blockchain nodes 104 may initially receive different instances of a given transaction and may therefore have conflicting views of which instances are "valid" before one instance is published into a new block 151, at which point all blockchain nodes 104 agree that only the published instance is the valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not yet published in a block 151).

[0050] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol. In an account-based model, each transaction transfers by referencing an absolute account balance, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in a series of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using an account's sequential transaction record (the so-called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign a transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0051] <UTXOベースのモデル> Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to be limiting to all possible implementations. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0052] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. Among other information, a UTXO may also include the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input and output fields 202 and 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the outstanding transaction 152 submitted to the node 104.

[0053] For example, suppose Alice 103a wants to create transaction 152j to transfer the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of the digital asset locked to Alice and transfers at least a portion of it to Bob in the output 203 of the previous transaction 152i in the sequence. The previous transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could point to any previous (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0054] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least when she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and submitted to the network 106, or Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may be equivalently replaced by "preceding" and "successor," or "ancestor" and "descendant," "parent" and "child," etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or node behavior.

[0055] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the quantity of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the quantity to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to whom the preceding transaction was locked.

[0056] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies the information needed to consume a transaction output 203, e.g., requirements for Alice's signature. An unlock script appears in the transaction output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the lock script. For example, it may include Bob's signature. An unlock script appears in the transaction input 202.

[0057] In the example shown, Tx0's output 203, UTXO0, contains a locking script [ChecksigPA], which requires Alice's signature SigPA in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A ] is the public key P from Alice's public-private key pair. A, a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, in order to distinguish it among any other possible outputs of Tx0. Tx1's input 202 further includes an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <sigpa>The data (or "message") that Alice needs to sign to provide a valid signature may be defined by the lock script, by the node protocol, or by a combination of these.

[0058] When a new transaction Tx1 arrives at a blockchain node 104, the node applies its node protocol, which involves running the lock script and unlock script together to check whether the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts.

number

[0059] where "||" denotes concatenation, "<...>" means placing data on a stack, and "[...]" are functions contained in the lock script (in this example, a stack-based language). Equivalently, the scripts may be executed one by one with a common stack rather than concatenating them. Either way, when executed together, the scripts will share Alice's public key P, which is contained in the lock script in the output of Tx0. A is used to authenticate that the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. The expected portion of the data ("message") must also be included to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (thus, there is no need to include a separate element specifying the signed portion of the data in plaintext, since the signed portion of the data is already inherently present).

[0060] The details of public-private cryptographic authentication will be well known to those skilled in the art. Essentially, if Alice signs a message with her private key, then another entity, such as node 104, given Alice's public key and the message in plaintext, can authenticate that the message must have been signed by Alice. Signatures typically involve hashing the message, signing the hash, and tagging the message as the signature, allowing the owner of the public key to authenticate the signature. Thus, in embodiments, reference to signing a particular piece of data, portion of a transaction, etc., may mean signing a hash of the piece of data or portion of a transaction.

[0061] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby broadcasting it throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it is defined as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0062] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0063] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" an amount defined in a UTXO while another amount is spent. However, an amount from a UTXO can be split among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to give herself change in the second output of Tx1 or to pay another party.

[0064] In particular, Alice must typically also include fees for Bitcoin nodes 104 that successfully included her transaction 104 in block 151. If Alice does not include fees for miners, Tx0 will likely be rejected by the miner's blockchain node 104, and thus, while technically valid, it will still not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transaction 152 if they do not want to). In some protocols, transaction fees do not require their own separate output 203 (i.e., they do not require a separate UTXO). Instead, the difference between the total amount indicated by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition that produces the block containing UTXO1. However, nothing necessarily precludes that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0065] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 in the blockchain 150. Thus, typically, a given party 103's assets are dispersed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to compile the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on one of the Bitcoin nodes 104.

[0066] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a specific function. "OP_...." represents a specific opcode in a scripting language. As an example, OP_RETURN, when preceded by OP_FALSE at the beginning of a lock script, is an opcode in a scripting language to generate an unspent output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0067] Typically, the input to a transaction is a public key P A In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific portion of the outputs to sign depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0068] A lock script is sometimes referred to as a "scriptPubKey," indicating that each transaction typically includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig," indicating that it typically provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions for redeeming a UTXO include authenticating a signature. More generally, a scripting language may be used to define any one or more conditions. Therefore, the more general terms "lock script" and "unlock script" are preferred.

[0069] As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the invitation of either party or a third party). The side channel 301 allows for the exchange of data separately from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, it may be used to exchange transactions 152 between Alice and Bob without them being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transactions 152 to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a “transaction template.” The transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0070] The side channel 301 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a local area network, such as a mobile cellular network or a local wireless network, or a direct wired or wireless link between Alice and Bob's devices 102a, 102b. In general, the side channel 301 referred to anywhere herein may include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, it should be noted that when Alice and Bob are said to exchange particular information, pieces of data, etc., over the side channel 301, this does not necessarily mean that all of these pieces of data need to be transmitted over the exact same link or the same type of network.

[0071] Client Software 3A illustrates an exemplary implementation of a client application 105, also referred to herein as a digital signature application, for implementing embodiments of the disclosed schemes. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to perform the client's 105's underlying transaction-related functionality, e.g., to form transactions 152, receive and / or send transaction and / or other data via side channels 301, and / or send transactions to one or more nodes 104 for propagation through the blockchain network 106, as described in more detail in accordance with the schemes described above. In accordance with embodiments disclosed herein, the transaction engine 401 of each client 105 includes functionality 403 for generating link transactions.

[0072] The UI layer 402 is configured to render a user interface via user input / output (I / O) means of each user computing device 102, including outputting information to each user 103 by user output means of the device 102 and receiving input from each user 103 by user input means of the device 102. For example, the user output means may include one or more display screens (touch or non-touch screen) to provide visual output, one or more speakers to provide audio output, and / or one or more tactile output devices to provide tactile output, etc. The user input means may include, for example, one or more touchscreen input arrays (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and voice recognition algorithms for receiving voice or voice input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, joysticks, etc.

[0073] Note: Although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting and may instead be implemented in two or more separate applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or in the functionality of a given module, or the transaction engine 401 may be split among more than one application. Also, this does not exclude some or all of the described functionality being implemented, for example, in the operating system layer. When reference is made elsewhere in this specification to a single or given application 105, it is understood that this is merely an example and, more generally, that the described functionality may be implemented in any form of software.

[0074] 3B provides a simulated representation of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by any other party's client 105b, Bob's device 102b, or any other party's device.

[0075] 3B illustrates UI 500 from Alice's perspective. UI 500 may include one or more UI elements 501, 502, 502 that are rendered as separate UI elements via user output means.

[0076] For example, the UI elements may include one or more user-selectable elements 501, such as different buttons on a screen or different options in a menu. The user input means is configured to allow the user 103 (Alice 103a in this case) to select or operate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: "manual" as used here simply means the opposite of automatic and is not necessarily limited to the use of hands). Optionally, the user (Alice) may be allowed to create linked transactions by modifying their signatures and / or approving links between documents.

[0077] Alternatively or additionally, the UI element may include one or more data entry fields 502 that allow a user to create a link transaction. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touchscreen. Alternatively, data may be received verbally, e.g., based on voice recognition.

[0078] Alternatively or additionally, the UI elements may include one or more information elements 503 that are output to output information to the user, for example, this / these may be drawn on a screen or rendered audibly.

[0079] For example, information element 503 can render a visual representation of an existing document that will be approved with a signature by the user. The user can view the document and decide whether to approve the document with a signature. The user can indicate their intent to sign the document via selectable element 501 or data entry field 502, as described below.

[0080] A user can specify the supplemental documents to link to the existing document by providing input via user-selectable elements 501 or data entry fields 502. For example, a user may upload the supplemental documents to electronic signature application 105 or a database accessible by electronic signature application 105 prior to creating the linking transaction so that a library of supplemental documents is stored and a unique reference is also stored for each saved supplemental document. The unique references may be presented to the user, for example, in the form of a drop-down menu on UI 500 for the user to select from. The supplemental document associated with the selected unique reference is then linked to the existing document in the linking transaction. Alternatively or additionally, a user may be able to upload supplemental documents while creating the linking transaction.

[0081] Once the user indicates a supplemental document to be linked to an existing document in a linking transaction, the user provides another input, for example, via selectable element 501, which prompts the calculation of document signature data associated with the linking transaction. This second user input includes at least one private key associated with the user (e.g., a passcode or biometric used for document signing). The document signature data is then calculated using the user's private key and used to authorize portions of the linking transaction. The user may be required to enter the private key in data entry field 502. Alternatively or additionally, the private key may be stored in or anywhere accessible to the electronic signature application 105, allowing the user to provide some other form of user verification, such as a password or user biometric, and authorize the electronic signature application 105 to use the stored private key. The private key may be stored in encrypted or unencrypted form. If encrypted, the second user input includes data to decrypt the private key needed to calculate the document signature data.

[0082] The digital signature application 105 uses the blockchain transaction to render the pre-existing document on the UI 500. As described below, the blockchain transaction may include either the document data of the pre-existing document or a reference to the pre-existing document. Thus, the pre-existing document can be rendered using the blockchain transaction by accessing the document data from the blockchain transaction if stored there, or by accessing data associated with a previous blockchain transaction in which the pre-existing document data was stored. The pre-existing document may be stored on the blockchain in an encrypted format, e.g., a hash of the document, or in an unencrypted format, e.g., in plain text.

[0083] Alternatively, the pre-existing document may be received by the digital signature application 105 from an off-chain source, such as the last party approving the document or the party responsible for creating the document, and rendered to the user. The digital signature application 105 can verify the received pre-existing document using a blockchain transaction. A copy or hash of the document is stored on the blockchain and can be used for this verification. In the case of a stored document, the digital signature application 105 can directly compare the two documents. If they are identical, the received version is verified. In the case of a hash of a document stored on the blockchain, the digital signature application 105 generates a hash of the received pre-existing document. If the hash generated by the digital signature application 105 matches the hash obtained from the blockchain transaction, the received document is verified.

[0084] The digital signature application 105 identifies blockchain transactions within a blockchain maintained by a blockchain network. The digital signature application 105 applies at least one validity check to the blockchain transaction before rendering the existing document to the user on a UI for the user to approve with a signature. An example of a validity check that may be implemented by the digital signature application 105 includes checking that the blockchain transaction has been immutably committed to the blockchain before rendering the existing document to the user for approval with a signature.

[0085] In some embodiments, the digital signature application 105 provides a means for verifying changes to a document. The user can verify these changes themselves by checking who previously signed the document and comparing this to known rules. The name of the previous signer is displayed to the user above in information element 503. An indication that the previous signer has been verified by a third party may be shown to the user via the digital signature application 105, for example, by rendering a symbol indicating third-party verification next to the previous signer's name. The changes made by the previous signer may be displayed to the user for checking against known rules.

[0086] The digital signature application 105 may provide a validation function itself. For example, known rules are known to the digital signature application 105. The validation function of the digital signature application 105 checks data retrieved from the blockchain against the known rules. The digital signature application 105 indicates to the user whether the retrieved data meets the requirements set forth in the known rules. In some embodiments, the document is presented to the user for signing only if the requirements are met. In other embodiments, a symbol or other validation message may be rendered to the user indicating whether the requirements of the rules have been met.

[0087] The known rules referenced above may be, for example, rules that define which parties can sign a document, the types of amendments each party can make to the document, the order in which parties must sign the document, and / or whether additional documents need to be linked to the document. It will be understood that different rules may exist for different types of documents.

[0088] For example, this / these may be rendered on the screen or audibly rendered. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that the UI 500 shown in FIG. 3 is merely a schematic mockup and may in fact include one or more additional UI elements, which are not shown for the sake of brevity.

[0089] <Node software> FIG. 4 illustrates example node software 450 that may be executed by each blockchain node 104 of the network 106 in the example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: an agreement module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152j (Tx j ) is received, and another preceding transaction 152i (Tx m-1 ), the protocol engine 451 executes Tx j The protocol engine 451 then identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and search for Tx i may be published on the blockchain 150. In this case, the protocol engine can obtain Txi from a copy of block 151 of the blockchain 150 stored in the node 104. Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 held by the node 154. i In either case, the script engine 451 identifies the lock script in the referenced output of Txi and passes it to the script engine 452.

[0090] The script engine 452 therefore i Lock script and Tx j 2, with the unlock script from the corresponding input. For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same can apply to any pair of transactions. Script engine 452 executes two scripts together as described above, which includes placing data on stack 453 and retrieving data according to the stack-based scripting language (e.g., Script) being used.

[0091] By executing the scripts together, script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether it "unlocks" the output that the lock script is contained in. Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, it returns the result "false."

[0092] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are one or more additional protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, and Tx j the total amount of digital assets specified in the output of Tx does not exceed the total amount pointed to by its input; i The output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j is actually validated, the decision engine 454 may then cause one or both of the agreement module 455C and the propagation module 455P to perform their respective blockchain-related functions as Tx j , which may choose to control the execution of Tx in each of the nodes' ordered transaction sets 154 for incorporation into block 151. j and a consensus module 455C that adds Tx to another blockchain node 104 in the network 106. j Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only conditional on both the transaction being declared and sufficient transaction fees remaining.

[0093] It is noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can represent any state that indicates a successful or positive outcome, and "false" can represent any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (the overall outcome is considered to convey true if both individual outcomes are true).

[0094] One-time check As previously mentioned, embodiments of the present disclosure provide methods for recording changes to documents and linking different documents on a blockchain. By way of further example, many real-world use cases are taught herein that could potentially benefit from digital signature technology.

[0095] Using blockchain as shown below, the blockchain provides an immutable record of documents, records changes such as transfers, approvals, and cancellations, and records who made changes to the document.

[0096] Furthermore, by mapping between documents and Bitcoin transactions, and between Bitcoin wallet addresses and identifiers, the blockchain can provide identification, authentication, authorization, linkability between different documents, and traceability as each document develops. It is understood that the present disclosure is not limited to use with Bitcoin, and that other similar blockchain-based usable coins may also be used.

[0097] The disclosed method takes advantage of the double-spend prevention feature of virtual currencies such as Bitcoin and similar coins. The inability to double-spend means that unspent outputs of a Bitcoin transaction can only be spent once. The single-spend property can be applied to securities.

[0098] The disclosed method increases the difficulty of forging any of the mapped documents to a high level, which is essential when using digital copies of these documents. A mapping between documents and unspent transaction outputs is provided. Changes to the state of a document, such as transferring ownership, replacing a document, or canceling a document, are made by using the transaction outputs in a new transaction whose output reflects the document's new state. Therefore, it is very easy to verify the current state of a document by checking the unspent outputs that contain the document. Without the authorization to use an expired document, forge a document, or modify a document, it is computationally impossible to do so.

[0099] As mentioned above, unlocking scripts within Bitcoin transactions contain digital signatures for the purpose of authorizing the allocation of BSV from one locking script to another, and in this context, the identity of the UTXO owner is irrelevant.

[0100] The method presented here repurposes the digital signature in the unlock script into a meaningful digital signature for data (such as a document) inserted into the transaction, which then associates the identity of the signer.

[0101] Public key certificates are necessary to provide an authenticated link between a public key and the owner's identity, but since it is recommended that a public key value not be used in multiple transactions (otherwise the private key could be compromised if the ephemeral key is not generated randomly enough), using the certificate's public key to sign transactions is not ideal.

[0102] The method provided here overcomes this problem by using "linkable signatures," which are described in more detail below. Essentially, a blockchain user has a public key P, which is an approved certificate that is not used when approving signed transactions on the blockchain. CA S Instead, it has two child public keys P Si and P i Use P Si =P CA S +P i '. Many child key pairs can be generated for one certificate public key. The signer uses the public key P Si and P i If you can provide a signature for ', then P CA S These public keys are known as sk Si =sk CA S +sk i ' is related to three private keys with the same relationship.

[0103] Linkable digital signatures can be in the form of a single transaction input containing two signatures, and the locking script is [P2PKH P Si P2PKH P i An example of such a linkable signature is shown below: [Table 1]

[0104] The present disclosure provides a method for linking usable outputs of a transaction to a document.

[0105] Ownership is mapped to the owner of the unspent transaction output. The owner of the unspent output represents the current authorized party of the document linked to the spent output. The document can be modified by the current authorized party in a new transaction. The authorized party modifies and approves the new transaction using a linkable signature.

[0106] In this disclosure, securities are used as an example of documents that may be modified and linked to other documents.

[0107] An instrument is a document evidence of title or liability that is freely transferable in exchange in lieu of money. An instrument is an unconditional order or promise to pay and includes cheques, bills of exchange, bearer bonds, some certificates of deposit, promissory notes, securities of exchange, and bank notes. The process of transferring the right to be paid, i.e., a document containing an order or promise to pay money, is called a negotiation.

[0108] Negotiability is the property of a document that makes it legally and unconditionally assignable or transferable. It allows ownership to be passed from one party, the assignor, to another, the assignee, by endorsement or delivery.

[0109] A contract can be modified in a variety of ways. Some of the things that can be modified include: Creation or publication Replace or edit Approval or acceptance transfer Completed, and cancel.

[0110] Other types of changes are possible and will vary depending on the document and use case. These types of changes are further explained in the examples below.

[0111] There are two main parties involved in any NI transaction: 1. The transferor (the current owner of the NI transferring the NI ownership interest), also referred to herein as the current authorized party. 2. The transferee (the new owner of the NI who is transferring ownership of the NI), also referred to herein as the next authorized party.

[0112] In addition to the above, there may optionally be a security issuer who acts as the transferor when the security is first created.

[0113] In the method disclosed herein, the transferor must approve the transaction input with a signature, but the transferee knows the unlock script that can unlock the transaction output. To incorporate the identification and authentication requirements, linkable signatures are used to approve transactions.

[0114] Each new transaction has at least one input, which contains a reference to a unspent transaction output and the corresponding unlock script associated with that output, where the unlock script is a signature of the child key pair associated with the authorized party's certificate public key.

[0115] Each new transaction also has at least one usable output, which includes the document itself or a reference to the document, an identifier for the next authorized party - i.e., the party that can modify the document associated with the output - and a reference to the next authorized party's certificate public key. In the case of linkable signatures, the reference to the certificate public key is some form of a child key pair associated with the next authorized party's certificate public key.

[0116] Additionally, a state can be inserted into the transaction output indicating the type of change that will be performed when an authorized party approves the transaction with a signature.

[0117] When a document is first created, it is inserted into the transaction output with a state of "created" or "issued." Each time a document is modified, the state of the document in the output of the transaction in which the change was recorded is changed to indicate the change.

[0118] Below is an example transaction for creating a security: The security is transferred from the issuer to the transferee (Alice). The issuer uses the private key s issuer and s' issuer This uses a form of linkable signature by signing with the public key P issuer1 and P' issuer1 It is compatible with P issuer1 =P CA S + P' issuer1 and P CA S is the public key of the issuer certificate. [Table 2]

[0119] TxID Issue The data inserted into typically includes: 1. <nidata>These include: a. Flags for data types and standards used, such as Universal Business Language (UBL); b. Securities description; c. NI terms and conditions or references thereto; and d. Constant resource identifier. 2. <flagissue>Data inserted into: A flag indicating the state of the NI. In the example above, this is of type issue. 3. <ID Alice The data inserted into > includes: a. Identification of the next owner or authorized party (Alice); b. A reference to the issuer's certificate and identifying information.

[0120] <P Alice The data to be inserted in is the linkable address of Alice (the assignee), e.g., [P2PKHP Alicei P2PKHP' Alicei ] or 2of2multi-sig.

[0121] Alice then signs TxID Issue By confirming with ||0, you can give NI to Bob in the transaction. [Table 3] TxID Transfer The data contained in the TxID is typically Issue is different from:

[0122] 1. Add a reference to the issuance transaction in which the security was originally issued. Since the NI data has not changed, we will not repeat it here. 2. The status has changed to "Forwarded." 3. The identity of the next authorized party has been changed to Bob.

[0123] It is understood that the identity of the new owner may not change in some transactions, for example, if an authorized party edits or replaces document data, the same party may still be authorized to modify the edited or replaced document.

[0124] The monitor receives the parent transaction TxID. Issue TxID Transfer can be easily traced and issuer authentication checked to ensure no NI is double-spent.

[0125] An NI can be in the hands of many owners. Each time, it is a transaction TxID. i and TxID i Enter the TxID i (i.e., the parent transaction). i The data contained in the NIDataTransactionTxID typically includes the state transfer, the next authorized party, and a valid NIDataTransactionTxID. Issue Contains a reference to.

[0126] 5 illustrates an example of a modification transaction 500 in accordance with the present invention. Transfer and TxID Issue are both examples of modification transactions 500. Modification transactions 500 can be identified by a unique transaction ID 502. The unique transaction ID 502 can be used to track documents and their modifications on the blockchain.

[0127] A modification transaction 500 includes an input list containing at least one input and an output list containing at least one output. While the example of Figure 5 shows two inputs 506a, 506b and four outputs 504a-c, it is understood that any number of inputs and outputs may be used in a single transaction. Thus, a single modification transaction 500 can be used to modify multiple documents.

[0128] Each input 506a, 506b of the modification transaction 500 includes an outpoint and a lock script. The outpoint references the output of a previous modification transaction. When the modification transaction 500 is propagated, the previous modification transaction does not need to be published to the blockchain.

[0129] Each input 506a, 506b Anne It also includes a lock script. Anne The lock script contains the linkable signatures of the currently authorized parties of the output referenced by the outpoint.

[0130] Anne The lock script may also include a SIGHASH flag that indicates which outputs of the modification transaction are approved by the currently authorized party associated with the linkable signature. For example, if the SIGHASH flag is set to SIGHASH_ALL, the currently authorized party authorizes all modifications of modification transaction 500, i.e., all modifications in the transaction output list. However, if it is set to SIGHASH_SINGLE, the currently authorized party only authorizes modifications of a single output of modification transaction 500.

[0131] Each output 504a, 504b, 504c, 504d of the modification transaction 500 is a spendable output. Each output 504a, 504b, 504c, 504d has an associated value, shown here as an amount in units of satoshis. It is understood that any blockchain currency and any unit of currency can be used to assign value to the outputs. Each output 504a, 504b, 504c, 504d can be individually allocated in subsequent modification transactions.

[0132] Each output 504a, 504b, 504c, 504d includes a locking script, which has two components: the data to be stored on the blockchain and the identity of the next authorized party for the document associated with the output.

[0133] Data stored on the blockchain includes either the document data of the security or a reference to the security. The document data does not need to be stored on the blockchain with every transaction; it is stored only when the document data changes, for example, when a document is issued or replaced. If necessary, the document data can be found by tracing the document changes through the blockchain using the document reference and the outpoint of each transaction. In the example of Figure 5, there are two outputs 504a and 504d that contain document data, and two outputs 504b and 504c that contain references to the documents. The document data for the documents referenced in outputs 504b and 504c are published to the blockchain in the previous change transaction.

[0134] The data stored on the blockchain also includes the state of the document. As mentioned above, the state indicates the type of change the security underwent in the transaction. The change is carried out by the currently authorized parties approving the transaction with their signatures.

[0135] For example, the current participant of input 506a approves all outputs 504a, 504b, 504c, and 504d of change transaction 500. This means that Anne The document states of outputs 504a, 504c, and 504d correspond to the changes made by the authorized parties of input 506a, and the document states of output 504b correspond to the changes made by the authorized parties of inputs 506a and 506b.

[0136] Other types of SIGHASH flags can also be used, for example, if two parties are required to approve the change, but only one of the two parties approves the transaction, SIGHASH_AnyOneCanPay can be used, meaning that a second signing party can add further input at a later date.

[0137] Data to be stored on the blockchain is inserted using the OP_PUSHDATA script opcode, which pushes data onto the stack in a manner that allows the output to be used. This differs from instances of the OP_RETURN script opcode, where data is pushed onto the stack but the output is not available. It is understood that data can be inserted using an OP_RETURN script, but not an OP_PUSHDATA script.

[0138] For each output 504a-d B The check script also includes an identifier for the next authorized party of the document associated with output 504a-d. The next authorized party is the party authorized to modify the document in a subsequent modification transaction. The identifier may include the next authorized party's certificate public key and / or the next authorized party's child public key pair.

[0139] The next authorized party identifier may be in the form of a Pay to Public Key (P2PK) or a Pay to Public Key Hash (P2PKH), with P2PKH being used in the example used here.

[0140] Outputs 504a and 504c identify only a single next authorized party. d identifies two next authorized parties. It is recognized that any number of next authorized parties may be identified for a single output.

[0141] Outputs 504b and 504 d identifies two next authorized parties. Output 504d requires a multi-signature 2 of 1, which allows one or the other of the two identified next authorized parties to modify the document without the approval of the other identified next party. There may be restrictions on the modifications that the next authorized parties can make. For example, P next5 The parties identified in P next6 Document only if the party identified in has not yet modified the document. A may be able to approve changes to the

[0142] Output 504b requires a multi-signature 2 of 2, i.e., both of the identified authorized parties have signed the Document Y You must approve the changes to

[0143] The next authorized party to modify the document in a subsequent modification transaction is the party currently authorized for that document in the subsequent transaction.

[0144] Each party may be authorized to perform only one or several types of changes to a document. For example, a current authorized user may be authorized to replace or approve a document, but not to mark it as complete. As mentioned above, the changes an authorized party is authorized to perform depend on whether another authorized party has performed a specific change to the document. Here, multisig 1 of 2 can be used. For example, a first current authorized party may be authorized to cancel a document only if a second current authorized party has not yet approved it.

[0145] Next, an example implementation of the modification transaction 500 is described. In the example shown here, the use of securities in shipping (import / export processing) is used as an example implementation. This is not a limiting example, and one skilled in the art will understand that the disclosed method can be used in any use case involving the modification of securities.

[0146] There are six main parties involved in the import / export process: exporters, importers, shippers, carriers, banks, and chambers of commerce.

[0147] The exporter is the person who owns the goods. This may also be called the seller or manufacturer. In this document, we will use the term exporter. A commercial invoice and a certificate of origin (COO) must be completed.

[0148] The importer is the person or company purchasing the goods, also known as the buyer. They apply for a letter of credit if that is the agreed method of payment.

[0149] The shipper is the party responsible for booking the carrier and arranging the shipment. This may be the owner or agent of the cargo. It may be the exporter or importer. This is also called the shipper or transportation user. This party is responsible for completing the packing list and shipper credit instructions.

[0150] Carriers, also known as transportation service providers, are responsible for the physical transportation of goods.

[0151] Banks play a major role in guaranteeing payments in international transactions. The various roles of banks are discussed below in the section on Letters of Credit (LoC).

[0152] The Chamber of Commerce or other authorized government agency may be required to sign the Certificate of Origin, which is submitted to the local Chamber of Commerce for endorsement. The Chamber must have access to relevant documents, such as the Commercial Invoice (CI) and Bill of Lading (BoL), to verify the exporter's claim.

[0153] Figure 6 illustrates an example of an import / export transaction between an importer 604 and an exporter 602. For simplicity, Figure 6 omits other participants, whose roles are described below.

[0154] In step S610, the importer 604 inquires about importing goods from the exporter 602.

[0155] In step S612, the exporter screens the potential importer 604 and the country from which the goods will be imported. This step may include determining whether there are any import restrictions or taxes.

[0156] In step S614, the exporter 602 provides a quote to the importer 604.

[0157] The sale is then finalized between the importer 604 and the exporter 602. This step involves both parties 602, 604 agreeing on payment terms, terms of sale, how the goods will be shipped, who is responsible for shipping, who is responsible for hiring the carrier or carriers, who is responsible for filing, how the transaction will be paid for (such as a letter of credit), and any other documentation required by regulation.

[0158] In step S618, the exporter prepares the goods. Shipping documents are also prepared in this step. Shipping documents include the commercial invoice, packing list, certificate of origin (COO), shipper's instructions, and bill of lading (BoL). These documents are listed in Annex A, and the possible states of the documents are listed in Annex BE.

[0159] The goods are shipped to the importer 604 in step S620, and the exporter 602 performs record-keeping operations in step S622.

[0160] The two primary instruments used in shipping and international sales are letters of credit and bills of lading. These documents are discussed below.

[0161] A Bill of Lading (BoL) can perform three functions: 1. A definitive receipt from the carrier to the shipper, i.e., confirmation that the goods have been loaded. 2. Evidence of the terms of the contract of carriage. 3. It serves as a document of ownership of the goods (i.e., a security).

[0162] The carrier (or the carrier's agent) will typically issue three original copies of the BoL, which must be attached to the shipped product and signed by authorized representatives of the carrier, shipper, and recipient (consignee).

[0163] There are three main stakeholders in the BoL: 1. Shipper: Also known as the consignor. This is the person who enters into a transportation contract with the carrier. This can be the importer or exporter depending on the agreed terms of sale. 2. Carrier: A representative of a shipping company or the captain of a ship. This is the party that provides the physical transportation services. 3. Consignee: The person entitled to take delivery of the goods under the contract of carriage shown on the bill of lading. This may be the importer, the importer's bank or the bank issuing the letter of credit.

[0164] See Appendix D for mapping of BoL changes onto the blockchain.

[0165] Without a genuine BoL, the shipper cannot release the cargo, so protecting the BoL from counterfeiting is essential.

[0166] Figure 7 is a diagram of a bill of lading. The BoL includes fields for describing the types of goods in the shipment, the quantity of each specific item, and the goods' destination. The bill of lading is signed by the shipper, carrier, and consignee.

[0167] A bill of lading can be negotiable, meaning the name of the consignee can be transferred to another person, or non-transferable, meaning the goods are entrusted to a specific person and cannot be transferred.

[0168] FIG. 8 illustrates an exemplary sequence for the use of a bill of lading in an import / export transaction.

[0169] In step S810, the shipper 804 transfers the goods to be shipped to the carrier 802, which loads the goods in step S812 and issues a BoL in step S814. When issuing the BoL, the carrier 802 signs it.

[0170] The carrier 802 provides the BoL to the shipper 804, who signs the BoL in step S816.

[0171] The carrier 802 transports the goods to the destination in step S818.

[0172] In step S820, the BoL is signed by the importer 604. The BoL is signed by all three parties 802, 804, 604. 。

[0173] The importer 602 presents the BoL signed by the three parties to the carrier 802 in step S822, which serves as proof that the importer 604 is entitled to receive the goods. The carrier 802 then releases the goods to the importer 604 in step S824.

[0174] A letter of credit (LOC) guarantees that an exporter will be paid by an importer or a bank. In the latter case, it is also known as a written LOC or a written credit. A written LOC is an agreement in which a bank agrees to pay an exporter for the export of specific goods upon presentation of specific documentation relating to those goods. A written LOC is issued in favor of an exporter (the credit beneficiary) at the request of an importer (the credit applicant). A letter of credit is usually a negotiable instrument, as the issuing bank will pay the beneficiary or a bank designated by the beneficiary.

[0175] Figure 9 shows an example sequence for the use of a letter of credit in the context of an import / export shipment. There are four main participants in this process:

[0176] The beneficiary 904 is the party to whom the favorable credit is issued. In the shipping context, this is the exporter 602 of the goods in the underlying contract.

[0177] The applicant 902 is the party requesting that a credit be issued. In the shipping context, this is the importer 604.

[0178] The applicant 902 and beneficiary 904 agree to the terms of the sale and exchange electronic sales agreement in step S911.

[0179] The applicant 902 applies for an electronic LOC from the issuing bank 906 in step S912.

[0180] The issuing bank 906 is the bank that opens and establishes the LOC. It is the bank that issues the credit at the request of the applicant 902 or on its own behalf. It is the ultimate payer of the LOC. Upon issuing the credit, the issuing bank 906 is irrevocably obligated to honor compliant presentations. The issuing bank 906 evaluates LOC applications in two primary categories: compliance with the issuing bank's policies and accuracy of the applicant's instructions.

[0181] In step S913, the issuing bank 906 issues the LOC to the advising bank 908, which may be subject to a set of rules such as the eRules for the Uniform Customs & Practice for Documentary Credits (eUCP).

[0182] Typically, the advising bank 908 and the exporter 602 are located in the same country and have a mutual commercial relationship. The exporter 602 informs the importer 604 of the advising bank's 908 preferences during the negotiation stage of the transaction.

[0183] The Advising Bank 908 has two main responsibilities: · You must demonstrate that you are satisfied with the apparent genuineness of the letter of credit or letter of correction. ·Must ensure that the LOC notice accurately reflects the terms of the credit extension or amendment from the issuing bank 906.

[0184] The advising bank 908 notifies the beneficiary 904 of the LOC in step S914. The beneficiary 904 then ships the item to the applicant 902 in step S915 and sends an electronic document shipment to the advising bank 908 as proof of shipment in step S916.

[0185] The advising bank 908 presents the electronic document to the issuing bank 906 in step S917. After the issuing bank 906 performs document management processes, it releases the payment associated with the shipped goods to the recipient 904 in step S918. This payment can be transmitted to the beneficiary 904 via the advising bank 908.

[0186] The issuing bank 906 releases the electronic document to the applicant 902 in step S919.

[0187] Figure 11 shows an example transaction set containing three "link" transactions for use in shipping. Link transactions TxID2, TxID3, and TxID4 are generated sequentially over time, followed by blockchain transactions TxID5 and TxID6, respectively.

[0188] Transactions TxID2 and TxID3 are linking transactions that link one or more new supporting documents to existing documents included or referenced in previous transactions. Transaction TxID4 links at least two existing documents (included or referenced in previous blockchain transactions).

[0189] Details of the possible formats that TxID2, TxID3, and TxID4 can take are provided below and in the transaction tables that accompany the descriptions.

[0190] The linking transaction shown in Figure 11 provides a way to link different changes to documents involved in an import / export transaction, as shown in Appendix BE.

[0191] We use the term "modification transaction" herein to refer to a transaction that modifies the content or state of an existing document. In the example below, link transactions TxID2, TxID3, and TxID4 are also modification transactions in this sense, but in general, link transactions are not necessarily modification transactions, and modification transactions may or may not be link transactions.

[0192] Alice is a manufacturer and exporter of tennis balls in country A, and Bob is an importer in country B. They agree on the terms of sale and payment by letter of credit. Shipping documents, including the bill of lading, are on the blockchain. There are four stages: 1. Alice and Bob agree to the terms of sale and Alice issues an invoice. 2. Alice prepares the shipping documents and ships the item. 3. Carol (who owns a shipping company) is in charge of the transportation. She receives the shipment from Alice, the shipper. Carol issues Alice a bill of lading. 4. Alice receives payment from her bank after providing proof of shipping. 5. Bob settles with the bank and gets the shipment released by Carol using the BOL.

[0193] The transactions at each stage are shown below.

[0194] Step 1. Alice and Bob agree on the terms of sale and Alice issues an invoice.

[0195] First, a preliminary transaction is needed to generate a transaction with a linkable signature: TxID. Certexporter is a transaction generated by Alice, in which she generates a transaction output that references a public key certificate. The locking script for the transaction is P2PKHP Alicei and P2PKHP' Alicei It consists of a concatenation of P Alicei =P' Alicei +P CA Alice and P CA Alice is a public key certificate. Therefore, the TxID in any transaction Certexporter Use of the public key certificate (i.e., the signer is Alice) proves that the user knows the private key of the public key certificate. [Table 4]

[0196] Similarly, other players wishing to use linkable signatures should use the TxID Certexporter You need to create a transaction similar to this.

[0197] In the next transaction, TxID1, Alice maps the issued commercial invoice to the transaction.

[0198] Transaction TxID1 is TxID Certexporter Use ||0 to prove that the invoice data has been approved by Alice.

[0199] Lock script in TxID1||0 <P exporter > can also be linked to Alice's certificate by adding the certificate to it, so the lock script would look like this:

number

[0200] Alice can use TxID1||0 in a new transaction when she decides to exchange or cancel an invoice, when the invoice is paid, or when she wants to link the invoice data to shipping documents (as shown in the next step). [Table 5]

[0201] Step 2. Alice prepares shipping documents and shipment.

[0202] Alice generates transaction TxID2 with the following documents: shipper instructions, certificate of origin, and packing list.

[0203] She also links the commercial invoice to the shipping document using TxID1||0 in the input for TxID2. First Output: TxID2||0 <Reference CI The data inserted into ||Satus> links to the transaction containing the Commercial Invoice (CI) data and indicates the current state of the invoice. Any new changes to the invoice are recorded in a new transaction using TxID2||0. The original invoice can always be obtained from transaction TxID1. However, after using output TxID1||0, the right to change the invoice data or state is transferred from output TxID1||0 to output TxID2||0.

[0204] The Certificate of Origin (COO) is also inserted into this transaction. The signature of the Chamber of Commerce (COC) is inserted into the second input. TxID CertCOC is the transaction that links to the COC public certificate (i.e., TxID CertCOC is TxID Certexporter (Similar to ). Note that the COO is issued and endorsed by the signatures of both the exporter and the COC, whereas the output TxID2||1 can only be used using Multi-sig 2 of 2, meaning that the document requires the signatures of both parties (shipper and COC) to be exchanged or cancelled.

[0205] The Packing List (PL) and SLI documents are issued by the exporter but not yet endorsed by the carrier. Because they are issued and not yet endorsed, we want only the exporter to be able to cancel or replace any of them without the carrier's signature. Therefore, Multi-sig 1 of 2 is used. This allows only the carrier to use the output when endorsing the document, and allows the exporter to replace or cancel the document as long as the carrier has not yet endorsed it. [Table 6]

[0206] Step 3. Carol (who owns a shipping company) handles the transportation: she accepts the shipment from Alice and issues a bill of lading to Alice.

[0207] In TxID3, Carol uses TxID2||2 and TxID2||3, which is equivalent to endorsing both the PL and the SLI documents generated by Alice (the shipper). Carol also issues the bill of lading. TxID3 can only be put into the blockchain when its parent transaction, TxID2, is submitted. Also, note that the unlock script for TxID3 contains the PL and SLI references, with their status flags changed from issued to endorsed. To change the state of either the SLI or the PL, outputs TxID3||1 and TxID3||2 must be used, respectively. In other words, the right to change the state of these documents has been transferred from the owners of the outputs TxID2||2 and TxID2||3 to the owners of outputs TxID2||1 and TxID3||2. Note that the SLI and PL are now endorsed, requiring signatures from the carrier and shipper. Therefore, the second and third outputs of TxID3 use Multi-sig 2 of 2. [Table 7]

[0208] Step 4. Alice receives payment from her bank after providing proof of shipping.

[0209] There are two important documents that Alice needs to provide to get paid: the bill of lading signed by the carrier and the invoice. Alice uses unspent outputs TxID3||0 and TxID2||0 for the BOL and invoice to the bank, respectively. The bank needs to: a. All parent transactions (TxIDs) of the submitted transaction 1~3 ) to trace. b. Verify that it is in fact signed by the entity that claims to be (this includes verifying that the correct hash flags are used). c.Ensure that the details in the shipping documents (BOL, PL, SLI, COO) are in accordance with the terms of the letter of credit.

[0210] When Alice receives payment, she signs transaction TxID4 using TxID3||0 and TxID2||0. She also transfers the BOL to her bank and maps the transfer as output TxID4||0, which contains a reference to the BOL in TxID3 and a flag, Transferred, indicating that the owner of output TxID4||0 can collect the goods. She also inserts a reference to the commercial invoice in a second output with a status flag of paid.

[0211] The bank also optionally signs the transaction to indicate its endorsement. Bank Input TxID CertBank ||0 is the transaction that provides the link to the bank certificate (Alice's TxID Certexporter (Similar to [Table 8]

[0212] Step 5. Bob settles with the bank and has the BOL transferred to him.

[0213] Bob pays the bank to transfer the BOL to him so that he can use it to release the goods. The bank generates a transaction using TxID4||0 and transfers the BOL to Bob in that transaction. Bob can trace all parent transactions with TxID5 and verify that the referenced BOL is signed by the carrier according to the terms agreed upon with Alice. [Table 9]

[0214] Step 6. Bob uses BOL to get the shipment released by Carol.

[0215] Now Bob gets the cargo released by Carol using unspent transaction TxID5||0. He generates transaction TxID6. [Table 10]

[0216] Note that the data inserted into the output with TxID6||0 now has the flag delivered. Carol can optionally add a signature to the transaction to indicate her endorsement (this is not shown here).

[0217] In some implementations, when Carol delivers and releases the goods to Bob, evidence that she provided transportation services is recorded in TxID6. This may be sufficient proof unless the flag state of the PL and SLI documents needs to be changed from endorsed to complete. In that case, Alice would use transaction TxID 6, which uses output TxID3||1,2 with the two outputs of the PL and SLI documents and the flag complete. 7partial Since TxID3||1,2 requires a 2 of 2 multisig, the transaction requires an additional signature from the carrier to complete. The bank holds the incomplete transaction and gives it to Bob when he obtains the BOL. After the goods are successfully delivered, Bob completes the transaction with Carol, TxID 7complete , which Carol completes and uploads to the blockchain. The SIGHASH function AnyOneCanPay allows you to enable partial authentication, as shown in the following example: [Table 11] [Table 12]

[0218] As mentioned above, by mapping changes to the blockchain, documents can be traced back to their current state and all changes made to the document since it was generated.

[0219] Implementations of the technology leverage the transaction validation mechanisms used to secure the blockchain to provide additional document signature validation capabilities. In this case, document signatures take the form of transaction signatures for transaction validation, particularly validation of spending relationships between transactions. This has the advantage that the existing work performed by nodes to validate blockchain transactions also serves to validate document signature requirements. In some embodiments, system parties (i.e., parties signing documents) are required to verify the identity of the signer and, for example, verify what was signed (i.e., the SIGHASH used). This means that a transaction may be accepted by a node and recorded on the blockchain despite not complying with known rules set out in the documents within the transaction.

[0220] FIG. 10 illustrates how the change transaction 500 disclosed herein can be used to verify changes both on and off the blockchain.

[0221] Each time a transaction 1002, 1004, 1006 is generated, it is sent to a node in the blockchain, which validates the transaction and publishes it to the blockchain in a block, a process that has been described in detail above.

[0222] When validating a transaction, a node verifies that the party approving the transaction using a signature is authorized to do so by checking the signature of the next authorized party identified in the output of the previous transaction, i.e., the party in the transaction input, as identified by the outpoint of the transaction input.

[0223] This validation by blockchain nodes makes it nearly impossible to use a canceled or replaced document, to forge document ownership, or to transfer a document twice, ensuring that document changes can only be made by authorized parties.

[0224] Document data is also published to the blockchain when a transaction is issued, allowing the blockchain to act as a backup for the document.

[0225] However, blockchain nodes do not validate that the parties approving a transaction have the legal authority to make the change—this step is performed off-blockchain.

[0226] Figure 10 shows Entity X, an entity external to the blockchain. To verify that the current authorized party is the legally authorized party permitted to make a particular change, Entity X accesses the transaction 1006 in which the change was made. The outpoints of the relevant inputs of the transaction are identified.

[0227] Entity X uses the outpoint to identify a previous transaction 1004 whose input is a usable output of transaction 1006. Entity X accesses the previous transaction 1004. The identity of the participant is determined from the output of the previous transaction 1004 identified by the outpoint. That is, Entity X accesses the child public key of the participant in the output of the previous transaction 1004.

[0228] Entity X then identifies the attestation transaction 1002 of the party legally authorized to make the change. It accesses this transaction 1002 and extracts the certificate public key. Entity X can then verify that the relationship between the child public key from the transaction output and the certificate public key is satisfied. If so, the party is legally authorized to make the change.

[0229] A similar process can be performed by entity X to track changes to a document. Entity X accesses transaction 1006 on the blockchain, which may be a transaction with an unspent spendable output associated with the document to be tracked.

[0230] The outpoint of the input associated with the document is identified and used to identify a previous transaction 1004 in which the input was a usable output. Entity X can access this previous transaction 1004, identify the associated usable output, determine what changes were made to the document in transaction 1004 by the state of the output, and determine who made the changes by checking the signature used to authorize the transaction.

[0231] If the state is issue or create, transaction 1004 is the one that caused the document to be published, such that there are no other previous transactions that include changes to the document.

[0232] However, if the state is not issue or create, then other changes were made to the document before transaction 1004. Entity X can find these other previous transactions in a similar manner by identifying the outpoint of the relevant input of transaction 1004 and using that outpoint to identify a previous transaction in which the document was changed. This can continue until an issue transaction is identified.

[0233] A similar process can be performed to track a document to its current state, where the spendable outputs associated with the document are tracked through the blockchain until an unspent spendable output associated with the document is found. As described here, recording document changes on the blockchain provides a mechanism for robustly checking the state of a document.

[0234] In some embodiments, a Bitcoin node or other trusted third party may provide an additional service that enforces rules regarding changes that subsequent parties can make to documents. Such an embodiment can be achieved, for example, by configuring all clients (or wallets) used by parties to approve transactions that connect to the blockchain through a gateway (trusted server) that ensures that only transactions containing authorized changes proceed to the blockchain. The trusted server may be another signer in the transaction, who adds his or her signature only if the correct flag is used—that is, if the party is authorized to make the changes indicated by the flag. The clients (or wallets) used may be authenticated to ensure compliance with system configurations, such as the use of the correct flag, and that users understand exactly what they are doing (e.g., which document they are approving and what changes they are making to the document). In some implementations, Bitcoin nodes may compare outpoint state flags with outputs to ensure compliance with rules.

[0235] While the use of linkable signatures is discussed above, it is understood that they do not require the signer to link their public key to the transaction, i.e., ownership of the document can be passed anonymously. For specific use cases, there may be rules and regulations that determine whether such an implementation is acceptable, and if such an implementation is used, it must be implemented via other verification methods.

[0236] In some implementations, the document is inserted into the input of the transaction as part of the unlock script. The document can be inserted as a prehash that is only revealed when using the transaction. For example, in such an implementation, the output of the transaction contains the lock script. <hashofthedocument>to unlock it when you use that transaction. <document>is inserted.

[0237] It is understood that, depending on the confidentiality requirements of the use case, some or all of the data inserted into the transaction will be in encrypted form. Also, different items may have different authorized access requirements. In such cases, the method disclosed above can be modified to provide selected access to this data. For example, a hash of a document or NI could be inserted instead of the document itself. This method not only provides confidentiality but also allows documents of any size to be inserted without violating the Bitcoin layer restrictions. A typical insertion would include the document hash plus appropriate flags and identifiers. The system must be designed so that signers always know what they are signing.

[0238] When using current methods for legal use cases such as shipping, it is important to use the most up-to-date forms and procedures. An on-blockchain export solution can help ensure that the templates used are up-to-date. The process and documentation can all be described in the blockchain and maintained as updates are made. The party wallets that provide the correct interface to the blockchain can always retrieve the most up-to-date forms and process and guide the parties as they complete the forms on-chain.

[0239] The above method uses OP_PUSHDATA to insert the data. Alternatively, OP_RETURN can be used. An output containing OP_RETURN is necessarily invalid (unusable), so no signature requirements are defined on the output. In this case, however, documentation or references may be included in an unusable output that is associated with another usable output that does define signature requirements.

[0240] Transactions can also include multiple outputs for the purpose of notifying other parties (e.g., importers, banks, customs, carriers) by including wallet addresses in the transaction outputs.

[0241] It is understood that the Metanet Protocol can be used as an alternative to the above method. An example is provided below.

[0242] In the Metanet protocol, there is a directed graph formed by nodes and edges. A node is a transaction, and an edge is an association between two nodes (i.e., transactions), where one transaction (the child) contains the identifier of the other transaction (the parent). Thus, updates to a child transaction can only be accepted if they are signed by the parent transaction's private key. [Table 13]

[0243] The above transaction is a Metanet transaction, where the indices of the node and its parent are given by:

number

[0244] BOL data can be inserted into the blockchain using the Metanet protocol as follows: When a shipper uses a carrier, a Metanet transaction is made between both parties and signed by both. This may be a transaction without a parent node, i.e. an orphan transaction. The TxID below shipping is an example. [Table 14]

[0245] When the carrier reaches the recipient, the following TxID recieving A transaction is created between the carrier and the receiver, with the TxID as a child. shipping The carrier may be associated with P shipping I know the private key. [Table 15]

[0246] Other variations or uses of the disclosed technology may become apparent to those skilled in the art after reading the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0247] For example, some embodiments described above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it is understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchain, blockchain network, and / or blockchain nodes may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104.

[0248] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the above-mentioned functions of generating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there are other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks, but may not generate and publish blocks (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0249] In non-preferred embodiments of the present invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to generate and publish blocks 151 but does not store and / or propagate the blocks 151 to other nodes.

[0250] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such entities / elements are configured to perform some or all of the roles of generating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

[0251] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided in accordance with any one or more of the following:

[0252] (Statement 1) A computer-implemented method for cryptographically linking multiple documents having multiple electronic signature requirements via a sequence of blockchain transactions, comprising: calculating document signature data that satisfies first signature requirements for the existing document, the first signature requirements being defined in a blockchain transaction that includes or references the existing document; the document signature data signs the portion of the link transaction that includes or references a supplemental document, the link transaction including an input for effectively using the spendable output of the blockchain transaction, whereby the document signature cryptographically links the supplemental document to the existing document; the signed portion includes a plurality of outputs of the link transaction; a first output of the plurality of signed outputs is usable and associated with the pre-existing document, the signed portion defining a second signature requirement for the pre-existing document; A second output of the plurality of signed outputs is usable and associated with the supplemental document, the signed portion defining signature requirements for the supplemental document.

[0253] (Statement 2) the first signature requirement is defined in the spendable output of the blockchain transaction and must be satisfied in order to use the spendable output, and the document signature data is in the form of transaction signature data that must be included in the input of the link transaction in order to validly use the spendable output of the blockchain transaction; the second signature requirement for the pre-existing document is defined in the first usable output and must be satisfied in order to use the first usable output in the linked transaction; The method described in statement 1, wherein the second signature requirement for the supplemental document is defined in the second usable output and must be satisfied in order to use the second usable output in the linked transaction.

[0254] (Statement 3) The method described in statement 1 or 2, wherein at least one of the signature requirements of the link transaction includes at least one public key.

[0255] (Statement 4) The method described in statement 3, wherein the public key is verifiable from a public key certificate of a certification transaction, and the signed portion of the link transaction identifies the certification transaction.

[0256] (Statement 5) The method described in statement 4, wherein the link transaction is directly or indirectly associated with the attestation transaction through one or more transaction usage relationships, thereby identifying the attestation transaction.

[0257] (Statement 6) A method according to any of statements 3 to 5, wherein the public key authenticates a master public key, but the signature requirement does not require the direct use of the corresponding private key, but instead includes a temporary public key and a composite public key derived from the temporary public key and the master public key.

[0258] (Statement 7) A method described in any of statements 1 to 6, wherein the blockchain transaction includes a first status flag associated with the existing document, and the signed portion of the link transaction includes a second status flag associated with the existing document and a status flag associated with the supplemental document.

[0259] (Statement 8) The pre-existing document is included in or referenced in the usable output of the blockchain transaction; A method according to any one of statements 1 to 7, wherein the first usable output of the link transaction includes a reference to the existing document and the second usable output of the link transaction includes data for a subsequent document.

[0260] (Statement 9) The method of claim 8, which depends on statement 7, in which the first status flag of the existing document is included in the usable output of the blockchain transaction, the second status flag of the existing document is included in the first usable output of the link transaction, and the status flag of the successor document is included in the second usable output of the link transaction.

[0261] (Statement 10) A method described in any of Statements 1 to 7, wherein the pre-existing document is included in an unusable output of the blockchain transaction, and the signed portion of the link transaction includes one or more unusable outputs containing a reference to the pre-existing document and data of the subsequent document.

[0262] (Statement 11) A method described in any of statements 1 to 8, wherein the data of the existing document is included in the input of the linked transaction to satisfy an existing document challenge of the usable output of the blockchain transaction.

[0263] (Statement 12) A method according to statement 11, which is dependent on statement 7, in which the second status flag of the existing document is included in the input of the link transaction.

[0264] (Statement 13) A method according to any one of statements 1 to 12, wherein at least one of the signature requirements of the linked transaction requires transaction signatures from multiple parties.

[0265] (Statement 14) The method described in any of statements 1 to 13, wherein at least one of the signature requirements of the linked transaction identifies multiple parties and only requires transaction signatures from a subset of the identified parties.

[0266] (Statement 15) The supplemental document is a further pre-existing document, the link transaction includes a second input for effectively using a spendable output of a second blockchain transaction, and the second blockchain transaction includes or references the further pre-existing document; The signature requirement for the further existing document is a second signature requirement for the further existing document, and the method further comprises: calculating further document signing data that satisfies a first signature requirement for the further existing document as defined in the second blockchain transaction; 15. A method according to any one of statements 1 to 14, including:

[0267] (Statement 16) A method according to statement 15, dependent on statement 2, wherein the first signature requirement for the further existing document is defined in the usable output of the second blockchain transaction, and the further document signing data takes the form of further transaction signing data for the second input of the linked transaction to effectively use the usable output of the second blockchain transaction.

[0268] (Statement 17) An electronic signature application for linking and signing multiple documents having multiple signature requirements, the digital signature application embodied as program instructions in a non-transitory medium and configured, when executed on a computer, to perform the method described in any of statements 1-16.

[0269] (Statement 18) rendering a visual representation of the pre-existing document to be signed using the blockchain transaction; receiving a first user input indicating a supplemental document to be linked to the existing document; receiving a second user input for calculating the document signature data; 18. The electronic signature application of statement 17, further configured to render a visual document signing interface for linking and signing the document by

[0270] (Statement 19) The electronic signature application of Statement 18, configured to place the blockchain transaction on a blockchain maintained by a blockchain network and apply at least one validity check to the blockchain transaction before rendering the pre-existing document for signing.

[0271] (Statement 20) The electronic signature application of Statement 19, wherein the at least one validity check includes checking whether the blockchain transaction was immutably committed to the blockchain before rendering the pre-existing document for signing.

[0272] (Statement 21) The electronic signature application of Statement 19 or 20, configured to use the blockchain transaction to retrieve the pre-existing document from the blockchain for rendering in the document signing interface, the pre-existing document being stored on the blockchain in encrypted or unencrypted format.

[0273] (Statement 22) The electronic signature application of Statement 19 or 20, configured to receive the pre-existing document from an off-chain source for rendering and verify the received pre-existing document using the blockchain transaction, wherein the blockchain stores a copy or hash of the pre-existing document to perform the verification.

[0274] (Statement 23) The electronic signature application according to any one of Statements 18 to 22, wherein the second user input includes at least one private key for calculating the document signature data.

[0275] (Statement 24) An electronic signature application described in any of statements 18 to 22, wherein the second user input includes data for decrypting at least one private key required to calculate the document signature data, and the encrypted private key is stored in a location accessible to the electronic signature application.

[0276] (Statement 25) An electronic signature application according to statements 17 to 24 dependent on claim 3, configured to verify the public key against a public key certificate of a certification transaction associated with the public key.

[0277] (Statement 26) A user device, one or more processors configured to implement an electronic signature application according to any of statements 17-25; a user interface for receiving user input; A user device including:

[0278] (Statement 27) A blockchain link transaction, the link transaction including an input for effectively using a usable output of a blockchain transaction that includes or references an existing document, and a plurality of outputs; document signature data signs the portion of the link transaction that includes or references a supplemental document, whereby the document signature cryptographically links the supplemental document to the existing document; the signed portion includes a plurality of outputs of the link transaction; a first output of the plurality of signed outputs is usable and associated with the pre-existing document, the signed portion defining a second signature requirement for the pre-existing document; A linked transaction, wherein a second output of the plurality of signed outputs is usable and associated with the supporting document, and the signed portion defines signature requirements for the supporting document.

[0279] (Statement 28) A node of a blockchain network, the node including one or more processors configured to verify the link transaction of claim 27 by checking that document signature data signing a signed portion of the link transaction satisfies a first signature requirement defined in the blockchain transaction.

[0280] (Statement 29) A computer system that implements the method described in any one of statements 1 to 16, the computer system including a user device described in statement 26 and a node described in statement 28.

[0281] According to another aspect disclosed herein, a method may be provided that includes the action of a signing party providing document signature data.

[0282] <Appendix A> The following table provides a brief description of the main documents used in shipping and international trade. [Table 16]

[0283] <Appendix B> A commercial invoice has the following status: Issued by exporter Cancellation by exporter Cancellation and Replacement by Exporter Paid The following table shows how changes to a commercial invoice are mapped to transactions on the blockchain. [Table 17]

[0284] <Appendix C> The packing list and shipper's instructions state: Generated by the shipper Cancellation by shipper Cancellation and Substitution by Shipper Authorization and acceptance by carrier or agent Services provided by service providers The following table shows how changes to the packing list and shipper's instructions map to transactions on the blockchain. [Table 18-1] [Table 18-2] The transaction for the approved document is as follows: 1. By the entity receiving the services when the services in the approved document service are provided and completed; 2. By the carrier or shipper when the carrier and shipper have agreed to revoke or replace the document; 3. When the shipper wishes to revoke or replace the agreement (if this is permitted at this stage), by the shipper alone; 4. When the carrier wishes to revoke the agreement (if this is permitted at this stage), by the carrier alone; It can be used.

[0285] <Appendix D> The following table shows how changes to the BoL map to transactions on the blockchain: [Table 19-1] [Table 19-2]

[0286] <Appendix E> The certificate of origin has the following status: Generated by exporter Cancellation by exporter Cancellation and Replacement by Exporter Endorsed and certified by the appropriate licensing body (e.g., Chamber of Commerce) The following table shows how changes to a Certificate of Origin map to transactions on the blockchain. [Table 20-1] [Table 20-2] < / document> < / hashofthedocument> < / flagissue> < / nidata> < / sigpa>

Claims

1. 1. A computer-implemented method for cryptographically linking multiple documents having multiple electronic signature requirements via a sequence of blockchain transactions, comprising: obtaining a blockchain transaction, the blockchain transaction including or referencing an existing document and defining a first signature requirement for the existing document; obtaining a link transaction, the link transaction including an input for effectively using a usable output of the blockchain transaction and a plurality of outputs, a first output of the plurality of outputs being usable, associated with the pre-existing document, and defining second signature requirements for the pre-existing document, and a second output of the plurality of outputs being usable, associated with a supplemental document, and defining signature requirements for the supplemental document; cryptographically signing a portion of the linking transaction that includes or references a supplemental document to calculate a document signature that satisfies the first signature requirement, the signed portion including the plurality of outputs of the linking transaction, whereby the document signature cryptographically links the supplemental document to the existing document; A method comprising:

2. the first signature requirement is defined in the spendable output of the blockchain transaction and must be satisfied in order to spend the spendable output, and the document signature takes the form of transaction signature data that must be included in the input of the link transaction in order to validly spend the spendable output of the blockchain transaction; the second signature requirement for the pre-existing document is defined in the first usable output and must be satisfied in order to use the first usable output in the linked transaction; 2. The method of claim 1, wherein the second signature requirement for the supplemental document is defined in the second available output and must be satisfied in order to use the second available output of the linked transaction.

3. The method of claim 1 or 2, wherein at least one of the signature requirements of the link transaction includes at least one public key.

4. The method of claim 3 , wherein the public key is verifiable from a public key certificate of a certification transaction, and the signed portion of the link transaction identifies the certification transaction.

5. The method of claim 4 , wherein the link transaction is directly or indirectly associated with the attestation transaction through one or more transaction usage relationships, thereby identifying the attestation transaction.

6. 6. The method of claim 3, wherein the public key authenticates a master public key, but the signature requirement does not require the direct use of a corresponding private key, but instead includes a temporary public key and a composite public key derived from the temporary public key and the master public key.

7. 7. The method of claim 1, wherein the blockchain transaction includes a first status flag associated with the pre-existing document, and the signed portion of the link transaction includes a second status flag associated with the pre-existing document and a status flag associated with the supplemental document.

8. the pre-existing document is included in or referenced in the usable output of the blockchain transaction; 8. The method of claim 1, wherein the first available output of the link transaction includes a reference to the existing document and the second available output of the link transaction includes data for a subsequent document.

9. 9. The method of claim 8 dependent on claim 7, wherein the first status flag of the existing document is included in the usable output of the blockchain transaction, the second status flag of the existing document is included in the first usable output of the link transaction, and the status flag of the successor document is included in the second usable output of the link transaction.

10. 8. The method of claim 1, wherein the pre-existing document is included in an unspent output of the blockchain transaction, and the signed portion of the linking transaction includes one or more unspent outputs containing a reference to the pre-existing document and data for a subsequent document.

11. 9. The method of claim 1, wherein data of the pre-existing document is included in the input of the linked transaction to satisfy an existing document challenge of the usable output of the blockchain transaction.

12. 12. The method of claim 11 dependent on claim 7, wherein the second status flag of the existing document is included in the input of the link transaction.

13. The method of any preceding claim, wherein at least one of the signature requirements of the linked transaction requires transaction signatures from multiple parties.

14. The method of any preceding claim, wherein at least one of the signature requirements of the linked transaction identifies multiple parties and only requires transaction signatures from a subset of the identified parties.

15. the supplemental document is a further pre-existing document, the link transaction includes a second input for effectively using a spendable output of a second blockchain transaction, the second blockchain transaction includes or references the further pre-existing document; The signature requirement for the further existing document is a second signature requirement for the further existing document, and the method further comprises: computing a further document signature that satisfies a first signature requirement for the further existing document as defined in the second blockchain transaction; The method according to any one of claims 1 to 14, comprising:

16. 16. The method of claim 15 dependent on claim 2, wherein the first signature requirement for the further existing document is defined in the spendable output of the second blockchain transaction, and the further document signature takes the form of further transaction signing data for the second input of the linked transaction to enable use of the spendable output of the second blockchain transaction.

17. 17. An electronic signature application for linking and signing multiple documents having multiple signature requirements, the electronic signature application embodied as program instructions in a non-transitory medium and configured to perform the method of any of claims 1 to 16 when executed on a computer.

18. Rendering a visual representation of the pre-existing document to be signed using the blockchain transaction; receiving a first user input indicating a supplemental document to be linked to the existing document; receiving a second user input for calculating the document signature; 18. The electronic signature application of claim 17, further configured to render a visual document signing interface for linking and signing the document by

19. 20. The electronic signature application of claim 18, configured to place the blockchain transaction on a blockchain maintained by a blockchain network and apply at least one validity check to the blockchain transaction before rendering the pre-existing document for signing.

20. 20. The electronic signature application of claim 19, wherein the at least one validity check includes checking whether the blockchain transaction was immutably committed to the blockchain before rendering the pre-existing document for signing.

21. 21. The electronic signature application of claim 19 or 20, configured to use the blockchain transaction to retrieve the pre-existing document from the blockchain for rendering in the visual document signing interface, the pre-existing document being stored on the blockchain in encrypted or unencrypted format.

22. 21. The electronic signature application of claim 19 or 20, configured to receive the pre-existing document from an off-chain source for rendering and to validate the received pre-existing document using the blockchain transaction, the blockchain storing a copy or hash of the pre-existing document for performing the validation.

23. The electronic signature application of any of claims 18 to 22, wherein the second user input includes at least one private key for computing the document signature.

24. 23. The electronic signature application of claim 18, wherein the second user input includes data for decrypting at least one private key required to calculate the document signature, the encrypted private key being stored in a location accessible to the electronic signature application.

25. 25. The electronic signature application of any one of claims 17 to 24 when dependent on claim 3, configured to verify the public key against a public key certificate of a certification transaction associated with the public key.

26. A user device, one or more processors configured to implement the electronic signature application of any of claims 17 to 25; a user interface for receiving user input; A user device including:

27. A node of a blockchain network, comprising one or more processors configured to validate a link transaction, the link transaction including an input for validating an available output of a blockchain transaction embodied on a computer-readable medium and including or referencing a pre-existing document, and a plurality of outputs; a document signature signs a portion of the linking transaction that includes or references a supplemental document, whereby the document signature cryptographically links the supplemental document to the existing document, and the signed portion includes multiple outputs of the linking transaction; a first output of the plurality of signed outputs associated with the pre-existing document, the signed portion defining a second signature requirement for the pre-existing document; a second output of the plurality of signed outputs is usable and associated with the supplemental document, the signed portion defining signature requirements for the supplemental document; Validating the link transaction includes: obtaining a document signature for the link transaction; Obtaining a first signature requirement defined in the blockchain transaction; checking that a document signature signing a signed portion of the link transaction satisfies the first signature requirement defined in the blockchain transaction; Contains the node.

28. A computer system for carrying out the method according to any one of claims 1 to 16, said computer system comprising a user device according to claim 26 and a node according to claim 27.

Images