Blockchain transactions

Abstract

This specification provides a computer implementation method for requesting a document signature in a document signing system. A signature request is received from a requester, and the signature request includes an identifier for the signer and an identifier for 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 a document signing requirement associated with the signer, and the document is signed by satisfying the document signing requirement, which is provided in the lock script of the document blockchain transaction and identifies the signer. The document blockchain transaction is made available to one or more nodes of the blockchain network.

Description

[Technical Field]

[0001] This disclosure relates to a computer implementation method for requesting a document signature from a document, a computer implementation method for generating a signature from a document, and computer equipment and programs for carrying out the methods. [Background technology]

[0002] A document signing application (DSA) provides a platform for users to digitally sign documents.

[0003] One known application is DocuSign®. DocuSign integrates with assistive technologies, mobile signatures, Microsoft®, Google®, and Dropbox®. This enables individuals and organizations 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: • SMS Two-Factor Authentication: DocuSign texts an authentication code to the recipient's mobile phone, and the recipient enters the code to begin signing. This complements existing DocuSign authentication options, including email access codes, phone calls, and knowledge-based authentication (KBA). • ePadlink Signature Pad Integration: The DocuSign Signature Pad option enables signing and signature adoption using a signature pad. In subsequent releases, DocuSign will add support for the ePadLinke Pad-ink (VP9805) signature pad device. • eWitness: Allows users to add electronic signatures and act as witnesses to agreements.

[0005] In DocuSign, an envelope is used as a container for documents that a user sends to a recipient for signing. An envelope can contain one or more documents, and one or more signers.

[0006] The envelope has a status (i.e., sent, delivered, completed, invalid) and includes information about the sender and a timestamp indicating the progress of the delivery procedure. • Sender: Creates, sends, and manages DocuSign envelopes. • Signatories: Envelope recipients who are required to act on the envelope or the documents within the envelope. • Fields: These indicate where the signatory needs to take action on the document. For example, filling in data, selecting a signature, or applying a signature. • Browsing / Signing Session: Session information.

[0007] However, DocuSign signatures are not generated using any arbitrary signature scheme; in fact, DocuSign simply stores an image of the signature. Users register their email address with DocuSign, upload documents, and sign them using the signature image. DocuSign also centrally manages all documents for the user. This puts documents at risk if a customer's email address is hacked and lost, and that lost address is used in a phishing attack.

[0008] To mitigate this risk, DocuSign uses various security measures to keep its servers secure: Physical security for data centers Network security measures such as firewalls and intrusion detection systems Encryption for both data storage and data transmission. Access control to restrict unauthorized access Regular security audits and penetration testing Compliance with industry security standards (e.g., SOC2, ISO27001) Furthermore, DocuSign's Electronic Notary feature requires the sender to have the document notarized by the person themselves. This is also known as the eWitness feature (eWitness in the UK and Notary in the US).

[0009] DocuSign provides the following APIs: · eSignature API: 400 endpoints for signing in workflows · Notary API: Notary-specific endpoints · Click API: A REST API for capturing consent to standard terms with a single click · Rooms API: Rationalize complex contracts via a secure digital workspace · Monitor API · Admin API · Salesforce Apex Toolkit

[0010] The following describes the process for preparing and signing a document implemented in DocuSign. 1. Document upload: The user uploads the document that needs to be signed to the DocuSign platform. 2. Add recipients: The user adds the recipients' email addresses and specifies the roles for signing (e.g., signer, reviewer, etc.). 3. Customize the signing order: The user can specify the order in which recipients sign the document. 4. Add signing fields: The user can add signatures, initials, and other fields to the document as needed. 5. Send the document: The user sends the document to the recipients for signing. 6. Signature Process: The recipient receives an email containing a link to the document and instructions on how to sign it. The user can review the document and add their electronic signature using a mouse, stylus, or finger on a mobile device. 7. Completed Document: 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.

[0011] There are numerous standards that have been introduced for eSignatures.

[0012] The ESIGN Act is a U.S. federal law passed in 2000. It gives legal recognition to electronic signatures and records whether all parties to a contract have chosen to use electronic documents and sign them electronically. The requirements of the Uniform Electronic Transactions Act (UETA) and the ESIGN Act state that each electronically signed document must comply with the following: • Intent to sign: A signature on an electronic document is only valid if the document and its sections are fully clear and the signature was made with intent. • Implicit or explicit consent to electronically sign: All electronic document / signature platforms should include a clause stating that the client consents to electronically sign this consent. Users can further this by including a checked consent box or verification step at the time of signing. • Signature Attribution: Users maintain a digital audit trail that associates signatures with a unique signer, such as a timestamp, email address, and IP address. • Signature protection: All signatures must be securely attached to the document and not stored separately. Signed documents should be stored in an encrypted environment and not transmitted to anyone other than the parties involved. • Copy sent to the signer: Once a document is signed, a copy of the document containing the signature must be sent to the client. • Record keeping: Users must retain a signed copy of each document that is duplicated when needed. • Opt-out clause: Clients should always have the opportunity to opt out of digital signatures in order to sign paper contracts. While digital is the new standard, clients should always have a paper backup in case someone chooses this route.

[0013] eIDAS (Electronic Identification, Authentication and Trust Services) has created standards that enable electronic transactions where electronic signatures, qualified digital certificates, electronic seals, timestamps, and other certifications for authentication mechanisms have the same legal status as transactions conducted on paper. • Advanced electronic signatures: An electronic signature is considered advanced if it meets the following specific requirements: A digital signature provides unique identification information that links the digital signature to the signer. The signer manages the data used to create the electronic signature independently. It must be possible to determine whether the data accompanying the message has been tampered with after it was signed. If the signed data is modified, the signature will be marked as invalid. +There are electronic signature certificates that verify the identity of the signer and link 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, as defined by the European Telecommunications Standards Institute (ETSI). A qualified digital signature is a sophisticated digital signature created by a qualified digital signature generator based on a qualified certificate for digital signatures. • A qualified digital certificate for electronic signatures, a certificate that certifies the authenticity of a qualified electronic signature issued by a qualified and trusted service provider.

[0014] All organizations distributing public digital signatures while being EU members must recognize the electronic identification from all EU member states. It should be noted that this means certificates used in closed systems are exempt from eIDAS.

[0015] Other digital signature standards include: • Switzerland: ZerES digital signature standard • US: NIST Digital Signing Standard (DSS) • UK: The eIDAS regulation provides a legal framework for the use of electronic credit services offered within the UK and 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 standards by which electronic records and electronic signatures are considered reliable, trustworthy, and equivalent to paper records. [Overview of the project]

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

[0017] Blockchain provides the following characteristics to DSA: • Accessibility: All documents and signature records are stored on a distributed ledger, which can improve security and accessibility. • Immutable record keeping: Transactions on the blockchain are permanent, unalterable, and guarantee the integrity of documents and signatures. • Smart contracts: The execution of automated contracts can be triggered based on the fulfillment of specific conditions, such as the completion of all required signatures. • Digital signatures: Digital signatures can be created using public-key cryptography, enabling secure and verifiable electronic signatures.

[0018] By utilizing these characteristics of blockchain, the DSA system provided in this specification can offer a secure and efficient solution for signing and managing electronic documents.

