Partitioning requests to blockchain transactions

Abstract

In one aspect, the present disclosure proposes methods, devices, and systems for partitioning requests associated with a digital asset into an arbitrary number of transactions. The partitioning is based on knowing or obtaining the maximum number of outputs allowed for the request and an arbitrary selection of possible integer partitions of any selected integer. The randomly selected integer partitions then form the basis for determining the number of transactions and UTXOs, and the digital asset value can be arbitrarily divided across the determined UTXOs before being stored on the public blockchain. In another aspect, the present disclosure proposes methods, devices, and systems for arbitrarily distributing the digital asset value associated with a request into an arbitrary determined number of transactions. This is based on an arbitrary selected number of transactions and the maximum number of outputs allowed for each request. In another aspect, the present disclosure proposes methods, devices, and systems for generating or determining one or more public addresses associated with a given entity for use in blockchain transactions for the given entity. Such addresses can be securely and accurately associated with a given entity while maintaining the anonymity of the entity's identity.

Description

[Technical field]

[0001] The present disclosure relates generally to methods and systems for improving privacy and security of transactions associated with a distributed ledger, and is particularly, but not exclusively, suited for application in connection with the transfer of digital assets involving one or more entities using a public blockchain while preserving anonymity and improving security associated with the entities involved in the transfer. [Background technology]

[0002] Herein, we use the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, public and private blockchains, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referred to herein for convenience and illustrative purposes, but it should be noted that this disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols associated with ant-type digital assets or representations of digital assets are encompassed within the scope of this disclosure. The terms "entity," "node," "user," "sender," and "receiver" are used herein to refer to computational or processor-based resources. The term "Bitcoin" is used herein to include any protocol derived from or a variation of the Bitcoin protocol. The term "digital asset" may refer to any transferable asset, such as a cryptocurrency, a token representing at least a portion of an estate, a smart contract, a license, i.e., a software license, or a DRM contract for media content, etc. The term "digital asset" is used throughout this specification to refer to a commodity that may be associated with value that can be transferred from one entity to another or provided as payment in a transaction.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system, composed of blocks, which 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 these blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since origin. Transactions contain small programs, known as scripts, that embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform the work to ensure that invalid transactions are rejected from the network and that each transaction is valid. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing the UTXO's lock and unlock scripts. If the execution of the lock and unlock 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 be (i) validated by the first node that receives the transaction, and if the transaction is valid, the node relays the transaction to other nodes in the network; (ii) added to a new block constructed by miners; and (iii) mined, i.e., added to the public ledger of past transactions.

[0005] Once stored on the blockchain as a UTXO, a user can transfer control of the associated resource to another address associated with an input in another transaction. The transfer is typically done using a digital wallet, which may be a device, physical media, a program, an application (app) on a computing device such as a desktop, laptop, or mobile terminal, or a remotely hosted service associated with a domain on a network such as the Internet. Digital wallets can be used to store public and private keys, track ownership of resources, tokens, assets, etc. associated with a user, receive or spend digital assets, and transfer tokens, which may be related to digital assets such as cryptocurrency or licenses or property or other types of resources.

[0006] A public blockchain serves as an immutable distributed data storage system that utilizes both cryptography and economic incentives for security. Blockchain technology is widely known for its use in connection with digital assets. As mentioned above, outputs or UTXOs related to transactions are provided or stored in the blockchain. These transactions can thus be viewed or accessed by parties with access to the blockchain and typically contain details such as the public address or public key of at least one entity, as well as an indication of the value of the digital asset or assets or tokens being transferred. While some elements of the transaction can be masked or encrypted (as is typically done), the idea of ​​a public distributed ledger is that public addresses and keys etc. are used so that such transactions can be verified by nodes of the blockchain network. Thus, while immutable and verifiable / auditable distributed storage is achieved, privacy of the (contents of) transactions remains a concern for many applications and entities that utilize blockchain. Furthermore, since existing technologies are based on knowledge of the public address or public key of a given entity or entities, the identity of the entities in question, which remains anonymous, is also a concern. This is especially true when an entity receives or sends a specific value associated with a digital asset or token for multiple transactions, such as a merchant who sells one type of product for a fixed amount of cryptocurrency and always requests such fixed amount using one or more known public keys. Such entities may be subject to attacks related to spoofing, message replay, or eavesdropping that damage the security, anonymity, and privacy of the entity and associated transactions if such details can be deduced from the public blockchain by a malicious party.

[0007] The present disclosure addresses these technical concerns by proposing a technique that significantly improves the security, privacy, and anonymity associated with a given entity and the transactions related to that entity. It is based on modifying the manner and structure in which transactions related to the transfer of digital assets between entities are provided and / or stored on a public blockchain, such as the Bitcoin blockchain, by partitioning the data related to the transfer in a completely arbitrary manner. This randomness is achieved based on intermediate selections, again performed arbitrarily. Summary of the Invention

[0008] In one aspect, the present disclosure proposes a method, apparatus, and system for partitioning a request associated with a digital asset into an arbitrary number of transactions. The partitioning is based on knowing or obtaining the maximum number of outputs allowed for the request and an arbitrary selection of possible integer partitions of any selected integer. The randomly selected integer partition then forms the basis for determining the number of transactions and outputs (UTXOs) such that the digital asset value can be arbitrarily divided across the determined UTXOs before being stored on the public blockchain.

[0009] In another aspect, the present disclosure proposes methods, apparatus, and systems for arbitrarily distributing the digital asset value associated with a request into any determined number of transactions, based on any selected number of transactions and a maximum number of outputs for each request.

[0010] In another aspect, the present disclosure proposes methods, apparatus, and systems for generating or determining one or more public addresses associated with a given entity for use in blockchain transactions for the given entity, such that such addresses can be securely and accurately associated with the given entity while preserving the anonymity of the entity's identity.

[0011] Throughout this specification, the terms "comprise", "includes", "comprises", "comprising", and other variations such as "comprise" and "having" are understood to mean a stated element, integer or step, or group of elements, integers or steps, but not to exclude any other element, integer or step, or group of elements, integers or steps. [Brief description of the drawings]

[0012] Aspects and embodiments of the present disclosure are now described, by way of example only, and with reference to the accompanying drawings. [Figure 1a] FIG. 1 is a flow diagram illustrating a method for partitioning a request associated with a digital asset into any number of transactions according to a first aspect, the method being performed by one or more processors associated with a recipient of a digital asset payment. [Figure 1b] FIG. 1 is a flow diagram illustrating a method for partitioning a request associated with a digital asset into any number of transactions according to a first embodiment, the method being performed by one or more processors associated with a sender of a digital asset payment. [Diagram 2] 1 is a table showing the number of possible integer partitions for each integer k, where 1≦k≦N and N=50. [Diagram 3] FIG. 2 is a schematic diagram showing M transactions arbitrarily selected for a request relating to the first embodiment, each transaction having N outputs. [Figure 4a] FIG. 11 is a flow diagram illustrating a method for distributing the value of a digital asset associated with a request or a request over an arbitrarily selected number of transactions according to a second aspect, the method being performed by one or more processors associated with a recipient of a digital asset payment. [Figure 4b]FIG. 11 is a flow diagram illustrating a method for distributing the value of a request or a digital asset associated with the request into an arbitrarily selected number of transactions according to a second aspect, the method being performed by one or more processors associated with a sender of a digital asset payment. [Diagram 5] FIG. 2 is a schematic diagram showing M arbitrarily selected transactions generated for a given request, each associated with n outputs, 1≦n≦N. [Figure 6] FIG. 11 is a flow diagram illustrating a method for securely generating multiple public addresses of an entity for use with one or more UTXOs in a public blockchain according to a third aspect, the method being performed by one or more processors associated with a sender or receiver of a digital asset payment or a trusted third party. [Figure 7] FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure can be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] According to a first aspect, the present disclosure provides a computer-implemented method of partitioning a request associated with a digital asset into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the request, the method being performed by one or more processors associated with a recipient, which may be a computing resource or node or entity that may be associated with a digital wallet.

