Blockchain technology is innovative and continuously evolving. It has gained unprecedented attention from both the research and industrial communities. As an important application of a blockchain, a distributed ledger can effectively record the change in user accounts. However, in many typical application scenarios, it is necessary to revoke the incorrect account operations caused by user mis-operation, financial fraud, hacking, etc. In particular:
In a distributed ledger, the private key of a user’s account is the unique identifier of the user’s identity. If the private key is stolen due to hacking or misuse, the assets held in the account cannot be recovered. A major event where this happened was on February 7, 2014, Mt.Gox, an exchange that traded 70% of all Bitcoin at that time, lost bitcoins due to a hack. This event caused the exchange to go bankrupt, and to date, has not compensated the loss to its users.
To ensure the safety of standard user operations, a blockchain that supports revocable operations has received widespread attention (Birch, 2016). Noteworthy, currently in both research and industry communities, some hold a traditional view believing that once transaction data is recorded on a blockchain system, it should remain immutable in any case. The ”classic” Ethereum project ETC (Ethereum, 2018) is an outstanding example. Contrary to it, those holding a development view typically argue that technology itself is continuously evolving, and the future development of technology should not be defined by the current characteristics of a blockchain (Accenture, 2016; Greenspan, 2017). The root cause of this controversy lies in the confusion between ”transaction state revocable” and ”business status revocable” on a blockchain. To be specific, from a business perspective, the irreversible nature of a blockchain transaction safely prevents data on chain from being tampered with in a decentralized manner.
This provides a low-cost mechanism for data safety, which is considered to have broad application prospects (Wikipedia, 2018). However, from the end-user’s point of view, data modification and operations is undoubtedly a necessary function for an effective business system. Clearly, under strict regulatory conditions, a ledger system should provide the functionality of modifying and withdrawing the operation performed on the account states.
Generally, the existing revocable technology on Bitcoin and Eth- ereum systems can be divided into three categories. The first type is represented by the EOS system (et al., 2018) which approves the revocation of operations by majority voting in quorum. However, this type of technology does not support the rollback of the transaction itself. This means that the data recorded on the blockchain cannot be changed. The second type is applying a ”hard fork”, which completely modifies the chain and account states. A ”hard fork” can be seen as controversial by the industry. An example of this happened in June 2016, when a project named ”The DAO” was hacked which resulted in a large amount of Ethereum (ETH) being stolen. This forced the Ethereum community to perform a hard fork to recover the stolen ETH (Mehar et al., 2019). The third type uses advanced technology like the Lightning Network (Poon and Dryja, 2016). The Lightning Network can cancel unconfirmed transactions, but it is not suited for a transaction that is already recorded on the blockchain. Similarly, revocable technologies on blockchains has also received widespread attention in the academic field. Specifically, some research (Ateniese et al., 2017; Puddu et al., 2017) have proposed an editable blockchain technique to modify the block by direct compliance to achieve the purpose of the revised operations. However, these technologies are mostly implemented as prototype systems. The safety and reliability of such academic systems have not yet been verified.
To address this issue, in this paper we take the first step toward realizing revocable operations on a blockchain. Targeting real-world application requirements, such as the loss of a user’s key and transfer operation errors, we propose GateChain, a blockchain system that supports a revocable transaction model (RTM) on a distributed ledger. Specifically, based on state-of-the-art blockchain technologies, GateChain can safely withdraw the account status change operations by leveraging an improved account model and extra designed transaction types. On that basis, GateChain exploits the characteristics of functional completeness, is easy to deploy, and lowers complexity.
To summarize, the contributions we made in this paper are as follows:
To the best of our knowledge, GateChain is the first work on realizing revocable account operations by leveraging an improved account model and extra designed transaction types. Considering that this blockchain provides support for transaction verification, the revocable operations proposed in this paper adopted the transaction model of a Utxo-based block- chain. In essence, the transaction method can make full use of proven, mature blockchain technologies, and can be regarded as a ”native” realization of the revocable operations.
GateChain proposes a user-friendly account model. Compared with the traditional blockchain account model adopted by Bitcoin and Ethereum, the account model of GateChain introduces a radical new vault account type, which is designed to support the withdrawal of account status change. The design of this vault account provides users with better security.
A real world application of GateChain is provided as a verifiable implementation of revocable business logic, with more comprehensive considerations on security, usage, as well as performance issues.
The rest of the paper is organized as follows:
Section 2 introduces the design of RTM.
Section 3 explains the safety considerations of RTM
Section 4 presents the design of GateChain, a verifiable realization of RTM.
Section 5 summarizes the paper and mentions the direction of future work.
2. The Design of RTM
Blockchain technology provides a decentralized distributed ledger architecture which supports complete, sequential transaction chain recording. In a typical distributed ledger application, the user’s assets are represented as the states in the account, and the states can only be changed by designated transactions, which are recorded and managed by a blockchain system. In essence, from the application level, revoking a transaction is not deleting the records of the transaction from the blockchain, but to support the user to withdraw the account status change caused by the transaction.
In this section, we propose a Revocable Transaction Model (RTM), a blockchain-based transaction model that supports revocable logic, for the sake of avoiding user account losses caused by misuse, financial fraud, and illegal hacking. The key features of RTM can be summarized as:
The intrinsic value of RTM is based on state-of-the-art block- chain technologies, which ensures that all transactions recorded on the chain cannot be tampered with.
To support the revocation of account status, we propose a radical new transaction model called RTM. With additionally designed transactions, RTM can support the revocation of the account status change within a designated delay period . The design of these transactions ensure the completeness of the extended transaction state machine.
To support revocable transactions, RTM includes the structure of a ”Vault Account” which is especially created for the revocation of account status. In real world applications, the vault account mechanism can tackle the problem of user private key loss, thus greatly enhance the security of the whole ledger application.
2.1. Basic Concepts
Intrinsically, the basic idea of the RTM is to initiate a transaction that support withdraw the change of given account status within a certain period of time, i.e. the delay period . To be specific, the account can be seen as the collection of business status of a given user at a given time. Consider the reliability guarantee provided by the blockchain, the transactions between accounts can be assumed as safe and reliable, with no additional design required. Therefore, the status of an account is often designated as a numerical value. The change in account assets is reflected by the change of the account status, which is represented by a real value.
Henceforth, we can give the following formal definitions of the concepts used throughout this paper.
Definition 2.1 (State).
As stated above, The state of a user is generally represented by a rational number . The state at time (i.e., the block height) is represented as .
Definition 2.2 (Account).
An account is defined as the collection of states. Given a state space , an account space , an account that has states can be formally defined as:
The state of at time n can be represented as:
Definition 2.3 (Transaction).
A transaction represents a change of states.
Definition 2.4 (State Machine).
A state machine represents the change of account states over time. Given state transition function , where are the input and initial state of respectively, the state machine can be formally defined as a collection of state transition functions, . Among them, is the states of all account at the -th transaction, is the input of the account at the -th transaction.
As stated in the above definitions, a state machine represents the relations among all transactions. In a blockchain system, transactions are grouped into blocks according to certain rules, and the blocks form a directed chain structure, which generate the basic data structure of the blockchain. In retrospect, the transaction at time can be formally defined as:
Definition 2.5 (Ledge).
A ledger is a collection of transactions. The ledger at time is represented as . Specifically, a ledger is an ordered set of transactions.
Definition 2.6 (Revocable State).
Definition 6 (Revocable State). From business aspect, revocable state means that the change on the account states should be partially or completely withdrawn under strict regulatory conditions. For a given transaction sequence and , where , partially revocable means that changes on some states of account can be withdrawn. i.e., ,,. The complete revocable means that all states of account can be withdrawn. i.e., .
Definition 2.7 (Revocable Ledger).
A revocable ledger is a distributed ledger system which uses a blockchain that supports a complete revocable state.
2.2. Design of Account Model
In this section, we introduce the basic design of the account model proposed by RTM. First, we give the formal definition of an account used in a ledger system.
Definition 2.8 (Account).
The account of user can be formally defined as:
is the unique identifier of account ;
is the address of , i.e., an encoding of ’s public key;
represent the type of , , where ”” state for standard account, and ”” state for vault account;
is the state managed by account , where represent the state of account at time ;
is the private/public key pair of account .
In order to support revocable status, RTM introduces two types of accounts, namely the standard account and the vault account. The standard account refers to the account used in traditional Utxo-based blockchain systems. The standard account is used for conventional account transfer transactions. In this setting, the transaction changes the account status immediately, and it does not support revocable states.
The vault account is specifically designed for RTM. It supports revocable states. From the user’s point of view, after an account transfer transaction is initiated by a vault account, the change of the account states can only come into effect after a delay period . Within the delay period , the user can initiate a revocable transaction to withdraw the change of the vault account states. For vault account A(k),if type=v,then the follow holds:
is the clear time (block height) of account .
defines the account where the revoked state is assigned to. Namely, is called as the ”retrieval account” of vault account , and generally located on a reputable third-party exchange platform;
Data is a list of transactions which records all the revocable transactions initiated by vault account .
Generally, the vault account is designed with the following characteristics:
Time delay: The revocable transaction can only be initiated by a vault account . For each revocable transaction, a delay period is assigned. From the application point of view, the account status change can be rolled back during the period of .
Revocable: Within the designated delay period , if initiates a revocable transaction to revoke the operation of , the revocable state can be rolled back to the original state.
2.3. Design of Revocable Logic
Revocation logic represents the core of the revocable transaction model (RTM). Therefore, the additional designed transactions in RTM are detailed as follows:
Definition 2.9 (, VaultAccountRevocable Transaction).
Transaction define a revocable transaction. It is initiated by a vault account , implementing a tentative account transfer operation from to . Formally:
Where is the designated delay time of ,and , .
Definition 2.10 (, Revoke Transaction).
Transaction is initiated by a vault account to revoke the tentative account transfer operation from the original vault account . The revocable states of is transferred to its bounded safety account . Formally:
The condition for to be correctly executed, attribute to that the block height of transaction T is less than .
Definition 2.11 (, VaultAccountCreation Transaction).
Transaction is used to create a vault account . is initiated by a normal account by issuing an account transfer transaction, formally:
Note that is not a revocable transaction. Once is successfully executed, the state assigned by is transferred from to the newly created vault account , and the state of is changed to , as well as the state of is changed to , where . In the delay period , can initialize a revocable transaction , withdraw the assets to the retrieval account bounded by vault account.
Based on the designed transaction and , the revocation logic of RTM is defined as follows:
At time , user initiates a revocable transaction on vault account . specifies the tentative amount of transfer assets , the destination account of user , and the delay period for the transfer to take effect.
After the transaction is verified and confirmed on the blockchain, , as a transaction, is recorded on the chain, and the status changes involved in are also recorded in accounts and , but the state and are not immediately changed.
If at time , user finds problems in the transaction, the user can initiate a revoke transaction , and revoke the transfer amount in to a retrieval account bounded by .
If at time , a revoke transaction targeting a is initiated, and is verified and confirmed on the blockchain, then all transactions initiated after time are invalid transactions.
At time , and is not revoked, the account states of both users remains unchanged. i.e., the transfer operation at time is delayed. That is, .
At time , any revoke transaction initiated for will be an invalid transaction.
2.4. Design of RTM’s Security Model
As stated by the early work of Rosenfeld(Rosenfeld, 2014), the cost of an attack grows exponentially, which is also correct as long as the blockchain system adopted consensus in mining blocks. In this work, we adopted the formal model proposed by Garay et. al. (Garay et al., 2015) for the core of the Bitcoin protocol, where blocks can be found simultaneously as each mining steps. Therefore, we assume the following assumptions holds for the security model of the generalized RTM.
Assumption 1 ().
The mining rate of the blockchain remains constant over time. e.g. in Bitcoin, blocks per second.
Assumption 2 ().
Under reliable networks, the block creation rates are much higher than the propagation time of blocks. Surely, the block propagate in the network is very fast relative to .
Assumption 3 ().
The honest miners only keep track of the longest chain they have been presented. i.e., the longest chain prevails.
Under these assumptions, the correct chain at time (height) h is uniquely determined as , , where denotes a block at time h. Clearly,
holds a collection of accepted transactions. Therefore, we formally define the acceptance probability of a transaction.
Definition 2.12 (Acceptance Probability).
The acceptance probability of a transaction that is robust against an arbitrary malicious attack. Formally, based on the above assumption, given block at height . For a correct transaction to be record in block
, the acceptance probability can be roughly estimated as
Similarly, for a malicious transaction to be recorded in block block , the acceptance probability can be roughly estimated as
Definition 2.13 (-robust Transaction).
A transaction is -robust transaction, or robust against malicious attack of blockchain, iff for any transactions at height , the following holds:
Definition 2.14 (-robust Model).
A transaction model is -robust Model, iff for any transactions initiated by attackers, the following holds:
Without loss of generality, we adopt (Sapirshtein et al., 2016) to define the attacker’s policy as a function that determines the action of the attacker at every possible state. An attacker is assumed to initiate transaction with probability . Given that each transaction is independent from other transactions, we can assume that the acceptance probability follows identical and independent distribution (i.i.d.). Thus, we simplify the probability of malicious attack risk as . Intuitively, states the probability of a standard account being hacked.
Consider the design of RTM. With the introduction of vault account detailed in Section 2.2, each user can have vault account in addition to the traditional standard blockchain account. By design, vault account support cascade to form a chain of revocable account states. Figure 1 illustrates the general design of cascaded vault account and associated RTM transactions.
In this setting, we get the following theorem to describe the characteristics of vault account and RTM.
Theorem 2.15 ().
The vault account support -robust transaction.
With the strong assumption of i.i.d. among transactions, the acceptance probability of malicious attack for a vault account with n-level cascade can be minimized to
Therefore, for -robust transactions, the probability of a vault account being malicious hacked is less than . Given a concrete example, if , and vault account support level cascade, then .
Theorem 2.16 ().
RTM is -robust Model.
We define that stochastically dominates the distribution of a random attack. The event in which the attack will accepted is then equivalent to the event that a random walk will ever arrive at a given cascaded vault account. Therefore, a necessary condition for a successful attack is that, an attacker had managed to create a chain with height , which is longer than the published chain, . Remind that in most cases, . This means that the acceptance probability .
To summarize, the cascaded vault account design makes RTM a -robust Model. Theoretically, vault account can efficiently prevent malicious attack from being accepted by the blockchain.
3. Further Security Considerations in RTM
The design of RTM is based on existing mature blockchain technologies. Noteworthy, the improved account model improves the security requirements in the actual applications, such as user key theft and transfer operation error. Additionally, RTM has introduced a radical new transaction type to tackle revocable state changes.
3.1. The impact on transaction performance
To tackle the problem of user error, financial fraud and account transfer error, RTM has introduced new transaction types and . Note that the implementation of and do not add additional complexity to the existing transaction model, and therefore do not degrade the overall performance of the system.
Generally, existing blockchain transaction models can be classified into two categories: Bitcoin’sUtxo-based model and Ethereum’s account model. For the Utxo-based model, RTM only needs to add an extra operation to check the type of the previous transaction, to ensure whether it is a revocable transaction. Remind that in order to verify the legality of the transaction, an extra operation to determine the transaction time (block height) should be added to RTM. To be specific, to query the balance of an account, it is necessary to distinguish between the revocable states and normal states in the unspent transactions.
For Ethereum’s account model, an account balance check operation should be added to the implementation of . To query the balance of an account, an extra account transfer operation is needed.
Overall, the extra operations needed to implement and have lower complexity , thus cannot significantly increase the cost of transaction implementation. Therefore, adding revocable transactions to the existing blockchain transaction model does not degrade the overall performance. In fact, it can only be seen as an advantage as it can prevent malicious users from attacking the system by initiating a huge number of revocable transactions.
3.2. The impact on user operations
In order to tackle the problem of user key theft caused by hacking, RTM has improved the account model by introducing a radical new design named ”Vault Account”. Henceforth, a user can have two types of accounts, i.e., a standard account and a vault account. Although the vault account improves the security of the account operation, it increases the complexity of the user operation. In order to avoid the security risk caused by user errors in real world implementation, the revocable account introduces extra operations for compliance verification in accordance with the business logic. Specifically, business logic compliance verification considers the following aspects:
A vault account can only initialize revocable transactions and , and / must also be initialized from a vault account.
By adopting differentiating encoding for different types of accounts, it is convenient for a user to intuitively distinguish between a retrieval account and a standard account, thus keeping users from mistakenly making a revocable transaction instead of a standard transaction.
A user can use the account balance to check revocable states (assets) and normal states. This helps users to confirm transaction types, and avoid blurring revocable transactions with standard transactions.
3.3. The double spend attact
The ”double spend” attack means that an account can transfer the same asset to more than one account. The essence of this attack is to use some abnormal factors such as network delays to purposely cause illegal inconsistencies between the nodes in a distributed ledger system. Generally, a blockchain system can avoid the ”double spend” attack by leveraging atomic broadcasting and consensus mechanisms.
In RTM, the verification of the revocable transaction is the same as the verification of the standard transaction. To be specific, for a Utxo-based transaction model, the verification of a current transaction needs to specify the previous transaction. For the Ethereum-based account model, the verification needs to check the account balance. Once a transaction is issued, the assets transferred out of an account will be deducted..Therefore, revocation of the transaction will not result in additional double spend risk. Specifically, the mechanisms used by and can be detailed as :
For , the assets involved in cannot be transferred out multiple times. Like traditional transfer business logic, the change of account status for a revocable transaction should be delayed. However, from the transaction point of view, as long as the transaction status change can be verified by the blockchain system, the correctness of the transaction can be guaranteed by the blockchain itself.
For , the assets involved in cannot be withdrawn multiple times. Once a transaction is verified by a blockchain system, the correctness of the transaction can also be guaranteed by the blockchain itself. Furthermore, in the implementation of the business logic, a compliance rule is further defined, which defines that the receiving account cannot use the assets in a delay period θ. This compliance check further ensures the robustness of the revocable logic.
4. GateChain: A Verification implementation of RTM
Using the proposed transaction model RTM, in this paper we implemented a verification blockchain system called GateChain. Specifically, GateChain adopted the RTM design, with its structure based on the state-of-the-art platform Tendermint (Rosenfeld, 2014), leveraging the distributed network and consensus mechanism provided by Tendermint Core, and the application layer implemented by using Cosmos SDK. Figure 2 illustrates the general structure of GateChain.
In essence, GateChain implemented several verification features targeting RTM. First, GateChain introduced the vault account to hold revocable states. Each vault account should bind a safety account as the revoked output of the vault account. Second, GateChain introduced the revocable transaction logic proposed by RTM. This application logic is well suited for the circumstance when a user is securely holding his private key but issues an unintended transfer transaction, for example hacking, misuse or financial fraud. Third, to support the revocable transaction logic, GateChain presented a solid implementation of , and , as proposed in Section 2.3.
4.1. Implementation of Account Model
In order to simultaneously support the revocable transactions and the standard transactions, GateChain has implemented two types of accounts: the standard account and the vault account.
The standard account has no difference with the account implemented in Utxo-based blockchain systems, and it is applicable to the standard account transfer scenarios. By default, the transferred assets arrive immediately, showing no revocable behavior. This is well suited for general transfer applications.
The vault account supports revocable transactions. The assets transferred from this type of account can only arrive after the designated delay period , while the transaction itself is adequately recorded by the blockchain system. In a single run, the status of a vault account will remain unchanged until the delay period expires. Noting that during the delay period, the vault account can initiate another transaction to revoke the aforementioned transaction, and withdraw the corresponding assets back to a designated retrieval account.
As stated in section 2.2, the target account which accepts the withdrawn assets from the vault account is called a retrieval account, which can be a standard account or a vault account. It is worth noting that the withdrawn assets of the vault account are not directly returned to the originating vault account itself, but to a retrieval account its bounded to.
The introduce of retrieval account increases the security of revocable transactions. From an application point of view, distinguishing the account type makes clear to the user:
Whether the current account is a vault account or a standard account
Whether the assets transferred by the account are revocable
Whether the revocable transaction has taken effect.
Therefore, this implementation lets the user select different account types according to their actual needs.
Note that a risk must be considered in real application scenario, which can be called the revoke of a delay transfer. To be specific, a malicious payer can initiate a revoke transaction which tentatively transfer certain amount to a payee. If payee mistakenly consider this as a normal transfer, and concluded the transaction in turn. The malicious payer can revoke the tentative transfer, thus causes an intended business fraud. To tackle this risk, GateChain introduces two encoding mechanism to technically explicify the type of transaction. Firstly, each account is encoded with a prefix to distinguish between standard account and vault account. From the prefix adhere to an account address, use can explicitly judge the type of the initiated transaction. Secondly, each transaction id is also encoded with a predefined prefix to stamp different transaction type, which details in Section 4.2. Encoding mechanism technically prevent the user from mistaken a revoke transaction with a standard transaction, thus take adequate action henceforth.
4.2. Implementation of Transaction Model
In addition to the standard transaction types supported by a vanilla Utxo-based blockchain , GateChain introduces two types of revocable transactions named and . Both types of transactions can only be initiated by a vault account, supporting revocable states. The consensus of GateChain is supported by the underlying consensus mechanism provided by the Tendermint platform. The implementation of these two transactions does not add any additional cost to the system as a whole. To be specific, different types of transactions are distinguished by a set prefix encoding. That is, a transaction is named following the pattern of ”fixed transaction type + transaction hash value”.The transaction prefix helps the user to clearly distinguish the transaction type, avoiding *unintended* operations and invalid operations. On the other hand, this design can help the blockchain itself and the application to check the correctness of a transaction, thus improving the security of the system. Details of transaction prefixes are listed as Table 1.
|Transaction type||Transaction prefix|
|Setting an account||ACCOUNTSET-¡id¿|
|Revoke a revocable pay||REVOKE-¡id¿|
|Clear a Vault Account||VAULTCLEAR-¡id¿|
The revocable logic of the transaction is applicable to the scenario in which the user properly owns his private key, and wants to revoke the transfer operations initiated by a vault account. The logic is implemented as vault account A initiates a transaction to transfer some assets to a designated account B, and sets the transaction type as , i.e., a revocable transaction. After the transaction is successfully executed, the transaction and the delay period are recorded in account and separately. However, the transferred assets are not immediately available in both and . In the event that the transaction delay period has expired, the transfer transaction is officially effective and the assets are officially available in . Therefore, during the delay period of the transaction, the vault account itself may initiate a revoke transaction , the asset is withdrawn to a safety account bounded by . Note that the operation of takes effect immediately, and the transfer operation is cancelled for account . Generally, the safety accounts are typically located on a third-party trustworthy platform. The transaction itself is recorded in the blocks of GateChain, and the inactive transactions maintained in the account are cleared by GateChain.
To conclude, GateChain implements a lightweight RTM based on existing mature blockchain technologies, namely, the Tendermint platform and the Cosmos SDK.
5. Conclusion and Outlook
Real world business, such as financial transfers, government regulation, copyright transactions, personal privacy, and transaction rollback logic, all natively require that the blockchain system should support revocable transactions. Regarding the perspective of implementation, revocable and non-tamperable are not two contradictory concepts. The reason lies in that as long as a revocable transaction is verified on the blockchain, the transaction itself is supported by the mechanism provided by a blockchain. Thus, we can add revocable features into existing blockchain systems by improving the design of the transaction model. This has proven to be the best way in natively implementing a revocable-supported blockchain.
We believe that, as an innovative technology, the blockchain ecosystem itself is continuously evolving. Some new features will be reflected in the design and implementation of the blockchain in the near future, and in the form of ”native” blockchain characteristics. Undoubtedly, revocable transactions are such a feature. Although blockchain technology is still in its exploratory phase in many areas, it is certain that it will continue to evolve and improve, leading to wide adoption in many fields.
- Why distributed ledger technology must adapt to an imperfect world. Note: https://www.accenture.com/_acnmedia/pdf-33/accenture-editing-uneditable-blockchain.pdf Cited by: §1.
- Redactable blockchain–or–rewriting history in bitcoin and friends. In 2017 IEEE European Symposium on Security and Privacy (EuroS&P), pp. 111–126. Cited by: §1.
- Mutable and immutable blockchains. Note: https://www.chyp.com/mutableand-immutable-blockchains/ Cited by: §1.
- EOS.io technical white paper v2. Note: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md/ Cited by: §1.
- Ethereum classic project. Note: https://ethereumclassic.github.io/ Cited by: §1.
- The bitcoin backbone protocol: analysis and applications. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 281–310. Cited by: §2.4.
- The blockchain immutability myth. Note: https://www.coindesk.com/blockchain-immutability-myth/ Cited by: §1.
- Understanding a revolutionary and flawed grand experiment in blockchain: the dao attack. Journal of Cases on Information Technology (JCIT) 21 (1), pp. 19–32. Cited by: §1.
- Bitcoin: a peer-to-peer electronic cash system. Technical report Manubot. Cited by: 2nd item.
- The bitcoin lightning network: scalable off-chain instant payments. Cited by: §1.
- chain: How to forget without hard forks.. IACR Cryptology ePrint Archive 2017, pp. 106. Cited by: §1.
- Analysis of hashrate-based double spending. arXiv preprint arXiv:1402.2009. Cited by: §2.4, §4.
- Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security, pp. 515–532. Cited by: §2.4.
- Blockchain. Note: https://en.wikipedia.org/wiki/Blockchain Cited by: §1.
- Ethereum: a secure decentralised generalised transaction ledger. Ethereum project yellow paper 151 (2014), pp. 1–32. Cited by: 2nd item.