[0019] According to one aspect disclosed in this specification, a computer implementation method for requesting a document signature of a document, wherein in a document signature system, A step of receiving a signature request from a requester, wherein the signature request includes an identifier of the signer and identifies the document, The steps include obtaining a 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, the document is signed by satisfying the document signing requirement, the document signing requirement is provided in the lock script of the document blockchain transaction and identifies the signer, The steps include making the aforementioned document blockchain transaction available to one or more nodes in the blockchain network, A method including this is provided. [Brief explanation of the drawing]

[0020] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the following appended drawings are referenced only as examples. [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This provides a schematic overview of some examples of transactions recorded on the blockchain. [Figure 3] This outlines the DSA signing process. [Figure 4] This provides an exemplary method for preparing documents in a managed DSA system. [Figure 5] This provides an exemplary method for signing documents in a managed DSA system. [Figure 6] This document provides an exemplary method for registering users in an unmanaged DSA system. [Figure 7] This provides an exemplary method for signing documents in an unmanaged DSA system. [Figure 8] This provides an exemplary method for finalizing documents in an unmanaged DSA system. [Figure 9] An example Merkle root structure for a signed document is shown. [Figure 10A] This provides an exemplary method for preparing documents in a separate document storage environment. [Figure 10B] This provides an exemplary method for preparing documents in a separate document storage environment. [Modes for carrying out the invention]

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

[0022] The DSA system has two main components: • Orchestrator: Workflow management solution • Document store: A database for storing documents and / or hash values ​​of documents. The orchestrator is also referred to as the document signature system in this specification.

[0023] The document store and the orchestrator may communicate directly, or they may be separate.

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

[0025] The DSA signing process can be carried out in two ways: • Custodial Management: The system manages key pairs and signing workflows on behalf of the user, under the user's instructions. • Non-custodial: The system allows users to sign blockchain transactions to prove that they have signed a document. An email link containing the document ID is sent to the signer's email address. It will be understood that access to the document may be provided to the signer by another method that is obvious to those skilled in the art. Once the signer verifies the document, the signer signs the transaction and issues it. The signer's signature is included in the transaction's unlock script to provide a record of the signature. The signature in the unlock script does not necessarily have to be the same as the signature on the document.

[0026] 1.1 Management DSA In a managed DSA, the orchestrator is responsible for generating signatures to sign documents on behalf of the signers.

[0027] An orchestrator may have one or more of the following abilities: • 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 who can view and sign documents. Users must be registered with the system. • To enable seamless integration with existing workflows, it provides interoperability with other systems such as cloud storage services, email systems, and certificate authorities. • The ability to be hosted by a cloud provider or within the customer's premises. This ensures that DSA appeals to as many customers as possible. • The ability to delete documents in order to comply with the right to be forgotten under the GDPR.

[0028] Furthermore, the management DSA must specify the following: • The location where documents are stored. Document retention period. • The orchestrator can support document signing using blockchain transactions.

[0029] 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 by specific signers to sign documents, and therefore the signer must know the DSA system before signing.

[0030] Registration can be performed by entering an email address, creating a password on the DSA interface, and thereby generating a user profile. Once a user is registered with the DSA system, the user can authenticate themselves before creating a signing request or signing a document. The DSA system creates a key pair and a public key (e.g., PK). signer The DSA assigns the associated private key to the registered user. The DSA holds the associated private key in its keystore and uses it to sign the signing transactions associated with the document on behalf of the user.

[0031] 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 a document for signing and defines the signing requirements that must be met by the signers.

[0032] If a signer is registered after a document transaction has been generated, the DSA generates a public-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 associated with the user profile, and the public key is provided to the user.

[0033] 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. An example of selecting a document to upload is provided in this specification to illustrate the process. This can be applied to the option of uploading a document hash.

[0034] Users upload the document to be signed to the DSA platform, add the recipient's email address or other identifier, and specify the roles of those signing (e.g., signer, reviewer, etc.). Optionally, users can also specify the order in which recipients sign the document and add their signature fields.

[0035] Further details are shown in Figure 4. In the example in Figure 4, the DSA system 400 includes both an orchestrator 402 and a document store 404, and as a result, 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 signature request transaction TXID1 as described below and issues the transaction to the blockchain. A signature request transaction is also called a document blockchain transaction in this specification. The lock script of TXID1 contains the hash value of the document as a data payload using OP_FALSE OP_RETURN. TXID1 is signed by two signers (PK signer1 PK signer2 This indicates that the signer can independently sign the 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 and the transaction ID of the document transaction. 10. The orchestrator 402 notifies user 103a that the document has been prepared for signing. This may be done, for example, by email or notification via the DSA portal or user interface. [Table 1]

[0036] TxID1 is an exemplary document blockchain transaction template for requesting a document signature. The transaction includes three outputs. The first output contains the first lock script, which stores the document hash on blockchain 150 and makes the output unavailable.

[0037] The other two outputs include the signature requirements for signing the document. In this example, the signature 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.

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

[0039] The first lock script contains a hash of the document. The hash of the document is sometimes referred to in this specification 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.

[0040] 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.

[0041] Other commitments to the document may also be used, in which case the commitment is derived from the document and can be used to verify that a copy of the document is authentic. Another example may be a zero-knowledge proof associated with the document, or a Merkle root derived from the document as described in Section 1.3. Any other known method of communication between the DSA and the signatory about the same data but without disclosing the data or its details may be used as a commitment to the data in the manner provided in this specification.

[0042] In the example above, document store 404 stores the document along with its document ID. In some embodiments, document store 404 may store a hash of the document instead of, or in addition to, the document. In this embodiment, orchestrator 402 may haveh the document before receiving it from user 103a and providing the hash to document store 404 for storage.

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

[0044] The transaction ID of a document transaction may be stored in the orchestrator 402 in association with the document ID, or in the document store 404 together with the document ID and the document or the hash of the document.

[0045] 1.1.3 Document Signature Once a document transaction is recorded on blockchain 150, signer 103b (or multiple signers) receives a notification or request indicating that the signer's authorization is required. In some examples, user 103a can send a request to signer 103b outside of DSA 400. For example, user 103a may send a document to signer 103b, notify the signer that the document can be signed on DSA 400, provide the signer with a link to sign the document on DSA 400, or provide a document ID so that signer 103b can access the document from document store 404.

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

[0047] 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 unlock script for a signing blockchain transaction that contains a signature generated using the private key associated with signer 103b. This means that the UXTO of TXID1 is consumed to sign the document.

[0048] The signature provided in the unlock script for a signed blockchain transaction serves a dual purpose: to sign the document and to unlock the UTXO. The signature is a cryptographic signature.

[0049] An example of the signature process is shown in Figure 5. 1. The document notification is sent from the DSA system 400 to signer 103b to request a signature. The notification includes the document ID. 2. Signer 103b logs into DSA system 400. 3. DSA400 authenticates signer 103b and views the document ID and transaction ID TXID1. 4. Signer 103b requests the document associated with the document ID. 5. The 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 on DSA400 to notify signer 103b that the operation was successful.

[0050] In step 3, signer 103b may submit a signature authorization request. This request may be a message sent to signer 103b. The signature authorization request may include a document transaction identifier, thereby enabling signer 103b to access the document transaction stored on blockchain 150. The signature authorization request may also include a document ID to enable signer 103b to access the document from document store 404 independently of orchestrator 402.

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

[0052] In another embodiment, signatory 103b is directly provided with a copy of the document by user 103a, who requests that the document be signed.

[0053] In some embodiments, signer 103b may request access to the document using a document transaction ID. DSA 400 uses this to determine the document ID associated with the transaction ID, retrieve the associated document, and provide it to signer 103b.

[0054] 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 searches for the document in the document store 404, hashes the document, and checks that the document hash in the document transaction matches the hash of the document generated by Signer 103b. If the hashes match, Signer 103b then grants Orchestrator 402 the authority to sign the document.

[0055] In another embodiment, the commitment to a document may be a Merkle tree derived from the document and signature requirements, as shown, for example, in Section 1.3. To verify the commitment to a document, signer 103b may reconstruct the Merkle tree based on the document and signature requirements to which he / she has access and check that the Merkle trees match. Alternatively, signer 103b may obtain Merkle certificates corresponding to the documents in the Merkle tree and calculate a Merkle root based on the documents and Merkle certificates. If the calculated Merkle root matches the Merkle root of the document transaction, signer 130b can confirm that the document of the commitment is the same one he / she intends to sign and authorize orchestrator 402 to sign the document.

[0056] Signer 103b grants orchestrator 402 the authority to sign the document in the signature authorization message.

[0057] When orchestrator 402 receives a signature authorization message, it searches the keystore for the private key of signer 103b in order to generate the signature.

[0058] In the method described above, the DSA authenticates signer 103b before allowing signer 103b to view the requested data. This authentication can be performed using any known method, such as through a username and password or the use of two-factor authentication.

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

[0060] 1.1.4 Finalizing Documents Once all signatures are complete on the transaction, orchestrator 402 can create a document audit trail and notify all involved parties. The document audit trail includes the following details of the document signers: • Email ·name ·signature ·date

[0061] 1.2 Unmanaged DSA In an unmanaged DSA, the orchestrator is not responsible for generating signatures to sign documents on behalf of the signers. In other words, an unmanaged DSA allows the user to manage their own key pair for document signing, rather than relying on the orchestrator. This is achieved by securely hosting the keys using a wallet.

[0062] 1.2.1 Wallet If the wallet is associated with an unmanaged solution, the following requirements should be met: • A wallet can use the owner's private key to sign transactions associated with a document. • The wallet securely stores private keys. • The wallet owner's public key is registered via an X.509 certificate to verify their identity. The CA issuing the X.509 certificate must be recognized by the organization requesting the document signing. The certificate uses the secp265k1 key pair.

[0063] 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 for document signing. 2. User 103a registers an account with DSA600 using their email address, certificate, and other information. The certificate includes user 103a's public key. 3. The DSA600 records user information and creates an account. 4. User 103a sets a password for that account. 5. The DSA600 stores a hash of the password related to the user's email address.

[0064] Furthermore, in the following process, user 103a may act as a signer. That is, signer 103b registers their certified public key and email address on the DSA platform 600 in the same manner. This allows the DSA system 600 to generate and issue a signature request transaction on behalf of signature requester 103a.

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

[0066] The public key, user identifier, and key certificate may 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.

[0067] Orchestrator 602 may verify that the certificate was generated by CA606 before storing the key. The certificate may also be signed by CA606, and the verification may include checking that the signature is from CA606.

[0068] 1.2.3 Document Preparation The document preparation steps are described in Section 1.1.2 and are similar to the management solution shown in Figure 4. Note that the public keys of the registered and authenticated signers in Section 1.2.2 are stored by the DSA600.

[0069] The following processes may be carried out: 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 certified signer's public key against the signer's email address. 4. Orchestrator 602 creates and issues signature request transaction TXID1, which locks the output to the signer's certified public key and includes the document hash as the data payload using OP_FALSE OP_RETURN. Note that the UTXO of TXID1 can only be used by signer 103b. 5. Orchestrator602 adds a transaction ID associated with the document ID. 6. Orchestrator 602 notifies user 103a that the document is ready for signing.

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

[0071] As described in Section 1.1.2, the document store 604 may store documents and / or document hashes and / or zero-knowledge proofs associated with documents in relation to the document ID. Therefore, commitments to documents included in a document transaction may be retrieved from the document store 604 or calculated based on the retrieved data.

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

[0073] 1.2.4 Document Signature Once a document transaction is recorded on blockchain 150, signer 103b (or multiple signers) will receive a notification or request indicating that their signature is required. Alternative methods for notifying signer 103b are described in 1.1.3, and other appropriate methods for notifying signer 103b may be used.

[0074] In contrast to the management system in Section 1.1, signer 103b signs the document and generates a signature to satisfy the document signing requirements of the document transaction via its own wallet 608. This is because DSA 600 does not store or has access to the signer's private key necessary to sign the document. Using the example in Section 1.1.2, the signing requirement is satisfied by the unlock script of the signing blockchain transaction, which contains the signature generated using signer 103b's private key. This means that the UXTO of TXID1 is consumed to sign the document. The alternative forms provided in Section 1.1.3 also apply to non-management systems.

[0075] Signer 103b receives the document ID from DSA600 and performs the following steps to sign it: 1. Connect to wallet 608 and check 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 one in the transaction. 4. Issue a new transaction TXID2. This consumes the UTXO of TXID1. TXID2 certifies that signer 103b signed the document.

[0076] As in the previous example, the commitment to the document is the document hash. Other possible commitments are provided in this specification.

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

[0078] 1.2.5 Finalizing Documents The document finalization stage in an unmanaged DSA is similar to that in a managed solution. The only difference is that the orchestrator 602 needs to monitor blockchain 150 to determine whether TXID2 is valid.

[0079] 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. 2. The DSA600 reports the status by sending a notification to user 103a that includes the document ID and audit trail. 3. DSA600 also sends a notice to signatory 103b containing the document ID and audit trail.

[0080] 1.3 Secure Enclave DSA In the alternative managed DSA system, users and signers do not need to have cryptocurrency (e.g., Bitcoin) accounts. In this embodiment, the signature on the document associated with the signer is separated from the signature provided in the unlock script for the signing transaction.

[0081] In this common scenario, users may prefer to sign documents independently, without signing them along with blockchain transactions. That is, the signer's digital signature should only sign the document, not the blockchain transaction. The DSA, then, signs all transactions itself.

[0082] This approach allows users to use any digital signature scheme of their choice to sign documents. In particular, due to high security requirements, 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 independent of blockchain transactions. It also offers excellent interoperability with existing signature solutions, as most secure enclaves typically do not allow the curve used by Bitcoin.

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

[0084] The signature request transaction can be modified as follows: [Table 2]

[0085] Here, PK1 and PK2 are used by DSA to separate the signature transaction from the document signature. That is, PK1 and PK2 are the public keys owned by DSA. These keys can be linked to or otherwise associated with each of the signer's public keys PK signer1 and PK signer2 or with the signer's identifier. However, any UTXO locked by a lock script containing PK1 and PK2 is locked with the private key of DSA. In this way, signer 103b does not need to have a cryptocurrency account or wallet.

[0086] The data payload containing the signer's public key enables the signature requester to verify the signature on the document without handling any Bitcoin or other cryptocurrency using the public key shown in the request transaction. H(Document) can be replaced by H(salt||Document) or any other type of cryptographic commitment to the document data.

[0087] PK signer1 and PK signer2 The associated private keys are used within DSA to directly sign the document. That is, DSA includes a key store such as the managed DSA system described in Section 1.1 that stores the signer's private key in relation to the signer's user identifier. The signatures are SIG PKsigner1 and SIG PKsigner2 There is no concern that the signature cannot be removed from the public blockchain.

[0088] Alternatively, the signer can store their private key and provide their signature SIG PKsigner1 to DSA when approving the signature transaction to be generated. This signature generated by the signer and provided to DSA is then included in the signature transaction. The signer's private key is likely to be held in a secure enclave or secure hardware module under the signer's control.

[0089] If privacy is an issue, PK signer1 PK signer2 This can be replaced by the cryptographic commitment or hash value of the public key. All public keys can be captured using a Merkle tree. In this case, the Merkle root can be included in the data payload after OP_FASLE OP_RETURN. For example, a Merkle root associated with the public keys of a document and signer can be constructed as follows: H(H(Document)||H(H(PK signer1 )||H(PK signer2 ))) Note that the hash values ​​at the leaves of a Merkle tree do not need to be at the same depth (see Figure 9). The Merkle root can be considered a commitment to the document.

[0090] DSA is a signature transaction TXID 2A Issue and sign transaction TXID 2A This uses the UTXO of TXID1' associated with signer1, and the signature TXID 2A The hash value of TXID is included in the OP_FALSE OP_RETURN output. 2B This is issued to signer2. Note that the hash value can be a salted hash or any cryptographic commitment scheme for privacy. A salted hash can be considered a hash of the document. Also, as with the above, for multiple signatures, a Merkle root can be added to the data payload instead. The user provides a TXID for proof. 2A and TXID 2B Using the above signature is optional. As mentioned above, the unlock script is generated using the private key held and owned by the DSA. [Table 3] [Table 4]

[0091] In this example, the signer's public key, PK signer1 PK signer2 By including this, you can define the signing requirements within the lock script. This requirement is the signing transaction TXID 2A and TXID 2B The hash H(SIG) of each document signature PKsigner1 ), H(SIG PKsigner2 This is satisfied by including ).

[0092] Signature Transaction TXID 2A and TXID 2B The hash of the signature provided within the lock script may be called the signature representation. The lock script may contain a signature representation that satisfies the signing requirements in another form. For example, a plaintext signature SIG as the signature representation. PKsigner1 It may also include.

[0093] This method can 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 may be generated by the signer and provided to the DSA when authorizing the signing transaction to be generated. For example, the signature requirement may be satisfied by a plaintext signature or an image of the plaintext signature. The signer generates this signature and provides the DSA with this signature or its hash to include in the lock script for the signing transaction. Alternatively, the DSA may store the signer's plaintext signature or its image and include it in the lock script for the signing transaction in response to an authorization message. The plaintext signature, the image of the plaintext signature, or a hash of either may be referred to as a signature representation.

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

[0095] The DSA generates TXID1' as described above, or according to any variation thereof. That is, PK signer1 This may be the signer's public key, or it may be 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 within the first lock script of TXID1'. The first lock script is configured to store both the signature requirements and the document representation on the blockchain.

[0097] TXID1' also includes a second lock script that locks the UTXO to the signer's public key PK1. Here, the UTXO is a very small amount of cryptocurrency, sufficient in some examples to cover transaction fees.

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

[0099] The signer accesses TXID1' and verifies that the representation of the document provided within the lock script corresponds to the document expected to be signed, thus fulfilling the document signing requirements. PKsigner1、 In other words, a signature can be generated for a document. The signer has a lock script containing the signature representation, the signature hash in the example above, and a signature transaction TXID. 2A Generates.

[0100] The signatory also has a TXID. 2A Generates the first unlock script for PK1. This includes a signature SIG1 generated based on the private key corresponding to PK1, where SIG1 is the signature transaction TXID. 2A I will sign it.

[0101] Therefore, the signatories are the signature SIGs for the document. PKsigner1 This generates a signature SIG1 for the transaction, thus separating the document signature from the transaction signature.

[0102] 1.4 DSA Expansion There are several ways to extend DSA, including the following: The document sender can set the signature method to be used by the document signer, for example, by using different signature schemes. • Pay a Satoshi to the signatory or notary of the document. • Assign clear roles to signatories. • Provide additional fields that need to be completed, such as witness information. • Provide multiple document envelopes for signing. • Supports multiple organizations, for example, each organization having its own users and transaction funds. • Use zero-knowledge proofs instead of document hashes.

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

[0104] It will be understood that any known type of zero-knowledge proof may be used in the manner provided in this specification. A zero-knowledge proof may be used between a DSA and a requester, or between a DSA and a signer, to verify that both entities refer to the same document. The use of a zero-knowledge proof provides a means of referring to a document to be signed without revealing the document data.

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

[0106] 1.5 Separate Document Storage The orchestrator and document store do not need to communicate directly; that is, a DSA system may include only an orchestrator. The purpose of separating these two components is to ensure that the DSA cannot access documents, thereby improving system security. The DSA can only access the document hash or zero-knowledge proof. Users can select a trusted DocumentStore to store their classified documents. Furthermore, users can register an account with the DSA using managed or unmanaged solutions.

[0107] The isolated system may be implemented using any of the controlled, uncontrolled, or secure enclave DSAs described in this specification.

[0108] 1.5.1 Document Preparation Figure 10 shows an exemplary process for preparing documents in a separated embodiment. User 103a uploads the document to the trusted DocumentStore 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. The orchestrator 1002 issues a signature request transaction that includes the document hash and the public key linked to signer 103b. When the requested transaction is consumed, 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 before, and independently of, the request for a signing notification from the DSA.

[0110] 1.5.3 Finalizing Documents When document storage is separated, the document finalization step remains unchanged.

[0111] 1.5.4 Implementation Issues and Their Solutions One problem is that the orchestrator needs to know the public keys of all signers before creating a transaction for signing. This problem can be solved if the DSA system is managed, as signers can generate key pairs when notified. However, in non-managed systems, it is necessary to check that all signers' public keys are known. If not, the orchestrator needs to request that signers register their public keys before sending the signing request.

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

[0113] The ultimate problem that may arise 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 a proven key pair.

[0114] 2. Overview of the Exemplary System A blockchain is a form of decentralized data structure in which a copy of the blockchain is maintained and widely published on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter also called a "blockchain network"). A blockchain contains a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence. A sequence may span one or more blocks that trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to a blockchain network are included in a new block. New blocks are generated by a process known as "mining." "Mining" involves each of several nodes competing to perform "proof-of-work," that is, solving a cryptographic puzzle based on the presentation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that a blockchain may be pruned on some nodes, and the publication of a block can be achieved through the publication of only the block header.

[0115] Transactions within a blockchain can be used for one or more of the following purposes: carrying digital assets (i.e., a large number of digital tokens), ordering sets of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or chronologically organizing index pointers. Blockchains can also be used to layer additional functionality on top of them. For example, a blockchain protocol may allow additional user data or indices to be stored within the data of a transaction. There is no predetermined limit on the maximum amount of data that can be stored within a single transaction. Therefore, more complex data can be incorporated. For example, this can be used to store electronic documents, or audio or video data, within the blockchain.

[0116] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any available output includes an element specifying the amount of digital asset that can be derived from a preceding transaction sequence. Available outputs are sometimes called UTXOs (unspent transaction output). Outputs may further include a lock script that specifies the conditions for the future redemption of the output. A lock script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlock script to unlock the lock script of the pointed output. Thus, when considering a pair of transactions, they are called the first transaction and the second transaction (or "target" transaction). The first transaction includes at least one output, which includes a lock script that specifies the amount of digital asset and defines one or more conditions for unlocking the output. The second target transaction includes at least one input, which includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0117] In this model, when a second target transaction is sent to the blockchain network where it is propagated and recorded on the blockchain, one of the validity criteria applied at each node is that the unlock script satisfies all of one or more conditions defined in the lock script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. Any node that finds a target transaction to be invalid due to any of these conditions will not propagate the transaction (as a valid transaction) (although it may register an invalid transaction) nor include it in a new block for recording on the blockchain.

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

