This is the actual contents of the **readme.txt** file in the Bitcoin prerelease source code, written by Satoshi Nakamoto himself. This text document details his personal notes and considerations while envisioning Bitcoin and the development process. He actually started coding on-and-off in 2007. It wasn't until August 2008 that he started approaching the proof-of-concept more seriously. # BitCoin v0.0.0 Proof-of-Concept Personal Notes   Timestamp: August 2008 I'm writing this document in an effort to get my thoughts on paper and construct a PoC to see if this is even possible. I think there's going to be a lot going on, so best to keep better documentation this time. I suck at doing proper documentation along the way, so this is a good time to improve. ## Abstract   Both SQL Server 2005 & 2008 can only do active/passive when it comes to fault tolerance. I have been doing a lot of SQL performance tuning and architectural roll-outs for Fortune 500 companies lately, and the lack of 'cost effective' fault tolerance seems to be a consistent issue. I was hoping the new SQL Server 2008 would have better offerings for fault tolerance... but alas, no. The only consistent viable way is with active/passive. Active/active is possible so both physical SQL Servers can be utilized simultaneously, but it requires splitting into multiple individual databases and spreading across both boxes. Not surprisingly, many big companies have a single database as their primary store. Companies are spending a fortune on hardware that is literally sitting there doing nothing because new transactions can only be written to one instance on one box. Regardless of active/passive or active/active, there is no solution that allows dozens or more database servers on a network. I am solving for the ability to have multiple master data stores on a network that will synchronize with each other; more specifically 'multiple write masters'. It should be possible to write new transactions to any database server (node) on the network and have those transactions synchronize seamlessly with the peer nodes.   ## Technical Challenges - Should I do some sort of routing of new transactions or allow any node to claim authority on the write? - How to ensure transactions will propagate in chronological order - Should I think about using an epoch? - Is it possible with a concurrency stamp (UNIQUEIDENTIFIER) and other values? - How to ensure that existing transactions are not overwritten (immutable data) - What method can I create using existing tech. I don't want to reinvent the wheel. - What about data collisions - When there is a data collision, how do I determine which is the correct/oldest transaction? - How can I execute a rollback on servers that think they have the correct transactions but don't? - Synchronization - What is a 'reasonable' amount of time to ensure strong consistency amongst all nodes? - Should I allow some sort of 'record locking' or allow dirty reads? - Scalability - What to do about WAN networks instead of LANs? Slow connections might be disaster. - How many nodes can effectively act as write masters? - Should I implement a split of a maximum number of write masters and remaining nodes acting as read masters only? ## Convention I decided to call it BitCoin. It's not really about coins and money, but it seems to make sense as a catchy name. It's really about multi-master data synchronization and persistence immutability, but that obviously sounds like shit as any type of name. It seems that everything going on in the world is all about the massive financial crisis. I can't turn on the TV without hearing about it. It's exhausting to hear about that nonstop, but that did get me thinking though... the simplest thing for me to demonstrate that the PoC works is to synchronize a single value, not some large dataset. Huge datasets are not required for a PoC. As long as I am showing the value propagates and synchronizes with all nodes and the transactions remain in the correct chronological order, the PoC works. That being said, I decided to make the single value a number, such as a bank account balance. ## Documentation TODO: I need to write a functional spec document and a technical architecture document. Ugh. ## Development ### Tools and Resources - Microsoft Visual C++ 6.0 (Visual Studio 2008 Pro)   - OpenSSL - Boost C++ Libraries ## QA and Testing TODO: If this actually works, find a user group that can help me validate my solution and provide some feedback.