SYSTEM AND METHOD FOR HIERARCHICAL TOKEN DISTRIBUTION IN A BLOCKCHAIN ​​NETWORK

Abstract

To provide a method and a device which provide security by encryption in a token mixing system and makes a plurality of input nodes cooperatively distribute tokens to a plurality of output nodes.SOLUTION: The method, which is executed in a mixer node (Uij), includes: a step of identifying an upstream node (Ui) and a plurality of downstream nodes (Uijk) associated with the mixer node; and a step of generating a first commitment channel (Ui→Uij) for a first transaction between the upstream node and the mixer node in cooperation with the upstream node and generating a second commitment channel (Uij→Uijk) for a second transaction between the mixer node and the downstream nodes, for each of the plurality of downstream nodes, in cooperation with the downstream nodes, where an unlock script of the first transaction is derived from any one unlock script of the second transaction.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates generally to transfers and transactions conducted over a blockchain, and more particularly to a method and apparatus for providing cryptographic security in a token mixing system to enable multiple input nodes to collaboratively distribute tokens to multiple output nodes. [Background technology]

[0002] As used herein, the term "blockchain" is used to include all forms of electronic, computer-based, distributed ledgers. These include, but are not limited to, blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin is referred to herein 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.

[0003] A blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed, computer-based system composed of blocks. Blocks, in turn, are composed of transactions. Each transaction is a data structure that encodes the transfer of control 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 chain together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs. Scripts specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform work to ensure each transaction is valid; invalid transactions are rejected by the network. A software client installed on a node performs this validation work on unspent transactions (UTXOs) by running its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, the transaction is valid and the transaction 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 the transaction; if the transaction is verified, the 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.

[0005] Another area of ​​interest related to blockchains is the use of "tokens" (or "colored coins") for the representation and transfer of real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Tokens thus function as identifiers that allow real-world items to be referenced from the blockchain. Tokens may, for example, represent future control of network resources and / or digital assets. In some cases, tokens may represent assets or values. This application is not limited to implementation in cryptocurrency environments, but may be understood more broadly as relating to blockchain networks for the decentralized transfer of tokens.

[0006] One of the recognized advantages of blockchain technology, such as Bitcoin, is the anonymity of transactions. Bitcoin users' personal details are not formally and explicitly attached to their Bitcoin addresses; only the blockchain's Bitcoin ledger contains public address information. However, using secondary data (e.g., shipping addresses required to complete transactions) and analysis, interested third parties may be able to combine publicly available information to link transaction details on the Bitcoin ledger to real-world identities. In certain systems, such as voting systems, medical applications, etc., traceability of users within or from the network is undesirable for a number of reasons, such as security and / or reliability.

[0007] One way that users can be identified through blockchain data is the amount of blockchain tokens controlled by a particular Bitcoin address. By tracking the flow of tokens in transactions broadcast through the Bitcoin network, it may be possible to attribute a specific amount of tokens to an address. This token amount can also be used (e.g., by an external third party) to infer the identity of a user associated with the address. For example, if the total amount of tokens transferred from an address is determined to be significantly large, the set of possible identities of users associated with that address can be narrowed to include only those known to hold or be capable of holding such a large amount of tokens.

[0008] The difficulty in protecting a user's identity is particularly pronounced when the tokens in an address are kept "intact" (i.e., maintained as unit amounts) rather than when they are divided into multiple sub-amounts / quantities before the actual transfer of tokens occurs from the address. Even when various anonymity techniques are used to attempt to disguise the transfer of tokens from an address, transactions originating from the address will be much easier to trace if the tokens to be transferred by the transaction are kept intact. Dividing the amount of tokens in an address, however, is not a straightforward task and presents technical challenges. In particular, dividing the initial amount of tokens in an address into small sub-amounts presents technical challenges because it separates users from the initial amount while maintaining ownership, i.e., control, of the tokens.

[0009] Therefore, it is desirable to provide a method and apparatus for dividing and distributing token amounts at blockchain addresses to achieve increased untraceability and non-linkability from input to output in blockchain transactions.

[0010] However, there are numerous technical challenges when attempting to securely mix and distribute tokens within a blockchain network. For example, security can be compromised if a participating node (or another node associated with that participating node) can claim tokens before executing a protocol that causes the other nodes to publish those tokens. Furthermore, it is important to prevent intentional or accidental misallocation of tokens, for example, by offline participants.

[0011] Such a solution is devised here.

[0012] Therefore, according to the present invention there is provided methods and apparatus as defined in the appended claims. Summary of the Invention

[0013] The present invention may provide a computer-implemented method and corresponding system. The method / system may be described as a blockchain-implemented method / system. The present invention may be described as a security method or encryption method / system. The present invention may provide secure transfer of digital resources / assets (e.g., tokens), such as cryptocurrency fractions or amounts. Additionally or alternatively, the present invention may provide control mechanisms for controlling transfer of digital resources / assets, such as cryptocurrency fractions or amounts. For ease of reference, assets or resources may be referred to herein as "tokens."

