Blockchain transactions

Abstract

A computer implementation method for signing a document is provided in the document signing system. A signature request is received from the requester, which includes the signer's identifier and identifies the document. A commitment to the document is obtained. A document blockchain transaction is generated, and the document blockchain transaction includes the commitment to the document and the document signing requirements associated with the signer, and the document is signed when the document signing requirements are met. The document blockchain transaction is made available to one or more nodes of the blockchain network. A signature approval message is received from the signer, and in response to receiving the signature approval message, a signature blockchain transaction is generated, which includes the signature associated with the signer, and the signature satisfies the document signing requirements. The signature blockchain transaction is made available to one or more nodes of the blockchain network.

Description

[Technical Field]

[0001] The present invention relates to a computer implementation method for signing documents in a document signing system, as well as computer equipment and computer programs for carrying out the method. [Background technology]

[0002] A Document Signature Application (DSA) provides a platform for users to digitally sign documents.

[0003] One well-known application is DocuSign (registered trademark, hereafter the same). DocuSign integrates with assistive technologies, mobile signatures, Microsoft (trademark), Google (trademark), and Dropbox (registered trademark). Individuals and organizations can use DocuSign to electronically sign and manage documents, eliminating the need for physical signatures and paper-based processes.

[0004] DocuSign utilizes the following technologies to assist in signature generation: • Two-factor authentication via SMS - DocuSign sends an authorization code via text message to the recipient's mobile phone, and the recipient enters the code to begin signing. This complements existing DocuSign authentication options such as email access codes, phone calls, and knowledge base (KBA) authentication. • ePadlink Signature Pad Integration - The DocuSign Signature Pad option enables signing and adoption of signatures using a signature pad. In the next release, DocuSign will add support for the ePadlink ePad-ink (VP9805) signature pad device. eWitness - Allows users to add electronic signatures and act as witnesses to contracts.

[0005] In DocuSign, an envelope is used as a container for a document that a user requests recipients to sign. An envelope can contain one or more documents and one or more signatories.

[0006] The envelope has a status (i.e., sent, delivered, completed, invalid) and contains information about the sender and a timestamp indicating the progress of the delivery process. • Sender: Create, send, and manage DocuSign envelopes • Signatories: Recipients of an envelope who need to act based on the envelope or the documents within the envelope. • Fields: These indicate where the signer needs to take action based on the document. For example, entering data, selecting or applying a signature. • Viewing / Signing Sessions - Session Information

[0007] However, DocuSign signatures are not generated using a signature scheme; in fact, DocuSign only stores the signature image. Users register their email address with DocuSign, upload documents, and sign them with the signature image. Furthermore, DocuSign centrally manages all of the user's documents. Therefore, if a customer's email address is lost due to hacking, and the lost address is used in a phishing attack, the documents are at risk.

[0008] To mitigate risks, DocuSign uses a variety of security measures to maintain the security of its servers. • Physical security of data centers • Network security measures such as firewalls and intrusion detection systems. • Encryption of both data storage and data transfer • Access control to restrict unauthorized access • Regular security audits and penetration testing ·Compliance with industry security standards (e.g., SOC 2, ISO 27001)

[0009] Furthermore, when using DocuSign's electronic notarization feature, the sender can request document notarization in person. This is also known as the eWitness feature (eWitness in the UK and Notary in the US).

[0010] DocuSign provides the following APIs: ·eSignature API - 400 endpoints for signature workflows ·Notary API - Notary-specific endpoints ·Click API - A REST API to obtain consent to standard terms with a single click ·Rooms API - Streamlines complex contracts through a secure digital workspace ·Monitor API ·Admin API ·Salesforce Apex Toolkit

[0011] The following describes the process of preparing and signing a document implemented in DocuSign. 1. Document upload: The user uploads the document that requires signatures to the DocuSign platform. 2. Recipient addition: The user adds the recipient's email address and specifies the signature role (signer, reviewer, etc.). 3. Customize signature order: The user can specify the order in which recipients sign the document. 4. Add signature fields: The user can add signatures, initials, and other fields to the document as needed. 5. Document sending: The user sends the document to the recipient for signature. 6. Signature Process: The recipient will receive an email containing a link to the document and instructions on how to sign it. The recipient can review the document and add their electronic signature on their mobile device using a mouse, stylus, or their finger. 7. Document Completion: Once all necessary signatures are obtained, the signed document is automatically returned to the sender and can be downloaded or stored on the DocuSign platform.

[0012] Various standards have been adopted for electronic signatures.

[0013] The ESIGN Act is a U.S. federal law passed in 2000. It gives legal effect to electronic signatures and electronic records when all parties to a contract choose to use electronic documents and electronic signatures. The requirements of the Uniform Electronic Transactions Act (UETA) and the ESIGN Act stipulate that electronically signed documents must meet the following requirements, respectively: • Intent of Signature - A signature on an electronic document is only valid if the document and its provisions are completely transparent and the signature was made with intent. • Explicit or Implied Consent to Electronic Signatures - All electronic document / signature platforms must include a clause in which the client consents to electronically signing this agreement. Users can further enhance this clause by adding a checkbox or confirmation step during the signing process. • Signature Attribution - Users maintain a digital audit trail that associates signatures with unique identifiers such as timestamps, email addresses, and IP addresses. • Protection of signatures - All signatures must be securely attached to the document and must not be stored separately. Signed documents must be stored in an encrypted environment and must not be transmitted to anyone other than those involved. • Send a copy to the signer - Once the document is signed, a copy of the document, including the signature, must be sent to the client. • Record keeping - Users must keep a signed copy of each document so that they can make copies as needed. • Opt-out clause - Clients should always have the opportunity to opt out of digital signatures and sign paper contracts. While digital signatures are becoming the new standard, clients should always have paper backups in case someone chooses this method. eIDAS (Electronic ID, Authentication, and Trust Services) has developed standards that enable electronic transactions to have the same legal status as paper-based transactions through electronic signatures, certified digital certificates, electronic seals, time stamps, and other authentication mechanisms. • Advanced digital signatures: A digital signature is considered an advanced signature if it meets certain requirements. - Provides unique identification information that links the signer to the signature. - The signer has sole control over the data used to create the electronic signature. - It is necessary to be able to identify whether the data accompanying the message has been tampered with after signing. - If the signed data is modified, the signature will be marked as invalid. - Electronic signatures have certificates that verify the identity of the signatory and serve as electronic proof linking the electronic signature verification data to that person. - Advanced digital signatures can be technically implemented in accordance with the XAdES, PAdES, CAdES, or ASiC baseline profile (Associated Signature Containers) standards for digital signatures defined by the European Telecommunications Standards Institute (ETSI). • Certified digital signature: A sophisticated digital signature created by a certified digital signature creation device based on a certified certificate for digital signatures. • Certified digital certificate for electronic signatures: A certificate that proves the authenticity of a certified electronic signature issued by a certified trusted service provider.

