EP4736049A1

EP4736049A1 - Blockchain transaction

Info

Publication number: EP4736049A1
Application number: EP24731510.4A
Authority: EP
Inventors: Liuxuan PAN; Arthur GORDON; Wei Zhang; Craig Wright
Original assignee: Nchain Licensing AG
Current assignee: Nchain Licensing AG
Priority date: 2023-06-29
Filing date: 2024-06-03
Publication date: 2026-05-06
Also published as: WO2025002725A1; CN121646778A; GB202309897D0

Abstract

Herein is provided a computer-implemented method for signing a document at a document signature system. A signature request comprising an identifier of a signer and identifying the document is received from a requestor. A commitment to the document is obtained. A document blockchain transaction is generated, wherein the document blockchain transaction comprises the commitment to the document and a document signature requirement associated with a signer, wherein satisfying the document signature requirement signs the document. The document blockchain transaction is made available to node(s) of a blockchain network. A signature authorisation message is received from the signer and, in response, a signature blockchain transaction is generated, wherein the signature blockchain transaction comprises a signature associated with the signer and which satisfies the document signature requirement. The signature blockchain transaction is made available to one or more nodes of the blockchain network.

Description

BLOCKCHAIN TRANSACTION

TECHNICAL FIELD

The present disclosure relates to a computer-implemented method for signing a document at a document signature system, and computer equipment and a computer program for implementing the method.

BACKGROUND

Document signing applications (DSAs) provide a platform for users to digitally sign documents.

One known application is DocuSign®. DocuSign has been integrated with assistive technologies, mobile signing, Microsoft™, Google™, and Dropbox®. It allows individuals and organizations to sign and manage documents electronically, eliminating the need for physical signatures and paper-based processes.

The DocuSign makes use of the following technologies to help signature generation:

• SMS two-factor authentication - DocuSign texts an authorization code to a recipient's mobile phone and the recipient enters the code to commence signing. This compliments existing DocuSign authentication options including email access code, phone, and knowledge based (KBA) authentication.

• ePadlink Signature Pad Integration - The DocuSign Signature Pad option allows signing and signature adoption using signature pads. With the upcoming release, DocuSign adds support for ePadLink ePad-ink (VP9805) signature pad devices.

• eWitness - allows users to add an electronic signature and act as a witness for an agreement.

On DocuSign, an envelope is used as a container for documents that a user sends to a recipient to sign. An envelope can have one document or many documents, and one signer or many signers. Envelopes have statuses (i.e., sent, delivered, completed, voided) and contain information about the sender and timestamps that indicate the progress of the delivery procedure.

• Sender: create, send, and manage DocuSign envelopes

• Signer: an envelope recipient who is required to act on an envelope or documents within an envelope

• Fields: Indicate where a Signer needs to act on the document. For example, filling in data, selecting or applying a signature.

• viewing/signing session - session information

However, the signatures in DocuSign are not generated using any signature scheme, in fact the DocuSign only stores the images of signatures. Users register their email addresses on DocuSign and upload documents to sign them with signature images. In addition, DocuSign centrally manages all documents for users. This puts documents at risk if customer's email addresses were lost in a hack and the lost addresses are used in a phishing attack.

To reduce the risk, DocuSign uses various security measure to keep its servers secure:

• Physical security for data centres

• Network security measures like firewalls, intrusion detection systems

• Encryption for both data storage and data transmission

• Access controls to restrict unauthorized access

• Regular security audits and penetration testing

• Compliance with industry security standards (e.g., SOC 2, ISO 27001)

Furthermore, DocuSign's Electronic Notary feature lets senders require that documents be notarized in person. This is also known as eWitness functionality (eWitness in UK, Notary in US).

DocuSign provides the following APIs

• eSignature API - 400 endpoints for signing workflow

• Notary API - notary-specific endpoints

• Click API - REST API for capturing consent to standard terms with a single click

• Rooms API - streamline complex agreement through secure digital workspace Monitor API

• Admin API

• Salesforce Apex Toolkit

The following describes the process for preparing and signing a document implemented in DocuSign:

1. Upload document: Users upload the document they need signed to the DocuSign platform.

2. Add recipients: The user adds the recipient's email address and specifies their signing role (e.g., signer, reviewer, etc.).

3. Customize signing order: The user can specify the order in which the recipients will sign the document.

4. Add signature fields: The user adds signature, initial, and other fields to the document as needed.

5. Send document: The user sends the document to the recipients for signature.

6. Signing process: Recipients receive an email with a link to the document and instructions on how to sign. They can review the document and add their electronic signature using a mouse, stylus, or their finger on a mobile device.

7. Completed document: Once all required signatures are obtained, the signed document is automatically returned to the sender and can be downloaded or stored in the DocuSign platform.

There are a number of standards which have been introduced for eSignatures.

The ESIGN Act is a US federal law passed in 2000. It grants legal recognition to electronic signatures and records if all parties to a contract choose to use electronic documents and to sign them electronically. Uniform Electronic Transactions Act (UETA) and ESIGN Act requirements state each electronically signed document needs to abide by the following: • Intent to sign - A signature on an electronic document is legal only if the document and clauses within are fully transparent and the signature is made with intent.

• Implied or express consent to sign electronically - All electronic documents/signing platforms should include a clause that the client agrees to sign this agreement electronically. The user can take this a step further by including a checked agreement box or a verification step upon signing.

• Signature attribution - the user maintains a digital audit trail that associates the signature with unique signifiers such as a timestamp, email, and IP address.

• Protection of signature - All signatures must be attached securely to the document and not stored separately. Signed documents should be stored in an encrypted environment and not sent to anyone aside from the parties involved.

• Copies sent to the signer - Upon signing a document, a copy of the document including the signature must be sent to the client.

• Record retention - the user needs to keep the signed copies of each document to be reproduced when required.

• Opt-out clause - a client should always have the opportunity to opt-out of digital signing in favour of signing a paper contract. While digital is the new norm, the client should always have paper backups in the event of someone choosing to go this route. elDAS (electronic IDentification, Authentication, and trust Services) has created standards for which electronic signatures, qualified digital certificates, electronic seals, timestamps, and other proof for authentication mechanisms enable electronic transactions, with the same legal standing as transactions that are performed on paper.