[0119] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may include a packet-switched network 101, which is typically a wide-area internetnet such as the internet. The packet-switched network 101 may include a number of blockchain nodes 104 (sometimes called "miners") that can be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled with other blockchain nodes 104.

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

[0121] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple nodes 104 within the decentralized or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from blockchain 150 as long as each blockchain node 150 stores the block header (described later) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0122] A blockchain node 104 may be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. A blockchain node 104 may also be configured to generate block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 may also maintain an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is sometimes referred to as a “mempool.” This term is not limited in this specification to any particular blockchain, protocol, or model. It represents an ordered set of transactions that a node 104 has accepted as valid and that a node 104 is obligated not to accept other transactions attempting to use the same output.

[0123] In a given current transaction 152j, each input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is redeemed or “spent” in the current transaction 152j. Spent or redeemed does not necessarily mean the transfer of a financial asset, but that is certainly one common application. More generally, use 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 the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist when the current transaction 152j is generated or sent to the network 106, but it must exist and be verified for the current transaction to be valid. Thus, in this specification, “preceding” means that which precedes in the logical sequence linked by the pointer, and does not necessarily mean the time of generation or transmission in a time series. Therefore, this does not necessarily preclude transactions 152i and 152j from being generated or sent out of order (see the discussion of orphan transactions below). The preceding transaction 152i can equally be called an antecedent or predecessor transaction.