[0014] "Commitment channels" may be configured in an ordered manner, with multiple nodes arranged hierarchically. A root node may control the execution of token transfers or exchanges (e.g., distribution of tokens to specific nodes) within the hierarchy. The methods and systems described herein may improve the security of token distribution by ensuring that any tokens associated with a distribution cannot be unlocked / accessed by any participant node until and unless the control node determines that the commitment channel has been properly created and then initiates the token transfer process. The control node may initiate the sequential disclosure of a secret value that, when coupled with the hierarchically arranged commitment channels, may ensure that participant nodes receive their prescribed distribution of tokens. For example, the sequential disclosure of the secret value along each path in the hierarchy may allow participant nodes to receive the tokens from each node along the token transfer path. The sequential disclosure of the secret may allow participant nodes to receive their respective tokens only when all token transactions have been signed by the participant nodes and the commitment channel has been properly created and completed as determined by the control node.

[0015] Additionally or alternatively, this application may describe a computer-implemented method for participating in a resource (or "asset" or "token") distribution process that divides a resource / asset / token quantity at an input address associated with an input node into multiple sub-quantities and distributes the sub-quantities to multiple output addresses associated with respective output nodes using a blockchain. Hereinafter, we will use the term "token" instead of "resource" or "asset" for convenience.

[0016] The token distribution process may be performed jointly by an input node, an output node, and a plurality of mixer nodes. The method may be performed in a mixer node. The method includes: Upstream nodes (U i ) and multiple downstream nodes (U ijk ), and in cooperation with the upstream node, generating a first commitment channel for a first (blockchain) transaction between the upstream node and the mixer node; and for each of the plurality of downstream nodes, in cooperation with the downstream node, generating a second commitment channel for a second transaction between the mixer node and the downstream node, such that the unlock script of the first (blockchain) transaction is derived from the unlock script of any one of the second (blockchain) transactions.

[0017] The term "transferor node" may be used herein synonymously with the term "upstream node." A transferor node may be a node that transfers resources to another node. The term "downstream node" may be used herein synonymously with the term "transferee node." A transferee node may be a node that receives resources from another node, e.g., a transferor node.

[0018] In some implementations, generating the second commitment channel may include, in cooperation with the downstream node, generating a first blockchain transaction to commit a quantity of tokens to be transferred to the downstream node, generating a second blockchain transaction to return the committed quantity of tokens to the mixer node, and generating a third blockchain transaction to execute the transfer of the committed quantity of tokens to the downstream node.

[0019] In some implementations, the token quantities may be determined based on a value assignment scheme of the mixer node that identifies respective quantities to forward to each of the plurality of downstream nodes.

[0020] In some implementations, the third blockchain transaction may include an unlock script that includes a second secret value associated with the second commitment channel.

[0021] In some implementations, the method may further include obtaining the second secret value associated with the second commitment channel.

[0022] In some implementations, the method may further include deriving the first secret value associated with the first commitment channel using the second secret value.

[0023] In some implementations, the first secret value is based on a secret key value associated with the input node, the secret key value being unknown to all mixer nodes.

[0024] In some implementations, the method may further include transmitting a mixer key value to the upstream node and to the input node.

[0025] In some implementations, the mixer node may include a first address at which the mixer node detects a transfer of a first token quantity from the upstream node, and a plurality of second addresses to which the mixer node transfers subquantities of the first quantity to the downstream node.

[0026] In some implementations, the total token quantity at the plurality of second addresses may be at least equal to the first quantity.

[0027] In some implementations, the second blockchain transaction may include transaction parameters that specify when the second blockchain transaction becomes eligible for submission to the blockchain.

[0028] In some implementations, the first blockchain transaction may be submitted to the blockchain after the second blockchain transaction has been signed by the downstream node.

[0029] In some implementations, the first commitment channel may be generated after any second commitment channel is generated.

[0030] The present application further describes a computing device for performing the described methods, which may include at least one processor, a memory, a network interface that provides network connectivity, and a blockchain application that includes processor-executable instructions that, when executed, cause the processor to perform one or more of the operations of the methods described herein.

[0031] The present application further describes a non-transitory processor-readable medium that may store processor-executable instructions for participating in a token distribution process, the token distribution process including an input node, a plurality of output nodes, and a plurality of mixer nodes, the processor-executable instructions, when executed by a processor of one of the nodes, causing the processor to perform one or more of the operations of the methods described herein. The processor may be located within the mixer node.