• Advanced electronic signature: An electronic signature is considered advanced if it meets certain requirements: It provides unique identifying information that links it to its signatory. The signatory has sole control of the data used to create the electronic signature. It must be capable of identifying if the data accompanying the message has been tampered with after being signed. If the signed data has changed, the signature is marked invalid. There is a certificate for electronic signature, electronic proof that confirms the identity of the signatory and links the electronic signature validation data to that person. Advanced electronic signatures can be technically implemented, following the XAdES, PAdES, CAdES or ASiC Baseline Profile (Associated Signature Containers) standard for digital signatures, specified by the European Telecommunications Standards Institute (ETSI).

• Qualified electronic signature, an advanced electronic signature that is created by a qualified electronic signature creation device based on a qualified certificate for electronic signatures.

• Qualified digital certificate for electronic signature, a certificate that attests to a qualified electronic signature's authenticity that has been issued by a qualified trust service provider.

All organisations delivering public digital signatures in an EU member state must recognise electronic identification from all EU member states. Note that this means that certificates used in closed systems are exempt from elDAS.

Other digital signature standards include:

• Switzerland - ZerES digital signing standards -

• US - NIST Digital Signing Standard (DSS)

• UK - elDAS Regulations provide the legal framework for the use of electronic trust services offered within the UK and recognise equivalent services offered in the EU.

• Canada - PIPEDA (Federal) and UECA (Provincial)

• Australia and New Zealand - Electronic Transactions Act

• CFR Part 11 - defines the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records. SUMMARY

Herein is provided a blockchain-based document signing application (DSA) which utilises features of blockchain technology.

The blockchain offers the following properties to DSA:

• Accessibility: All documents and signature records could be stored on a distributed ledger, allowing for increased security and accessibility.

• Immutable record-keeping: Transactions on the blockchain are permanent and cannot be altered, ensuring the integrity of documents and signatures.

• Smart Contracts: Automated contract execution could be triggered based on the fulfilment of specific conditions, such as the completion of all required signatures.

• Digital signatures: Public-key cryptography could be used to create digital signatures, allowing for secure and verifiable electronic signatures.

By utilizing these features of blockchain, the DSA system provided herein can offer a secure and efficient solution for electronic document signing and management.

According to one aspect disclosed herein, there is provided a computer-implemented method for signing a document at a document signature system, the method comprising: receiving a signature request comprising an identifier of a signer and identifying the document from a requestor; obtaining a commitment to the document; generating a document blockchain transaction, wherein the document blockchain transaction comprises the commitment to the document and a document signature requirement associated with a signer, wherein satisfying the document signature requirement signs the document; making the document blockchain transaction available to one or more nodes of a blockchain network; receiving, from the signer, a signature authorisation message; in response to receiving the signature authorisation message, generating a signature blockchain transaction, wherein the signature blockchain transaction comprises a signature associated with the signer and which satisfies the document signature requirement; and making the signature blockchain transaction available to one or more nodes of the blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

Figure 1 is a schematic block diagram of a system for implementing a blockchain;

Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain;

Figure 3 provides an overview of a DSA signing process;

Figure 4 provides an example method for preparing a document in a custodial DSA system;

Figure 5 provides an example method for signing a document in a custodial DSA system;

Figure 6 provides an example method for registering a user in a non-custodial DSA system;

Figure 7 provides an example method for signing a document in a non-custodial DSA system;

Figure 8 provides an example method for finalising a document in a non-custodial DSA system;

Figure 9 shows an example Merkle root structure for signed documents; and

Figure 10 provides an example method for preparing a document in a decoupled document storage environment.

DETAILED DESCRIPTION OF EMBODIMENTS

1. DOCUMENT SIGNING APPLICATION

A Document Signing Application (DSA) may utilise a blockchain to sign documents. There are two main components in the DSA system:

• Orchestrator: a workflow management solution

• Document Store: a database for storing documents and/or the hash values of documents

The Orchestrator may also be referred to herein as a document signature system.

The Document Store and the Orchestrator may be in direct communication, or they may be decoupled.

There are three main stages in DSA system: document preparation 302, document signing 304, and document finalisation 306, as shown in Figure 3.

The DSA signing process can be implemented in two ways:

• Custodial - the system manages a key pair and signing workflow on behalf of users under their instructions.

• Non-custodial - the system enables users to sign a blockchain transaction to prove that they have signed the document. An email link is sent to signer's email including a document ID. It will be appreciated that access to the document may be provided to the signer in another way, apparent to the person skilled in the art. When the signer confirms the documents, they sign the transaction and publishes it. The signer's signature is then included in the unlocking script of the transaction to provide a record of the signing. The signature in the unlocking script is not necessarily the same as the signature for the document.

1.1 Custodial DSA

In a custodial DSA, the Orchestrator is responsible for generating the signature for signing the document on behalf of the signer.

The Orchestrator may have one or more of the following capabilities: • Send document signing notifications to signers.

• Provide a web-based interface for users to sign, send, and manage documents.

• Use role-based access controls to restrict who can view and sign a document. Users will need to be registered with the system.

• Provide interoperability with other systems, such as cloud storage services, email systems, certificate authorities to enable seamless integration with existing workflows.

• Capability to be hosted by cloud providers or on customer premises. This should ensure that the DSA appeals to as many customers as possible.

• Capability to delete documents, to comply with GDPR right to be forgotten.

Furthermore, the custodial DSA should specify:

• Where documents are to be stored.

• Document retention period.

• The Orchestrator can support document signing using a blockchain transaction.

1.1.1 User Registration

Users are required to register with the DSA system before they are able to sign documents. This is because the DSA system stores keys used to sign documents by a specific signer, and therefore the signer must be known to the DSA system prior to signing.

The registration can be done by filling an email address and creating a password on a DSA interface, and thereby generating a user profile. Once users have been registered with the DSA system, they can authenticate themselves prior to creating signing requests or signing documents. The DSA system creates a key pair and allocates the public key (e.g., PK_signer) to the registered user. The associated private key is maintained by the DSA at a key store and used to sign a signature transaction associated with the document, on behalf of the user. In some embodiments, the signer is registered with the DSA system after a document blockchain transaction has been generated. The document blockchain transaction is described in more detail later. The document blockchain transaction provides or identifies the document for signing and defies a signature requirement to be satisfied by the signer.

In the event of the signer registering after the document transaction has been generated, the DSA generates the public-private key pair as set out above for the signer and stores this in the document store with an identifier of the signer. When the signer registers with the DSA, the stored private key is then associated with the user profile and the user provided with the public key.

1.1.2 Document Preparation

