Skip to content

Instantly share code, notes, and snippets.

@fjsousa

fjsousa/bitcoin.md

Last active April 17, 2017 17:56
Show Gist options
  • Save fjsousa/476279e49e2f75770b6d to your computer and use it in GitHub Desktop.
Save fjsousa/476279e49e2f75770b6d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
bitcoin.md

Bitcoin

Cryptographic Hash Function

  • H: hash function (Sha-256)

  • M = H(message) fixed length digest or hash of the message

  • The size of the digest has a fixed length

  • Collision resistant: The probability of a conflicting digest value is very small

Digital Signatures

  • V: verification or public key
  • S: signing or private key
  • Hs: Signing function
  • Hv: verification function

Signing process

A signed message or signature Ms is obtained by appling the signing function to the hash of the message and the signing key.

Ms = Hs(M, S)

Each signed message is unique and altering the signature would invalidate it and it would fail the verification process

Verification Process

The signed messaged is verified using the verification function and the public function. Returns a boolean, true if the message was verified, false otherwise.

Verified? = Hv(M, Ms, V)

Transaction records

The identity in bitcoin system is the verification or public key V. This is the "wallet number" bitcoins are sent to.

  • Alice Va wants to transfer 50 BTC to Bob Vb

  • Alice has a record of 3 transfers in the past in the total of 65 BTC

    • T1: 25 from Vc
    • T2: 20 from Vd
    • T3: 20 from Vt

  • A transfer to bob has information about the previous transactions.

  • You'll apply a hash function to each of the records to obtain a digest:

    • Dc = H(T1)
    • Dd = H(T2)
    • Dt = H(T3)

  • These digests guarantee that Alice is the owner of these bitcoins. This is the input portion of the transaction.

  • The output portion of the transaction is the amount and verification key of each recipient, plus the signature with her private key of all the input and output of the transaction.

  • This transaction is sent to all nodes.

INPUT: Dc Dd Dt
OUTPUT': 50, Vb

T:
INPUT: INPUT
OUTPUT: OUTPUT', Hs(INPUT+OUTPUT', S)
  • Bob can use Alice's Public key to verify the transfers, however, the transaction needs to be sealed by the network to be accepted and avoid double spending.

Transaction block chains

A bitcoin transaction is a line in the ledger A transaction block is a page in the ledger.

  • A block contains all the transactions that are considered to have occurred at the same time.
  • Transactions that are not contained in a block are called unconfirmed or unordered.
  • Each new transaction is sent to all nodes.
  • The nodes will incorporate in the block chain all the unordered transactions that were made in a given time window.
  • Each miner will hash the unordered transactions plus the previous block chains. This hash is called the challenge.
  • The miners will look for a proof, and the function of that proof plus the challenge, is a number which has a certain number of prefixed zeros.
Hash(challenge, proof) = 000000.....0XXXX
  • Everytime a miners finds the proof, he can assigned a reward to himself, a Bitcoin.
  • It takes on average 10 min for a proof to be found across all network, although it would take several years for a single computer.
  • When a proof is found, the node that found it broadcasts the solution, and the block of transactions he was working on, is considered the next in the chain.
  • Occasionally, a block will be solved on several different locations, leading to branching. Each node should build on top of the first block they receive, but the order might change between nodes, leading to branching.
  • The tie gets broken when a new block is solved. The nodes should then switch to the bigger branch.
  • What happens to the blocks outside of the accepted branch? Are they dropped ?
  • This branching mechanism opens the possibility to double spending attacks. An attacker might issue a transfer to pay for a product, build a bigger block chain branch which will include this new transfer, the only difference being that the output is his own account. Because this new branch is bigger, other nodes will accept it and drop the other, smaller branches that contain the first transaction.
  • What prevents this attack is the time it takes to solve a block, that is, to find the proof that seals the block.
  • A transaction is only vulnerable to a double spending attack near the end of the chain, which is why it's recommended to wait several blocks to consider a transfer as safe.

Recomended links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment