Cryptographic method and system for secure extraction of data from blockchain

Abstract

To provide a computer implemented method for connection to a hierarchical network.SOLUTION: A hierarchical network includes a plurality of nodes arranged in a set of ordered layers. The set of ordered layers includes, in order, a core layer including a set of core nodes, a second layer including a set of second nodes, and one or more outer layers which include respective sets of outer nodes, respectively. Each core node is connected to at least one other core node. A method is executed by a connection node and includes connecting to the network according to a connection protocol. The connection protocol requires that each node must connect with at least one node of a preceding layer and each outer node must connect with at least one core node.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] This disclosure relates generally to cryptographic techniques for secure processing, transmission, and exchange of data. This disclosure also relates to peer-to-peer distributed ledgers, such as, but not limited to, the Bitcoin blockchain and related technologies. In particular, this disclosure relates to control solutions for identifying, protecting, retrieving, transmitting, and updating data in a cryptographically controlled and secure manner. This disclosure also relates to the ability to communicate data between different computing systems and system interoperability. [Background technology]

[0002] A blockchain is a computer-based, decentralized, distributed, peer-to-peer electronic ledger implemented as a system composed of blocks, each of which consists of transactions. Each transaction is a data structure that encodes the transfer of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain, from its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0003] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform the work of ensuring each transaction is valid, with invalid transactions being rejected by the network. A software client installed on the node performs this validation on unspent transactions (UTXOs) by executing its locking and unlocking scripts. If the locking and unlocking scripts evaluate to TRUE, the transaction is valid and is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives it—and if the transaction is verified, this node relays the transaction to other nodes in the network—ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions.

[0004] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be more diverse in their applications while still being able to take advantage of the benefits of blockchain (e.g., distributed processing of a permanent, tamper-resistant record of events).

[0005] One area of ​​current research is the use of blockchain to implement "smart contracts." A smart contract is a computer program designed to automate the execution of machine-readable contracts or agreements. Unlike traditional contracts, which may be written in natural language, a smart contract is a machine-executable program that contains rules that can process inputs to produce results and then cause actions to be taken depending on those results. Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Thus, the token acts as an identifier that allows real-world items to be referenced from the blockchain.

[0006] In this disclosure, these technologies are used in novel and advantageous configurations that allow data and assets to be transferred between different computer systems, one of which is blockchain. Computer systems used within large organizations or entities are often very large, complex, and technologically diverse. Security of data is typically of paramount importance. Access to and utilization of data stored in the systems needs to be efficient and cost-effective. There is a need to overcome at least some of the technical difficulties that arise from using complex computing systems within large organizations that are often hierarchical in nature.

[0007] In this document, a financial accounting context is used to illustrate one possible use or application of the present invention. However, it is important to note that this example is for illustrative purposes only, and the present invention is not limited in this respect. Instead, the present invention provides a general, cryptographically implemented, blockchain-based solution for use with any type of non-blockchain-implemented computing system associated with an organization.

[0008] In relation to an exemplary use, an entity's general ledger is a collection of accounts that summarizes all financial transactions that occur within the entity. The structure of this collection of accounts is typically established by the individual entity itself and may include accounts reported in business financial statements, such as cash, accounts payable, expense accounts, and purchases and loans. In some situations, a general ledger may be subdivided into multiple sub-ledgers. In such cases, each sub-ledger within the general ledger may hold a separate or current balance of financial position based on monetary exchange for each account that the entity needs to track.

[0009] An accounting setup for an entity can be relatively complex, with hundreds or even thousands of separate reporting points, i.e., business units, divisions, products, etc. Parallel books may be required, for example, one per product line, one per division, etc.

[0010] Large entities may implement complex financial systems that are based on large database structures to manage accounts for a general ledger. For example, a financial system may require the management and synchronization of various databases so that captured data can be accurately reported.

[0011] The term "blockchain" is used in this document to include all forms of electronic, computer-based distributed ledgers, including, but not limited to, peer-to-peer consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. While Bitcoin may be referenced in this disclosure for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. Summary of the Invention

[0012] The invention is defined in the claims.

[0013] The present invention may provide cryptographic methods and corresponding systems. The present invention may provide blockchain-implemented methods / systems. The present invention may provide control systems for secure identification, retrieval, transmission, processing, and / or updating of data. The present invention may provide methods / systems for integrating blockchains with non-blockchain-implemented computing resources (e.g., data storage / processing resources) using cryptographic keys. The present invention may provide methods / systems for extracting data from a blockchain and / or integrating blockchain-sourced data into non-blockchain-implemented storage resources using cryptographic keys. The present invention may provide a computer-implemented method for generating records of an entity's interest (first) structure in or from a peer-to-peer distributed ledger (i.e., blockchain). An entity may be referred to as an organization, a system, or a network.

[0014] The present invention offers significant advantages over the prior art, particularly because it enables secure processing of data, the integrity of which is preserved through the use of novel cryptographic techniques. The present invention also enables communication and exchange of data between separate computer systems implemented with different designs, structures, architectures, and protocols. Thus, the present invention provides system interoperability. The present invention enables the use of cryptographic keys to act as a facilitator or interface between existing computer systems and blockchains without the need to modify the structure or protocol of either party. The present invention provides enhanced performance and efficiency of data processing, as it facilitates the management and synchronization of potentially multiple complex systems, such as databases.

[0015] An entity may be composed of multiple elements, such as, for example, a system component, an account, a data record, or a network entity. An entity may be a hierarchical entity with multiple elements organized or related in a hierarchical relationship. These elements within an entity may form a structure of elements, which may be a hierarchical structure. The structure may include a chain or tree-like hierarchy that defines or reflects the relationships or associations between these elements within the entity. These elements within the structure may be related to subentities, units, or other collections within the entity.

[0016] An entity and / or one or more elements within a structure may be associated with a respective cryptographic key. This key may form part of a public / private key pair. There may be one key or key pair designated as a "root" key / pair. Further elements within the structure may be associated with subkeys or pairs derived from this root. Subkeys may be generated deterministically. Subkeys may be generated or determined substantially as described in the section below entitled "Methods for Subkey Generation." Subkeys may be generated, derived, or determined based on another (previous) key. Subkey generation may include the use of ECC techniques. Subkeys may be generated, derived, or determined using a deterministic key (DK) based on a cryptographic hash of a message (M). Messages may be random, pseudo-random, predefined, or selected. In a preferred embodiment, messages are selected, constructed, or created to correspond to meaningful values, such as account numbers. Messages may have some meaning related to an entity or subentity / element. Messages may provide a link, association, or reference to an entity or element. The subkeys may be determined based on a scalar addition of the associated public parent key and a scalar multiplication of the deterministic key and a generator (G). The message may be stored within the blockchain transaction (Tx) or as metadata within the blockchain transaction (Tx). The message may be rehashed to provide additional subkeys.

[0017] The invention associating one or more elements of the structure with a cryptographic subkey derived from another cryptographic key; extracting data including or related to the element's subkeys from a blockchain transaction (Tx); sending the extracted data to a non-blockchain based computer system; A non-blockchain based computer system may not be part of a blockchain.

[0018] The method may include scanning, traversing, and / or analyzing the blockchain to identify one or more blockchain transactions (TXs) that include the element's cryptographic subkey or that include data related to the element's cryptographic subkey.

[0019] The method may further include processing the extracted data to generate an output. In one embodiment, the output may be a result, a calculation, a report, a decision, or a record, such as a financial accounting record. The method may include communicating the output to a destination over a network.

