Method and apparatus for increasing the entropy of a blockchain using blinded outcome diversification

Abstract

To provide a computer-implemented method and computing apparatus that enhance security of blockchain implemented transactions.SOLUTION: Each participating node may participate as a message originator, selector, and propagator. A method implemented in a participating node includes receiving a ciphertext from a predecessor node, determining whether the participating node is a selector node for the ciphertext received from the predecessor node, selecting a subset of the ciphertext when the participating node is a selector node for the ciphertext, decrypting the selected subset of the ciphertext to provide a selected ciphertext, and sending the selected ciphertext to the next node, decrypting the ciphertext received from the predecessor node when the participating node is not a selector node for the ciphertext, and sending the decrypted ciphertext to the next node.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present invention relates generally to blockchain transactions, and more particularly to methods and apparatus for increasing the security of blockchain-implemented transactions. [Background technology]

[0002] In this document, the term "blockchain" is used to include all forms of electronic, computer-based, distributed ledgers, including, but not limited to, consensus-based blockchain and transaction chain technologies, permissioned and permissionless 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 this document may refer to Bitcoin 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 computer-based, decentralized, distributed system composed of blocks, which are made up of transactions. Each transaction (Tx) is a data structure that encodes the transfer of control of a digital asset or value 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, so blocks are chained 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 that specify how and by whom the transaction's output can be accessed. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] A network node that receives a new transaction will immediately attempt to push that transaction to other nodes in the network. Before sending a new transaction to other nodes, it may be "validated," that is, checked against a set of criteria to ensure that the transaction meets the basic requirements for a valid transaction according to the applicable blockchain protocol.

[0005] For a transaction to be written to the blockchain, it is incorporated into a block. This is done by mining nodes ("miners") designed to collect transactions and form them into blocks. Miners then attempt to complete a "proof of work" for the block (specifically the block header). Miners throughout the blockchain network compete to first assemble a block of transactions and complete the associated proof of work for that block. Successful miners add their confirmed block to the blockchain, which then propagates through the network so other nodes that maintain copies of the blockchain can update their records. Nodes that receive a block also "verify" the block and all of the transactions within it to ensure that the block follows the formal requirements of the protocol.

[0006] As described, a blockchain transaction may have one or more inputs and one or more outputs. Script embedded in the inputs and outputs specifies how and by whom the transaction output can be accessed. A transaction output may be an address to which a token value may be transferred as a result of the transaction. That token value may then be associated with that output address as an unspent transaction output. Subsequent transactions may then reference that address as an input to consume or distribute that value.

[0007] One of the recognized advantages of blockchain transactions is the ability to transfer token value by associating it with one or more addresses. However, these addresses are publicly displayed on the blockchain ledger, and therefore there is a risk that information about unspent transaction outputs may be observed by nodes that may or may not be participating in the blockchain transaction.

[0008] For example, the development of coin mix services for blockchain ledgers focuses on preventing monitoring nodes from identifying links between input and output addresses. However, while such coin mix operations may make it more difficult to identify or trace the movement of tokens between addresses, monitoring nodes may still be able to perform data mining and machine learning operations on publicly available data to determine associations between inputs and outputs for blockchain transactions and thus trace associations between token values ​​and addresses. The fact that some coin mix operations involve coin mixing creates additional security vulnerabilities in which a third-party coordinator may be compromised, potentially exposing more data from the blockchain than would otherwise be publicly available.

[0009] Even if the third-party coordinator is not necessarily compromised, publicly available information on the blockchain may provide a monitoring node with enough data to detect a pattern that can be attributed to a particular source associated with a set of addresses, potentially enabling the monitoring node to determine that a particular set of addresses involved in transaction mixing are associated with a common owner. This potential pattern information in public blockchain data may be identifiable through big data analysis using machine learning algorithms, etc. This represents a security and privacy vulnerability of existing blockchain technology, even when coin or value mixing operations are used to enhance security and privacy.

[0010] The entropy of a system may refer to the disorder or uncertainty in the system and may relate to the probability that a monitoring node can infer information about a transaction address after observing several blockchain transactions. The maximum entropy of a system may be given by the logarithm to the base 2 of the number of participants N:

number

number

[0011] Because blockchain transactions can be submitted to a public ledger, monitoring nodes can attribute different probabilities to specific nodes in the system through transaction traffic analysis or timing analysis. The degree of anonymity, d, may be related to the information known by the monitoring nodes and may be measured as a normalized change in entropy:

number

[0012] It would be advantageous to provide a method and apparatus for increasing the entropy of a system to improve security and privacy and reduce the probability of exposing latent patterns in data from multiple transactions. [Means for solving the problem]

[0013] Such an improved method and apparatus for distributing token value via blockchain-implemented transactions has now been devised.

[0014] The methods described herein relate to the operation of blinded outcome diversification (BOD) methods to ameliorate some of the challenges and drawbacks described herein. In some implementations, the operation of Blinded Outcome Diversification (BOD) methods may enhance security by reducing the probability that a monitoring node can determine a link between input and output addresses in a value-mixing transaction. These methods increase the entropy of the system, reducing the ability of a monitoring node to determine associations between addresses and identify patterns in the data of multiple transactions. These methods may be implemented in participant nodes that participate in blockchain transactions. Each participant node in a plurality of participant nodes may generate or generate a ciphertext based on a common transaction option and transaction value. A dealer node may randomly designate a selector node from the plurality of participant nodes, and the selector node may select one of the transaction options to include in the blockchain transaction. A selector node may be randomly selected from the participating nodes to select transaction options for inclusion in said blockchain transaction for a particular transaction, and since the number of output addresses for inclusion in a blockchain transaction may exceed the number of input addresses, the entropy of the system increases and the ability of the monitoring node to successfully identify associations between addresses decreases.

[0015] Thus, in accordance with the present invention, there is provided a method and apparatus as defined in the appended claims.

[0016] In one aspect, the present application describes a computer-implemented method for increasing security of blockchain-implemented transactions involving participation from multiple participant nodes. Each participant node may have its own public key and private key. Each participant node may participate as a message originator, selector, and propagator. The method may include receiving ciphertext from a predecessor node; determining whether the participant node is a selector node for the ciphertext received from the predecessor node; if the participant node is a selector node for the ciphertext, selecting a subset of the ciphertext and decrypting the selected subset of the ciphertext using the participant node's private key to provide selected ciphertext for propagation to a next node; and transmitting the selected ciphertext to the next node; if the participant node is not a selector node for the ciphertext, decrypting the ciphertext received from the predecessor node using the participant node's private key; and transmitting the decrypted ciphertext to the next node.

[0017] In some implementations, if a participating node is a selector node, the ciphertext may include two or more encrypted messages, and selecting a subset of the ciphertext may include selecting one of the two or more encrypted messages.

[0018] In some implementations, the present application may provide an operation for generating a ciphertext, which may include: generating at least two messages including a first message having an output address to which the transaction is to assign a first value and a second message having two output addresses to which the transaction is to assign a second value and a third value, respectively, where the sum of the second value and the third value is the first value; encrypting each of the at least two messages to provide a ciphertext, where each of the at least two messages is a transaction option; and transmitting the ciphertext to a next node.

[0019] In some implementations, the application may provide that encrypting each of the at least two messages to provide a ciphertext includes: receiving a transaction public key and an ordered list of public keys from a dealer node, where the ordered list of public keys includes a public key associated with each participating node in the plurality of nodes, the ordered list of public keys being in descending order with the public key associated with the next node being the last public key in the ordered list of public keys; and encrypting each of the at least two messages with the transaction public key and then with the ordered list of public keys, where each encrypted message is a nested encryption of that message.

[0020] In some implementations, the application may provide that each of a plurality of participating nodes may generate transaction options having at least one specified format and at least one specified transaction value.

[0021] In some implementations, the present application may provide for operations of receiving from a dealer node an indication that the participating node is a propagator node for a ciphertext originating from another node in the plurality of participating nodes; generating a transaction public key and a transaction private key; and transmitting the transaction public key to the dealer node for transmission to the other node originating the ciphertext.

[0022] In some implementations, if the participant node is the propagator node for the ciphertext, after decrypting the ciphertext using the participant node's private key, the application may describe the subsequent operations of: decrypting the decrypted ciphertext using the participant node's transaction private key to provide an unencrypted selected message corresponding to the selected ciphertext provided by the selector node associated with the selected ciphertext; if the unencrypted selected message includes a first output address, encrypting the first output address and an associated first transaction value using the participant node's public key to provide a propagator output; if the unencrypted selected message includes a second output address and a third output address, encrypting each of the second output address and the third output address, together with the associated second transaction value and third transaction value, respectively, using the participant node's public key to provide the propagator output; and forwarding the propagator output to a successor node for mixing propagator outputs from each of the plurality of participant nodes.

[0023] In some implementations, the present application may provide for receiving an indication from a dealer node that the participant node is a selector node for a ciphertext originating from another participant node, where the participant node is randomly designated as the selector node by the dealer node.

[0024] In some implementations, the present application may provide a dealer node that designates one of the plurality of participant nodes as a propagator node and one of the plurality of participant nodes as a selector node associated with the ciphertext, wherein the propagator node, the selector node, and the participant node that originates the ciphertext are different participant nodes in the plurality of participant nodes.

[0025] In some implementations, the present application may describe a dealer node designating each of the plurality of participating nodes as a propagator node for one other participating node in the plurality of participating nodes.

[0026] In some implementations, the present application may provide that the plurality of participating nodes includes at least four participating nodes.

[0027] In some implementations, the present application may provide that the participating nodes may simultaneously participate as a message sender, a selector, and a propagator for associated ciphertexts, and that each participating node in the plurality of participating nodes provides a propagator output for associated ciphertexts for which the participating node is designated as a propagator node.

[0028] Features described in connection with one aspect or implementation may be used in combination with any other aspect or implementation. For each implementation of the method, a corresponding computing device configured to implement the method is provided. Features described in connection with an implementation of the method are also applicable to the corresponding computing device, and vice versa.

[0029] In additional or alternative aspects, the present application may provide a non-transitory processor-readable medium storing processor-executable instructions that, when executed by a processor, cause the processor to perform any one or more of the methods described herein for increasing security of blockchain-implemented transactions.

[0030] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. 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]

[0031] [Figure 1] FIG. 1 is a block diagram from an example blockchain network related to a blockchain. [Figure 2] 1 illustrates a node from an exemplary cycle Ci that performs the method described herein. [Figure 3] 10 illustrates an example of an exemplary message that may be generated by a participating node. [Figure 4] FIG. 3 illustrates nested encryption of each of two or more messages. [Figure 5] 1 illustrates an exemplary implementation of nested decryption of ciphertext and selection of transaction options for cycle Ci according to the present application. [Figure 6] 1 illustrates, in flowchart form, an exemplary method implemented in a participant node participating in a blockchain transaction, according to the present application. [Figure 7] 1 illustrates, in flowchart form, an exemplary method implemented in a participating node that may be designated as a propagator, in accordance with the present application. [Figure 8] 10 illustrates an example propagator output from a participating node designated as a propagator for cycle C1 in accordance with the present application. [Figure 9]Figure 1 shows the nodes participating in a blockchain transaction according to the present application, with each participating node providing a propagator output from its respective cycle Ci. [Figure 10] 1 illustrates the encryption phase of a propagator node output based on an exemplary coin mixing method according to the present application. [Figure 11] 11 illustrates the decryption phase for the exemplary coin mixing method of FIG. 10 in accordance with the present application. [Figure 12] 10 illustrates the distribution of the number of output address combinations as a function of the number of participating nodes following operation of the method described herein, in accordance with the present application. [Figure 13] 1 illustrates, in block diagram form, a simplified example of a participating node according to the present application. DETAILED DESCRIPTION OF THE INVENTION

[0032] As used herein, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements alone, any subcombination, or all of the listed elements, and does not necessarily exclude additional elements.

[0033] As used herein, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination, or all of the listed elements, and does not necessarily exclude additional elements, nor does it necessarily require all elements.

[0034] Reference is now made to FIG. 1, which illustrates in block diagram form an example of a blockchain-related blockchain network 100. The blockchain network 100 is a peer-to-peer, open membership network in which anyone can join without an invitation or consent from other members. Distributed electronic devices running instances of the blockchain protocol under which the blockchain network 100 operates 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 protocol.

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

[0036] The nodes 102 of the blockchain network 100 may be coupled to one another using any suitable communication technology, which may include wired or wireless communication technology. In some cases, the blockchain network 100 may be 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 may maintain a general ledger of all transactions on the blockchain. The global ledger may be a distributed ledger, and each node 102 may store a full or partial copy of the global ledger. Transactions that affect the global ledger may be verified by other nodes 102 to ensure the validity of the global ledger is maintained. The details of implementing and operating a blockchain network, such as one using the Bitcoin protocol, will be understood by those skilled in the art.

[0038] Each transaction may have one or more inputs and one or more outputs. Script embedded in the inputs and outputs specifies how and who can access the transaction's output. A transaction output may be an address to which value is transferred as a result of the transaction. That value may then be associated with that output address as an unspent transaction output. Subsequent transactions may then reference that address as an input to consume or distribute that value.

[0039] Although transactions may be pseudo-anonymous, meaning that no personal information is included in transactions on a blockchain ledger, it may theoretically be possible for a monitoring device to track or associate value transfers in a chain of transactions and, in some cases, use external data to associate the transferred value with a specific entity. External data may include information extracted from, for example, internet blog sites, social media, or other third-party systems about specific users associated with participating nodes. The development of coin-mixing services for blockchain ledgers focuses on preventing monitoring devices from easily associating transaction input and output addresses to associate the transfer of digital assets from one entity to another. For example, a coin-mixing system may include a group of devices that pool assets (e.g., Bitcoin) together and then distribute the pooled assets to alternate device addresses. These coin-mixing systems may increase the difficulty for monitoring devices to associate transaction input and output addresses.

[0040] As described, some coin mixing systems may utilize a shuffling operation to disassociate input addresses from output addresses for blockchain transactions. However, a typical shuffling operation may utilize a pseudorandom process to shuffle the order of addresses, which may be derived from inherently deterministic mathematical operations. Thus, a monitoring device may attempt a "brute force" type attack to infer information about one or more participating nodes in a blockchain transaction.

[0041] Note that the terms "participating node" and its "output address" may be used herein. References to a participating node's "output address" are not intended to refer to the network address of the physical node; the "output address" is the address specified in a transaction on the blockchain that has unspent value. A physical node can claim ownership of that unspent value by possessing the key corresponding to the signature on that transaction. In this sense, the "output address" is not the address of the participating node, but the blockchain transaction output address associated with the participating node. Any references to the "output address" of a participating node in this specification should be understood accordingly.

[0042] This application may describe methods performed by multiple participants. For example, the multiple participant nodes may include at least four participant nodes. Many more participant nodes may participate in the blockchain transactions described herein.

[0043] Each participant node may be a computing device that participates in blockchain transactions. A computing device may participate as a message originator, generating a message and then encrypting the message. A computing device may also participate as a selector, selecting a subset of ciphertexts, where the subset may have been generated by another participant node in the plurality of participant nodes. A computing device may also participate as a propagator for ciphertexts that may have been originated by yet another participant node in the plurality of participant nodes.

[0044] This application describes a dealer node for distributing public and private keys. In some implementations, the dealer node may be a node other than a participant node, and the dealer node may transfer public keys from one participant node to another. Furthermore, the dealer node may assign specific roles to the participant nodes. For example, each participant node may be a message originator. Furthermore, the dealer node may assign each participant node as a selector for ciphertexts originating from other participant nodes and as a propagator for ciphertexts originating from yet other participant nodes. The respective operations of the originator, selector, and propagator are described later in this document.

[0045] Reference is now made to Figure 2. Figure 2 shows an exemplary cycle C i The graph shows the subset of participating nodes for cycle C. i may generally be defined by the actions performed by multiple participant nodes for a given blockchain transaction. The dealer node 210 may randomly designate certain participant nodes as selector nodes and certain participant nodes as propagator nodes.

[0046] Dealer Node 210 also operates Cycle C i The dealer node 210 may define the order or position of each participating node among multiple participating nodes for cycle C. Each participating node may be associated with a public key and a private key, and the public key of each participating node may be shared with each of the other participating nodes. In some example implementations, the dealer node 210 (1) specifies the order or position of each participating node, and (2) determines the order or position of each participating node for cycle C. i An ordered list of public keys may be sent to each participating node based on the order or position of each participating node with respect to cycle C. i The order or position of each participating node among the participating nodes for may be determined randomly or in any other manner.

[0047] The dealer node 210 may designate one of the multiple participant nodes as a propagator node and one of the multiple participant nodes as a selector node. That is, the dealer node 210 may designate a selector 230 and a propagator 240 to select and prepare messages from the sender 220, respectively. Cycle C i In the cycle C, the sender 220, the selector 230, and the propagator 240 each i For example, cycle C1 may show BOD operations performed by multiple participating nodes, where a message may be generated by node U1 and transaction options may be set by node U2. j The selected transaction option may be selected by node U. n may be propagated by, n may represent the number of participating nodes, and 1 <j<nである。

[0048] The dealer node 210 may designate the propagator 240 to decrypt a message originating from the originator 220. The decrypted message may be a transaction to be included in a blockchain transaction. In some examples, the blockchain transaction may be a transaction for a coin mixing operation. The propagator 240 may be a Cycle C i Transaction public / private keys (P i D / V i D In some implementations, before the originator 220 generates and encrypts a message, the propagator 240 generates a transaction public key (P i D ) to the dealer node 210, which then sends its transaction public key (P i D ) may be sent to the sender 220. Cycle C iFor i D ) may be sent to the originator 220.

[0049] The dealer node 210 may randomly designate a selector 230, which may be any of multiple participating nodes. As described below, the selector 230 receives ciphertexts from previous participating nodes, selects a subset of the received ciphertexts, and decrypts the selected subset of the ciphertexts using the selector's 230 private key to generate cycle C. i The selector 230 may provide a selected ciphertext for propagation to the next node in the chain. As will be evident from the methods described herein, the selector 230 may be randomly selected by the dealer node 210, and because the selection mechanism from each of the participating nodes may be different, the distribution of token values ​​by blockchain transactions may be provided in a less deterministic manner to ameliorate some of the security shortcomings described herein.

[0050] Reference is now made to FIG. 3, which diagrammatically illustrates exemplary messages that may be generated by any participating node. When a participating node may be designated as an originator 220 (FIG. 2) that originates a ciphertext, the participating node may generate at least two messages, including a first message having one output address to which the transaction should assign a first value and a second message having two output addresses to which the transaction should assign a second value and a third value, respectively. The sum of the second value and the third value may be equal to the first value. Further, the participating node may encrypt each of the at least two messages to provide a ciphertext, and each of the at least two messages may be a transaction option. The participating node may then transmit the generated ciphertext to the next node.

[0051] To illustrate, the originator 220 may generate a first message (r1) 350 and a second message (r2) 360. The first message 350 may include a first output address 356. The second message 360 ​​may include a second output address 366 and a third output address 368. In this example, the originator 220 generates two transaction options, including (i) an option to split an input value for the transaction (e.g., 10 bitcoins) into two identical values ​​(e.g., 5 bitcoins), each of which may be associated with a respective output address, or (ii) an option to send the entire input value (e.g., 10 bitcoins) to a single output address. The selection of one of the two message options may be performed by a randomly designated selector 230 (FIG. 2). The selector 230 may select an option without knowing who the originator is. As described below, each of the message options undergoes nested encryption with the transaction public key and the public keys of multiple participating nodes, so that the selection of one of two or more message options may be made by selector 230 without any knowledge of the message contents (e.g., token value and output address).

[0052] Message Option Format Cycle C i and each participating node that performs the operation of transmitting a ciphertext may be defined in terms of its cycle C i3. A message may be generated according to the specified message option format for Cycle C. That is, in some implementations, each of a plurality of participating nodes may generate transaction options having at least one specified format and at least one specified transaction value. For example, in FIG. 3, the specified message option format may include a first message 350 having a first transaction value 352 (e.g., 10 bitcoins) and a first output address 356. The message option format may also be specified to include a second message 360 ​​having a second transaction value 362 (e.g., 5 bitcoins) and a third transaction value 364 (e.g., 5 bitcoins), where the second transaction value 362 may be associated with a second output address 366, and the third transaction value 364 may be associated with a third output address 368. Each of these message options may be associated with a second message 360 ​​having a second transaction value 362 (e.g., 5 bitcoins) and a third transaction value 364 (e.g., 5 bitcoins), where the second transaction value 362 may be associated with a second output address 366, and the third transaction value 364 may be associated with a third output address 368. i There may be transaction options regarding:

[0053] The originator 220 may encrypt these message options to provide ciphertext. For example, the originator 220 may receive a transaction public key and an ordered list of public keys from the dealer node 210. The ordered list of public keys may include a public key associated with each participating node in a plurality of participating nodes. The ordered list of public keys may be in reverse or descending order, with the public key associated with the next node being the last public key in the ordered list of public keys. Furthermore, the originator 220 may encrypt each message option with the transaction key and then with the ordered list of public keys. Each encrypted message is a nested encryption of that message.

[0054] In the above example, a participating node may generate the second message with two output addresses, but in some implementations, the second message may include three or more output addresses where the transaction assigns a value to each output address, and the sum of the assigned values ​​may equal the first value. For example, the second message may include three output addresses where the transaction assigns a second value, a third value, and a fourth value to each output address, and the sum of the second value, the third value, and the fourth value may equal the first value. That is, in some implementations, the second message may include any number of output addresses for associating values ​​with.

