What Is a Blockchain — Why a Ledger With No One in Charge Holds Up

If You Change Yesterday's Line Today

Someone who secretly breaks into someone else's computer has one more job to do after getting in. It is to erase the traces that they came in. Attackers customarily cover their footprints in the records left by the system after an intrusion. This is to make the job of investigators difficult (DOI: 10.14722/ndss.2020.24065).

That record is inside the very machine that was breached. A person who has even entered inside the machine can touch the records as well. The very object that is supposed to tell you what happened is placed within reach of the person who wants to hide that event.

Outside the computer, the shape is the same. Let us say that a warehouse's inventory notebook is written by a warehouse keeper alone and kept by them alone. Even if an item goes missing, if the warehouse keeper fixes the line they wrote yesterday today, the notebook looks as if nothing happened. What comes before our eyes is only today's notebook, and what yesterday's notebook was like is known only to the warehouse keeper.

Bank balances, property registers, and report cards all run because there is a place that takes charge of records like this. While the place in charge is honest, this method is sufficient. The difficulty lies in the fact that there is no way from the outside to notice the moment that honesty goes awry.

Here, a question arises. Even when there is no place taking charge at all, is it possible to make a record that no one can secretly alter or erase? One answer presented to this question is blockchain, the title of this article. That answer is made of three pieces: a seal that makes tampering obvious, a key that reveals who wrote it, and witnesses who decide among themselves which record is the real one. All three pieces are explained on top of a single notebook.

A Notebook That Shows When It Is Tampered With

There is a recording device that does not prevent erasure, but instead makes it apparent. In front of this device, an intruder must choose one of two options. If they leave the records untouched and stay quiet, those records are used in the investigation. If they erase the records, the fact that they erased them is detected (A case study evaluated on a single real-world attack scenario, DOI: 10.14722/ndss.2020.24065).

The property this device has has a name. Tampering detection is a property that does not prevent modification, but makes the fact that something was modified apparent. In a notebook, a seal handles this job. A seal does not stop a hand from tearing it, but it leaves behind the trace of having been torn.

The notebook this article covers also has a name. A ledger is a record that writes down who did what and when in the order it happened. A bank account's transaction history is a ledger, and a warehouse's inventory notebook is also a ledger.

Seals are made with hashes. A hash is something that shrinks any text, no matter how long, down to a single short value of a fixed length. Putting in the same text always produces the same value, and changing even a single letter produces a different value. Hashes are counted among the most important tools in cryptography. They are used for checking whether text is genuine, digital signatures, and electronic time-stamping that proves some text already existed at a certain time (DOI: 10.26483/ijarcs.v11i2.6508). In this article, the value taken by a hash is called a seal value.

For a seal to work, one more thing is needed. It must be absurdly difficult to modify text and still end up with the same seal value. Only then does the fact that the value is the same mean that the text is also the same. This difficulty is continuously tested. A 2020 survey notes that new attacks targeting hashes emerge almost daily, making hash security an important subject, and analyzes attacks targeting specific hashes (DOI: 10.26483/ijarcs.v11i2.6508). A hash acts as a seal only for as long as that difficulty has not been overcome by anyone.

Attaching a seal to each line one by one is not enough. If you lift an entire line out together with that line's seal, no trace is left. Therefore, the seals are linked back and forth.

A block is a compartment containing a batch of records along with the seal value of the preceding batch. In terms of a notebook, it is a page, and at the top of that page is written the seal value of the entire preceding page. A chain is a line formed by each compartment containing the seal value of the previous compartment, linked so that you can retrace your steps all the way to the very beginning.

If you modify a single letter in the middle of a page, that page's seal value changes. Then it stops matching the next page, which has that value written at the top. If you rewrite the value at the top of the next page to the new value, this time the seal value of the next page changes. This is because the seal value is taken over the entire page, including the preceding page's seal value written at the top. In this way, the mismatch propagates to the end in sequence. To modify a single line without leaving a trace, you would have to reseal all the subsequent pages.

When connected like this, the order is also preserved. Because any given page contains the seal value of the preceding page, it can only be created after the preceding page is fully written. Well-known methods of electronic time-stamping also stand on the same principle. They link requests to have timestamps taken to one another, leaving behind the relative order of which came first (DOI: 10.1109/icc.2006.255122). However, what the chain leaves behind is just the before-and-after of the lines already entered. When two conflicting lines try to enter, the chain does not decide which one goes in.

A ledger woven out of blocks into a chain is the skeleton of a blockchain. A 2017 survey defines a blockchain as a ledger that is distributed across multiple places, inspectable by anyone, and unmodifiable. And it places the rule by which multiple parties decide on a single answer at its core (DOI: 10.1109/icaccs.2017.8014672). The word used by the survey is "unmodifiable", but this article reads it as "cannot be modified secretly". What this notebook guarantees through seals alone is simply that if you modify something belatedly, it shows. Sharing the ledger across multiple places and the rule for deciding on a single answer are handled by the third piece, the witness.

Who Wrote It and What Came First

A line enters the notebook: "I transfer my share of 10 to A." The seal tells us that this line has not been changed later. The seal does not tell us who wrote this line.

That role is handled by the digital signature covered in the previous primer "Keys and Locks". A digital signature is a mark that can only be created by the person holding the private key, and can be verified by anyone using the paired public key. The private key is a secret key known only to the owner, and the public key is its counterpart, the key put out for everyone to see. If you attach this signature to every line, anyone holding the notebook can verify who wrote that line.

One problem remains that a signature cannot solve. The same person sends a second line to the notebook: "I transfer the same 10 to myself." Both lines are signed with my private key, so both signatures are genuine, and the verifier passes both.

Double-spending is spending the exact same thing twice. A physical banknote leaves my hand the moment I hand it over, but digital money is a record made of text, so you can send the same line to different parties as many times as you like. In a system run collectively by many, situations arise where people tell conflicting stories to different parties, and Bitcoin's double-spending is a specific case of this. Payment schemes that make the party who told conflicting stories lose money through contracts, later penalizing the double-spender, have also been proposed (DOI: 10.1145/2810103.2813686).

The remaining question is the order. If we recognize only the line written first and reject the conflicting line that came later, the same share is spent only once. To make that happen, everyone holding the notebook must have the same answer as to which of the two lines came first. Bitcoin's public ledger, the blockchain, includes every single transaction precisely to prevent double-spending and protect the integrity of the records (DOI: 10.1109/comst.2018.2818623).

The signature answers who wrote it, and hands off the question of what came first to the third piece.

Carrying the Same Notebook Together

If you remove the single responsible place, the notebook must exist in multiple places. If one place burns down, the others are holding it, and if one place alters yesterday's page, it shows when compared against the remaining copies.

A node is a single computer that holds a complete copy of that ledger and exchanges it with other participants. What we call a witness in this article is a node.

When there are multiple copies, the copies can drift apart, and there is no judge to decide who is right. Consensus is the process by which multiple parties who do not particularly trust each other agree on a single answer for what is currently written in the ledger. A blockchain is a device that allows people who do not fully trust each other to maintain a single ledger together. They agree on what is in the ledger, what that value is, and what history that value has gone through (DOI: 10.1109/tkde.2017.2781227). In terms of a notebook, everyone holds the same answer as to who currently has how much and what lines that share has passed through. The ruling is made by rules that everyone follows instead of a judge.

If you take a majority vote by the number of witnesses, a gap opens up. This is because a single computer can create as many new names as it wants. A Sybil attack is an attack that inflates the head count by mass-producing fake identities. A 2021 risk analysis counts Sybil attacks and double-spending as the two most concerning security risks in blockchains (DOI: 10.1109/access.2021.3081998).

Proof of work is a method that requires paying a large amount of computation first in order to attach the next block to the chain. The computation you pay is a calculation to match a seal. Until the seal value of the next page meets a pre-arranged condition, you repeatedly stamp the seal while slightly changing the content of the page. You cannot know in advance which content will yield the correct value, so you have no choice but to keep stamping until it hits.