[0124] For resources related to transaction validation and publication, typically each of the blockchain nodes 104 takes the form of a server or an entire data center, including at least one physical server unit. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals or user terminals that are networked together.

[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 one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any operation belonging to the blockchain node 104 can be performed by software running on the processing unit of each computer device. Node software can be implemented in one or more applications, in lower layers such as the application layer, operating system layer, protocol layer, or any combination thereof.

[0126] Any given blockchain node may be configured to perform one or more of the following operations: verifying transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104; that is, a node may specialize in a particular operation. For example, node 104 may focus on transaction verification and propagation, or on block mining. In some examples, blockchain node 104 may perform two or more of these operations in parallel. Any reference to blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0127] Network 101 is also connected to the computer equipment 102 of several parties 103, each acting as a consumer user. These users can interact with the blockchain network but do not participate in transaction validation or block construction. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of blockchain 150 (e.g., they obtain a copy of the blockchain from a blockchain node 104).

[0128] Some or all of Party 103 may be joined as a part of a different network, for example, a network superimposed on a blockchain network 106. Users of the blockchain network (often called “clients”) can be said to be a part of the system including the blockchain network 106. However, these users are not blockchain nodes 104, as they do not perform the required role of a blockchain node. Instead, each Party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby joining (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: the first party 103a and its respective computer devices 102a, and the second party 103b and its respective computer devices 102b. Many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each Party 103 may be an individual or an organization. For purely illustrative purposes, Party 103a is referred to as Alice in this specification, and Party 2 is referred to as Bob, but this is not restrictive, and it will be understood that any reference to Alice or Bob in this specification can be replaced with "Party 1" and "Party 2," respectively.

[0129] Each computer device 102 of Party 103 includes 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 includes memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium or medium. This memory may include one or more memory units using one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as an SSD, flash memory, or EEPROM, and / or an optical medium such as an optical disc drive. The memory on each computer device 102 of Party 103 stores software including each instance of at least one client application 105 arranged to run on the processing device. It will be understood that any action attributed to Party 103 as given in this specification can be performed using software running on the processing device of each computer device 102. Each computer device 102 of Party 103 includes at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. A given computer device 102 of party 103 may include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0130] The client application 105 may first be provided to the computer equipment 102 of any given party 103 on one or more suitable computer-readable storage media, such as those downloaded from a server, or on removable storage devices such as removable SSDs, flash memory keys, removable EEPROMs, removable magnetic disk drives, magnetic floppy disks or tapes, optical disks, such as CDs or DVD ROMs, or removable optical drives.

