**Reversible Transactions** Credit card payments are monitored by a central authority (the credit card networks). The central authority reserves the right to reverse a transaction under some situations - e.g. fraud. Being able to reverse a transaction can be useful in some situations but it also has some disadvantages. The reversible nature of credit card payments puts businesses at risk of charge-back fraud - e.g. a consumer initiates a payment reversal by falsely claiming that the item they bought was never delivered. Merchants can therefore lose the payment for the item after sending the item to the customer, and also have to pay a fee for the charge-back. Bitcoin transactions are non-reversible, meaning that after a transaction has been successfully completed there is no entity that can undo that transaction. Analysis to show that as long as an attacker possesses less than 50% of the computational power in the network, he produces blocks at a lower expected rate than the rest of the nodes, and so the probability of a successful attack on a given transaction decreases exponentially as more blocks are added to the chain on top of it. This is the step at which we are checking for any double spending. The purpose of the timestamp server is to prove (or disprove) the existence of a piece of data at a certain point in time. To do that the timestamp server calculates the hash of the data and publishes it widely. The timestamp server is therefore a series of $(hash, timestamp)$ pairs. One can confirm the existence of a piece of data at a certain point in time by recomputing the hash of the data and checking it against the one published by the timestamp server. The article (https://dev.to/damcosset/blockchain-what-is-in-a-block-48jo) explains the contents of a block well. What is $m$ in the $verify$ function arguments? @RJ: No, we would not, but as the author goes on to demonstrate, the probability of someone being able to do that exponentially decreases as the number of blocks increase. @RJ: No, we would not, but as the author goes on to demonstrate, the probability of someone being able to do that exponentially decreases as the number of blocks increase. Satoshi Nakamoto is the name used by an unknown person or persons. The exact identity is unknown. Craig S Wright is a suspect https://twitter.com/proffaustus What is proof of work? Would we even know if that has happened? Highlighted for importance Daniel, lets say there is t1, t2 and t3 transactions were made at 10 min. When two nodes create the blocks, both of the block will contain t1, t2 and t3, only the order might be differ. Even if one of them fails, all the transactions will be processed, of course if the transactions are valid. Any PoW system can be used to fight spam. It is in Hashcash that you are looking for a nonce such that the hash has many leading zeroes. To understand better this concept of process of work there is this video: https://www.youtube.com/watch?v=bBC-nXj3Ng4&list=WL&index=162 Can escrow be used to prevent charge-back fraud for credit cards? More broadly, can escrow (or a similar scheme) be used to enable completely non-reversible transactions in traditional, centralized finance? Is this the only purpose of the timestamp? A [block](https://en.bitcoin.it/wiki/Block) is a record of a number of transactions in the bitcoin network. A block contains: * The transactions that happened during a period of time * A number of metadata fields such as: * Timestamp * Nonce (the solution to the proof-of-work problem) * The current difficulty (how hard it is to solve the proof-of-work problem) * Reference to the previous block * The root hash of the [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) of all transactions in the block As it stands, the system is still vulnerable to double spending. Say that Owner 1 just completed the transaction to Owner 2. Right after he does this, nothing prevents him from approaching another person, Owner 4, and repeating the exact same process, reusing the funds he got from Owner 0. In order words, Owner 1 would do exactly the same thing he did for the transaction to Owner 2, but he would instead use Owner 4’s public key. I don't think Satoshi intended one-ASIC 50,000+ votes that's not possible, and is part of the transaction validation the miners are doing. Doesn't this jeopardise Satochi's initial idea of a currency for small transactions free of charge? Is this transaction fee a percentage or a fixed rate? What is the definition of "best effort basis" in this context? Creating this alias of 'Charlie' is possible simply because of how unimaginably large the bitcoin address space is (2^160); so you could generate a 256 bit alphanumeric-address, and the possibility of a collision is so small that it is practically 0. This nicely — and correctly — shows crypto systems are alternatives to trust. $k$ is the number of blocks the attacker has already mined in secret. If the attacker has mined more blocks than the current $z$ blocks in the blockchain, then he has already won. Here the author describes a way to develop bitcoin clients that don’t need to have the complete block chain on disk. The main reason for this would be to conserve disk space (e.g. perhaps you want to have a bitcoin client on your phone but you don’t want it to take up multiple gigabytes of disk space). Using this scheme does make the user vulnerable to a specific type of [attack](http://sourceforge.net/p/bitcoin/mailman/message/28618979/), which is not possible if you have the entire blockchain locally. 403 error on that link Joao, any other links? One important thing to understand here is that each transaction can only be forwarded as a whole and cannot be broken into smaller parts. Imagine that you just got your bitcoin wallet and a friend of yours sent you 10 bitcoins (let’s call it Transaction 0 - $Tx_0$). Now you want to send 2 bitcoins to Alice (which will be $Tx_1$). In order to only send 2 bitcoins to Alice you will setup $Tx_1$ with one input -$Tx_0$ and with two outputs: * *Output 0* - sends 2 bitcoins to Alice * *Output 1* - sends 8 bitcoins back to you According to your example, if I am a spammer I only need to find the nonce once and then send my message to millions of users. I suppose a way around this would be to include the email address of the recipient in the challenge string. Is this the approach that Hashcash takes, or do they do something else? Exactly, the transactions are basically chained together with the last person being the current owner of the transaction chain, i.e the only one who can spend the transaction. He can prove to be the rightful owner of this transaction by signing it with his private key. Only then is he able to spend it, e.g. by sending it to the next person. [Archived version of the link is available](https://web.archive.org/web/20210507001335/https://sourceforge.net/p/bitcoin/mailman/message/28618979/) A quick resource for understanding Merkle Trees: https://hackernoon.com/merkle-trees-181cb4bc30b4 I think escrow is used for that purpose in traditional financial systems currently. However, it comes with a fee, which has to be paid to the escrow agent. Craig has largely been discredited, Nur. I have explained it further below on page 3. "Peer-to-Peer" is an important concept in Bitcoin. It means that Bitcoin does not require a trusted, central authority that oversees all transactions, but instead relies solely on the network of machines participating in the bitcoin protocol. The risk that a digital currency can be spent twice. Double-spending is a problem unique to digital currencies because digital information can be reproduced relatively easily. Physical currencies do not have this issue because they cannot be easily replicated, and the parties involved in a transaction can immediately verify the bona fides of the physical currency. With digital currency, there is a risk that the holder could make a copy of the digital token and send it to a merchant or another party while retaining the original. Read more: Double-Spending Definition | Investopedia https://www.investopedia.com/terms/d/doublespending.asp#ixzz50lZqicke I don't get it, is there a single chain in order, where Owner 1 needs to prove that got the same amount of money from Owner 0, to be able to transfer the same amount to Owner 2? When we talk about 'modifying a block' we are not talking about changing the bits of a block that is already in the blockchain. In order to 'change' a block, and 'rewrite history' an attacker has to generate an alternative chain of blocks which contains the manipulated blocks and is longer than the existing chain. If the attacker manages to do this his alternative chain will be the one that gets accepted by the other nodes. What, in the case of bitcoin, is the *challenge string* exactly? Here, I believe escrows can only help the buyers but merchants still have the problem of not getting paid with escrows. The miners need to be rewarded for their work. In bitcoin that is accomplished via the mining reward and transaction fees. As the mining reward gets smaller (it halves approximately every 4 years), transaction fees will increasingly become the way miners get paid. The transaction fees are voluntary and set by the person that wants to execute the transaction. Nevertheless miners are not obliged to accept a specific transaction and include it in the block. Therefore transaction fees work as an incentive on the part of the bitcoin user to make sure that a specific transaction will be included in the next block. Escrow is a legal concept describing a financial instrument whereby an asset or escrow money is held by a third party on behalf of two other parties that are in the process of completing a transaction. For example, an online platform acts as the middleman for online product sales. The buyers send the money to an escrow service, and they hold the money until the buyer gives confirmation that the product received satisfies the buyer-seller agreement. Then, they may release the funds to the seller. the difficulty scaling was chosen in such a way, that it support it. also, even in 2009 he did foresee an arms race and called for gentlemen agreement to postpone it a bit https://bitcointalk.org/index.php?topic=12.msg54#msg54 The double spending problem in a cryptocurrency is about a user being able to successfully spend the same digital token multiple times. If you were designing a system relying on a central, trusted authority this issue could be simply solved by just always checking with that authority before accepting a token from another user. In this case, the central authority has a global view of all transactions happening in the system and can therefore prevent a user from spending the same token twice. In a decentralized system, this problem is much harder to solve. Bitcoin proposes a solution that is efficient and makes use of a peer-to-peer network instead of a trusted authority. The "longest" chain isn't necessarily the one with the most blocks in it, but the one which represents the greatest amount of work. Can you elaborate please? Are these two almost the same concept? How the Bitcoin nodes calculate the chain with the greatest amount of work? In case it wasn't clear: Alice has 3 Bitcoins and wants to send Bob 1 of them. She generates a new identity Charlie and publishes the transaction -- 3 Bitcoins from Alice, 1 to Bob, 2 to Charlie. By only looking at the transaction, you would not be able to tell that the person behind "Charlie" is the same as the person behind "Alice," thus providing an additional layer of anonymity. Bitcoin paper approves of the "Routine Escrow Mechanisms" that could be (and **should be**) implemented to protect buyers. Why is it called a mint instead of a bank? nonce stands for **number used once** If I may be correct the purpose of the timestamp is to prevent double-spending Does this mean that transactions fees would spike when the block rewards stop? Each block contains a nonce that is hashed together with the actual data in the block to produce a final hash containing $n$ leading zeros. As noted above in the explanation of Hashcash, the greater $n$ is, the more exponentially hard it is to generate such a hash. The greater the difficulty, the more work has to be put into finding a nonce that generates such a hash. As such, by looking at the number of leading zeros there are, one can determine the difficulty and thus estimate the amount of work put into generating said blocks. So a single block with ten leading zeros for its hash would represent more work than ten blocks with one leading zero for their hashes. Simplified Payment Verification (SPV) is about verifying that a transaction has been accepted into the blockchain without having to download the entire blockchain. With SPV the client downloads only the block headers and not the transactions themselves. In the diagram, we can see a sequence of block headers. We are trying to check if transaction $Tx_{3}$ is part of the second block (block 2). In order to do that the client performing SPV needs to request a few more nodes of block 2’s Merkle tree from some other bitcoin client that has the whole blockchain locally. We only need to request *Hash01* and *Hash2*. Then we can use *Hash2* and *Hash3* (which we got from $Tx_{3}$) to compute *Hash23* and then we can use *Hash23* and *Hash01* to compute the Merkle Root hash. Finally, we compare the computed Merkle Root hash against the one referenced on block 2’s header. If those values match, $Tx_{3}$ has been accepted into the blockchain. If you want to learn more about SPV I suggest you check out [Bitcoin and the Blockchain - Chapter 6. The Bitcoin Network](http://chimera.labs.oreilly.com/books/1234000001802/ch06.html#spv_nodes) @Decio Soares - Ownership is demonstrated by signing with one's private key, generating a digital signature. Then, anyone with your public key can decrypt the signature to get the message and verify that it is legitimate. Aside on Public Key Encryption: A Public Key is something that is visible to everyone, whereas a private key is kept secret. Private and Public Key pairs function in a sort of 'xor' fashion: if one is used to encrypt, the other is used to decrypt(they do have to be from the same key pair). So for instance, if Bob wants to send Alice a message that he wants only Alice to be able to read, he would sign it with her Public Key. That way, even if a man-in-the-middle were to intercept this hash, only Alice has her private key, which she would use to decrypt this message. If Bob wants to prove that a message really did come from him, he would sign with his private key and say 'hey guys, here's my signature, use my public key to decrypt it and verify that the decrypted message actually makes sense, in which case you know it was me'. It is (mathematically) impossible for a decryption to 'by-chance' give a legitimate message, since even a small deviation from the right public key would generate gibberish on decryption. *Hashcash* is a proof-of-work system that can be used for instance to fight email spam. The idea is that in order to send an email the sender has to spend some CPU resource (i.e. perform a costly operation) to come up with a value that is attached to the email header. This will not affect you much if you are a regular user using email in a legitimate way. However, a spammer, who might be sending millions of emails per day, cannot afford to spend the aggregate amount of CPU power necessary to send all of those emails (it would just be too expensive to have that many computers computing all of the proofs of work necessary to send the emails) In a proof of work you usually have a challenge string *c* and you are looking for a nonce *n* such that $hash(c + n)$ will result in a string with a certain number of leading zeroes. Let’s say our challenge string was *“Hello, world!”* and our target was to get a *SHA-256* hash beginning with ‘000’. One way to go about it is to start with a nonce of ‘0’ and progressively increment it until you get an hash starting with ‘000’. In this case that would take 4251 tries (which happens to have 4 leading zeroes): ``` SHA-256("Hello, world!0") = 1312af17... SHA-256("Hello, world!1") = e9afc424... ... SHA-256("Hello, world!4249") = c004190b... SHA-256("Hello, world!4250") = 0000c3af... ``` Computing 4251 hashes on a modern computer is not that much work, however you can easily ramp up the difficulty by increasing the leading number of zeroes required for the proof of work. @Georg Stricker writes: "He can prove to be the rightful owner of this transaction by signing it with his private key". Is this affirmation correct? It is my understanding that the proof of ownership is the fact that his own public key was hashed together with the previous transaction and then signed by the previous owner. Could someone please correct me if I'm wrong? Here I give a quick overview of a few concepts important for a good understanding of bitcoin. **Public-keys and Private-keys** The concept of public-key and private-key come from Public-key cryptography. Public-key cryptography is a set of cryptographic protocols based on algorithms that require two separate keys: - Private-key - which as the name indicates is meant to be secret - Public-key - which is public / visible to others These two keys are mathematically linked. In public-key cryptography the public key is used to encrypt plaintext, where the private key is used to decrypt cipher text. Every node in the bitcoin network has a public-key and a private-key. **Digital Signatures** Digital signatures make heavy use of public-key cryptography. You can think of a digital signature as somewhat similar to a physical signature. A digital signature is also used to prove the authenticity of a document/digital message. A digital signature binds an identity to a message. Only the person with the private key can produce valid signatures. Anybody with access to the public key can test the validity of the signatures. Say alice wants to digitally sign a message *m*. In order to do that Alice must have: - Private-key (signing key) - $KEY_{private}$ - Public-key (verification key) - $KEY_{public}$ Alice then uses the *signing* function to produce a valid signature: $$signing(message, KEY_{private}) \rightarrow signature$$ Don’t worry about the internals of the *signing* function. What you need to know is that it takes a *message* and the Private-key and it will produce a signature (a short string). Again, only a person who possesses a private key can produce a valid signature. Anyone can use the public key to verify the signature: $$verify(m,signature,KEY_{public}) \rightarrow true\ or\ false$$ **Hash Functions** A hash function takes a string of characters of arbitrary length (called message) and maps it to another string of characters of fixed length (called a hash value or simply hash). Bitcoin uses a hash function called SHA-256. Let’s look at an example: $$SHA-256(fermat) = 5e494e69...139dab5e$$ In this example the input/message is ‘fermat’ and the output/hash is 32 byte hash (I omitted part of the hash). Note that the length of the output/hash is always the same regardless of the size of the input. If you are an OS X user you can compute the SHA-256 hash value of 'fermat' by running the following command in your terminal: ``` echo -n fermat | shasum -a 256 ``` Here are 4 properties of a hash function that are important to note: - it is easy to compute the hash value for any given message - it is infeasible to generate a message from its hash - it is infeasible to modify a message without changing the hash - it is infeasible to find two different messages with the same hash. @RJ: No, we would not, but as the author goes on to demonstrate, the probability of someone being able to do that exponentially decreases as the number of blocks increase. @RJ: No, we would not, but as the author goes on to demonstrate, the probability of someone being able to do that exponentially decreases as the number of blocks increase. I will like to point out that João sentence starts with "As it stands", validation comes later. that _m_ should be _message_ Consider an attacker that has paid some merchant, has had its transaction embedded in the block chain, but wishes to reverse it (after obtaining some goods in return). The attacker may then use the fact that nodes will adopt an alternative version of the block chain if it is longer than their current one. It can try to create a fork of the current chain that splits off just before the block containing his transaction, and extend this fork in the chain until it is longer than the current chain. Once published, this alternative chain will take over as the accepted version of events and the attacker's original transaction will be discarded along with the block that contained it. Doesn't the specific attack mentioned in that post still require amassing enough computing power to generate a substitute blockchain, and will affect you regardless of whether you do this pruning? As far as I understand, the argument metioned there is basically -- say the value of your transaction is small compared to the cost of generating an alternate blockchain without your transaction in it. Even then, an attacker may find it profitable to fool many others such as you at the same exact time, so that the combined profit from small transactions is greater than the cost of overtaking the network for a certain amount of time. As such, you cannot actually rely on the insignificance of your own transaction to assume that nobody would bother to undo it. As Mike Hearn says in the end, this seems to be discussing a different problem than the transaction pruning mentioned here. Amos, thank you for your clarification. I have another question: what happens to all of the transactions that were approved in the "loser" blockchain (i.e.: say three blocks were mined and coins minted on two simultaneous chains, and 30 minutes later, one chain turns out to be the one with more proof of work, thereby rendering the other one a dud. Do all transactions and minted coins from the losing chain automatically fail)? I believe the escrow service can be designed in a way that it also protects the seller if all parties which physically participate in the transaction are involved. If we take for example a product delivery, we could design a multisigniture escrow where the buyer and the seller have to sign a transaction to be valid. In this case of course the buyer could just claim to have never received the package and thus not pay the seller despite package delivery. Changing this to include all participants, that is, the buyer, the seller and the delivery service offers the possibility to make a 2 out of 3 multisigniture escrow. If the seller and the delivery service both claim to have delivered the product the transaction becomes valid. There should be no incentive for the delivery service to cheat or cooperate with the seller to trick the buyer, besides the possibility of just an incapable delivery employee (But this is outside of the scope of Bitcoin). Also more strict definitions of delivery (you have to sign-off when delivered) and just plain use of modern day technology (packing stations) should avoid lost packages. But this is again outside of the scope of Bitcoin itself. One could argue that the delivery service is a third party in this case (where Bitcoin tries to be purely peer-2-peer). But I would say, that there is no third party involved in the payment process (as promised by Bitcoin), but purely in the physical delivery process. And just like in the physical transaction it acts as a checkpoint that the product was delivered correctly, it acts like a checkpoint on the multisigniture escrow. This diagram can be hard to understand at first. The diagram is illustrating the transaction flow from Owner 0 to Owner 1 to Owner 2. The idea is that before Owner 2 can accept the transaction from Owner 1, Owner 1 needs to show proof that he is entitled to the funds. In this case, that proof is a record showing that Owner 1 got the funds from Owner 0. In the first transaction box of the diagram we can see that Owner 0 takes the previous transaction (arrow coming from the left), adds Owner 1’s public key (the public key of the person Owner 0 wants to transfer funds to) and hashes the result. The output of the hash is then digitally signed by Owner 0 using his private key (which proves that Owner 0 was indeed the person that put together the transaction). Then Owner 0 sends this transaction to Owner 1. Owner 1 follows the same process and sends the transaction to Owner 2.