<p>There are two types of double spend. The first is the easy one, solved by nodes validating the chain; the second one is the harder one, and what mining is intended to solve (or at least, disincentivize).</p>
<p>In both Bitcoin and the system you're describing, it is indeed easy to make sure the chain received by nodes does not contain any double spends: just validate all transactions and reject any chain which spends an output that was spent earlier within the same chain. Done.</p>
<p>This however does nothing about the issue of how to make sure you have the same chain as everyone else, and more importantly, have a chain that will be built on by other miners/builders in the future. See, in Bitcoin, you are never <em>completely</em> sure that the (valid) block you have seen will in fact remain part of the accepted chain in the future. It is possible there is another more-work chain out there you simply haven't heard about, and when you do, you'd switch to it. And when you do, a comfirmed transactions may go back to being unconfirmed, or worse, be in conflict with a transaction that is now confirmed in the new chain.</p>
<p>So the hard part has nothing to do with double-spends within one chain, but with ascertaining that there is consensus about what that chain is. Bitcoin does this with the most-work rule, the (otherwise valid) chain with the most accumulated proof of work in it is to be accepted as the active one. This incentivizes miners to work together, because if a block they build isn't built upon by other miners, it becomes worthless (the subsidy/fees from it are lost if it doesn't end up in the active chain).</p>
<p>Could your system work? Possibly, but it depends on the details, and will inevitably work under very different assumptions. First of all, how is your moderator decided, and how do you make sure that everyone agrees on who the moderator is? If not everyone agrees on this, you risk forking off nodes who believe the moderator is someone else. This is a very nontrivial problem, especially in the presence of a potentially flaky network, with potentially malicious actors who may choose to selectively not forward all messages to their peers. In fact, I believe the only solutions to this problem are either having a fixed, trusted, set of controllers who decide the moderator (centralized...), or... using proof-of-work to decide the moderator (which makes it something like DPoW). Second, what do you do when a moderator signs two different blocks at the same height, and sends one version to some nodes, and another version to other nodes? Do they learn about this, communicate with eachother, and then try to &quot;blacklist&quot; the moderator? Then the same problem appears: how do you make sure everyone agrees on this blacklist? There are solutions to this, but they all involve some sort of consensus mechanism to make everyone on the network agree. None of these consensus mechanisms are simple, many are flawed, and they all have their sets of assumptions which may or may not apply in the real world.</p>
<p>So ultimately the issue is that solving double-spending (beyond double spends within the same chain) requires a consensus mechanism. And the solution to the consensus problem in Bitcoin is Proof of Work.</p>

CC BY-SA 4.0
2021-09-19T22:09:58.847Z
2021-09-19T22:45:28.047Z
2021-09-19T22:45:28.047Z
Pieter Wuille
<p>A Proof of Work scheme could theoretically &quot;fail&quot; if a large majority of miners are malicious.</p>
<p>Similarly, your scheme could theoretically &quot;fail&quot; if a large majority of block composers are malicious.</p>
<p>Nakamoto 2008 &quot;solved&quot; the problem of choosing the next miner (Byzantine Generals) by introducing a Deus Ex Machina, the physical energy input.</p>
<p>Similarly, your scheme requires some Deus Ex Machine device who chooses the next block composer fairly (Byzantine Generals) in some way that a group of malicious nodes can't possibly game. If you simply work some &quot;random&quot; algorithm but results pseudorandom for some reason, malicious nodes will eventually figure it out and become a larger share of block composers. Then they start creating private alternative block chains and release them as necessary for them so that, by using transaction reorganization, double spend happens.</p>
<p>If your scheme doesn't support transaction reorganization, then it can not reliably generate blocks at a predictable pace.</p>