[0131] The client application 105 includes at least a “wallet” function, which primarily has two functions. One of these is to enable each party 103 to create, authorize (e.g., sign), and send transactions 152 that are to be propagated across the entire network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report the amount of digital assets currently owned to each party. In an output-based system, this second function includes matching the amount defined in the outputs of various transactions 152 scattered throughout blockchain 150 belonging to that party.

[0132] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting. Instead, any client function described in this specification may be implemented in a suit of two or more different 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, or in a lower layer such as an operating system, or any combination thereof. The following description will be from the perspective of client application 105, but this is not to be understood as limiting.

[0133] Each computer device 102 instance of a client application or software 105 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transaction to which each party 103 is the recipient (or, in this embodiment, inspect the transactions of other parties within the blockchain 150, as the blockchain 150 is a public facility that provides transaction trust in part through its public visibility). The wallet function on each computer device 102 is configured to form and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 in order to propagate transaction 152 across the entire blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 within blockchain 150. The same node protocol is used for all nodes 104 within network 106.

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

[0135] Several account-based transaction models share some similarities with the output-based transaction models described in this specification. For example, as mentioned above, the data fields of an account-based transaction can retrospectively point to previous transactions, which is equivalent to the input of 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 includes a “Recipient” field (where the recipient's address in the account is specified) and a “Value” field (where the amount of digital asset may be specified). Both the recipient and value fields are equivalent to the output of an output-based transaction that can be used to allocate the amount of digital asset to a blockchain address. Similarly, an account-based transaction has a “Signature” field that contains the signature of the transaction. The signature is generated using the sender’s private key and confirms that the sender authorized this transaction. This is typically equivalent to the input / unlock script of an output-based transaction that contains the signature of the transaction. Once both types of transactions are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a “smart contact” refers to a transaction containing a script configured to perform one or more actions (e.g., sending or “releasing” a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) that satisfy one or more conditions defined by the smart contact’s script. A smart contract exists as a transaction on the blockchain and can be invoked (or triggered) by subsequent transactions.Therefore, in some cases, a smart contract can be considered equivalent to a lock script for an output-based transaction that can be triggered by a subsequent transaction, checking whether one or more conditions defined by the lock script are met by the input of the subsequent transaction.

[0136] 3. UTXO-based models Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. 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 output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments. The exemplary UTXO-based protocol will be described with reference to Bitcoin, but it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0137] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may contain an unused 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 that specifies the amount of digital asset, which represents the set number of tokens on the distributed ledger. In addition to other information, the UTXO may also contain the transaction ID of the transaction from which it originates. The transaction data structure may also contain a header 201, which may contain an indicator of the size 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 unprocessed transaction 152 submitted to node 104.

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