[0055] Now, reference is made to Figure 4. Figure 4 shows cycle C i 2. The nested encryption of each of the two or more messages generated by the sender 220 (FIG. 2) for Cycle C is shown diagrammatically. The nested encryption of each of the two or more messages ... i and an ordered list of the public keys of the participating nodes in descending order for .

[0056] Specifically, Figure 4 illustrates nested encryption 450 of the first message (r1) 350 (Figure 3). The originator 220 (1) encrypts the transaction public key (e.g., provided by the dealer node 210 and its cycle C) i (1) may then encrypt a first message (r1) 350 using the ordered list of public keys in reverse order.

[0057] For example, cycle C i includes five participating nodes, the originator 220 may (1) encrypt a first message (r1) using the transaction public key, and then (2) sequentially encrypt using the public keys associated with the fifth participating node, the fourth participating node, the third participating node, and the second participating node.

[0058] Similarly, Figure 4 also illustrates nested encryption 460 of the second message (r2) 360 (Figure 3). The originator 220 may (1) encrypt the second message (r2) using the transaction public key, and then (2) sequentially encrypt it using the public keys associated with the fifth, fourth, third, and second participating nodes. The combination of the nested encryption of the first message (r1) and the second message (r2) is called the cycle C. i 3 and 4 includes two message or transaction options (e.g., a first message (r1) and a second message (r2)), in some example implementations, the originator 220 may send a ciphertext associated with the originator 220 for cycle C. i You may generate three or more transaction options for

[0059] The nested encryption of the first message (r1) and the second message (r2) is performed in cycle C according to the order specified by the dealer node 210. i The nested encryption of the first message (r1) and the second message (r2) is sequentially decrypted as each participating node uses its private key to decrypt the received ciphertext. The ciphertext is finally delivered to the propagator 240 (e.g., cycle C). i When the ciphertext is sent to the participating nodes (the last node for cycle C), the propagator 240 may decrypt the ciphertext using the propagator's 240 private key and then decrypt the resulting ciphertext using the transaction private key. i The transaction public key may correspond to a transaction public key that the propagator 240 previously sent to the dealer node 210 for transmission to the originator 220.

[0060] Reference is now made to Figure 5. Figure 5 shows the cycle C i Cycle C illustrates the nested decryption of ciphertexts and the selection of transaction options for i In general, cycle C may be defined by the operations performed by multiple participating nodes. i may have eight participating nodes 502. For ease of explanation, the individual participating nodes 502 may be identified as "U1," "U2," "U3," "U4," "U5," "U6," "U7," and "U8." Although the participating nodes for the cycle shown in FIG. 5 include eight participating nodes, any number of nodes may participate in cycle C. i In some implementations, the number of participating nodes may be any number greater than three. Figure 5 illustrates cycle C1, in which node U1 may originate a message and generate a ciphertext. Additionally, the dealer node may designate node U6 as a selector node and node U8 as a propagator node.

[0061] A dealer node may specify a node order or node position. In FIG. 5, the dealer node may specify a node order according to an ascending node identifier order, such as U1 to U8. However, in some examples, the dealer node may specify a node order in any other manner, and the node order may not follow an ascending node identifier order.

[0062] Generally, the sender 220 (FIG. 2) i The propagator 240 may be the first participating node for the last participating node U n The selector 230 may select an intermediately located participant U jIt may also be the case that, where n is the number of participating nodes and 1 < j < n. The dealer node may specify node U6 as selector node 230 (FIG. 2). Thus, in FIG. 5, the sender 220 may be node U1, the selector 230 may be node U6, and the propagator 240 (FIG. 2) may be node U8. Although node U6 is specified as selector 230, selector 230 may be any other node that is not the sender or the propagator. In FIG. 5, the dealer node may also randomly specify any one of nodes U2, U3, U4, U5, or U7 as selector 230.

[0063] Before executing the operation of cycle C1, node U8 may receive an indication from dealer node 210 that it is the propagator 240 for the ciphertext transmitted from sender 220. It should be understood that in some implementations, propagator 240 may not need to know which participating node is sender 220. Further, propagator 240 may not need to know which participating node is sender 220. Propagator 240 only needs to know that it can perform the operation of the propagator for the ciphertext transmitted from another participating node in a plurality of participating nodes. Node U8 may generate a transaction public key and a transaction private key and transmit the transaction public key to dealer node 210 for transmission to sender 220.

[0064] The dealer node may also transmit an ordered list of public keys to the originator 220. In the example of FIG. 5, the dealer node 210 may transmit an ordered list of public keys (e.g., public keys associated with nodes U8, U7, U6, U5, U4, U3, and U2). The order of the transmitted public keys may be based on a participant node order specified by the dealer node 210. In the example of FIG. 5, the ordered list of public keys may be a descending ordered list of public keys, i.e., public keys associated with nodes U8, U7, U6, ..., U3, and U2. As is apparent from the description herein, when node U1 generates a message option and encrypts the message option using nested encryption operations to provide ciphertext, the ciphertext is sequentially transmitted to the next node in the ordered participating nodes and, thus, sequentially decrypted using the respective private keys associated with each "next node."

[0065] In FIG. 5, node U1 may generate at least two messages, including a first message and a second message. The first message may be a first message option including a first output address to which the transaction assigns a first value. The second message may be a second message option including a second output address to which the transaction assigns a second value and a third output address to which the transaction assigns a third value. When these two messages are provided for cycle C1, node U1 may encrypt the first message (r1) and the second message (r2), respectively, using the nested encryption operation briefly described with reference to FIG. 4. The combination of the nested encrypted first message (r1) and the nested encrypted second message (r2) may be a ciphertext, and node U1 may transmit the ciphertext to node U2.

[0066] Reference is now made simultaneously to FIG. 6, which illustrates, in flowchart form, an exemplary method 600 implemented by a participant node participating in a blockchain transaction in accordance with the present disclosure. Method 600 may include operations that may be performed by one or more processors at one of the participant nodes of the blockchain transaction. This implementation assumes that the participant node performing the operations is not the originator of the received ciphertext.

[0067] For purposes of illustration, assume that the participating node performing the operations of method 600 of Figure 6 is node U2. At operation 610, the processor may receive a ciphertext from a predecessor node. In this example, the predecessor node may be node U1, and the ciphertext may include a combination of a nested encrypted first message (r1) and a nested encrypted second message (r2). The combination of the nested encrypted messages may be the ciphertext.

[0068] At operation 620, the processor may determine whether the participating node is a selector node for the ciphertext received from the predecessor node. In FIG. 5, node U6 may be the designated selector node. At operation 620, the processor may determine that node U2 is not a selector node for the ciphertext received from node U1. That is, the participating node is other than a selector node for the ciphertext received from node U1.

[0069] If the processor determines that the participating node is other than the selector node for the received ciphertext, then the processor may decrypt the received ciphertext using the private key of the participating node (e.g., node U2) in operation 660. Because node U1 (the originator) performed the operation of generating the nested encrypted message using the set of public keys corresponding to the specified node order, node U2 may decrypt the "current" state of the ciphertext 504 received from node U1.

[0070] The processor may then send the decrypted ciphertext to the next participating node (e.g., node U3). When node U2 decrypts the "current state" of ciphertext 504 using node U2's private key, the originally generated first message (r1) and the originally generated second message (r2) are decrypted, and the "subsequent current state" of the ciphertext (denoted in FIG. 5 by reference numeral 506) is such that fewer public keys may be required to provide an unencrypted version of the ciphertext. As shown in FIG. 5, once node U2 decrypts the "current" state of ciphertext 504, the decrypted ciphertext may be a nested encryption requiring a remaining list of public keys to be used to provide an unencrypted version of the ciphertext.