[0014] All organizations providing public digital signatures in EU member states must recognize the electronic identities of all EU member states. Note that this means certificates used in closed systems are not covered by eIDAS.

[0015] Other digital signature standards include the following: • Switzerland - ZerES Digital Signature Standard - • United States - NIST Digital Signature Standard (DSS) • United Kingdom - The eIDAS regulation provides a legal framework for the use of electronic trust services offered within the UK, and also recognizes equivalent services offered in the EU. • Canada - PIPEDA (federal) and UECA (provincial) • Australia and New Zealand - Electronic Transactions Act • CFR Part 11 - Defines the criteria by which electronic records and electronic signatures are considered reliable and equivalent to paper records. [Overview of the Initiative]

[0016] This specification provides a blockchain-based document signing application (DSA) that leverages the capabilities of blockchain technology.

[0017] Blockchain provides the following characteristics to DSA: • Accessibility: All documents and signature records can be stored in a distributed ledger, improving security and accessibility. • Immutable record keeping: Transactions on the blockchain are persistent and immutable, ensuring the integrity of documents and signatures. • Smart contracts: Automated contract execution can be triggered based on the fulfillment of certain conditions, such as the completion of all required signatures. • Digital signatures: Using public-key cryptography, digital signatures can be created, resulting in secure and verifiable electronic signatures.

[0018] The DSA system provided herein, by leveraging these blockchain capabilities, can offer a secure and efficient solution for signing and managing electronic documents.

[0019] According to one embodiment disclosed herein, a computer implementation method for signing a document in a document signing system is provided. The method comprises the steps of: receiving a signature request from a requester, which includes an identifier of a signer and identifies a document; obtaining a commitment to the document; generating a document blockchain transaction, wherein the document blockchain transaction includes the commitment to the document and a document signing requirement associated with the signer, and the document is signed by satisfying the document signing requirement; making the document blockchain transaction available to one or more nodes of a blockchain network; receiving a signature approval message from the signer; generating a signature blockchain transaction in response to receiving the signature approval message, wherein the signature blockchain transaction includes a signature associated with the signer, and the signature satisfies the document signing requirement; and making the signature blockchain transaction available to one or more nodes of a blockchain network.

[0020] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments are carried out, the accompanying drawings are referenced as examples. [Brief explanation of the drawing]

[0021] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates some examples of transactions that may be recorded on the blockchain. [Figure 3] This diagram shows an overview of the DSA signing process. [Figure 4] This diagram shows an example of how to prepare documents using a managed DSA system. [Figure 5] This diagram shows an example of how to sign a document using a managed DSA system. [Figure 6]This diagram shows an example of how to register a user in an unmanaged DSA system. [Figure 7] This diagram shows an example of how to sign a document in an unmanaged DSA system. [Figure 8] This diagram shows an example of how to finalize a document in a non-retention DSA system. [Figure 9] This figure shows an example of the Merkle root structure of a signed document. [Figure 10] This figure shows an example of how to prepare documents in a separate document storage environment. [Modes for carrying out the invention]

[0022] 1. Document signing application Document signature applications (DSAs) can use blockchain technology to sign documents.

[0023] The DSA system has two main components. • Orchestrator: Workflow management solution • Document store: A database that stores documents and / or hash values ​​of documents.

[0024] In this specification, the orchestrator may also be referred to as the document signing system.

[0025] The document store and orchestrator can communicate directly or separately.

[0026] The DSA system has three main stages, as shown in Figure 3: document preparation 302, document signing 304, and final document approval 306.

[0027] The DSA signing process can be implemented in the following two ways: • Custodial - The system manages key pairs and signing workflows on behalf of the user, according to the user's instructions. • Non-custodial - In this system, users can prove they have signed a document by signing a blockchain transaction. A link containing the document ID is sent to the signer's email address. It should be understood that signers may also be provided with access to the document through other means that are obvious to those skilled in the art. Once the signer verifies the document, they sign the transaction and make it public. The signer's signature is then included in the transaction unlock script to provide a record of the signature. The signature in the unlock script is not necessarily the same as the signature on the document.

[0028] 1.1 Managed DSA In managed DSA, the orchestrator is responsible for generating the signatures to sign the document on behalf of the signers.

[0029] An orchestrator has one or more of the following functions: • Send a document signing notification to the signer. • Provides a web-based interface for users to sign, send, and manage documents. • Use role-based access control to restrict which users can view and sign documents. Users must be registered with the system. • Provides interoperability with other systems such as cloud storage services, email systems, and certificate authorities, enabling seamless integration with existing workflows. • It has the capability to be hosted by a cloud provider or on-premises by the customer. This should make DSA attractive to as many customers as possible. • To comply with the GDPR's right to be forgotten, there is a function to delete documents.

[0030] Furthermore, the following items must be specified in a managed DSA: • The location where documents are stored. • Document retention period. • The orchestrator can support document signing using blockchain transactions.

[0031] 1.1.1 User Registration Users must register with the DSA system before they can sign documents. This is because the DSA system stores the keys used to sign documents by specific signers, and therefore, the signer needs to be recognized by the DSA system before signing.

[0032] Registration involves entering an email address and creating a password on the DSA interface to generate a user profile. Once a user is registered with the DSA system, authentication can be performed before creating signature requests or signing documents. The DSA system creates a key pair and provides the registered user with a public key (e.g., PK). signer Assigns a private key. The associated private key is stored in the keystore by the DSA and used to sign the signing transactions associated with the document on behalf of the user.

[0033] In some embodiments, signers are registered with the DSA system after the document blockchain transaction has been generated. Document blockchain transactions will be described in more detail later. A document blockchain transaction provides or identifies the document to be signed and defines the signing requirements that the signers must meet.

[0034] If a signer registers after the document transaction has been generated, the DSA generates a public and private key pair for the signer as described above and stores it in the document store along with the signer's identifier. Once the signer registers with the DSA, the stored private key is then associated with the user profile, and the public key is provided to the user.

[0035] 1.1.2 Document Preparation At this stage, the user can choose to upload a document or a hash of a document to the DSA platform. This specification provides an example of choosing to upload a document, which is shown to illustrate the process. This also applies to the option of uploading a hash of a document.