In this stage, users can choose to upload documents or hashes of documents to the DSA platform. The example of selecting upload documents is provided herein to illustrate the process. This can be applied to the option of uploading document hashes.

Users upload the document to be signed to the DSA platform, add the recipient's email address or other identifier, and specifies their signing role (e.g., signer, reviewer, etc.). Optionally the user also can specify the order in which the recipients will sign the document and add signature fields.

The details are shown in Figure 4. In the Example of Figure 4, the DSA system 400 comprises both the Orchestrator 402 and the document store 404, such that the two components can communicate with each other.

1. The user 103a logs in the DSA system 400 and uploads the document to Orchestrator 402.

2. The Orchestrator 402 processes the document and stores it in the Document Store 404.

3. The Document Store 404 returns a document ID to the Orchestrator 402.

4. The Orchestrator 402 sends the document ID to the user 103a.

5. The user 103a adds the signer's email address (or other identifier).

6. The Orchestrator 402 matches the public key to the signer's email address. 7. The Orchestrator 402 requests a hash value from Document Store 404.

8. The Orchestrator 402 creates a signature request transaction TXID₁ as described below and publishes the transaction to the blockchain. The signature request transaction may also be referred to herein as a document blockchain transaction. Note that in the locking script of TXID₁, the hash value of the document is included as a data payload using OP_FALSE OP_RETURN. The TXID₁ shows that two signers (PK_signerl, PK_signer2) can sign the documents independently. There can be one or more than one signer in the signature request transaction.

UXT O_DSA is an output controlled by the DSA 400 and used to generate the signature request transaction.

9. The Orchestrator 402 stores the transaction ID associated with the document ID, transaction ID of the document transaction.

10. The Orchestrator 402 informs the user 103a that the document is prepared for signing. This may be by way of an email or notification via a DSA portal or user interface, for example.

TxIDi is a template of an example document blockchain transaction for requesting a document signature. The transaction comprises three outputs. The first output comprises a first locking script which stores a hash of the document to the blockchain 150, and which causes the output to be unspendable. The other two outputs comprise signature requirements for signing the document. In this example, the signature requirement is a pay-to-public-key hash associated with each signer. To satisfy the requirement, the signer must provide a valid signature in an unlocking script of a signature transaction.

The signer public keys used to derive the signature requirements, in this example the second and third locking scripts, are obtained from the key store of the Orchestrator 402.

The first locking script comprises a hash of the document. The hash of the document may be referred to herein as a commitment to the document. In the example of Figure 4, the document store 404 generates the document hash. However, in some embodiments, the document store 404 provides the document to Orchestrator 402, which hashes the document before including in the locking script.

In some embodiments, the document itself is included in the locking script of the document transaction. In such an embodiment, the document may be referred to as the commitment to the document.

Other commitments to the document may be used, where the commitment is derived from the document and can be used to verify that a copy of the document is correct. Another example may be a zero-knowledge proof associated with the document, or a Merkle root derived based on the document as discussed in section 1.3. Any other known methods for communicating about the same data between the DSA and the signer but without revealing the data or details thereof may be used as the commitment to the data in the methods provided herein.

In the example set out above, the document store 404 stores the document together with a document ID. In some embodiments, the document store 404 may store, instead of or in addition to the document, a hash of the document. In this embodiment, the Orchestrator 402 may receive the document from the user 103a and hash the document before providing the hash to the document store 404 for storing. In some embodiments, the user 103a does not provide the document to the Orchestrator 402. Instead the user 103a may only provide a hash of the document, which the Orchestrator provides to the document store 404 for storing.

The transaction ID of the document transaction may be stored at the Orchestrator 402 in associated with the document ID or at the document store 404 together with the document ID and document or hash thereof.

1.1.3 Document Signing

Once the document transaction has been recorded to the blockchain 150, the signer 103b (or signers) is sent a notification or request to indicate that their signature authorisation is required. In some instance, the user 103a may send the request to the signer 103b externally to the DSA 400. For example, the user 103a may send the document to the signer 103b and inform them that the document can be signed at the DSA 400, provide them with a link to sign the document at the DSA 400, or provide the document ID such that the singer 103b can access the document from the document store 404.

Alternatively, the DSA 400 may notify the signer 103b. For example, signers 103b receive an email with a link to the document, or the document ID, and instructions on how to sign.

They can review the document, retrieved from the document store 404, and use the Orchestrator 402 to sign.

To sign the document, a signature blockchain transaction is generated which comprises a signature satisfying the signature requirements of the document transaction. Using the example of section 1.1.2, the signature requirement is satisfied by an unlocking script of the signature blockchain transaction comprising a signature generated using a private key associated with the signer 103b. That means, the UXTO of TXID will be spent for signing the document.

The signature provided in the unlocking script of the signature blockchain transaction has a dual purpose - both signing the document and unlocking the UTXO. The signature is a cryptographic signature. An example signing process is described in Figure 5:

1. A notification of the document is sent from the DSA system 400 to the signer 103b for requesting signature. The notification includes the document ID.

2. The signer 103b logs in the DSA system 400.

3. The DSA 400 authenticates the signer 103b to view the document ID and the transaction ID TXID₁.

4. The signer 103b requests the document associated with the document ID.

5. The DSA 400 matches the document to the request document ID and authenticates the signer 103b to view the document.

6. The signer 103b approves the document and authenticates the Orchestrator 402 to sign the document.

7. The Orchestrator 402 creates a new blockchain transaction TXID₂ which spends the UTXO of TXID^ related to the signer 103b.

8. The Orchestrator 402 records TXID₂ in the DSA 400 and notifies the signer 103b that the operation was successful.

At step 3, the signer 103b may be sent a signature authorisation request. This request may be a message sent to the signer 103b. The signature authorisation request may comprise the identifier of the document transaction, thereby allowing the signer 103b to access the document transaction stored on the blockchain 150. The signature authorisation request may also comprise the document ID, to allow the signer 103b to access the document from the document store 404 independently of the Orchestrator 402.

Alternatively, the signer 103b may be provided with access to the transaction ID and/or document ID by way of a user account or portal of the DSA 400.

In another embodiment, the signer 103b is provided with a copy of the document directly by the user 103a requesting the document be signed. In some embodiments, the signer 103b may request access to the document using the document transaction ID. The DSA 400 determines a document ID associated with the transaction ID, which it uses to retrieve the associated document and provide it to the signer 103b.