[0139] Here, the terms “preceding” and “following” used in the context of transaction sequences refer to the order of transactions in a sequence defined by transaction pointers specified within a transaction (such as which transaction points to which other transaction). They can be equally replaced by “preceding” and “inheriting” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily mean the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. Nevertheless, a following transaction (descendant transaction or “child”) that points to a preceding transaction (ancestor transaction or “parent”) will not be validated unless the parent transaction is validated. A child that arrives at blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for its parent, depending on the node protocol and / or the node’s behavior.

[0140] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO labeled UTXO0 in this specification. Each UTXO contains a value specifying the amount of digital asset represented by the UTXO and a lock script defining conditions that must be met by the unlock script in the input 202 of the subsequent transaction in order for the subsequent transaction to be validated and therefore for the UTXO to be successfully redeemed.

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

[0142] In the illustrated example, UTXO0 in output 203 of Tx0 is the lock script [Checksign P A This includes Alice's signature Sig P for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be valid). A [Checksig P A ] is the public key P from Alice's public-private key pair. A The input 202 of Tx1 includes a pointer to Tx1 (for example, its transaction ID TxID0, which in an embodiment 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 it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlock script containing Alice's cryptographic signature, which is created by applying Alice's private key from the key pair to a given portion of the data (sometimes called a "message" in cryptography). <Sig P A>Includes. The data (or "message") that Alice needs to sign in order to provide a valid signature may be defined by the lock script, by the node protocol, or a combination thereof.

[0143] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves running the lock script and unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (these conditions may include one or more criteria).

[0144] Note that script code is often expressed in general terms (i.e., does not use precise language). For example, operation codes (opcodes) that express specific functions may be used. "OP_..." represents a specific opcode in the scripting language. For example, OP_RETURN is a scripting language opcode for generating an unusable output of a transaction, which, when preceded by OP_FALSE at the beginning of the lock script, allows data to be stored within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may include documents that are desirable 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 elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs a portion of the transaction input and all or part of the transaction output. The specific portion of the output to be signed depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code typically included at the end of the signature that selects which output is signed (and is therefore fixed at the time of signing).

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

[0147] 4. Further points to note Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon disclosure in this specification. The scope of this disclosure is not limited by the embodiments described, but is limited only by the appended claims.

[0148] For example, some of the embodiments described above have been explained in terms of a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may be applied generally to any blockchain. In other words, the present invention is not limited in any way to the Bitcoin blockchain. More generally, the above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may be replaced by the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104.

[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 above functions of generating, publishing, propagating, and storing a block 151 of the blockchain 150. It is not excluded that other network entities (or network elements) may exist that perform only one or some of these functions, rather than all of them. That is, network entities may perform the function of propagating and / or storing blocks, but do not have to generate and publish blocks (remember that 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 part of, but not all, of the functions of generating, publishing, propagating, and storing block 151 of blockchain 150. For example, in these other blockchain networks, “node” may be used to represent a network entity configured to generate and publish block 151 but not to store and / or propagate said block 151 to other nodes.

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

[0152] Several embodiments have been described concerning blockchain networks that implement a proof-of-work consensus mechanism to protect 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-elapsedtime. As a specific example, 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 their tokens for a certain period of time in order to have the opportunity to become 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] It will be understood that the embodiments described above are merely 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 requesting a document signature, wherein in a document signature system, A step of receiving a signature request from a requester, wherein the signature request includes an identifier of the signer and identifies the document, The steps include obtaining a 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 document signing requirement being provided in the lock script of the document blockchain transaction and identifying the signer, The steps include making the aforementioned document blockchain transaction available to one or more nodes in the blockchain network, A method that includes this.

[0155] (Statement 2) The method according to Statement 1, further comprising the step of sending a signature authorization request to the signer, which includes the transaction identifier of the document blockchain transaction.

[0156] (Statement 3) The document is stored in the document store in association with a document identifier for identifying the document, and the method is The step of providing the signer with the document identifier in the aforementioned request for authorization of signature, The method described in Statement 2, which further includes the following.

[0157] (Statement 4) The method according to any one of statements 1 to 3, 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.

[0158] (Statement 5) 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 method further includes the step of generating a hash of the retrieved document, The generated hash is included in the document blockchain transaction according to the method of statement 4.

[0159] (Statement 6) The method according to Statement 4, wherein 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 hash of the document, and the retrieved hash of the document is included in the document blockchain transaction.

[0160] (Statement 7) The method of statement 4, wherein the commitment to the document is the document, and the data stored in the document store associated with the document identifier is the document.

[0161] (Statement 8) The steps include receiving the document from the requester, The steps include storing at least one of the document and the hash of the document in a document store, together with a document identifier for identifying the document, The method described in any of statements 1 through 7, further including the above.

[0162] (Statement 9) The method of Statement 8, further comprising the step of providing the document identifier to the requester, wherein the document is received prior to the receipt of the signature request.

[0163] (Statement 10) The document is the method described in Statement 8, received from the requester in the signature request.

[0164] (Statement 11) The document is stored in the document store, and the method is The steps include receiving the document identifier from the signer, The steps include: retrieving the document stored in association with the document identifier from the document store; The steps include providing the aforementioned document to the signatory, A method of statement 3 or any statement subordinate to statement 3, further including the above.

[0165] (Statement 12) The aforementioned method, The steps include receiving the hash of the document from the requester, The steps include storing the hash of the document together with a document identifier for identifying the document, The method described in Statement 6, which further includes the following.

[0166] (Statement 13) The aforementioned method, The steps include receiving a registration request from the signer, which includes the signer's identifier and the public key of a public-private key pair associated with the signer, The steps include storing the public key in a key store associated with the signer's identifier, The method according to any one of statements 1 to 11, further comprising the public key being used to derive the document signing requirement for the document blockchain transaction.

[0167] (Statement 14) The aforementioned method, The steps include receiving a certificate to prove the association between the signer and the public key, The steps include determining whether the aforementioned certificate was generated by a trusted certificate authority, It further includes, The method according to statement 13, wherein if the certificate is generated by the trusted certificate authority, the public key is stored in the key store.

[0168] (Statement 15) The step of generating the aforementioned document blockchain transaction is: The steps include obtaining the public key associated with the signer from the aforementioned key store, The steps include providing a lock script derived based on the public key associated with the signer, Includes, The lock script is the method described in statement 13 or 14 that defines the document signing requirements.

[0169] (Statement 16) The method according to statement 15, wherein the lock script is configured to verify the signature provided in the unlock script when executed together with the unlock script for a signed blockchain transaction.

[0170] (Statement 17) The method according to statement 16, wherein the step of generating the document blockchain transaction includes the step of providing a second lock script configured to store the commitment to the document on the blockchain.

[0171] (Statement 18) The method according to statement 17, further comprising the step of providing a third lock script configured to verify the signature provided in the unlock script of the second signature blockchain transaction when performed together with the unlock script of the second signature blockchain transaction.

[0172] (Statement 19) The method according to any one of statements 1 to 15, wherein the lock script further includes the commitment to the document, and the lock script is configured to store the commitment to the document and the document signing requirements on the blockchain.

[0173] (Statement 20) The method according to statement 19, comprising the step of generating the document blockchain transaction, the step of providing a second lock script, the second lock script being configured to verify the signature provided in the unlock script when executed together with the unlock script for the signature blockchain transaction, the signature provided in the unlock script being generated based on the private key of the signer.

[0174] (Statement 21) The commitment to the said document is as described in Statement 19 or 20, which is subordinate to any of Statements 1 to 12, and is a Merkle tree derived based on the said document and the requirements for signing the said document.

[0175] (Statement 22) The method according to any one of statements 1 to 21, further comprising the step of storing an identifier of the blockchain transaction in association with a document identifier for identifying the document.

[0176] (Statement 23) The aforementioned method, A step of determining that the signature blockchain transaction is stored in a block of the blockchain network, wherein the signature blockchain transaction includes the signature which effectively satisfies the document signing requirement, The method described in Statement 1, further including the following.

[0177] (Statement 24) The aforementioned method, A step of storing the identifier of the signed blockchain transaction in association with the identifier of the blockchain transaction and the document identifier, The method described in statements 22 and 23, further including the following.

[0178] (Statement 25) A computer implementation method for generating a signature on a document in the signer's device, wherein the method is A step of receiving a signature generation request, wherein the signature generation request is associated with the document and includes an identifier for a document blockchain transaction, the document blockchain transaction includes a commitment to the document and a document signing requirement associated with the signer, the document is signed by satisfying the document signing requirement, the document signing requirement is provided in the lock script of the document blockchain transaction and identifies the signer, The steps include obtaining the aforementioned document, The steps include obtaining the commitment to the document from the document blockchain transaction, A step of determining whether the commitment to the document corresponds to the document, If the commitment to the said document corresponds to the said document, A step of generating the signature of the signer, wherein the signature is configured to satisfy the document signing requirements of the document blockchain transaction, A step of generating the aforementioned signed blockchain transaction, wherein the aforementioned signed blockchain transaction includes the signature, The steps include making the aforementioned signed blockchain transaction available to one or more nodes in the blockchain network, A method that includes this.

[0179] (Statement 26) The document is retrieved from a document store configured to store the document in association with a document identifier, and the method is The steps include obtaining the aforementioned document identifier, A step of retrieving the document from the document store using the document identifier, The method described in Statement 25, which further includes the following.

[0180] (Statement 27) The document identifier is the method described in statement 26, received in the signature generation request on the signer's device.

[0181] (Statement 28) The commitment to the document is the hash of the document or the salted hash of the document, and whether the commitment to the document corresponds to the document is To generate a hash of the said document or a salted hash of the said document, The generated hash or salted hash of the document is compared with the commitment to the document, Determined by, If the generated hash or salted hash of the document matches the commitment to the document, the commitment to the document is the method of any of statements 25 to 27 corresponding to the document.

[0182] (Statement 29) The method according to any one of statements 25 to 27, wherein the commitment to the document is a zero-knowledge proof derived from the document, and whether the commitment is associated with the document is determined by verifying that the zero-knowledge proof was derived from the document.

[0183] (Statement 30) The method according to any one of statements 25 to 27, wherein the commitment to the document is a Merkle tree derived based on the document and the document signing requirements, and whether the commitment is associated with the document is determined by verifying the Merkle root of the Merkle tree based on the document and the Merkle certification.

[0184] (Statement 31) The aforementioned method, providing a public key for storage in association with an identifier of the signer in a document signing system, the document signing system generating the document blockchain transaction, the signature requirement being based on the public key of the signer, The method according to any one of statements 25 to 29, further comprising.

[0185] (Statement 32) The method includes obtaining, from a trusted certification authority, a certificate for proving the association between the signer and the public key; providing the certificate to the document signing system for storage; The method according to statement 31, further comprising.

[0186] (Statement 33) The lock script of the document blockchain transaction includes the document signature requirement and further includes a commitment to the document, the lock script being configured to store the commitment to the document and the document signature requirement in the blockchain, and the step of generating the signature blockchain transaction includes providing, in a first lock script of the signature blockchain transaction, a representation of the signature for satisfying the signature blockchain transaction, the first lock script of the signature blockchain transaction being configured to store the representation of the signature in the blockchain, the method according to any one of statements 25 to 32, including the step.

[0187] (Statement 34) The document blockchain transaction further includes a second lock script, and when the second lock script is executed together with the unlock script of the signature blockchain transaction, it is configured to verify a second signature provided in the unlock script. The step of generating the signature blockchain transaction includes generating a second signature of the signer based on the secret key of the signer, and providing the second signature of the signer to the unlock script of the signature blockchain transaction, and further includes, The method described in statement 33, wherein the second signature is configured to unlock the lock script of the document blockchain transaction.

[0188] (Statement 35) The method described in statement 33 or 34, wherein the representation of the signature is a hash of the signature.

[0189] (Statement 36) The method described in statement 33 or 34, wherein the representation of the signature is an image file including a digital image of the signature.

[0190] (Statement 37) The lock script of the document blockchain transaction including the document signature requirement is configured to verify a signature provided in the unlock script when executed together with the unlock script of the signature blockchain transaction. The step of generating the signature blockchain transaction includes The method described in any of statements 25 to 32, including the step of providing the signature for satisfying the document signature requirement in the unlock script of the signature blockchain transaction.

[0191] (Statement 38) A computer device, Memory containing one or more memory units, A processing device including one or more processing units, Includes, A computer device in which the memory stores code configured to be executed on the processing device, and the code is configured to perform the method described in any of statements 1 to 37 when executed on the processing device.

[0192] (Statement 39) A computer program that is embodied on a computer-readable storage device and configured to execute any of the methods described in statements 1 through 37 when executed on one or more processors.

Claims

1. A computer implementation method for requesting a document signature, wherein in a document signature system, A step of receiving a signature request from a requester, wherein the signature request includes an identifier of the signer and identifies the document, The steps include obtaining a 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, the document is signed by satisfying the document signing requirement, the document signing requirement is provided in the lock script of the document blockchain transaction and identifies the signer, The steps include making the aforementioned document blockchain transaction available to one or more nodes in the blockchain network, A method that includes this.

2. The method according to claim 1, further comprising the step of sending a signature authorization request to the signer, which includes a transaction identifier for the document blockchain transaction.

3. The document is stored in the document store in association with a document identifier for identifying the document, and the method is The step of providing the signer with the document identifier in the aforementioned request for authorization of signature, The method according to claim 2, further comprising:

4. The method according to claim 1, 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.

5. 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 method further includes the step of generating a hash of the retrieved document, The method according to claim 4, wherein the generated hash is included in the document blockchain transaction.

6. The method according to claim 4, wherein the commitment to the document is a hash of the document, the data stored in the document store associated with the document identifier is a hash of the document, and the retrieved hash of the document is included in the document blockchain transaction.

7. The method of claim 4, wherein the commitment to the document is the document, and the data stored in the document store associated with the document identifier is the document.

8. The steps include receiving the document from the requester, The steps include storing at least one of the document and the hash of the document in a document store together with a document identifier for identifying the document, The method according to claim 1, further comprising:

9. The method of claim 8, further comprising the step of providing the requester with the document identifier, wherein the document is received before the request for signature is received.

10. The method according to claim 8, wherein the document is received from the requester in the signature request.

11. The document is stored in the document store, and the method is The steps include receiving the document identifier from the signer, The steps include: retrieving the document stored in association with the document identifier from the document store; The steps include providing the aforementioned document to the signatory, The method according to claim 3, further comprising:

12. The aforementioned method, The steps include receiving the hash of the document from the requester, The steps include storing the hash of the document together with a document identifier for identifying the document, The method according to claim 6, further comprising:

13. The aforementioned method, The steps include receiving a registration request from the signer, which includes the signer's identifier and the public key of a public-private key pair associated with the signer, The steps include storing the public key in a key store associated with the signer's identifier, The method according to claim 1, further comprising the public key being used to derive the document signing requirement for the document blockchain transaction.

14. The aforementioned method, The steps include receiving a certificate to prove the association between the signer and the public key, The steps include determining whether the aforementioned certificate was generated by a trusted certificate authority, It further includes, The method according to claim 13, wherein if the certificate is generated by the trusted certificate authority, the public key is stored in the key store.

15. The step of generating the aforementioned document blockchain transaction is: The steps include obtaining the public key associated with the signer from the aforementioned key store, The steps include providing a lock script derived based on the public key associated with the signer, Includes, The lock script defines the document signing requirement, according to the method of claim 13.

16. The method according to claim 15, wherein the lock script is configured to verify the signature provided in the unlock script when executed together with the unlock script for a signed blockchain transaction.

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

18. The method according to claim 17, further comprising the step of providing a third lock script configured to verify the signature provided in the unlock script of the second signature blockchain transaction when performed together with the unlock script of the second signature blockchain transaction.

19. The method according to claim 1, wherein the lock script further includes the commitment to the document, and the lock script is configured to store the commitment to the document and the document signing requirements on a blockchain.

20. The method according to claim 16, 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 when executed together with the unlock script of the signature blockchain transaction, the signature provided in the unlock script being generated based on the private key of the signer.

21. The method according to claim 19, wherein the commitment to the document is a Merkle tree derived based on the document and the document signing requirements.

22. The method according to claim 1, further comprising the step of storing an identifier for a document blockchain transaction in association with a document identifier for identifying the document.

23. The aforementioned method, A step of determining that a signature blockchain transaction is stored in a block of the blockchain network, wherein the signature blockchain transaction includes a signature that effectively satisfies the document signing requirement, The method according to claim 22, further comprising:

24. The aforementioned method, A step of storing the identifier of the signature blockchain transaction in association with the identifier of the document blockchain transaction and the document identifier, The method according to claim 23, further comprising:

25. A computer implementation method for generating a signature on a document in the signer's device, wherein the method is A step of receiving a signature generation request, wherein the signature generation request is associated with the document and includes an identifier for a document blockchain transaction, the document blockchain transaction includes a commitment to the document and a document signing requirement associated with the signer, the document is signed by satisfying the document signing requirement, the document signing requirement is provided in the lock script of the document blockchain transaction and identifies the signer, The steps include obtaining the aforementioned document, The steps include obtaining the commitment to the document from the document blockchain transaction, A step of determining whether the commitment to the document corresponds to the document, If the commitment to the said document corresponds to the said document, A step of generating the signature of the signer, wherein the signature is configured to satisfy the document signing requirements of the document blockchain transaction, A step of generating a signed blockchain transaction, wherein the signed blockchain transaction includes the signature, The steps include making the aforementioned signed blockchain transaction available to one or more nodes in the blockchain network, A method that includes this.

26. The document is retrieved from a document store configured to store the document in association with a document identifier, and the method is The steps include obtaining the aforementioned document identifier, The steps include: retrieving the document from the document store using the document identifier; The method according to claim 25, further comprising:

27. The method according to claim 26, wherein the document identifier is received in the signature generation request on the signer's device.

28. The commitment to the document is the hash of the document or the salted hash of the document, and whether the commitment to the document corresponds to the document is To generate a hash of the said document or a salted hash of the said document, The generated hash or salted hash of the document is compared with the commitment to the document, Determined by, The method of claim 25, wherein if the generated hash or salted hash of the document matches the commitment to the document, the commitment to the document corresponds to the document.

29. The method of claim 25, wherein the commitment to the document is a zero-knowledge proof derived from the document, and whether the commitment is associated with the document is determined by verifying that the zero-knowledge proof was derived from the document.

30. The method of claim 25, wherein the commitment to the document is a Merkle tree derived based on the document and the document signing requirements, and whether the commitment is associated with the document is determined by verifying the Merkle root of the Merkle tree based on the document and the Merkle certification.

31. The aforementioned method, A step of providing a document signing system with a public key to be stored in association with the signer's identifier, wherein the document signing system generates the document blockchain transaction, and the document signing requirement is based on the signer's public key, The method according to claim 25, further comprising:

32. The aforementioned method, The steps include obtaining a certificate from a trusted certificate authority to prove the association between the signer and the public key, The steps include providing the aforementioned certificate to the document signing system for storage, The method according to claim 31, further comprising:

33. The lock script for the document blockchain transaction includes the document signing requirements, further including the commitment to the document, and the lock script is configured to store the commitment to the document and the document signing requirements on the blockchain, and the step of generating the signed blockchain transaction is: The method of claim 25, comprising the step of providing a representation of the signature to satisfy the signature blockchain transaction in a first lock script of the signature blockchain transaction, wherein the first lock script of the signature blockchain transaction is configured to store the representation of the signature on the blockchain.

34. The document blockchain transaction further includes a second lock script, which, when executed together with the unlock script of the signature blockchain transaction, is configured to verify the second signature provided in the unlock script, and the step of generating the signature blockchain transaction is: A step of generating a second signature of the signer based on the signer's private key, The steps include providing the signer's second signature to the unlock script of the signature blockchain transaction, It further includes, The method according to claim 33, wherein the second signature is configured to unlock the lock script of the document blockchain transaction.

35. The method according to claim 33, wherein the signature representation is the hash of the signature.

36. The method according to claim 33, wherein the representation of the signature is an image file containing a digital image of the signature.

37. The lock script of the document blockchain transaction, which includes the document signing requirement, is configured to verify the signature provided in the unlock script when executed together with the unlock script of the signing blockchain transaction, and the step of generating the signing blockchain transaction is: The method of claim 25, further comprising the step of providing the signature to satisfy the document signing requirement in the unlock script of the signature blockchain transaction.

38. Computer equipment, Memory containing one or more memory units, A processing device including one or more processing units, Includes, A computer device wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to claim 1 when executed on the processing device.

39. A computer program that is implemented on a computer-readable storage device and is configured to perform the method described in claim 1 when executed on one or more processors.

Images