user133537: If there is double spending occuring, I don't understand why the longest chain rule would decrease the likelihood for only one transaction to be confirmed.
Can someone explain step by step why this makes sense logically? I've scoured through youtube videos but they do not explain the logic behind this. The videos only describes using the longest chain rule.
I also have one additional question. Are all the miners also verifying that the block that is solved is correct once it's solved?

user13866: Double spending
Suppose Alice has a bitcoin, an unspent transaction output (UTXO) worth 1.001 BTC.
Using a computer in Chicago, Alice creates a transaction that uses that UTXO to pay 1 BTC to Bob.
Using remote access to a computer in Tokyo, Alice creates a transaction that uses that same UTXO to pay 1 BTC to Carol.
Alice is a bad person and is trying to cheat either Bob or Carol.
A Miner in Chicago sees the Chicago transaction and mines a new block containing the transaction which pays Bob.
A Miner in Tokyo sees the Tokyo transaction and mines a new block containing the transaction which pays Carol.
People in Chicago see the Chicago block which pays Bob
People in Tokyo see the Tokyo block which pays Carol
People in Chicago see the Tokyo block and reject it as a double spend because the UTXO has already been used to pay Bob not Carol
People in Tokyo see the Chicago block and reject it as a double spend because the UTXO has already been used to pay Carol not Bob
Now half the world thinks Bob was paid and half the world thinks Carol was paid. Unless we have some way to put these blocks, and the transactions in them, into the same order everywhere in the world, the bitcoin network will fall into chaos.
We need some way to sort the Tokyo and Chicago blocks into an order which does not depend on how near you are to Tokyo or Chicago. This way everyone can agree whether Bob has the 1 BTC or Carol does. Then Alice does not get to use her money twice.

Validation
After creating a new block with a hash less than the target,  miners don't need to verify or validate the blocks they produce because they already validated everything before starting to mine.
All nodes, whether wallets, miners or other types, validate as much data as they can as soon as they receive it. No node cares whether other nodes validate anything because no full-node trusts any other node.
Validation is different from confirmation. Confirmation is simply a count of how many blocks have been mined since the block containing a transaction. The block that contains the transaction is included in the count.

user77103: What's exactly the double-spending problem? How does Bitcoin deal with it?
In one word: already-spent money should not magically come back to be spent yet again.

You may already know that Bitcoin's ledger, called a blockchain, is public, which keeps track of the transacting history of all bitcoins ever existed, up to where it was initially generated. (in other words, "mined", in a special type of transaction, aka "coinbase transaction") Obviously we (actually, everyone - again, the blockchain ledger is public) can verify whether a miner is following rules, like, the rule which disallows generating arbitrary amount of new bitcoins out of thin air. Or in other words, everyone can validate the content of the blockchain ledger, from the genesis block to the latest chain tip. It's clear that every coin has its own origin.

With the help of digital signature, we (same as above, everyone actually) can verify whether a transaction, which essentially transfers the ownership of coins (UTXOs), is valid.

In the blockchain ledger, it's easy to spot an invalid transaction which spends a nonexistent coin, no matter it's already spent or just never existed at all. Practically full node software generally maintains a database called "UTXO set" which essentially stores the ownership of every currently existing bitcoin. Determining whether an UTXO exists in the UTXO set is almost instant. (There once were software bugs like CVE-2018-17144 which erroneously allows spending an already-spent coin once again, however it had been quickly fixed as soon as it was discovered and reported to the developers.)


Yes, blockchain data is gigantic - however full node software actually does not need to deal with old blocks at all, because, you just need to take good care of the UTXO set (which is just the "current balances"), instead of the whole gigantic history. A brand new full node does still needs to download and verify all blocks, but this only needs to happen for one time, after which the UTXO set will be established and kept up-to-date.