[0032] Any feature described in relation to one aspect or embodiment of the invention may be used in relation to one or more other aspects / embodiments. These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0033] [Figure 1] 1 illustrates an exemplary blockchain network of nodes. [Figure 2]1 illustrates, in flow chart form, an exemplary process for configuring a commitment channel. [Figure 3] 1 illustrates an exemplary hierarchy of nodes utilized in a hierarchical token distribution protocol. [Figure 4] 1 illustrates, in flowchart form, an exemplary process for initiating an instance of a hierarchical token distribution protocol. [Figure 5A] 1 shows a schematic diagram of a commitment channel used in a hierarchical token distribution protocol. [Figure 5B] 1 illustrates, in flowchart form, an exemplary process for configuring a commitment channel between a node and a downstream node in a hierarchical token distribution protocol. [Figure 6] 1 illustrates, in flowchart form, an exemplary process for submitting a token transfer along a path in a hierarchical structure in a hierarchical token distribution protocol. [Figure 7] FIG. 10 shows a schematic diagram illustrating the use by a mixer node of different blockchain addresses to receive and transfer tokens, respectively, in a hierarchical token distribution protocol. [Figure 8] 1 shows a simplified block diagram of a participating node. DETAILED DESCRIPTION OF THE INVENTION

[0034] Reference is first made to Figure 1, which illustrates, in block diagram form, an exemplary blockchain network 100 associated with a blockchain. A blockchain network is a peer-to-peer, open, membership-based network that anyone can join without invitation or approval from other members. The blockchain network 100 operates under a blockchain protocol, and distributed electronic devices running instances of the blockchain protocol may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrency.

[0035] The electronic devices that execute the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smart watches, or other electronic devices.

[0036] The nodes 102 of the blockchain network 100 are coupled to one another using suitable communication technologies, which may include wired and wireless communication technologies. Often, the blockchain network 100 is implemented at least in part over the internet, and some of the individual nodes 102 may be located in geographically dispersed locations.

[0037] Nodes 102 maintain a global ledger of all transactions on the blockchain. The global ledger is a distributed ledger, and each node 102 may store a full or partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. The details of the implementation and operation of blockchain networks, such as those using the Bitcoin protocol, are understood by those skilled in the art.

[0038] Each transaction typically has one or more inputs and one or more outputs. Script embedded in the inputs and outputs specifies how and by whom the transaction's outputs are accessible. A transaction's output may be an address to which tokens are transferred as a result of the transaction. The tokens are then associated with the output address as an available transaction output. In a cryptocurrency context like Bitcoin, an available transaction output may be called an unspent transaction output (UTXO). Subsequent transactions may then reference that address as an input to transfer the tokens to one or more other addresses.

[0039] Transactions are pseudo-anonymous in that personal information is not included in transactions on the blockchain ledger, but it is possible to track the transfer of tokens within the chain of transactions and, in some cases, link tokens to individuals using external data. To improve anonymity, mixing transactions can be used to pool inputs from various sources and assign the pooled tokens to outputs. If all inputs and outputs are the same size, it is difficult to associate a specific input with a specific output. However, in such a transaction, at least one participating node is aware of the connection between the input address and the output address specified by another participating node. In such mixing transactions, such as the CoinJoin operation in the Bitcoin protocol, a single transaction with multiple inputs and multiple outputs is used to mix tokens.

[0040] Several other anonymization techniques are used to try to avoid disclosing the link between inputs and outputs, such as ring signatures or stealth addresses, which have varying degrees of effectiveness. Stealth addresses attempt to isolate the output address to which tokens should be sent from a specific user. Ring signatures attempt to create source untraceability by creating an equal likelihood that one of a group of possible signers is the one who signed / approved a particular transaction. Unfortunately, ring signatures have proven problematic to implement in some blockchain protocols.

[0041] The present disclosure provides techniques for distributing tokens at a blockchain address to multiple different addresses. More specifically, techniques are described for dividing an initial token quantity at an address into smaller subquantities and distributing the subquantities among a set of output addresses. The division of tokens is accomplished in terms of separating control / ownership of the initial token quantity from control / ownership of the subquantities at those final addresses. In particular, the initial token subquantities are distributed in a manner that makes it difficult for an external observer to associate the final output addresses with the addresses that stored the initial token quantity.

[0042] According to an embodiment of the present invention, initial tokens at an address on a blockchain are distributed through a hierarchical structure of token transfers among a set of participating nodes. In particular, the initial token amount and its subamounts are sequentially divided through multiple layers of a "hierarchical structure." The term "hierarchical structure," as used in this disclosure, refers to a structure for conceptualizing a set of transfers generated to distribute subamounts of the initial token amount at an address. In the context of this application, a "hierarchical structure" may be understood as a tree structure including a root node and child subtrees with parent nodes, represented as a set of linked nodes. The hierarchical token distribution scheme proposed in this disclosure uses token transfers among participating nodes (represented as nodes in the tree structure) to distribute tokens from a "root" node corresponding to the initiator of the distribution to multiple "leaf" nodes, which are also output addresses controlled by the initiator.