[0036] Users upload the document to be signed to the DSA platform, add recipient email addresses or other identifiers, and specify the signing roles (signer, reviewer, etc.). Optionally, they can also specify the order in which recipients sign the document and add signature fields.

[0037] Further details are shown in Figure 4. In the example in Figure 4, the DSA system 400 consists of both an orchestrator 402 and a document store 404, and the two components can communicate with each other. 1. User 103a logs into the DSA system 400 and uploads the document to the orchestrator 402. 2. The orchestrator 402 processes the document and stores it in the document store 404. 3. Document store 404 returns the document ID to orchestrator 402. 4. Orchestrator 402 sends the document ID to user 103a. 5. User 103a adds the signer's email address (or other identifier). 6. Orchestrator 402 verifies the public key against the signer's email address. 7. The orchestrator 402 requests a hash value from the document store 404. 8. Orchestrator 402 creates and publishes the signature request transaction TXID1 to the blockchain as described below. A signature request transaction is also referred to herein as a document blockchain transaction. Note that the lock script for TXID1 includes the document hash value as the data payload using OP_FALSE OP_RETURN. TXID1 is signed by two signers (PK signer1 PK signer2 This indicates that a person can independently sign a document. A signature request transaction may have one or more signers. UXTO DSA This is the output controlled by the DSA400 and used to generate signature request transactions. 9. Orchestrator 402 stores the transaction ID associated with the document ID, i.e., the transaction ID of the document transaction. 10. The orchestrator 402 notifies user 103a that the document is ready for signing. This may be done via email, the DSA portal, or the user interface. [Table 1]

[0038] TxID1 is a template for an example document blockchain transaction to request a document signature. This transaction has three outputs. The first output is a first lock script that stores the document hash on blockchain 150 and makes the output non-consumable.

[0039] The other two outputs contain the signing requirements for signing the document. In this example, the signing requirement is the pay-to-public-key hash associated with each signer. To satisfy this requirement, signers must provide a valid signature in the unlock script for the signing transaction.

[0040] The signer's public keys used to derive the signing requirements, the second and third lock scripts in this example, are obtained from the orchestrator 402's keystore.

[0041] The first lock script contains a hash of the document. This hash of the document may be referred to herein as a commitment to the document. In the example in Figure 4, the document store 404 generates the document hash. However, in some embodiments, the document store 404 provides the document to the orchestrator 402, which hashes the document before including it in the lock script.

[0042] In some embodiments, the document itself is included in the lock script of the document transaction. In such embodiments, the document may be referred to as a commitment to the document.

[0043] Other commitments to the document may also be available, derived from the document, and used to verify that a copy of the document is authentic. Other examples include zero-knowledge proofs associated with the document, or Merkle roots derived from the document as described in Section 1.3. Other known methods of communication between the DSA and the signatory regarding the same data but without disclosing the data or its details may be used as commitments to the data in the manner provided herein.

[0044] In the example above, the document store 404 stores the document along with its document ID. In some embodiments, the document store 404 may store a hash of the document instead of, or in addition to, the document. In this embodiment, the orchestrator 402 receives a document from user 103a, hashes the document, and provides the hash to be stored in the document store 404.

[0045] In some embodiments, user 103a does not provide documents to orchestrator 402. Instead, user 103a provides only the hash of the document, which the orchestrator provides to document store 404 for storage.

[0046] The transaction ID of a document transaction is stored in orchestrator 402 in association with the document ID, or in document store 404 along with the document ID and the document or document hash.

[0047] 1.1.3 Document Signature Once a document transaction is recorded on blockchain 150, a notification or request is sent to signer 103b (or multiple signers) indicating that signature approval is required. In some cases, user 103a may send a request to signer 103b from outside DSA 400. For example, user 103a may send a document to signer 103b, notifying them that the document can be signed on DSA 400, providing a link to sign the document on DSA 400, or providing a document ID so that signer 103b can access the document from document store 404.

[0048] Alternatively, DSA400 may notify signer 103b. For example, signer 103b receives an email containing a link to the document, or a document ID and instructions on how to sign it. Signer 103b can then review the document retrieved from document store 404 and sign it using orchestrator 402.

[0049] To sign the document, a signing blockchain transaction is generated that contains a signature that satisfies the signing requirements of the document transaction. Using the example in Section 1.1.2, the signing requirement is satisfied by an unlocking script for a signing blockchain transaction that contains a signature generated using the private key associated with signer 103b. That is, UXTO of TXID1 is used to sign the document.

[0050] The signature provided in the unlock script for a signature blockchain transaction serves two purposes: signing the document and unlocking the UTXO. This signature is a cryptographic signature.

[0051] An example of the signature process is shown in Figure 5. 1. The DSA system 400 sends a document notification to signer 103b requesting a signature. This notification includes a document ID. 2. Signer 103b logs into DSA system 400. 3. DSA400 authenticates that signer 103b is viewing the document ID and transaction ID TXID1. 4. Signer 103b requests the document associated with the document ID. 5. DSA400 verifies the document against the requested document ID and authenticates that signatory 103b is authorized to view the document. 6. Signatory 103b approves the document and authorizes orchestrator 402 to sign the document. 7. Orchestrator 402 creates a new blockchain transaction TXID2 that consumes the UTXO of TXID1 associated with signer 103b. 8. Orchestrator 402 records TXID2 to DSA400 and notifies signer 103b that the operation was successful.

[0052] In step 3, a signature approval request is sent to signer 103b. This request may also be a message sent to signer 103b. The signature approval request may include a document transaction identifier, which allows signer 103b to access the document transaction stored on blockchain 150. The signature approval request may also include a document ID, which allows signer 103b to access the document from document store 404 without relying on orchestrator 402.

[0053] Alternatively, signer 103b may be provided with access to the transaction ID and / or document ID through a user account or portal in DSA400.

[0054] In another embodiment, signatory 103b is provided with a copy of the document directly from user 103a who requested the document to be signed.

[0055] In some embodiments, signer 103b may request access to a document using a document transaction ID. The DSA 400 identifies the document ID associated with the transaction ID, uses it to retrieve the relevant document, and provides it to signer 103b.

[0056] Signer 103b verifies that the commitment to the document provided in the document transaction is accurate with respect to that document. For example, signer 103b retrieves the document from the document store 404, hashes it, and verifies that the document hash in the document transaction matches the hash of the document generated by signer 103b. If the hashes match, signer 103b approves the signing of the document to orchestrator 402.

[0057] In another embodiment, the commitment to a document may be a Merkle tree derived from the document and signing requirements, for example, as shown in Section 1.3. To verify the commitment to a document, signer 103b can reconstruct the Merkle tree based on the accessible document and signing requirements and confirm that the Merkle trees match. Alternatively, signer 103b can obtain the Merkle certificates corresponding to the documents in the Merkle tree and compute a Merkle root based on the documents and Merkle certificates. If the computed Merkle root matches the Merkle root of the document transaction, signer 130b confirms that the document subject to the commitment is identical to the document to be signed and authorizes orchestrator 402 to sign the document. Signer 103b authorizes orchestrator 402 to sign the document in a signature authorization message.

[0058] When orchestrator 402 receives a signature authentication message, it retrieves the private key of signer 103b from the keystore and generates a signature.

[0059] In the method described above, the DSA authenticates signer 103b before signer 103b can view the requested data. This authentication can be implemented using any known method, such as a username and password or two-factor authentication.

[0060] In some embodiments, a signing transaction may further include a signature on the document, i.e., an image of the signature that satisfies the document signing requirements. The signature image can be included in the OP_RETURN script within the signing transaction's lock script. The signature image may be, for example, a signature hash or an image file showing a handwritten signature. Other images of the signature may also be used.

[0061] 1.1.4 Final Decision on the Document Once all signatures for the transaction are complete, Orchestrator 402 creates a document audit trail and notifies all parties involved. The document audit trail includes the following details about the signers of the document: • Email ·name ·signature ·date

[0062] 1.2 Unmanaged DSA In an uncontrolled DSA, the orchestrator is not responsible for generating signatures to sign the document on behalf of the signer. In other words, in an uncontrolled DSA, the user, not the orchestrator, manages the key pair for document signing. This is achieved by securely hosting the keys using a wallet.

[0063] 1.2.1 Wallet If the wallet is related to an unmanaged solution, it must meet the following requirements: • The wallet can use the owner's private key to sign transactions associated with documents. • The wallet securely stores private keys. • The wallet owner's public key is registered via an X.509 certificate to verify its identity. The CA issuing the X.509 certificate must be approved by the organization requesting the document signing. The certificate uses the secp265kl key pair.

[0064] 1.2.2 Registration Process The user registration process is shown in Figure 6. In the example in Figure 6, the DSA system 600 includes both the orchestrator 602 and the document store 604. 1. User 103a generates a key pair and obtains a certificate for its public key from a trusted Certificate Authority (CA) 606. User 103a can specify that the public key be used to sign documents. 2. User 103a registers an account with DSA600 using their email address, certificate, and other information. The certificate contains user 103a's public key. 3. The DSA600 records user information and creates an account. 4. User 103a sets the password for that account. 5. The DSA600 stores the password hash related to the user's email address.

[0065] It should be noted that user 103a can assume the role of signer in the subsequent process. That is, signer 103b registers their authenticated public key and email address with the DSA platform 600 in the same manner. This allows the DSA system 600 to generate and publish a signature request transaction on behalf of signature requester 103a.

[0066] It will be understood that obtaining and providing a certificate is not mandatory for user 130 to use DSA600. However, since user 103 provides the public key to DSA600, rather than DSA600 generating a key pair as in the managed DSA system described in Section 1.1, DSA600 cannot verify the validity of the public key provided by user 103. Therefore, adding certificate provision improves the security of the system.

[0067] The public key, user identifier, and key certificate can be stored in the orchestrator 602's keystore. Before storing user 103's public key, DSA600 can verify that the certificate was generated by CA606.

[0068] Orchestrator 602 can verify that the certificate was generated by CA606 before storing the key. The certificate may be signed by CA606, and verification includes confirming that the signature is a CA606 signature.

[0069] 1.2.3 Document Preparation The document preparation procedure is described in Section 1.1.2 and is similar to the managed solution shown in Figure 4. Note that the public keys of the registered certified signers in Section 1.1.2 are stored by the DSA600.

[0070] The following process may be implemented. 1. User 103a uploads the document hash to orchestrator 602 and obtains the document ID. 2. User 103a adds the signer's email address. 3. Orchestrator 602 verifies the authenticated signer's public key against the signer's email address. 4. Orchestrator 602 creates and publishes the signature request transaction TXID1. This transaction locks the output to the signer's authenticated public key and includes the document hash as the data payload using OP_FALSE OP_RETURN. Note that the UTXO of TXID1 is only available to signer 103b. 5. Orchestrator 602 adds a transaction ID associated with the document ID. 6. The orchestrator 602 notifies user 103a that the document is ready for signing.

[0071] As described in Section 1.1.2, a signature request transaction, or document transaction, includes a commitment to a document and a signing requirement that, if fulfilled, sign the document. In this example, the commitment to the document is a document hash, but in some embodiments, the document itself or a zero-knowledge proof derived from the document may also be used. The signing requirement is defined by a lock script that locks the UTXO to signer 130b using a stored public key.

[0072] As mentioned in Section 1.1.2, the document store 604 can store documents, document hashes, and / or zero-knowledge proofs associated with documents, in association with document IDs. Therefore, commitments to documents included in a document transaction can be retrieved from or calculated based on the retrieved data in the document store 604.

[0073] A template for document transactions is shown in Section 1.1.2.

[0074] 1.2.4 Document Signature Once a document transaction is recorded on blockchain 150, a notification or request indicating that a signature is required is sent to signer 103b (or the signers). The method for notifying signer 103b is described in 1.1.3, and other appropriate methods may also be used to notify signer 103b.

[0075] In contrast to the managed system in Section 1.1, signer 103b signs the document via wallet 608 and generates a signature to satisfy the document signing requirements of the document transaction. This is because DSA 600 does not store, nor can access, the signer's private key required to sign the document. Using the example in Section 1.1.2, the signing requirement is satisfied by the unlock script for the signing blockchain transaction, which includes a signature generated using signer 103b's private key. That is, the UXTO of TXID1 is used to sign the document. The alternatives provided in Section 1.1.3 also apply to unmanaged systems.

[0076] Signer 103b receives the document ID from DSA600 and signs it by following these steps. 1. Connect to wallet 608 and verify the requested transaction ID associated with the received document ID. 2. Retrieve the transaction associated with the document ID from blockchain 150. 3. Calculate the hash value of the received document and compare it to the hash value within the transaction. 4. Issue a new transaction TXID2 that consumes the UTXO of TXID1. TXID2 certifies that signer 103b signed the document.

[0077] As with previous examples, the commitment to the document is the document hash. Other possible commitments are provided herein.

[0078] Signer 103b can compare the calculated hash of the received document with the hash of the document in the document transaction obtained from blockchain 150. Signer 130b can sign the document by generating a signed blockchain transaction only if they determine that the hashes match.

[0079] 1.2.5 Final Decision on the Document The final decision-making stage for documents in an uncontrolled DSA is similar to that in a controlled solution. The only difference is that orchestrator 602 needs to monitor blockchain 150 and determine whether TXID2 is valid.

[0080] Figure 8 shows an example of the process for finalizing a document. 1. The DSA system 600 monitors the status of TXID2. If TXID2 is valid on blockchain 150, the orchestrator 602 updates the signature status to complete the process. 2. DSA600 sends a notification to user 103a reporting the status, including the document ID and audit trail. 3. DSA600 also sends a notice to signatory 103b containing the document ID and audit trail.

[0081] 1.3 Secure Enclave DSA In the alternative managed DSA system, users and signers do not need to hold cryptocurrency (e.g., Bitcoin) accounts. In this embodiment, the signing of documents associated with a signer is separate from the signature provided in the unlock script for the signing transaction.

[0082] In this common scenario, users may prefer to sign documents individually rather than signing them together with the blockchain transaction. That is, the signer's digital signature only signs the document, not the blockchain transaction. The DSA itself signs all transactions.

[0083] This approach allows users to use any digital signature scheme to sign documents. Especially where high security requirements are needed, digital signatures are expected to be generated within a secure enclave of hardware devices such as mobile phones. Furthermore, users do not need to handle blockchain transactions, and signature verification can be performed independently of blockchain transactions. Additionally, since many secure enclaves do not typically support the curve used by Bitcoin, this approach also offers excellent interoperability with existing signature solutions.

[0084] A typical DSA follows a process similar to that outlined in the managed DSA scheme, with a few exceptions.

[0085] The signature request transaction may be modified as follows: [Table 2] Here, PK1 and PK2 are used by the DSA to separate the signed transaction from the document signature. In other words, PK1 and PK2 are public keys owned by the DSA. These keys are the public keys of the signers. signer1 and PK signer2 Alternatively, it may be linked or associated with the signer's identifier by some means, such as a database. However, a UTXO locked by a lock script including PK1 or PK2 is locked to the DSA's private key. Thus, signer 103b does not need to have a cryptocurrency account or wallet.

[0086] The data payload, containing the signer's public key, allows the signer to verify the signature on the document using the public key provided in the requested transaction, without having to handle Bitcoin or other cryptocurrencies. H(Document') can be replaced with H(salt||Document) or any other type of cryptographic commitment to the document data.