Therefore, the weight of a witness is counted by the amount of computation paid instead of the head count. Identities can be increased for free, but computation cannot be increased for free. Bitcoin's core technology also lies in matching transaction records and preventing double-spending using a blockchain and hash-based proof of work (DOI: 10.48550/arxiv.1402.2009, preprint).

That does not mean fake identities become useless. Witnesses compete over who seals the next page first. A 2019 attack model analysis finds a gap in this competition. Double-spending is difficult to succeed at without massive computing power. However, if you set up a mass of fake identities to delay the spread of new blocks, the attacker's probability of winning the race to attach the next block goes up, making it possible to succeed in double-spending. The analysis also calculates that success probability and the point where the attack starts to become profitable (DOI: 10.1109/tii.2019.2921566).

The party that pays the computation receives a reward, and in exchange for that reward, they are expected to maintain the ledger honestly. Bitcoin's safety heavily relies on this proof-of-work-based consensus protocol, where rewards are aligned to point in the same direction as honesty (DOI: 10.1109/comst.2018.2842460).

What that reward is, why the party paying the computation pays that cost, and how much that value is will be covered in the next installment, "The Right to Write a Line in the Ledger". In this notebook, the weight of a witness is measured by the amount of computation paid.

Saying That Something Cannot Be Reversed Is a Probability

A notebook can branch into two books behind either side. A fork is when a chain splits into two branches behind a certain square. This happens even without an attack when two witnesses seal the next page at nearly the same time, or someone can create it on purpose. Up to the split point, both branches are identical, and different sides are attached thereafter. In a notebook that uses proof of work, if the witnesses split into two branches, they follow the branch with more accumulated computation. When one of the two branches is discarded, the lines written on the discarded side also never happened.

There is an attack that aims at this split. For the attacker's branch to win, it must attach pages to its own branch faster than all honest witnesses attach pages to the original branch. Therefore, a party holding more than half of the network's total computing power can split the chain and perform a double spend. They can spend the same share twice, block transactions, and cancel already attached squares (DOI: 10.3390/app9091788). When computing power gathers in one hand to exceed half, that single hand can rewrite the pages that witnesses have guarded.

A 2019 analysis records these two faces of the attack together. The cost required is so astronomical that for a long time it was considered very unlikely to happen. However, around the time that analysis came out, it actually occurred with frequent frequency and inflicted millions of dollars in losses on several cryptocurrencies. Cryptocurrencies with low computing power are always vulnerable to this attack because that computing power can be easily obtained (DOI: 10.3390/app9091788).

The situation on the defending side is also in the same analysis. The authors review five of the most advanced protection techniques and conclude that in most cases, these techniques do not provide practical protection. This is because the weaknesses are inherited from the consensus protocol itself (DOI: 10.3390/app9091788).

Finality is the state in which a recorded record can be seen as no longer reversible. For the receiving party, the question of when it is okay to hand over an item is directly this question.

The answer comes out as a probability. As more pages are attached behind the page containing my line, the number of pages that the branch trying to erase that line must catch up to also increases. Therefore, the longer you wait, the lower the probability of being reversed, but it does not completely disappear. Regarding this probability, a 2014 preprint notes that while this system is well understood qualitatively, there is widespread confusion on the quantitative side, and calculates the success probability of a typical attack (DOI: 10.48550/arxiv.1402.2009, preprint). The probability that a double-spend attack will succeed can be calculated. The results can help determine what to trade off between the risk of a double-spend attempt and the waiting time before accepting a transaction. The same calculation can also be used by the side paying for the computation to formulate a strategy to increase their share (DOI: 10.1109/jiot.2020.3004273).

The waiting time was not short. In a 2012 analysis, Bitcoin's payment verification method was designed to prevent double spending, but verifying a single transaction took tens of minutes. This means it was not suited for fast payments where goods and money move in a few seconds. The implementation at the time did not include proper detection techniques to catch double spending, and as it stood, double-spend attacks in fast payments succeeded with overwhelming probability and low cost (DOI: 10.1145/2382196.2382292).