[0043] The technology described herein also provides a security mechanism implemented through the use of "commitment channels" to transfer tokens between participating nodes to ensure that participating nodes in a distribution are not at risk of having their tokens stolen. The initiator of the protocol controls the subsequent "unlocking" of a commitment channel using propagated disclosure of a secret value associated with the commitment channel, preventing a token transaction in the protocol from being executed until all commitment channels for that transaction have been established. Upon successful completion of all token transactions using the created commitment channels, the address's initial token amount is distributed to multiple destination (output) addresses.

[0044] In the description herein, the terms "input node," "output node," "participant node," "input address," and "output address" may be used. Reference to the "address" of a node does not imply a reference to the network address of a physical node. Rather, the "address" is an address specified in a transaction on the blockchain that has an allocation of tokens over which the physical node can claim ownership by having a key corresponding to a signature in the transaction. In this sense, an "output address" is not the address of a participating node, but rather a blockchain transaction output address owned by or associated with a participating output node. Similarly, an "input address" is the address of a usable transaction output (UXTO in cryptocurrency terms) owned by or associated with a participating input node.

[0045] <Commitment Channel> Various blockchain technologies, such as Bitcoin, sometimes use "commitment channels" in structuring pairwise transactions between participating nodes. Commitment channels are designed to allow nodes to generate multiple transactions without committing all of them to the blockchain. Once a commitment channel is established between a pair of participating nodes, the nodes can engage in as many transfers as they wish within a given time period, with only two of the transactions ultimately being added to the blockchain. As a result, the use of commitment channels can reduce the number of transactions that need to be added to the blockchain and the associated transaction costs. Commitment channels also provide the transferor node with the flexibility to have tokens returned if certain criteria are not met by the transferor node, or if either the transferor or transferee node decides to terminate processing after a certain set of transfers.

[0046] Figure 2 shows the transfer node U A Transferred from node U BOne-way commitment channel to U A →U B 2 illustrates, in flowchart form, an exemplary process 200 for generating a participating node U. A and U B For example, a one-way commitment channel may be suitable for use in a scenario where party A wishes to pay party B (e.g., for a service) in multiple transfers over a period of time. More generally, a commitment channel U A →U B is the participating node U A and U B A set of possible exchanges of tokens between the

[0047] In step 202, the transferor U A is a commitment transaction T c A commitment transaction is a transaction that guarantees that a specified token set x is used by U B Represents the commitment component of a commitment channel that is sent / committed for transfer to. In some implementations, the commitment transaction may be a 2-of-2 multi-signature pay-to-script-hash (P2SH) transaction, where the transaction is not submitted to the blockchain network.

[0048] In step 204, all tokens from the multi-signature controlled token are A A separate return transaction T r,0 U A This transaction contains a parameter nLockTime that makes the blockchain transaction executable only after a specified time. The return transaction is generated by the transferee node U. B If node U is unable to complete the stated criteria for the commitment transaction within the allotted time (i.e., by nLockTime), the node U will transfer the committed tokens to node U. A to return it.

[0049] In step 206, the transferor U A In step 208, U signs the return transaction. B If it is determined that U has signed the return transaction, then in step 210, A is the original commitment transaction T C Then, node U signs the token and submits it to the blockchain. A and U B creates one or more new return transactions (T) to reflect the token transfers that are being generated outside the blockchain as shown in steps 212-226. r,1 ,T r,2 ,...,T r,i ,...). In particular, these return transactions are A At that point, U B A participating node may request a return transaction T r,i If the node refuses to sign the previous transaction T, it will sign the previous transaction T after nLockTime. r,i-1 For example, in the worst case scenario, U A is T r,0 By signing and submitting it to the blockchain network, c Among U A All committed tokens can be redeemed by

[0050] As shown in Figure 2, U A and U B The repeated (off-block) return transactions between U A From U B More specifically, initial return transaction T r,0 The nLockTime value of stop where n is U A and U BThe nodes can continue to negotiate new transfers (step 216) if t≦S is the number of return transactions generated in the ongoing off-block transfers generated between them and s, and s is the time both parties have to agree on a return transaction before the node endangers other nodes submitting previous return transactions. stop During -i*s (i.e., while nLockTime of the initial return transaction has not yet elapsed), the value of nLockTime is decremented for each subsequent return transaction until the final return transaction is submitted to the blockchain.

[0051] <Hierarchical token distribution> This disclosure describes techniques for distributing tokens at a particular address in a blockchain to multiple output addresses. The amount of tokens at an initial address is divided into multiple sub-amounts. The multiple sub-amounts are then distributed among a set of output addresses. The token distribution scheme proposed in this disclosure (Hierarchical Token Distribution scheme, or HTD) utilizes a "hierarchical" structure of transfers between participating nodes (represented as nodes in a conceptual "hierarchy"). In particular, HTD transfers tokens from an initial address through a multi-level hierarchy of nodes. In some cases, HTD may be used as part of or in addition to a solution for anonymizing transactions within a blockchain network. An example of an HTD is described below with reference to Figures 3-8.