Here we meet the real "double spending" problem. What if a malicious party creates an alternative (and dishonest) version of blockchain ledger, which includes the malicious/dishonest (but valid according to the consensus rules!) transaction which says "Alice paid 3 BTC to herself" (or other people - which is equivalent to the case that Alice paid herself because Alice still essentially "gets her already-spent money back to spend again"), but not the original/honest (also valid) transaction which says "Alice paid 3 BTC to Bob"? How does one tell which version of the blockchain ledger is the "correct" one? That's the real problem Bitcoin faces - instead of the trivial case mentioned above.

Here comes the alleged "longest chain rule"

To address the problem mentioned above, Bitcoin just takes the simple and effective approach: choose the chain with the most accumulated proof-of-work (yes, actually it's not "the longest", that was a mistake even Satoshi Nakamoto himself had once made and then corrected) as the "correct" one.

If every honest node follows the protocol to always find and follow  the chain with the most accumulated work in their own view, they will finally converge to work on one single commonly accepted chain, which is the "consensus" to make Bitcoin actually exist.


Why Proof-of-Work
Just as the name suggests, mining a block has considerable costs in real world (which makes the miners think twice), which is also resistant to fakery. It's trivial to verify, as easy as calculate the hash (for only one time - while mining a new block requires billions of calculations) and count how many leading zeroes are there.
Why are the miners willing to do the boring transaction validation job? Why aren't miners themselves cheating (ignoring/breaking the rules)?
As a miner you have to invest considerable resource to mine a block. A miner is supposed to be "greedy" - make as much money with as little cost as possible. Then, as an individual miner what you faces is a prisoners' dilemma: although the transaction validation job is not hard, obviously not doing this at all takes even less effort, doesn't it? However, as a rational miner (who is also supposed to consist of just negligible part of bitcoin hashpower) you can almost certainly realize the fact that you cannot overwhelm the whole rest part of bitcoin hashpower (which is also not supposed to cooperate with you). If you as a negligible individual decide to skip the validation job (or even include invalid transactions on purpose), other miners who does this job will soon find invalidity in your block (if your block has any invalidity), then all your invested resources are now worth zero because other miners keep extending on valid blockchain, instead of your invalid one. After all, just as mentioned above, validating the blockchain ledger is not hard. Not only miners, but also users, can do this - just run a full node.
Are miners also verifying that the block that is solved is correct once it's solved?

An honest miner extends only the valid most PoW chain in his view. In other words, he always make his best efforts to find such valid most PoW chain, all the time.

Due to the "memoryless" nature of mining, it costs nothing to "give up work on previous base" - there's actually no "previous work" to give up.

For him to win the reward of newly generated bitcoins (plus transaction fees collected within a block), he obviously does not need to verify the transactions which his new block will include over and over again. With the UTXO set he can instantly know whether a transaction is valid (rule-compliant) and then eligible for inclusion. In practice, full node software typically maintains a pool which contains such eligible (and valid of course) transactions, as known as "mempool".

Actually the mining "rigs" don't have to deal with the full block data at all - all the validation job is supposed to be done by the mining pool (which is also a full node of Bitcoin network - also, in principle technically anyone can run a pool, however in reality running a public pool is also related to engineering and economics) already. All the included transactions finally yields a Merkle root in the block header, then the block header (which contains the nonce field) is theoretically the only thing the mining rigs needs to deal with. (In practice the nonce of Bitcoin block header quickly runs out, therefore the coinbase transaction is also fed to the "rig" machine.) However, on the other hand, this is also the long blamed (re)centralizing problem of Bitcoin in reality - after all, just as mentioned above, the mining rigs themselves do not validate (the whole) block, and, a miner who does not rely on his own full node also (blindly) trusts the public mining pool operators. To address (or relieve, at least) this problem, new mining protocols which enable the miners (who in reality trust/rely on public pool operators) to also validate blocks like StratumV2 have been proposed.


What if a malicious miner chooses to mine a "valid (rule-compliant) but dishonest" (double-spending) alternative chain, instead of an "invalid (rule-breaking) chain" which is always apparent & easy to spot?
Finally, we meet the real double-spending problem and the so-called 51% attack.
Since the dishonest chain is also compliant with rules, for any bystander who hasn't witnesses the whole genuine history (which is also not practical/possible due to reasons like network latency), it's hard/impossible to tell which chain should be the "correct" one.
However, with the most-accumulated-proof-of-work rule, at least the payee can choose to wait for more confirmations (how many later blocks has been appended to the block which includes the payment) to make his risks lower, as long as the supposed attacker does not control > 50% of all bitcoin hashpower. Just as the calculations in the Bitcoin whitepaper by Satoshi Nakamoto, the chance/probability for the double-spending attacker to succeed will drop dramatically as the confirmation number grows, as long as the attacker only controls < 50% of hashpower.
What if the double spending attack finally succeeds?
Technically, the payee obviously loses the payment he was originally supposed to gain - no new coins will be created out of thin air, of course.
However, there will be much more subtle implications once a double spending attack succeeds, which are hard to tell.

133537: <p>If there is double spending occuring, I don't understand why the longest chain rule would decrease the likelihood for only one transaction to be confirmed.</p>
<p>Can someone explain step by step why this makes sense logically? I've scoured through youtube videos but they do not explain the logic behind this. The videos only describes using the longest chain rule.</p>
<p>I also have one additional question. Are all the miners also verifying that the block that is solved is correct once it's solved?</p>
 13866: <h2>Double spending</h2>
<p>Suppose Alice has a bitcoin, an unspent transaction output (UTXO) worth 1.001 BTC.</p>
<p>Using a computer in Chicago, Alice creates a transaction that uses that UTXO to pay 1 BTC to Bob.</p>
<p>Using remote access to a computer in Tokyo, Alice creates a transaction that uses that same UTXO to pay 1 BTC to Carol.</p>
<p>Alice is a bad person and is trying to cheat either Bob or Carol.</p>
<p>A Miner in Chicago sees the Chicago transaction and mines a new block containing the transaction which pays Bob.</p>
<p>A Miner in Tokyo sees the Tokyo transaction and mines a new block containing the transaction which pays Carol.</p>
<p>People in Chicago see the Chicago block which pays Bob</p>
<p>People in Tokyo see the Tokyo block which pays Carol</p>
<p>People in Chicago see the Tokyo block and reject it as a double spend because the UTXO has already been used to pay Bob not Carol</p>
<p>People in Tokyo see the Chicago block and reject it as a double spend because the UTXO has already been used to pay Carol not Bob</p>
<p>Now half the world thinks Bob was paid and half the world thinks Carol was paid. Unless we have some way to put these blocks, and the transactions in them, into the same order everywhere in the world, the bitcoin network will fall into chaos.</p>
<p>We need some way to sort the Tokyo and Chicago blocks into an order which does not depend on how near you are to Tokyo or Chicago. This way everyone can agree whether Bob has the 1 BTC or Carol does. Then Alice does not get to use her money twice.</p>
<hr />
<h2>Validation</h2>
<p>After creating a new block with a hash less than the target,  miners don't need to verify or validate the blocks they produce because they already validated everything before starting to mine.</p>
<p>All nodes, whether wallets, miners or other types, validate as much data as they can as soon as they receive it. No node cares whether other nodes validate anything because no full-node trusts any other node.</p>
<p>Validation is different from confirmation. Confirmation is simply a count of how many blocks have been mined since the block containing a transaction. The block that contains the transaction is included in the count.</p>
 77103: <h3>What's exactly the double-spending problem? How does Bitcoin deal with it?</h3>
<p><strong>In one word: already-spent money should not magically come back to be spent yet again.</strong></p>
<ol>
<li><p>You may already know that Bitcoin's ledger, called a blockchain, is public, which keeps track of the transacting history of all bitcoins ever existed, up to where it was initially generated. (in other words, &quot;mined&quot;, in a special type of transaction, aka &quot;coinbase transaction&quot;) Obviously we (actually, everyone - again, the blockchain ledger is public) can verify whether a miner is following rules, like, the rule which disallows generating arbitrary amount of new bitcoins out of thin air. Or in other words, everyone can validate the content of the blockchain ledger, from the genesis block to the latest chain tip. It's clear that every coin has its own origin.</p>
</li>
<li><p>With the help of digital signature, we (same as above, everyone actually) can verify whether a transaction, which essentially transfers the ownership of coins (UTXOs), is valid.</p>
</li>
<li><p>In the blockchain ledger, it's easy to spot an invalid transaction which spends a nonexistent coin, no matter it's already spent or just never existed at all. Practically full node software generally maintains a database called &quot;UTXO set&quot; which essentially stores the ownership of every currently existing bitcoin. Determining whether an UTXO exists in the UTXO set is almost instant. (There once were software bugs like CVE-2018-17144 which erroneously allows spending an already-spent coin once again, however it had been quickly fixed as soon as it was discovered and reported to the developers.)</p>
</li>
</ol>
<p><em>Yes, blockchain data is gigantic - however full node software actually does not need to deal with old blocks at all, because, you just need to take good care of the UTXO set (which is just the &quot;current balances&quot;), instead of the whole gigantic history. A brand new full node does still needs to download and verify all blocks, but this only needs to happen for one time, after which the UTXO set will be established and kept up-to-date.</em></p>
<ol start="4">
<li><strong>Here we meet the real &quot;double spending&quot; problem.</strong> What if a malicious party creates <strong>an alternative (and dishonest) version of blockchain ledger</strong>, which includes the malicious/dishonest <strong>(but valid according to the consensus rules!)</strong> transaction which says &quot;Alice paid 3 BTC to herself&quot; (or other people - which is equivalent to the case that Alice paid herself because Alice still essentially &quot;gets her already-spent money back to spend again&quot;), but not the original/honest (also valid) transaction which says &quot;Alice paid 3 BTC to Bob&quot;? <strong>How does one tell which version of the blockchain ledger is the &quot;correct&quot; one?</strong> That's the real problem Bitcoin faces - instead of the trivial case mentioned above.</li>
</ol>
<h3>Here comes the alleged &quot;longest chain rule&quot;</h3>
<ol>
<li><p>To address the problem mentioned above, Bitcoin just takes the simple and effective approach: choose the chain with <strong>the most accumulated proof-of-work</strong> (yes, actually it's <strong>not &quot;the longest&quot;</strong>, that was <a href="https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3" rel="nofollow noreferrer">a mistake</a> even Satoshi Nakamoto himself had once made and then corrected) as the &quot;correct&quot; one.</p>
</li>
<li><p>If every honest node follows the protocol to always find and follow  the chain with the most accumulated work in their own view, they will finally converge to work on one single commonly accepted chain, which is the &quot;consensus&quot; to make Bitcoin actually exist.</p>
</li>
</ol>
<h3>Why Proof-of-Work</h3>
<p>Just as the name suggests, mining a block has <strong>considerable costs in real world</strong> (which makes the miners think twice), which is also <strong>resistant to fakery</strong>. <strong>It's trivial to verify</strong>, as easy as calculate the hash (for only <strong>one</strong> time - while mining a new block requires billions of calculations) and count how many leading zeroes are there.</p>
<h3>Why are the miners willing to do the boring transaction validation job? Why aren't miners themselves cheating (ignoring/breaking the rules)?</h3>
<p>As a miner you have to invest considerable resource to mine a block. A miner is supposed to be &quot;greedy&quot; - make as much money with as little cost as possible. Then, as an individual miner what you faces is a prisoners' dilemma: although the transaction validation job is not hard, obviously not doing this at all takes even less effort, doesn't it? However, as a rational miner <strong>(who is also supposed to consist of just negligible part of bitcoin hashpower)</strong> you can almost certainly realize the fact that <strong>you cannot overwhelm the whole rest part of bitcoin hashpower (which is also not supposed to cooperate with you).</strong> If you as a negligible individual decide to skip the validation job (or even include invalid transactions on purpose), other miners who does this job will soon find invalidity in your block (if your block has any invalidity), then all your invested resources are now worth zero because other miners keep extending on valid blockchain, instead of your invalid one. After all, just as mentioned above, <strong>validating the blockchain ledger is not hard. Not only miners, but also users, can do this - just run a full node.</strong></p>
<h3>Are miners also verifying that the block that is solved is correct once it's solved?</h3>
<ol>
<li><p>An honest miner extends only the valid most PoW chain in his view. In other words, <strong>he always make his best efforts to find such valid most PoW chain, all the time.</strong></p>
</li>
<li><p><strong>Due to the &quot;memoryless&quot; nature of mining, it costs nothing to &quot;give up work on previous base&quot; - there's actually no &quot;previous work&quot; to give up.</strong></p>
</li>
<li><p>For him to win the reward of newly generated bitcoins (plus transaction fees collected within a block), he obviously does not need to verify the transactions which his new block will include over and over again. <strong>With the UTXO set he can instantly know whether a transaction is valid (rule-compliant) and then eligible for inclusion.</strong> In practice, full node software typically maintains a pool which contains such eligible (and valid of course) transactions, as known as <strong>&quot;mempool&quot;</strong>.</p>
</li>
<li><p><strong>Actually the mining &quot;rigs&quot; don't have to deal with the full block data at all</strong> - all the validation job is supposed to be done by the mining pool (which is also a full node of Bitcoin network - also, in principle technically anyone can run a pool, however in reality running a public pool is also related to engineering and economics) already. All the included transactions finally yields a Merkle root in the block header, then the block header (which contains the nonce field) is theoretically the only thing the mining rigs needs to deal with. (In practice the nonce of Bitcoin block header quickly runs out, therefore the coinbase transaction is also fed to the &quot;rig&quot; machine.) However, on the other hand, this is also the long blamed (re)centralizing problem of Bitcoin in reality - after all, just as mentioned above, <strong>the mining rigs themselves do not validate (the whole) block, and, a miner who does not rely on his own full node also (blindly) trusts the public mining pool operators.</strong> To address (or relieve, at least) this problem, new mining protocols which enable the miners (who in reality trust/rely on public pool operators) to also validate blocks like StratumV2 have been proposed.</p>
</li>
</ol>
<h3>What if a malicious miner chooses to mine a &quot;valid (rule-compliant) but dishonest&quot; (double-spending) alternative chain, instead of an &quot;invalid (rule-breaking) chain&quot; which is always apparent &amp; easy to spot?</h3>
<p><strong>Finally, we meet the <em>real</em> double-spending problem and the so-called 51% attack</strong>.</p>
<p>Since the dishonest chain is also compliant with rules, for any bystander who hasn't witnesses the whole genuine history (which is also not practical/possible due to reasons like network latency), it's hard/impossible to tell which chain should be the &quot;correct&quot; one.</p>
<p>However, with the most-accumulated-proof-of-work rule, at least the payee can choose to wait for more confirmations (how many later blocks has been appended to the block which includes the payment) to make his risks lower, <strong>as long as the supposed attacker does not control &gt; 50% of all bitcoin hashpower.</strong> Just as the calculations in the Bitcoin whitepaper by Satoshi Nakamoto, the chance/probability for the double-spending attacker to succeed will drop dramatically as the confirmation number grows, as long as the attacker only controls &lt; 50% of hashpower.</p>
<h3>What if the double spending attack finally succeeds?</h3>
<p>Technically, the payee obviously loses the payment he was originally supposed to gain - no new coins will be created out of thin air, of course.</p>
<p>However, there will be much more subtle implications once a double spending attack succeeds, which are hard to tell.</p>