[0014] In some embodiments, the request may be a request for payment or a trigger or message indicating that a payment associated with a value or amount of a digital asset is requested. The method includes obtaining a maximum number of possible outputs N for a request associated with the recipient. In some embodiments, the maximum number of outputs N is predefined for the request or the recipient. In some embodiments, the maximum number of outputs N may be the overall maximum number of outputs of all transactions associated with the request. In some embodiments, the maximum number of outputs N is associated with the public address of the recipient. For example, the recipient or the recipient's wallet may determine N to be applied to all requests, or may arbitrarily select N based on one of the requests or a characteristic thereof. For example, requests for digital assets that meet a value threshold may have a different value for N when compared to requests that do not meet the threshold. Then, for each integer k, 1≦k≦N, all possible integer partitions are determined. Integer partitions are then arbitrarily selected from the possible integer partitions of the request.

[0015] The method of the first aspect includes generating one or more (M′) transaction templates Tx′ based on the selected integer partition. In some embodiments, the transaction template provided by the receiver includes all details necessary for the sender or another entity to make a digital asset payment to the receiver, such as the receiver's public key or address in the output script (UTXO), as well as the digital asset and any digital signature to be applied based on existing Public Key Infrastructure (PKI) protocols. The method includes splitting a value associated with a digital asset across outputs associated with one or more generated transaction templates Tx′ and providing the one or more generated transaction templates Tx′ for or to the sender. For example, the digital asset requested may be a cryptocurrency payment in BSV. In some embodiments, the transaction template Tx′ may be sent directly to a processor or wallet associated with the sender. In other embodiments, the template may be sent to a payment service associated with the sender, or may be stored in a blockchain, or distributed ledger, for retrieval.

[0016] In some embodiments, the method includes receiving one or more completed transactions Tx based on the one or more generated transaction templates Tx' from the sender. The receiver can then submit the completed transactions to the distributed ledger. In some embodiments, this submission may be performed after known methods of validation using PKI techniques.

[0017] Advantageously, the above-described method of the first aspect allows for complete randomization of the process of requesting digital asset payments by using a similar technique of providing transaction templates or output scripts to receive digital assets. The arbitrary selection from any number of possible partitions significantly reduces the probability that these transactions will be traced or associated with a particular entity, thereby improving the privacy of the corresponding transactions when posted on the blockchain. Advantageously, this method also improves the anonymity of the recipient and also provides more security against malicious parties considering an attack by eavesdropping to identify or intercept the recipient's transactions on the blockchain. This may be to observe patterns in the transaction output addresses or digital asset values ​​or known distributions associated with the request. This inference by a malicious party by observing the blockchain becomes extremely difficult if a random number of transaction templates and outputs are given for a single request from the recipient entity. The method also provides security against MITM or message replay attacks, where a malicious party poses as either the sender or the recipient along the way and modifies or intercepts some of the data between the two corresponding parties. This is because it becomes difficult to associate a template with a given entity or node based on an arbitrarily generated transaction template.

[0018] The method of the first aspect may be implemented by one or more processors associated with the sender, or a third party entity associated with the sender that may in some cases provide services to implement the method of the first aspect of the present disclosure. In this case, the sender executes the method in response to receiving a request or trigger to make a digital asset payment associated with the recipient. In some embodiments, the request may be received from the recipient, or may be automatically generated by one or more processors or a digital wallet associated with the sender following an indication of intent to purchase one or more goods or services from the recipient. The method described above obtains a maximum number of possible outputs (N) for a request associated with the recipient. For each integer k, 1≦k≦N, a possible integer partition is determined, where the integer partition is arbitrarily selected from the possible integer partitions determined for the request. The sender generates one or more transactions Tx based on the selected integer partition. The method then includes dividing a value associated with the digital asset across outputs associated with one or more generated transactions, each output being associated with a public address or public key associated with the recipient.

[0019] The above method differs from the method of the first aspect implemented by the receiver by not requesting a transaction template but directly generating a transaction for said request that can be provided to a public blockchain. The sender implements the method to make a payment to a receiver entity, so no template is required. The above method of the first aspect, when implemented by a sender, provides all the advantages of the first aspect described above, and further provides advantages when it allows or enables providing such partitions to one or more receivers or nodes that may not be able to generate the above transaction template or may not have the resources to do so. Also, in many commercial supply chains, the sender may be a large entity that buys from smaller suppliers. In this scenario, the sender may implement the method as a payment security service to smaller, less computationally advanced suppliers or receivers. Furthermore, by making the method executable by a processor at the sender end or receiver end, interoperability for digital asset payments can be achieved based on one or more requirements specified for the receiver entity.

[0020] In some embodiments, a recipient or sender may be an entity associated with or implemented by one or more computing resources, user terminals, or applications associated with the computing resources. In some embodiments, typically, each (sender or recipient) entity may be associated with a digital wallet, or may be an entity associated with a digital wallet, such as a user terminal having a digital wallet or an application for a digital wallet installed. Although aspects and embodiments of the present disclosure relate to a digital wallet of a recipient entity or sender entity, it should be understood that entities that do not have a digital wallet or a separate application for it, but are configured to provide functionality to operate as or with or similar to a digital wallet, are also within the scope of the present disclosure. For ease of explanation only, the following description relates to recipients and senders, and the present disclosure is not limited to entities having digital wallets.

[0021] When implemented by a sender, in some embodiments, the method of the first aspect further comprises generating or determining one or more public addresses associated with the recipient based on the selected integer partition, a given public address among the one or more public addresses being assigned to a given output of a given transaction Tx among the one or more generated transactions. In cases where the recipient is a computationally non-sophisticated entity, this embodiment advantageously enables the generation of a public address for securely receiving a payment to be made at a different entity, such that the recipient and transaction template can benefit from improved security, privacy and anonymity.

[0022] In some embodiments, when performed by the sender, the method includes sending one or more generated transactions Tx to the receiver. In some embodiments, the generated transactions may include a digital signature associated with the sender that is verifiable at the receiver end. This is advantageous because it places the onus of submission to the blockchain on the receiver, who knows the completed transaction for payment requests. In other embodiments, the generated transactions Tx can be submitted to the distributed ledger by the sender. As a result, UTXOs are posted to the blockchain, and therefore visible, rather than being sent to the receiver.

[0023] The following embodiments relate to a first aspect of randomly partitioning requests into any number of transactions and / or outputs on a blockchain, and relate to the method when implemented by a Receiver or a Sender. As mentioned above, the embodiments relating to generating transaction templates relate to Receiver implementations, and those relating to generating transactions relate to Sender implementations.

[0024] In an embodiment, the number of transaction templates M' or the number of generated transactions M is based on the number of integers in the selected integer partition. In some embodiments, the number of outputs in a given transaction template Tx' or generated transaction Tx is based on the value of the integer in each position in the selected integer partition associated with the given transaction Tx or template Tx'. For example, if N=5, and the arbitrarily selected integer partition associated with integer k=3 is 2+1, this means that there are two transactions / templates TxID1 and TxID2, where TxID1 has two outputs for the recipient and TxID2 has one output. This embodiment is further described in detail with respect to Figures 1a and 1b.