[0052] Token distribution initialization Referring to FIG. 4, FIG. 4 illustrates an exemplary process 400 for initiating an instance of the HTD protocol. A node can join an HTD instance to divide and distribute tokens at addresses associated with the node. As described above, HTD proceeds by conceptually arranging multiple nodes into a multi-level hierarchical structure. The initiator of the HTD is represented as the root node U0, and the output addresses of the token distribution are represented as leaf nodes in the hierarchical structure. The HTD instance may be managed by the initiator itself or by a different node and / or control system. In the latter case, the initiator may request to use HTD services provided by the node / control system.

[0053] At step 402, initialization data including various parameters of the HTD service may be collected or selected by an administrator and / or initiator, including: A fixed number of branches per node in the hierarchy (n b ) indicates the number of children / successors each non-leaf node has in the hierarchy.

[0054] Number of outputs or "leaves". In at least some embodiments, the number of outputs may be selected from a set of values ​​within the range of the following function: Leaves=f(n b ,n l )=n b nl-1 .

[0055] where n l >2 is the number of levels in the hierarchy, with the root node at level 1 and the final level being the level containing the leaves. For example, n b = 2, the range of leaves is Leaves={2 2 ,2 3 ,2 4 ,...,2 nl-1}={4,8,16,...}.

[0056] In step 404, the HTD recruits a set of participating nodes to act as "mixer nodes" in the hierarchy. Recruitment may be performed by an administrator and / or initiator of the HTD, or recruitment may be distributed (e.g., participating nodes may be "opted in" by the HTD to function as mixer nodes and receive payment, for example, for providing their "mixing" services). Mixer nodes are non-root, internal nodes in the tree structure of the hierarchy. Each mixer node is configured to receive a first token quantity from its "parent" (or upstream) node and forward subquantities of the first quantity to its "child" (or downstream) nodes. The parameter n b and n l Given the number of mixer nodes in the hierarchy of the HTD instance, n mix may be calculated by the following formula:

[0057]

number

[0058] A key element of the HTD protocol is the implementation of security mechanisms that ensure the protocol is fully implemented without the risk of partial completion and the resulting failure to achieve the final distribution of the desired tokens. To achieve the necessary security for HTD, the solution exploits the homomorphic property of the public-private key relationship in elliptic curve cryptography, where E(m) + E(n) = E(m + n).

[0059] E(x) = xG, where G is the base point of the elliptic curve. The security of the protocol is ensured by the use of a "commitment channel" for all token transactions between parent-child node pairs in the HTD hierarchy, and by the initiator U through the commitment channel established between the participating nodes of the protocol. rt It depends on the control being performed by

[0060] In setting up this security mechanism, the initiator first generates a random value (or key) k s Select and press k s Calculate G, where G represents the base point on the elliptic curve. s The value of is kept secret by the initiator through the HTD. In step 408, all other participating nodes U i is the random value / key k i In step 410, the initiator then selects a set of random values ​​{k rt,i}, where each of these random numbers corresponds to a leaf (output) node in the hierarchy. That is, the initiator selects a random value k leaf to each leaf node.