[0071] If, at operation 620, the processor determines that the participant node is a selector node for the ciphertext, then, at operation 630, the processor may select a subset of the ciphertext. To illustrate, assume that the participant node performing the operations of method 600 of FIG. 6 is node U6. The dealer node may have designated node U6 as the selector, so at operation 630, the processor may select one of the nested encrypted first message (r1) and the nested encrypted second message (r2). If the participant node performing the operations is node U6, the ciphertext received from the predecessor node is shown as the ciphertext identified by reference numeral 508 in FIG. 5. This ciphertext includes both the first message (r1) and the second message (r2), encrypted with the transaction public key and the private keys associated with nodes U8, U7, and U6, respectively. In FIG. 6, the selector node may select the nested encrypted second message (r2) as the subset of the ciphertext. In some implementations, the selection of the first message (r1) or the second message (r2) may be based on input received at the selector node, although the selection may be made in any other manner.

[0072] At operation 640, the processor may use a private key associated with node U6 to decrypt the selected subset of the ciphertexts to provide chosen ciphertext. For example, the processor may use the private key of node U6 to decrypt the nested encrypted second message (r2) to provide chosen ciphertext 510.

[0073] In operation 650, the processor may transmit the selected ciphertext 510 to the next participating node. As shown in FIG. 5, node U6 propagates the selected ciphertext 510 to node U7. Because the processor did not select a nested encrypted ciphertext corresponding to the first message (r1), the first message (m1) may not be propagated to any subsequent participating nodes for cycle C1. That is, the nested encrypted ciphertext corresponding to the first message (r1) may never be received by propagator node U8.

[0074] In some example implementations, even if the nested encrypted ciphertexts corresponding to the first message (r1) are eventually propagated to node U7, subsequent participating nodes may not be able to successfully decrypt the nested encrypted ciphertexts according to the nested order of encryption / decryption because node U6 does not use its private key to decrypt the non-selected ciphertexts associated with the first message (r1).

[0075] To further illustrate, assume that the participating node performing the operations of method 600 of Figure 6 is node U7. At operation 610, the processor may receive a ciphertext from node U6. In this example, the received ciphertext may be chosen ciphertext 510. The chosen ciphertext 510 may be the "current state" of the ciphertext, which may be a second message (r2) encrypted with the transaction public key and public keys associated with the eighth and seventh participating nodes.

[0076] In operation 620, the processor may determine that the participating node, node U7, is other than the selector node for the received ciphertext. In the first cycle C1, the selector node may be node U6, and node U7 may be positioned subsequent to node U6.

[0077] At operation 660, the processor may decrypt the received selected ciphertext 510 using a private key associated with node U7 to provide a decrypted ciphertext for propagation to node U8. In this example, the decrypted ciphertext may be a second message (r2) encrypted with the transaction public key and a public key associated with node U8. That is, the decrypted ciphertext may be pre-propagator ciphertext 512, as shown in FIG. 5. Thus, at operation 660, the processor may send pre-propagator ciphertext 512 to the propagator node, node U8.

[0078] Reference is now made to Figure 7, which illustrates in flow chart form an exemplary method 700 implemented at a participant node in accordance with the present application. The participant node may be (1) other than the selector 230 (Figure 2) or (2) designated by the dealer as the propagator 240 (Figure 2). Method 700 is implemented in cycle C. i The implementation may include operations that may be performed by one or more processors at one of the participating nodes of a blockchain transaction in cycle C. i It is assumed that the node is not the source of the received ciphertext.

[0079] At operation 760, the processor may decrypt the received ciphertext using the private key of the participating node to provide the decrypted ciphertext. Operation 760 shown in Figure 7 may correspond to operation 660 shown in Figure 6.

[0080] At operation 710, the processor may determine whether the participating node is a propagator 240 (FIG. 2). If the participating node is not a propagator 240, the processor may transmit the decrypted ciphertext to the next node at operation 750. Illustratively, assume that the current participating node is a participating node other than the selector and a participating node other than the propagator. For example, assume that the participating node is the second participating node, node U2, in FIG. 5. At operation 750, the processor may transmit the decrypted ciphertext 506 to the next node at cycle C. i may be transmitted to the next node of the participating node, for example node U3.

[0081] In operation 710, the processor determines whether the participating node is in cycle C. i If the processor determines that the selected message is a propagator 240 for the transaction, then in operation 720, the processor may decrypt the decrypted ciphertext using the transaction private key to provide an unencrypted selected message that corresponds to the selected ciphertext provided by the selector node.

[0082] To illustrate, assume that the participating node performing the operations of method 700 of FIG. 7 is node U8. At operation 760, the processor may decrypt the received ciphertext using the private key of node U8 to provide a decrypted ciphertext. Further, at operation 720, if the participating node is the propagator node for the decrypted ciphertext, the processor may decrypt the decrypted ciphertext using the transaction private key to provide an unencrypted selected message corresponding to the selected ciphertext provided by the selector node associated with the selected ciphertext. The operations described herein may be performed for a given cycle C iFor any participating node (e.g., one acting as a monitoring node in parallel), cycle C is required to associate the propagator (and thus the propagator output(s)) with the originator, since it may require the propagator to perform the decryption using: (1) the private key associated with that propagator node, and (2) the transaction private key. i Inferring a chain of participating nodes between multiple participating nodes for ∑ i = 1 ...

[0083] In cycle C1 of the present example of FIG. 5, the selector, node U6, selected a subset of ciphertext originating from node U1. The selected subset of ciphertext included a nested encrypted second message. Recall that the second message (r2) 360 (FIG. 3) may include a second output address 366 (FIG. 3) associated with a second transaction value 362 (e.g., 5 bitcoins) and a third output address 368 (FIG. 3) associated with a third transaction value 364 (e.g., 5 bitcoins). Because the unencrypted selected message includes two output addresses, in operation 740, the processor may encrypt each of the unencrypted output addresses and associated values ​​with the public key of a participating node (e.g., node U8) to provide a propagator node output.

[0084] However, if the selected subset of ciphertexts includes a nested encrypted first message (not shown in FIG. 5), then in operation 730, the processor may encrypt the unencrypted output address and associated value using the public key of the participating node (e.g., node U8) to provide a propagator node output.

[0085] In the method described herein, the sender 220 sends a cycle C iThe originator 220 may have knowledge of the ordering of the participant nodes for the cycle C described herein. However, the originator 220 may not have knowledge of which participant nodes may be selectors 230. The originator 220 may have knowledge of which participant nodes are propagators 240, but because the transaction public key is transmitted to the originator 220 through the dealer node 210, the propagators 240 may not have knowledge of which participant nodes are originators 220. The originator 220 may have knowledge of which participant nodes are propagators 240 and could request the transaction private key from the propagators 240, but doing so would negate the benefits provided by the methods described herein. That is, the originator 220 may have knowledge of which participant nodes are propagators 240 and could request the transaction private key from the propagators 240. i If one were to attempt to bypass the operation on , the benefits realized by removing the selection process from certain participating nodes would be negated.

[0086] Reference is now made to Figure 8, which illustrates possible propagator node outputs from node U8 in accordance with the present application. To illustrate the possible propagator node outputs from each of operations 730 or 740, Figure 8 graphically illustrates the possible propagator node outputs from node U8 for cycle C1 shown in Figure 5.