CC BY-SA 4.0
2021-09-19T16:52:20.113Z
But wouldn't every node verify that there's no double-spend in the blocks that they receive? That is, they would check every single incoming transaction so that it is not referenced as input to more than one transaction.
Utku
CC BY-SA 4.0
2021-09-19T16:54:31.720Z
Yes, they would, but the problem with double spends is not internal to the system, but external. The double spend problem is not in the system, but in a side effect of the system. The internal solution to double spend is trivial, but the external solution is impossible.
Mercedes
CC BY-SA 4.0
2021-09-19T17:17:32.067Z
Could you expand on what do you mean by "external"? Or point me to some resources?
Utku
CC BY-SA 4.0
2021-09-19T17:59:21.343Z
Yes, of course. By external I just mean, it's related to "outside the system's rules". That is, is the side effect. That is, that means, it seemed I gave you funds, you gave me the goods or services or bearable rights, I created the double spend, so I didn't really gave you the funds, but I'm now running so fast you can't catch me (that's external to the system's rules).
Mercedes
CC BY-SA 4.0
2021-09-19T18:23:45.433Z
So you created a transaction to send me coins, I waited until it is in the chain and then sent you the goods. This should be OK right? The only thing is, the seller might be the bad actor and not send the goods after the transaction is in the chain.
Utku
CC BY-SA 4.0
2021-09-19T18:36:23.743Z
There are things to solve seller fraud, such as multisig refundable deposits, but the solution to the seller fraud problem is off topic in this post. Double spend is a buyer fraud problem.
Mercedes
CC BY-SA 4.0
2021-09-19T16:24:07.680Z
2021-09-22T06:29:30.637Z
2021-09-22T06:29:30.637Z
Mercedes
<p>I'm new to Bitcoin and trying to understand how the double-spending problem can occur and implicitly, the need for &quot;mining&quot;.</p>
<p>Let's say Bitcoin worked the following way:</p>
<ul>
<li>In the network, one node is chosen as the &quot;moderator&quot; node. That is, the responsibility of creating a &quot;block&quot; from the broadcasted transactions lies on this block and nobody else. This &quot;moderator&quot; node is changed every N seconds or every N block creations, etc.</li>
<li>From the pool of unconfirmed transactions, the &quot;moderator&quot; randomly picks 100 transactions. It verifies that they are legitimate (authorized) using the public keys, and it verifies that there is no &quot;double-spend&quot; among the selected transactions and past transactions by looking at the blockchain.</li>
<li>Once it verifies that all transactions are legit, it creates a block simply by putting these transactions together (that is, no mining, nothing. Simply a very fast operation) and broadcasts this block on the network.</li>
<li>Every node that receives the block verifies that it is legitimate. That is, they verify that the transactions are authorized by checking the public key and they verify that there's no double spend either within the new block itself, or within the whole blockchain.</li>
<li>Repeat.</li>
</ul>
<p>So, what's the problem with this scheme? How can &quot;double-spend&quot; occur here and how can &quot;mining&quot; prevent it?</p>

<mining-theory><doublespend>
How can double-spending occur?
Utku
# How can double-spending occur?

(Asked by: username_0 on 2021-09-19)

I'm new to Bitcoin and trying to understand how the double-spending problem can occur and implicitly, the need for "mining".

Let's say Bitcoin worked the following way:

* In the network, one node is chosen as the "moderator" node. That is, the responsibility of creating a "block" from the broadcasted transactions lies on this block and nobody else. This "moderator" node is changed every N seconds or every N block creations, etc.
* From the pool of unconfirmed transactions, the "moderator" randomly picks 100 transactions. It verifies that they are legitimate (authorized) using the public keys, and it verifies that there is no "double-spend" among the selected transactions and past transactions by looking at the blockchain.
* Once it verifies that all transactions are legit, it creates a block simply by putting these transactions together (that is, no mining, nothing. Simply a very fast operation) and broadcasts this block on the network.
* Every node that receives the block verifies that it is legitimate. That is, they verify that the transactions are authorized by checking the public key and they verify that there's no double spend either within the new block itself, or within the whole blockchain.
* Repeat.

So, what's the problem with this scheme? How can "double-spend" occur here and how can "mining" prevent it?

**Tags:** mining-theory, doublespend


---

## 2 answers

### Answer by username_1 on 2021-09-19. Score: 2

There are two types of double spend. The first is the easy one, solved by nodes validating the chain; the second one is the harder one, and what mining is intended to solve (or at least, disincentivize).

In both Bitcoin and the system you're describing, it is indeed easy to make sure the chain received by nodes does not contain any double spends: just validate all transactions and reject any chain which spends an output that was spent earlier within the same chain. Done.