The signer 103b verifies that the commitment to the document provided in the document transaction is accurate with respect to the document. For example, the signer 103b retrieves the document from 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 the signer 103b. The signer 103b then authorises the Orchestrator 402 to sign the document if the hashes match.

In another embodiment, the commitment to the document may be a Merkle tree derived from the document and the signature requirements, as shown in section 1.3 for example. To verify the commitment to the document, the signer 103b may reproduce the Merkle tree based on the document they have access to and the signature requirements and check that the Merkle trees match. Alternatively, the signer 103b may obtain a Merkle proof corresponding to the document in the Merkle tree and calculate a Merkle root based on the document and the Merkle proof. If the calculated Merkle root matches the Merkle root of the document transaction, the signer 130b can confirm that the document of the commitment is the same as that they intend to sign, and authorises the Orchestrator 402 to sign the document.

The signer 103b authorises the Orchestrator 402 to sign the document in a signature authorisation message.

The Orchestrator 402, on receiving the signature authorisation message, retrieves the private key of the signer 103b from the key store to generate the signature.

In the method set out above, the DSA authenticates the signer 103b before allowing them to view requested data. This authentication may be implemented using any known method, such through the use of a username and password or two-factor authentication. In some embodiments, the signature transaction may further comprise an image of the signature over the document, i.e. the signature satisfying the document signature requirements. The image of the signature may be included in an OP_RETURN script within a locking script of the signature transaction. The image of the signature may be a hash of the signature or an image file showing a handwritten signature for example. Other images of the signature may be used.

1.1.4 Document Finalisation

Once all the signatures are complete on the transaction, the Orchestrator 402 can create a document audit trail and notify all parties involved. The document audit trail contains the following details of the document signer(s):

• Email

• Name

• Signature

• Date

1.2 Non-Custodial DSA

In a non-custodial DSA, the Orchestrator is not responsible for generating the signature for signing the document on behalf of the signer. That is, the non-custodial DSA enables the user to manage their key-pair for document signatures, not the Orchestrator. This is achieved by using a wallet to securely host the keys.

1.2.1 Wallet

When a wallet is involved in the non-custodial solution, the following requirements should be met:

• The wallet can use the owner's private keys to sign the transaction associated with the document.

• The wallet stores secret keys securely.

• The wallet owner's public key is registered via an X.509 certificate to attest to their identity. The CA issuing the X.509 certificate will need to be recognised by the organisation requesting document signatures. The certificate will use a secp265kl key-pair.

1.2.2 Registration Process

The user registration process is shown in Figure 6. In the example of Figure 6, the DSA system 600 comprises both the Orchestrator 602 and the document store 604.

1. The user 103a generates a key pair and obtains a certificate on that public key from a trusted certificate authority (CA) 606. The user 103a can specify that the public key is used for document signing.

2. The user 103a registers an account in the DSA 600 using the email address, certificate, and other information. The certificate includes the public key of the user 103a.

3. The DSA 600 records the user's information and generates an account.

4. The user 103a sets the password for that account.

5. The DSA 600 stores the hash of the password with respect to the user's email address.

Note that the user 103a can become the role of signers in the following processes. That means, the signer 103b will register their certified public key and email address on the DSA platform 600 in the same way. This allows the DSA system 600 to generate and publish the signature request transaction on behalf of the signature requestor 103a.

It will be appreciated that obtaining and providing the certificate is not essential for the user 130 to use the DSA 600. However, since the user 103 provides the DSA 600 with their public key, rather than the key pair being generated at the DSA 600 as in the custodial DSA system described in section 1.1, the DSA 60 cannot be sure that the public key provided by the user 103 is valid. Therefore, the addition of providing the certificate improves the security of the system. The public key, user identifier, and key certificate may be stored in a keystore of the Orchestrator 602. The DSA 600 may, before storing the public key of the user 103, verify that the certificate is generated by a CA 606.

The Orchestrator 602 may verify that the certificate is generated by a CA 606 before storing the key. The certificate may be signed by the CA 606, and the verification may comprise checking that the signature is that of a CA 606.

1.2.3 Document Preparation

The document preparation steps are similar to the custodial solution described in section

1.1.2 and shown in Figure 4. Note that the registered certified signer's public key in section

1.2.2 is stored by the DSA 600.

The following process may be implemented:

1. The user 103a uploads the document hash to Orchestrator 602 and obtains a document ID.

2. The user 103a adds the signer's email address.

3. The Orchestrator 602 matches the certified signer's public key to the signer's email address.

4. The Orchestrator 602 creates and publishes a signature request transaction TXID₁, which locks an output to the signer's certified public key and includes the document hash as a data payload using OP_FALSE OP_RETURN. Note that the UTXO of TXID^ only can be spent by the signer 103b.

5. The Orchestrator 602 adds the transaction ID associated with the document ID.

6. The Orchestrator 602 informs the user 103a that the document is ready for signing.

As discussed in section 1.1.2, the signature request, or document, transaction comprises a commitment to the document and the signature requirement which, when satisfied, signs the document. In this example, the commitment to the document is the document hash, but may in some embodiments be the document itself or a zero-knowledge proof derived from the document for example. The signature requirement is defined in a locking script locking the UTXO to the signer 130b using their stored public key.

As also discussed in section 1.1.2, the document store 604 may store the document and/or the document hash and/or the zero-knowledge proof associated with the document in association with the document ID. The commitment to the document included in the document transaction may, therefore, be retrieved from the document store 604 or computed based on retrieved data.

A template of for the document transaction is shown in section 1.1.2.

1.2.4 Document Signing

Once the document transaction has been recorded to the blockchain 150, the signer 103b (or signers) is sent a notification or request to indicate that their signature is required. The alternative ways in which the signer 103b may be notified are set out in 1.1.3, and other suitable methods of notifying the signer 103b may be used.

In contrast to the custodial system of section 1.1, the signer 103b, via their wallet 608, generates the signature for signing the document and satisfying the document signature requirements of the document transaction. This is because the DSA 600 does not store or have access to the signer's private key, required to sign the document. Using the example of section 1.1.2, the signature requirement is satisfied by an unlocking script of the signature blockchain transaction comprising a signature generated using a private key of the signer 103b. That means, the UXTO of TXID will be spent for signing the document. The alternatives provided in section 1.1.3 also apply to the non-custodial system.

The signer 103b receives the document ID from DSA 600 and performs the following steps to sign it:

1. Connect to the wallet 608 to check the request transaction ID associated with the received document ID.