[0061] Once a sufficient number of mixing nodes have been recruited by the HTD service, a hierarchy of nodes is "built" based on the number of output values ​​or leaves selected by the initiator. An exemplary hierarchy 300 of nodes is shown in FIG. 3, where n b = 2, and the number of leaves n l is equal to 4. The hierarchy includes a root node 302, eight leaf nodes 304, and a number of mixer nodes 306 located at unique positions along eight different paths between the root node 302 and the leaf nodes 304. An initial amount of tokens at the address associated with the root node 302 can be distributed to the output leaf nodes 304 using a distribution scheme based on the hierarchy 300. (Without loss of generality, the following notation is used to label nodes throughout this disclosure: if a node is U ij If labeled as Uij The parent node of is U i and U ij The child node of is U ijk where k∈[1,n b ].

[0062] An HTD "hierarchy" is a representation of the set of token transactions between participating nodes that result in the distribution of an initial amount of tokens at a particular blockchain address to multiple different output addresses. In particular, the relative position of a node within the hierarchy defines the transactions used by the HTD protocol in distributing the initial address's tokens. Each node in the hierarchy other than the root node receives a transfer of tokens from its parent node, and all non-leaf nodes in the hierarchy transfer their respective amount of tokens to each of their child nodes. More specifically, each mixer node in the hierarchy participates in two types of transactions: (1) it receives a transfer of a specific amount x of tokens from its parent node, and (2) it transfers respective subamounts of x to its child nodes. Thus, a node's position within the hierarchy completely defines the set of transactions with which the corresponding participating node is involved.

[0063] To aid in the anonymization capabilities of the HTD, various randomization processes may be performed during the construction of the hierarchy to determine the location of individual mixing nodes. Randomization may be performed on a level-by-level basis (i.e., participating nodes are assigned to a level in the hierarchy, but their location within that level is determined randomly), or nodes may be placed in any random mixing node location within the hierarchy.

[0064] Due to the hierarchical arrangement of mixer nodes in the HTD, the randomization selection is based on the number of tokens already available in the mixer node, min xFor a mixer node to be able to mix token transfers during HTD, the mixer node should process at least a minimum amount of tokens before accepting tokens for distribution. For example, a limit may be imposed during the recruitment of mixer nodes, such that at least one of the mixer nodes must b A mixer node is required to have a number of tokens already available at a separate address equal to the number it is asked to distribute to its child nodes. This means that the higher a mixer node is in the hierarchy, the more tokens it must handle in order to participate in the HTD, depending on the ratio in which the tokens should be divided among its child nodes (because nodes higher in the hierarchy receive a larger number of tokens for distribution). Thus, when a mixer node is recruited for a particular level in the hierarchy, randomization is limited to moving nodes "horizontally" across that level in the hierarchy, and a level has its own minimum limit. x On the other hand, if mixer nodes are recruited without any level restrictions, the mixer nodes can be randomly positioned at any position in any level of the hierarchical structure, and the min x The value can be common.

[0065] Having determined the position of the mixer node within the hierarchical structure in step 412, the initiator (conceptually) constructs a hierarchical structure including a root node and leaf nodes in step 414, and communicates to each participating node Ui in step 416 the nodes from which the mixing node expects to receive tokens and the nodes to which the mixing node intends to forward the tokens, respectively.

[0066] <HTDにおけるコミットメントチャネル> Once the hierarchical design is established and each participating node knows its respective giver (upstream node) and giver (downstream node), a set of one-way commitment channels is established between all participating nodes and their givers. All token transactions between parent-child node pairs in HTD are accomplished through the use of "commitment channels." In HTD, a commitment channel consists of three separate transactions: a commitment transaction Tc, a return transaction Tc, and a r,0 , and a transfer transaction T t , . Figure 5A shows a schematic diagram illustrating the relationship between the three transactions. Therefore, without loss of generality, ij Each transfer of tokens to will generate three blockchain transactions: ·Commitment transaction Tc is U i U ij A 2-of-2 multi-signature P2SH transaction is used to commit a set of tokens x for transfer to . The transfer is controlled by either: 2-of-2 Multi-Signature (U i ,U ij ), or secret value sv ij knowledge of, and U ij Signature of. Return transaction T r,0 replaces the previously committed token x with U i This transaction becomes eligible to be submitted to the blockchain after a certain point in time. To successfully execute a return transaction, user U i and U ij The signature of the Transfer transaction T t will convert the committed token x into U ij To successfully execute this transaction, the secret value sv ij Knowledge and User U ij The signature of the

[0067] Each commitment channel created as part of the HTD is “locked” by a secret value that the giver must provide in order to receive any transfer of tokens. i and the recipient node U ij Commitment Channel U i →U ij An exemplary process 500 for constructing a .DELTA..times ... 1. Step 502: Transferee U ij is a random value k ij Each commitment channel may utilize a different random number to make it more difficult for an external node to associate a set of transactions as being part of the same instance of the HTD. In particular, being able to link different transactions visible in the blockchain to a common instance of the HTD can be made more complicated because the transactions are not necessarily all tagged with the same secret. 2. Step 502: Transferee U ij is k ij The value of U i Communicate to. 3. Step 504: The transferor Ui is ij =Q i +k ij G=sv ij Using G, the secret value sv ij Encrypted version Q of ij Calculate. 4. Step 506: Transferor U i is the encrypted value Q ij Using the commitment transaction T c Generate a commitment transaction T c (1)U i and U ij or (2) sv ij and U ij , or a signature of 5. Step 508: Transferor U i returns transaction Tr,0 Generate a return transaction T r,0 is the committed value x in U i The return transaction includes a parameter nLockTime, which specifies the point in time at or after which the return transaction becomes eligible to be submitted to the blockchain. The proposed nLockTime value may be calculated as follows:

[0068]

number

[0069] At HTD, the first commitment channel U i →U ij The tokens received via are divided into several sub-quantities, which in turn are b Second Commitment Channel U ij →U ijk , and forwarded via the HTD hierarchy. The division of the token quantity at each non-leaf node for forwarding to child nodes may be controlled by the respective node's value assignment scheme. For example, a node's value assignment scheme may indicate the ratio (e.g., 50:50, 40:35:25, etc.) in which the token quantity received at the node may be divided among the node's child nodes. The value assignment scheme may be determined independently for each non-leaf node in the hierarchy, or the same value assignment scheme may be applied to all non-leaf nodes. In some embodiments, a value assignment scheme may be utilized to ensure that the desired sub-quantities arrive at their respective destination (output) addresses in the HTD hierarchy.

[0070] A participating node serving as a mixer node in an HTD may want to ensure that it receives a transfer of a token quantity from its upstream (parent) node that is at least equal to the sum of the sub-quantities it transferred to its children in the distribution process. This is where the use of commitment channels can provide a security measure for HTD participating nodes by helping to ensure that protocol transactions are completed without allowing a node to abort or undo any of the transactions. rt For every path in the hierarchy that traces the path from U to a leaf node, commitment channels between parent-child node pairs are generated in a specific order. In particular, the commitment channel U i →U ij is any commitment channel U ij →U ijk This means that the token is generated before the user U ij The commitment channel for the transaction to be forwarded to ij From U ijk This ordered sequence is established before any commitment channel for a transaction that Uij forwards to its assignee U ijk Node U if it forwards to at least one of ij Before Uij can compromise / generate a transfer, ij To T t It allows you to ensure that a transaction exists.

[0071] In at least some embodiments, there is a transaction "cost" associated with one or more of the transfer transactions in the HTD. Additionally, mixer nodes participating in the protocol may require receipt of tokens before providing their mixing services. For example, for each of at least one of the mixer nodes, a certain amount of tokens needs to be transferred to the mixer node in order to activate the mixer node's services (e.g., to mobilize and / or control the node's resources for mixing tokens). These "costs" may be considered by the initiator when deciding on the amount of tokens to be introduced into the HTD in view of the desired / expected token output at the leaf nodes.