There is also the latter part of the same analysis. The authors showed that the countermeasures recommended by developers at the time did not consistently catch double spending, and noted that even if those recommendations were incorporated into future implementations, attacks would still be possible. And they directly proposed and implemented a modification that guarantees the detection of double spending in fast payments (DOI: 10.1145/2382196.2382292).

The property of being irreversible is a probability traded off against waiting time, and that probability stands on the condition that computing power has not gathered in one hand to exceed half.

What the Seal Does Not Guarantee and the Price Paid

Bitcoin ran into performance problems of low throughput and long transaction latencies. This means that few transactions are processed in a given amount of time, and it takes a long time from sending a transaction to it entering the ledger. Other cryptocurrencies based on proof-of-work inherited the same flaw. Whether this performance can be maintained as the number of users grows is the scalability problem, and several solutions have emerged to address it, which a survey organizes by dividing them according to which layer of the system is fixed (DOI: 10.1109/access.2020.2967218).

Blockchains that limit participants to pre-verified people are also appearing in industrial settings. A 2021 risk analysis discusses how such systems handle the security and implementation challenges that block the adoption of blockchains (DOI: 10.1109/access.2021.3081998). Because someone must take charge of verifying participants, entities in charge are created anew to that extent.

There is also a heavy cost in performance. A database is a conventional computerized record-keeping system managed by a single entity. When three permissioned blockchains were compared in terms of data processing load, there was a large performance gap between blockchains and databases. What is gained and lost varies depending on how the system is designed, and research directions borrowing database design principles to narrow that gap are also being discussed (DOI: 10.1109/tkde.2017.2781227).

There is a price attached to the connection method itself. In time-stamping, the approach of chaining requests together has three flaws. It does not scale well as requests increase, measures time only in coarse ticks, and has high latency. Therefore, alternative methods overcoming those flaws have also been proposed (DOI: 10.1109/icc.2006.255122). How much of a cost the computations of proof-of-work entail is the subject of the next part.

Apart from the costs, there are things this system does not guarantee from the start. A 2019 overview from operations management places five strengths and five corresponding weaknesses side by side. The strengths are visibility, aggregation, verification, automation, and resilience. The weaknesses are lack of privacy, lack of standards, garbage in, garbage out, the black box effect, and inefficiency (DOI: 10.1287/msom.2018.0752).

The third weakness speaks to the limit of the seal. If you put something wrong in at the beginning, what comes out is wrong just the same. The seal does not guarantee that the recorded contents are true. If you record a falsehood and seal it, fixing it becomes a falsehood that is equally expensive.

This limitation is clearly revealed in accounting. Digital currency on a blockchain exists only within that ledger. On the other hand, the economic transactions that accounting deals with happen outside of accounting records. A 2017 accounting analysis argues that because of this gap, an acceptable level of transaction verification is not achieved. Thus, it concludes that even if blockchains successfully built a digital currency network without a center, becoming a safer alternative to current accounting ledgers is not feasible. The authors write that the advantages making blockchains ostensibly tamper-proof cannot be fully utilized or trusted in an accounting environment (DOI: 10.2308/jeta-51910).

The fact that every line is visible to every witness is also a cost. Bitcoin is considered to provide anonymity by using pseudonyms instead of real names, but it is one of the most transparent payment networks where all transactions are public. The ledger data allows observers to track the flow of money and user activity, and combining it with external data can expose identities. Several expansions and alternatives to enhance anonymity and privacy have also been proposed (DOI: 10.1109/comst.2018.2818623).

Researchers who reviewed the issue of applying this technology to government work in 2017 view the benefits touted in literature as exaggerated and evaluate them critically. They appeal for a shift from the approach of introducing technology first and looking for a use case, to the approach of tailoring technology to what the business needs. They also write that establishing who operates this system under what rules and with what responsibility—in other words, a sound governance model—was a condition for realizing the benefits (DOI: 10.1016/j.giq.2017.09.007).