This however does nothing about the issue of how to make sure you have the same chain as everyone else, and more importantly, have a chain that will be built on by other miners/builders in the future. See, in Bitcoin, you are never *completely* sure that the (valid) block you have seen will in fact remain part of the accepted chain in the future. It is possible there is another more-work chain out there you simply haven't heard about, and when you do, you'd switch to it. And when you do, a comfirmed transactions may go back to being unconfirmed, or worse, be in conflict with a transaction that is now confirmed in the new chain.

So the hard part has nothing to do with double-spends within one chain, but with ascertaining that there is consensus about what that chain is. Bitcoin does this with the most-work rule, the (otherwise valid) chain with the most accumulated proof of work in it is to be accepted as the active one. This incentivizes miners to work together, because if a block they build isn't built upon by other miners, it becomes worthless (the subsidy/fees from it are lost if it doesn't end up in the active chain).

Could your system work? Possibly, but it depends on the details, and will inevitably work under very different assumptions. First of all, how is your moderator decided, and how do you make sure that everyone agrees on who the moderator is? If not everyone agrees on this, you risk forking off nodes who believe the moderator is someone else. This is a very nontrivial problem, especially in the presence of a potentially flaky network, with potentially malicious actors who may choose to selectively not forward all messages to their peers. In fact, I believe the only solutions to this problem are either having a fixed, trusted, set of controllers who decide the moderator (centralized...), or... using proof-of-work to decide the moderator (which makes it something like DPoW). Second, what do you do when a moderator signs two different blocks at the same height, and sends one version to some nodes, and another version to other nodes? Do they learn about this, communicate with eachother, and then try to "blacklist" the moderator? Then the same problem appears: how do you make sure everyone agrees on this blacklist? There are solutions to this, but they all involve some sort of consensus mechanism to make everyone on the network agree. None of these consensus mechanisms are simple, many are flawed, and they all have their sets of assumptions which may or may not apply in the real world.

So ultimately the issue is that solving double-spending (beyond double spends within the same chain) requires a consensus mechanism. And the solution to the consensus problem in Bitcoin is Proof of Work.


---

### Answer by username_2 on 2021-09-19. Score: 0

A Proof of Work scheme could theoretically "fail" if a large majority of miners are malicious.

Similarly, your scheme could theoretically "fail" if a large majority of block composers are malicious.

Nakamoto 2008 "solved" the problem of choosing the next miner (Byzantine Generals) by introducing a Deus Ex Machina, the physical energy input.

Similarly, your scheme requires some Deus Ex Machine device who chooses the next block composer fairly (Byzantine Generals) in some way that a group of malicious nodes can't possibly game. If you simply work some "random" algorithm but results pseudorandom for some reason, malicious nodes will eventually figure it out and become a larger share of block composers. Then they start creating private alternative block chains and release them as necessary for them so that, by using transaction reorganization, double spend happens.

If your scheme doesn't support transaction reorganization, then it can not reliably generate blocks at a predictable pace.

> **Comments:**
> **username_0**: But wouldn't every node verify that there's no double-spend in the blocks that they receive? That is, they would check every single incoming transaction so that it is not referenced as input to more than one transaction.  
> **username_2**: Yes, they would, but the problem with double spends is not internal to the system, but external. The double spend problem is not in the system, but in a side effect of the system. The internal solution to double spend is trivial, but the external solution is impossible.  
> **username_0**: Could you expand on what do you mean by "external"? Or point me to some resources?  
> **username_2**: Yes, of course. By external I just mean, it's related to "outside the system's rules". That is, is the side effect. That is, that means, it seemed I gave you funds, you gave me the goods or services or bearable rights, I created the double spend, so I didn't really gave you the funds, but I'm now running so fast you can't catch me (that's external to the system's rules).  
> **username_0**: So you created a transaction to send me coins, I waited until it is in the chain and then sent you the goods. This should be OK right? The only thing is, the seller might be the bad actor and not send the goods after the transaction is in the chain.  
> **username_2**: There are things to solve seller fraud, such as multisig refundable deposits, but the solution to the seller fraud problem is off topic in this post. Double spend is a buyer fraud problem.  

---