[0025] Advantageously, the above embodiments further specify implementation details of how the structure and granularity of transactions and outputs are arbitrarily selected based on knowing only one value, namely, the maximum number N of outputs for a request associated with a recipient. Outputs are associated with the recipient's public key or address.

[0026] In some embodiments, the method further comprises determining a maximum number M' of transaction templates allowed for the request or the recipient. max or the maximum number of transactions M max obtaining the signal from the input device;

[0027] This advantageously ensures processing resource optimization, thereby reducing the overhead of having too many transactions, while still benefiting from the improved security, privacy, and anonymity provided to recipients by the random partitions of the first aspect.

[0028] In some embodiments, the method further comprises determining a minimum number M' of transaction templates for the request or the recipient. min or the minimum number of transactions M min and / or the minimum number of outputs, N min obtaining the signal from the input device;

[0029] This advantageously avoids the possibility of significant trivial integer partitions that could result in a transaction that looks and behaves like a normal or existing blockchain transaction, such as having a single transaction with one output.

[0030] In some embodiments, each output in a given transaction template Tx′ or generated transaction Tx is associated with a different public address of the recipient node, said public address being unique to each output.

[0031] This advantageously ensures that each output is associated with a different public key or address of the recipient, which helps improve security and anonymity for the recipient, as transactions for the same recipient and the same request will appear more random and unrelated to a malicious party observing and attempting to identify a particular request or recipient's transactions.

[0032] The method of the first aspect, when performed by a recipient, is executed by one or more processors of a sender entity for completing a digital asset payment, comprising obtaining or identifying one or more transaction templates Tx' associated with the request, the templates Tx' associated with the recipient and generated according to the method of the first aspect and related embodiments when performed by the recipient, completing the one or more templates Tx' to generate a corresponding blockchain transaction Tx for the payment, and providing the corresponding transaction Tx to the sender for submission to the blockchain or alternatively submitting the corresponding transaction to the distributed ledger.

[0033] When the method of the first aspect is implemented by a sender, the method is executed by one or more processors of a recipient of a digital asset payment and includes providing the associated request to the sender. In some embodiments, this may be a separate message or indicator sent on-chain or off-chain to the sender. The method includes receiving one or more completed transactions Tx from the sender, the one or more completed transactions being generated according to the method of the first aspect and an embodiment thereof when implemented by the sender, and then submitting the completed transactions to the distributed ledger.

[0034] According to a second aspect, the present disclosure provides a computer-implemented method of distributing a request across one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the request, the method being performed by one or more processors associated with a recipient. The method includes obtaining a value L associated with the request, the value representing a digital asset requested by the recipient. The method includes obtaining a predetermined number M' of transaction templates associated with the request, the M' templates Tx' being associated with a predetermined maximum number N of outputs associated with the request or the recipient, a given transaction template Tx' among the M' transaction templates Tx' having n outputs, n≦N. In some embodiments, the obtaining step is based on the method of the first aspect when performed by the recipient to obtain N and M'. The method of the second aspect then includes obtaining n-1 value partitions U of the value L. (i=1to(n-1)) and sorting the n-1 value partitions in ascending value order, (1) (2) <… (n-1) <L、ここで、U (0) =0 and U (n) = L. The method includes the step of: i =U (i) -U (i-1) , i=1 to n, the value X of a given transaction among the predetermined number M′ of transaction templates (i=1 to M') The method includes the step of calculating:

[0035] ​​​In addition to the advantages discussed for the first aspect, the method of the second aspect advantageously further improves privacy and the opportunity for recipients to remain anonymous. In the above-described method of the second aspect, arbitrarily dividing the value of the digital asset into random denominations for inclusion in a large number of arbitrarily generated transactions makes it difficult for an observer or malicious party to associate a blockchain transaction with a recipient based on knowledge or inference of the value of the digital asset or the denomination normally or previously used to receive digital asset payments associated with the recipient. This also further improves the security of transactions on the blockchain, as it becomes very difficult for a malicious party to infer or calculate any meaning or source identity from looking for a value in the output of a given transaction in the blockchain.

[0036] In some embodiments, the method of the first aspect and the method of the second aspect may be combined and performed by the recipient, and the splitting step of the first aspect may be performed by a step of the second aspect.

[0037] The method of the second aspect may be implemented by a single-site processor associated with a sender, in response to receiving a request or trigger to make a digital asset payment associated with a recipient, in which case the method, when implemented by the sender, includes obtaining a value L associated with the request, the value representing a digital asset, and obtaining a predetermined number M of transactions associated with the request, where M transactions Tx are associated with a predetermined maximum number N of outputs for the request or the recipient, a given transaction Tx among the M transactions Tx having n outputs, where n≦N.

[0038] In some embodiments, the obtaining step, when implemented by the sender, is performed based on a method for partitioning requests across multiple transactions and outputs as described in the first aspect. As discussed with respect to the first aspect, the sender implementation differs from the receiver implementation in that no transaction template Tx' is required if it is the sender that partitions requests to the receiver. The method of the second aspect obtains n-1 value partitions U of the value L. (i=1to(n-1)) and sorting the n-1 value partitions in ascending value order, (1) (2) <… (n-1) <L、ここで、U (0) =0 and U (n) The method includes the step of: where the difference Xi between each (i-th) value partition and the previous value partition in sorted order is Xi=U (i) -U (i-1) , i=1 to n, the value X of a given transaction among the predetermined number M of transactions (i=1 to M) The method includes the step of calculating:

[0039] The sender implementation provides the same advantages associated with the second aspect as described above for the receiver implementation. Moreover, similar to the first aspect, such implementation advantageously allows a computationally non-sophisticated receiver to ensure that the privacy, security, and anonymity of the payment transaction intended for it can still be achieved from another entity that can enforce any partitioning to the transaction on its behalf.

[0040] ​​​According to a second aspect, the present disclosure provides a computer-implemented method of generating a plurality of public keys associated with a recipient, each public key being associated with one or more blockchain transaction outputs (UTXOs) for one or more transactions associated with the recipient, the method being implemented by one or more processors, which may be associated with either a sender or receiver of a digital asset payment, or a trusted third party. The method generates a private key S associated with the recipient. B and based on a code C, which in some embodiments may be a chain code, associated with the recipient, a parent public key P B The method includes obtaining a plurality of (n) child public keys P Bi(i=1 to n) where each (i-th) child public key is a respective derived child secret key S Bi(i=1 to n) In a third aspect, each derived child public key P Bi represents a derived public address unique to one or more blockchain transaction outputs (UTXOs) that may be associated with the recipient.

[0041] In some embodiments, the parent public and / or private keys are compressed, hex-encoded, stable elliptic curve digital signature algorithm (ECDSA) keys, i.e., valid points on the secp256k1 curve. In this case, in some embodiments, the parent public key P B , P B =S B G, where G is an origin or base on the elliptic curve of the Bitcoin generator, or where G is a known constant. In some embodiments, the corresponding (i-th) child public key and child secret key can then be derived based on the above using a secure hash algorithm. This derivation is described below with respect to FIG. 6.