[0020] Additionally or alternatively, the invention may include: identifying a set of first structure public keys including at least one public root key associated with the first structure and one or more associated public subkeys; deriving a deterministic association between at least one public root key and one or more associated public subkeys; Extracting (copying) transaction data / information from a plurality of blockchain transactions from a peer-to-peer (P2P) distributed ledger (blockchain), the extracted data comprising at least: data indicative of a transaction between the first structure and at least one further structure; a first structure public key associated with the first structure, the first structure public key being part of a cryptographic pair including the first structure public key and the first structure private key; and generating an output (e.g., financial accounting records) for the first structure of interest by matching the set of first structure public keys against the extracted transaction data using the deterministic association; may include:

[0021] A transaction between the first structure and at least one further structure may involve the transfer of an asset from one party to another. The asset may be a tokenized asset or some type of digital asset. It may be part of a cryptocurrency. The transaction may transfer ownership and / or control of the asset from one party to another.

[0022] The blockchain may be associated with a cryptocurrency. For example, the blockchain may be the Bitcoin blockchain. Alternatively, another cryptocurrency or blockchain protocol may be used.

[0023] The first structure may represent a defined group of items, e.g., elements within an entity. The items may be physical or logical, e.g., accounts. For example, the first structure may be associated with a first business unit, such as a first group, department, or team of users; a first product or service of the entity; or the entity as a whole.

[0024] At least one further structure may exist within the entity, for example, the at least one further structure may be associated with a second business unit or a second product or service.

[0025] Alternatively, the at least one further structure may reside within the further entity, for example, the at least one further structure may be associated with a business unit of the further entity, a product or service of the further entity, or the further entity as a whole.

[0026] The first structure public key set may include at least one public root key and all associated public subkeys.

[0027] The step of deriving a deterministic association between at least one public root key and one or more associated public subkeys may include determining rules for determining the public subkeys from the associated parent key. For example, the rules for determining the subkeys may include determining a hash of a message to generate a seed value.

[0028] The deterministic association between at least one public root key and one or more associated public subkeys may be a tree hierarchy. Alternatively, the deterministic association may be a chain hierarchy.

[0029] Each public subkey may represent a virtual or physical or logical item (eg, an account) within the entity.

[0030] The step of identifying the set of first structure public keys may include identifying at least one public root key and determining one or more public sub-keys based on the at least one public root key. The at least one public root key may be identified by retrieving data, such as a chart of accounts, from an internal database.

[0031] The step of extracting transaction data from the plurality of transactions from the blockchain includes extracting the following data items from the plurality of transactions: Transaction input values; A transaction output value; and rules for deriving transaction input values ​​or transaction output values ​​based on data indicative of the transaction; A timestamp for the transaction; The block number of the block in the blockchain, The method may further include extracting or copying one or more of:

[0032] The transaction between the first structure and the further structure may relate to a currency exchange, a contractual arrangement, a goods or services exchange, or the like. With respect to a currency exchange, it will be appreciated that the transaction may relate to a cryptocurrency exchange, such as Bitcoin, or may relate to a fiat currency exchange, for example by using a token amount of cryptocurrency.

[0033] Extracting transaction information from a plurality of transaction records from the P2P distributed ledger may include identifying transaction records not previously extracted to generate financial accounting records. In one example, the method may include identifying block numbers of blocks in the P2P distributed ledger and comparing the block numbers to previously generated financial accounting records.

[0034] The method may include posting the output to a computer-based resource, which may be any type of computer-based system, such as a database system, or a financial accounting ledger, which may be internal to the entity in that it may be arranged and configured for storage of data relating to the entity and / or sub-entities of the entity. The computer-based resource may be a general ledger for the entity.

[0035] Alternatively, a financial accounting ledger may be a sub-ledger of an entity's general ledger. As noted above, an entity's general ledger generally represents a collection of accounts that summarize all financial transactions that occur within the entity.

[0036] The step of transcribing the generated output into a computer-based resource may be performed automatically, in other words, it may be an automated process performed by a computer that does not require human intervention.

[0037] The step of transcribing the generated output may be performed periodically, which may be after a predetermined period of time or at a defined time.

[0038] The step of transcribing the generated output may include writing the generated output to one or more locations or files, which may be referred to as transcription files, for example. The one or more transcription files may have any suitable format, such as JSON, XML, or XBRL. The one or more transcription files may be encrypted. For example, the one or more transcription files may be hashed. In a further example, the one or more transcription files may be encrypted using the calculated secret. An example of calculating the secret is described in more detail below in the section entitled "Method of Subkey Generation."

[0039] The method may include signing one or more transcription files with a first structure private key, the first structure private key being part of an asymmetric cryptographic pair including the first structure private key and an associated first structure public key. In this manner, the one or more transcription files may be verified using the first structure public key associated with the first structure private key used to sign the one or more transcription files.

[0040] The method may include storing the generated output. In one particular example, the generated output may be recorded in an internal database or other storage facility of or within the entity. In another example, the generated output may be stored in a public database, which may be centralized or decentralized, such as a distributed hash table. In a particular example, the generated output may be stored in the blockchain in the form of a transaction (Tx). For example, the generated output may be recorded as metadata in (the) blockchain transaction (Tx). A hash value of the transaction may be signed using the private key of the first structure of interest.

[0041] The method may include encrypting the generated output for storing the data in a database or blockchain.

[0042] The method may include hashing and / or signing the generated output for storing the generated output in a database, a storage facility, or a blockchain.

[0043] The method may include analyzing the generated output. In one example, the method may include determining cash flows for the first structure of interest. In a further example, the method may include determining assets and / or liabilities for the first structure of interest.

[0044] The step of posting the generated financial accounting records may include making the generated financial accounting records available to a dedicated accounting system, which may be configured to execute dedicated accounting software for the entity.

[0045] According to an embodiment of the present disclosure, there is provided a computer system configured to perform any of the embodiments of the method of the present invention, which may be configured to generate a record of an entity's first structure of interest in a blockchain, identifying a set of first structure public keys including at least one public root key associated with the first structure and one or more associated public subkeys; Derive a deterministic association between at least one public root key and one or more associated public subkeys. a processing device configured to: 1. A network interface configured to extract transaction information from a plurality of transaction records from a peer-to-peer (P2P) distributed ledger, the extracted information comprising at least: information indicative of a transaction between the first structure and at least one further structure; a first structure public key associated with the first structure, the first structure public key being part of a cryptographic pair including the first structure public key and the first structure private key; a network interface including: and The processing device is further configured to generate financial accounting records for the first structure of interest by matching the set of first structure public keys to the extracted transaction information using the deterministic association.

[0046] A computer program comprising machine readable instructions to cause a processing device to perform any one of the methods described above is provided. [Brief explanation of the drawings]

