Blockchain From: http://news.bitcoin.com Zwischen Genesis und - - PowerPoint PPT Presentation

▶
blockchain
SMART_READER_LITE
LIVE PREVIEW

Blockchain From: http://news.bitcoin.com Zwischen Genesis und - - PowerPoint PPT Presentation

Sep 25, 2023 531 likes •876 views

Blockchain From: http://news.bitcoin.com Zwischen Genesis und Mondlandung 2016-08-06 Jonas Nick jonasd.nick@gmail.com https://nickler.ninja @n1ckler Peer-to-Peer Cash Ideal: Internet money without central control and anonymous I've

slide-1
SLIDE 1

Blockchain

Zwischen Genesis und Mondlandung

From: http://news.bitcoin.com

2016-08-06 Jonas Nick jonasd.nick@gmail.com https://nickler.ninja @n1ckler

slide-2
SLIDE 2

Peer-to-Peer Cash

  • Ideal: Internet money without central control and anonymous

I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. [...] Satoshi Nakamoto

  • The Cryptography Mailing List
slide-3
SLIDE 3

A toy currency

  • Start with arbitrary bits that you call coins from now on
  • Use cryptographic signatures to make forging messages impossible

Alice Bob Carol “I, Alice, hereby transfer coins xyz to Bob” double spend: “I, Alice, hereby transfer coins xyz to Carol”

  • A central bank could tell which transaction came first.
slide-4
SLIDE 4

A toy currency

  • Decentralize control: Shared ledger

○ Every participant keeps a record of the transaction history ○ This works as long you know all the participants and trust a majority.

  • But in open peer-to-peer systems

○ It is impossible to know all the participants. ○ It is impossible to meaningfully count votes.

  • Want: dynamic membership of the participant set
slide-5
SLIDE 5

Bitcoin

  • Proof of Work: small proof that some amount of computation was done

1. Define that the “official” transaction history

a. is valid b. has the most proof of work

2. Providing PoW (mining) to the official history is rewarded with coins Effect: 1. Consensus on official history. 2. Incentivizes mining on a history. Incentivizes mining on the official history.

slide-6
SLIDE 6

Mining

  • History is represented as a chain of blocks.

○ Blocks contain transactions.

  • Miners create blocks by collecting transactions.
  • And attempt to solve the PoW function.
  • Blocks are mined on expectancy every 10 minutes.
  • The miner gets a mining reward.

Tx1 Tx2 Tx3 Tx4 Miner +1 PoW Tx1 Tx2 Tx3 Tx4 Miner +1 PoW Tx1 Tx2 Tx3 Tx4 Miner +1 PoW

...

slide-7
SLIDE 7

Mining

  • Miner attempting to rewrite the history always loses in the long run

○ As long as miner has less than 50% hash rate

  • Miners can not spend your coins or include invalid transactions

○

f.e. A tx that send more coins than the attacker has available. Tx1 Tx2 Tx3 Tx4 Miner +1 PoW Tx1 Tx2 Tx3 Tx4 Miner X +1 PoW Tx1 Tx2 Tx3 Tx4 Miner +1 PoW

...

Tx5 Tx6 Tx7 Tx8 Miner Y +1 PoW

slide-8
SLIDE 8

Blockchain technology

  • 2 years ago: An application that uses Bitcoin in some way
  • Now: Consensus on shared censorship-resistant state with immutable

rules in a distributed environment with potentially dishonest nodes.

  • Goal: Reduce trust or expensive processes
  • Can enable interactions that were previously impossible.
slide-9
SLIDE 9

Part 2: Transactions

slide-10
SLIDE 10

Transactions

  • Balance-based vs. UTXOs
  • Balance-based (f.e. Ethereum)

○ Transaction: Alice 1 coin Bob Alice 2 Bob Alice 1 Bob 1

Ledger state New ledger state

slide-11
SLIDE 11

Transactions Inputs & Outputs

  • utput
  • utput

Input Transaction output: tuple of recipient and value input: tuple of txid, vout and signature Input

  • utput

Transaction 1 Transaction 2

slide-12
SLIDE 12

Unspent Transaction Outputs (UTXOs)

  • Alice owns 2 coins = Alice can spend transaction outputs whose values sum

to 2 0.5 1.5

Transaction 1: Transaction 2:

slide-13
SLIDE 13

Spending Outputs

0.5 1.5 1.0 1.0

slide-14
SLIDE 14

Part 3: Script

slide-15
SLIDE 15

Cryptography Basics

  • Cryptographic hash functions

○ hash: {0,1}* -> {0,1}^n ○ Example: sha1(“foo”) = f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 ○ collision resistant

  • Public key cryptography

○ key pair: secret key sk and public key pk

○

cryptographic signature over message m ■ sign(message, sk) -> sig ■ verify(message, pk, sig) -> {0, 1} ○ Nobody can create a sig for a pk without the sk.

slide-16
SLIDE 16

Script Evaluation: Pay-to-pubkey (P2PK)

= Bitcoin script <pubKey> OP_CHECKSIG = Bitcoin script <sig>

+

= <sig> <pubKey> OP_CHECKSIG = true

slide-17
SLIDE 17

Multisig

scriptPubKey: <m> <pubKey_1> … <pubKey_n> <n> OP_CHECKMULTISIG scriptSig: <sig_1> … <sig_m> 2 of 3 Multisig Output Use cases: Wallet security, Escrow, Micropayment Channels

slide-18
SLIDE 18

Payment Channels

Setup: Alice creates transaction with 10 bitcoin to a 2-of-2 multisig with Bob

