Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto Papers We Love Jlle #1 20/01/2021

Porque ler este artigo? ● Um dos documentos mais importantes para entender os building blocks de cryptocurrencies; ● Entender o que motivou a criação do Bitcoin; ● Entender de forma introdutória como o Bitcoin funciona; ● Paper seminal que juntou as partes e deu origem à tecnologia blockchain. A implementação do Bitcoin tem muitas especificidades e diferenças.

Como ler um artigo científico? Como eu faço: 1. Ler Abstract, Introdução e Conclusão a. Queremos antes de qualquer coisa saber se o artigo nos interessa 2. Escanear o miolo a. Determinar o propósito e a estrutura 3. Ler com cuidado a. Grifar e anotar b. Buscar resumo sobre conceitos que não entende 4. Criticar os argumentos a. Faz sentido? Existem contradições? Pontos fortes, fracos do argumento b. Comparar com outros trabalhos c. Buscar outros artigos que fazem citação 5. Buscar as referências deste artigo

Abstract

Introdução Problema ● E-commerce sobre da fraqueza do modelo baseado em confiança; ● Instituições financeiras revertem transações; ● Isso aumenta o custo de transação limitando o tamanho delas e restringindo transações menores; Caras e lentas? 🤔 ● Mercadores precisam de informações do cliente para evitar fraudes; ● Um percentual de fraudes é aceitável.

Introdução Proposta: ● Sistema de pagamento eletrônico sem intermediários baseado em provas criptográficas ao invés de confiança; ● Solução para o double spending problem usando um timestamp server distribuído baseado em peer-to-peer para gerar provas criptográficas da ordem correta das transações; ● O sistema se mantém seguro desde que a maioria dos nós sejam honestos.

Dissecando algumas ideias

Peer-to-Peer (P2P) ● Uma arquitetura de sistema distribuídos onde cada nó da rede funciona tanto como servidor como cliente, eliminando a necessidade de um servidor central; ● Ótimo para artefatos que podem ser replicados; ● Para artefatos que não podem ser replicados impõe desafios; ● Torrent, SoulSeek, DNS. https://pt.wikipedia.org/wiki/Peer-to-peer centralizado p2p

Double Spending Problem ● Falha de sistema onde um agente consegue gastar as mesmas moedas mais de um vez; ● Grande problema de transações digital, dado que artefatos digitais podem ser duplicados; ● De forma centralizada esse problema é resolvido com a presença de uma entidade que verifica fraudes e autoriza ou não as transações; ● Na versão distribuída se faz uso de um protocolo para lidar com tentativas de gasto duplo. https://en.wikipedia.org/wiki/Double-spending

Digital Distributed Ledger (livro-razão) ● Uma moeda baseada na internet é um ledger distribuído que guarda: ○ Quantas moedas pertencem para cada endereço da rede; ○ Transações que ocorreram.

Double Spending Problem

Hayek Money Nos anos 70 Hayek propõe que qualquer instituição financeira deveria poder distribuir suas moedas. Em um sistema de moedas concorrentes, os agentes escolhem em qual moeda e instituição emissora confiam mais, pressionando o governo para ser mais cauteloso com nosso dinheiro. Apesar das comparações, Bitcoin vai além da proposta do Hayek. Mas para Hayek, essas moedas ainda estariam atreladas a instituições regulamentadas pelo estado e que podem expandir ou contrair a oferta monetária.

Crítica ● O argumento apresentado não se sustenta. Bitcoin é mais lento e mais caro que outros tipos de transação eletrônica hoje em dia. Não só em termos financeiros. https://www.nature.com/articles/s41558-018-0321-8

Crítica ● Visa é capaz de processar 47.000 transações por segundo; ● Bitcoin suporta cerca de 7 tps com um limite de bloco de 1MB; ○ Foi proposto aumento do tamanho do bloco, porém ... ○ Para obter uma capacidade equivalente a Visa o limite seria quase 8 gigabytes por bloco Bitcoin. Isto resultaria em 400 TB ao ano. ● Sulução proposta: Lightning Network: ○ Permite que a informação trafegue através da rede passando por intermediários minimamente confiáveis (sub-redes baseadas em stacking), proporcionando que um nó possa pagar qualquer outro nó mesmo que eles não tenham um canal direto aberto entre eles. https://en.wikipedia.org/wiki/Bitcoin_scalability_problem