[0072] As an example, mixer node U ij The transfer of tokens to U is seen as a percentage of the node's received tokens. ij U ij The total mixer node cost for a transaction set in HTD is C mix can be expressed by the following formula:

[0073]

number

[0074] <Commitment channel secret value> Each commitment channel U i →U ij is the secret value sv that the grantor uses to receive tokens through the commitment channel. ij In the HTD protocol, the initiator controls all transfers (between parent-child node pairs) that are performed as part of the token distribution process. ij The function of the HTD is to "lock" the commitment channel, preventing any of the participating nodes from withdrawing tokens until the initiator is confident that a commitment channel has been created to transfer the tokens to the leaf node. i →U ij The secret value may be obtained according to the following process. 1.U ij is the random number k ij (U during HTD initialization ij 4 (selected by U i Communicate with U i is the encrypted version of your secret key Q i U ij where Q i =sv i It's G. 2. Commitment Channel U i →U ij The secret value of sv ij =sv i +k ij results in Here, the encrypted value of this is Q ij =Q i +k ij G. The secret value sv ij is determined iteratively, starting with sv0 = k s and starting. 3. This secret value sv ij =k s +k a +k b +…+k ij , where k s ,k a ,k b [[ID=Z3]],…,k i is a random number selected by the participating nodes of the previous commit channel of the same path in the commit channel U i →U ij . This can be seen from the following calculation. Q ij =Q i +k ij G=(k s G+k a G+k b G+...+k i G)+k ij G=(k s [ s +k a +k b +...+k ij )G At this time, since the initiator holds k s secretly and is not known to any other node in HTD, node U ij does not know the secret value of the commit channel. More generally, none of the transfer transactions in HTD can start without the initiator disclosing the secret value k s .

[0075] <Execution of HTD Transactions> [[ID=7Z]]Referring to Figure 6, Figure 6 shows an exemplary process 600 for executing a transfer transaction of a commit channel generated by a participating node in HTD. As described above, the initiator U i from all nodes in the hierarchy and therefore possess all the secret values. (The secret value of the commitment channel used in HTD is sv ij =k s +k a +k b +...+k ij (Recall that the secret value of the HTD is defined by sv final =k s +k a +k b +...+k z +k leaf The "final" secret value sv given by final The initiator discloses the final The value corresponds to U z Nodes (i.e., U in the path) leaf This can be done by communicating directly to the parent of the transaction T. Alternatively, the initiator can t :U z →U leaf (since the initiator also has a leaf node), which results in a secret value sv final In step 604, if the nLockTime of the commitment channel for transferring the token to the leaf node has not elapsed, the initiator can retrieve T t :U z →U leaf Submit it to the blockchain.

[0076] Step 606 U z sv final Once the value is obtained, in step 608, U z is sv final From (U leaf By its parent U z (Previously communicated to)k leaf can simply be extracted, and U z sv is the secret value required to receive a token from its parent node z More generally, for each node U ijk is the value sv ijk The transferee U ij You may communicate directly with U ijk If fails to do so, node U ij The token is U ij Before the nLockTime value of the transfer transaction to transfer to expires, the value sv in the blockchain ledger ijk Attempt to extract it.

[0077] In this way, the secret value sv ij are sequentially disclosed (through steps 608-622). Meanwhile, by moving up the paths in the hierarchical structure and discovering the relationships sv ij =sv ijk -k ijk By using the formula: the current time is less than:

[0078]

number

[0079] <Token return> Submission of a return transaction to the blockchain is limited by the nLockTime value, which is the time period during which the return transaction should not be accepted by the blockchain. In HTD, the proposed value of nLockTime is given by:

[0080]

number

[0081] <Consideration of anonymity> As mentioned above, mixer nodes may provide the functionality of mixing tokens while distributing them through the multi-level hierarchy of the HTD. That is, mixer nodes may make it more difficult to track the flow of tokens. One way this can be done is by ensuring that mixer nodes have pre-existing addresses that are different from the addresses at which tokens are received (from parent nodes) and at which mixer nodes can pass tokens to their child nodes. An example of this scenario is shown in Figure 7. In Figure 7, U ij is U ij The token is U i Address (Addr_P1) received from, and child node U ijk Each node has a separate address (Addr_P2) where a sufficient number of tokens to be passed to the node is already available. Using these separate addresses of mixer nodes to separate the receipt of token amounts at the node and the transfer of sub-amounts from the node may provide anonymity benefits in the HTD. In at least some embodiments, the HTD protocol may be designed to require a minimum number of mixer nodes with different payment receiving addresses. For example, the initiator and / or administrator of the HTD may enforce that at least one mixer node in each path of the hierarchy adheres to a different transfer receiving address convention.

[0082] Reference is now made to Figure 8, which illustrates, in block diagram form, a simplified example of a participating node 800. Node 800 may be an input node or an output node. Node 800 includes a processor 802, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Node 800 further includes memory 804, which may include permanent and non-permanent memory, for storing values, variables, and, in some examples, processor-executable program instructions, as well as a network interface 806, which provides network connectivity via a wired or wireless network.

[0083] The node 800 includes a processor-executable blockchain application 808 that includes processor-executable instructions that, when executed, cause the processor 802 to perform one or more of the functions or operations described herein.

[0084] The devices and processes described herein, as well as the modules, routines, processes, threads, applications, or other software components that implement the described methods / processes comprising a participating node, may be implemented using standard computer programming techniques and languages, and the application is not limited to particular processors, computer languages, computer programming techniques, data structures, and other such implementation details.

[0085] It should be noted that the above-described embodiments do not limit the present invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" or "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes" or "consists of," and "comprising" means "including" or "including of." The singular reference of an element does not exclude the presence of a plurality of such elements, and vice versa. The invention can be implemented by means of hardware comprising several distinct elements or by means of a suitably programmed computer. In a device claim enumerating several means, these several means can be embodied by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage. [Explanation of symbols]

[0086] 100 Blockchain Networks 102 nodes< / scriptsig> < / scriptsig>

Claims

1. 1. A computer-implemented method for creating a one-way commitment channel from a first node to a second node, the method being performed by a processing resource, the method comprising: generating a first commitment transaction representing a commitment component to be sent or committed for transfer from the first node to the second node; generating a return transaction returning all tokens from the second node to the first node; signing the return transaction and signing the first commitment transaction based on signing the return transaction; generating one or more further return transactions to reflect transfers of tokens made off-blockchain; A method comprising:

2. 2. The method of claim 1, wherein the first commitment transaction is a pay-to-script-hash transaction.

3. The method of claim 1 , wherein the return transaction is only possible after a specified time.

4. 2. The method of claim 1, wherein the one or more further return transactions reflect all token transfers the first node is requested to make to the second node.

5. The method of claim 1 , wherein the method is performed by both the first node and the second node.

6. The method of claim 1 , wherein the first node is a giver node and the second node is a giver node.

7. 2. The method of claim 1, wherein the one-way commitment channel is suitable for use by a party A associated with the first node wishing to pay a party B associated with the second node in multiple transfers over a period of time.

8. 2. The method of claim 1, wherein the return transaction enables the second node to return a committed token to the first node if the second node cannot meet the criteria set forth for the first commitment transaction.

9. 2. The method of claim 1, wherein the first node provides a secret value to the second node or the second node provides the secret value to the first node, and the secret value locks the one-way commitment channel.

10. The secret value is: a random number is transferred between the first node and the second node; an encrypted version of a secret value is transferred between the first node and the second node; The method of claim 9 , wherein the method is produced according to a method comprising:

11. 1. A computing device comprising: a processor; Memory and A network interface; a blockchain application comprising computer-executable instructions that, when executed by the processor, cause the processor to perform the method of claim 1; 1. A computing device comprising:

12. 10. A non-transitory processor-readable medium storing processor-executable instructions that, when executed by a processor of one of the nodes, cause the processor to perform the method of claim 1.

Images