# k-Root-n: An Efficient Algorithm for Avoiding Short Term Double-Spending Alongside Distributed Ledger Technologies such as Blockchain

## Abstract

**:**

## 1. Introduction

## 2. Overview of k√n Random Double-Spending Detection

^{−9}of zero common, honest and responsive nodes. Therefore, the chances of getting away with double-spending are negligible, and there is a probability very close to 1 that any double-spending will be detected as soon as both branches of the spend reach honest nodes.

^{−9}of not being caught.

^{6}nodes. We will see that this gives a probability of just p ≈ 10

^{−9}of getting away with double-spending, even if half of the nodes are fraudulent and 10% of the nodes are unavailable (i.e., 4.5√n honest, responsive validating nodes). Thus, each transaction only burdens 1 out of 10,000 nodes, a performance improvement of four decimal orders of magnitude. With 10 billion transactions per hour globally, or 2.77 million transactions per second globally, each node should be involved in just 278 transactions per second. This transaction throughput is feasible for a modern computer (especially in 2050).

## 3. Preliminaries

**Definition**

**1.**

**Transaction**T = (x, t, S, R, s

_{s}, s

_{r}) is an agreement to transfer a balance from a sender node/wallet to a receiver node/wallet; the tuple comprises a positive monetary amount, that is a quantity of coin, x = x[T], a time stamp t = t[T], identifiers (public keys) of the sender user S = S[T] and the receiver user R = R[T]. Additionally, s

_{s}and s

_{r}are the respective digital signatures of S and R of the data tuple (x, t, S, R) evidencing their agreement to the transaction.

_{s}).

**Definition**

**2.**

**Balance b[S, t**of a user S at time t

_{1}]_{1}, given that s/he had a balance of b

_{0}at the time t

_{0}of the last known global ledger consensus, is defined by

**Definition**

**3.**

**Lineage LIN[T]**of a transaction or potential transaction T is the transaction history for the sender S[T] from the last known global ledger consensus at time t

_{0}before t[T] and up to the time of T:

**Definition**

**4.**

**Critical Lineage CLIN[T]**of a transaction or potential transaction T is a set of transactions whose elements are a subset of LIN[T], comprising a minimal subset of inbound transactions critical to provide the balance that allows the sender to afford T. Formally, suppose that a sender S makes a payment of amount x in a transaction or potential transaction T; suppose that S’s last known global ledger consensus balance was b

_{0}. Suppose that the set of transactions in which S participated since the last global ledger consensus, LIN[T], includes inbound payments, T

_{1}...T

_{n}, in descending order of amount (and ordered chronologically when amounts are equal) and outbound payments, U

_{1}...U

_{m}. Now, the critical inbound payments are the subset CLIN[T] = {T

_{1}...T

_{j}} of inbound payments with j minimal such that

_{1}...T

_{k}} is a minimal subset of inbound transactions that are enough to provide balance coverage for this payment of x. Even if any of the other inbound payments, T

_{j+1}...T

_{n}, is derived directly or indirectly from fraud, the validation by the receiver of these critical inbound payments CLIN[T] of the sender is sufficient due diligence to ensure that the sender can afford x. Therefore, the minimum due diligence of the receiver R[T] is to check the following: (A) LIN[T] is complete and (B) the lineage of each transaction in CLIN[T] is complete. We now formalize this recursive set of transactions.

**Definition**

**5.**

**Pedigree**PED[T] of a transaction or potential transaction T is the recursive closure of the set {T} under the CLIN operator. To compute this:

- Start with the set of PED[T] = {T}.
- For each T
_{1}in PED[T], add any element of CLIN[T_{1}] which is not already in PED[T] to PED[T]. Repeat until there is nothing to add. - PED[T] = PED[T].

**Definition**

**6.**

**Disclosure DIS[T]**for a potential transaction T is a communication from sender S[T] to receiver R[T] of PED[T] and LIN[T

_{1}] for every T

_{1}in PED[T].

**Definition**

**7.**

**Fraudulent Transaction**T is any transaction wherein the sender S[T] provides the receiver with an incomplete LIN[T] in the disclosure. Additionally, a transaction is considered a fraudulent transaction in retrospect if, at some time between t[T] and the next global ledger consensus, the same sender S[T] is the sender of another transaction T

_{1}and fails to disclose T when disclosing LIN[T

_{1}].

**Definition**

**8.**