Transactions https://nakamotoinstitute.org/bitcoin/

Transactions ● Problema: como o recebedor pode verificar que o emissor double-spend the coin? ○ Solução tradicional: entidade centralizadora que media transações. ● Se ocorrer double-spend, a primeira transação é que conta, ignora as outras; ● Para conseguir validar, precisamos conhecer todas as transações, ou seja, todas precisam ser públicas: ○ Isso parece esquisito, mas transações de compra e venda de ações na bolsa é público. ● E os participantes da rede precisam concordar em seguir uma única versão da ordem de transações. https://en.wikipedia.org/wiki/Unspent_transaction_output

Transactions ● O emissor gera uma chave pública e uma privada; ● Assina a transação que garante que ela é autêntica; ● Envia a chave pública junto com a transação assinada para a rede; ● A chave pública pode ser usada para validar se a transação foi mesmo feita pelo emissor e não por uma parte terceira. Problema: ● Evitamos que alguém faça uma transação em nosso nome, porém, não evitamos que alguém faça duas transações fraudulentas; ● Como os participantes da rede Bitcoin concordam em um único histórico da ordem em que as transações foram recebidas? Timestamp server.

Transactions

Transactions https://www.blockchain.com/charts/transactions-per-second

Transactions Demo https://andersbrownworth.com/blockchain/public-private-keys/transaction

Timestamp Server ● Gera um hash de um bloco contendo uma lista de transações realizadas e publica na rede; ● Prova que os dados devem ter existido na época; ● Garante ordem histórica das transações; ● Cada timestamp inclui o anterior em seu hash, formando uma cadeia, com cada timestamp adicional reforçando os que vieram antes dele.

Timestamp Server Garantimos uma sequência de transações, mas aparece um novo problema: E se eu forçar a emissão de um blockchain secundário na rede? Posso reescrever o histórico de transações. Como podemos evitar um ataque na rede, onde vários nós reescrevem o histórico mudando a ordem das transações? Isso se resolve na próxima seção com Proof of Work.

Timestamp Server ● É por isso que que o Bitcoin mantém um mempool! (não citado no paper); ● Transações não são descartadas ou aceitas imediatamente. Um blockchain é uma linked list distribuída, onde o endereço de do nó anterior é o hash do cabeçalho, ao invés do endereço de memória de uma lista tradicional.

Mempool https://www.blockchain.com/charts/mempool-count ● Memória temporária onde novas transações são guardadas para serem processadas pelos mineradores e um novo bloco ser gerado; ● Mineradores podem escolher quais transações processar! (problema de Incentivos)

Block anatomy

Transaction anatomy

Transaction anatomy https://en.bitcoin.it/wiki/Script https://github.com/bitcoin/bips

Proof of Work ● Forma dos nós concordarem com quais transações são válidas; ● Envolve procurar um valor que quando calculado o hash, o mesmo comece com um número específico de zeros. Dado o algoritmo de hash usado (sha256 aqui), o trabalho cresce de forma exponencial ao número de bits zero requeridos.

Proof of Work ● "um voto por CPU" (não previram as Mining Farms); ● A decisão da maioria é representada pela cadeia mais longa; ● Todas as transações em um bloco específico são consideradas ocorridas ao mesmo tempo, e cada bloco é vinculado a uma cadeia de outros blocos com timestamp em ordem cronológica.

Proof of Work ● Se a maioria do poder de CPU é controlado por nós honestos, a cadeia honesta vai crescer mais rápido e superar quaisquer cadeias concorrentes; ● Para modificar um bloco passado, o atacante terá de refazer a prova-de-trabalho do bloco e depois de todos os blocos posteriores e, em seguida, alcançar e superar o trabalho dos nós honestos.

Proof of Work ● É por isso que exchanges validam com certeza uma transação após X blocos serem gerados. No geral, 6 blocos. Isso é demonstrado na seção 11 (Calculations); ● É possível enganar a rede com 51% das CPUs!