[0042] Advantageously, the method according to the third aspect allows the secure generation of a large number of public addresses represented by a public key that is linked to a given entity. In the above case, this is the receipt of payments of digital assets. This is because these addresses are linked to a parent key (S B ) and the code (C), ensuring that the address can be easily identified or determined on the blockchain by the recipient. This is particularly advantageous when identifying arbitrarily partitioned transactions on the blockchain based on the request in the first and / or second aspects. The address derived according to the third aspect can be used in the output associated with the transactions generated for the partitioned request. This then advantageously provides a mechanism that allows these arbitrarily generated transactions to be effectively linked to a common factor, namely the recipient. This is particularly useful when an authorized party wants to determine which of the partitioned transactions relate to the recipient. This can be done by deriving and looking up the address based on the methods described above.

[0043] In some embodiments, hardening of the child key pair can also be implemented as an additional security feature when such derivation needs to be limited to the recipient only. Advantageously, when the child is hardened, knowledge of the child private key and the chaincode C is not sufficient to reconstruct the parent's private key. Only the recipient has access to the parent private key S. B Since the recipient knows the address, no entity other than the recipient can construct a child address.

[0044] In embodiments where the child key pair is not hardened, the public key P BAnd any entity with knowledge of the chaincode C can construct a derived child address on behalf of the recipient (e.g., the sender or a trusted third-party entity). This ensures that transactions related to an arbitrarily partitioned request can be determined, since other entities, when securely provided with the above details, can also construct public addresses in a way that links them to the recipient. This can be a useful backup mechanism to determine transactions associated with the recipient if the recipient itself turns out to have been compromised or attacked by a malicious party.

[0045] In some embodiments, the derivation of the linked public address according to the third aspect may be based on a message m associated with a request. This request may relate to requests partitioned in the first and second aspects. In such a case, the derivation of the address also requires knowledge of the message m. Details of how this derivation works.