If a trustworthy place is already in charge of keeping records and there is a way to verify that trust, the rationale for separately bringing in this system, which is slower than a database, is weak. If there is a place where this system is worth trying, it is where there is no trustworthy place at all, or where even if there is one, there is no way to verify its trust. Even in such places, that 2017 government review notes purpose-fit design and sound governance as conditions for benefits (DOI: 10.1016/j.giq.2017.09.007).

There is a question left by "Keys and Locks": who guards the certificate authority, the entity that issues certificates—name tags guaranteeing that a website is genuine? This question is also one of the places where this system has been tried. A 2020 proposal paper notes that recent security incidents show certificate authorities can sign fraudulent certificates, whether attacked or of their own accord. It therefore proposes putting certificates and their revocation status onto a public blockchain to check the absolute authority of certificate authorities (DOI: 10.1109/tdsc.2020.2983022).

In this proposal, that ledger acts as an append-only public record monitoring the signatures and revocations of certificate authorities. Browsers accept a received certificate only when it is listed on that ledger and has not been revoked. The authors claim that this approach significantly strengthens the security guarantees of certificates, and report that the overhead of the prototype was at a manageable level (DOI: 10.1109/tdsc.2020.2983022). As "Keys and Locks" noted, there is no single answer to this question, and this proposal is one of those answers. Another path that allows anyone to view all issuances in a record without a blockchain is covered by "What Does the Padlock in Your Address Bar Actually Guarantee? — Instead of Picking a Trustworthy Authority, the Web Decided to Write Every Issuance Down".

Until a Line Goes Into the Notebook and Hardens

Now let's try writing a line in the notebook.

"I am transferring my share of 10 to Ga." I sign this line with my private key and send it to the witnesses. The witnesses verify that signature with my public key. Who wrote this line is decided right here.

This line is not yet in any page of the notebook. One of the witnesses performs a calculation to guess the seal, creates the next page, includes this line on that page, and writes the seal value of the previous page at the very top of the page. The other witnesses receive that page and attach it to their own copies.

The remaining question for Ga is when to hand over the item. There is a trade-off between the risk of double-spending and the waiting time, and the probability calculation we saw earlier can help the recipient decide that trade-off (DOI: 10.1109/jiot.2020.3004273). A 2012 analysis showed that verification took tens of minutes. In settings where items were handed over in just a few seconds without proper detection techniques, double-spending succeeded with overwhelming probability (DOI: 10.1145/2382196.2382292).

The next day, suppose someone tries to alter this line from yesterday's page to read "I am transferring the same 10 to myself." If the letters on that page change, the seal value of that page changes, and from the next page where that value was written all the way to the end, everything becomes mismatched. Comparing it with the copies held by the witnesses reveals which page was altered. This is as far as the seal goes.

The altered page and the pages after it must guess their seals anew to become a chain again. Meanwhile, honest witnesses keep attaching new pages to the end of the original branch, so for the altered branch to get ahead, it must calculate faster than all of them combined. Witnesses follow the branch where more accumulated calculations are piled up, and a party that holds over half of the network's total computing power can fork the chain and carry out a double-spend (DOI: 10.3390/app9091788). If the altered branch survives and the original branch is discarded, the 10 that was passed to Ga never happened. This attack has a massive cost and has long been considered highly unlikely to occur. However, cryptocurrencies with low total network computing power make it easy to acquire that computing power, leaving them constantly vulnerable, and a 2019 analysis concluded that five preceding protection techniques do not provide practical protection in most cases (DOI: 10.3390/app9091788).

And what this notebook protects is the written line. Events that happen outside the notebook, such as the item Ga handed over, are not verified inside the notebook (DOI: 10.2308/jeta-51910).

What protected this single line were the seal, the signature, and the witnesses' calculations. That protection stood on the conditions that computing power was not concentrated in one hand beyond half, and that Ga chose to trade off waiting time against risk. "Keys and Locks" wrote this about locks: it is merely made so expensive that no one can yet pay the unlocking value, not proven impossible to open. If that value becomes cheap, the lock weakens along with it. This notebook, too, is merely made expensive to alter, not proven impossible to alter. The difference is that the value of this notebook has actually become cheap at times. That value depends on how easily a majority of computing power can be gathered, and in cryptocurrencies where the network's total computing power is low, a majority can be easily acquired, leaving them constantly vulnerable to this attack (DOI: 10.3390/app9091788).

