Patent Application
20240388575
This disclosure relates generally to computer-implemented methods and systems suitable for exchanging transactions off-chain before submission of the transactions and their diffusion over a blockchain network. The disclosure is particularly suited, but not limited, to use with the Bitcoin blockchain.
In this document we use the term ‘blockchain’ to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin may be referred to herein for the purpose of convenience and illustration, it should be noted that the disclosure is not limited to use with the Bitcoin blockchain and alternative blockchain implementations and protocols fall within the scope of the present disclosure.
A blockchain is a consensus-based, electronic ledger which is implemented as a computer-based, decentralised, distributed system made up of blocks which in turn are made up of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. Each block contains a hash of the previous block to that blocks become chained together to create a permanent unalterable record of all transactions which have been written to the blockchain since its inception. Transactions contain small programs known as scripts embedded into their inputs and outputs, which specify how and by whom the outputs of the transactions can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.
In order for a transaction to be written to the blockchain, it must be “validated”. Some network nodes act as miners and perform work to ensure that each transaction is valid, with invalid transactions rejected from the network. For example, software clients installed on the nodes perform this validation work on transactions that reference unspent transaction outputs (UTXO). Validation may be performed by executing its locking and unlocking scripts. If execution of the locking and unlocking scripts evaluate to TRUE and, if certain other conditions are met, the transaction is valid and the transaction may be written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) validated by a node that receives the transaction-if the transaction is validated, the node relays it to the other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e. added to the public ledger of past transactions. The transaction is considered to be confirmed when a sufficient number of blocks are added to the blockchain to make the transaction practically irreversible.
Although blockchain technology is most widely known for the use of cryptocurrency implementation, digital entrepreneurs have begun exploring the use of both the cryptographic security system Bitcoin is based on and the data that can be stored on the Blockchain to implement new systems. It would be highly advantageous if the blockchain could be used for automated tasks and processes which are not limited to the realm of cryptocurrency. Such solutions would be able to harness the benefits of the blockchain (e.g. a permanent, tamper proof record of events, distributed processing, etc.) while being more versatile in their applications.
One area of research is the use of the blockchain for the implementation of “smart contracts”. These are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike a traditional contract which would be written in natural language, a smart contract is a machine executable program which comprises rules that can process inputs in order to produce results, which can then cause actions to be performed dependent upon those results.
Blockchains which provide an open, public ledger make available to any interested parties the ability to trace the movement of specific digital coins, digital assets, or control of digital resources across a sequence of addresses. While the ledger being open and distributed is useful in acting as a means to trust the system, the ability it gives for tracking transactions across addresses allows for digital assets related to specific historical transactions to be analysed and correlated. To address this issue, security and anonymization solutions have been developed. This can be useful as many real-world commercial transactions are confidential in nature, either for legal reasons, commercial reasons, or both. Accordingly, blockchain systems must be capable of ensuring both security and confidentiality for such commercial transactions despite the public nature of the blockchain.
Although the use of pseudonyms in the Bitcoin cryptocurrency protocol is often thought of as being an enabler of anonymous payments, the success of a variety of research in uncovering user identities has shown that anonymity within the Bitcoin network is not so easily achieved. Given that the demand for anonymity remains, the present disclosure proposes a variety of technical solutions based on implementing a plurality of or a combination of type of transactions for effecting one or more digital asset payments transfers off chain in a secure manner, thereby improving the levels of security as well as anonymity available for cryptocurrency protocols or protocols for transfer of digital assets between one or more computing resources, at both application and network layers.
According to a first aspect of the disclosure as described herein there is provided a computer-implemented method for exchanging blockchain transactions between n>2 participants and subsequently broadcasting the blockchain transactions over a blockchain network for storage on a blockchain, the computer-implemented method comprising:
Advantageously, the method of the first aspect presents a way for multiple blockchain users to exchange their transaction before diffusion over the blockchain network in order to blur the link between the IP address of the transaction generated by a user and the user's blockchain address in the transaction.
The method provides a technical solution to exchange transactions directly off-chain. Participants in the method agree to make deposits and alter their transaction in such a way that a refund and compensation scheme put in place automatically relies on the confirmations in the blockchain of the transactions exchanged among participants thus providing increased security as well as anonymity. The method scales for an arbitrary number (n>2) of participants.
The technical advantages are provided by defining the above-mentioned plurality of distinct types of transactions to be set up, i.e. deposit, refund, compensation, main transaction etc., and the manner in which they interact with each other. The present disclosure herein also discusses the structure for each of these types of transaction, and the key exchange mechanism between the participants. In some embodiments, a sequence of such types of transactions that provide intermediate results enables the off-chain exchange to take place accurately and securely, while preserving anonymity in relation to the IP or network end points associated with the participants. Furthermore, as discussed below, specific mechanism for computing one or more cryptographic keys for encrypted channels and/or signatures and/or blockchain addresses are proposed for ensuring these advantages. Accordingly, and advantageously the present disclosure, particularly the claimed aspects and embodiments, propose a secure, accurate and scalable technique for implementing one or more transactions that may be associated with digital assets, i.e. cryptocurrency or tokens, off-chain before it is provided to a distributed ledger.
The generating and exchanging of cryptographic keys and associated blockchain addresses between participants may comprise the following:
Furthermore, one of the blockchain addresses (αi) created by each participant may require a signature from both the participant (Ui) and another participant (Ui+1). Furthermore, one of the blockchain addresses (βi) created by each participant (Ui) may require only a signature from another participant (Ui−1).
The aforementioned options provide an example of how suitable cryptographic keys and associated blockchain addresses can be generated and exchanged for subsequent use in the transaction exchange, refund and compensation scheme.
Each participant Ui may also generate a private-public key pair (yi, Qi) and publish the public key. This enables the participants to communicate with each other via an encrypted channel using the key pair (yi, Qi ) when implementing the transaction exchange, refund, and compensation scheme.
The one or more deposit transactions can be constructed such that outputs of the one or more deposit transactions are shuffled or randomized relative to inputs of the one or more deposit transactions. The participants make their deposit in a common deposit transaction or alternatively each participant can create an individual deposit transaction. The deposit transactions can be Pay To Script Hash (P2SH) deposit transactions. Furthermore, each deposit can be constructed such that it is sent to one of the blockchain addresses generated and exchanged by the participants or, after a time ΔTE, to a blockchain address of the participant who made the deposit if their blockchain transaction is not confirmed on the blockchain. Further still, the deposit transaction for the participants is constructed by one of the participants.
The aforementioned options provide an example of how one or more suitable deposit transactions can be generated to implement the transaction exchange, refund and compensation scheme.
Modifying each of the blockchain transactions to be exchanged can comprise locking the refund output under the public key provided by another participant and the modified transaction is signed and sent to the other participant. Each participant Ui can construct their refund transaction Rxi using for inputs the output in the one or more deposit transactions (i.e. the output Oi locked by participant Ui in the deposit transaction) and the refund output sent to the public address βi−1 in the blockchain transaction Txi−1 generated by participant Ui−1 such that participant Ui's refund will inherently depend on them submitting participant Ui−1's blockchain transaction Txi−1 for inclusion into the blockchain. The two inputs in the newly created transaction Rxi can thus require the signature of Ui and Ui−1 as follows:
Following the above, participant Ui can send their refund transaction Rxi to participant Ui−1 who signs it and sends it back to participant Ui who also then signs the transaction Rxi.
The aforementioned options provide an example of how suitable refund transactions can be generated to implement the transaction exchange, refund and compensation scheme.
Each participant Ui can construct their compensation transactions Cxi using the output sent to Oi+1 in the one or more deposit transactions and participant Ui sends the newly created transaction Cxi to participant Ui+1 who signs it and return it to participant Ui where input x (Oi+1) in Cxi requires the signature of both Ui and Ui+1. The compensation transactions can have outputs which are locked for a time ΔTS that defines the maximum time allowed for the participants to broadcast the exchanged blockchain transactions and see these confirmed on the blockchain network.
The aforementioned options provide an example of how suitable compensation transactions can be generated to implement the transaction exchange, refund and compensation scheme.
Broadcasting the compensation transactions and the blockchain transactions can comprise each participant Ui broadcast two transactions Cxi and Txi−1 in that order. This ensures the compensation transaction is in place prior to broadcast of the main blockchain transaction.
Broadcasting the refund transactions upon confirmation of the blockchain transactions on the blockchain can comprise each participant Ui broadcasting refund transaction Rxi thereby claiming their deposit. Furthermore, a participant may only claim the unspent output in the compensation transaction when their blockchain transaction is not confirmed on the blockchain after a time ΔTS. This methodology is consistent with providing compensation transactions having outputs which are locked for a time ΔTS that defines the maximum time allowed for the participants to broadcast the exchanged blockchain transactions and see these confirmed on the blockchain network.
Embodiments of the present disclosure can be provided in a variety of forms. For example, a computer readable storage medium can be provided which comprises computer-executable instructions which, when executed, configure one or more processors to perform the method as described herein. An electronic device can also be provided which comprises: an interface device; one or more processor(s) coupled to the interface device; and a memory coupled to the one or more processor(s), the memory having stored thereon computer executable instructions which, when executed, configure the one or more processor(s) to perform the method as described herein. A node of a blockchain network can also be provided, the node configured to perform the method as described herein.
These and other aspects of the present disclosure will be apparent from and elucidated with reference to, the embodiments described herein. Embodiments of the present disclosure will now be described, by way of example only, with reference to the accompany drawings in which:
As previously indicated in the background section, although the use of pseudonyms in the Bitcoin cryptocurrency protocol is often thought of as being an enabler of anonymous payments, the success of a variety of research in uncovering user identities has shown that anonymity within the Bitcoin Network is not so easily achieved. Given that the demand for anonymity remains, a variety of technical solutions have been developed that improve on the levels of anonymity available for cryptocurrency protocols at both application and network layers.
This specification presents an extension of a Direct Transaction Exchange (DTE) protocol to n>2 participants. A DTE protocol offers a solution to exchange transactions directly off-chain before submission of the transactions and their diffusion in the Bitcoin network. Participants in the DTE protocol agree to deposit some coins and alter their main transaction in such a way that the refund and compensation scheme put in place relies on the confirmations in the blockchain of the transactions exchanged among participants. In the present specification it is described how to scale a DTE protocol to an arbitrary number (n>2) of participants.
The Internet Protocol (IP) address(es) associated with a cryptocurrency user may be used to compromise Bitcoin network anonymity. Indeed, a malicious adversary may link a public key to an IP address and track all transactions submitted by a user. Moreover, IP information may be used to retrieve the real user's identity by combining this information with other sources, e.g. internet forums and social media. In such circumstances, generating multiple public-private key pairs for different sets of transactions or participating in mixing services as expedients to increase the anonymity of the operations may not be successful [1].
De-anonymization attacks are typically carried out using a “super node”, which connects to active Bitcoin nodes and monitors the transactions transmitted. Symmetric diffusion over the network allows for a 30% success rate in IP-public key linking [2]. The algorithms used mainly exploit peer-to-peer (P2P) graph structure and information about the diffusion.
By tracking the Bitcoins' or other cryptocurrencies' flow, monitoring the public ledger one may link multiple addresses generated by the same user. This result can be achieved by analysing the transaction graph and clustering together addresses.
Anonymous relay tools such as Tor [3] offer identity protection, but still exhibit weaknesses and possible downsides. Indeed, relay systems may be vulnerable to traffic analysis, whereby the user's “first-hop” link to Tor and the “last-hop” link from Tor to the user's communication partner may be traced and used to correlate packets. Moreover, attack may cause denial of service as well as put the users' anonymity at risk.
Biryukov, et al., [2] present a method to de-anonymise P2P networks, by linking the users' pseudonyms with their IP addresses. This solution relies on the set of nodes a client connects to, which uniquely determine the client identity and the origin of the transaction.
In this specification we propose a protocol to enforce the users' anonymity at the network layer by allowing Bitcoin users to exchange their transactions before their diffusion on the network, thus blurring the link between the IP address of the transaction generated by a user and the user's Bitcoin address in the transaction. As detailed in this specification, the n-DTE protocol relies on a deposit of coins made by the participants, and the alteration of their main transaction in such a way that the refund and compensation scheme put in place relies on the confirmation in the blockchain of the transactions exchanged among participants.
In its simplest form [4], we considered two participants in the DTE protocol. Both participants generate a Main Transaction that they wish to exchange before submission for inclusion in the Bitcoin blockchain. In order to do so and ensure that both participants fulfil their roles and are protected in case the protocol is interrupted before completion, the participants must commit funds in a deposit transaction and alter their original transaction so that their refund is conditioned by the confirmation of the exchanged transactions on the network.
We propose to scale that protocol to n>2 participants. The different steps in the n-DTE protocol are detailed herein. We first describe key generation and exchange between participants. We then construct a Deposit Transaction using the keys and addresses newly generated. We describe the alteration of the Main Transactions being exchanged between the participants. We then construct Refund and Compensation schemes of the protocol. Finally, we describe the transactions exchange between, and broadcast by, the participants.
Given a set of n individuals {Ui|i∈[0, n−1]} participating in the n-DTE protocol to exchange their Main Transaction, the participants create and exchange public keys in the following way:
Each participant Ui generates one extra (ephemeral) private-public key pair: (yi, Qi) and publishes the public key.
The participants are randomised to realise an ordered set {U0, U1, . . . , Un−2, Un−}. The participants can communicate with their neighbours via encrypted channel using the ephemeral key pair made public (yi, Qi).
Each participant Ui exchanges the two public keys, Pi1 and Pi2, with their two closest neighbours. As an example U0 exchanges P01 and P02 with U1 and Un−1 while U1 exchanges P11 and P12 with U0 and U2.
Each participant Ui creates a pair of Bitcoin addresses using their public keys and the ones provided by her neighbours [here we show the Bitcoin public keys generated by a participant; the Bitcoin address A associated to a public key P is given by A=RIPEMD160(SHA256(P))]:
As an example, U0 creates the following two addresses:
The addresses generation is illustrated in
The funds sent to the address derived from αi will require a signature from both Ui and Ui+1 using their first private keys, respectively ki1 and ki+11.
The funds sent to the address derived from βi will require a signature from Ui−1 using the private key associated to the new public key, given by: ki−12+H(ki−12×Pi2). Although it is easy for the participant Ui to create and share the public key with Ui−1, only the latter can deduce the private key and therefore sign a transaction's UTXO sent to the address derived from βi.
The participants can then exchange their newly created public keys/addresses and verify their validity knowing the public keys used to construct these. In summary, the participant Ui creates 2 addresses and knows of 2 addresses shared with his left-hand neighbour Ui−1, and 2 addresses shared with his right-hand neighbour Ui+1 as illustrated in
Note that the participant Ui does not know the private key associated to the public key βi he or she created. On the other hand, only Ui knows the private key associated to the public key βi+1 created by his right-hand neighbour Ui+1.
Recall that the goal of this protocol is for the n participants to exchange their transaction before broadcast on the blockchain. We will denote Main Transactions as these transactions being exchanged in the following.
In order to incentivise the participants to complete the n-DTE protocol and to protect honest participants from malicious ones, we propose that each participant deposit an arbitrary amount of Bitcoin whose refund is conditioned on the successful completion of the required tasks by the participant.
Such deposit can be made in various ways. For instance, the participants can all make their deposit in a common Bitcoin transaction, or each participant can create his/her individual deposit transaction (although this would imply more fees paid to the miners overall). In the following, we consider a common transaction to collect the participants' deposit. This choice implies the use of a shuffling technique to blur the link between the inputs and the outputs in the said transaction.
The n participants creates a n-input/n-output P2SH Deposit Transaction, denoted Dx in the following, where they all commit an amount of x Bitcoin agreed beforehand.
The UTXOs from Dx will be used later in the protocol to create two sets of transactions:
Participant Ui constructs the script Li locking his/her deposit in Dx. This script will offer two options to spend the associated output amount x Bitcoin:
We will denote Oi the output (parameter set) generated by the participant Ui:Oi:{Li,x}. An example of the locking script for the deposit of x Bitcoin made by Ui is shown in
One participant is responsible for gathering all the outputs and crafting the Deposit Transaction Dx. In the following we will designate U0 as the participant collecting the set of outputs and the first participant to add his/her input and sign it in Dx. To protect the participants in the n-DTE protocol from external attack, the set of outputs is encrypted using the participants' public key Qi before being transferred from one participant to another. To blur the link between inputs and outputs in Dx, we consider that each participant will shuffle the set of outputs before passing on to his/her right-hand neighbour. This way the inputs order will not match that of the outputs in Dx. Alternatively, we could randomise the order of participants during the signing phase.
The outputs shuffling process, based on the CircleShuffle protocol [WP0388], begins when the first participant, U0 , encrypts his/her output O0 with the next participant public key Q1. The encrypted output address then comprises the ‘set of shuffled outputs’ (SSO). U0 passes the SSO to U1. U1 decrypts the SSO, using her private key y1 adds her output, shuffles the outputs and encrypts the SSO using Q2, and forwards it to U2. This process, illustrated for 4 participants in
After Un−1's output address is added to the SSO, Un−1 performs a final shuffle, encrypts the SSO with Q0, and sends the SSO back to the first user, U0. This permutation of the output addresses in the SSO represents the final order in which the outputs are included in the Deposit Transaction Dx.
U0 decrypts the SSO, using her private key y0 and creates the Deposit Transaction Dx. U0 adds his/her input, signs the transaction and forwards Dx to the next participant. Each participant on seeing the inclusion of his/her chosen output in the transaction, adds and signs his/her input with a SIGHASH_ANYONECANPAY flag. After all participants have signed Dx, the transaction is submitted by the last participant for inclusion into the blockchain.
{U0, U1, U2, U3}={Alice, Bob, Carol, Dave}.
We change the indices i={0,1,2,3} into i={A, B, C, D} when referring to our illustration with 4 participants.
Upon seeing the Deposit Transaction Dx confirmed on the blockchain, the participants can now enter the next phase of the protocol that is the exchange their Main Transaction as detailed below. If they have not completed the exchange and broadcast of the Main Transactions before ΔTE they will collect their deposit of x Bitcoin in Dx and the protocol will finish.
The n-DTE protocol relies on a Refund and Compensation mechanism destined to incentivise the participants to complete the Main Transactions exchange and broadcast on the Bitcoin Network. Such mechanism can be achieved by constraining the refund of the coins locked in the Deposit Transaction committed by the participants in such way that the refund for a participant is only available after he or she broadcasts the Main Transaction issued by another participant. To do so, we propose to alter a Main Transaction by adding an extra output used in the Refund Transaction of the participant in charge of broadcasting the said Main Transaction.
Although we do not wish to restrict the format/structure of the participants' Main Transaction (number of inputs/outputs aside the dust, amount transfer, locking script), we argue that the transactions should have similar size for uniformity purposes. The amount spent by a participant should remain arbitrary although bigger than the fees for miners involved in this protocol. In the following, we assume for simplicity that each participant wishes to transfer an arbitrary amount of Bitcoin from one address to another using Pay-to-Public-Key scripts. In our illustration in
The participants agree on a dust amount d of Bitcoin—a few satoshis—and add an extra output to their Main Transaction. Generally, we will denote Txi the Main Transaction generated by the participant Ui for i={0,1,2,3} or i={A, B, C, D} in our illustration with 4 participants.
As an example, the first participant U0 (or Alice in the illustration) alters her Main Transaction Tx0 (or TxA), by adding a second output with d as the output amount and locked under a Pay-To-Public-Key script using the public key created earlier by U1 (or Bob): β1=P12+c0,1×G (or βB=PB2+cA,B×G). Alice signs her transaction TxA and forwards it to Bob. Generally, the participant Ui signs his/her transaction Txi and sends it to her neighbour Ui+1.
This process continues until each participant has received the transaction of their closest neighbour to the left.
At this point, the participants do not broadcast the received Main Transaction on the network. They first prepare the refund and compensation scheme:
The participant Ui is now in possession of the Main Transaction Txi−1 generated by his/her left-hand neighbour Ui−1. As illustrated in
The participant Ui creates his/her Refund Transaction, namely Rxi, using for inputs the UTXO sent to Oi in the Deposit Transaction Dx and the dust sent to βi−1 in the Main Transaction Txi−1 generated by Ui−1. This way, Ui's refund will inherently depend on him/her submitting Ui−1's Main Transaction Txi−1 for inclusion into the blockchain. Ui sends his/her newly created Refund Transaction Rxi to Ui−1 who partially signs it (using ki−11) and return it to Ui. Note that the two inputs in this newly created transaction Rxi require the signature of Ui and Ui−1 as follows:
A Compensation Transaction is created to account for the case where one participant does not broadcast another participant's Main Transaction. In our example, if Bob does not broadcast Alice's Main Transaction TxA, Alice should be compensated for Bob's misconduct. Alice therefore creates a Compensation Transaction CxA that takes as input the x Bitcoin spent by Bob (OB) in the Deposit Transaction Dx. The output in the transaction CxA contains a LockTime value ΔTS agreed upon by all the participants in the n-DTE protocol, that should reflex the maximum time allowed for the participants in the protocol to broadcast the Main Transactions and see these confirmed on the network. Alice sends CxA to Bob who verifies it, signs it and sends it back to Alice.
Generally, a participant Ui creates his/her own Compensation Transaction using the UTXO sent to Oi+1 in the Deposit Transaction Dx. Ui sends the newly created transaction Cxi to Ui+1 who signs it and return it to U ¿. Note that the input x (Oi+1) in Cxi requires the signature of both Ui and Ui+1 using their first private keys, respectively kli1 and ki+11.
With the refund and compensation scheme in place, each participant Ui can now broadcast the following two transactions on the network: Cxi and Txi−1, in that order. Upon confirmation of Txi−1 on the blockchain the participant U¿ broadcasts Rxi, effectively claiming his/her deposit. If Ui does not see his/her Main Transaction Txi confirmed on the network after an elapsed time ΔTS he/she can spend the UTXO in the Compensation Transaction Cxi, effectively claiming the deposit made by Ui+1. On the other hand if Ui sees his/her Main Transaction confirmed in the blockchain before ΔTS, Ui+1 would have rightfully broadcast Rxi+1, thus invalidating Cxi, since the UTXO Oi+1 included in both Cxi and Rxi+1 would already have been spent.
The n-DTE protocol relies on a secure way to exchange public information between n participants. The participants in the protocol exchange their public keys and create 2-of-2 multi-signature addresses and new public keys using the Diffie-Hellman secret share scheme. They also exchange their Main Transactions for broadcast, as well as the other transactions (Refund and Compensation Transactions) generated in the protocol for signature.
Although not explicitly mentioned we recommend using each public key only once when generating (public key-based and multi-signature) addresses used in the transactions built in the n-DTE protocol, in order to blur the link between the different transactions generated in the protocol.
Additionally. we advocate for encrypting each message (public keys, transactions, addresses) sent between the participants using the public key of the message receiver.
Each participant Ui will send up to three transactions on the network:
Although an attacker might succeed in linking the addresses used in these transactions with the IP address of the user Ui, the desired effect to blur the link between the user's address of the transaction's author and the user's IP address is achieved as the Main Transaction is not sent to the network by its original author. An external attacker could gain enough knowledge to reconstruct the links between the transactions and their original author if the order of outputs in the deposit transaction Dx revealed the order of participants in the protocol. Mainly for that reason, we describe a method to shuffle the outputs in Dx to blur the link between the inputs and outputs in Dx. Alternatively, as we mentioned previously, the deposit made by the participant could be done in individual deposit transactions.
This specification presents an n-Direct transaction Exchange protocol (n-DTE) which offers a solution to exchange transactions directly off-chain before submission of the transactions and their diffusion in the network. This aims at blurring the link between the IP address of the transaction generated by a user and the user's bitcoin address in the transaction, therefore enforcing the anonymity of the user on the network.
The transactions exchange is achieved by adding a dust amount of Bitcoin into the Main Transactions output and constructing Refund Transactions that include this dust as well as a deposit made by the participants. This allows the participants to claim their deposit after they broadcast another participant's Main Transaction.
A Compensation scheme is also put in place to compensate a participant whose Main Transaction would not have been submitted for inclusion into the blockchain during the allocated time in this protocol.
Turning now to
As shown in
The processor(s) 2602 can 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.
A bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.
The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface for receiving data from, and transmitting data to, other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network such that the data technician may be able to transmit data to the device and receive data from the device while in a remote location, such as a data centre.
The user interface input devices 2612 may include one or more user input devices such as a keyboard; pointing devices such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen incorporated into the display; audio input devices such as voice recognition systems, microphones; 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 to the computing device 2600.
The one or more user interface output devices 2614 may include a display subsystem, a printer, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), light emitting diode (LED) display, or 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 user interfaces to facilitate user interaction with applications performing processes described and variations therein, when such interaction may be appropriate.
The storage subsystem 2606 may provide a computer-readable storage medium for storing the basic programming and data constructs that may provide the functionality of at least one embodiment of the present disclosure. The applications (programs, code modules, instructions), when executed by one or more processors, may provide the functionality of one or more embodiments of the present disclosure, and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by the one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and cache memory 2602 can provide volatile storage for program and data. The persistent storage 2610 can provide persistent (non-volatile) storage for program and data and may include flash memory, one or more solid state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g. CD-ROM or DVD or Blue-Ray) drive with associated removable media, and other like storage media. Such program and data can include programs for carrying out the steps of one or more embodiments as described in the present disclosure as well as data associated with transactions and blocks as described in the present disclosure.
The computing device 2600 may be of various types, including a portable computer device, tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 through one or more ports (e.g., USB, a headphone jack, Lightning connector, etc.). The device that may be connected to the computing device 2600 may include a plurality of ports configured to accept fibre-optic connectors. Accordingly, this device may be configured to convert optical signals to electrical signals that may be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 depicted in
It should be noted that the above-mentioned embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims.
In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may 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 features are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1810981.9 | Jul 2018 | GB | national |
This application is a continuation of U.S. patent application Ser. No. 17/257,805, filed Jan. 4, 2021, entitled “COMPUTER-IMPLEMENTED SYSTEM AND METHODS FOR OFF-CHAIN EXCHANGE OF TRANSACTIONS PERTAINING TO A DISTRIBUTED LEDGER,” which is a 371 National Stage of International Patent Application No. PCT/IB2019/055680, filed Jul. 3, 2019, which claims priority to United Kingdom Patent Application No. 1810981.9, filed Jul. 4, 2018, the disclosures of which are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17257805 | Jan 2021 | US |
| Child | 18666634 | US |