[0046] In addition to the advantages discussed above for the third aspect, this embodiment allows the recipient or another entity to identify all public addresses that can be used for a particular request m on the blockchain based on the parent private key and the code C. If the chaincode C is shared, another entity, such as the sender, can also use it to derive the public addresses. Furthermore, the request m hash may also be transmitted or stored by a trusted third party or authority (along with the recipient's parent public key) for archival purposes, such as for disaster recovery purposes, or to provide an additional layer of security in case the recipient node is attacked or compromised by a malicious party. This is because the derivation based on m provides a verifiable link of all transactions associated with the request from the recipient.

[0047] In some embodiments, the code C is a chain code that is secret or private to the recipient, and the chain code C is optionally a secure hash of a secret seed associated with the recipient, in which case only the recipient can execute the method of the third aspect to derive the recipient's public address or request.

[0048] In some embodiments, the code C is a chaincode shared with another entity, where the other entity is the sender of a digital asset associated with the request to the recipient, or the other entity is a trusted third party associated with the recipient or the sender, in which case a public address can be derived by the other party as well as the recipient.

[0049] In some embodiments, the code C is associated with a secret S shared by the recipient and another entity, where the secret S is a parent public key P of the sender and the recipient. A and P B The shared secret S may be shared between the recipient and another entity based on a known or predefined secure key exchange protocol based on S. In some embodiments, the shared secret S may be encrypted.

[0050] In addition to all the above advantages discussed for the third aspect, the key derivation based on a shared secret common to both the sender and the receiver ensures that all blockchain transactions linked to a given sender of a given message m associated with the receiver are identified and verified if necessary. Furthermore, if the derived public key is not hardened, the sender can also determine and verify transactions based on the derived public key of the receiver of a given message m.

[0051] In some embodiments, a computing device is provided that includes a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform the aspects and / or embodiments described above.

[0052] In some embodiments, a non-transitory computer readable storage medium is provided having executable instructions stored thereon that, when executed by a processor of a computer system, cause the computer system to perform a method of any of the aspects and / or embodiments described above.

[0053] Several specific embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numbers indicate like functionality, and in which:

[0054] First aspect - Receiver implementation 1a is a flow chart illustrating a method of partitioning a request according to a first aspect of the present disclosure, the request being associated with a digital asset associated with a distributed ledger implemented by one or more processors associated with a recipient.

[0055] For example, for illustration only and to aid, consider a scenario where a sender (A or Alice) purchases a good or service from a receiver (B or Bob). The receiver Bob then sends a request to the sender for 3BSV. The request in this scenario is in the form of a transaction template Tx'. A transaction template Tx' becomes a transaction once Bob enters some of the outputs and Alice enters hers. An existing form of the template may be roughly as follows: [Table 1]

[0056] In the above transaction template, Bob has one output address associated with him, P, with an output value of 3 BSV. B1 is inserted.

[0057] In this scenario, Alice has her address P A1Suppose she has one UTXO with a value of 4 BSV at . She then inserts this into the input of a transaction template, and in the output, she writes it to her other address P A2 She sends herself 1 BSV in change (balance) at . The transaction is now complete and is roughly given by: [Table 2]

[0058] The above illustrates a typical transaction based on a request, which may be an invoice or a message, requesting payment of a digital asset, such as BSV or any other cryptocurrency. For clarity and ease of reference herein, reference is made hereinafter to BSV, although the disclosure is not limited thereto.

[0059] As mentioned above, if a malicious party observing a transaction infers from the value of 3BSV that Bob normally charges, or from the public key representing the public address Bob normally uses to receive payments for goods, the malicious party can infer Bob's identity, thereby compromising Bob's anonymity and the privacy of the transactions associated with Bob, and possibly Alice's as well, especially if Alice purchases the same goods from Bob at regular intervals using the same public address, as these public addresses and keys are masked on the blockchain. Once the identity of the transaction is known, the malicious party can also compromise the overall security, as they can perform eavesdropping attacks by listening or collecting information related to Bob for malicious purposes. An example of this is a message replay attack, where an attacker eavesdrops, obtains a copy of a message or transaction, and later reuses the message in an attempt to fool the encryption protocol used to make it seem like the message or transaction originated from the original merchant or recipient, i.e., Bob. A malicious party can also perform a man-in-the-middle attack by impersonating a genuine party and tampering with messages or transactions.

[0060] A first aspect of the present disclosure overcomes the above-mentioned shortcomings of lack of anonymity, privacy, and security associated with existing transactions for payment requests from Bob (and thus the recipient of digital assets) by modifying the structure of a transaction template Tx', as discussed below with respect to Figure 1a when implemented by one or more processors of the recipient or the recipient's wallet (Bob's wallet).

[0061] Step 102a shows obtaining the maximum number of possible outputs N for a request associated with the blockchain associated with Bob, i.e. the maximum number of public addresses associated with Bob for a given request. This may be preset for requests associated with all digital assets, or for actual transactions associated with Bob, or may be optionally set to a different number for each request. In some embodiments, it is also possible to obtain a maximum or minimum number of transactions allowed, or a minimum number of transactions and subsequent outputs allowed, to control the granularity of transactions submitted to the blockchain. However, this is not required. The maximum number of outputs N is the only basic parameter required for the recipient.

[0062] Step 104a indicates checking, for a given integer k, whether 1≦k≦N. If this condition is true, the method proceeds to step 106a. Otherwise, the method proceeds to step 112a.

[0063] Step 106a shows determining possible integer partitions for each integer k, where 1≦k≦N.

[0064] An integer partition is a distinct combination of (unordered) numbers that, when added together, gives k. For example, the integer partitions for k=3 and k=4 are:

number

[0065] It can be seen that there are 3 possible integer partitions of 3, and 5 possible integer partitions of 4.

[0066] The number of integer partitions does not scale linearly. The table in Figure 2 lists the number of possible partitions for each integer k, k≦50.

[0067] Steps 108a and 110a show that step 106a is performed incrementally for each integer k, for the next k=k+1, as long as k+1≦N.

[0068] Step 112a shows the step of randomly selecting an integer partition n from the possible integer partitions determined for the request. Thus, in this step, either a single integer partition is selected or chosen uniformly at random from all possible partitions for each k, with 1≦k≦N. For example, if we consider N=4, a partition is selected from all partitions with k being 1, 2, 3, and 4. From the table in FIG. 2, this means that we can choose from 5+3+2+1=11 possible partitions. In this example, for a selected integer k=4, the selected integer partition, chosen completely randomly, is 2+2. In this case, we also have k=N, as the maximum number of outputs.

[0069] Step 114a illustrates the generation of one or more, namely M', transaction templates Tx' based on the integer partition selected in step 112a, namely 2+2. The number M' of generated transaction templates is based on the number of integers in the selected integer partition, and the number of outputs in a given transaction template Tx' among the M' generated transaction templates Tx' is based on the value of the integer at each position in the selected integer partition. This step describes the generation of M' transaction templates Tx' with a total of n actual outputs in each template Tx, where n≦N, based on the selected integer partition. This therefore results in M' transaction templates, each transaction template having a total of n outputs, where n≦N. Continuing with the example above, the actual number n of outputs in each transaction for recipient Bob is n=2 for both TxIDs. Thus, the arbitrarily selected partitions are n1+...+n m= n, where n is an integer k corresponding to the selected integer partition, m = M' transaction templates, 1 ≤ m ≤ n ≤ N. Thus, each term is n i This is interpreted as defining a transaction that has n outputs. That is, m=M' transaction templates are constructed, and the i-th transaction or transaction i has n i outputs, with 1≦i≦m, which are generally and diagrammatically shown in FIG.

[0070] In the above example, there are 2 integers in the selected partition, which means there are 2 transaction templates generated for the request, so the selected partition is 2+2, which means M=2. This also means that each of the templates has 2 actual outputs, n, where each output is associated with Bob (the recipient). In some embodiments, each of these outputs is associated with a public key P, which represents Bob's public address. b , and in some embodiments each address is distinct from Bob's other addresses. Techniques for securely deriving an entity's public key are detailed below with respect to the third aspect of this disclosure in conjunction with FIG.

[0071] Step 116a illustrates dividing the value associated with the digital asset across outputs associated with one or more generated transaction templates Tx' from step 106a above. In the above example, this value is 3BSV. A method for arbitrarily dividing the value and distributing it across four outputs (two in each transaction TxID1 and TxID2) is detailed below with respect to FIG. 4a and the second aspect of the present disclosure. Now, assume that a value of 3BSV is arbitrarily divided, where M'=2 for an arbitrary selected partition 2+2, the actual number of outputs n=2 for each of the M' templates, and k=N=4, and the M' transaction templates Tx' from step 114a are shown diagrammatically as given below for the same request. That is, a payment of 3BSV is requested from Alice. [Table 3] [Table 4]

[0072] Thus, instead of one output address for the payment in one transaction to Bob, this step results in the generation of M'=2 transaction templates for the request, each with two outputs, each associated with a different public address of Bob, all matching the N=4 condition.

[0073] Step 118a shows providing the sender (Alice) with one or more generated transaction templates Tx' generated by Bob in the previous step. Although not shown in FIG. 1a, sender Alice may wish to use multiple addresses of her own for the transaction templates if necessary, and thus complete the transaction templates for the request to generate a completed transaction on the blockchain. However, in this embodiment, the maximum number of outputs N is related to the receiver's outputs and does not include Alice's outputs. A completed transaction with N=4 for receiver addresses / outputs, i.e., meeting the requirements set by the receiver for the request, is shown below. Here, for a payment of 3BSV from Alice to Bob, Bob uses k=N=4 addresses and Alice uses 8 addresses. [Table 5] [Table 6]

[0074] Compared to standard existing transactions associated with payments of digital assets on a public blockchain, the above-mentioned arbitrarily selected M′ transactions, having N or fewer arbitrarily selected outputs for Bob, make it much more difficult for a single invoice to be identified on the public blockchain and attributed to Alice or Bob.

[0075] Depending on the nature of the interaction, Alice may give the completed transaction to Bob, who submits it to the blockchain or distributed ledger. In an alternative implementation, Alice may submit the transaction to the network herself. Either way, both partitions may check that the transaction is received and verified by miners, and ultimately mined into the blockchain. The verification and mining process is beyond the scope of this disclosure and will not be discussed here. However, known techniques of validating, submitting, and mining transactions for a blockchain may be used and are therefore contemplated for aspects and embodiments of the present disclosure.

[0076] First Aspect - Sender or Trusted Third Party Implementation 1b is a flow chart illustrating a method of partitioning a request according to a first aspect of the present disclosure when implemented by one or more processors associated with the sender, i.e., Alice, for the above-mentioned exemplary scenario of paying 3 BSV to Bob (the recipient). As discussed above, implementation of the method of the first aspect by one or more processors associated with the sender, or indeed a trusted third party, which partitions the request, resulting in the request being split across multiple transactions and outputs, is advantageous for computationally less sophisticated recipients who are not capable of handling the processing associated with implementing the method themselves. For ease of reference, implementation by one or more processors or digital wallets associated with the sender will be discussed herein.

[0077] At step 102b, a request for payment is received from or on behalf of the recipient. In the example above, this may be a notice or message that Alice is being charged 3 BSV for goods or services purchased from Bob by Alice. In some embodiments, the request may represent an invoice.

[0078] Steps 104b to 114b are performed by sender Alice in the same manner as described for steps 102a to 112a, respectively, but performed by the sender, and therefore these steps are not repeated here again to avoid repeating the same concepts of the first aspect.

[0079] Step 116b shows generating one or more transactions Tx based on the selected integer partition. This step is similar to the implementation discussed with respect to 114a, but instead of M′ transaction templates, the sender implementation can directly generate M transactions for the request, since in this implementation no input or template is sent from the receiver, as also described above in the related embodiment associated with the first aspect. In some embodiments, the method also includes deriving one or more public addresses or public keys associated with the receiver Bob. A process for securely performing such derivation by the sender or a trusted third party is discussed with respect to the third aspect of FIG. 6.

[0080] In steps 118b and 120b, splitting the value associated with the digital asset across the outputs associated with one or more generated transactions is performed in the manner discussed in steps 116a and 118a, respectively, but performed by the sender. Once the M completed transactions are generated, the sender can submit them to a public blockchain or send them in a secure manner to the recipient for submission to the blockchain.

[0081] Second aspect - Receiver implementation 4a is a flow chart illustrating a method for distributing a value associated with a request across multiple transaction outputs according to a second aspect of the disclosure. The request is associated with a digital asset. Following the same scenario described with respect to the first aspect, the digital asset is BSV and has a value of 3. In this figure, the method is performed by one or more processors or digital wallets associated with the recipient (Bob). In some embodiments, the method of the second aspect is used to perform the step of splitting the transaction value in step 116a.

[0082] Step 402a illustrates obtaining a value L associated with the request, where the value represents a digital asset such as, but not limited to, BSV.

[0083] Step 404a illustrates obtaining a predefined number M' of transaction templates associated with the request. As described with respect to the first aspect, each transaction template Tx' is associated with a predefined maximum number N of outputs related to the request, the outputs being associated with a recipient. In some embodiments, this step is related to follow from or include steps 102a-114a of FIG. 1a to obtain M' transaction templates. Each of the M' transaction templates has n actual outputs associated with Bob, the recipient, where n≦N.

[0084] Step 406a selects n-1 value partitions U of the value L. (i=1to(n-1)) Thus, if N is 4, then 3 partitions of values ​​are randomly generated, i.e., L=3 in this case. This can be in any unit, such as 0.1 or 0.5.

[0085] In some embodiments, the step of randomly generating n-1 numbers, in conjunction with both the sender and receiver implementations, may include steps of: -8uniformly randomly generate n-1 numbers with precision (U1, U2, …, U N-1 ∈(0,1).

[0086] Advantageously, the method of the second aspect can accommodate different metrics and units of precision based on the cryptocurrency and digital assets to be transferred. In the above embodiment, a metric based on satoshis to BSV (Bitcoin Satoshi Vision) is presented, with the smallest unit being 1 satoshi-10. -8 In BSV, a satoshi is the smallest unit of approximately 0.00000001 BSV. Ethereum or Ripple may have different precision metrics.

[0087] In step 408a, the n-1 value partitions are sorted in ascending value order starting from 0 (1) (2) <… (n-1) <L、U (0) =0 and U (n) = L. Other sort orders may be considered, or the order may be random.

[0088] Step 410a calculates, for each given transaction template among a predetermined number M′ of transaction templates, a value X (i=1 to M') This value is calculated based on the difference between each (i-th) value partition and the previous value partition in sorted order. This is X i =U (i) -U (i-1)、 Represented by i = 1 to n.

[0089] Step 412a illustrates forming a completed transaction, including the calculated value of X, to complete each template and sending the completed transaction to the sender or submitting the completed transaction to the blockchain.

[0090] ​​​Considering the example above, following partitioning the claim into any number of transactions and outputs using the method of the first aspect, the value of the claim can then be arbitrarily divided using the method of the second aspect, resulting in the claim being divided into M=2 transactions, each having n=2 outputs, and the total number of outputs N associated with the recipient being no more than 4, as discussed above.

[0091] Thus, following the above example of a request for 3 BSV, rather than a single transaction with one address of recipient Bob, consider now the situation where Alice spends 4 BSV in the input, Bob receives 3 BSV in the output, and Alice gets 1 BSV in change. This situation is shown diagrammatically in Figure 5 of the accompanying drawings. As mentioned above, each of these component transactions, rather than a single transaction, is submitted to the blockchain to ensure that a malicious party cannot easily infer the intended identity of the transaction associated with such a request by looking closely at the public key or BSV value in the transaction.

[0092] Second aspect - Sender implementation 4b is a flow chart illustrating a method of distributing the value of a claim according to the second aspect of the disclosure when implemented by one or more processors associated with the sender, i.e., Alice, for the above-mentioned example scenario of paying 3 BSV to Bob (the recipient). As mentioned above, implementation of the method of the second aspect by one or more processors associated with the sender, or indeed a trusted third party, which distributes the value of the claim, resulting in the claim being split across multiple transactions and outputs, is advantageous for computationally less sophisticated recipients who are not capable of handling the processing associated with implementing the method themselves. For ease of reference, implementation by one or more processors or digital wallets associated with the sender will be discussed herein.

[0093] At step 402b, a request for payment is received from or on behalf of the recipient. In the example above, this may be a notice or message that Alice is being charged 3 BSV for goods or services purchased from Bob by Alice. In some embodiments, the request may represent an invoice.

[0094] Steps 404b to 414b are performed by the sender Alice in the same manner as described in steps 402a to 412a, respectively, but by the sender. However, in the sender implementation, instead of M' transaction templates Tx', M transactions Tx can be generated directly for the request in the sender implementation. This was also described above in the related embodiment associated with the second aspect. This is because, in this implementation, no inputs or templates are sent from the receiver. Therefore, these steps are not repeated here again to avoid repeating the same concepts of the first aspect.

[0095] Third aspect FIG. 6 is a flow chart illustrating a method for generating multiple public keys associated with a recipient. Each public key represents a public address of the recipient. Once generated, the public keys can then be associated with one or more blockchain transaction outputs (UTXOs) of one or more transactions associated with the recipient. The method of the third aspect may be performed in some embodiments together with the methods of the first and second aspects. For example, the steps of generating a transaction Tx or a transaction template Tx′ in FIGS. 1a and 1b (steps 114a and 116b, respectively) require that a public address be provided in the transaction / template. The method of the third aspect may be used to derive such a public address associated with a recipient entity. As a result, a payment can be sent to the recipient. As mentioned above, using the method of the third aspect to derive the public address / public key of an entity allows a transaction on a public blockchain to be securely and accurately associated or linked to a given entity. In many cases, this is the recipient entity, but the method is not so limited. Similar techniques can be implemented by the sender entity or indeed by a third party entity as a service provided to the recipient or sender.

[0096] In FIG. 6, step 602 involves obtaining a private key S associated with the recipient. B Based on the code C, the parent public key P B In some embodiments, the code C is associated with a recipient. In some embodiments, the parent public and private keys may be compressed, hex-encoded, ECDSA keys, i.e., valid points on the secp256k1 Bitcoin curve. However, other blockchains may use other types of curves. Also, keys such as ECDSA keys are not required. The parent keys can be generalized to any public / private key pair with homomorphic properties. Thereby, S Bi +S Bi+1 and the corresponding public key is P Bi +P Bi+1That is, homomorphic encryption allows computations on the ciphertext to produce encrypted results that, when decrypted, match the results of the operations as if they had been performed on the plaintext.

[0097] Step 604 is to generate multiple (n) child public keys P Bi(i=1 to n) , where each child public key is a respective derived child secret key S Bi(i=1 to n) Each derived child public key P Bi represents a derived public address that is unique to one or more blockchain transaction outputs (UTXOs) associated with the recipient. This derivation can be permuted in a number of different but related ways, as explained in the steps below. B , P B =S B Derived based on G, which is the generator or base point on the elliptic curve of the Bitcoin generator in the case of ECDSA keys, or G is a known constant.

[0098] Step 606 illustrates one embodiment of deriving a public key or address of the entity based on the derivation of the child private key and the code C. In this embodiment, the code may be a constant that is private to the recipient or shared with the sender or another entity.

[0099] In this embodiment, for a given child secret key S Bi The corresponding (i-th) child private key of P Bi =P B +L i The corresponding child key pair is derived by G. B1 =S B1 G,…,P Bn =S Bn Given by G.

[0100] Following this computation, a given (i-th) child private key is derived by:

number

[0101] where index i is a 32-bit integer and HMAC represents a hash-based message authentication code computation function, which may be based on a known secure hash algorithm.

[0102] This embodiment thus allows the derivation of an entity's public address based on knowledge of the secret or shared code C and the parent secret key. The code may be a chaincode. Optional strengthening of the child key pair is an additional security feature. If the child is strengthened, knowledge of the child private key and the chaincode is not sufficient to reconstruct the parent's private key. Only the recipient knows the secret or private key S B If the child key pair is not hardened, then the public key P B And any entity with knowledge of the chaincode C can construct a derived child key on behalf of the receiver (e.g., the sender, if necessary).

[0103] Step 608 illustrates an embodiment in which in addition to the code C, which may be a chain code or a constant, the message m related to the information or data item of the request is also used for the derivation, which has the additional advantage of determining the public address of the recipient entity that is linked to the given message.

[0104] Once the requested data item, i.e., the data item or message m associated with the recipient, is obtained, the i-th derived private child key P Bi(i=1ton) is S Bi =S B +HMAC256(L i ,m) mod n.

[0105] The corresponding public key P Bi P Bi =P B +HMAC256(L i,m) · G, where G is the origin or base on the elliptic curve of the Bitcoin generator or G is a known constant, m represents the message or data item associated with the request, and the request is related to a digital asset.

[0106] Step 610 illustrates an embodiment in which the code C is in fact a secret S shared by the recipient and another entity, where the other entity is the sender of the digital asset associated with the recipient or a trusted third party associated with the recipient or sender. In some embodiments, the secret S is a parent public key P of the sender and the recipient. A and P B The key is shared between the recipient and another entity based on a known or predefined secure key exchange protocol, namely the Diffie-Hellman exchange, based on

[0107] In this embodiment, the i-th child private key is derived by:

number

[0108] Here, the index i is a 32-bit integer, and HMAC represents a hash-based message authentication code computation function.

[0109] The corresponding public key P Bi is given by:

number

[0110] This embodiment ensures that all transaction templates associated with a recipient and linked to a given sender of a given message m must be able to be identified and verified. Furthermore, if the derived public key is not hardened, the sender or key-shared party can also determine and verify transactions based on the derived public key of the recipient of a given message m.

[0111] In all of the above embodiments of the third aspect, a party other than the recipient to derive the recipient's public address provides a useful backup if the recipient is compromised. If a trusted third party can also derive the address, this can also act as additional validation, or as disaster recovery or backup if the recipient and / or sender are compromised.

[0112] Referring to FIG. 7, an illustrative simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the illustrated systems described above. For example, the computing device 2600 may be configured to be used as one or more components of the illustrated DBMS. Alternatively, the computing device 2600 may be configured to be a client entity associated with a given user, which makes database requests to a database managed by the DBMS of FIG. 6. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 7, the computing device 2600 may include one or more processors with one or more levels of cache memory and memory controllers (collectively labeled 2602) that may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and a persistent storage device 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read only memory (ROM) 2620 as shown. The storage subsystem 2606 and cache memory 2602 may be used for storage of information such as details associated with transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0113] The processor 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0114] Bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is illustrated generally as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0115] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616, in some embodiments, may act as an interface to receive data from and transmit data to other systems in the computing device 2600. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that the data technician can send data to and receive data from the device without being in a remote location, such as a data center.

[0116] User interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computing device 2600.

[0117] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device, etc. The display subsystem may include a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a flat-panel device such as a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface and facilitate user interaction with applications that perform the processes and transformations described herein, when such interaction is appropriate.

[0118] The storage subsystem 2606 may provide a computer-readable storage medium that stores basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (e.g., programs, code modules, instructions) that, when executed by one or more processors, provide the functionality of one or more embodiments of the present disclosure may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 also provides a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage device 2610 may provide permanent (non-volatile) storage of programs and data and may include a magnetic hard disk drive, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, or DVD, or Blue-Ray) drives associated with removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments described in this disclosure, and data associated with the transactions and blocks described in this disclosure.