[0047] Embodiments of the present disclosure will now be described, by way of non-limiting example, with reference to the accompanying drawings, in which: [Figure 1] 1 is a schematic diagram of an exemplary system for generating financial accounting records. [Figure 2] 2 is another schematic diagram of an exemplary computer system for generating financial accounting records. [Figure 3] 1 is a flowchart of an exemplary computer-implemented method for determining an accounting structure for generating financial accounting records. [Figure 4] Schematic diagram showing a deterministic association between a root public key and one or more public subkeys. [Figure 5] 1 is a flowchart of an exemplary computer-implemented method for extracting information from a P2P distributed ledger (blockchain) to generate financial accounting records. [Figure 6] 4 is a flowchart of an exemplary computer-implemented method for posting generated financial accounting records to a financial accounting ledger. [Figure 7] FIG. 2 illustrates aspects of an exemplary technique for deriving sub-keys from a parent key, as described below, suitable for use in connection with aspects of the present invention. [Figure 8] FIG. 2 illustrates aspects of an exemplary technique for deriving sub-keys from a parent key, as described below, suitable for use in connection with aspects of the present invention. [Figure 9]FIG. 2 illustrates aspects of an exemplary technique for deriving sub-keys from a parent key, as described below, suitable for use in connection with aspects of the present invention. [Figure 10] FIG. 2 illustrates aspects of an exemplary technique for deriving sub-keys from a parent key, as described below, suitable for use in connection with aspects of the present invention. [Figure 11] FIG. 2 illustrates aspects of an exemplary technique for deriving sub-keys from a parent key, as described below, suitable for use in connection with aspects of the present invention. [Figure 12] FIG. 2 illustrates aspects of an exemplary technique for deriving sub-keys from a parent key, as described below, suitable for use in connection with aspects of the present invention. [Figure 13] FIG. 2 illustrates aspects of an exemplary technique for deriving sub-keys from a parent key, as described below, suitable for use in connection with aspects of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0048] overview The present disclosure generally relates to methods and systems that use peer-to-peer (P2P) distributed ledgers (hereinafter "blockchain"), such as the Bitcoin blockchain, in identifying, extracting, transmitting, processing, and / or updating data. The present invention provides a secure, cryptographically implemented solution for using data posted to the blockchain to augment, append, or integrate data with computer-based resources provided within an organization (entity). The computer-based resources may be databases, accounting systems, or any other type of computer-based facility for storing and / or processing data. Because this system is not part of the blockchain and is internal to the organization, it may be referred to as an "internal" system.

[0049] The present invention provides a data control and security solution by assigning cryptographic keys to elements associated with an entity or sub-entity. These elements are organized into a structure (linear or tree) defined or specified by the relationships between the elements. Each element in the structure is associated with a cryptographic public / private key pair, with the root key pair at the highest level of the structure. Elements lower in the structure are associated with key pairs that are deterministically derived from the previous key pair. This deterministic derivation may preferably be performed according to a method substantially described in the section below entitled "Method of Sub-Key Generation." Thus, a hierarchy of cryptographic key pairs is generated to reflect the hierarchical relationships between elements within the entity. In the examples below, the term "account" may be used in place of "element."

[0050] Without intending to limit the nature of the present invention to this area of ​​use or application, and purely for illustrative purposes, an example is provided of using the present invention to generate financial accounting records for an entity's structure of interest. It is important to note that this financial aspect is not essential to the present invention, and the present invention may be used in conjunction with any type of computer-based internal system for the control, transmission, and security of any type of data.

[0051] In this example, the structure of interest may be a business unit, such as a department or sub-entity within the entity, or may represent the entire entity for which outputs (e.g., accounting records) are to be generated. Alternatively, the structure of interest may relate to goods or services of interest or any suitable structure of the entity for which financial accounting records are to be generated and, optionally, posted to, for example, the entity's general ledger.

[0052] Embodiments of the present disclosure provide significant advantages, such as using a public blockchain, such as the Bitcoin blockchain, to generate records of financial transactions because the Bitcoin blockchain is inherently distributed. This means that transaction records on the Bitcoin blockchain are synchronized and stored across the network, ensuring that all information is distributed and public.

[0053] Furthermore, the generated financial and accounting records for the structure of interest can be recorded on the same blockchain, for example in the form of metadata in transaction records. This offers the advantage of creating a permanent, immutable public record that is a true and accurate reflection of the entity's activities. This may ultimately eliminate the need for the assistance of external parties such as auditors.

[0054] 1, a computer system 10 for generating accounting records according to an exemplary embodiment of the present disclosure is shown. The financial accounting records may be posted to a financial accounting ledger, such as, for example, an entity's general ledger.

[0055] In this example, the computer system includes a processor 12 configured to control and coordinate operation, a memory 14, and a network interface 16, which communicate with each other via a bus 18. The network interface 16 facilitates wireless communication between the computer system 10 and a P2P distributed ledger, such as the Bitcoin blockchain 20, over a communications network, in this example the Internet 22.

[0056] Memory 14 stores instructions 24 and data 26 for the processes described below, and processor 12 executes instructions 24 from memory 14 to perform the processes. It should be noted that while computer system 10 is illustrated as a separate network element, computer system 10 may alternatively be part of another network element, and functions performed by computer system 10 may be distributed among multiple network elements. Computer system 10 may represent a first entity computer system.

[0057] 1 also shows a second entity, a further computer system 28. It will be appreciated that this is for illustrative purposes only and that other computer systems or entities may be part of the network.

[0058] Financial accounting ledger / general ledger for the entity As mentioned above, a general ledger is a collection of accounts that summarizes all financial transactions that occur within an entity. It is typically used as the entity's primary financial record and incorporates all financial transactions (accounts) related to the entity. These may include asset accounts (e.g., cash and cash equivalents, securities, accounts receivable, inventory, and intellectual property) and liability accounts (e.g., notes payable, accounts payable, expense accounts, and borrowings). The above example accounts are merely illustrative and should not be construed as limiting. Each account in a general ledger traditionally maintains a balance of the entity's financial position based on the monetary exchange for each account.

[0059] Both small and large entities need to keep records of their accounts using general ledgers, but larger entities may need to keep track of thousands or even hundreds of thousands of accounts. Such tracking can be a large and potentially complex task. There are several difficulties associated with keeping a very large general ledger, and such a ledger could potentially take days to audit or balance.

[0060] In this regard, some organizations may consider introducing sub-ledgers within the general ledger to simplify the complexity of the general ledger.

[0061] The general ledger may be subject to an entity's internal and external audits. Audits are often tedious and time-consuming tasks performed by specially designated auditors. However, by recording the general ledger, or one or more of the sub-ledgers, on a publicly viewable blockchain, this may facilitate and alleviate the auditor's tasks.

[0062] Hereinafter, the term "financial accounting ledger" may refer to an entity's general ledger or one or more of the sub-ledgers within the general ledger. However, the present invention is not limited to use with financial or accounting systems, and any other type of computer-based system may be used.

[0063] Bitcoin Blockchain Although the embodiments described below may make particular reference to transaction records on the Bitcoin blockchain (or Blockchain), it will be understood that the present disclosure may be implemented using any blockchain. For simplicity's sake, the Bitcoin blockchain is used below to describe aspects of the present disclosure solely because of its high level of standardization and the large amount of public documentation associated with it.

[0064] Blockchain is a public transaction ledger that is distributed across network nodes participating in the system based on the Bitcoin protocol. Each Bitcoin transaction is broadcast to the network, the transactions are confirmed, and then aggregated into blocks. These blocks are then included on the Blockchain.

[0065] A complete copy of a blockchain contains every transaction (Tx) that has ever been posted to the ledger since its inception, thus providing a continuously growing list of transaction records. Because each transaction entered on the blockchain is cryptographically enforced, the blockchain is hardened against tampering and revision, even by operators of data store nodes.

[0066] Due to the transparency of the Bitcoin blockchain, the transaction history is publicly available for each transaction. Another advantage of the Blockchain is that a transaction and its record are the same, i.e., the transaction record is embedded within the transaction.

[0067] In this way, the information related to the data exchange is captured in the actual transaction (Tx). Because this record is permanent and immutable, each transaction made using Bitcoin is not only facilitated by the Blockchain, but is also immutably recorded on the Blockchain. This therefore removes the need for third parties to keep transaction records in separate databases.

[0068] In embodiments of the present disclosure, instead of or in addition to being used in its designed function of storing transaction records representing payments of Bitcoin from one party to another, Blockchain is used in a novel manner to generate data about an entity's or organization's interest structures, such as business units or products of interest. Such data may be used in any predictable manner, such as, for example, generating accounting records. For purposes of simplicity, but not limitation, the following examples refer to "accounting records." In this example, the generated accounting records are suitable for posting to the entity's general ledger or for providing to the entity's dedicated accounting system.

[0069] The following exemplary embodiments will refer to the Bitcoin blockchain as the public ledger, but it should be understood that the present disclosure applies to any blockchain platform or protocol.

[0070] Functional Components of a Computer System A representation of an example implementation of computer system 40 is shown in Figure 2, where the functional components of computer system 40 are illustrated in place of hardware components. The functional components in this example may be implemented using the hardware components of computer system 10 shown in Figure 1, such that a network interface is provided to facilitate access to the Bitcoin blockchain.

[0071] In this example, computer system 40 comprises a control unit 42 that controls and coordinates the operation of the components of computer system 40. This control unit 42 may be realized, for example, by processor 12 shown in FIG.

[0072] Additionally, the computer system 40 has a network interface 44 to facilitate access to information stored on the Bitcoin blockchain 20 via the Internet 22.

[0073] Computer system 40 further includes a database management system (“DBMS”) 50 that stores data received and / or generated at computer system 40 in data storage 52. It will be appreciated that such data may alternatively be stored in a remote database, such as cloud storage, or may be received at computer system 40 via internet 22 via network interface 44.

[0074] The data storage 52 includes memory for storing accounting configuration data 54 of the first entity. For example, the accounting configuration data 54 may include a chart of accounts that collects account names and identifiers for each account. This may further include information regarding the public root key, as will be described in more detail with reference to FIG. 4.

[0075] The stored transaction configuration data 54 may be accessed by a transaction configuration determiner 56 of the computer system 40 .

[0076] Data storage 52 further includes memory for storing transcription files 58 created by transcription component 60 of computer system 40. For example, generated financial accounting records may be written to one or more transcription files, which may be stored in data storage 52.

[0077] The computer system 40 further includes a transaction information collector 62 in communication with the network interface 44 to obtain transaction information from transaction records on the Bitcoin blockchain 20 via the Internet 22.

[0078] A matching component 64 of computer system 40 communicates with accounting configuration determiner 56 and transaction information collector 62. Matching component 64 is configured to match extracted transaction information from the blockchain against identified public keys associated with respective accounts of entities to generate financial accounting records.

[0079] As described above, these generated financial accounting records may then be written to one or more posting files and posted to the entity's general ledger 66 in data storage 52.

[0080] Overview of an exemplary method for generating financial accounting records In the following, the method for generating financial accounting records is divided into four main method steps: determining an accounting structure (100), extracting transaction information from transaction records on the blockchain (200), generating financial accounting records and creating one or more posting files (300), and posting the one or more posting files to the entity's general ledger (400).

[0081] The first structure of interest may be any suitable structure of the first entity for which accounting records are to be generated. For example, the first structure may relate to the first entity as a whole, and the generated accounting records will be posted to the first entity's general ledger. In another example, the first structure of interest may represent a business unit, such as a department, team, or designated group of employees. Alternatively, the first structure of interest may relate to a first product or service that may span multiple business units. In this manner, the generated accounting records may be created to analyze accounts associated with the desired product or service.

[0082] Accounting Configuration 3 and 4, a flow chart illustrating method steps for determining accounting configuration 100 and a schematic diagram of some of the method steps of method 100 are shown.

[0083] In particular, method 100 may include identifying a set of first entity public keys including at least one public root key associated with the first entity and one or more associated public subkeys, each of which may represent an account within the first entity. In this regard, the set of first entity public keys may be identified by first identifying (100.10) one or more accounts for which financial accounting records are to be generated.

[0084] In a further step, at least one public root key associated with the identified one or more accounts is identified (100.20). This may be done by accessing data stored in the first entity's internal data storage, such as data storage 54 shown in FIG. 2. The internal data storage may store a chart of accounts that collects account names and identifiers for each account. The identifiers may include the associated public root key. In the example shown in FIG. 3, method 100 identifies three public root keys that may represent accounts in three different business units.

[0085] Method 100 further includes step 100.30 of determining a deterministic association between the identified public root key and one or more public subkeys. In other words, rules for deriving one or more public subkeys that depend on the public root key are determined. In the particular example shown in Figure 4, the deterministic association defines a tree hierarchy in which each of the three identified public root keys is associated with successive child and grandchild tree nodes.

[0086] Following the determination of the deterministic association in step 100.30, one or more public sub-keys associated with the at least one public root key are determined, some selected using information from the chart of accounts in step 100.10. It will be appreciated that depending on the identity of the account for which an accounting record is to be generated, all or only some of the public sub-keys that depend on the public root key may be determined.

[0087] In this particular example shown in Figure 4, four public subkeys have been selected for the generation of financial accounting records: the first child of the first public root key, the first and first grandchild of the second public root key, and the second child of the third public root key. These four public subkeys may be associated, for example, with particular products or services across three different business units represented by these public root keys.

[0088] In one particular example, a series of successive deterministic public keys may be determined, where each successive public key may be determined based on the previous public key. For example, elliptic curve cryptography (ECC) may be used. In this regard, a subkey may be determined by first determining a deterministic key (DK) based on a cryptographic hash of a message (M), which may be random, pseudorandom, or predefined. The subkey may then be determined based on a scalar addition of an associated public parent key and a scalar multiplication of the deterministic key (DK) and a generator (G). To re-determine the deterministic key (DK) and thereby the subkey, only the message (M) and the generator (G) are required. In this regard, the message (M) may be stored in the form of metadata of a transaction record on the blockchain, for example, in the form of an invoice number.

[0089] In a further example, the message may be rehashed to determine the next generation public subkey.

[0090] The steps for determining successive public keys, briefly described above, are described and illustrated in more detail below in the section entitled "Method of Subkey Generation."

[0091] In a further step 100.40, one or more rules are determined for deriving the information to be included in the financial accounting record for the selected public key. In other words, method step 100.40 determines what information is needed for the accounting record to be generated for the general ledger and how this information is to be obtained.

[0092] In particular, this information may include: Transaction input / output; General ledger accounts to post; Reversing general ledger accounts; Rules for calculating value for a transaction; Rules for deriving explanations for transactions.

[0093] Extracting information from the blockchain Referring now to FIG. 5, a flow chart illustrating a method 200 including method steps for extracting 200 information from the Bitcoin blockchain is shown.

[0094] First, method 200 includes step 200.10 of identifying one or more blocks of the blockchain for extracting transaction information from a plurality of transactions recorded on the blockchain. For example, step 200.10 of identifying one or more blocks may include identifying a first block number associated with a block containing a transaction record not previously used to generate a financial accounting record. This may be done by identifying the associated block number of a block that is part of each transaction record on the blockchain. Alternatively, one or more blocks may be identified based on transaction date or time. As described above, blocks on the Bitcoin blockchain have a defined order, and each block contains a hash of the previous block.

[0095] Once one or more blocks are identified, the transaction records associated with the first structure of the entity are scanned on the Blockchain and matched (200.20) against the subkey identified in step 100.30.

[0096] In a further step 200.30, the rules determined in step 100.40 are executed to extract transaction information from each of the matched transaction records on the Blockchain, thus determining what information needs to be extracted, how to derive predetermined information from the extracted information, and where / how to post this information to the general ledger.

[0097] For example, one or more of the following information from multiple transaction records may be extracted: Transaction input values; Transaction output value; Public key; Metadata; rules for deriving transaction input values ​​or transaction output values ​​based on information indicative of the transaction; a timestamp for the transaction; and The block number of a block in a P2P distributed ledger.