2. Get the transaction associated with the document ID from the blockchain 150. 3. Calculate the hash value of the received document and compare it with the one in the transaction.

4. Publish a new transaction TXID₂ which spends the UTXO of TXID₁. The TXID₂ proves that the signer 103b signs the document.

As in previous examples, the commitment to the document is the document hash. Other possible commitments have been provided herein.

The signer 103b may compare the calculated hash of the received document to the hash of the document in the document transaction retrieved from the blockchain 150. The signer 130b may only sign the document, by generating the signature blockchain transaction, if they determine that the hashes match.

1.2.5 Document Finalisation

The document finalisation stage in non-custodial DSA is like the custodial solution. The only difference is that the Orchestrator 602 needs to monitor the blockchain 150 to determine whether the TXID₂ is valid.

Figure 8Error! Reference source not found, shows an example process of finalising the document:

1. The DSA system 600 monitors the status of TXID₂. TXID₂ is valid on the blockchain 150, then the Orchestrator 602 will update the signing status to complete.

2. The DSA 600 sends the notification to the user 103a to report the status, including the document ID and the audit trail.

3. The DSA 600 also sends a notification to the signer 103b including the document ID and audit trail.

1.3 SECURE ENCLAVE DSA

In an alternative custodial DSA system, users and signers are not required to have cryptocurrency (e.g. Bitcoin) account. In this embodiment, the signature over the document, associated with the signer, is decoupled from the signature provided in the unlocking script of the signature transaction.

In this generic case, users may prefer to sign documents independently without signing it together with blockchain transactions. That is, the digital signatures of the signers should only sign the document, not blockchain transactions. The DSA then itself signs all transactions.

This approach allows users to use any digital signature schemes of their choice for signing documents. In particular, for a high security requirement, one would expect that digital signatures to be generated in secure enclaves of hardware devices such as mobile phones. Furthermore, users do not need to handle blockchain transactions and the verification of the signature can be independent of blockchain transactions. It also provides great interoperability to existing signing solutions, as most secure enclaves may not typically allow for the curve used in Bitcoin.

The generic DSA follows a similar process shown in the custodial DSA scheme with a few exceptions.

The signature request transaction may be modified as follows:

Here PK and PK₂ are used by the DSA to decouple signing transactions from document signatures. That is, PK and PK₂ are public keys owned by the DSA. These keys may be linked to, or otherwise associated with, signers' public keys PK_signerl and PK_signer2 respectively, or the signers' identifiers, by some means, for example in a database. However, any UTXO locked by the locking scripts comprising PK or PK₂ is locked to a private key of the DSA. In this way, the signers 103b do not need to have a cryptocurrency account or wallet.

The data payload including signers' public keys allows the signature requestor to use the public keys shown in the request transaction to verify the signature against on the document, without handling any bitcoin or other cryptocurrency. H (Document') can be replaced by H (salt\ \Document) or any other types of cryptographic commitment to the document data.

The private keys associated with PK_signerl and PK_signer2 are used to sign the document directly in the DSA. That is, the DSA comprises a key store as in the custodial DSA system described in section 1.1 storing the signer's private key in association with a user identifier of the signer. The signatures are denoted SIG_PKsigneri and SIG_PKsigner2 . There is no concern that the signatures cannot be removed from a public blockchain.

Alternatively, the signer may store their private key, and provide their signature SIG_PKsignen to the DSA when authorising the signature transaction to be generated. This signature, generated by the signer and provided to the DSA, is then included in the signature transaction. The private key of the signer would likely be held in a secure enclave, or secure hardware module under the control of the signer.

If privacy is a concern, PK_singerl, PK_signer2 can be replaced by cryptographic commitment or hash values of the public keys. A Merkle tree can be used to capture all public keys. In this case, a Merkle root can be included in the data payload after OP_FASLE OP_RETURN. For example, the Merkle root associated with the document and signers' public keys can be constructed as: Note that the hash values in the leaves of the Merkle tree do not need to be of the same depth, see Figure 9. The Merkle root can be considered a commitment to the document.

The DSA publishes a signature transaction TXID_2A, which spends the UTXO of TXID related to the signerl and includes the hash value of the signature SIG_{PK signerl} in OP_FALSE OP_RETURN output. TXID_2B is published for signer . Note that, the hash value could be in a salted hash or any cryptographic commitment scheme for privacy. The salted hash may be considered a hash of the document. Also similar to the point above, for multiple signatures, a Merkle root can be added to the data payload instead. It is optional for users to use the signatures on the TXID_2A and TXID_2B for attestation. As set out above, the unlocking scripts are generated using private keys held and owned by the DSA.