[0119] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device that can be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. The device may thus be configured to convert optical signals into electrical signals that are transmitted to the computing device 2600 through the ports connecting the devices for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 7 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 7.

[0120] <Enumerated exemplary embodiments> The present disclosure will now be discussed based on the following sections related to the above-mentioned aspects, which are provided as exemplary embodiments to better explain, describe and understand the aspects and embodiments claimed herein. (Item 1) A computer-implemented method for partitioning claims associated with digital assets into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the claims, the method being performed by one or more processors associated with a recipient, the method comprising: obtaining a maximum number (N) of possible outputs for a request associated with said recipient; determining possible integer partitions for each integer k, where 1≦k≦N; randomly selecting an integer partition from the possible integer partitions determined for said request; generating one or more (M') transaction templates Tx' based on the selected integer partition; splitting a value associated with the digital asset across outputs associated with one or more generated transaction templates Tx'; providing said one or more generated transaction templates Tx' to or for a sender; The method includes: (item 2) receiving from the sender one or more completed transactions Tx based on the one or more generated templates Tx'; submitting the completed transaction to the distributed ledger; Item 1. The method according to item 1, further comprising: (Item 3) A computer-implemented method for partitioning a request into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the request, the method being performed by one or more processors associated with a sender, the method comprising: in response to receiving the request from a recipient, obtaining a maximum number (N) of possible outputs for a request associated with the recipient; determining possible integer partitions for each integer k, where 1≦k≦N; randomly selecting an integer partition from the possible integer partitions determined for said request; generating one or more transactions Tx based on the selected integer partition; dividing a value associated with the digital asset across outputs associated with one or more generated transactions, each output being associated with a public address associated with the recipient; The method includes: (Item 4) The method of item 3, further comprising generating or determining one or more public addresses associated with the recipient based on the selected integer partition, wherein a given public address among the one or more public addresses is assigned to a given output of a given transaction Tx among the one or more generated transactions. (Item 5) The method of any one of items 3 or 4, further comprising a step of sending the one or more generated transactions Tx to the sender or submitting the generated transactions Tx to the distributed ledger. (Item 6) The method of any one of items 1 to 5, wherein the number of transaction templates M' or the number of generated transactions M is based on the number of integers in the selected integer partition. (Item 7) A method according to any of items 1 to 6, wherein the number of outputs in a given transaction template Tx' or generated transaction Tx is based on the value of an integer at each position in a selected integer partition associated with the given transaction Tx or template Tx'. (Item 8) A method according to any of items 1 to 7, wherein a maximum number of outputs N is predetermined for either the request or the recipient, and the N outputs are associated with a public address associated with the recipient. (Item 9) The maximum number M' of transaction templates allowed for the request or the recipient. max or the maximum number of transactions M max 9. The method according to any one of items 1 to 8, further comprising the step of obtaining: (Item 10) A minimum number M' of transaction templates for the request or the recipient min or the minimum number of transactions M min and / or the minimum number of outputs, N min 10. The method according to any one of items 1 to 9, further comprising the step of obtaining. (Item 11) A method according to any of items 1 to 10, wherein each output in a given transaction template Tx' or generated transaction Tx is associated with a different public address of a recipient node, the public address being unique to each output. Item 12. A computer-implemented method for partitioning requests associated with digital assets into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the requests, the method being performed by one or more processors associated with a sender, the method comprising: obtaining or identifying one or more transaction templates Tx' associated with the request, the templates Tx' being associated with a recipient and generated according to the method according to any one of claims 1, 2, 6 to 11; completing said one or more templates Tx' to generate corresponding transactions Tx; providing the corresponding transaction Tx to the sender or submitting the corresponding transaction to the distributed ledger; The method includes: Item 13. A computer-implemented method for partitioning claims associated with digital assets into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the claims, the method being performed by one or more processors associated with recipients, the method comprising: providing the associated request to a sender; receiving one or more completed transactions Tx from the sender, the one or more completed transactions Tx being associated with a receiver and generated according to the method according to any one of the methods described in paragraphs 3 to 11; submitting the completed transaction to the distributed ledger; The method includes: (Item 14) A computer-implemented method of distributing a request across one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the request, the method being performed by one or more processors associated with a recipient, the method comprising: obtaining a value L associated with the request, the value representing a digital asset; obtaining a predetermined number M' of transaction templates associated with the request, the M' transaction templates Tx' being associated with a predetermined minimum number N of outputs related to the request or the recipient, a given transaction template Tx' among the M' transaction templates Tx' having n outputs, n≦N; A partition U of n-1 values ​​of L (i=1to(n-1)) and optionally generating Sorting the n-1 value partitions in ascending value order, (1) (2) <… (n-1) <L、U (0) =0 and U (n) = L, and For a given transaction template among the predetermined number M′ of transaction templates, the difference X between each (i-th) value partition and the previous value partition in storage order i =U (i) -U (i-1) , i=1 to n, based on the value X (i=1 to M') and calculating The method includes: (Item 15) The method according to Item 14, wherein the acquiring step includes the method according to any one of Items 1, 2, and 6 to 11. (Item 16) The method described in Item 1, wherein the dividing step includes the method described in Item 14. ​​​(Item 17) A computer-implemented method for distributing a request across one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the request, the method being performed by one or more processors associated with a sender, the method comprising: in response to receiving the request from the recipient, obtaining a value L associated with the request, the value representing a digital asset; obtaining a predetermined number M of transactions associated with the request, the M transactions Tx being associated with a predetermined maximum number N of outputs related to the request or the recipient, a given transaction ten Tx among the M transactions Tx having n outputs, n≦N; A partition U of n-1 values ​​of L (i=1to (n-1)) and optionally generating Sorting the n-1 value partitions in ascending value order, (1) (2) <… (n-1) <L、U (0) =0 and U (n) = L, and For a given transaction among the predetermined number M of transactions, the difference X between each (i-th) value partition and the previous value partition in storage order i =U (i) -U (i-1) , i=1 to n, based on the value X (i=1 to M) and calculating The method includes: (Item 18) The method according to Item 15, wherein the acquiring step includes the method according to any one of Items 3 to 11. (Item 19) The method described in Item 3, wherein the dividing step includes the method described in Item 17. (Term 20) The step of randomly generating n-1 numbers is 10 -8 uniformly randomly generate n-1 numbers with precision (U1, U2, ..., U N-1 ​​​20. The method according to any one of claims 14 to 19, comprising the step of: ∈(0,1). 21. A computer-implemented method for generating a plurality of public keys associated with a recipient, each public key being associated with one or more blockchain transaction outputs (UTXOs) of one or more transactions associated with the recipient, the method being implemented by one or more processors, the method comprising: A private key S associated with the recipient B Based on the code C, the parent public key P B and obtaining Multiple child public keys P Bi(i=1 to n) wherein each child public key is associated with a respective derived child secret key S Bi(i=1 to n) Based on this, each derived child public key P Bi represents a derived public address unique to one or more blockchain transaction outputs (UTXOs) associated with the recipient; and The method includes: (Item 22) The method described in Item 21, wherein the recipient is an entity intended to receive the digital asset, and the code C is a code associated with the recipient. (Item 23) A method according to any one of items 19 or 20, wherein the parent public and / or private keys are stable Elliptic Curve Digital Signature Algorithm (ECDSA) keys. (Section 24) The parent public key P B 24. The method of claim 23, wherein G is derived based on, where G is a generator or base point on the elliptic curve of the Bitcoin generator, or G is a known constant. (Section 25) Given a child secret key S Bi The corresponding (i-th) child private key of P Bi =P B +L i The corresponding child key pair is derived by P B1 =S B1 G,...,P Bn =S Bn The method according to claim 24, wherein the formula is given by G. (Item 26) A given (i-th) child private key is derived by:

number

number

number

number

number

[0121] It should be noted that the above-mentioned aspects and embodiments illustrate, rather than limit, the present disclosure, and that those skilled in the art can devise many alternative embodiments without departing from the scope of the present disclosure, which is defined by the appended claims. In the claims, any reference signs in parentheses shall not be construed as limiting the claims. The terms "comprising" and "including" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "having or consisting of" and "comprising" means "comprising or consisting of". A singular reference of an element does not exclude a plural reference of such an element. Vice versa. The present disclosure 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 means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage.

Claims

1. 1. A computer-implemented method for partitioning requests associated with digital assets into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the requests, the method being performed by one or more processors associated with a recipient, the method comprising: obtaining a maximum number (N) of possible outputs for a request associated with said recipient; determining possible integer partitions for each integer k, where 1≦k≦N; randomly selecting an integer partition from the possible integer partitions determined for said request; generating one or more (M') transaction templates Tx' based on the selected integer partition; splitting a value associated with the digital asset across outputs associated with one or more generated transaction templates Tx'; providing said one or more generated transaction templates Tx' to or for a sender; The method includes:

2. receiving from the sender one or more completed transactions Tx based on the one or more generated templates Tx'; submitting the completed transaction to the distributed ledger; The method of claim 1 further comprising:

3. 1. A computer-implemented method for partitioning a request into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the request, the method being performed by one or more processors associated with a sender, the method comprising: in response to receiving the request from a recipient, obtaining a maximum number (N) of possible outputs for a request associated with the recipient; determining possible integer partitions for each integer k, where 1≦k≦N; randomly selecting an integer partition from the possible integer partitions determined for said request; generating one or more transactions Tx based on the selected integer partition; dividing a value associated with the digital asset across outputs associated with one or more of the generated transactions, each output being associated with a public address associated with the recipient; The method includes:

4. 4. The method of claim 3, further comprising generating or determining one or more public addresses associated with the recipient based on the selected integer partition, wherein a given public address among the one or more public addresses is assigned to a given output of a given transaction Tx among the one or more generated transactions.

5. 5. The method of claim 3, further comprising the step of transmitting the one or more generated transactions Tx to the sender or submitting the generated transactions Tx to the distributed ledger.

6. The method according to any of claims 1 to 5, wherein the number M' of transaction templates or the number M of generated transactions is based on the number of integers in the selected integer partition.

7. 7. The method of claim 1, wherein the number of outputs in a given transaction template Tx' or generated transaction Tx is based on the value of an integer in each position in a selected integer partition associated with the given transaction Tx or template Tx'.

8. The method according to any of claims 1 to 7, wherein a maximum number N of outputs is predefined for either the request or the recipient, the N outputs being associated with a public address associated with the recipient.

9. The maximum number M' of transaction templates allowed for the request or the recipient max or the maximum number of transactions M max The method according to any one of claims 1 to 8, further comprising the step of obtaining:

10. A minimum number M' of transaction templates for the request or the recipient min or the minimum number of transactions M min and / or the minimum number of outputs N min The method according to any one of claims 1 to 9, further comprising the step of obtaining:

11. The method of any of claims 1 to 10, wherein each output in a given transaction template Tx' or generated transaction Tx is associated with a different public address of a recipient node, said public address being unique for each output.

12. 1. A computer-implemented method for partitioning a request associated with a digital asset into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the request, the method being performed by one or more processors associated with a sender, the method comprising: obtaining or identifying one or more transaction templates Tx' associated with the request, the templates Tx' being associated with a recipient and generated according to the method of any one of claims 1, 2, 7 and 11; completing said one or more templates Tx' to generate corresponding transactions Tx; providing the corresponding transaction Tx to the sender or submitting the corresponding transaction to the distributed ledger; The method includes:

13. 1. A computer-implemented method for partitioning requests associated with digital assets into one or more transactions associated with a distributed ledger, each transaction having one or more outputs associated with the requests, the method being performed by one or more processors associated with a recipient, the method comprising: providing the associated request to a sender; receiving one or more completed transactions Tx from the sender, the one or more completed transactions Tx being associated with a recipient and generated according to a method according to any one of claims 3 to 11; submitting the completed transaction to the distributed ledger; The method includes:

Images