[0087] If the selector (e.g., node 6) selects a subset of ciphertexts that includes a nested encrypted first message (r1) (not shown in FIG. 5), then in operation 720 (FIG. 7), the processor may provide a first unencrypted selected message (r1) 880, shown in FIG. 8.

[0088] If the selector (e.g., node 6) selects a subset of ciphertexts that includes a nested encrypted second message (r2), then in operation 720 (FIG. 7), the processor may provide a second unencrypted selected message (r2) 890, shown in FIG. 8.

[0089] In operation 730, if the unencrypted selected message includes the first output address, the processor may encrypt the first output address and the associated first transaction value with the public key of node U8 to provide a propagator output. That is, the first unencrypted selected message (r1) 880 may include an output address associated with a transaction value. In operation 730, the propagator output may be the first propagator output 885.

[0090] At operation 740, if the unencrypted selected message includes a second output address and a third output address, the processor may encrypt the second output address and the associated second transaction value with U8's public key and encrypt the third output address and the associated third transaction value with node U8's public key to provide a propagator output. That is, the second unencrypted selected message (r2) 890 may include two output addresses, each associated with a transaction value. At operation 740, the propagator output may be a second propagator output 895 that includes two outputs. Each output may represent a divided transaction value. For example, if the selector (e.g., node 6) selects a subset of ciphertext associated with dividing a transaction output into two outputs (e.g., dividing 10 bitcoins into two 5 bitcoin messages), at operation 740, the propagator will include two outputs.

[0091] Therefore, Cycle C iAt the end of cycle C1, depending on the message option selection made by the selector node, the propagator may generate either a one-line propagator output with one output address or two one-line propagator outputs with two output addresses. As described, in the example cycle C1 shown in Figure 5, the propagator (e.g., node U8) provides two one-line propagator outputs, such as the second propagator output 895 shown in Figure 8.

[0092] In addition to the first cycle C1 shown in FIG. i The participating nodes may perform operations associated with each cycle C. For example, cycle C2 may be generated, where node U2 may be the originator, and the dealer node may randomly designate the selector and propagator for cycle C2. Similarly, cycles C3, C4, ..., and C8 may be generated, where node U3, node U4, ..., and node U8 may be the originators, respectively, and the dealer node may randomly designate the selector and propagator for each cycle. The dealer node may then generate a cycle C2 for each cycle C3, C4, ..., and C8. i For each cycle C, a selector node may be randomly selected among the participating nodes. i Because the selector nodes for are randomly assigned, the methods described herein may further limit the possibilities for the monitoring nodes to infer decision patterns.

[0093] The method described herein contemplates that a monitoring node may be interested in associating one or more output addresses with a particular entity so that token transfers can be tracked. However, the only output addresses that may be known to a participating node may be those for which that node is a propagator. In the method described herein, a propagator may be the propagator of a given cycle C i The monitoring node may not have knowledge of the sender for a given cycle C iTo limit the possibilities of guessing which participant node may be the selector in a cycle, the dealer node may randomly designate a participant node as the selector, where the random designation in one cycle is independent of any designation of that participant node for another cycle. According to the method described herein, the first participant node may be the selector for some cycles. i The second participating node may be designated as a selector in any cycle of C i It may not be specified as a selector in

[0094] In some implementations, each participating node in the plurality of participating nodes may be designated as a propagator for at most one cycle. For example, once node U8 is designated as the propagator for cycle C1 (e.g., node 1 is the sender), node U8 cannot be a propagator for any other cycle (e.g., node U8 may not be a propagator for cycles C2, C3, ..., or C8).

[0095] In some implementations, with N participant nodes, there may be N cycles. The N cycles may be run in parallel, provided that the dealer node(s) designate specific participant nodes as selectors and propagators for each of the N cycles, and public transaction keys and participant node public keys are exchanged a priori (e.g., see Figure 2).

[0096] Reference is now made to Figure 9, which graphically illustrates a propagator node output 904 after operations performed by participant nodes 902 over N cycles may be completed in accordance with the present application. In the example shown in Figure 9, there may be eight participant nodes participating in a blockchain transaction. Thus, there may be eight cycles (e.g., cycles C1, C2, ... and C8).

[0097] In Figure 9, each participant node may be designated as a propagator for a ciphertext originating from a sender. The sender may be a different participant node from the designated propagator. In Figure 9, each participant node Ui may be a propagator and may provide either one line propagator output or two one line propagator outputs based on messages originated by other participant nodes Uj.

[0098] To illustrate, if node U8 is designated as the propagator of a message originating from node U1 (e.g., cycle C1 shown in Figure 5), node U8 will propagate the propagator output r 1α and r 1β Two 1-line propagator outputs may be provided.

[0099] In another example, if node U1 is designated as the propagator for a message originating from node U7, node U1 will have a propagator output r 7α and r 7β Two 1-line propagator outputs may be provided.

[0100] In another example, if node U2 is designated as the propagator for a message originating from node U6, node U2 will receive the propagator output r 6α As such, one line propagator output may be provided.

[0101] In the example implementation described herein, at the end of the N cycles, each participating node may provide a propagator output. The number of provided propagator outputs for the N cycles may be greater than the number of participating nodes because it may be statistically unlikely that the selector for each of the N cycles will select a transaction option that does not divide the input value (e.g., splitting 10 bitcoins into two 5 bitcoin message outputs in the example described herein).

[0102] Thus, to construct a blockchain transaction that may involve multiple participating nodes, a shuffling technique may be performed to merge propagator node outputs so that the propagator node outputs are assembled in a random order. In a scenario where a selector may select a transaction option for splitting an input value (e.g., in the example described herein, splitting 10 bitcoins into two 5 bitcoin message outputs), after the propagator outputs are shuffled and merged, the two output addresses associated with the split input values ​​(e.g., 5 bitcoins each) may no longer be adjacent in the shuffled / merged set of propagator outputs.

[0103] To illustrate operations for shuffling and merging propagator output values, reference is now made to Figures 10 and 11, which diagrammatically show an exemplary CircleShuffle operation for shuffling and merging participating nodes' propagator node outputs into blockchain transactions as described herein. The CircleShuffle operation may be one example of shuffling and merging output addresses, although any other coin mixing method or operation may be used in combination with the BOD operations described herein.

[0104] Figure 10 illustrates the encryption phase for a CircleShuffle operation. Figure 11 illustrates the decryption phase for a CircleShuffle operation. For ease of explanation, the exemplary CircleShuffle operation described with reference to Figures 10 and 11 assumes a group of four participating nodes, although more than four participating nodes may be desired to realize the benefits of the operations described herein.

[0105] The encryption phase for the CircleShuffle operation of FIG. 10 includes four participating nodes 1002. For ease of explanation, the individual participating nodes may be identified as “U1,” “U2,” “U3,” and “U4.” In particular, node U1 may be the designated propagator of node U3’s transaction in which the token value may not be split. Node U2 may be the designated propagator of node U1’s transaction in which the token value may not be split. Node U3 may be the designated propagator of node U4’s transaction in which the token value may be split. Node U4 may be the designated propagator of node U2’s transaction in which the token value may be split. As an illustrative example, the input value may be 10 bitcoins, and if the participating nodes choose to split the input value, two 5-bitcoin values ​​may each be associated with the output value. If the input value may be split, selector 230 (FIG. 2) may select the message option to provide two one-line propagator outputs. That is, the two one-line propagator outputs may be two output addresses, and each output address may be associated with a transaction value (see, for example, second message (r2) 360 in FIG. 3).