[0098] Once the transaction records in one block are scanned and processed, the next block in the blockchain is scanned for transaction records associated with the first entity.

[0099] Financial accounting records are then generated (200.40) using the extracted information from step 200.30.

[0100] Transaction Records Below, transaction records stored on the Bitcoin blockchain are considered in more detail.

[0101] Each transaction record on the Bitcoin blockchain includes at least a first structure public key associated with a first structure, which indicates that the entity's first structure is related to the transaction stored on the Bitcoin blockchain.

[0102] Furthermore, each transaction (Tx) on the Bitcoin blockchain includes at least information indicating a transaction between a first entity and a further entity. Note that any type of entity can be exchanged between the first entity and the further entity and stored in the transaction.

[0103] Examples of transactions may include Bitcoin transactions such as cryptocurrency exchanges, fiat transactions, tokens (representing any type of transferable contract or asset), contracts, and any type of goods and services.

[0104] token Tokens may represent assets or contracts such as contracts that grant the holder certain rights (virtual banknotes) redeemable for fiat currency, contracts that represent ownership of property (e.g., title deeds), or contracts that grant admission to an event (tickets), to name just a few of many examples. Goods and services may include new or used goods, labor (e.g., billed by the hour), completed work (e.g., mowing the lawn), to name just a few of many examples.

[0105] A token is an exchangeable entity that is represented by / represents a contract. The contract can take one of several forms. For example, a contract can grant rights to a holder or represent ownership of property. The value of a token can be specified by a contract and linked to an underlying BTC amount via a "pegging rate." Tokens are exchangeable through a novel type of transaction that uses a cryptocurrency protocol, such as the Bitcoin protocol. The Bitcoin value of a transaction serves as a token that digitally represents a rights contract. The contract itself can be stored on the transaction, held in a publicly accessible location, or held privately by the parties to the contract, depending on the specific embodiment. If the contract is not stored on the transaction, the transaction can store a unique pointer to the contract.

[0106] Tokens may be divisible. A divisible token is one in which the value associated with a transaction output can be subdivided into smaller amounts that can be allocated across multiple new tokens. Examples of divisible tokens include tokens for fiat currency or for racehorse shares. Divisible contracts may be defined as specifying a non-zero pegging rate. In other words, the token value is pegged to the underlying Bitcoin value. Alternatively, tokens may be indivisible. An indivisible token is a contract that specifies the holder's rights in a fixed value, for example, a contract to redeem a house or 1,000 Australian dollars. Thus, indivisible tokens are not linked to the underlying Bitcoin value.

[0107] To be valid, a token must be digitally signed by a token issuer, which may be, for example, an institution such as a registry of rights. A token issuer can issue a token to a user in return for payment. The token can then grant the user the right to exercise a contract linked to the token, whether the contract represents a right to redeem fiat currency or a right to receive a service.

[0108] Examples of tokens according to the above include: A fiat token pegged to the BTC value of the transaction output by the issuer of the contract. For example, "Any user of this token (Bitcoin transaction) is entitled to redeem a portion of this token for Canadian dollars (CAD) at the rate of 1 share (10 cents) for every 1,000 satoshis." A racehorse owned by multiple members of a group. Any item whose ownership is by deed. For example, a house or other property may be treated this way. An electronic contract representing a concert ticket, which is indivisible in nature. ·Bearer bonds (indivisible) A unique identifier (such as a barcode or RFID) given to the product / service. If used, this identifier is preferably verified by the signature of an authorized entity. Without the signature, it falls into the less secure "product / service" category (see below). A contract for the right to receive a service. Note that this is not the same as the actual service itself, only the right to receive the service. This right is redeemable. For example, a voucher from Michael's Mowing for up to 3 hours of lawn mowing within the Sydney metropolitan area. The holder of this voucher (contract) can exchange the voucher for the actual service.

[0109] The token must specify the value of the share, for example, 1 share = 10 cents CAD, 1 share = 1 rupiah, or 1 share = 1% ownership of an item or property (a racehorse, a house, etc.).

[0110] Transcription File Referring now to FIG. 6, a flow chart illustrating method steps of a method 300 for creating one or more transcription files is shown.

[0111] Method 300 includes step 300.10 of writing the generated accounting records from step 200.40 to one or more posting files. This may include consolidating specified information for general ledger posting purposes. For example, the generated accounting records may be consolidated by date, or each accounting record may represent an individual file.

[0112] The one or more posting files may have any suitable format, such as, but not limited to, JSON, XML, or XBRL. The format may be predefined by the general ledger.

[0113] The method 300 may further include a step 300.20 of hashing one or more transcription files. For example, the cryptographic hashing algorithm may include SHA-256 to generate a 256-bit transcription file hash.

[0114] Method 300 may further include step 300.30 of signing a hash of the transcription file. The hash of the transcription file may be signed, for example, using a private key that is part of an asymmetric cryptographic pair having a private key and an associated public key. In this manner, the signed hash of the transcription file may be verified using the associated public key.

[0115] Following step 300.20 of hashing one or more transcription files, the hashes are stored on the blockchain for permanent, immutable proof (300.40). For example, the hashes of the transcription files may be stored in the form of metadata for the transaction record. As discussed above with reference to P2SH, the transcription files may be stored in the form of an "ephemeral" public key within the script.

[0116] In a specific example, an agent application can be used to record the hash of a posting file and a block number range on the Blockchain as a contract transaction.

[0117] Posting to the general ledger Below, method steps of a method 400 for posting one or more posting files to a first entity's general ledger are described.

[0118] As described above, a general ledger is a collection of accounts that aggregates all transactions that occur within an entity. Method 400 of posting one or more posting files to a general ledger may include securely accessing the one or more posting files and verifying that the one or more posting files are from an authorized source. In this regard, method 400 may include obtaining a public key associated with the private signature key used in step 300.30 to verify the signature.

[0119] If one or more posting files are successfully validated, the one or more posting files are applied to the general ledger.

[0120] Dedicated accounting system In one example, the financial accounting records are generated such that the financial accounting records can be provided to an entity's proprietary accounting system, e.g., the entity's proprietary accounting system can be configured to run proprietary accounting software for the entity.

[0121] It will be appreciated that Bitcoin transactions may only form part of an entity's trading context, in which case the generated financial accounting records utilizing transaction records on the Bitcoin blockchain may be incorporated into existing accounting models.

[0122] Subkey Generation Method In accordance with the present invention, it is necessary to generate sub-keys from the original (master) key. A method for accomplishing this is provided to illustrate one way in which this can be done. The following provides an exemplary use of techniques that may be used in accordance with or adapted for use with the present invention. The following description is provided with reference to Figures 7-13.

[0123] 7 shows a system 1 including a first node 3 communicating with a second node 7 over a communications network 5. The first node 3 has an associated first processing device 23, and the second node 7 has an associated second processing device 27. The first node 3 and the second node 7 may include electronic devices such as computers, phones, tablet computers, mobile communications devices, computer servers, etc. In one example, the first node 3 may be a client (user) device, and the second node 7 may be a server.

[0124] The first node 3 uses the first node master private key (V 1C ) and the first node master public key (P 1C ) The second node 7 is associated with a first asymmetric cryptographic pair having a second node master private key (V 1S ) and the second node master public key (P 1S ) is associated with a second asymmetric cryptographic pair having a public-private key pair. In other words, the first node and the second node each have a respective public-private key pair.

[0125] The first and second asymmetric cryptographic pairs of the first node 3 and second node 7, respectively, may be generated during a registration process, such as registration for a wallet. The public key of each node may be shared publicly, such as via the communications network 5.