Proof of Work

Proof of Work

Hashcash (parênteses) Proposta original do Proof-of-Work citado no artigo; ● Proposto em 97 para evitar spam em sistemas de e-mail: ○ Hashcash - A Denial of Service Counter-Measure (Adam Back); ○ Baseado em uma ideia de 92! Pricing via Processing or Combatting Junk Mail (Cynthia Dwork,Moni Naor). The hypothesis is that spammers, whose business model relies on their ability to send large numbers of emails with very little cost per message, will cease to be profitable if there is even a small cost for each spam they send. Receivers can verify whether a sender made such an investment and use the results to help filter email.

Proof of Work Demo https://andersbrownworth.com/blockchain/coinbase

Network ● Se dois nós transmitem versões diferentes do próximo bloco; simultaneamente, os nós da rede consideram o primeiro que receberam; ● Consideram a cadeia mais longa como correta e continuarão trabalhando para estendê-la; ● Espera-se que eventualmente chegue-se a um consenso.

Incentive ● A primeira transação em um novo bloco é uma recompensa para o minerador. Um incentivo para suportarem a rede; ● É possível pagar uma taxa de mineração também, fazendo com o que o minerador escolha as transações com maiores taxas no mempool para serem processadas primeiro; ● Define-se o limite de moedas na rede, mas não a quantidade; ● Se atacantes forem capazes de reunir mais poder de CPU do que todos os nós honestos, eles teriam que escolher entre usá-lo para roubar pagamentos (tirando a confiança e quebrando o sistema) ou usá-lo para gerar novas moedas. https://en.wikipedia.org/wiki/Expected_utility_hypothesis

Custo de um ataque

Incentive (halving) ● Jan 2009 - Nov 2012: 50 BTC; ● Nov 2012 - Jul 2016: 25 BTC; ● Jul 2016 - Feb 2020: 12.5 BTC; ● Feb 2020 - Sep 2023: 6.25 BTC. Média por bloco: 10 minutos https://en.wikipedia.org/wiki/Expected_utility_hypothesis

Incentivos (dificuldade mineração)

Reclaiming Disk Space O hash das transações é gerado a partir de uma estrutura de Merkle Tree (data compression), dessa forma não precisa-se carregar todos os dados sempre, podendo cortar nós da árvore economizando espaço em disco.

Simplified Payment Verification Não é necessário ser um minerador para participar da rede. É possível enviar e receber transações, e verificar transações feitas, sem manter o histórico completo da rede, porém não é possível verificar se as transações são válidas.

Combining and Splitting Value Para permitir que o valor seja dividido e combinado, as transações contém múltiplas entradas e saídas. Podem existir várias entradas, mas no máximo duas saídas: uma para o pagamento, e outra retornando o troco para o remetente.

Considerações ● Em nenhum momento no paper se fala na quantidade de Bitcoin; ● Em nenhum momento no paper se fala na taxa de mudança da dificuldade do PoW (Muda a cada 4 anos no bitcoin); ● Pouco se fala da estruturas de dados dos blocos e transações; ● Não entramos em detalhes da evolução do sistema: ○ Scripting; ○ Lightning Network; ○ SegWit.

Ideias que vieram antes ● Secure digital transactions (Nick Szabo, 2005); ● Cryptography to secure transactions (DigiCash, 1989); ● Criação de dinheiro fora do sistema governamental (B-Money); ● Proof-of-Work (Hashcash).

Complete Token Demo https://andersbrownworth.com/blockchain/public-private-keys/blockchain

Papers We Love

Próximo encontro Sugestão de tema: protocolos de consenso.

Outras referências ● Livro Mastering Blockchain; ● Diferenças da implementação e Whitepaper: https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3 ● Versions of Bitcoin: https://bitcoin.org/en/version-history; ● Desenvolvimento: https://bitcoincore.org ● Cypherpunk Manifesto: https://github.com/NakamotoInstitute/nakamotoinstitute.org/blob/maste r/sni/static/docs/cypherpunk-manifesto.txt