[0106] In Figure 10, each participating node 1002 may encrypt a set of shuffled options (SSO) 1004 with the public key of the next node. Illustratively, node U1 may encrypt its propagator output (e.g., r 3α ) with the public key associated with node U1, and the shuffled set of options (e.g., the encrypted propagator output r 3α) using the public key of node U2. In some implementations, the propagator output may be associated with a transaction value and an output address associated with the transaction value. Node U1 may encrypt the SSO with the public key of node U2. Then, when the encrypted SSO is sent to node U2, node U2 may be able to decrypt the SSO. That is, a node that does not have the private key associated with node U2 may not be able to decrypt the SSO.

[0107] When node U2 receives the encrypted SSO from node U1, node U2 may (i) decrypt the received encrypted SSO; (ii) encrypt U2's propagator outputs using node U2's public key; and (iii) shuffle the order of the encrypted propagator outputs included in the SSO. Once the encrypted propagator outputs have been shuffled, the shuffled SSO may be encrypted using the public key associated with node U3. Node U2 may forward the updated, encrypted SSO to the next node.

[0108] In some implementations, participating nodes may utilize any suitable pseudo-random process when performing operations to shuffle the order of encrypted addresses within an SSO. It may be appreciated that the pseudo-random process for shuffling addresses may be generated by a mathematical procedure that is inherently deterministic.

[0109] Node U3, upon receiving the encrypted shuffled SSO from node U2, may perform similar operations and may similarly encrypt the updated shuffled SSO with the public key of node U4. Node U3 may forward the updated encrypted SSO to the next node, node U4. Similarly, node U4, upon receiving the encrypted shuffled SSO from node U3, may perform operations and may similarly encrypt the updated shuffled SSO with the public key of node U1. Node U4 may forward the updated encrypted SSO to the next node, node U1.

[0110] Following the encryption / shuffle operation shown in FIG. 10, in FIG. 11, node U1 receives the set of shuffled outputs. Node U1 may decrypt the received SSO using node U1's private key and look up node U1's encrypted output address in the SSO. When node U1 obtains node U1's encrypted propagator output, node U1 may decrypt the propagator output using node U1's private key and then re-encrypt the propagator output using node U1's public key. Node U1 may encrypt the updated SSO using the public key associated with the next available participating node, node Ui. Node Ui, the next available participating node, does not necessarily have to be node U2, but can be another of the participating nodes.

[0111] Node Ui may then perform similar operations to decrypt the received encrypted updated SSO, look up the propagator output associated with node Ui, decrypt the propagator output using the private key associated with node Ui, and re-encrypt the address using node Ui's public key. Node Ui may also encrypt the updated SSO using the public key of another participating node (e.g., a participating node in the set {Ui, U2, ..., Un}).

[0112] Once each participating node looks up its encrypted propagator output in the received SSO, (i) replaces the header with its corresponding decrypted value, and re-encrypts the output addresses with node U1's public key, the final updated encrypted SSO may be sent to node U1. In an exemplary implementation, the final updated encrypted SSO may include the output addresses encrypted with node U1's public key.

[0113] Once node U1 receives the final updated encrypted SSO, node U1 may decrypt the SSO using a private key associated with node U1 to provide the output addresses. The permutation of the output addresses in the final SSO may correspond to the final ordering in which the outputs are included in the targeted blockchain transaction.

[0114] In some implementations, node U1 may generate a blockchain transaction with the output addresses from the final updated SSO. Inputs from node U1 may be added to the blockchain transaction using the SIGHASH_ANYONECANPAY signature script, and any other participating nodes may iteratively add their inputs to the transaction. Node U1 may then send the transaction to the next participating node, which may check that the node's corresponding output information is correct, add its own input, sign the transaction, and forward the transaction to the next participating node. Similar operations are performed by any number of remaining participating nodes until the last participating node signs and submits the transaction to the blockchain.

[0115] It can be appreciated that when generating blockchain transactions for N participating nodes to transfer value having the same value (e.g., each of the N participating nodes transferring 10 bitcoins associated with one or more output addresses), a monitoring node can observe the input and output addresses over time and attempt to correctly associate the transfer of value with a particular transaction address.

[0116] However, when generating a blockchain transaction using a coin mixing operation in combination with the BOD operation described herein for N participant nodes, m participant nodes may choose to transfer value to multiple output addresses. The probability that the monitoring node will correctly associate an input address with the correct corresponding combination of output addresses (or a single output address) based on data mining and machine learning operations may decrease as the number of propagator outputs increases. For example, if m participant nodes may choose to transfer tokens to multiple output addresses via a blockchain transaction, Nm participant nodes may transfer value to a single output address, or m participant nodes may split the value into k amounts. Thus, the number of output addresses included in a coin mixing transaction may be:

number

number

[0117] If the transfer of value can be divided evenly, the number of possible combinations between m participants that divide the value to be transferred into k amounts may be given by:

number

number

[0118] In some implementations, the probability that a monitoring node will correctly associate one or more output addresses with a participating device may be given as follows: If the transferred value associated with a certain output address is equal to the input (maximum) amount, the probability may be given by: Pa=1 / (Nm) If the transferred value associated with an output address can be less than the input (or maximum) amount, the probability of associating that output with an input address may be given by: P1=1 / (km) If the transferred value associated with some output address can be less than the input (or maximum) amount, the probability of associating some output addresses such that the sum of the transferred values ​​is equal to the input (maximum) amount may be given by: Pk=1 / (nC) Thus, in some implementations, the probability that a monitoring node will correctly associate a single output address with a single input address may be given by:

number

number

[0119] Thus, when the BOD operations described herein are performed, the number of combinations of output addresses for transferring tokens may be greater than if the coin mixing method could be performed by itself. That is, when the BOD operations described herein are performed, the probability that a monitoring node can correctly associate one or more output addresses with input addresses may be lower than if the coin mixing method could be performed by itself. Thus, the methods described herein are directed to distributing token values ​​in a less deterministic manner to increase the overall entropy of the system and decrease the probability of associating input addresses with output addresses.

[0120] To illustrate, consider 10 participating nodes and two scenarios: (a) when an equal split of the value can be transferred, and (b) when an odd split (e.g., an unequal split) of the value can be transferred. If the propagator output for five of the participating nodes results in the token value being split into two output addresses (e.g., k=2) (e.g., splitting 10 Bitcoins into two 5 Bitcoin output addresses), and the propagator output for the remaining five participating nodes does not result in a split of the token value, then the number of combinations for N=10, m=5, and k=2 may be given as follows: (a) When equal divisions of value may be transferred:

number

number

[0121] In both instances, the number of combinations may be higher than if the transaction option were not used, and the probability that the monitoring node will correctly associate one or more output addresses with the input addresses may be lower compared to the behavior of known coin mixing methods performed by itself.

[0122] Reference is now made to FIG. 12, which graphically illustrates the number of possible combinations of output addresses as a function of the number of participants for even and odd splits, when m=N / 2, and for various values ​​of k. It can be appreciated that the greater the number of combinations, the smaller the probability that a monitoring node will be able to make the correct association. That is, in some implementations, the probability of correctly associating one or more output addresses with input addresses may be given as the inverse of the distribution shown in FIG. 12. It can be appreciated that although the odd split case may result in fewer possible combinations than the even split case, each case may provide more combinations than would be provided when performing the operation of known coin mixing systems on its own.