[0087] PK signer1 and PK signer2 The private keys associated with signer1 and signer2 are used to directly sign a document within DSA. That is, DSA includes a key store that stores a signer's private key in association with the signer's user identifier, similar to the managed DSA system described in Section 1.1. The signature is

Number

[0088] Alternatively, the signer can keep their private key and, when authorizing the generation of a signed transaction, provide the signature

Number

[0089] If privacy is a concern, signer1 and signer2 can be replaced with cryptographic commitments or hash values of the public keys. A Merkle tree can be used to obtain all the public keys. In this case, the Merkle root can be included in the data payload after OP_FALSE OP_RETURN. For example, the Merkle root associated with a document and the signer's public key can be constructed as follows: signer1 and signer2 signer2 It should be noted that the hash values of the leaves of the Merkle tree do not have to be at the same depth (see Figure 9). The Merkle root can be considered a commitment to the document. H(H(Document) || H(H( Signer1 ) || H( Signer2 ))) Signer1 ) || H( Signer2 Signer2 )) DSA signs the transaction TXID

[0090] ​2A The following will be made public: Signature transaction TXID 2A This consumes the UTXO of TXID'1 associated with signer 1 and signs.

number

[0091] In this example, the signing requirement is the signer's public key (PK). signer1 PK signer2 It can be said that this is defined in the lock script by including the signature transaction TXID. 2A and TXID 2B Each contains the hash of the document signature.

