"Peer-to-Peer" is an important concept in Bitcoin. It means that Bi...
Here I give a quick overview of a few concepts important for a good...
Satoshi Nakamoto is the name used by an unknown person or persons. ...
The double spending problem in a cryptocurrency is about a user bei...
What is proof of work?
The risk that a digital currency can be spent twice. Double-spendin...
What is the definition of "best effort basis" in this context?
**Reversible Transactions** Credit card payments are monitored b...
This nicely — and correctly — shows crypto systems are alternatives...
Here, I believe escrows can only help the buyers but merchants stil...
Escrow is a legal concept describing a financial instrument whereby...
This diagram can be hard to understand at first. The diagram is i...
As it stands, the system is still vulnerable to double spending. Sa...
The purpose of the timestamp server is to prove (or disprove) the e...
Is this the only purpose of the timestamp?
*Hashcash* is a proof-of-work system that can be used for instance ...
A [block](https://en.bitcoin.it/wiki/Block) is a record of a number...
I don't think Satoshi intended one-ASIC 50,000+ votes
When we talk about 'modifying a block' we are not talking about cha...
This is the step at which we are checking for any double spending.
The "longest" chain isn't necessarily the one with the most blocks ...
Highlighted for importance
Doesn't this jeopardise Satochi's initial idea of a currency for sm...
Here the author describes a way to develop bitcoin clients that don...
A quick resource for understanding Merkle Trees: https://hackernoon...
Simplified Payment Verification (SPV) is about verifying that a tra...
One important thing to understand here is that each transaction can...
In case it wasn't clear: Alice has 3 Bitcoins and wants to send Bob...
Consider an attacker that has paid some merchant, has had its trans...
Analysis to show that as long as an attacker possesses less than 50...
$k$ is the number of blocks the attacker has already mined in secre...
Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto
The network timestamps transactions by hashing them into an ongoing chain of
attack the network, they'll generate the longest chain and outpace attackers. The
1. Introduction
over a communications channel without a trusted party.
cooperating group of attacker nodes.
2. Transactions
The problem of course is the payee can't verify that one of the owners did not double-spend
transactions. For our purposes, the earliest transaction is the one that counts, so we don't care
majority of nodes agreed it was the first received.
3. Timestamp Server
Item Item ...
Item Item ...
Owner 1's
Public Key
Owner 0's
Owner 2's
Public Key
Owner 1's
Owner 3's
Public Key
Owner 2's
Owner 2's
Private Key
Owner 1's
Private Key
Owner 3's
Private Key
4. Proof-of-Work
would include redoing all the blocks after it.
diminishes exponentially as subsequent blocks are added.
5. Network
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
branch will then switch to the longer one.
Prev Hash Nonce
Tx Tx ...
Prev Hash Nonce
Tx Tx ...
realizes it missed one.
6. Incentive
7. Reclaiming Disk Space
not need to be stored.
Block Header (Block Hash)
Prev Hash Nonce
Hash0 Hash1 Hash2 Hash3
Root Hash
Block Header (Block Hash)
Root Hash
Transactions Hashed in a Merkle Tree After Pruning Tx0-2 from the Block
Prev Hash Nonce
Tx0 Tx1 Tx2 Tx3
8. Simplified Payment Verification
run their own nodes for more independent security and quicker verification.
9. Combining and Splitting Value
complete standalone copy of a transaction's history.
In Out
Hash2 Hash3
Block Header
Merkle Root
Prev Hash Nonce
Block Header
Merkle Root
Prev Hash Nonce
Block Header
Merkle Root
Prev Hash Nonce
Merkle Branch for Tx3
Longest Proof-of-Work Chain
10. Privacy
individual trades, the "tape", is made public, but without telling who the parties were.
the same owner.
11. Calculations
money he recently spent.
gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's
p = probability an honest node finds the next block
q = probability the attacker finds the next block
= probability the attacker will ever catch up from z blocks behind
1 if pq
q / p
if pq
Identities Transactions
Third Party
Counterparty Public
Identities Transactions Public
New Privacy Model
Traditional Privacy Model
sufficiently certain the sender can't change the transaction. We assume the sender is an attacker
sender hopes it will be too late.
parallel chain containing an alternate version of his transaction.
progress will be a Poisson distribution with expected value:
k =0
q / p
if k z
1 if k z
k =0
1q / p
z k
Converting to C code...
#include <math.h>
double AttackerSuccessProbability(double q, int z)
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
double poisson = exp(-lambda);
poisson *= lambda / i;
return sum;
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
Solving for P less than 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
12. Conclusion
[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.
2, pages 99-111, 1991.
[6] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and
[8] W. Feller, "An introduction to probability theory and its applications," 1957.


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. The "longest" chain isn't necessarily the one with the most blocks in it, but the one which represents the greatest amount of work. The article (https://dev.to/damcosset/blockchain-what-is-in-a-block-48jo) explains the contents of a block well. What, in the case of bitcoin, is the *challenge string* exactly? 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)? 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. 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 Can you elaborate please? Are these two almost the same concept? How the Bitcoin nodes calculate the chain with the greatest amount of work? This is the step at which we are checking for any double spending. 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. Craig has largely been discredited, Nur. What is $m$ in the $verify$ function arguments? 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. 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. @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. @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? 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? I have explained it further below on page 3. Here, I believe escrows can only help the buyers but merchants still have the problem of not getting paid with escrows. 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 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. 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. Would we even know if that has happened? 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. "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. 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? Does this mean that transactions fees would spike when the block rewards stop? 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. Highlighted for importance 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 I don't think Satoshi intended one-ASIC 50,000+ votes I will like to point out that João sentence starts with "As it stands", validation comes later. 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 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. 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? What is the definition of "best effort basis" in this context? 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. Is this the only purpose of the timestamp? This nicely — and correctly — shows crypto systems are alternatives to trust. that's not possible, and is part of the transaction validation the miners are doing. 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. 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? $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. 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. 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) 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 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. 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? 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. 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? 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/) *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. **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. 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. @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. 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.