**Invalid transaction**is a transaction that is not fraudulent, but wherein the sender in retrospect did not have balance to cover the transaction after removing fraudulent transactions. Equivalently, these are transactions that turn out to have a fraudulent transaction in their pedigree.

**Definition**

**9.**

**Due diligence**for a potential transaction T is the process of receiver R[T] communicating the offered disclosure DIS[T] with a random selection of $k\surd n$ (strictly $\lceil k\surd n\rceil $ i.e., $k\surd n$ rounded up to the nearest integer) nodes, called the

**validating nodes**, and confirming that none of them has seen an alternative version of LIN[T

_{1}] for any T

_{1}in PED[T].

## 4. k-root-n Algorithm

_{0}in the recent past; we call this time the

**global ledger consensus**. Each global ledger consensus may become known at time t

_{1}> t

_{0}, that is, with some latency after the time t

_{0}which it relates to (e.g., in bitcoin, we may wait some hours for transactions to be included in a block and then for 6-block confirmation, before trusting that consensus was achieved). When we refer to the last global ledger consensus before time t, we mean the last one known before time t.

- Demand that the sender transmits the disclosure DIS[T], that includes the recursive list of dependent transactions PED[T] and the transaction history LIN[T
_{1}], for each T_{1}in PED[T]. - Validate that each transaction T
_{1}in PED[T] was properly formed and signed by known nodes, and that each node had the balance to cover T_{1}based on the last known global ledger consensus balance of S[T_{1}] plus the provided LIN[T_{1}]. - Due diligence: Randomly choose $\lceil k\surd n\rceil $ validating nodes on the network; send each (directly or by communicating through a cascading tree of nodes) the disclosure DIS[T], and ask the validating nodes to validate that they have not seen any alternative LIN history for any transaction in PED[T].
- Any honest node receiving this due diligence request will validate that they have never previously seen a contradictory LIN history for any of the transactions T
_{1}in PED[T]. If all is well, they will confirm their validation by digitally signing DIS[T] and transmitting that validation back to the receiver R[T]. Each validating node must then store every LIN transaction history they are asked to validate until the next achieved global ledger consensus, for future validation. - If any validating node has in fact seen an alternative LIN transaction history for some T
_{1}in PED[T], it informs the receiver R[T] who rejects potential transaction T. Proof of fraud, which comprises two alternative histories LIN[T_{1}] and LIN’[T_{1}], should be broadcast to all nodes on the network by the validating node. The double-spending wallet S[T_{1}] will be blacklisted and any balance forfeited. - The receiver R[T] should also broadcast the list of any of the other $k\surd n$ validating nodes that failed to raise an alarm. That is, in case R[T
_{1}] or any other nodes had previously disclosed LIN’[T_{1}] to one of these same validating nodes V, then this node should also be blacklisted with proof of**validation fraud**, that is proof that V validated the current potential transaction, even though the disclosure included LIN[T_{1}] while the same V has previously validated a transaction disclosure that included a forked lineage LIN’ for the same sender. Thus, the nodes are also held accountable for providing validation services honestly. - If on the other hand all the validating nodes validate the transaction, the transaction is accepted and signed by the receiver.

## 5. An Example of Detection of Double-Spending Using the k-Root-n Algorithm

- Chuck (malicious) $100
- Mallory (malicious) $100
- Alice (honest) $100
- Bob (honest) $100