number

[0092] Signature Transaction TXID 2A and TXID 2B The hash of the signature provided in the lock script is sometimes called the signature representation. The lock script may contain a signature representation that satisfies the signing requirements in another form, for example, a plain signature.

number

[0093] This method can also be used for non-cryptographic signature requirements. In such embodiments, the document signature requirement may include an identifier of signer 103b instead of the signer 103b's public key. The lock script for the signing transaction includes a signature that satisfies the non-cryptographic signature requirement. This signature is generated by the signer and provided to the DSA when approving the generation of the signing transaction. For example, the signature requirement may be satisfied by a plaintext signature or an image of a plaintext signature. The signer generates this signature and provides the DSA with this signature or a hash of it for inclusion in the lock script for the signing transaction. Alternatively, the DSA may store the signer's plaintext signature or an image of it and include it in the lock script for the signing transaction in response to an approval message. A plaintext signature, an image of a plaintext signature, or a hash of these may be referred to as a signature representation.

[0094] This method can also be used in unmanaged DSA systems. In such embodiments, the signer is the PK signer1 It holds the private key corresponding to PK1.

[0095] DSA generates TXID'1 as shown above, or according to any variation thereof. That is, PK signer1 This can be the signer's public key or the signer's identifier in a non-cryptographic signature scheme. In any case, PK signer1 This is a document signature requirement and identifies the signatory.

[0096] PK signer1 This, along with the document representation, is provided in the first lock script of TXID'1. The first lock script is configured to store both the signature requirements and the document representation on the blockchain.

[0097] TXID'1 also has a second lock script that locks a UTXO to the signer's public key PK. Here, the UTXO is a very small amount of cryptocurrency, sometimes only enough to cover transaction fees.

[0098] DSA sends TXID'1 to a node on the blockchain network to include it in a blockchain block.

[0099] The signer accesses TXID'1, verifies that the representation of the document provided in the lock script matches the document to be signed, and signs the document, fulfilling the document signing requirements.

number

[0100] The signer also signs the transaction TXID 2A A TXID containing a signature generated based on the private keys corresponding to PK1 and SIG1, which are used to sign the TXID. 2A Generates the initial unlock script.

[0101] Therefore, the signatory signs the document.

number

[0102] 1.4 DSA Extension There are several ways to extend DSA, as follows: The document creator can set the signing method used by the document's signers. For example, different signing schemes can be used. • Pay the signatory or notary of the document in Satoshi. • Allow signatories to have different roles. • Provide additional fields that need to be filled in, such as witness information. • Provides an envelope for multiple documents to be signed. • Supports multiple organizations, for example, each with its own users and transaction funds. • Use zero-knowledge proofs instead of document hashes.