[0123] In Figure 12, a first curve 1210 shows the number of possible combinations of output addresses as a function of the number of participants during the operation of a known coin mixing method. A second curve 1220 shows the number of possible combinations of output addresses when an odd division of the transferred value is implemented and the transferred value can be divided into two amounts (e.g., k = 2). A third curve 1230 shows the number of possible combinations of output addresses when an odd division of the transferred value is implemented and the transferred value can be divided into three amounts (e.g., k = 3).

[0124] Additionally, a fourth curve 1240 shows the number of possible combinations of output addresses when an even division of the transferred values ​​is implemented and the transferred values ​​can be divided into two amounts (e.g., k=2). A fifth curve 1250 shows the number of possible combinations of output addresses when an even division of the transferred values ​​is implemented and the transferred values ​​can be divided into three amounts (e.g., k=3).

[0125] The operation of the Blinded Outcome Diversification (BOD) method described herein may mitigate some of the drawbacks or security risks associated with distributing token values ​​on a public ledger. The operation described herein does not rely on any centralized entity. In particular, the operation described herein does not rely on any centralized entity. i The propagator output is provided for each cycle C. i By randomly designating participating nodes as selectors for the blockchain, the operation of the BOD method may increase the entropy of the system and make any node-specific biases more randomly distributed, thereby reducing the probability that a monitoring node may utilize machine learning operations to infer patterns across multiple transactions that reveal associations between input and output addresses. It may be understood that in some implementations, the operation of the BOD method may require that the format and token split values ​​of possible message options may need to be specified prior to the initiation of operations for N cycles between participating nodes in a blockchain transaction.

[0126] In some implementations, the monitoring node may monitor the cycle C in accordance with the methods and computing apparatus described herein. iFor example, a monitoring node may be a participating node for a blockchain transaction, performing operations according to the methods described herein, or simply observing messages or ciphertexts sent from participating node to participating node. Additionally, a monitoring node may be a blockchain node, which may be a participating node in cycle C. i A participant node may not be a participant node in the blockchain. However, before a propagator output can be added to a blockchain transaction for submission to the blockchain, each participant node may sign the transaction to verify whether the output corresponding to the generated message is correct. Thus, a transaction may not be validated for submission to the blockchain unless each participant node in the multiple participant nodes signs the transaction. The impact of a monitoring node performing operations and / or observing messages / ciphertexts may be that operations performed according to each cycle may be wasted. In some implementations, to counter participants acting as monitoring nodes, participant nodes may periodically change their input and output addresses.

[0127] Reference is now made to FIG. 13 , which illustrates a simplified example of a participant node 1300 in block diagram form. The participant node 1300 may include a processor 1302, a network interface 1304, and memory 1306. The participant node 1300 may be implemented using any suitable computing hardware having network connectivity and sufficient processing and memory resources to perform the functions described herein. The participant node may include processor-executable instructions for implementing the functions described herein. In some implementations, the processor-executable instructions may be referred to as a blockchain application 1320, although it will be understood that the instructions may be implemented in one or more modules, applications, scripts, or other programming structures, depending on the hardware and operating system. The processor 1302 may include a processor, a multi-core processor, and / or multiple processors. The memory 1306 may store data, including data for the operations described herein in this exemplary implementation.

[0128] It will be understood that the apparatus and processes described herein, and any modules, routines, processes, threads, applications, or other software components implementing the described methods / processes for participating in blockchain transactions, may be implemented using standard computer programming techniques and languages, and the application is not limited to any particular processor, computer language, computer programming conventions, data structures, or other such implementation details.

[0129] It should be noted that the above-described embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, reference signs placed between parentheses shall not be construed as limiting the claims. The use of words such as "comprise" and "have" 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, "comprise" means "comprises or consists of," and "has" means "comprises or consists of." The singular reference of an element does not exclude the plural reference of such elements, and vice versa. The present invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. 1. A computer-implemented method for increasing security of blockchain-implemented transactions, in a network including a plurality of participant nodes and dealer nodes, each having its own public key and private key, the method comprising: For each cycle of the plurality of cycles, at the dealer node: ordering the participating nodes such that there is a cycle node order; designating the first node in the node order as the message originator and the last node as the propagator; By designating one of the remaining participating nodes as the selector obtaining a set of output addresses, each node not being the message originator in more than one cycle node order, each node not being the propagator in more than one cycle order, and designating one of the participating nodes as a selector node; generating, at the message originator, a ciphertext including two nested encrypted messages and sending the ciphertext to the next participating node in the node order, each message including one or more transaction details; transmitting the ciphertext from node to node in the cyclic node order, each node decrypting the ciphertext before transmitting it, and the selector further removing one of the nested encrypted messages from the ciphertext before transmitting it; decrypting the remaining single message at the propagator to obtain the one or more transaction details contained in the message; generating a shuffled order of the transaction details obtained from all cycles at all nodes designated as propagators; generating blockchain transactions, each output of the transaction based on one of the transaction details, the outputs ordered according to the shuffled order; method.

2. Each transaction details includes the transaction amount and output address.

2. The method of claim 1, wherein for each cycle, the sum of the transaction amounts in the first messages is equal to the sum of the transaction amounts in the second messages.

3. The step of generating a shuffled order comprises: in each of said propagators, encrypting each transaction detail obtained in each cycle using its public key, adding it to a shuffled set of encrypted transaction details, and shuffling the set; The method of claim 1.

4. further comprising the step of, at each of said propagators other than the last, encrypting the shuffled set using the public key of another propagator and transmitting the encrypted set to that propagator. The method of claim 3.

5. After the step of generating a shuffled order is completed on the shuffled set of encrypted transaction details: In each of said propagators: Identifying the shared public key; attempting to decrypt all transaction details in the shuffled set using the private key to obtain one or more decrypted transaction details; encrypting the decrypted transaction details with the temporary public key; The method of claim 3.

6. 6. The method of claim 5, wherein the shared public key is the public key of one of the propagators.

7. After the blockchain transaction is created: and further comprising, at each of a plurality of the participating nodes, adding an input to the blockchain transaction. The method of claim 1.

8. For each cycle, the step of generating ciphertext at each message originator comprises: generating the first message and the second message; encrypting each message sequentially using the transaction public key for that cycle and an ordered list of public keys of the other participating nodes to generate two nested encrypted messages; The method of claim 1.

9. and for each cycle, at the dealer node, providing the ordered list of the transaction public keys and node public keys for that cycle to the message originator, the ordered list being in reverse order with respect to the cycle node order. The method of claim 8.

10. for each cycle, generating, at the propagator node, a transaction public key for that cycle and a corresponding transaction private key for that cycle, and transmitting the transaction public key to the dealer node; 10. The method of claim 9.

11. 11. The method of claim 10, wherein for each cycle, at the propagator, decrypting the nested message comprises decrypting with the private key of the propagator and then decrypting with the transaction private key for that cycle.

12. A network of computing devices, each computing device being one of a plurality of participant nodes or dealer nodes, each computing device: a network interface providing network connectivity to at least one other participating node in the plurality of participating nodes; a processor; and a memory storing non-transitory computer-executable instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1 to 11. network.

Images