In this example, the signature requirement may be said to be defined in the locking script by the inclusion of the public keys of the signers: PK_singerl, PK_signer2. This requirement is satisfied by the signature transactions TXID_2A and TXID_2B by the inclusion of the hash of the document signature H(SIG_PKsinger , H(SIG_PKsinger2) respectively. The hash of the signature provided in the locking script of the signature transactions TXID_2A and TXID_2B may be referred to as representations of the signatures. The locking script may comprise a representation of the signature satisfying the signature requirement in another form. For example, the plain signature SIG_PKsingeri may be included as the representation of the signature.

This method may be used for non-cryptographic signature requirements. In such an embodiment, the document signature requirement may comprise an identifier of the signer 103b instead of their public key. The locking script of the signature transaction comprises the signature which satisfies the non-cryptographic signature requirement. This signature may be generated by the signer and provided to the DSA when authorising the signature transaction to be generated. For example, the signature requirement may be satisfied by a plaintext signature or an image of a plaintext signature. The signer generates this signature and provides it, or a hash thereof, to the DSA for including in the locking script of the signature transaction. Alternatively, the DSA may store the plaintext signature, or image thereof, of the signer and, in response to an authorisation message, include this in the locking script of the signature transaction. The plaintext signature, image of the plain text signature, or hash of either, may be referred to as a representation of the signature.

A method may also be used in a non-custodial DSA system. In such an embodiment, the signer holds the private keys corresponding to PK_singerl and PK₁.

The DSA generates TXID'-^ as shown above, or following any of the variations set out above. That is, PK_singerl may be a public key of the signer, or may be an identifier of the signer in a non-cryptographic signature scheme. In any event, PK_singerl is the document signature requirement and identifies the signer.

PKsi_ngeri '^s provided in a first locking script of TXID'-^ together with the representation of the document. The first locking script is configured to store both the signature requirement and the document representation to the blockchain. TXID^ also comprises a second locking script which locks a UTXO to the signer public key PK . Here, the UTXO is a negligible amount of cryptocurrency, in some instances enough only to cover the transaction fee.

The DSA sends TXID^ to a node of the blockchain network for including in a block of the blockchain.

The signer can access TXID'^ , verify that the representation of the document provided in the locking script corresponds to the document they are expected to sign, and generate the signature which satisfied the document signature requirement, SIG_{PK singerl}> e. the signature over the document. The signer generates the signature transaction TXID_2A with a locking script comprising a representation of the signature, which in the example above is a hash of the signature.

The signer also generates a first unlocking script for TXID_2A comprising a signature generated based on the private key corresponding to PK , SIG₁, which signs the signature transaction TXID_2A.

The signer therefore generates a signature over the document, SIG_{PK singerl}, and ^a signature over the transaction SIG₁, thus decoupling the document signature from transactions signing.

1.4 DSA EXTENSIONS

There are several ways the DSA could be extended, including:

• Document originator could set the signing method to be used by the document signers, for example a different signature scheme could be used.

• Pay signers or notaries of the document with Satoshi.

• Allow distinct roles for signers.

• Provide additional fields that need to be completed, e.g., witness's information.

• Provide an envelope of multiple documents for signing. Support multiple organisations, e.g., each with their own users and transaction funds.

• Use a zero-knowledge proof rather than a hash of document.

In the case of signing multiple documents, the document transaction may include a commitment to each document individually, or a single commitment for all documents. For example, there may be a hash of each document, or a hash of a concatenation of the documents. Which is included may depend on the signing requirements. For example, if it is valid to sign some documents but not the complete set, separate hashes would be provided. However, it would be more likely that the documents should be signed as a complete set, so a single (Merkel root) hash of the documents could be used. This may be a setting that the requestor can select when requesting for the document to be signed.

It will be appreciated that any known type of zero-knowledge proof may be used in the methods provided herein. The zero-knowledge proofs may be used to verify between the DSA and the requestor or the DSA and the signer that both entities are referring to the same document. The use of zero-knowledge proofs provides means for referencing the document to be signed without revealing document data.

It is noted that a zero-knowledge proof may be derived from a hash of the document.

1.5 DECOUPLED DOCUMENT STORAGE

The Orchestrator and document store may not be in direct communication. That is, the DSA system may comprise only the Orchestrator. The purpose of decoupling these two components is to ensure that the DSA does not have any access to the documents, thereby improving security of the system. The DSA only has access to the hash of the document, or zero-knowledge proofs. The user can choose a trusted Documentstore to store classified documents. Furthermore, the user can register an account in the DSA using the custodial or non-custodial solution.

The decoupled system may be implemented using either the custodial, non-custodial, or secure enclave DSAs described herein. T1

1.5.1 Document Preparation

Figure 10 shows an example process of preparing the document in a decoupled embodiment.

• The user 103a uploads the document to the trusted Documentstore 1004 and provides the signer 103b with a link to the document.

• The 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 the user 103a.

• The user 103a adds the signer's information in the DSA 1000.

• The Orchestrator 1002 matches the added signer's information and the registered signer's ID.

• The Orchestrator 1002 publishes the signature request transaction including the document hash and a public key linked to the signer 103b.

• Once the request transaction is spent, the Orchestrator 1002 updates the transaction ID linking to the document ID.

1.5.2 Document Signing

The document signing process is similar to the process described in section 1.1.3 (custodial) or section 1.2.4 (non-custodial). The only difference is that the signer receives the document link prior to, and independent of, the request for signing notification from the DSA.

1.5.3 Document Finalisation

The document finalisation step is unchanged when the document storage is decoupled.

1.5.4 Issues for Implementation and their Resolution

One issue is that the Orchestrator needs to know all signers' public keys before creating the transaction for signing. This issue can be resolved if the DSA system is custodial as it can generate the keypair when notified of the signer. However, in a non-custodial system it will need to check that all signers' public keys are known. If not, the Orchestrator needs to request the signers to register with their public keys prior to sending out the signing request.

Another issue may be that we present the solution assuming that the key pairs used to sign blockchain transactions are the same as the one used to sign the documents. In most cases, this is not an issue. However, in some cases, the signing request may require using a specific signature scheme other than the one used on the blockchain. In this case, the signer can either generate a corresponding key pair for the specific signature scheme and link it with the key pair used on the blockchain, or they can send a signed instruction to the Orchestrator to generate the key pair for the specific signature scheme and sign on their behalf. The signature scheme may be any public-private key pair scheme, and is not limited to ECDSA.

The final issue that may arise from the solution is the concern over privacy by reusing the key pairs. One way to address that is to derive unbounded number of keys while making sure that each key pair used is linked to the certified one.

2. EXAMPLE SYSTEM OVERVIEW

A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below.

Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation 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 the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers. The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and/or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data.

In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly.

Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104.

Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising 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 equipment such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and/or an optical medium such as an optical disk drive.

The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.

A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.

In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

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

Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, 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, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations.

Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104).

Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his/her respective computer equipment 102a, and a second party 103b and his/her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively.

The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and/or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as 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 the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

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

The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 104 in the network 106.

An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.

Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a "recipient" field (in which a receiving address of an account is specified) and a "value" field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an outputbased transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction 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 that contains a script configured to perform one or more actions (e.g. send or "release" a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

3. UTXO-BASED MODEL

Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.

In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.

Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled " TxT. It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “ Txo" in Figure 2. TAT? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and/or node behaviour. One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.

The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions.

So in the example illustrated, UTXOo in the output 203 of TAT? comprises a locking script [Checksig PA which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig PA contains a representation (i.e. a hash) of the public key PA from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these. When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria).

Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain.

Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred.

4. FURTHER REMARKS Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims.

For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104. However it will be appreciated that the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and/or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above.

In preferred embodiments of the invention, the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and/or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the preferred bitcoin network 106).

In other embodiments of the invention, the blockchain network 106 may not be the bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and/or propagate those blocks 151 to other nodes.

Even more generally, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity/element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity/element may be implemented in hardware in the same way described above with reference to a blockchain node 104.

Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof- of-work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof- of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator.

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