[0103] When signing multiple documents, a document transaction may include individual commitments to each document or a single commitment to all documents. For example, it may include hashes for each document or a concatenated hash of all documents. Which is included depends on the signing requirements. For instance, if signing some documents is valid but signing the entire set is not, individual hashes will be provided. However, since the documents are likely to be signed as a set, a single (Merkle root) hash of the documents can be used. This is a setting that the requester can choose when requesting document signatures.

[0104] It will be understood that any known type of zero-knowledge proof can be used in the methods provided herein. Zero-knowledge proofs can be used to verify that a DSA and a requester, or a DSA and a signer, refer to the same document. The use of zero-knowledge proofs provides a means of referring to a document to be signed without revealing the document data.

[0105] Note that zero-knowledge proofs can be derived from document hashes.

[0106] 1.5 Separate Document Storage The orchestrator and document store may not communicate directly; that is, a DSA system may contain only an orchestrator. The purpose of separating these two components is to prevent the DSA from accessing documents and to improve system security. The DSA can only access the document hash, i.e., zero-knowledge proof. Users can choose a trusted document store to store confidential documents. Furthermore, users can register an account with the DSA using a managed or unmanaged solution.

[0107] The isolation system can be implemented using one of the managed, unmanaged, or secure enclave DSAs described herein.

[0108] 1.5.1 Document Preparation Figure 10 shows an example of the process for preparing documents in a separated embodiment. User 103a uploads a document to the trusted document store 1004 and provides a link to the document to signer 103b. User 103a uploads the document hash to the DSA system 1000. The orchestrator 1002 generates a document ID associated with the uploaded document hash and sends it to user 103a. User 103a adds the signer's information to DSA1000. Orchestrator 1002 verifies the added signer information against the registered signer ID. Orchestrator 1002 publishes a signature request transaction containing the document hash and a public key linked to signer 103b. When a request transaction is used, orchestrator 1002 updates the transaction ID linked to the document ID.

[0109] 1.5.2 Document Signature The document signing process is similar to the process described in Section 1.1.3 (Controlled) or Section 1.2.4 (Uncontrolled). The only difference is that the signer receives the document link prior to, and independently of, the signature request notification from the DSA.

[0110] 1.5.3 Final Decision on the Document Even if document storage is separated, the final decision-making process for documents remains unchanged.

[0111] 1.5.4 Implementation challenges and their solutions One problem is that the orchestrator needs to know the public keys of all signers before creating a transaction for signing. If the DSA system is a managed system, this problem can be solved because the key pairs can be generated as soon as the signers are notified. However, in an unmanaged system, it is necessary to ensure that the public keys of all signers are known. If they are not known, the orchestrator needs to ask the signers to register their public keys before sending the signing request.

[0112] Another issue is that the solution assumes the key pair used to sign a blockchain transaction is the same as the key pair used to sign a document. In most cases, this is not a problem. However, in some cases, a signature request may require the use of a specific signature scheme different from the one used on the blockchain. In this case, the signer can either generate a key pair corresponding to the specific signature scheme and link it to the key pair used on the blockchain, or send a signed instruction to an orchestrator to generate a key pair for the specific signature scheme and request a signature. The signature scheme is not limited to ECDSA; any public-private-key pair scheme can be used.

[0113] The final potential problem arising from this solution is privacy concerns due to the reuse of key pairs. One way to address this is to derive an unlimited number of keys while ensuring that each key pair used is linked to an authenticated key pair.

[0114] 2. Example of a system overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0115] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0116] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0117] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0118] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0119] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0120] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0121] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind 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.

[0122] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0123] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0124] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0125] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0126] Any given blockchain node can be configured to perform one or more of the following actions: transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, a node can specialize in a particular action. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0127] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 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 a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0128] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain network 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0129] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0130] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and provided 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 such as a CD or DVD ROM, or removable optical drive.

[0131] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0132] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0133] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0134] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by the nodes of that network and is constantly updated. In such a system, transactions are ordered using the account’s transaction execution record (also called a “position”). This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0135] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction that references the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0136] 3. UTXO base model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0137] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0138] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding 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 blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0139] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0140] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

[0141] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it might include Bob's signature. The unlock script appears in transaction input 202.

[0142] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A ] is the public key P from Alice's public key-private key pair. AThe input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A It includes Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by a lock script, by a node protocol, or a combination of these.

[0143] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0144] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0145] Typically, the input to a transaction is the public key P A This includes a corresponding digital signature. 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 some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0146] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all blockchain applications that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0147] 4.Addendum Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0148] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0149] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the preferred Bitcoin network 106).

[0150] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0151] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104.

[0152] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0153] Please note that the embodiments described above are illustrative. More generally, methods, apparatus, or programs can be provided in accordance with any one or more of the following statements.

[0154] Statement 1. A computer implementation method for signing a document in a document signing system, comprising the steps of: receiving a signature request from a requester, which includes an identifier of a signer and identifies the document; obtaining a commitment to the document; generating a document blockchain transaction, wherein the document blockchain transaction includes a commitment to the document and a document signing requirement associated with the signer, and the document is signed by satisfying the document signing requirement; making the document blockchain transaction available to one or more nodes of a blockchain network; receiving a signature approval message from the signer; generating a signature blockchain transaction in response to receiving the signature approval message, wherein the signature blockchain transaction includes a signature associated with the signer, and the signature satisfies the document signing requirement; and making the signature blockchain transaction available to one or more nodes of a blockchain network.

[0155] Statement 2. The method according to Statement 1, further comprising the steps of: obtaining a private key associated with a signer from a keystore in response to receiving a signature approval message; and using the obtained private key associated with the signer to generate a signature for a signature blockchain transaction.

[0156] Statement 3. The method described in Statement 2, wherein the keystore is stored in the document signing system.

[0157] Statement 4. The method of any of Statements 1-3, wherein a document blockchain transaction is configured to verify that the signature satisfies the document signing requirements when executed together with a first lock script containing the document signing requirements and a first unlock script for a signing blockchain transaction.

[0158] Statement 5. The method according to Statement 4, wherein the first unlock script for a signature blockchain transaction includes a signature, and the first unlock script is configured to satisfy the document signing requirement when executed together with the document blockchain transaction.

[0159] Statement 6. The method according to any one of Statements 1 to 3, wherein a document blockchain transaction has a first lock script containing a document signing requirement, and the first lock script is configured to store the document signing requirement on the blockchain at runtime.

[0160] Statement 7. The method according to Statement 6, wherein a signature blockchain transaction has a first lock script containing a signature representation that satisfies the document signing requirements, and is configured to store the signature representation on the blockchain.

