What problem does Bitcoin solve?

A solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.

Why the problem exists?

The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services.

The problem of course is the payee can’t verify that one of the owners did not double-spend the coin. To accomplish this without a trusted party, transactions must be publicly announced [1].
There also needs to be a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of

nodes agreed it was the first received.

Solution 1 – Timestamp server

The solution we propose begins with a timestamp server. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it

Solution 2 – Proof-of-Work

To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof of-work system similar to Adam Back’s Hashcash. The proof-of-work scans for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.

For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block’s hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.

Glossary:
Electronic coin: A chain of digital signatures.
Timestamp server: taking a hash of a block of items to be timestamped and widely publishing the hash

 

Example 1: Providing a deposit – – establish your trustworthiness with the operators,

1. The user and website send each other a newly-generated public key.
2. The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.
3. User sends the hash of Tx1 to the website.
4. The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can’t be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.
5. Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected – that the coins will eventually come back to him – but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn’t finished though; there are only zeros where the user’s signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.
6. The user broadcasts Tx1, then broadcasts Tx2.

Example 2: Assurance contracts – –  funding the creation of a public good

1. An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.
2. Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.
3. The transaction is uploaded to the entrepreneur’s server, which saves it to disk and updates its count of how many coins have been pledged.
4. Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address – it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.

The finished transaction is broadcast, sending the pledged coins to the announced address.