Statement 1. A computer-implemented method for signing a document at a document signature system, the method comprising: receiving a signature request comprising an identifier of a signer and identifying the document from a requestor; obtaining a commitment to the document; generating a document blockchain transaction, wherein the document blockchain transaction comprises the commitment to the document and a document signature requirement associated with a signer, wherein satisfying the document signature requirement signs the document; making the document blockchain transaction available to one or more nodes of a blockchain network; receiving, from the signer, a signature authorisation message; in response to receiving the signature authorisation message, generating a signature blockchain transaction, wherein the signature blockchain transaction comprises a signature associated with the signer and which satisfies the document signature requirement; and making the signature blockchain transaction available to one or more nodes of the blockchain network. Statement 2. The method of statement 1, wherein the method further comprises: in response to receiving the signature authorisation message, obtaining from a keystore a private key associated with the signer; and generating the signature of the signature blockchain transaction using the obtained private key associated with the signer.

Statement 3. The method of statement 2, wherein the keystore is stored at the document signature system.

Statement 4. The method of any preceding statement, wherein the document blockchain transaction comprises a first locking script comprising the document signature requirement and configured, when executed together with a first unlocking script of the signature blockchain transaction, to verify the signature satisfies the document signature requirement.

Statement 5. The method of statement 4, wherein the first unlocking script of the signature blockchain transaction comprises the signature, wherein the first unlocking script, when executed together with the document blockchain transaction, is configured to satisfy the document signature requirement.

Statement 6. The method of any of statements 1 to 3, wherein the document blockchain transaction comprises a first locking script comprising the document signature requirement, wherein the first locking script is configured, when executed, to store the document signature requirement on the blockchain.

Statement 7. The method of statement 6, wherein the signature blockchain transaction comprises a first locking script comprising a representation of the signature which satisfies the document signature requirement, and configured to store the representation of the signature to the blockchain.

Statement 8. The method of statement 7, wherein the representation of the signature is a hash of the signature. Statement 9. The method of statement 7 or statement 8 when dependent on statement 1, wherein the method further comprises: receiving from the signer the signature, or the representation of the signature, associated with the signer and for satisfying the document signature requirement; and providing the signature in the first locking script of the signature blockchain transaction.

Statement 10. The method of statement 9, wherein the signature or representation of the signature is received in the signature authorisation message.

Statement 11. The method of any of statements 6 to 10, wherein generating the document blockchain transaction comprises providing, in the first locking script, the commitment to the document, wherein the first locking script is further configured to store the commitment to the document to the blockchain.

Statement 12. The method of any of statements 6 to 11, wherein generating the document blockchain transaction comprises providing a second locking script configured to verify a signature provided in an unlocking script of the signature blockchain transaction when executed together with the unlocking script of the signature blockchain transaction, wherein the signature provided in the unlocking script of the signature blockchain transaction is generated based on a private key of the document signature service.

Statement 13. The method of any preceding statement, wherein the signature authorisation message is received from the signer after the document blockchain transaction has been included in a block by a node of the blockchain network.

Statement 14. The method of any preceding statement, wherein the method further comprises: sending, to the signer, a signature authorisation request comprising a transaction identifier of the document blockchain transaction; wherein the signature authorisation message is received in response to the signature authorisation request. Statement 15. The method of statement 14, wherein the document is stored in a document store in association with a document identifier for identifying the document, wherein the method further comprises: providing the document identifier to the signer in the signature authorisation request.

Statement 16. The method of any preceding statement, wherein the commitment to the document is a hash of the document or a salted hash of the document.

Statement 17. The method of any preceding statement, wherein the signature request further comprises a document identifier for identifying the document, wherein the commitment to the document is obtained by accessing a document store and retrieving data stored therein in association with the document identifier.

Statement 18. The method of statement 16 and statement 17, wherein the commitment to the document is the hash of the document, wherein the data stored in the document store in association with the document identifier is the document, wherein the method further comprises: generating a hash of the retrieved document; wherein the generated hash is included in the document blockchain transaction.

Statement 19. The method of statement 16 and statement 17, wherein the commitment to the document is the salted hash of the document, wherein the data stored in the document store in association with the document identifier is the document, wherein the method further comprises: generating a salted hash of the retrieved document; wherein the generated salted hash is included in the document blockchain transaction.

Statement 20. The method of statement 16 and statement 17, wherein the data stored in the document store in association with the document identifier is the hash of the document or the salted hash of the document, wherein the retrieved hash of the document or retrieved salted hash of the document is included in the document blockchain transaction respectively. Statement 21. The method of any preceding statement, wherein the method further comprises: receiving the document from the requestor; and storing at least one of: the document; a hash of the document; and a salted hash of the document; in a document store together with a document identifier for identifying the document.

Statement 22. The method of statement 21, wherein the document is received prior to receiving the signature request, wherein the method further comprises providing the document identifier to the requestor.

Statement 23. The method of statement 21, wherein the document is received in the signature request.

Statement 24. The method of statement 15 or any statement dependent thereon, wherein the document is stored in the document store, wherein the method further comprises: receiving, from the signer, the document identifier; obtaining, from the document store, the document stored in association with the document identifier; and providing the document to the signer; wherein the signature authorisation message is received in response to providing the document to the signer.

Statement 25. The method of statement 24, wherein the method further comprises: determining if the signer is authorised to access the document; wherein the document is provided to the signer if it is determined that the signer is authorised to access the document; and wherein the document is not provided to the signer if it is determined that the signer is not authorised to access the document.

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

Statement 27. The method of any of statements 1 to 15, wherein the commitment to the document is a Merkle tree derived based on the document and the document signature requirement. Statement 28. The method of statement 27, wherein the method further comprises: receiving, from the requestor, the hash or slated hash of the document; and storing the hash or salted of the document respectively with a document identifier for identifying the document.

Statement 29. The method of any of statements 1 to 8, or any statement dependent thereon, wherein the method further comprises: receiving a registration request from the signer comprising the identifier of the signer; generating a public-private key pair for the signer; and storing the public-private key pair in a keystore in association with the identifier of the signer; wherein the private key is used to generate the signature.

Statement 30. The method of statements 3 to 5 and statement 29, wherein generating the document blockchain transaction comprises: obtaining, from the keystore, the public key associated with the signer; and providing the first locking script derived based on the public key associated with the signer.

Statement 31. The method of statement 30, wherein generating the document blockchain transaction comprises providing a second locking script configured to store the commitment to the document to the blockchain.

Statement 32. The method of statement 31, wherein the method further comprises providing a third locking script configured to verify a signature provided in a second signature blockchain transaction when executed together with an unlocking script of the second signature blockchain transaction.