[0161] Statement 8. The method described in Statement 7, wherein the representation of the signature is the hash of the signature.

[0162] Statement 9. The method of Statement 7 or 8, which is subordinate to Statement 1, further comprising the steps of receiving from a signer a signature or representation of a signature which is associated with the signer and satisfies the requirements for document signing, and providing a signature to a first lock script of a signing blockchain transaction.

[0163] Statement 10. The method described in Statement 9, wherein a signature or representation of a signature is received in a signature approval message.

[0164] Statement 11. The method according to any of Statements 6-10, wherein the step of generating a document blockchain transaction includes the step of providing a commitment to the document in a first lock script, and the first lock script is further configured to store the commitment to the document on the blockchain.

[0165] Statement 12. The method according to any of Statements 6-11, wherein the step of generating a document blockchain transaction includes the step of providing a second lock script, the second lock script being configured to verify the signature provided in the unlock script for the signature blockchain transaction when executed together with the unlock script for the signature blockchain transaction, and the signature provided in the unlock script for the signature blockchain transaction being generated based on the private key of the document signing service.

[0166] Statement 13. The method described in any of Statements 1-12, wherein a signature approval message is received from the signer after the document blockchain transaction has been included in a block by a node on the blockchain network.

[0167] Statement 14. The method according to any of Statements 1 to 13, wherein the method includes the step of sending a signature approval request containing the transaction identifier of a document blockchain transaction to a signer, and a signature approval message being received in response to the signature approval request.

[0168] Statement 15. The method of Statement 14, wherein a document is stored in a document store associated with a document identifier for identifying the document, and the method further comprises the step of providing the signer with the document identifier in a signature approval request.

[0169] Statement 16. Any method in any of Statements 1-15, wherein the commitment to the document is the hash of the document or the salted hash of the document.

[0170] Statement 17. The method of any of Statements 1 to 16, wherein a signature request further includes a document identifier for identifying the document, and a commitment to the document is obtained by accessing the document store and retrieving data stored in the document store associated with the document identifier.

[0171] Statement 18. The method according to Statement 16 or 17, wherein the commitment to a document is a hash of the document, the data stored in the document store associated with a document identifier is the document, and the method further comprises the step of generating a hash of the retrieved document, the generated hash being included in the document blockchain transaction.

[0172] Statement 19. The method according to Statement 16 or 17, wherein the commitment to a document is a salted hash of the document, the data stored in the document store associated with a document identifier is the document, and the method further comprises the step of generating a salted hash of the retrieved document, the generated salted hash being included in the document blockchain transaction.

[0173] Statement 20. The method according to Statement 16 or 17, wherein the data stored in the document store in association with a document identifier is a hash of the document or a salted hash of the document, and the retrieved hash of the document or the retrieved salted hash of the document is included in the document blockchain transaction, respectively.

[0174] Statement 21. The method according to any one of Statements 1 to 20, further comprising the steps of receiving a document from a requester and storing at least one of the document, a hash of the document, and a salted hash of the document together with a document identifier that identifies the document in a document store.

[0175] Statement 22. The method of Statement 21, wherein the document is received before a request for signature is received, and the method further comprises the step of providing a document identifier to the requester.

[0176] Statement 23. The method described in Statement 21, which allows a document to be received in a signature request.

[0177] Statement 24. A method of Statement 15 or any statement subordinate to Statement 15, wherein a document is stored in a document store, and the method further comprises the steps of receiving a document identifier from a signer, retrieving a document stored in association with the document identifier from the document store, and providing the document to the signer, wherein a signature approval message is received in response to providing the document to the signer.

[0178] Statement 25. The method according to Statement 24, further comprising a step of determining whether the signatory has the authority to access the document, wherein if the signatory has the authority to access the document, the document is provided to the signatory, and if the signatory does not have the authority to access the document, the document is not provided to the signatory.

[0179] Statement 26. Any method in Statements 1-15 in which the commitment to the document is a zero-knowledge proof.

[0180] Statement 27. The method described in any of Statements 1-15, wherein the commitment to the document is a Merkle tree derived based on the document and document signing requirements.

[0181] Statement 28. The method according to Statement 27, further comprising the steps of receiving a hash of a document or a salted hash of a document from a requester, and storing the hash of a document or a salted hash of a document together with a document identifier that identifies the document.

[0182] Statement 29. A method of any statement that is subordinate to any of Statements 1-8 or any statement that is subordinate to any of Statements 1-8, further comprising the steps of receiving a registration request from a signer including an identifier of the signer, generating a public-private key pair for the signer, and storing the public-private key pair in a keystore in association with the identifier of the signer, wherein the private key is used to generate a signature.

[0183] Statement 30. The method according to any of Statements 3-5 and Statement 29, wherein the step of generating a document blockchain transaction includes the steps of obtaining a public key associated with a signer from a keystore and providing a first lock script derived based on the public key associated with the signer.

[0184] Statement 31. The method according to Statement 30, wherein the step of generating a document blockchain transaction includes the step of providing the blockchain with a second lock script configured to store a commitment to the document.

[0185] Statement 32. The method according to Statement 31, further comprising the step of providing a third lock script, wherein the third lock script is configured to verify the signature provided in the second signature blockchain transaction when executed together with the unlock script for the second signature blockchain transaction.

[0186] Statement 33. The method according to any of Statements 1 to 32, further comprising the step of storing an identifier for a document blockchain transaction in association with a document identifier for identifying a document.

[0187] Statement 34. The method of Statement 33, further comprising the step of storing an identifier for a signed blockchain transaction in association with a blockchain transaction identifier and a document identifier.

[0188] Statement 35. A computer device comprising a memory having one or more memory units and a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 34.

[0189] Statement 36. A computer program, embodied on computer-readable storage, configured to perform any method described in Statements 1 to 34 when executed on one or more processors. [Explanation of Symbols]

[0190] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output

Claims

1. A computer implementation method for signing a document in a document signing system, The steps include receiving a signature request from the requester, which includes the signer's identifier and identifies the document, Steps to obtain commitment to the aforementioned document, A step of generating a document blockchain transaction, wherein the document blockchain transaction includes the commitment to the document and a document signing requirement associated with the signer, and the document is signed by satisfying the document signing requirement. The steps include making the aforementioned document blockchain transaction available to one or more nodes in the blockchain network, The step of receiving a signature approval message from the aforementioned signer, A step of generating a signed blockchain transaction in response to receiving the aforementioned signature approval message, wherein the signed blockchain transaction includes a signature associated with the signer, and the signature satisfies the document signing requirements. The steps of making the signed blockchain transaction available to one or more nodes of the blockchain network. A method that includes [a certain feature].