- Bob notices that Mallory’s $100 balance is contingent on the money from Chuck (so transaction #2 is in the critical lineage CLIN[#4] and therefore in PED[#4]). Thus, Bob validates transaction #2 by requiring Mallory to provide Chuck’s transaction history LIN[#2] as part of the pedigree. In this case no further recursion is required.
- Chuck now does his due diligence and queries k√n random network nodes by asking them to validate the pedigree, which includes both LIN[#4] and LIN[#2].
- Some of these nodes (k
^{2}on average, but at least 1 with an extremely high probability) had previously been told about Chuck’s alternative transaction history of transaction #3 in which he gave $99 to Alice. This triggers the following actions.- ○
- The common validating nodes raise the alarm of double-spending, and broadcast a fraud-proof, namely that transaction #3 was not disclosed in LIN[#4]. The fraud-proof comprises two divergent transaction histories that were both signed by Chuck.
- ○
- Bob rejects the fraudulent transaction.
- ○
- Chuck has his wallets blacklisted and forfeits his $1 minimum stake.
- ○
- The fraudulent transaction #2 from Chuck to Mallory (which was later hidden from Alice) is also rejected from the distributed ledger. Therefore, transaction #4 is invalid since it depends on a fraudulent transaction #2.
- ○
- The network preferably should ask Mallory to show that she queried k√n validating nodes. When she fails to do so, Mallory may also be blacklisted and forfeit her balance. (This is optional extra protection which we might call no due diligence fraud, although this is not required for the algorithm to work and cannot be enforced in case Mallory had k√n co-conspirators and pretends to select them at random).
- ○
- Alice and Bob compare notes and find all the ~k
^{2}common validating nodes they had consulted in #3 and #4. If any common node failed to raise the alarm, then such node would also be blacklisted for validation fraud, with the fraud-proof showing that the node received two alternative lineages from Chuck and in both cases approved and digitally signed them.

- Chuck (malicious) $100 (blacklisted with balance forfeited for double-spending)
- Mallory (malicious) $1 (may be blacklisted for failing to do due diligence on #2)
- Alice (honest) $100
- Bob (honest) $199

## 6. Algorithm Correctness

**Theorem**

**1.**

^{2}common nodes queried by both honest nodes (any one of which can detect double-spending and raise the alarm).

**Proof**

**of**

**Theorem**

**1.**

^{2}on average will overlap. □

**Lemma**

**2.**

**Proof**

**of**

**Lemma**

**2.**

_{0}~ 10

^{−9}for all large n. For convenience, we typically recommend that k = 4.5. k must be large enough to allow for the level of Byzantine faults in the network. As we saw a typical practical value would be k = 10 to allow for 10% unavailable nodes and 50% fraudulent nodes, so we have k = 4.5 of honest available nodes. 10% unavailability seems generous for most modern networks, while 50% of fraudulent nodes is typically the maximum supported by the distributed ledger technology used for global ledger consensus.

**Theorem**

**3.**

**Proof**

**of**

**Theorem**

**3.**

## 7. Algorithm Message Space Complexity

**Definition**

**10.**

**critical inbound transaction size j[T]**is the number of inbound transactions (since the last global ledger consensus) which a sender depends on for their balance when spending money in a transaction t, that is j[T] = |CLIN[T]|.

**Definition**

**11.**

**The critical velocity of money v[T]**of a transaction T, is the maximum depth of the recursion in PED[T].

## 8. Sybil Attack

^{6}and k = 10. Assume that there are initially n honest nodes, and the fraudster creates another n fraudulent nodes, to control 50%, and suppose further that 10% of the nodes are unavailable. We already saw that k = 4.5 and the fraudster has successfully reduced p

_{0}$\approx $10

^{−44}to p

_{0}$\approx $10

^{−9}. But with M/m=10

^{6}there is no incentive to double-spend with p

_{0}$\approx $10

^{−9}.

_{0}$>$10

^{−6}and achieve a positive expected value for double-spending. Therefore, the criminal would need approximately 2n fraudulent nodes. However, the fraudster then faces another challenge. The loss from a single unsuccessful double-spending is not limited to forfeiting the double-spending wallet, but also the loss of all the nodes that failed to detect the double-spend and thereby committed a verification fraud. According to Theorem 1 the expected number of common nodes is (10 − 3.5)

^{2}= 42.25 nodes for an average loss of at least 42.25 m. Thus, even in this case, double-spending will have a negative expected value.

^{2}- k

^{2}/f dishonest nodes, and if the double-spending is caught these k

^{2}(1-1/f) nodes will be disqualified.

_{0}(k, n)M $\approx {e}^{-{k}^{2}/f}M$, against the expected cost of (k

^{2}(1 − 1/f) + 1)m ≈ k

^{2}m (the fraudulent nodes that fail to report the double-spending, plus one for the double-spending wallet) for every unsuccessful transaction against a setup cost of (f − 1)nm.

_{0}= ${e}^{-{k}^{2}/f}={e}^{-9}\approx 0.00012$. Thus, a double-spending of M = $1,000,000 would have an expected value of $120, while the expected cost would be losing k

^{2}(1 − 1/f) + 1 = 91 nodes at a cost of 91m = $91, giving an expected profit of $29. After such an extreme attack, a single fraudulent transaction would have a positive expected value.

^{6}, it costs $10 million to setup 10 million nodes. The user would have to repeat the double-spending three hundred thousand times to recoup the initial investment. However, they would lose 91 nodes, on average, each time they fail, meaning that they would lose the vast majority of the fraudulent nodes before recovering their investment, so the whole scheme is not feasible.

^{2}= 100, then the fraud can pay off. p

_{0}gets closer to 1 and the fraudster earns a payback that tends to M as f increases. However, this requires creating O(100n) nodes to dominate ~99% of the network. Various strategies that can help to defend against such an extreme attack include the following.

- Reducing M/m: Reducing M can force honest people to have more wallets that increase n.
- Increasing k.
- Biasing the k√n random nodes towards the nodes that have been around for longer or have higher balances.
- Monitoring for suspicious behaviour such as the creation a huge number of wallets with close to a minimum stake.

## 9. Variations on the Algorithm for Further Research

#### 9.1. k-root-n without Global Ledger Consensus

#### 9.2. Nodes Versus Wallets

#### 9.3. Forced Validation

^{2}nodes would detect his double-spending and simply claim that those particular nodes were not available. This would have to be mitigated by common monitoring of node availability, or honest nodes may self-monitor, so that anyone can later validate any claim that a certain node was unavailable at a certain time.

_{0}= 3.70 × 10

^{−44}, the user must consider O(10

^{44}) combinations of wallets and time slots to obtain one with no clashes to an earlier transaction, which is not feasible.

## 10. Conclusions

## Funding

## Acknowledgments

## Conflicts of Interest

## Appendix A. Table of k and p_{0}

_{0}, the chances of zero clashes when two honest nodes each consult k√n random nodes for various values of k and a couple of values of n.

k | p_{0}(n = 10^{4}, k√n) | p_{0}(n = 10^{10}, k√n) | ${\mathit{e}}^{-{\mathit{k}}^{2}}$ |
---|---|---|---|

1 | 0.36 | 0.37 | 0.37 |

1.5 | 0.1 | 0.11 | 0.11 |

2 | 0.017 | 0.018 | 0.018 |

2.5 | 0.0016 | 0.0019 | 0.0019 |

3 | 9.30 × 10^{−05} | 1.20 × 10^{−04} | 1.20 × 10^{−04} |

3.5 | 3.10 × 10^{−06} | 4.80 × 10^{−06} | 4.80 × 10^{−06} |

4 | 5.80 × 10^{−08} | 1.10 × 10^{−07} | 1.10 × 10^{−07} |

4.5 | 6.10 × 10^{−10} | 1.60 × 10^{−09} | 1.60 × 10^{−09} |

5 | 3.70 × 10^{−12} | 1.40 × 10^{−11} | 1.40 × 10^{−11} |

5.5 | 1.20 × 10^{−14} | 7.30 × 10^{−14} | 7.30 × 10^{−14} |

6 | 2.30 × 10^{−17} | 2.30 × 10^{−16} | 2.30 × 10^{−16} |

6.5 | 2.30 × 10^{−20} | 4.50 × 10^{−19} | 4.50 × 10^{−19} |

7 | 1.30 × 10^{−23} | 5.20 × 10^{−22} | 5.20 × 10^{−22} |

7.5 | 3.70 × 10^{−27} | 3.70 × 10^{−25} | 3.70 × 10^{−25} |

8 | 5.60 × 10^{−31} | 1.60 × 10^{−28} | 1.60 × 10^{−28} |

8.5 | 4.60 × 10^{−35} | 4.20 × 10^{−32} | 4.20 × 10^{−32} |

9 | 1.90 × 10^{−39} | 6.60 × 10^{−36} | 6.60 × 10^{−36} |

9.5 | 4.10 × 10^{−44} | 6.30 × 10^{−40} | 6.40 × 10^{−40} |

10 | 4.40 × 10^{−49} | 3.70 × 10^{−44} | 3.70 × 10^{−44} |

## References

- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 15 January 2020).
- Chohan, U. The Limits to Blockchain? Scaling vs. Decentralization. SSRN/3338560. 2019. Available online: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3338560 (accessed on 15 January 2020).
- Scalability. Bitcoin Wiki, 2015. Available online: https://en.bitcoin.it/wiki/Scalability (accessed on 15 January 2020).
- Garzik, J. Making Decentralized Economic Policy. 2015. Available online: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf (accessed on 15 January 2020).
- Vries, A.D. Bitcoin’s Growing Energy Problem. Joule
**2018**, 2, 801–805. [Google Scholar] [CrossRef] [Green Version] - Canneti, R.; Rabin, T. Optimal Asynchronous Byzantine Agreement; Technical Report #92-15; Computer Science Department, Hebrew University: Jerusalem, Israel, 1992. [Google Scholar]
- Castro, M.; Liskov, B. Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, LA, USA, 22–25 February 1999. [Google Scholar]
- Douceur, J.R. The Sybil Attack, Peer-to-Peer Systems. Lect. Notes Comput. Sci.
**2002**, 2429, 251–260. [Google Scholar] - Live Bitcoin Transactions. Blockchain Unconfirmed Transactions. Available online: https://www.blockchain.com/btc/unconfirmed-transactions (accessed on 15 January 2020).
- Azzolini, D.; Riguzzi, F.; Lamma, E. Studying Transaction Fees in the Bitcoin Blockchain with Probabilistic Logic Programming. Information
**2019**, 10, 335. [Google Scholar] [CrossRef] [Green Version] - Irreversible Transactions. Available online: https://en.bitcoin.it/wiki/Irreversible_Transactions (accessed on 15 January 2020).
- Luu, L.; Narayanan, V.; Baweja, K.; Zheng, C.; Gilbert, S.; Saxena, P. SCP: A Computationally-Scalable Byzantine Consensus Protocol for Blockchains. IACR Cryptol.
**2016**, 20. Available online: https://www.weusecoins.com/assets/pdf/library/SCP (accessed on 15 January 2020). - Gilad, Y.; Hemo, R.; Micali, S.; Vlachos, G.; Zeldovich, N. Algorand: Scaling Byzantine Agreements. In Proceedings of the SOSP 17 26th Symposium on Operating Systems Principles, Shanghai, China, 28–31 October 2017; pp. 51–68. [Google Scholar]
- Eyal, I.; Gencer, A.E.; Sirerr, E.G.; van Renesse, R. Bitcoin-NG: A Scalable Blockchain Protocol. In Proceedings of the 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), Santa Clara, CA, USA, 16–18 March 2016. [Google Scholar]
- Apeltsin, L. A CryptoCubic Protocol for Hacker-Proof Off-Chain Bitcoin Transactions; Cornell University: Ithaca, NY, USA, 2014. [Google Scholar]
- Dryja, J.; Poon, T. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 2016. Available online: https://www.bitcoinlightning.com/wp-content/uploads/2018/03/lightning-network-paper.pdf (accessed on 15 January 2020).
- Chohan, U.W. The Double Spending Problem and Cryptocurrencies. Bank. Insur. J. Soc. Sci. Res. Netw.
**2017**. [Google Scholar] [CrossRef] - Heilman, E.; Kendler, A.; Zohar, A.; Goldberg, S. Eclipse Attacks on Bitcoin’s Peer-to-Peer Network, SEC’15. In Proceedings of the 24th USENIX Conference on Security Symposium, Washington, DC, USA, 12–14 August 2015; pp. 129–144. [Google Scholar]
- Apostolaki, M.; Zohar, A.; Vanbever, L. Hijacking Bitcoin: Routing Attacks on Cryptocurrencies. IEEE Symp. Secur. Priv.
**2017**. [Google Scholar] [CrossRef] [Green Version] - Pinzón, C.; Rocha, C. Double-spend Attack Models with Time Advantange for Bitcoin. Electron. Notes Theor. Comput. Sci.
**2016**, 329, 79–103. [Google Scholar] [CrossRef] - Ittay, E.; Peter, G.; Aljosha, J.; Sarah, M.; Nicholas, S.; Itay, T.; Edgar, W.; Alexei, Z. Pay-To-Win: Incentive Attacks on Proof-of-Work Cryptocurrencies. IACR Cryptol. ePrint Arch.
**2019**, 775. [Google Scholar] - Stewart, I.; Ilie, D.; Zamyatin, A.; Werner, S.; Torshizi, M.F.; Knottenbelt, W.J. Committing to quantum resistance: A slow defence for Bitcoin against a fast quantum computing attack. R. Soc. Open Sci.
**2018**, 5, 180410. [Google Scholar] [CrossRef] [PubMed] [Green Version] - Saad, M.; Spaulding, J.; Njilla, L.; Kamhoua, C.; Shetty, S.; Nyang, D.; Mohaisen, A. Exploring the Attack Surface of Blockchain: A Systematic Overview. arXiv
**2019**, 1904, 3487. [Google Scholar] - Karame, G.O.; Androulaki, E.; Roeschlin, M.; Gervais, A.; Čapkun, S. Misbehavior in Bitcoin: A Study of Double-Spending and Accountability. ACM Trans. Inf. Syst. Secur.
**2015**, 18, 1. [Google Scholar] [CrossRef] - Pérez-Solà, C.; Delgado-Segura, S.; Navarro-Arribas, G.; Herrera-Joancomartí, J. Double-spending prevention for Bitcoin zero-confirmation transactions. Int. J. Inf. Secur.
**2019**, 18, 451–463. [Google Scholar] [CrossRef] [Green Version] - Kang, K.-Y. Cryptocurrency and Double Spending History: Transactions with Zero Confirmation. Munich Pers. RePEc Arch.
**2019**, 16, 48. [Google Scholar] - Göbel, J.; Krzesinski, A.E. Increased Block Size and Bitcoin Blockchain Dynamics. In Proceedings of the 27th International Telecommunication Networks and Applications Conference (ITNAC), Melbourne, Australia, 22–24 November 2017. [Google Scholar]
- Ericsson, N.R.; Hendry, D.F.; Hood, S.B. Milton Friedman and Data Adjustment. In IFDP Notes; Board of Governors of the Federal Reserve System: Washington, DC, USA, 2017. [Google Scholar]
- Ball, W.W.R. Probability. In Mathematical Recreations and Essays; Macmillan: New York, NY, USA, 1960; p. 45. [Google Scholar]
- UNDESA. The World Population Prospects 2019: Highlights; Population Division of the UN Department of Economic and Social Affairs: New York, NY, USA, 2019. [Google Scholar]
- Lielacher, A. How Many People Use Bitcoin in 2019? Bitcoin Mark. J.
**2019**, 643, 32. [Google Scholar] - Sedgwick, K. No, Visa Doesn’t Handle 24,000 TPS and Neither Does Your Pet Blockchain. Available online: https://news.bitcoin.com/no-visa-doesnt-handle-24000-tps-and-neither-does-your-pet-blockchain/ (accessed on 15 January 2020).
- Global General Purpose Cards—Midyear 2018, The Nilsen Report. Available online: https://nilsonreport.com/upload/issues/1140_0321.pdf (accessed on 15 January 2020).
- Skene, J.; Lamanna, D.D.; Emmerich, W. Precise Service Level Agreements ICSE ’04. In Proceedings of the 26th International Conference on Software Engineering, Edinburgh, UK, 28 May 2004; pp. 179–188. [Google Scholar]
- Lamanna, D.; Skene, J.; Emmerich, W. SLAng: A Language for Defining. In Proceedings of the Ninth IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS), San Juan, PR, USA, 30 May 2003. [Google Scholar]
- Fisher, I.; Gunnison Brown, H. The Purchasing Power of Money, its Determination and Relation to Credit, Interest and Crises; Nabu Press: Charleston, SC, USA, 2010; pp. 377–381. [Google Scholar]
- Federal Reserve Bank of St. Louis, Velocity of M1 Money Stock, Fred Economic Data, No.2019. Available online: https://fred.stlouisfed.org/series/M1V (accessed on 15 January 2020).
- Bastiaan, M. Preventing the 51%-Attack: A Stochastic Analysis of Two Phase Proof of Work in Bitcoin. Available online: https://www.hmbastiaan.nl/martijn/docs/2015/preventing-the-majority.pdf (accessed on 15 January 2020).

**Figure 1.**Simple illustration of node C receiving coin from B, and verifying with a random selection of 2√n nodes that the coin is not double spent; if B is relying on a previous payment from A, C verifies that transaction too with the same nodes.

**Figure 3.**An example of transactions between two dishonest and two honest nodes, including attempted double-spending.

© 2020 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Schreiber, Z.
*k*-Root-*n*: An Efficient Algorithm for Avoiding Short Term Double-Spending Alongside Distributed Ledger Technologies such as Blockchain. *Information* **2020**, *11*, 90.
https://doi.org/10.3390/info11020090

**AMA Style**

Schreiber Z.
*k*-Root-*n*: An Efficient Algorithm for Avoiding Short Term Double-Spending Alongside Distributed Ledger Technologies such as Blockchain. *Information*. 2020; 11(2):90.
https://doi.org/10.3390/info11020090

**Chicago/Turabian Style**

Schreiber, Zvi.
2020. "*k*-Root-*n*: An Efficient Algorithm for Avoiding Short Term Double-Spending Alongside Distributed Ledger Technologies such as Blockchain" *Information* 11, no. 2: 90.
https://doi.org/10.3390/info11020090