Statement 33. The method of any preceding statement, wherein the method further comprises storing an identifier of the document blockchain transaction in association with a document identifier for identifying the document.

Statement 34. The method of statement 33, wherein the method further comprises storing an identifier of the signature blockchain transaction in association with the identifier of the blockchain transaction and the document identifier. Statement 35. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 1 to 34.

Statement 36. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 34.

Claims

1. A computer-implemented method for signing a document at a document signature system, the method comprising: receiving a signature request comprising an identifier of a signer and identifying the document from a requestor; obtaining a commitment to the document; generating a document blockchain transaction, wherein the document blockchain transaction comprises the commitment to the document and a document signature requirement associated with a signer, wherein satisfying the document signature requirement signs the document; making the document blockchain transaction available to one or more nodes of a blockchain network; receiving, from the signer, a signature authorisation message; in response to receiving the signature authorisation message, generating a signature blockchain transaction, wherein the signature blockchain transaction comprises a signature associated with the signer and which satisfies the document signature requirement; and making the signature blockchain transaction available to one or more nodes of the blockchain network.

2. The method of claim 1, wherein the method further comprises: in response to receiving the signature authorisation message, obtaining from a keystore a private key associated with the signer; and generating the signature of the signature blockchain transaction using the obtained private key associated with the signer.

3. The method of claim 2, wherein the keystore is stored at the document signature system.

4. The method of any preceding claim, wherein the document blockchain transaction comprises a first locking script comprising the document signature requirement and configured, when executed together with a first unlocking script of the signature blockchain transaction, to verify the signature satisfies the document signature requirement.

5. The method of claim 4, wherein the first unlocking script of the signature blockchain transaction comprises the signature, wherein the first unlocking script, when executed together with the document blockchain transaction, is configured to satisfy the document signature requirement.

6. The method of any of claims 1 to 3, wherein the document blockchain transaction comprises a first locking script comprising the document signature requirement, wherein the first locking script is configured, when executed, to store the document signature requirement on the blockchain.

7. The method of claim 6, wherein the signature blockchain transaction comprises a first locking script comprising a representation of the signature which satisfies the document signature requirement, and configured to store the representation of the signature to the blockchain.

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

9. The method of claim 7 or claim 8 when dependent on claim 1, wherein the method further comprises: receiving from the signer the signature, or the representation of the signature, associated with the signer and for satisfying the document signature requirement; and providing the signature in the first locking script of the signature blockchain transaction.

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

11. The method of any of claims 6 to 10, wherein generating the document blockchain transaction comprises providing, in the first locking script, the commitment to the document, wherein the first locking script is further configured to store the commitment to the document to the blockchain.

12. The method of any of claims 6 to 11, wherein generating the document blockchain transaction comprises providing a second locking script configured to verify a signature provided in an unlocking script of the signature blockchain transaction when executed together with the unlocking script of the signature blockchain transaction, wherein the signature provided in the unlocking script of the signature blockchain transaction is generated based on a private key of the document signature service.

13. The method of any preceding claim, wherein the signature authorisation message is received from the signer after the document blockchain transaction has been included in a block by a node of the blockchain network.

14. The method of any preceding claim, wherein the method further comprises: sending, to the signer, a signature authorisation request comprising a transaction identifier of the document blockchain transaction; wherein the signature authorisation message is received in response to the signature authorisation request.

15. The method of claim 14, wherein the document is stored in a document store in association with a document identifier for identifying the document, wherein the method further comprises: providing the document identifier to the signer in the signature authorisation request.

16. The method of any preceding claim, wherein the commitment to the document is a hash of the document or a salted hash of the document.

17. The method of any preceding claim, wherein the signature request further comprises a document identifier for identifying the document, wherein the commitment to the document is obtained by accessing a document store and retrieving data stored therein in association with the document identifier.

18. The method of claim 16 and claim 17, wherein the commitment to the document is the hash of the document, wherein the data stored in the document store in association with the document identifier is the document, wherein the method further comprises: generating a hash of the retrieved document; wherein the generated hash is included in the document blockchain transaction.

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

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

21. The method of any preceding claim, wherein the method further comprises: receiving the document from the requestor; and storing at least one of: the document; a hash of the document; and a salted hash of the document; in a document store together with a document identifier for identifying the document.

22. The method of claim 21, wherein the document is received prior to receiving the signature request, wherein the method further comprises providing the document identifier to the requestor.

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

24. The method of claim 15 or any claim dependent thereon, wherein the document is stored in the document store, wherein the method further comprises: receiving, from the signer, the document identifier; obtaining, from the document store, the document stored in association with the document identifier; and providing the document to the signer; wherein the signature authorisation message is received in response to providing the document to the signer.

25. The method of claim 24, wherein the method further comprises: determining if the signer is authorised to access the document; wherein the document is provided to the signer if it is determined that the signer is authorised to access the document; and wherein the document is not provided to the signer if it is determined that the signer is not authorised to access the document.

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

27. The method of any of claims 1 to 15, wherein the commitment to the document is a Merkle tree derived based on the document and the document signature requirement.

28. The method of claim 27, wherein the method further comprises: receiving, from the requestor, the hash or slated hash of the document; and storing the hash or salted of the document respectively with a document identifier for identifying the document.

29. The method of any of claims 1 to 8, or any claim dependent thereon, wherein the method further comprises: receiving a registration request from the signer comprising the identifier of the signer; generating a public-private key pair for the signer; and storing the public-private key pair in a keystore in association with the identifier of the signer; wherein the private key is used to generate the signature.

30. The method of claims 3 to 5 and claim 29, wherein generating the document blockchain transaction comprises: obtaining, from the keystore, the public key associated with the signer; and providing the first locking script derived based on the public key associated with the signer.

31. The method of claim 30, wherein generating the document blockchain transaction comprises providing a second locking script configured to store the commitment to the document to the blockchain.

32. The method of claim 31, wherein the method further comprises providing a third locking script configured to verify a signature provided in a second signature blockchain transaction when executed together with an unlocking script of the second signature blockchain transaction.

33. The method of any preceding claim, wherein the method further comprises storing an identifier of the document blockchain transaction in association with a document identifier for identifying the document.

34. The method of claim 33, wherein the method further comprises storing an identifier of the signature blockchain transaction in association with the identifier of the blockchain transaction and the document identifier.

35. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 34.

36. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 34.