2. The method described above is The steps include: obtaining the private key associated with the signer from the keystore in response to receiving the aforementioned signature approval message; The steps include generating the signature of the signature blockchain transaction using the acquired private key associated with the signer, and The method according to claim 1, further comprising:

3. The method according to claim 2, wherein the key store is stored in the document signing system.

4. The method according to any one of claims 1 to 3, wherein the document blockchain transaction includes a first lock script which includes the document signing requirements, and is configured to verify that the signature satisfies the document signing requirements when executed together with a first unlock script which includes the signing blockchain transaction.

5. The method according to claim 4, wherein the first unlock script for the signature blockchain transaction includes the signature, and the first unlock script is configured to satisfy the document signing requirement when executed together with the document blockchain transaction.

6. The method according to any one of claims 1 to 3, wherein the document blockchain transaction has a first lock script that includes the document signing requirement, and the first lock script is configured to store the document signing requirement on the blockchain when executed.

7. The method according to claim 6, wherein the signature blockchain transaction has a first lock script which includes a representation of the signature that satisfies the document signing requirement, and is configured to store the representation of the signature in the blockchain.

8. The method according to claim 7, wherein the representation of the signature is a hash of the signature.

9. The method described above is The steps include receiving from the signatory a signature or a representation of the signature that is associated with the signatory and satisfies the document signing requirements, The steps include providing the signature to the first lock script of the signature blockchain transaction and The method according to claim 7 or 8, which is dependent on claim 1, further comprising the above.

10. The method according to claim 9, wherein the signature or the representation of the signature is received in the signature approval message.

11. The method according to any one of claims 6 to 10, wherein the step of generating the document blockchain transaction includes the step of providing the commitment to the document in the first lock script, and the first lock script is further configured to store the commitment to the document in the blockchain.

12. The method according to any one of claims 6 to 11, wherein the step of generating the document blockchain transaction includes the step of providing a second lock script, the second lock script being configured to verify the signature provided in the unlock script for the signature blockchain transaction when executed together with the unlock script for the signature blockchain transaction, and the signature provided in the unlock script for the signature blockchain transaction is generated based on the private key of the document signing service.

13. The method according to any one of claims 1 to 12, wherein the signature approval message is received from the signer after the document blockchain transaction has been included in a block by a node in the blockchain network.

14. The method described above is The steps include sending a signature approval request to the signer, which includes the transaction identifier of the aforementioned document blockchain transaction, The method according to any one of claims 1 to 13, wherein the signature approval message is received in response to the signature approval request.

15. The document is stored in a document store associated with a document identifier for identifying the document, and the method is The method of claim 14, further comprising the step of providing the signer with the document identifier in the signature approval request.

16. The method according to any one of claims 1 to 15, wherein the commitment to the document is a hash of the document or a salted hash of the document.

17. The method according to any one of claims 1 to 16, wherein the signature request further includes a document identifier for identifying the document, and the commitment to the document is obtained by accessing a document store and retrieving data stored in the document store in association with the document identifier.

18. The commitment to the document is the hash of the document, the data stored in the document store associated with the document identifier is the document, and the method is The step further includes generating a hash of the retrieved document, The method according to claim 16 or 17, wherein the generated hash is included in the document blockchain transaction.

19. The commitment to the document is the salted hash of the document, the data stored in the document store in association with the document identifier is the document, and the method is The process further includes a step of generating a salted hash of the retrieved document, The method according to claim 16 or 17, wherein the generated salted hash is included in the document blockchain transaction.

20. The method according to claim 16 or 17, wherein the data stored in the document store in association with the document identifier is the hash of the document or the salted hash of the document, and the hash of the acquired document or the salted hash of the acquired document is each included in the document blockchain transaction.

21. The method described above is The steps include receiving the document from the requester, The steps include storing at least one of the document, the hash of the document, and the salted hash of the document in a document store, together with a document identifier that identifies the document. The method according to any one of claims 1 to 20, further comprising:

22. The method according to claim 21, wherein the document is received before the signature request is received, and the method further comprises the step of providing the document identifier to the requester.

23. The method according to claim 21, wherein the document is received in the signature request.

24. The document is stored in the document store, and the method is The steps include receiving the document identifier from the signatory, The steps include: obtaining the document stored in association with the document identifier from the document store; The further step is to provide the aforementioned document to the signatory, The method according to claim 15 or any claim dependent on claim 15, wherein the signature approval message is received in response to providing the document to the signatory.

25. The method described above is The further step is to determine whether the signatory has the authority to access the document, If the signatory has the authority to access the document, the document is provided to the signatory. The method according to claim 24, wherein if the signatory does not have the authority to access the document, the document is not provided to the signatory.

26. The method according to any one of claims 1 to 15, wherein the commitment to the document is a zero-knowledge proof.

27. The method according to any one of claims 1 to 15, wherein the commitment to the document is a Merkle tree derived based on the document and the document signing requirements.

28. The method described above is The steps include receiving a hash of the document or a salted hash of the document from the requester, A step of storing the hash of the document or the salted hash of the document together with a document identifier that identifies the document. The method according to claim 27, further comprising:

29. The method described above is The steps include receiving a registration request from the signer, which includes the signer's identifier, The steps include generating a public key-private key pair for the signer, The step further comprises storing the public key-private key pair in a keystore in association with the identifier of the signer, The method according to any of claims 1 to 8 or any claim dependent on any of claims 1 to 8, wherein the private key is used to generate the signature.

30. The step of generating the aforementioned document blockchain transaction is, The steps include obtaining the public key associated with the signer from the aforementioned keystore, A step of providing a first lock script derived based on the public key associated with the signer. The method according to any one of claims 3 to 5 and claim 29, including the method described in any one of claims 3 to 5.

31. The method according to claim 30, wherein the step of generating the document blockchain transaction includes the step of providing the blockchain with a second lock script configured to store the commitment to the document.

32. The method according to claim 31, further comprising the step of providing a third lock script, wherein the third lock script is configured to verify the signature provided in the second signature blockchain transaction when executed together with an unlock script for the second signature blockchain transaction.

33. The method according to any one of claims 1 to 32, further comprising the step of storing an identifier for the document blockchain transaction in association with a document identifier for identifying the document.

34. The method according to claim 33, further comprising the step of storing the identifier of the signed blockchain transaction in association with the identifier of the blockchain transaction and the identifier of the document.

35. A memory having one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 34.

36. A computer program, which is implemented on computer-readable storage, and which, when executed on one or more processors, is configured to perform the method described in any one of claims 1 to 34.

Images