The remaining question is who takes the turn to write the next page in this notebook, and at what cost. The next installment, "The Right to Write a Line in the Ledger", takes up that question.

Where to Look Next

How many lying witnesses can be mixed in while still reaching a single answer was not covered in this article. "Consensus Without Trust — How Mutually Distrusting Participants Agree on One Ledger" (/articles/consensus-without-trust-basics) takes that entire place.

Whether the witnesses are actually scattered, and where the computing power is gathered, is measured by "Is Blockchain Really Decentralized — From Mining Pools to MEV, Where Power Reassembles" (/articles/blockchain-decentralization-debate).

The proposal to vote with an unfixable ledger is matched one by one against the requirements of an election in "If We Voted on a Blockchain, Nobody Could Tamper With It — Right? Make It Checkable, but Provable to No One" (/articles/electronic-voting-verifiability).

Another path to protect the issuer of a name tag, the decision to have every issuance written down in a record anyone can see, is in "What Does the Padlock in Your Address Bar Actually Guarantee? — Instead of Picking a Trustworthy Authority, the Web Decided to Write Every Issuance Down" (/articles/certificate-transparency).

Source Papers

Preprints are marked with their rating in the body.

• "Custos: Practical Tamper-Evident Auditing of Operating Systems Using Trusted Execution" (2020) — DOI: 10.14722/ndss.2020.24065 — After an intrusion, attackers routinely erase their traces from system logs. Using tamper-evident logging and a decentralized auditing protocol, real-world APT attack scenario case studies drive attackers into a "catch-22" of either hiding (preserving logs) or erasing and being detected.
• "Cryptographic Hash Functions and Attacks – A Detailed Study" (2020) — DOI: 10.26483/ijarcs.v11i2.6508 — Hash functions compress inputs of arbitrary length into fixed-length strings. As one of cryptography's most important tools, they are used for authenticity, signatures, and timestamps, and have become a security-critical subject as they face new attacks almost daily. Attack classification and analysis of specific hash attacks.
• "A Scalable and Intrusion-tolerant Digital Time-stamping System" (2006) — DOI: 10.1109/icc.2006.255122 — Well-known timestamp systems are based on a chaining method that links requests together to provide a relative time sequence, but they do not scale well to high volumes of requests, have coarse granularity, and suffer from high latency. We propose an alternative approach based on real-time timestamps.
• "Survey of consensus protocols on blockchain applications" (2017) — DOI: 10.1109/icaccs.2017.8014672 — Blockchains are distributed, transparent, and unalterable ledgers, with consensus protocols as their core.
• "Liar, Liar, Coins on Fire!" (2015) — DOI: 10.1145/2810103.2813686 — A contract that financially deters equivocation in distributed protocols. Bitcoin's double-spending is a special case of this, and we design a payment protocol that imposes retroactive penalties on the party that double-spends.
• "A Survey on Anonymity and Privacy in Bitcoin-Like Digital Cash Systems" (2018) — DOI: 10.1109/comst.2018.2818623 — Public ledgers contain all transactions to prevent double-spending and ensure integrity. Although perceived as anonymous due to pseudonyms, it is one of the most transparent payment networks, and identities can be revealed when combined with external data. We review proposals for improving anonymity and privacy.
• "Untangling Blockchain: A Data Processing View of Blockchain Systems" (2018) — DOI: 10.1109/tkde.2017.2781227 — A distributed ledger in which parties who do not completely trust each other jointly maintain a global state and agree on its existence, values, and history. Benchmarks across three permissioned blockchain systems with authenticated participants reveal design tradeoffs and a large performance gap with databases. We discuss research directions to narrow the gap.
• "Exploring Sybil and Double-Spending Risks in Blockchain Systems" (2021) — DOI: 10.1109/access.2021.3081998 — Treating Sybil and double-spending as the two most concerning risks, we outline threats, vulnerabilities, and defenses. We identify security and implementation challenges that hinder adoption and discuss how permissioned blockchains, which have emerged in industrial settings, address these challenges (without proving their effectiveness).
• "Analysis of Hashrate-Based Double Spending" (2014, preprint) — DOI: 10.48550/arxiv.1402.2009 — Bitcoin's core innovation is synchronizing transactions and preventing double-spending using a blockchain and hash-based proof-of-work. While understood qualitatively, widespread confusion persists around quantitative aspects, so we analyze the stochastic process and success probability of typical attacks.
• "A Survey on Security and Privacy Issues of Bitcoin" (2018) — DOI: 10.1109/comst.2018.2842460 — Bitcoin records all transactions in a distributed, append-only public ledger, and its security relies heavily on an incentive-aligned, proof-of-work-based distributed consensus protocol. Participants are expected to maintain the ledger honestly in exchange for incentives.
• "Assessing Blockchain Consensus and Security Mechanisms against the 51% Attack" (2019) — DOI: 10.3390/app9091788 — Having more than half of the computing power allows splitting the chain to double-spend, restrict transactions, and cancel blocks. Long considered too costly and rare, these attacks have occurred frequently in recent times, causing millions of dollars in losses. Cryptocurrencies with low computing power are perpetually vulnerable. Five previous protection mechanisms mostly fail to provide practical protection because they inherit their weaknesses from the consensus protocol.
• "Bitcoin and Blockchain: Security and Privacy" (2020) — DOI: 10.1109/jiot.2020.3004273 — Analysis of double-spending success probability and attack profitability. The results establish a tradeoff between the risk of double-spending and the waiting time (or confidence) before accepting a transaction, and can also be used by miners to formulate profit strategies.
• "Double-spending fast payments in bitcoin" (2012) — DOI: 10.1145/2382196.2382292 — Verification takes tens of minutes, making it unsuitable for fast payments. Without proper detection mechanisms, double-spending in fast payments succeeds at low cost with overwhelming probability. Developer recommendations are not always effective, and even when implemented, attacks remain possible. We propose and implement a modification that guarantees detection.
• "Double-Spending With a Sybil Attack in the Bitcoin Decentralized Network" (2019) — DOI: 10.1109/tii.2019.2921566 — While double-spending is difficult without massive computing power, slowing down block propagation via a Sybil attack increases the probability of winning the block race, enabling a new attack model for double-spending. We analyze the success probability and the attacker's break-even point.
• "Solutions to Scalability of Blockchain: A Survey" (2020) — DOI: 10.1109/access.2020.2967218 — Bitcoin's low throughput and high transaction latency. Other proof-of-work-based cryptocurrencies inherit the same flaw. We classify scaling solutions by layer.
• "OM Forum—Distributed Ledgers and Operations" (2019) — DOI: 10.1287/msom.2018.0752 — Five strengths (visibility, aggregation, verification, automation, and resilience) and five corresponding weaknesses (lack of privacy, lack of standards, garbage in garbage out, black box effect, and inefficiency).
• "Can Blockchains Serve an Accounting Purpose?" (2017) — DOI: 10.2308/jeta-51910 — While blockchains have successfully created decentralized digital currency networks, they are not feasible as a safer alternative to accounting ledgers. Digital currencies reside solely within the ledger, but economic transactions occur outside of it, making transaction verification impossible, and even apparent immutability cannot be fully utilized or trusted in an accounting environment.
• "Blockchain in government" (2017) — DOI: 10.1016/j.giq.2017.09.007 — A critical evaluation of the exaggerated benefits found in the literature. We call for a shift from technology-led to need-led adoption and identify sound governance as a precondition for realizing benefits.
• "Blockchain-Based Certificate Transparency and Revocation Transparency" (2020) — DOI: 10.1109/tdsc.2020.2983022 — Based on recent incidents where Certificate Authorities were (compromised and) able to sign fraudulent certificates, we propose placing certificates and their revocation status onto a certificate blockchain to check the absolute authority of Certificate Authorities. Browsers accept only certificates that are published and not revoked. The overhead of the prototype is at a reasonable level.