[0126] To determine the common secret (CS) at both the first node 3 and the second node 7, the first node 3 and the second node 7 perform the steps of methods 300 and 400, respectively, without communicating the private key over the communications network 5.

[0127] The method 300 performed by the first node 3 includes obtaining at least the first node master private key (V 1C ) and the generator value (GV), the first node 2C) The generator value may be based on a message (M) shared between the first node and the second node, which may include sharing the message over the communication network 5, as described in further detail below. The method 300 also includes determining (330) at least the second node master public key (P 1S ) and the generator value (GV), the second node second public key (P 2S ) to determine (370) the first node second private key (V 2C ) and the second node second public key (P 2S ) and determining (380) a common secret (CS).

[0128] Importantly, the same common secret (CS) can also be determined by the method 400 at the second node 7. The method 400 determines the first node master public key (P 1C ) and the generator value (GV), the first node second public key (P 2C ) The method 400 includes determining (430) the second node master private key (V 1S ) and the generator value (GV), the second node second private key (V 2S ) The method 400 further includes determining (470) a second node second private key (V 2S ) and the first node second public key (P 2C ) and determining (480) a common secret (CS).

[0129] The communication network 5 may include a local area network, a wide area network, a cellular network, a wireless communication network, the Internet, etc. In these networks, data may be transmitted over communication media such as wires, optical fibers, or wirelessly, and these networks may be subject to eavesdropping, for example, by an eavesdropper 11. The methods 300, 400 may enable both the first node 3 and the second node 7 to independently determine the common secret without transmitting the common secret over the communication network 5.

[0130] One advantage therefore is that the common secret (CS) can be determined securely and independently by each node without the need to transmit the private key over a potentially insecure communications network 5. The common secret can then be used as (or as the basis for) the private key.

[0131] The methods 300, 400 may include additional steps, see Figure 8. The method 300 comprises, at the first node 3, transmitting a message (M) and a first node second private key (V 2C ) to the second node 7. The method 300 further includes transmitting (360) the first signed message (SM1) to the second node 7 over the communication network. The second node 7 may then perform step 440 of receiving the first signed message (SM1). The method 400 also includes generating a signed message (SM1) based on the first node second public key (P 2C ), and step 460 of authenticating the first node 3 based on the result of verifying the first signed message (SM1). Advantageously, this allows the second node 7 to authenticate that the purported first node (from which the first signed message was generated) is the first node 3. This is because only the first node 3 has the first node master private key (V 1C ), and therefore only the first node 3 has access to the first node second private key (V 2C ) can be determined. Similarly, it should be appreciated that a second signed message (SM2) may be generated at the second node 7 and sent to the first node 3, for example in a peer-to-peer scenario, so that the first node 3 can authenticate the second node 7.

[0132] Sharing a message (M) between a first node and a second node may be accomplished in various ways. In one example, a message may be generated at the first node 3 and then transmitted to the second node 7 over the communication network 5. Alternatively, a message may be generated at the second node 7 and then transmitted to the second node 7 over the communication network 5. In some examples, the message (M) may be public and therefore transmitted over an insecure network 5. One or more messages (M) may be stored in a data store 13, 17, 19. Those skilled in the art will understand that sharing a message may be accomplished in various ways.

[0133] Advantageously, a record can be kept to enable the recreation of the common secret (CS) without the record itself having to be stored in secret or transmitted securely.

[0134] Registration method 100, 200 9, examples of registration methods 100, 200 are described. Method 100 is performed by a first node 3 and method 200 is performed by a second node 7. This involves establishing a first asymmetric cryptographic pair and a second asymmetric cryptographic pair for the first node 3 and the second node 7, respectively.

[0135] These asymmetric cryptographic pairs include an associated private key and a public key, such as those used in public key cryptography, and in this example, are generated using the properties of elliptic curve cryptography (ECC) and elliptic curve arithmetic.

[0136] In methods 100, 200, this involves a first node agreeing (110) to use a common ECC system and base point (G), and a second node agreeing (210) to use a common ECC system and base point (G). (Note: The base point is sometimes referred to as a common generator, but the term "base point" is used to avoid confusion with the generator value GV.) In one example, the common ECC system may be based on secp256K1, the ECC system used by Bitcoin. The base point (G) may be selected, randomly generated, or assigned.

[0137] Turning now to the first node 3, the method 100 includes agreeing (110) on a common ECC system and base point (G). This may include receiving the common ECC system and base point from the second node 7 or the third node 9. Alternatively, a user interface 15 may be associated with the first node 3, whereby a user may selectively provide the common ECC system and / or base point (G). In yet another alternative, one or both of the common ECC system and base point (G) may be randomly selected by the first node 3. The first node 3 may send a notification to the second node 7 over the communications network 5 indicating that it will use the common ECC system and base point (G). The second node 7 may then agree (210) by sending a notification indicating acknowledgment to use the common ECC system and base point (G).

[0138] The method 100 also includes the first node 3 transmitting the first node master private key (V 1C ) and the first node master public key (P 1C ) based at least in part on random integers within a specified range of tolerances in a common ECC system. 1C), which also includes generating the first node master private key (V 1C ) and the base point (G) based on the elliptic curve point multiplication, the first node master public key (P 1C ) including determining: P 1C = V 1C x G (Equation 1)

[0139] Thus, the first asymmetric cryptographic pair comprises: V 1C : First node master private key, which is kept secret by the first node P 1C : The first node master public key to be made publicly known

[0140] The first node 3 uses the first node master private key (V 1C ) and the first node master public key (P 1C ) may be stored in a first data store 13 associated with the first node 3. For security purposes, the first node master private key (V 1C ) may be stored in a secure part of the first data store 13 to ensure that the key remains secret.

[0141] The method 100 includes transmitting a first node master public key (P 1C ) and the second node 7 transmits (130) the first node master public key (P 1C ) is received (220), the first node master public key (P 1C ) may be stored 230 in a second data store 17 associated with the second node 7.

[0142] Similar to the first node 3, the method 200 of the second node 7 involves the second node master private key (V 1S ) and the second node master public key (P 1S ) and generating (240) a second asymmetric cryptographic pair including a second node master private key (V 1S) is also a random integer within the allowed range. Then, the second node master public key (P 1S ) is determined by the following equation 2: P 1S = V 1S x G (Equation 2)

[0143] Thus, the second asymmetric cryptographic pair comprises: V 1S : Second node master private key, which is kept secret by the second node P 1S : The second node master public key that will be made publicly known

[0144] The second node 7 may store the second asymmetric cryptographic pair in a second data store 17. The method 200 may include providing the first node 3 with a second node master public key (P 1S ) (250). The first node 3 then transmits the second node master public key (P 1S ) is received (140), and the second node master public key (P 1S ) can be stored (150).

[0145] It should be appreciated that in some alternatives, the respective master public key may be received by a third node 9 (such as a trusted third party) and stored in a third data store 19 associated with the third node 9. This may include a third party acting as a public directory, such as a certificate authority. Thus, in some examples, the first node master public key (P 1C ) may only be requested and received by the second node 7 (and vice versa) if it is determined that a common secret (CS) is required.

[0146] The registration step may only need to occur once as an initial setup.

[0147] Session initiation and determination of a shared secret by the first node 3 An example of determining the common secret (CS) is described with reference to Figure 10. The common secret (CS) may be used for a particular session, time, transaction, or other purpose between the first node 3 and the second node 7, and it may be undesirable or insecure to use the same common secret (CS). Thus, the common secret (CS) may be changed between different sessions, times, transactions, etc.

[0148] The following is provided for illustration of the secure transmission techniques described above.

