> For the complete documentation index, see [llms.txt](https://satuser.gitbook.io/en-the-book-of-satoshi-by-phil-champagne-beta/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://satuser.gitbook.io/en-the-book-of-satoshi-by-phil-champagne-beta/10.-about-synchronization-of-transactions.md).
# 10. About Synchronization of Transactions
### 10
### About Synchronization of Transactions
IN THIS POST, Satoshi explains what happens when a miner receives two conflicting transactions. The first transaction received is the one that the miner incorporates in the next proof-of-work. If more information is needed, see the explanation in Chapter 2.
#### Re: Bitcoin P2P e-cash paper
Satoshi Nakamoto Sun, 09 Nov 2008 11:14:170800
James A. Donald wrote:
The core concept is that lots of entities keep complete and consistent information as to who owns which bitcoins.
But maintaining consistency is tricky. It is not clear to me what happens when someone reports one transaction to one maintainer, and someone else transports another transaction to another maintainer. The transaction cannot be known tobe valid until it has been incorporated into a globally shared view of all past transactions, and no one can know thata globally shared view of all past transactions is globally shared until after some time has passed, and after many new transactions have arrived.
Did you explain how to do this, and it just passed over my head, or were you confident it could be done, and a bit vague as to the details?
The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.
A transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at closeto the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort.
If the transactions did come at exactly the same time and there was an even split, it’s a toss up based on which gets into a proof-ofwork first, and that decides which is valid.
When a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it’s now invalid according to the accepted chain.
The proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU power to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that’s a few links back in the chain, it is firmly etched into the global history.
Satoshi Nakamoto
The Cryptography Mailing List
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://satuser.gitbook.io/en-the-book-of-satoshi-by-phil-champagne-beta/10.-about-synchronization-of-transactions.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.