Alice pays by signing tx and sending it directly to Bob

Alice 9.9 Bob 0.1 Alice 9.8 Bob 0.2 Alice 9.7 Bob 0.3

Closing the Channel: Bob signs tx and broadcast to miners

slide-19
SLIDE 19

Micropayment Channel

  • Problem: If Bob vanishes, Alice’s coins are lost
  • CheckLockTimeVerify

○ 12345 OP_CLTV ○ script evaluation fails if blockchain < 12345 blocks

  • Idea: After some time, Alice gets refund
slide-20
SLIDE 20

Part 4: Sidechains

slide-21
SLIDE 21

Sidechains

  • Observations

a. There is no single blockchain that meets all requirements. b. Blockchains make different trade offs. c. New blockchain rules need consensus, slow process. d. Creating new blockchains from scratch is a huge challenge ■ Network effect, security

  • Interoperability

a. Pass information from chain to chain in a trustless and automated way. b. Leverage security from a different chain. c. Common API.

slide-22
SLIDE 22

Sidechains

  • Use case: Add features to Bitcoin

Output Parent chain Withdraw lock Sidechain Withdraw lock Output Withdraw lock Withdraw lock

slide-23
SLIDE 23

Federated Peg

  • New security model: Set of mutually distrusting functionaries
  • Enforce the rules that Bitcoin is currently unable to.
  • Uses m-of-n multisig instead of PoW.
  • Auditable
  • Allows creation of interoperable private chains.
slide-24
SLIDE 24

Elements

https://elementsproject.org / https://github.com/elementsproject/elements

  • Bitcoin Core code fork
  • Uses federated peg

○

  • ur public chain pegged to Bitcoin testnet
  • Alpha released, Beta soon
slide-25
SLIDE 25

Liquid

https://elementsproject.org/sidechains/liquid/

  • Production Bitcoin sidechain
  • Based on elements
  • Key feature: Decrease interchange settlement lag (ISL)

○ Because Liquid uses federated Peg: improves latency, throughput

  • + Elements features (CT)
  • Primarily for Bitcoin exchanges, payment processors, traders
  • Strong Federation
  • Launch in late summer 2016
slide-26
SLIDE 26

Alpha feature: Confidential Transactions (CT)

Tx verification: input_value = output_value + fee Verification with CT: Enc(input_value) = Enc(output_value) + fee alpha_address = bitcoin_address + blinding_pubKey Without corresponding blinding private key, values are hidden (blinded). Auditors can import private blinding key

slide-27
SLIDE 27

Part 5: Bitcoin Roadmap

“Through the use of cryptographic proof and decentralized networks Bitcoin minimizes and replaces trust costs.”

slide-28
SLIDE 28

Segregated Witness

  • Signaturen sind nicht mehr Teil der Transaktion

○ Sie sind nur ein Zeuge (Witness) den man zur Validierung braucht

  • Soft-fork: Benutzer bestimmen selbst ueber Upgrade
  • Implementiert, aber noch nicht aktiviert
  • Loest “malleability” Problem
  • Erhoeht den effektiven Transaktions-Durchsatz
  • Skript Versionierung
slide-29
SLIDE 29

Signature Aggregation

  • Neue Skript Version
  • Fuehrt neuen Signatur Algorithmus ein (Schnorr)
  • Es wird nur eine Signature pro Transaktion benoetigt
  • Im Durchschnitt bis zu 30% Einsparung der Transaktionsgroesse

○ Erhoeht Durchsatz

  • Nebeneffekt: Man spart Transaktionsgebuehren (~ 5%) wenn man eine

Transaktion gemeinsam mit einer anderen Person erstellt (“CoinJoin”)

slide-30
SLIDE 30

CoinJoin

Transaction 1: Transaction 2:

+ =

slide-31
SLIDE 31

Lightning Network

  • = Payment channel + Netzwerk
  • Zahlung benoetigt im Allgemeinen

nicht Eroeffnung eines Channels

  • Sind Off-chain
  • Privatsphaere durch Onion

Routing

From: https://BitcoinMagazine.com

slide-32
SLIDE 32

Allgemeinere “Smart Contracts”

  • Ziele

○ On-Chain Verifikation, Off-Chain Berechnung ○ Basierend auf 80 Jahren Fortschritt in der Informatik ■ Und 40 Jahren Software Entwicklung ○ Privat

  • Beispiele

○ MAST ■ Bitcoin Skript, aber es wird nur der ausgefuehrte Teil offenbart ○ ZKCP ■ Zk-snark: Beweis, dass Funktion auf Input true zurueckgibt ist, ohne den Input zu

  • ffenbaren

■ Beispiel: is_valid_Sudoku_solution(solution) ■ Bezahlung erfolgt nur genau dann wenn Beweis und Input offenbart wird ○ etc.

slide-33
SLIDE 33

Zusammenfassung

  • Blockchain: Consensus on shared censorship-resistant state with

immutable rules in a distributed environment with potentially dishonest nodes.

  • Bitcoin ist eine flexible Plattform fuer Blockchain Applikationen.
  • Sidechains fuegen state-of-the-art Features hinzu und werden ab dem

spaeten Sommer in Produktion gehen.

  • Unzaehlige neue Features in Bitcoin sind in Entwicklung. Besondere

Wertlegung auf Erhaltung der Dezentralisierung.

  • Slides: https://nickler.ninja/slides/2016-Munster.pdf

2016-08-06 Jonas Nick jonasd.nick@gmail.com https://nickler.ninja @n1ckler