[0149] Message (M) generation 310 In this example, the method 300 performed by the first node 3 includes generating 310 a message (M). The message (M) can be random, pseudo-random, or user-defined. In one example, the message (M) is based on Unix time and a nonce (as well as an arbitrary value). For example, the message (M) can be provided as: Message (M) = UnixTime + nonce (Formula 3) (Message (M) = Unix time + nonce)

[0150] In some examples, the message (M) is arbitrary. However, it should be understood that the message (M) may have optional values ​​(such as an account number, Unix time, etc.) that may be useful in some applications.

[0151] The method 300 includes sending 315 a message (M) to a second node 7 over a communication network 5. The message (M) may be transmitted over an insecure network because the message (M) does not include information about the private key.

[0152] Determining Generator Value (GV) 320 The method 300 further includes step 320 of determining a generator value (GV) based on the message (M). In this example, this includes determining a cryptographic hash of the message. Examples of cryptographic hash algorithms include SHA-256 for generating a 256-bit generator value (GV), i.e., GV = SHA-256(M) (Equation 4) is.

[0153] It should be understood that other hash algorithms may be used. This may include other hash algorithms in the Secure Hash Algorithm (SHA) family. Some examples include instances in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. Other hash algorithms may include hash algorithms in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. An example may include RIPEMD-160. Other hash functions may include families based on Zemor-Tillich hash functions and knapsack-based hash functions.

[0154] Determining the first node's second private key 330 The method 300 then generates the second node master private key (V 1C ) and the generator value (GV), the first node 2C ) according to Equation 5 below. 1C ) and a generator value (GV): V 2C = V 1C + GV (Equation 5)

[0155] Therefore, the first node's second private key (V 2C) is not a random value, but is deterministically derived from the first node master private key. The corresponding public key in the cryptographic pair, i.e., the first node second public key (P 2C ) have the following relationship: P 2C = V 2C x G (Equation 6)

[0156] V from Equation 5 to Equation 6 2C Substituting gives the following equation 7: P 2C = (V 1C + GV) x G (Equation 7) In the above equation, the "+" operator refers to elliptic curve point addition. Keeping in mind that elliptic curve cryptography algebra is distributive, Equation 7 can be expressed as: P 2C = V 1C x G + GV x G (Equation 8)

[0157] Finally, substituting Equation 1 into Equation 8 may give the following equation: P 2C = P 1C + GV x G (Equation 9.1) P 2C = P 1C + SHA-256(M) x G (Equation 9.2)

[0158] Therefore, the corresponding first node second public key (P 2C ) is the first node master public key (P 1C ) and knowledge of the message (M). The second node 7 can derive the first node second public key (P 2C ) independently.

[0159] Generate 350 a first signed message (SM1) based on the message and the first node's second private key. The method 300 includes receiving a message (M) and a determined first node second private key (V 2C) to generate (350) a first signed message (SM1) based on the first node's second private key (V). Generating the signed message includes applying a digital signature algorithm to digitally sign the message (M). In one example, this is done in an Elliptic Curve Digital Signature Algorithm (ECDSA) using the first node's second private key (V 2C ) to the message to obtain a first signed message (SM1). Examples of ECDSA include those based on the secp256k1, secp256r1, secp384r1, and se3cp521r1 ECC systems.

[0160] The first signed message (SM1) is sent to the second node 7 using the corresponding first node second public key (P 2C ) This verification of the first signed message (SM1) can be used by the second node 7 to authenticate the first node 3, which is described in method 400 below.

[0161] Determining second node second public key 370' The first node 3 then sends the second node second public key (P 2S ) can be determined (370). As mentioned above, the second node second public key (P 2S ) must contain at least the second node master public key (P 1S ) and a generator value (GV). In this example, the public key is determined 370′ as an elliptic curve point multiplication of the private key and the base point (G), so that the second node's second public key (P 2S ) can be expressed similarly to Equation 6 as: P 2S = V 2S x G (Equation 10.1) P 2S = P 1S + GV x G (Equation 10.2)

[0162] The mathematical proof for Equation 10.2 is that the first node's second public key (P 2C) is the same as described above to derive equation 9.1 for . It should be understood that the first node 3 can determine 370 the second node second public key independently of the second node 7.

[0163] Determining the shared secret 380 at the first node 3 Then, the first node 3 uses the determined first node second private key (V 2C ) and the determined second node second public key (P 2S ) a common secret (CS) may be determined (380) based on the common secret (CS). The common secret (CS) may be determined by the first node 3 using the following equation 11: S = V 2C x P 2S (Formula 11)

[0164] Method 400 performed at second node 7 A corresponding method 400 performed in the second node 7 will now be described. It will be understood that some of these steps are similar to the steps performed by the first node 3 described above.

[0165] The method 400 includes receiving 410 a message (M) from the first node 3 over the communications network 5. This may include the message (M) sent by the first node 3 in step 315. The second node 7 then determines 420 a generator value (GV) based on the message (M). The step 420 of determining the generator value (GV) by the second node 7 is similar to the step 320 performed by the first node 3, described above. In this example, the second node 7 performs this determining step 420 independently of the first node 3.

[0166] The next step is to create the first node master public key (P 1C ) and the generator value (GV), the first node second public key (P 2CIn this example, the public key is determined 430′ as an elliptic curve point multiplication of the private key and the base point (G), so that the first node second public key (P 2C ) can be expressed similarly to Equation 9 as: P 2C = V 2C x G (Equation 12.1) P 2C = P 1C + GV x G (Equation 12.2)

[0167] The mathematical proofs for Equations 12.1 and 12.2 are the same as those given above for Equations 10.1 and 10.2.

[0168] Authentication of First Node 3 by Second Node 7 The method 400 may include steps performed by the second node 7 to authenticate the purported first node 3 as the first node 3. As previously mentioned, this includes receiving 440 the first signed message (SM1) from the first node 3. The second node 7 then receives 440 the first node second public key (P 2C ) can be used to verify (450) the signature on the first signed message (SM1).

[0169] The verification of the digital signature may be performed according to the Elliptic Curve Digital Signature Algorithm (ECDSA), as described above. Importantly, the first node's second private key (V 2C ) is signed by the first node's second public key (P 2C ) should be correctly verified using only V 2C and P 2C These keys are the first node master private key (V) generated during the registration of the first node 3. 1C ) and the first node master public key (V 1C), verifying the first signed message (SM1) can be used as a basis to authenticate that the purported first node that sent the first signed message (SM1) is the same as the registering first node 3. Therefore, the second node 7 can further perform step 460 of authenticating the first node 3 based on the result of verifying (450) the first signed message. See Figure 11.

[0170] Second node 7 determines the shared secret The method 400 includes a step in which the second node 7 acquires the second node master private key (V 1S ) and the generator value (GV), the second node second private key (V 2S ) similar to step 330 performed by the first node 3. 2S ) is the second node master private key (V 1S ) and a generator value (GV): V 2S = V 1S + GV (Equation 13.1) V 2S = V 1S + SHA-256(M) (Equation 13.2)

[0171] Then, the second node 7, independently of the first node 3, calculates the second node second private key (V 2S ) and the first node second public key (P 2C ) can determine (480) a common secret (CS) based on: S = V 2S x P 2C (Formula 14)

[0172] Proof of the common secret (CS) determined by the first node 3 and the second node 7 The common secret (CS) determined by the first node 3 is the same as the common secret (CS) determined at the second node 7. A mathematical proof that Equation 11 and Equation 14 provide the same common secret (CS) is described.

[0173] Turning to the common secret (CS) determined by the first node 3, Equation 10.1 can be substituted into Equation 11 as follows: S = V 2C x P 2S (Formula 11) S = V 2C x (V 2S x G) S = (V 2C x V 2S ) x G (Equation 15)

[0174] Turning to the common secret (CS) determined by the second node 7, Equation 12.1 can be substituted into Equation 14 as follows: S = V 2S x P 2C (Formula 14) S = V 2S x (V 2C x G) S = (V 2S x V 2C ) x G (Equation 16)

[0175] Since ECC algebra is commutative, Equation 15 and Equation 16 are equivalent because S = (V 2C x V 2S ) x G = (V 2S x V 2C ) x G (Equation 17) Because that is the case.

[0176] Common Secret (CS) and Private Key Here, the common secret (CS) may be used as a private key or as the basis for a private key in a symmetric key algorithm for secure communication between the first node 3 and the second node 7 .

[0177] The common secret (CS) is the elliptic curve point (x S , y S ) which can be converted to a standard key format using standard known operations agreed upon by nodes 3 and 7. For example, x S The value is AES 256 It can be a 256-bit integer that can be used as a key for encryption. It can also be converted to a 160-bit integer using RIPEMD160 for applications requiring a key of the following length:

[0178] The common secret (CS) can be determined as needed. Importantly, the first node 3 does not need to store the common secret (CS) as it can be re-determined based on the message (M). In some examples, one or more messages (M) used may be stored in the data store 13, 17, 19 (or other data store) without the same level of security required for a master private key. In some examples, the message (M) may be public.

[0179] However, depending on the application, the shared secret (CS) may be used in conjunction with the first node master private key (V 1C ), the common secret (CS) may be stored in a first data store (X) associated with the first node.

[0180] Advantageously, this technique can be used to determine multiple shared secrets, which may correspond to multiple secure private keys, based on a single master key cryptographic pair.

[0181] Generator Value (Key) Hierarchy For example, a series of successive generator values ​​(GV) may be determined, where each successive GV may be determined based on the previous generator value (GV). For example, instead of repeating steps 310-370 and steps 410-470 to generate multiple successive single-purpose keys, by prior agreement between these nodes, a previously used generator value (GV) may be repeatedly rehashed by both parties to establish a hierarchy of generator values. In fact, a generator value based on a hash of a message (M) may be the next-generation message (M') for the next-generation generator value (GV'). Doing this allows successive generations of the shared secret to be calculated without the need for additional protocol establishment transmissions, particularly the transmission of multiple messages for each generation of the shared secret. The next-generation common secret (CS') may be calculated as follows:

[0182] First, both the first node 3 and the second node 7 independently determine the next generation generator value (GV'), which is similar to steps 320 and 420, but modified using the following formula: M' = SHA-256(M) (Equation 18) GV' = SHA-256(M') (Equation 19.1) GV' = SHA-256(SHA-256(M)) (Equation 19.2)

[0183] The first node 3 then generates the next generation second node second public key (P 2S ') and the first node's second private key (V 2C ') can be determined: P 2S ' = P 1S + GV' x G (Equation 20.1) V 2C ' = V 1C + GV' (Equation 20.2)

[0184] The second node 7 then generates the next generation first node second public key (P 2C ') and the second node second private key (V 2S ') can be determined: P 2C ' = P 1C + GV' x G (Equation 21.1) V 2S ' = V 1S + GV' (Equation 21.2)

[0185] The first node 3 and the second node 7 can then each determine a next generation common secret (CS'). In particular, the first node 3 determines the next generation common secret (CS') using the following equation 22: CS' = V 2C ' x P 2S ' (Formula 22)

[0186] The second node 7 determines the next generation common secret (CS′) using the following Equation 23: CS' = V 2S ' x P 2C ' (Formula 23)

[0187] Further generations (CS'', CS''', etc.) can be calculated in a similar manner to create a hierarchy of chains. This technique requires both the first node 3 and the second node 7 to keep track of the original message (M) or initially calculated generator value (GV) and which node it is associated with. As this is publicly known information, there are no security issues with keeping this information. Therefore, this information can be kept in a "hash table" (linking hash values ​​to public keys) and freely distributed over the network 5 (e.g., using Torrent). Furthermore, even if an individual shared secret (CS) in the hierarchy is compromised, the private key V 1C , V 1Sremains secure, this does not affect the security of any other shared secrets in the hierarchy.

[0188] Key tree structure Similar to the chain (linear) hierarchy described above, a hierarchy in the form of a tree structure can be created. Using the tree structure, various keys for different purposes, such as authentication keys, encryption keys, signing keys, payment keys, etc., can be determined, whereby these keys are all linked to a single, securely maintained master key. This is best illustrated in Figure 12, which shows a tree structure 901 containing various different keys, each of which can be used to create a shared secret with another party. Tree branching can be achieved in several ways, three of which are described below.

[0189] (i) Master Key Spawning In the chain hierarchy, each new "link" (public / private key pair) is created by adding multiple rehashed messages to the original master key, for example (for clarity, only the private key of the first node 3 is shown): V 2C = V 1C + SHA-256(M) (Equation 24) V 2C ' = V 1C + SHA-256(SHA-256(M)) (Equation 25) V 2C '' = V 1C + SHA-256(SHA-256(SHA-256(M))) (Equation 26) ...etc.

[0190] Any key can be used as a sub-master key to create a branch. For example, V 2C ' is done for V as is done for a normal master key. 2C By adding a hash to the sub-master key (V 3C ) can be used as: V3C = V 2C ' + SHA-256(M) (Equation 27)

[0191] Submaster Key (V 3C ) itself is, for example, the next generation key (V 3C ') can have: V 3C ' = V 2C ' + SHA-256(SHA-256(M)) (Equation 28)

[0192] This provides a tree structure 903 using a master key spawning method, as shown in FIG.

[0193] (ii) Logical association In this method, all nodes (public / private key pairs) in the tree are generated as a chain (or in any other form) and the logical relationship between the nodes in the tree is maintained by a table where each node in the tree is simply related to its parent node using a pointer. The pointer can then be used to determine the relevant public / private key pair for determining the key for the session (CS).

[0194] (iii) Message multiplicity A new private / public key pair can be generated by introducing a new message at any point in the chain or tree. The message itself may be arbitrary or may convey some meaning or function (e.g., it may be related to a "real" bank account number, etc.). It may be desirable for such a new message to form the new private / public key pair to be kept secure.

Claims

1. 1. A computer-implemented method for securely extracting data from a blockchain, comprising: associating one or more elements of the structure with a cryptographic subkey derived from another cryptographic key; The structure is formed by elements in hierarchical entities, and The hierarchical entity has a plurality of elements organized in a hierarchical relationship. Steps and extracting data from the blockchain transaction, the data including the cryptographic sub-key associated with the one or more elements; transmitting the extracted data to a non-blockchain based computer system associated with the hierarchical entity; A method comprising:

2. The method further comprises: scanning, traversing, and / or analyzing the blockchain to identify one or more blockchain transactions that include the cryptographic sub-key associated with the one or more elements; The method of claim 1 , comprising:

3. The method further comprises: processing the extracted data to generate an output; 3. The method of claim 1 or 2, comprising:

4. The method further comprises: communicating the output to a non-blockchain based computer system associated with the hierarchical entity; The method of claim 3, comprising:

5. 1. A computer device comprising: a processor; a memory storing instructions executable by said processor; Including, The processor is configured to execute the instructions stored in the memory to perform the method of any one of claims 1 to 4. Computer equipment.

6. A computer-readable storage medium having instructions stored thereon, The instructions, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 4. A computer-readable storage medium.

Images