# Bitcoin Fundamentals: Mechanics and Working By [DiligentDeer](https://paragraph.com/@diligentdeer-2) · 2022-08-03 --- **Here is what we are going to cover:** * A simple analogy to understand Bitcoin * Applying rules to that analogy to build Bitcoin * Technicals behind transaction mechanics. This article provides an analogy-based approach to how bitcoin was built. The information is made extremely easy to digest. * * * _If this simple reading layout doesn’t excite you, you could scroll down to consume the same content as if it were a magazine._ _⚠_ **_Disclaimer_**_: All information presented here is my perspective and should be considered educational content. I won’t be responsible for any kind of financial profits or losses derived from your decisions. Financial and investment advice_ * * * ### Building Bitcoin with an example Conventional financial systems rely hugely on knowing the consumers and are majorly owned and regulated by very few entities, thus being centralized. If those few entities wish to wrap things up, you are probably screwed provided you are a part of their system. Moreover, when someone interacts with these centralized entities, the execution of your actions can stretch up to days to get confirmed. Bitcoin was introduced in 2008-09 and at that time we didn’t have the robust infrastructure of digital systems that we currently have. Bitcoin since then, claims to solve the issues with centralization, privacy, and speed of transactions. You will be introduced to simple examples, and from there, we will keep building until you understand how bitcoin works. Let’s dive in, In any type of digital transaction, a third party is exclusively needed to resolve the double-spending issue. > Imagine A, B, C, and D are transacting, A has a balance of $100 and he claims that he gave $100 to B and C each. > > This is the simplest example of double-spending. > > In absence of a third party, no one knows who’s correct until they have the record of transactions and a record of the wallet balance of each of 4 people. Let’s say B starts collecting the above-mentioned records, soon B will become the third party, as everyone would reach out to B to ensure no one has double-spent their money. Eliminating the issue of double-spending is hard without a third party. Let’s understand how Bitcoin pulled this off: Imagine there is an open ledger that everyone can view and make entries in it. To eliminate the issue of double-spending, we need to make an adjustment where if one records the transaction on the public ledger the other one needs to validate it. > If A records the transaction as “A paid $100 to B”, B needs to validate if it is true. > > Imagine a scenario where A paid $100 to B and when recording the transaction B denied to validate. A might permanently lose his $100 in this case. Let’s improve the system **Improvement 1: Validation is a mandate if you want to make a transaction (In our example, B has no choice but to validate if he wants to make a transaction in the future).** > What if A & B forms an alliance to ditch the system? > > For example, let’s suppose A took $100 on credit from C (a legitimate transaction), now A records a transaction as “A paid $100 to B”, as B is on A’s side, B validates the transaction as true though he didn’t receive $100. Here A happily defaults for his liability to pay $100 to C and closes off the account, withdrawing $100 he earlier took on credit from C (Making a profit of $100 instantly). B on the other hand will have $100 showing in his balance as per recorded transaction, thus B can spend those $100 by not even owning them in real. > This example relies hugely on assumptions and it’s highly improbable to get executed, but this example surely explains how systematic fraud can take place by exploiting a small loophole. > > Our system only seeks the validation from B (Transaction counter-party) and that’s the loophole **Improvement 2: The validation should be reflected by more than 50% of ledger users.** **Improvement 3: Transactions will have a timestamp to mitigate the chances of double-spending.** > In our earlier example, 4 people were transacting, A had a balance of $100 and he claims that he gave $100 to B and C each. > > Aggregating A’s transaction, all 4 people know that A has a balance of $100, and when he makes a transaction to B, he won’t be able to list his double spending to C because there is a time function, the transaction made earlier will be listed as soon as it is validated (receiving funds can act as validation). > > When B receives the funds the transaction gets validated and if A wants to make a new > > transaction, an aggregate of A’s transaction (wallet balance) needs to be greater than the amount he wishes to payout. > > With 2nd and 3rd improvements, our system can expand without any issues and as our system grows, the security also increases. Bitcoin system works in a similar fashion There is a secret key and a public key derived from that secret key, for each wallet (this provides layers of privacy and anonymity). > For easier understanding assume the secret key to be the password to your fund locker where funds are stored and the public key is the proof that implies you are the owner of that locker. > > The public key is also your locker’s address that people might use to transfer funds from their locker to yours. > > The owner of the secret key is the owner of all the funds transacted under all the public keys derived from that single original secret key. In our example we had 4 people maintaining the ledger, in the Bitcoin mechanism we have nodes to verify the chain of transactions (remember improvement 2, more nodes = more robust system) and each node has a digital copy of the ledger. ### Bitcoin Transaction Mechanics Let’s say, A needs to make a transaction: “A paid $100 to B”. A will use the information of the current and past transactions to digitally sign the transaction with his secret/private key. > Note: In the bitcoin system, only transactions are recorded and not the wallet balance, wallet balance can be tracked via aggregating the past transaction. User signs the transaction to push that transaction to get validated. The signature will carry the information of current and past transactions thus making it unique for every transaction, this eliminates the risk of signature forgery. The transaction is then published to nodes to verify. > For nodes to verify the transactions, A must prove that he is the owner of the public key address to whom earlier transactions were directed i.e. checking if A is making an authentic transaction. > > The nodes try to match the signature containing the secret/private key with the public key of A, if it matches the transaction is valid. This transaction is not confirmed yet, and it waits in the unconfirmed transaction pool until they are approved and attached to a block in the blockchain. > Nodes can group a set of unconfirmed transactions from the pool and form a block, and broadcast it to the rest of the network of nodes as a suggestion for the next block in the chain. For a block to be considered valid, each block has a specific puzzle that needs to be solved via guessing. The first node to solve the guessing problem broadcasts their block and gets to have the chosen group of transactions accepted as next in the chain. The transactions are flagged as confirmed once the block is attached to the chain. But what if 2 nodes solve the puzzle at the same time? When the node broadcasts a block, every node stops working on its current puzzle and adds the block to the chain. These nodes then build on top of what block they received, the probability of 2 nodes solving a block at the same time is very low, thus when the node adds another block, the nodes refresh their chain choosing the chain having the largest number of blocks i.e. longest chain. > Thus it is impossible to change a particular past transaction unless you change all the transactions after it. The same goes with blocks as well because every block is referenced in the next block that joins the chain. * * * _Thank you for being here._ _You can provide the same value by_ [_sharing_](https://mirror.xyz/0x1825bAEf615a3Ea4a176b995aFe1Edc645ff307e/e3KnRLBmP594Zi8resqA4Zy7KvzQQdDHj0HMCz8Abh4) _this article with your circle._ _You could even contribute/support these articles by owning one ✌._ * * * ![---](https://storage.googleapis.com/papyrus_images/b33ed6e35310e0217752b84668ac966e2538c9bde7808b941d7ab2fcddbfde60.png) \--- ![---](https://storage.googleapis.com/papyrus_images/fc359a7c58dbd569ccff60c1822ccc19ef734a2da9f75abdca3b6179792d4f52.png) \--- ![---](https://storage.googleapis.com/papyrus_images/0542e0d80cd652f5097ea579f13e2e0733f3bb9311468351bd3c7bc2cf84b13c.png) \--- * * * _Thank you for being here._ _You can provide the same value by sharing this article with your circle._ _You could even contribute/support these articles by owning one ✌._ * * * This was my first [article](https://diligentdeer.substack.com/p/understanding-the-mechanics-behind?r=1hy5qt&s=w&utm_campaign=post&utm_medium=web) when I was about to dive deep into the decentralized finance world. I always loved to rely on fundamentals and wanted to explore the rabbit holes. --- *Originally published on [DiligentDeer](https://paragraph.com/@diligentdeer-2/bitcoin-fundamentals-mechanics-and-working)*