Elogios para 'Mastering Bitcoin' "Quando eu falo sobre bitcoin para o pœblico em geral, ˆs vezes me perguntam 'mas como que isso realmente funciona?' Agora eu tenho uma —tima resposta para essa pergunta, porque qualquer um que ler o Mastering Bitcoin ter‡ um entendimento aprofundado de como ele funciona e estar‡ bem preparado para desenvolver a nova gera•‹o de incr’veis aplicativos de criptomoedas." Ñ Gavin Andresen, Andresen, Cientista Chefe Chefe da Bitcoin Bitcoin Foundation Foundation
"As tecnologias do Bitcoin e da blockchain est‹o se tornando pe•as fundamentais na constru•‹o da pr—xima gera•‹o da internet. Os melhores e mais brilhantes profissionais do Vale do Sil’cio est‹o e st‹o trabalhando nisso. O livro do Andreas ir‡ ajud‡-lo ˆ juntar-se ˆ revolu•‹o do software no mundo das finan•as." Ñ Naval Ravikant, Ravikant, Co-fundador Co-fundador da AngelList AngelList
" Mastering Bitcoin Ž a melhor referncia tŽcnica sobre o bitcoin atualmente dispon’vel. E o bitcoin provavelmente ser‡ visto retrospectivamente como a tecnologia mais importante dessa dŽcada. Como tal, esse livro Ž um item indispens‡vel para qualquer desenvolvedor de software, especialmente aqueles interessados em construir aplicativos com o protocolo bitcoin. Altamente recomendado." Ñ Balaji S. Srinivasan Srinivasan (@balajis), (@balajis), General General Partner Partner
ÒA inven•‹o da Blockchain do Bitcoin representa uma plataforma completamente nova, que ir‡ possibilitar um ecosistema t‹o amplo e diverso quanto a pr—pria Internet. Como um dos proeminentes l’deres da ideologia, Andreas Antonopoulos Ž a escolha perfeita para escrever esse livro." Ñ Roger Ver, Ver, Empreendedor Empreendedor e Investidor Investidor Bitcoin Bitcoin
1
êndice
Pref‡cio Escrevendo o Livro do Bitcoin A primeira vez que ouvi falar em bitcoin foi em meados de 2011. Minha rea•‹o imediata foi mais ou menos essa "Pfft! Dinheiro de nerd!" e eu ignorei-o por mais seis meses, sem compreender a sua import‰ncia. Esta Ž uma rea•‹o que eu tenho observado com frequncia entre muitas das pessoas mais inteligentes que conhe•o, o que me d‡ algum consolo. A segunda vez que me deparei com bitcoin, em uma lista de discuss‹o, eu decidi ler o seu "manual de instru•›es" oficial, o white paper escrito por Satoshi Nakamoto, para ver do que se tratava. Ainda me lembro do momento em que eu terminei de ler aquelas nove p‡ginas, quando eu percebi que bitcoin n‹o era simplesmente uma moeda digital, mas uma rede de confian•a que tambŽm poderia servir de base para aplica•›es muito mais avan•adas do que apenas moedas. Ap—s constatar que o bitcoin n‹o Ž dinheiro, mas sim uma rede de confian•a descentralizada, comecei uma viagem de quatro meses para devorar cada peda•o de informa•‹o que eu poderia encontrar sobre o assunto. Eu me tornei obcecado e encantado, gastando 12 ou mais horas por dia colado ao monitor, lendo, escrevendo, codificando e aprendendo o m‡ximo que pude. Ap—s pular muitas refei•›es, sa’ desse per’odo de obsess‹o 9 quilos mais magro e determinado a dedicar-me a trabalhar com bitcoin. Dois anos depois, ap—s criar v‡rias pequenas startups para explorar servi•os e produtos relacionados ao bitcoin, eu decidi que estava na hora de escrever meu primeiro livro. O Bitcoin foi um t—pico que me levou a um frenesi de criatividade e consumiu meus pensamentos; Foi a tecnologia mais empolgante que eu encontrei desde que conheci a Internet. Estava na hora de compartilhar minha paix‹o sobre essa incr’vel tecnologia com uma audincia mais ampla.
Pœblico Alvo Esse livro foi escrito principalmente para programadores. Se voc sabe alguma linguagem de programa•‹o, esse livro ir‡ ensin‡-lo como as moedas criptogr‡ficas funcionam, como utiliz‡-las e como desenvolver softwares que trabalhem com elas. Os primeiros cap’tulos tambŽm s‹o adequados como uma introdu•‹o aprofundada ao bitcoin para n‹o-programadores, que queiram entender o funcionamento interno do bitcoin e das criptomoedas.
Conven•›es Usadas Neste Livro As seguintes conven•›es tipogr‡ficas s‹o usadas neste livro: It‡lico
Indica novos termos, URLs, endere•os de e-mail, nomes e extens›es de arquivos. Largura constante
Usada para listagem de programas, assim como dentro de par‡grafos par‡grafos para se referir a elementos de programas como vari‡veis e nomes de fun•›es, banco de dados, tipos de dados, vari‡veis de 1
ambiente, declara•›es e palavras-chave palavras-chave.. Largura constante em negrito
Mostra comandos ou outro texto que deveria ser digitado literalmente pelo usu‡rio. Largura constante em it‡lico
Mostra um texto que deveria ser substitu’do por valores fornecidos pelo usu‡rio, ou valores determinados pelo contexto. TIP
Esse ’cone Ž usado em dicas, sugest›es ou notas em geral.
WARNING
Esse ’cone indica uma mensagem de aviso ou cuidado.
Exemplos de C—digos Os exemplos s‹o ilustrados em Python, C++ e usando uma linha de comando de um sistema operacional do tipo Unix, como Linux ou Mac OS X. Todos os snippets de c—digos est‹o dispon’veis no GitHub repository reposit—rio repository reposit—rio GitHub no subdiret—rio code do reposit—rio principal. Voc pode fazer um fork do c—digo do livro, testar exemplos de c—digos ou enviar corre•›es via GitHub. Todos os snippets de c—digos podem ser replicados na maioria dos sistemas operacionais com uma instala•‹o m’nima dos compiladores e interpretadores das linguagens correspondentes. Quando necess‡rio, n—s providenciaremos as instru•›es b‡sicas da instala•‹o e exemplos passo-a-passo do resultado dessas instru•›es. Alguns dos snippets de c—digos e do output do c—digo foram reformatados para a impress‹o. Em todos esses casos, as linhas foram divididas por uma barra invertida (\), seguida por um caractere de nova linha. Ao transcrever os exemplos, remova estes dois caracteres e una as linhas novamente, obtendo resultados idnticos aos mostrados no exemplo. Todos os snippets de c—digos, sempre que poss’vel, usam valores e c‡lculos reais, de maneira que voc possa construir de exemplo a exemplo e observar os mesmo resultados em qualquer c—digo que voc escrever para calcular os mesmos valores. Por exemplo, as chaves privadas e seus endere•os e chaves pœblicas correspondentes s‹o reais. As amostras de transa•‹o, blocos e referncias ˆ blockchain foram realmente introduzidas na blockchain do bitcoin e fazem parte do ledger pœblico, para que voc possa revis‡-las em qualquer sistema bitcoin.
Agradecimentos Este livro representa o esfor•o e contribui•›es de muitas pessoas. Agrade•o por toda ajuda que recebi de amigos, colegas e atŽ desconhecidos, que se juntaram a mim nessa tarefa de escrever o livro tŽcnico definitivo sobre criptomoedas e bitcoin. ƒ imposs’vel fazer uma distin•‹o entre a tecnologia Bitcoin e a comunidade bitcoin Ñ e este livro Ž um produto tanto dessa comunidade quanto Ž sobre a tecnologia. Meu trabalho nesse livro foi encorajado, 2
comemorado. apoiado e recompensado por toda a comunidade bitcoin desde o seu in’cio atŽ o fim. Mais do que tudo, esse livro me permitiu ser uma parte de uma comunidade maravilhosa por dois anos e n‹o posso agradecer suficientemente por eu ter sido aceito por essa comunidade. H‡ um nœmero imenso de pessoas para ser mencionadas pelo nome Ñ pessoas que encontrei em conferncias, eventos, semin‡rios, meetups, encontros de pizza e pequenas reuni›es, assim como tantos que se comunicam comigo via Twitter, Reddit, bitcointalk.org e pelo GitHub e que impactaram esse livro de alguma forma. Cada ideia, analogia, pergunta, resposta e explica•‹o que voc encontrar nesse livro foi de algum modo inspirada, testada ou melhorada atravŽs da intera•‹o com a comunidade. Muito obrigado a todos pelo apoio; esse livro n‹o teria acontecido sem vocs. Serei eternamente grato. A jornada para se tornar um autor come•a, Ž claro, muito antes do primeiro livro. Minha l’ngua nativa (e tambŽm na escola) era o grego, e por isso tive que fazer um curso emergencial de ingls escrito ainda no meu primeiro ano de universidade. Sou muito grato a Diana Kordas, minha professora de ingls escrito, que muito me ajudou a construir a confian•a e as habilidades que precisei naquele ano. Mais para frente, j‡ como profissional, desenvolvi minhas habilidades em escrita tŽcnica sobre data centers, escrevendo para a revista Network World. Meu agradecimentos a John Dix e John Gallant, que me deram meu primeiro trabalho como colunista na Network World, ao meu editor Michael Cooney e meu colega Johna Till Johnson, que editaram minhas colunas e as fizeram public‡veis. Escrever 500 palavras por semana durante quatro anos me deu experincia suficiente para eventualmente considerar a me tornar um autor. Obrigado ˆ Jean de Vera por ter me encorajado a tornar-me um autor e por sempre acreditar e insistir que eu tinha um livro dentro de mim. Obrigado tambŽm ˆqueles que me apoiaram quando enviei ˆ OÕReilly minha proposta de livro, ao enviarem referncias e revisarem o esbo•o. Especificamente, obrigado a John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver, and Jon Matonis. Um obrigado especial ao Richard Kagan e Tymon Mattozko, que revisaram as primeiras vers›es da proposta e a Matthew Owain Taylor, que fez a editora•‹o da proposta. Obrigado ao Cricket Liu, autor do t’tulo DNS and BIND, que me apresentou ˆ OÕReilly. Outro obrigado para Michael Loukides e Allyson Macdonald da OÕReilly, que trabalharam por meses, ajudando na confec•‹o desse livro. A Allyson foi especialmente paciente quando os prazos eram perdidos e as entregas atrasavam quando a vida fazia sua interven•‹o em nossa agenda planejada. Os primeiros rascunhos dos primeiros cap’tulos foram os mais dif’ceis, pois o bitcoin Ž um assunto dif’cil de ser desvendado. Cada vez que eu puxava um fio sobre a tecnologia bitcoin, eu tinha que puxar o novelo inteiro. Eu fiquei travado repetidas vezes, assim como um pouco desanimado enquanto lutava para fazer um t—pico de f‡cil entendimento e criar uma narrativa ao redor de um assunto t‹o denso tecnicamente. Eventualmente, decidi contar a est—ria do bitcoin atravŽs de est—rias de pessoas que usavam a criptomoeda e todo o livro ficou f‡cil de ser escrito. Devo meus agradecimentos ao meu amigo e mentor, Richard Kagan, que me ajudou a desvendar a est—ria e a superar os momentos de "bloqueio de escritor" e a Pamela Morgan, que revisou os primeiros rascunhos de cada cap’tulo e fez as perguntas dif’ceis, com o prop—sito de torn‡-los melhores. Obrigado tambŽm aos desenvolvedores do grupo San Francisco Bitcoin Developers Meetup e a Tariq Lewis, co-fundador do grupo, por me ajudar a testar o material inicial.
3
Durante o desenvolvimento do livro, eu disponibilizei os primeiros rascunhos via GitHub e convidei o pœblico para comentar. Mais de uma centena de coment‡rios, sugest›es, corre•›es e contribui•›es me foram enviadas em resposta. Tais contribui•›es foram reconhecidas e agradecidas publicamente em Lan•amento do Rascunho Inicial (Contribui•›es no GitHub). GitHub) . Obrigado especial para Minh T. Ngyuen, que se voluntariou para gerenciar as contribui•›es no GitHub e muitas outras que ele pr—prio adicionou. Obrigado tambŽm ao Andrew Naugler pelo desenho do infogr‡fico. Uma vez que o livro foi rascunhado, ele passou por diversas rodadas de revis‹o tŽcnica. Obrigado ao Cricket Liu e Lorne Lantz pelas extensas revis›es, coment‡rios e apoio. V‡rios desenvolvedores de bitcoin contribu’ram com exemplos de c—digos, revis›es, coment‡rios e encorajamento. Obrigado a Amir Taaki e Eric Voskuil pelos exemplos de snippets de c—digo e muitos coment‡rios de valor; a Vitalik Buterin e Richard Kiss pela ajuda com a matem‡tica da curva el’ptica e contribui•›es com o c—digo; Gavin Andresen pelas corre•›es, coment‡rios e encorajamento; Michalis Kargakis pelos coment‡rios, contribui•›es e escrita btcd; e a Robin Inge pelos envios de erratas, melhorando a segunda impress‹o do livro. Eu devo o meu amor pelas palavras e livros ˆ minha m‹e, Theresa, que me criou em uma casa com livros enfileirados em cada parede. Minha m‹e tambŽm me deu meu primeiro computador em 1982, mesmo ela sendo uma tecn—foba assumida. Meu pai, Menelaos, um engenheiro civil que recŽm publicou seu primeiro livro aos 80 anos de idade, foi quem me ensinou o pensamento l—gico e anal’tico, bem como o amor pela cincia e engenharia. Obrigado a todos por me apoiarem durante toda esta jornada.
Lan•amento do Rascunho Inicial (Contribui•›es no GitHub) Muitos contribuidores enviaram coment‡rios, corre•›es e adi•›es para a vers‹o inicial no GitHub. Muito obrigado a todos por suas contribui•›es para esse livro. Abaixo, uma lista de contribuidores not‡veis no GitHub, incluindo seus IDs em parnteses: ¥ Minh T. T. Nguyen, editor editor de contribui•‹o no GitHub (enderminh) (enderminh) ¥ Ed Eykho Eykholt lt (edey (edeykho kholt) lt) ¥ Micha Michalis lis Karga Kargakis kis (karg (kargakis) akis) ¥ Eri Erikk Wahlst Wahlstršm ršm (erik (erikwam wam)) ¥ Richa Richard rd Kiss (rich (richardki ardkiss) ss) ¥ Eri Ericc Winchel Winchelll (winch (winchell ell)) ¥ Serg Sergej ej Kotl Kotliar iar (zig (ziggamon gamon)) ¥ Naga Nagaraj raj Hubli (naga (nagaraj rajhubli hubli)) ¥ ethers ¥ Alex Wa Waters ters (alex (alexwater waters) s) ¥ Mih Mihail ail Russu Russu (Mihail (MihailRus Russu) su)
4
¥ Ish Ot Jr. Jr. (ish (ishotj otjr) r) ¥ Jame Jamess Addiso Addison n (jaya (jayaddiso ddison) n) ¥ Nek Nekoma omata ta (neko (nekomat mata-3 a-3)) ¥ Simon de la Rouvi Rouviere ere (simon (simondlr) dlr) ¥ Chap Chapman man Shoop (belo (belovacha vachap) p) ¥ Holg Holger er Schinz Schinzel el (schi (schinzelh nzelh)) ¥ effe effectsT ctsToCau oCause se (ver (vericoin icoin)) ¥ Ste Stepha phan n Oeste Oeste (Em (Emzy) zy) ¥ Joe Baue Bauers rs (joeb (joebaue auers) rs) ¥ Jaso Jason n Bisterfe Bisterfeldt ldt (jbiste (jbisterfel rfeldt) dt) ¥ Ed Lea Leafe fe (Ed (EdLea Leafe) fe)
Edi•‹o Aberta Essa Ž a edi•‹o aberta do "Mastering Bitcoin", publicado para tradu•›es sob a licen•a Creative Commons Atribui•‹o-CompartilhaIgual (CC-BY-SA). (CC-BY-SA) . Essa licen•a permite que voc leia, compartilhe, copie, imprima, venda ou reutilize esse livro ou partes dele, desde que voc: ¥ Utili Utilize ze a mesma licen• licen•aa (Compartil (Compartilha-Ig ha-Igual) ual) ¥ Inc Inclua lua atr atribu ibui•‹ i•‹oo
Atribui•‹o Mastering Bitcoin por Andreas M. Antonopoulos LLC https://bitcoinbook.info Copyright 2016, Andreas M. Antonopoulos LLC
Tradu•‹o Se voc estiver lendo esse livro em um idioma que n‹o seja o ingls, ele foi traduzido por volunt‡rios. As seguintes pessoas contribu’ram para essa tradu•‹o: ¥ AndrŽ Torres Torres (@Criptonauta) (@Criptonauta) - Coordena•‹o e tradu•‹o tradu•‹o / Rodrigo Castilhos - Revis‹o Revis‹o e tradu•‹o tradu•‹o ¥ Fern ernand andoo Bitti Bitti Loureir Loureiroo ¥ Fe Fernan rnando do Paladini, Paladini, Anderso Anderson n Juhasc, Paulo Paulo Gomes
5
Gloss‡rio R‡pido Este gloss‡rio r‡pido contŽm muitos dos termos relacionados ao bitcoin que ser‹o usadas durante todo o livro. Recomendamos que favorite essa se•‹o para ter uma referncia r‡pida, caso necess‡rio. endere•o Um endere•o bitcoin se parece com 1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV. Ele consiste de uma sequncia de letras e nœmeros come•ando com um "1" (nœmero um). Assim como voc pede para alguŽm enviar um email para seu endere•o de email, voc pediria a outras pessoas para enviarem bitcoin para seu endere•o bitcoin. bip Bitcoin Improvement Proposals (Propostas de Melhoria Bitcoin). Um conjunto de propostas que membros da comunidade bitcoin tm feito para melhorar o bitcoin. Por exemplo, BIP0021 Ž uma proposta para melhorar melhorar a estrutura do Identificador Uniforme de Recursos (URI) do bitcoin. bitcoin O nome da unidade monet‡ria (a moeda), a rede e o software. bloco Um agrupamento de transa•›es, marcadas com um registro de tempo e uma impress‹o digital do bloco anterior. O cabe•alho do bloco Ž codificado para produzir uma prova de trabalho, assim validando as transa•›es. Blocos v‡lidos s‹o adicionados ˆ blockchain atravŽs atravŽs do consenso da rede. blockchain Uma lista de blocos validados, cada um ligado ao seu predecessor atŽ chegar ao bloco gnesis. confirma•›es Uma vez que uma transa•‹o Ž inclu’da em um bloco, ela recebe uma confirma•‹o. Assim que outro bloco Ž minerado na mesma blockchain, a transa•‹o tem duas confirma•›es, e assim continua. Seis ou mais confirma•›es s‹o consideradas como prova suficiente de que a transa•‹o n‹o pode ser desfeita. dificuldade Um par‰metro que afeta toda a rede e controla o quanto de esfor•o computacional Ž necess‡rio para produzir uma prova de trabalho. meta de dificuldade Uma dificuldade na qual toda a computa•‹o na rede encontrar‡ blocos aproximadamente a cada 10 minutos. calibragem da meta de dificuldade Um rec‡lculo da meta de dificuldade que afeta toda a rede e ocorre a cada 2.106 blocos, levando em considera•‹o o poder de hashing dos 2.106 blocos anteriores.
1
taxas O emissor de uma transa•‹o frequentemente inclui uma taxa para a rede pelo processamento de uma determinada transa•‹o. A maioria das transa•›es requer uma taxa m’nima de 0.5 mBTC. hash Uma impress‹o digital de alguma entrada bin‡ria. bloco gnesis O primeiro bloco na blockchain, usado para iniciar a criptomoeda. minerador Um n— da rede que encontra uma prova de trabalho v‡lida para novos blocos, atravŽs do uso repetido de hash. rede Uma rede ponto-a-ponto (peer-to-peer) que propaga transa•›es e blocos para cada n— de bitcoin na rede. Prova-de-Trabalho Prova-de-Trab alho Em ingls, Proof-of-Work (PoW). Uma parte de um dado que requer um esfor•o computacional consider‡vell para ser encontrada. No bitcoin, mineradores devem encontrar uma solu•‹o numŽrica consider‡ve para o algoritmo SHA-256 que esteja em conformidade com a meta da rede, a meta de dificuldade. recompensa Uma quantidade de moedas inclu’da pela rede, em cada novo bloco, como recompensa ao minerador que encontrou a solu•‹o da Prova-de-Trabalho. Atualmente, a recompensa Ž de 25BTC por bloco. chave secreta (chave privada) O nœmero secreto que destrava os bitcoins enviados para um determinado endere•o. Uma chave secreta se parece com 5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh. transa•‹o Em termos simples, uma transferncia de bitcoins de um endere•o para outro. Mais precisamente, uma transa•‹o Ž uma estrutura de dados assinada que expressa uma transferncia de valor. Transa•›es s‹o transmitidas pela rede bitcoin, coletadas por mineradores, inclu’das nos blocos e tornadas permanentes na blockchain. carteira Um software que contŽm todos seus endere•os bitcoins e suas chaves secretas. Usada para enviar, receber e armazenar seus bitcoins.
2
Introdu•‹o O que Ž Bitcoin? Bitcoin Ž um conjunto de conceitos e tecnologias que formam a base de um ecossistema de dinheiro digital. As unidades de moeda chamadas bitcoins s‹o usadas para armazenar e transmitir valor entre os participantes na rede Bitcoin. Os usu‡rios Bitcoin comunicam-se entre si utilizando o protocolo bitcoin principalmente atravŽs da Internet, mas outras formas de rede tambŽm podem ser usadas. A implementa•‹o da pilha do protocolo bitcoin, est‡ dispon’vel como software de c—digo aberto, pode ser executada em uma ampla variedade de dispositivos de computa•‹o, incluindo laptops e smartphones, o que torna a tecnologia de f‡cil acesso. Os usu‡rios podem transferir bitcoins atravŽs da rede para fazer as mesmas coisas que as moedas convencionais podem fazer, incluindo compra e venda de bens, envio de dinheiro a pessoas e organiza•›es ou mesmo a extens‹o de crŽdito. Os bitcoins podem ser comprados, vendidos ou trocados por outras moedas em em casas de c‰mbio especializadas especializadas - as populares exchanges. De certo modo, modo, o Bitcoin Ž o dinheiro perfeito para a Internet, pois Ž r‡pido, seguro e sem fronteiras. Ao contr‡rio das moedas tradicionais, os bitcoins s‹o inteiramente virtuais. N‹o h‡ moedas f’sicas ou mesmo moedas digitais por si s—. As moedas de bitcoin se subentendem como transa•›es que transferem valor de um remetente a um destinat‡rio. Os usu‡rios de bitcoin possuem chaves que lhes permitem provar a posse de transa•›es na rede bitcoin, desbloqueando o valor (em bitcoins) a ser gasto e o transferindo para um novo destinat‡rio. Essas chaves geralmente s‹o armazenadas em uma carteira digital no computador ou smartphone de cada usu‡rio. A posse da chave que desbloqueia uma transa•‹o Ž o œnico prŽ-requisito para gastar os bitcoins, pondo o controle inteiramente nas m‹os de cada usu‡rio. Bitcoin Ž um sistema distribu’do ponto-a-ponto (peer-to-peer ou P2P). Como tal, n‹o existe um servidor "central" ou ponto de controle. Os bitcoins s‹o criados (gerados) atravŽs de um processo chamado de "minera•‹o", que consiste em competir para encontrar solu•›es para um problema matem‡tico enquanto se processam transa•›es de bitcoins. Qualquer participante na rede bitcoin (ou seja, qualquer usando um dispositivo que execute a implementa•‹o completa de protocolo Bitcoin) pode ser um minerador, bastando utilizar o poder de processamento de seu computador para verificar e registrar transa•›es. transa•›es. Em mŽdia, a cada 10 minutos alguŽm Ž capaz de validar as transa•›es dos œltimos 10 minutos, sendo recompensado com bitcoins novinhos em folha. Essencialmente, a minera•‹o de bitcoins descentraliza as fun•›es de emiss‹o de moeda e de compensa•‹o tipicamente atribu’das a um banco central, dessa forma substituindo a necessidade de qualquer banco central. O protocolo bitcoin contm algoritmos que regulam a fun•‹o de minera•‹o atravŽs da rede. A dificuldade da tarefa de processamento que os mineradores devem realizar Ñ registrar com sucesso um bloco de transa•›es na rede bitcoin Ñ ajusta-se dinamicamente de tal forma que, em mŽdia, alguŽm Ž bem-sucedido a cada 10 minutos, independentemente de quantos mineradores (e CPUs) estejam trabalhando na tarefa a qualquer momento. O protocolo tambŽm reduz ˆ metade, a cada 4 anos, a taxa com que novos bitcoins s‹o criados, limitando, assim, o nœmero total de bitcoins que ser‹o 1
criados a um m‡ximo de 21 milh›es de moedas. O resultado Ž que o nœmero de bitcoins em circula•‹o segue uma curva previs’vel que alcan•ar‡ 21 milh›es no ano de 2140. Devido ˆ taxa decrescente de emiss‹o, em longo prazo a moeda bitcoin Ž deflacion‡ria. AlŽm disso, bitcoin n‹o pode ser inflacionado "imprimindo" novo dinheiro alŽm da taxa t axa de emiss‹o j‡ esperada esperada.. Nos bastidores, bitcoin Ž tambŽm o nome do protocolo, de uma rede e de uma inova•‹o digital distribu’da. A moeda bitcoin Ž, na verdade, apenas a primeira aplica•‹o desta inven•‹o. Como um programador, eu vejo o bitcoin parecido com a Internet do dinheiro, uma rede para propagar valor e proteger a posse de ativos digitais atravŽs da computa•‹o distribu’da. H‡ muito mais no bitcoin do que se enxerga ˆ primeira vista. Neste cap’tulo inicial ensinaremos alguns dos principais conceitos e termos, alŽm de como baixar o software necess‡rio e como usar o bitcoin para transa•›es simples. Nos cap’tulos seguintes iremos desembrulhar as camadas de tecnologia que tornam poss’vel o bitcoin e examinar o funcionamento interno da rede e do protocolo bitcoin. Moedas Digitais Antes do Bitcoin O surgimento de uma moeda digital vi‡vel est‡ intimamente relacionado ˆ evolu•‹o da criptografia. criptografi a. Isso n‹o Ž algo surpreendente surpreendente quando se leva em considera•‹o considera•‹o os desafios fundamentais envolvidos no uso de bits para a representa•‹o de um valor que pode ser trocado por bens e servi•os. Duas perguntas b‡sicas feitas por qualquer um que aceite dinheiro digital s‹o: 1. Posso confiar que o dinheiro Ž autntico e n‹o falsificado? falsificado? 2. Posso estar seguro seguro de que ninguŽm ninguŽm vai reclamar que esse dinheiro dinheiro lhe pertence e n‹o a mim? (tambŽm conhecido como o problema do "gasto duplicado") Os emissores do dinheiro em papel est‹o o tempo todo enfrentando o problema da falsifica•‹o atravŽs do uso de papŽis e tecnologias de impress‹o cada vez mais sofisticados. O dinheiro f’sico resolve facilmente o problema do gasto duplicado, pois a mesma nota em papel n‹o pode estar em dois lugares ao mesmo tempo. ƒ claro que o dinheiro convencional Ž frequentemente armazenado e transmitido de forma digital. Nestes casos, os problemas de falsifica•‹o e de gastos duplicados s‹o tratados pela compensa•‹o de todas as transa•›es eletr™nicas atravŽs de autoridades centrais que detm uma vis‹o global da moeda em circula•‹o. No caso do dinheiro digital, que n‹o pode pode se beneficiar de tintas especiais ou marcas hologr‡ficas, a criptografia proporciona a base para confiar na legitimidade de um valor que um usu‡rio afirma possuir. Especificamente, as assinaturas digitais criptogr‡ficas permitem a um usu‡rio assinar um ativo digital ou transa•‹o provando a posse do ativo. Com a arquitetura apropriada, as assinaturas digitais tambŽm podem ser usadas para resolver o problema do gasto duplicado. No final dos anos 1980, quando a criptografia come•ou a se tornar mais acess’vel e entendida, muitos pesquisadores come•aram a tentar us‡-la para construir moedas digitais. Estes projetos pioneiros emitiam dinheiro digital, normalmente lastreados por uma moeda nacional ou um metal precioso - como o ouro.
2
Apesar destas moedas digitais pioneiras funcionarem, elas eram centralizadas e, como resultado, eram f‡ceis de ser atacadas tanto por governos como por hackers. As primeiras moedas digitais usavam uma central de compensa•‹o para finalizar todas as transa•›es em intervalos regulares, da mesma forma que um sistema banc‡rio tradicional. Infelizmente, em muitos casos essas moedas digitais que surgiam se tornavam um alvo dos governos preocupados e eventualmente desapareciam. Algumas falharam em quebras espetaculares quando a companhia respons‡vel era liquidada de repente. Para ser robusta contra a interven•‹o de opositores, fossem governos leg’timos ou elementos criminosos, uma moeda descentralizada digital se tornava necess‡ria para evitar um œnico ponto de ataque. Este sistema Ž o Bitcoin, projetado para ser completamente descentralizado e livre de qualquer autoridade central ou ponto de controle que possa ser atacado ou corrompido. O Bitcoin representa o auge de dŽcadas de pesquisa em criptografia e sistemas distribu’dos e inclui quatro inova•›es chaves reunidas em uma combina•‹o œnica e poderosa. O Bitcoin consiste em: ¥ Uma rede rede peer-to-peer peer-to-peer descentralizada descentralizada (o protocolo bitcoin) ¥ Um registro pœblico de transa•›es (a blockchain ou cadeia de blocos) ¥ Uma emiss‹o de moeda descentraliza descentralizada, da, matem‡tica e determin’stica (a minera•‹o minera•‹o distribu’da) ¥ Um sistema descentralizado descentralizado de de verifica•‹o de transa•›es transa•›es (o script de transa•‹o)
A Hist—ria do Bitcoin O Bitcoin foi inventado em 2008 com a publica•‹o de um documento intitulado "Bitcoin: Um Sistema de Dinheiro Eletr™nico Ponto-a-Ponto" ("Bitcoin: A Peer-to-Peer Electronic Cash System" em ingls), escrito por um autor sob o pseud™nimo de Satoshi Nakamoto. Nakamoto combinou v‡rias das inven•›es anteriores tais como b-money e HashCash para criar um sistema de dinheiro eletr™nico completamente descentralizado que n‹o dependesse de uma autoridade central para a emiss‹o de moeda ou para a liquida•‹o e valida•‹o de transa•›es. A principal inova•‹o foi usar um sistema de computa•‹o distribu’do (chamado algoritmo de "prova de trabalho" ou "proof of work") para conduzir uma "elei•‹o" global a cada 10 minutos, permitindo ˆ rede descentralizada chegar em um consenso sobre o estado das transa•›es. Isto resolve de forma elegante o problema de gasto duplicado, onde uma um a œnica unidade de moeda poderia ser gasta duas vezes. Antes do Bitcoin, o problema de gasto duplicado era uma fraqueza do dinheiro digital, e sua solu•‹o envolvia a transmiss‹o e verifica•‹o de todas as transa•›es atravŽs de uma entidade central. A rede bitcoin surgiu em 2009, baseada em uma implementa•‹o de referncia publicada por Nakamoto e desde ent‹o revisada por muitos outros programadores. A computa•‹o distribu’da que proporciona seguran•a e robustez ao bitcoin cresceu exponencialmente, e agora excede a capacidade combinada de processamento dos principais supercomputadores do mundo. Em 2014, o valor de mercado do bitcoin era estimado entre 5 e 10 bilh›es de d—lares americanos, dependendo da taxa de c‰mbio entre o bitcoin e o d—lar. A maior transa•‹o processada atŽ 2014 pela rede foi de US$ 150
3
milh›es, transmitida instantaneamente e processada sem nenhuma taxa. Satoshi Nakamoto afastou-se do pœblico em abril de 2011, deixando a responsabilidade pelo desenvolvimento do c—digo e da rede nas m‹o de um animado grupo de volunt‡rios. A identidade da pessoa ou pessoas por tr‡s do bitcoin ainda Ž desconhecida. No entanto, nem Satoshi Nakamoto nem qualquer outra pessoa exerce controle sobre o sistema bitcoin, que opera baseado em princ’pios matem‡ticos totalmente transparentes. transparentes. A inven•‹o em si Ž revolucion‡ria e j‡ criou um novo campo de estudos nas ‡reas da computa•‹o distribu’da, economia e econometria.
Uma Solu•‹o para um Problema de Computa•‹o Distribu’da O invento de Satoshi Nakamoto Ž tambŽm uma solu•‹o pr‡tica para um problema que atŽ ent‹o n‹o estava resolvido na computa•‹o distribu’da, conhecido como o "Problema dos Generais Bizantinos". Em resumo, o problema consiste em tentar tomar uma decis‹o atravŽs do interc‰mbio de informa•›es sobre uma rede pouco confi‡vel e potencialmente comprometida. A solu•‹o de Satoshi Nakamoto, que utiliza o conceito de prova de trabalho (proof-of-work) para alcan•ar o consenso sem uma autoridade central confi‡vel, representa um enorme avan•o na cincia de computa•‹o distribu’da e possui amplas aplica•›es alŽm da ser um meio de pagamento. Tal solu•‹o pode ser usada para alcan•ar consenso em redes descentralizadas para provar a honestidade de elei•›es, loterias, registros de bens, notariza•‹o digital e mais.
Usos do Bitcoin, Seus Usu‡rios e Suas Hist—rias Bitcoin Ž uma tecnologia usada para representar dinheiro, que Ž fundamentalmente uma linguagem para a troca de valor entre pessoas. Vamos conhecer as hist—rias de pessoas que est‹o usando bitcoin e alguns dos usos mais comuns da moeda e do protocolo. Iremos reutilizar essas hist—rias ao longo do livro para ilustrar os usos do dinheiro digital na vida real e como eles se tornaram poss’veis por meio das v‡rias tecnologias que s‹o partes do bitcoin. Varejo de baixo valor nos Estados Unidos
A Alice mora na ‡rea norte da ba’a da Calif—rnia. Ela ouviu falar sobre o bitcoin atravŽs dos seus amigos e quer come•ar a us‡-lo. Iremos acompanhar a hist—ria de como ela aprende a respeito do bitcoin, adquire algumas moedas e ent‹o gasta alguns de seus bitcoins para comprar uma x’cara de cafŽ no BobÕs CafŽ em Palo Alto. Esta hist—ria ir‡ nos apresentar ao software, ˆs casas de c‰mbio e transa•›es b‡sicas desde a perspectiva de um consumidor do varejo. Varejo de produtos de alto valor nos Estados Unidos
A Carol Ž dona de uma galeria de arte em San Francisco. Ela vende pinturas caras por bitcoin. Esta hist—ria nos vai apresentar os riscos de um ataque de consenso "51%" para varejistas de produtos de alto valor. Servi•os de contrato contratoss internacionai internacionaiss
O Bob, o dono da cafeteria de Palo Alto, est‡ montando um novo website. Ele contratou um
4
programador web indiano, o Gopesh, que mora em Bangalore, êndia. O Gopesh aceitou ser pago em bitcoin. Esta hist—ria vai examinar o uso do bitcoin para a terceiriza•‹o, contratos de servi•os e transferncias transfernci as banc‡rias internacionais. Doa•›es beneficentes beneficentes
A Eugnia Ž a diretora de uma institui•‹o de caridade para crian•as nas Filipinas. Recentemente ela descobriu o bitcoin e quer us‡-lo para alcan•ar um grupo completamente diferente de doadores locais e estrangeiros para financiar sua institui•‹o de caridade. Ela tambŽm tem investigado formas de usar o bitcoin para rapidamente distribuir os fundos nas ‡reas necessitadas. Esta hist—ria ir‡ mostrar o uso do bitcoin para a angaria•‹o de fundos atravŽs de fronteiras e moedas e o uso de um registro cont‡bil aberto para a transparncia de organiza•›es de caridade. Importa•‹o e exporta•‹o exporta•‹o
O Mohammed Ž um importador de eletr™nicos em Dubai. Ele vem tentando usar o bitcoin para comprar eletr™nicos dos Estados Unidos e da China para importa•‹o aos Emirados çrabes Unidos e assim acelerar o processo de pagamentos para as importa•›es. Esta hist—ria ir‡ mostrar como o bitcoin pode ser usado para grandes pagamentos internacionais B2B entre neg—cios de grande porte atados a mercadorias f’sicas. Minerando bitcoins bitcoins
O Jing Ž um estudante de engenharia de computa•‹o em Shanghai. Ele possui uma aparelhagem de "minera•‹o" para para minerar bitcoins, usando suas habilidades de engenharia para complementar sua renda. Esta hist—ria ir‡ examinar a base "industrial" do bitcoin: o equipamento especializado usado para proteger a rede bitcoin e emitir nova moeda. Cada uma dessas hist—rias se baseia em pessoas reais e indœstrias reais que atualmente usam bitcoin para criar novos mercados, novas indœstrias e solu•›es inovadoras para os problemas econ™micos globais.
Como Come•ar Para participar da rede bitcoin e come•ar a usar a moeda, tudo que um usu‡rio precisa fazer Ž baixar um programa ou usar um aplicativo web. Como o bitcoin Ž um padr‹o, h‡ muitas implementa•›es do software de cliente bitcoin. TambŽm h‡ uma implementa•‹o de referncia, conhecida como o cliente Satoshi, que Ž gerenciado como um projeto de c—digo aberto por uma equipe de desenvolvedores e provŽm da implementa•‹o original escrita por Satoshi Nakamoto. Os trs principais tipos de clientes bitcoin s‹o: Cliente completo
Um cliente completo, ou "n— completo", armazena todo o hist—rico de transa•›es de bitcoins (cada uma das transa•›es de todos os usu‡rios, desde o come•o), gerencia as carteiras dos usu‡rios e pode iniciar transa•›es diretamente na rede bitcoin. Isto Ž similar a um servidor de email independente, no sentido de que ele trata de todos os aspectos do protocolo sem depender de quaisquer outros servidores ou servi•os de terceiros. 5
Cliente compacto
Um cliente compacto armazena a carteira do usu‡rio, mas depende de servidores mantidos por terceiros para ter acesso ˆs transa•›es e ˆ rede Bitcoin. O cliente compacto n‹o guarda uma c—pia completa de todas as transa•›es e portanto precisa confiar nos servidores de terceiros para validar transa•›es. ƒ similar a um cliente de email aut™nomo que se conecta a um servidor de email para acessar uma caixa de emails, no sentido de que depende de um terceiro para interagir com a rede. Cliente web
Os clientes web s‹o utilizados atravŽs de um navegador web e armazenam a carteira do usu‡rio em um servidor mantido por um terceiro. terceiro. Isso Ž similar ao webmail no sentido em em que eles dependem completamente de um servidor de terceiros.
Clientes m—veis ("smartphones, clientes para bitcoin"Os clientes m—veis para smartphones, tais como aqueles baseados no sistema Android, podem operar tanto como clientes completos, quanto como compactos ou web. Alguns clientes m—veis se sincronizam com um cliente web ou de PC, proporcionando assim uma carteira multiplataforma entre mœltiplos dispositivos, mas com uma fonte comum de fundos. A escolha do cliente bitcoin depende de quanto controle o usu‡rio quer sobre os fundos. Um cliente completo ir‡ oferecer o m‡ximo n’vel de controle e independncia do usu‡rio, mas, em compensa•‹o, deixa a responsabilidade pelos backups e pela seguran•a nas m‹os do usu‡rio. No outro extremo de op•›es, um cliente web Ž o mais f‡cil de configurar de de usar, mas, em compensa•‹o, introduz um risco adicional, j‡ que a seguran•a e o controle s‹o compartilhados com o usu‡rio e o dono do servi•o web. Se um servi•o de carteira web Ž comprometido, como muitos j‡ foram, os usu‡rios podem perder todos os seus fundos. Por outro lado, se os usu‡rios tiverem um cliente completo sem os backups adequados, eles podem perder todos os seus fundos por causa de um contratempo do computador. Para os prop—sitos deste livro, demonstraremos o uso de uma variedade de clientes bitcoin que podem ser baixados, desde a implementa•‹o de referncia (o cliente Satoshi) atŽ as carteiras web. Alguns dos exemplos v‹o necessitar o uso do cliente de referncia, que alŽm de ser um cliente completo tambŽm exp›e APIs de acesso ˆ carteira, rede e servi•os de transa•›es. Se voc planeja explorar as interfaces program‡ticas de acesso no sistema bitcoin, voc ir‡ precisar do cliente de referncia.
In’cio R‡pida Alice, a quem apresentamos na se•‹o Usos do Bitcoin, Seus Usu‡rios e Suas Hist—rias n‹o Ž uma usu‡ria tŽcnica e s— recentemente ouviu falar do bitcoin atravŽs de um amigo. Ela come•a sua jornada visitando o website oficial bitcoin.org bitcoin.org,, onde encontra uma ampla sele•‹o de clientes bitcoin. Seguindo o conselho do site bitcoin.org, ela escolhe o cliente bitcoin compacto Multibit. Alice segue um link do site bitcoin.org para baixar e instalar a Multibit no PC dela. Multibit est‡ dispon’vel para computadores computadores Windows, Mac OS e Linux.
6
WARNING
Uma carteira bitcoin deve ser protegida por uma senha ou frase. H‡ muitos criminosos tentando quebrar senhas fracas, ent‹o tenha o cuidado de selecionar uma que n‹o possa ser facilmente decifrada. Use uma combina•‹o de caracteres maiœsculos e minœsculos, nœmeros e s’mbolos. Evite usar informa•‹o pessoal como datas de nascimento ou nomes de times de futebol. Evite quaisquer palavras facilmente encontradas em dicion‡rios, em qualquer idioma. Se puder, use um gerador de senhas para criar uma senha completamente aleat—ria que tenha no m’nimo 12 caracteres de comprimento. Lembre-se: bitcoin Ž dinheiro e pode ser transferido instantaneamente para qualquer lugar do mundo. Se n‹o for bem protegido, ele pode ser facilmente roubado.
Assim que a Alice terminar de baixar e instalar o aplicativo Multibit, ela o executa e Ž saudada pela tela de Boas-Vindas, como mostrado na A tela de boas-vindas do cliente bitcoin Multibit .
Figure 1. A tela de boas-vindas boas-vindas do cliente cliente bitcoin Multibit Multibit
Multibit automaticamente cria uma carteira e um novo endere•o bitcoin para Alice, que Alice pode ver clicando na aba Solicitar em O novo endere•o bitcoin da Alice, na aba Solicitar do cliente Multibit. Multibit .
7
Figure 2. O novo novo endere•o bitcoin da Alice, na aba Solicitar Solicitar do cliente cliente Multibit
A parte mais importante desta tela Ž o endere•o bitcoin da Alice. Assim como um endere•o de email, a Alice pode compartilhar este endere•o e qualquer um pode us‡-lo para mandar dinheiro diretamente ˆ carteira dela. Na tela aparece uma longa sequncia de letras e nœmeros: 1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK. Junto ao endere•o bitcoin da carteira est‡ um c—digo QR, uma forma de c—digo de barras que contŽm a mesma informa•‹o, mas em um formato que pode ser escaneado pela c‰mera de um smartphone. O c—digo QR Ž a imagem quadrada que contŽm pequenos quadrados preto e brancos no lado direito da janela. A Alice pode copiar o endere•o bitcoin ou o c—digo QR clicando no bot‹o copy junto de cada um deles. Ao clicar no pr—prio c—digo QR ele ser‡ ampliado, podendo facilmente ser escaneado pela c‰mera de um smartphone. A Alice pode tambŽm imprimir o c—digo QR como uma forma de passar facilmente seu endere•o a outras pessoas sem que eles tenham de se lembrar de digitar uma longa sequncia de letras e nœmeros.
TIP
Os endere•os bitcoin come•am sempre com o d’gito 1 ou 3. Assim como endere•os de email, eles podem ser compartilhados com outros usu‡rios bitcoin que podem us‡-los para mandar bitcoin diretamente a sua carteira. Ao contr‡rio dos endere•os de email, voc pode criar novos endere•os ˆ vontade, e todos eles direcionar‹o os fundos para sua carteira. Uma carteira Ž simplesmente uma cole•‹o de endere•os e as chaves que desbloqueiam os fundos que est‹o nela. Voc pode aumentar a sua privacidade usando um endere•o diferente para cada transa•‹o. N‹o h‡ nenhuma limita•‹o na quantidade de endere•os que um usu‡rio pode criar.
Agora a Alice est‡ pronta para come•ar a usar sua nova carteira bitcoin.
Obtendo Os Seus Primeiros Bitcoins Ainda n‹o Ž poss’vel comprar os bitcoins em um banco ou casa de c‰mbio de moedas estrangeiras. Em 2014, ainda era dif’cil adquirir bitcoins na maior parte dos pa’ses. H‡ algumas casas de c‰mbio 8
especializadas onde voc pode comprar e vender bitcoin pagando com a sua moeda local. Estas operam online como bolsas de criptomoedas e incluem: Bitstamp
Uma bolsa de criptomoedas europŽia que permite comprar v‡rias divisas inclusive euros (EUR) e d—lares americanos (USD) atravŽs de transferncia banc‡ria. Coinbase
Baseada nos EUA, Ž uma carteira e uma plataforma de bitcoin onde comerciantes e consumidores podem fazer transa•›es em bitcoin. Coinbase torna f‡cil comprar e vender bitcoin, permitindo aos usu‡rios se conectarem ˆs suas contas banc‡rias nos EUA atravŽs do sistema ACH (Automated Clearing House). Bolsas de criptomoedas como essas operam na interse•‹o entre moedas nacionais e criptomoedas. Assim elas est‹o sujeitas ˆs normas nacionais e internacionais e, com frequncia, s‹o espec’ficas a um determinado pa’s ou regi‹o econ™mica e se especializam nas moedas nacionais daquela regi‹o. Sua escolha de bolsas de criptomoedas ser‡ espec’fica para moeda nacional que voc usa e limitada ˆs exchanges que operam dentro da jurisdi•‹o legal de seu pa’s. De maneira similar a uma conta banc‡ria, pode levar v‡rios dias ou semanas para configurar as contas necess‡rias com estes servi•os pois eles requerem v‡rias formas de identifica•‹o para atender ˆs exigncias das regula•›es banc‡rias KYC (know your customer ou conhe•a seu cliente) e AML (anti-money laundering ou combate ˆ lavagem de dinheiro). Assim que voc tiver uma conta em um exchange bitcoin, voc pode comprar e vender bitcoins rapidamente assim como voc faria com uma moeda estrangeira em uma conta de corretagem. Voc pode encontrar encontrar uma lista mais completa em bitcoin charts, charts, que Ž um site que mostra as cota•›es e outros dados de mercado obtidos de dezenas de bolsas de criptomoedas. Como um novo usu‡rio. h‡ outras quatro formas de conseguir bitcoins: ¥ Encontre um amigo amigo que tenha bitcoins e compre compre dele diretamente. Muitos usu‡rios de bitcoin come•am dessa forma. ¥ Use um servi•o de classificados como localbitcoins.com localbitcoins.com para encontrar encontrar um vendedor vendedor na sua ‡rea para comprar os bitcoins pagando pessoalmente em dinheiro. ¥ Venda Venda um produto ou servi•o por bitcoin. Se voc for um programador, programador, venda as suas habilidades habilidades de programa•‹o. ¥ Use um caixa eletr™nico eletr™nico de bitcoin na sua cidade. cidade. Voc pode pode encontrar o mais perto de voc consultando em um mapa online da CoinDesk CoinDesk.. Alice foi apresentada ao bitcoin por um amigo e portanto ela tinha uma maneira f‡cil de conseguir os seus primeiros bitcoins enquanto espera que sua conta em uma exchange de criptomoedas na Calif—rnia seja verificada e ativada.
9
Enviando e Recebendo Bitcoins Depois de criar a sua carteira bitcoin, Alice agora est‡ pronta para receber fundos. A carteira gera aleatoriamente uma chave privada (descrita em mais detalhes em [private_keys] [private_keys])) junto com o endere•o bitcoin correspondente. Nesse ponto, o endere•o bitcoin dela ainda n‹o Ž conhecido pela rede bitcoin, nem "registrado" em qualquer parte do sistema bitcoin. O endere•o bitcoin dela Ž simplesmente um nœmero que corresponde a uma chave que ela pode usar para controlar o acesso aos fundos. N‹o h‡ uma conta ou associa•‹o entre aquele endere•o e uma conta. AtŽ o momento em que este endere•o esteja referenciado como o destinat‡rio de um valor em uma transa•‹o publicada no ledger ou registro cont‡bil de bitcoin (a blockchain), ele Ž simplesmente parte da vasta quantidade de poss’veis endere•os considerados "v‡lidos" em bitcoin. A partir do momento em que esteja associado com uma transa•‹o, ele se torna parte dos endere•os conhecidos na rede e a Alice poder‡ comprovar o saldo dela no registro pœblico. A Alice encontrou-se com o amigo dela, o Joe, que a apresentou ao bitcoin, em um restaurante local para que eles possam trocar alguns d—lares e colocar bitcoins na conta dela. Ela trouxe um papel com o endere•o dela e o c—digo QR impressos conforme aparecem na carteira bitcoin. N‹o h‡ nenhuma informa•‹o que deva ser protegida, desde um ponto de vista de seguran•a, no endere•o bitcoin. Ele pode ser publicado em qualquer lugar sem nenhum risco de seguran•a ˆ conta da Alice. A Alice quer trocar somente 10 d—lares por bitcoin, para que assim ela n‹o arrisque muito dinheiro nessa nova tecnologia. Ela d‡ ao Joe uma nota de $10 e o papel impresso com seu endere•o para que o Joe possa lhe mandar o montante equivalente em bitcoin. bitcoin. Em seguida, Joe tem que descobrir a taxa de c‰mbio para que ele possa dar a quantidade certa de bitcoins ˆ Alice. H‡ centenas de aplicativos e p‡ginas web que informar a taxa de mercado atual. Eis alguns dos mais populares: Bitcoin Charts Charts
Um servi•o de listagem de dados de mercado que informa a taxa de c‰mbio do bitcoin em diversas exchanges em todo o planeta, nas diferentes moedas locais Bitcoin Average Average
Um site que permite, de forma simples, ver a mŽdia ponderada dos volumes negociados em cada moeda. ZeroBlock
Um aplicativo gr‡tis para Android e iOS que mostra o pre•o do bitcoin em diferentes bolsas de criptomoedas (procure por ZeroBlock, um aplicativo de pre•o de mercado do bitcoin para Android e iOS)) iOS Bitcoin Wisdom Wisdom
Outro servi•o de listagem de dados de mercado
10
Figure 3. ZeroBlock, ZeroBlock, um aplicativo aplicativo de pre•o de mercado do bitcoin para para Android e iOS
Usando um dos aplicativos ou sites recŽm listados, Joe determina o pre•o do bitcoin como aproximadamente 100 d—lares por bitcoin. Nesse momento, ele deveria dar a Alice 0.10 bitcoin, tambŽm chamado de 100 millibits, em troca dos 10 d—lares que ela lhe deu. Uma vez que Joe determinou um pre•o justo para a troca, ele abre um aplicativo de carteira em seu celular e seleciona "enviar" bitcoin. Por exemplo, se estiver usando a carteira da Blockchain em um telefone Android, ele veria uma tela pedindo duas informa•›es, como mostrado em A tela de envio de bitcoin da carteira m—vel Blockchain. Blockchain . ¥ O endere•o endere•o bitcoin bitcoin de destin destinoo para para a transa•‹o transa•‹o ¥ A quantidad quantidadee de bitcoins bitcoins para para enviar enviar No campo para inserir o endere•o bitcoin, h‡ um pequeno ’cone que se parece com um c—digo QR. Isso permite que Joe escaneie o c—digo de barras com a c‰mera de seu smartphone para que ele n‹o tenha que digitar o endere•o bitcoin da Alice (1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK), o que seria algo grande e dif’cil de se digitar. Joe toca no ’cone do c—digo QR e ativa a c‰mera para escanear o c—digo QR da carteira impressa que a Alice trouxe consigo. O aplicativo de carteira mobile preenche o endere•o bitcoin e Joe pode verificar que o c—digo foi escaneado corretamente ao comparar alguns d’gitos com o endere•o impresso pela Alice.
Figure 4. A tela de envio envio de bitcoin da carteira carteira m—vel Blockchain
11
Ent‹o o Joe digita o valor em bitcoins da transa•‹o, 0,10 bitcoin. Ele confere com cuidado para ter certeza de que digitou a quantia correta, pois ele est‡ a ponto de transmitir dinheiro e qualquer erro pode sair muito caro. Finalmente ele aperta Send para transmitir a transa•‹o. A carteira m—vel do Joe constr—i a transa•‹o que assigna 0,10 bitcoin ao endere•o da Alice, gerando os fundos da carteira do Joe e assinando a transa•‹o com as chaves privadas dele. Isso informa a rede bitcoin que o Joe autorizou uma transferncia de valor de um de seus endere•os para o novo endere•o da Alice. Ë medida que a transa•‹o se transmite conforme o protocolo peer-to-peer, ela rapidamente se propaga pela rede bitcoin. Em menos de 1 segundo, a maioria dos n—s com melhor conex‹o na rede recebem a transa•‹o e vem o endere•o da Alice pela primeira vez. Se a Alice tiver um smartphone ou um laptop com ela, tambŽm ser‡ capaz de ver a transa•‹o. O registro cont‡bil do bitcoin Ñ um arquivo que n‹o p‡ra de crescer e que guarda cada uma das transa•›es em bitcoin que j‡ ocorreram desde o in’cio Ñ Ž pœblico, o que significa que tudo que ela tem de fazer Ž olhar seu pr—prio endere•o e ver se quaisquer fundos foram mandados para ele. Ela pode fazer isso facilmente no site blockchain.info, digitando o endere•o dela no campo de busca. O website lhe vai mostrar uma page page listando listando todas as transa•›es de e para aquele endere•o. Se a Alice estiver olhando essa p‡gina, vai ver uma atualiza•‹o que mostra uma nova transa•‹o transferindo transferindo 0,10 bitcoin para o saldo dela logo depois do Joe apertar Send.
Confirma•›es Inicialmente, o endere•o da Alice vai mostrar a transa•‹o do Joe como "Transa•‹o n‹o Confirmada." Isto significa que a transa•‹o j‡ se propagou pela rede, mas ainda n‹o foi inclu’da no registro cont‡bil de transa•›es do bitcoin, conhecido como a blockchain (cadeia de blocos). Para ser inclu’da, a transa•‹o deve ser "escolhida" por um minerador e inclu’da em um bloco de transa•›es. Quando um novo bloco Ž criado, em aproximadamente 10 minutos, as transa•›es dentro do bloco passam a ser aceitas como "confirmadas" pela rede e ent‹o podem ser gastas. A transa•‹o Ž vista instantaneamente por todos, mas s— se torna "confiada" por todos quando est‡ inclu’da em um novo bloco minerado. A Alice agora Ž a orgulhosa dona de 0,10 bitcoin que ela pode gastar. No pr—ximo cap’tulo, observaremos sua primeira compra com bitcoin e examinaremos em maiores detalhes as tecnologias de transa•‹o e propaga•‹o envolvidas.range envolvidas.range="endofrange ="endofrange", ", startref="ix_ch01-asciidoc1")
12
Como Funciona o Bitcoin Transa•›es, Blocos, Minera•‹o e a Blockchain O sistema bitcoin, diferente dos tradicionais sistemas banc‡rios e de pagamentos, Ž baseado em uma confian•a descentralizada. Ao invŽs de uma autoridade central confi‡vel, no Bitcoin a confian•a Ž alcan•ada como uma propriedade emergente das intera•›es dos diferentes participantes no sistema bitcoin. Nesse cap’tulo, iremos examinar o bitcoin atravŽs do rastreamento de uma transa•‹o atravŽs do sistema bitcoin e observar como ela se torna "confi‡vel" e aceita pelo mecanismo de consenso distribu’do da rede bitcoin para ser finalmente gravada na blockchain - o livro-raz‹o distribu’do que contŽm todas as transa•›es. Cada exemplo Ž baseado em uma transa•‹o real ocorrida na rede bitcoin, simulando as intera•›es entre os usu‡rios (Joe, Alice e Bob) ao enviarem fundos de uma carteira para outra. Iremos usar um site blockchain explorer para visualizar cada etapa. Um site block explorer (ou explorador de blockchain) Ž um aplicativo web que opera como um motor de busca de opera•›es de bitcoin, que permite ao usu‡rio verificar transa•›es, endere•os e blocos, alŽm de ver as rela•›es e fluxos entre eles. Alguns dos exploradores de blockchain mais populares: ¥ Blockchain info ¥ Bitcoin Block Explorer ¥ insight ¥ blockr Block Reader Cada um destes sites possui um sistema de busca que pode verificar um endere•o, hash de transa•‹o ou nœmero do bloco e encontrar o dado equivalente na rede bitcoin e na blockchain. Com cada exemplo, iremos fornecer uma URL que o levar‡ diretamente para a entrada relevante, de forma que voc possa estudar o assunto detalhadamente.
Vis‹o Geral do Bitcoin No diagrama de vis‹o geral mostrado em Vis‹o Geral do Bitcoin, Bitcoin , vemos que o sistema bitcoin consiste de usu‡rios com carteiras contendo chaves, transa•›es que s‹o propagadas pela rede e mineradores que produzem (atravŽs de computa•‹o competitiva) o consenso da blockchain - que Ž o registro oficial de todas as transa•›es. Nesse cap’tulo, rastrearemos uma transa•‹o enquanto ela viaja atravŽs da rede e examinaremos as intera•›es entre cada parte do sistema bitcoin. Os cap’tulos subsequentes investigar‹o a tecnologia por tr‡s das carteiras, da minera•‹o e do sistema de transa•›es.
1
Figure 1. Vis‹o Geral do Bitcoin Bitcoin
Comprando uma X’cara de CafŽ Alice, apresentada no cap’tulo anterior, Ž uma nova usu‡ria que acabou de obter seu primeiro bitcoin. Em [getting_first_bitcoin] [getting_first_bitcoin],, Alice encontrou com seu amigo, Joe, para trocar algum dinheiro por bitcoin. A transa•‹o criada por Joe alocou 0,10 BTC na carteira de Alice. Agora, ela ir‡ fazer sua primeira compra, um transa•‹o de varejo, comprando uma x’cara de cafŽ na cafeteria do Bob, em Palo Alto, Calif—rnia. A cafeteria do Bob recŽm come•ou a aceitar pagamentos em bitcoin, ao adicionar a op•‹o de pagamentos por bitcoin no sistema do seu ponto de vendas. Os pre•os na cafeteria s‹o listados na moeda local (d—lares americanos), mas no caixa, os clientes agora contam com a op•‹o de pagar tanto em d—lares quanto em bitcoin. Alice faz seu pedido - uma x’cara de cafŽ - e Bob entra a transa•‹o em seu sistema de vendas. O sistema do ponto de vendas far‡ a convers‹o do pre•o total em d—lares para bitcoins, tendo como referncia a cota•‹o do momento, e apresenta o valor final nas duas moedas, bem como um c—digo QR contendo uma requisi•‹o de pagamento para essa transa•‹o (ver C—digo QR de solicita•‹o de pagamento (Dica: Tente escanear esse c—digo!)): c—digo!) ): Total: $1.50 USD 0,015 BTC
2
Figure 2. C—digo QR de solicita•‹o de pagamento (Dica: Tente Tente escanear esse c—digo!) O c—digo QR de solicita•‹o de pagamento codifica a seguinte URL, definida em BIP0021:
bitcoin:1GdK9UzpHBzqzX2A9JFP3Di4weBwqg bitcoin:1GdK9UzpHBzqzX2A9 JFP3Di4weBwqgmoQA? moQA? amount=0.015& label=Bob%27s%20Cafe& message=Compra%20no%20Bob message=Comp ra%20no%20Bob%27s%20Cafe %27s%20Cafe Componentes da URL Um endere •o bitcoin: "1GdK9UzpHBz "1GdK9UzpHBzqzX2A9JFP3Di4 qzX2A9JFP3Di4weBwqgmoQA" weBwqgmoQA" Valor do pagamento (amount): "0.015" Um r—tulo para o endere •o do destinat ‡rio (label): "Bob's Cafe" Uma descri •‹o para o pagamento (message): "Compra no Bob's Cafe"
TIP
Ao contr‡rio de um c—digo QR que simplesmente contŽm um endere•o de bitcoin como destinat‡rio, um QR code com uma requisi•‹o de pagamento contŽm uma URL codificada a qual contŽm mœltiplos par‰metros: um endere•o de pagamento, um valor de pagamento e uma descri•‹o genŽrica como "BobÕs Cafe". Isso permite que um aplicativo de carteira bitcoin preencha as informa•›es usadas para enviar o pagamento enquanto mostra uma descri•‹o intuitiva para o usu‡rio. Voc pode escanear o c—digo QR acima com um aplicativo de carteira bitcoin para ver o que a Alice veria.
Bob diz: "A conta deu 1,50 d—lares, ou 15 millibits." A Alice ent‹o usa o smartphone dela para escanear o c—digo de barras mostrado na tela do Bob. O smartphone dela mostra um pagamento de 0,0150 BTC para o BobÕs Cafe e ao clicar em Enviar ela autoriza o pagamento. Dentro de alguns segundos (aproximadamente o mesmo tempo que leva uma autoriza•‹o de cart‹o de crŽdito), o Bob visualiza a transa•‹o em seu caixa, completando a transa•‹o. Nas pr—ximas se•›es, examinaremos essa transa•‹o em maiores detalhes, veremos como a carteira da Alice a construiu, como ela foi propagada atravŽs da rede, como ela foi verificada e, finalmente, como o Bob pode gastar a quantia recebida em novas transa•›es t ransa•›es futuras.
3
NOTE
A rede bitcoin pode fazer transa•›es em valores fracion‡rios, por exemplo, desde millibitcoins (1/1.000 de um bitcoin) atŽ um satoshi (1/100.000.000 de um bitcoin). Ao longo deste livro n—s iremos usar o termo bitcoin para se referir a qualquer quantidade na moeda bitcoin, desde a menor unidade poss’vel (1 satoshi) atŽ o nœmero m‡ximo (21.000.000) de bitcoins que podem ser minerados.
Transa•›es Bitcoin Em termos simples, uma transa•‹o informa para a rede que o dono de uma quantidade de bitcoins autorizou a transferncia de alguns destes bitcoins para outro dono. O novo dono agora pode gastar esses bitcoins ao criar uma nova transa•‹o que autoriza a transferncia para um outro dono, e assim por diante, em uma cadeia de posse de bitcoins. As transa•›es s‹o como linhas em um "registro cont‡bil" (ledger) de dupla entrada. Em termos simples, cada transa•‹o contŽm um ou mais "inputs" (entradas), que s‹o dŽbitos em uma conta bitcoin. No outro lado da transa•‹o, existem um ou mais "outputs" (sa’das) que s‹o crŽditos adicionados em uma conta bitcoin. A soma dos inputs e outputs (dŽbitos e crŽditos) n‹o necessariamente resultam na mesma quantia. Ao invŽs disso, os outputs s‹o um pouco maiores do que os inputs, e essa diferen•a se d‡ devido ˆ "taxa de transa•‹o", que Ž um pequeno pagamento coletado pelo minerador que inclui a transa•‹o no registro cont‡bil do bitcoin (a blockchain). Uma transa•‹o bitcoin Ž mostrada como uma entrada no registro cont‡bil em Transa•‹o como um registro cont‡bil de entrada-dupla. entrada-dupla. A transa•‹o tambŽm contŽm uma prova de posse para cada quantia de bitcoins (inputs) que Ž transferida, na forma de uma assinatura digital assinada pelo dono, que pode ser validada por qualquer pessoa, de maneira independente. Usando a terminologia do bitcoin, "gastar" Ž assinar uma transa•‹o que transfere um valor (de uma transa•‹o prŽvia) para um novo dono, o qual Ž identificado atravŽs de um endere•o bitcoin. Transa•›es movimentam valores a partir de inputs de transa•‹o para outputs de transa•‹o . Um input Ž o lugar de onde vem o valor da moeda, geralmente um output de
TIP
4
uma transa•‹o prŽvia. Um output de transa•‹o designa um novo dono para o valor ao associ‡-lo com um script de travamento. Esse script de travamento exige uma assinatura ou outra forma de valida•‹o ( script de destravamento) para a retirada dos fundos em transa•›es futuras. Outputs de uma transa•‹o podem ser usados como inputs em uma nova transa•‹o, dessa maneira criando uma cadeia de posses ˆ medida que o valor Ž movido de um endere•o para outro (ver Uma cadeia de transa•›es, onde o output de uma transa•‹o Ž o input da pr—xima transa•‹o). transa•‹o ).
Figure 3. Transa•‹o Transa•‹o como um registro cont‡bil cont‡bil de entrada-dupla entrada-dupla
5
Figure 4. Uma cadeia cadeia de transa•›es, transa•›es, onde o output de uma uma transa•‹o transa•‹o Ž o input da pr—xima pr—xima transa•‹o transa•‹o
O pagamento da Alice para o BobÕs Cafe usa uma transa•‹o prŽvia como seu input. No cap’tulo anterior, a Alice recebeu bitcoins do amigo dela em troca de dinheiro. Aquela transa•‹o continha um nœmero de bitcoins "trancados" (alienados) com a chave da Alice. Sua nova transa•‹o para o BobÕs Cafe utiliza a transa•‹o prŽvia como um input e cria novos outputs para pagar pela x’cara de cafŽ e receber o troco. As transa•›es formam uma cadeia, onde os inputs da œltima transa•‹o correspondem aos outputs das transa•›es anteriores. A chave da Alice fornece a assinatura que desbloqueia estes outputs de transa•›es prŽvios, desta maneira provando ˆ rede bitcoin que ela Ž a dona dos fundos. Ela vincula seu pagamento pelo cafŽ ao endere•o do Bob, desta maneira m aneira "alienando" "alienando" este output com o requisito de que Bob produza uma assinatura, liberando essa quantidade de bitcoins para ser gasta. Isso representa a transferncia de valor entre Alice e Bob. Essa cadeia de transa•›es, do Joe para a Alice, e dela para o Bob, Ž ilustrada em Uma cadeia de transa•›es, onde o output de uma transa•‹o Ž o input da pr—xima transa•‹o.. transa•‹o
Formas Comuns de Transa•‹o A forma mais comum de transa•‹o Ž um pagamento simples de um endere•o para outro, que frequentemente inclui algum "troco" que Ž devolvido para o dono original. Esse tipo de transa•‹o possui um input e dois outputs, e Ž mostrada em A forma mais comum de transa•‹o transa•‹o....
6
Figure 5. A forma forma mais comum de de transa•‹o
Outra forma comum de transa•‹o Ž uma que agrega mœltiplos inputs em um œnico output (ver Transa•‹o agregadora de fundos ). Isso representa o equivalente no mundo real a uma troca de uma pilha de moedas e notas por uma nota de valor maior. As transa•›es deste tipo s‹o ˆs vezes geradas pelos aplicativos de carteira para limpar v‡rios valores pequenos que foram recebidos como troco pelos pagamentos efetuados.
7
Figure 6. Transa•‹o Transa•‹o agregadora agregadora de fundos
Finalmente, outra forma de transa•‹o frequentemente vista no registro cont‡bil do bitcoin Ž uma transa•‹o que distribui um input para mœltiplos outputs, que representam mœltiplos destinat‡rios (ver Transa•‹o de distribui•‹o de fundos ). Este tipo de transa•‹o ˆs vezes Ž usada por entidades comerciais para distribuir fundos, como, por exemplo, ao processar folhas de pagamento para mœltiplos colaboradores.
Figure 7. Transa•‹o Transa•‹o de distribui•‹o distribui•‹o de fundos
8
Construindo uma Transa•‹o O aplicativo de carteira contŽm toda a l—gica para selecionar os inputs e outputs apropriados para construir uma transa•‹o com os dados especificados pela Alice. Ela s— precisa fornecer os dados de destino e uma quantia: o seu aplicativo de carteira faz todo o resto, sem que ela sequer veja os detalhes. Outro aspecto importante, Ž que o aplicativo de carteira tambŽm pode construir transa•›es mesmo estando completamente offline. Da mesma maneira que voc pode preencher um cheque em casa para depois deposit‡-lo em um envelope no banco, uma conex‹o com a rede bitcoin n‹o Ž necess‡ria para que uma transa•‹o seja constru’da e assinada. A transa•‹o s— precisa ser enviada para a rede quando a pessoa quiser efetu‡-la.
Recebendo os Inputs Certos O aplicativo de carteira da Alice ter‡ primeiro que achar os inputs que podem pagar pela quantia que ela quer enviar para o Bob. A maioria dos aplicativos de carteira mantŽm um pequeno banco de dados de "outputs de transa•›es n‹o gastos" que s‹o trancados (alienados) com as pr—prias chaves da carteira. Logo, a carteira de Alice iria conter uma c—pia do output da transa•‹o do Joe, que foi criada na troca pelo dinheiro (ver [getting_first_bitcoin] [getting_first_bitcoin]). ). Um aplicativo de carteira de bitcoin que roda como um cliente de ’ndice completo na verdade contŽm uma c—pia de cada output n‹o gasto de todas as transa•›es presentes na blockchain. Isso permite que a carteira construa inputs de transa•‹o, alŽm de verificar rapidamente se as transa•›es que chegam tem inputs corretos. No entanto, como um cliente de ’ndice completo ocupa muito espa•o de armazenamento em disco, a maioria das carteiras roda clientes "leves" que mantŽm somente o registro dos outputs n‹o gastos do usu‡rio. Se a wallet n‹o mantiver uma c—pia dos outputs de transa•‹o n‹o-gastos, ela pode fazer uma requisi•‹o ˆ rede bitcoin para solicitar essa informa•‹o, usando as APIs (ou Interfaces de Programa•‹o de Aplica•›es) que os diferentes fornecedores colocam ˆ disposi•‹o, ou fazendo uma requisi•‹o a um n— de ’ndice completo usando um API de bitcoin JSON RPC. Consultando todos os outputs n‹o gastos do endere•o de bitcoin da Alice Alice mostra que todos os outputs n‹o-gastos para o endere•o de bitcoin de Alice mostram uma requisi•‹o API RESTful, constru’do como um comando HTTP GET para uma URL espec’fica. Essa URL ir‡ retornar todos os outputs de transa•‹o n‹o gastos para um endere•o, fornecendo para qualquer aplicativo a informa•‹o necess‡ria para construir inputs de transa•‹o de t al forma que os bitcoins sejam gastos. N—s usamos um simples cliente HTTP de linha de comando cURL para solicitarmos a resposta. Example 1. Consultando Consultando todos todos os outputs n‹o gastos gastos do endere•o de bitcoin bitcoin da Alice
$ curl https://block https://blockchain.info/u chain.info/unspent?active nspent?active=1Cdid9KFAaat =1Cdid9KFAaatwczBwBttQcwXY wczBwBttQcwXYCpvK8h7FK CpvK8h7FK
9
Example 2. Resposta Resposta ˆ consulta
{
"unspent_outputs":[ {
"tx_hash":"186f9f998a5...2836dd734d2804fe65fa35779", "tx_index":104810202, "tx_output_n": "tx_output_ n": 0, "script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac", "value": 10000000, "value_hex": "00989680", "confirmations":0
} ] }
A resposta no Resposta ˆ consulta mostra consulta mostra um output n‹o-gasto (um que ainda n‹o foi resgatado) sob a posse do endere•o de Alice 1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK. A resposta inclui uma referncia ˆ transa•‹o na qual esse valor n‹o-gasto est‡ contido (o pagamento do Joe) e seu valor em satoshis, 10 milh›es, equivalente a 0,10 bitcoin. Com essa informa•‹o, o aplicativo carteira de Alice pode construir uma transa•‹o para transferir o valor para o endere•o do novo dono. TIP
Veja a transa•‹o de Joe para Alice. Alice .
Como voc pode ver, a carteira de Alice contŽm bitcoins suficientes em um output n‹o-gasto isolado para pagar pela x’cara de cafŽ. Caso n‹o contivesse, o aplicativo carteira de Alice teria que "vasculhar" uma pilha de pequenos outputs n‹o-gastos, como se estivesse pegando as moedas em uma bolsa, atŽ encontrar o suficiente para poder pagar o cafŽ. Em ambos os casos, pode haver uma necessidade de receber algum troco de volta, que Ž o assunto que iremos ver na pr—xima se•‹o, quando o aplicativo carteira cria os outputs da transa•‹o (pagamentos).
Criando os Outputs Um output de transa•‹o Ž criado na forma de um script que cria uma aliena•‹o no valor a ser transferido, de maneira maneira que o valor s— pode ser regastado se uma solu•‹o for apresentada ao script. De maneira simplificada, o output da transa•‹o de Alice ir‡ conter um script que diz algo como "Esse output Ž pag‡vel para aquela pessoa que conseguir apresentar uma assinatura para a chave correspondente ao endere•o pœblico de Bob". Como somente o Bob possui a carteira com as chaves correspondentes ˆquele endere•o, somente a carteira de bob pode apresentar a assinatura para resgatar esse output. A Alice ao fazer uma exigncia de assinatura do Bob, ela est‡ fazendo uma "aliena•‹o" ao valor de output. 10
Essa transa•‹o tambŽm incluir‡ um segundo output, porque os fundos de Alice est‹o na forma de um output de 0,10 BTC, que Ž dinheiro demais para a transa•‹o de 0,015 BTC pela x’cara de cafŽ. A Alice precisar‡ de 0,085 BTC de troco. O pagamento do troco da Alice Ž criado pela carteira de Alice na mesma transa•‹o que o pagamento do Bob. Essencialmente, a carteira de Alice divide seus fundos em dois pagamentos: um para o Bob, e outro de volta para si mesma. Ela pode ent‹o usar o output do troco em uma transa•‹o no futuro, gastando-o mais tarde. Finalmente, para que a transa•‹o seja processada pela rede em tempo h‡bil, o aplicativo de carteira da Alice ir‡ adicionar uma pequena taxa. Isso n‹o est‡ expl’cito na transa•‹o: isso est‡ impl’cito na diferen•a entre os inputs e os outputs. Se ao invŽs de receber 0,085 de troco, Alice cria somente 0,0845 como um segundo output, haver‡ 0,0005 (metade de um milibitcoin) restantes. O input de 0,10 BTC n‹o Ž totalmente gasto com os dois outputs, porque ele ir‡ se somar atŽ menos do que 0,10. A diferen•a resultante Ž a taxa de transa•‹o que Ž coletada pelo minerador como um pagamento por ter inclu’do a transa•‹o em um bloco e adicionar esse bloco no ledger da blockchain. A transa•‹o resultante pode ser vista usando um aplicativo web explorador de blockchain, como visto em Transa•‹o de Alice para o BobÕs Cafe Cafe..
Figure 8. Transa•‹o Transa•‹o de Alice para para o BobÕs Cafe TIP
Veja a transa•‹o de Alice para o BobÕs Cafe Cafe..
Adicionando uma Transa•‹o ao Registro (Ledger) A transa•‹o criada pelo aplicativo de carteira da Alice tem 258 bytes de comprimento e contŽm todas as informa•›es necess‡rias para confirmar a sua posse dos fundos e para designar novos donos. Agora,
11
a transa•‹o deve ser transmitida para rede bitcoin, onde ela se tornar‡ parte do ledger distribu’do (da blockchain). Na pr—xima se•‹o, iremos ver como a transa•‹o torna-se parte de um novo bloco e como o bloco Ž "minerado". Por fim, iremos ver como o novo bloco, ap—s ser adicionado ˆ blockchain, torna-se cada vez mais confi‡vel conforme novos blocos s‹o adicionados posteriormente ˆ ele. Transmitindo a transa•‹o
Como a transa•‹o contŽm toda a informa•‹o necess‡ria para que seja processada, n‹o importa como ou onde ela Ž transmitida para a rede bitcoin. A rede bitcoin Ž uma rede ponto-a-ponto (P2P), com cada cliente bitcoin participando ao se conectar a mœltiplos outros clientes bitcoins. A proposta da rede bitcoin Ž propagar as transa•›es e os blocos para todos os participantes. Como ela se propaga
A carteira da Alice pode enviar a nova transa•‹o para qualquer um dos outros clientes bitcoins se ela estiver conectada atravŽs de uma conex‹o de Internet: por cabo, WiFi ou m—vel. A sua carteira n‹o tem que obrigatoriamente estar conectada diretamente ˆ carteira do Bob ou usar a conex‹o de internet oferecida pela cafeteria, embora essas op•›es tambŽm sejam poss’veis. Qualquer n— (outro cliente) na rede bitcoin que receber uma transa•‹o v‡lida que n‹o tenha sido vista anteriormente, ir‡ propag‡-la imediatamente para outros n—s com os quais est‡ ligado. Logo, a transa•‹o rapidamente Ž propagada atravŽs da rede ponto-a-ponto (P2P), atingindo uma grande percentagem dos n—s dentro de poucos segundos. A vis‹o do Bob
Se a wallet do Bob estiver diretamente conectada ˆ wallet da Alice, o aplicativo pode ser o primeiro n— a receber a transa•‹o. Entretanto, mesmo que a carteira de Alice envie a transa•‹o atravŽs de outros n—s, a transa•‹o chegar‡ ˆ carteira do Bob dentro de pouco segundos. A carteira de Bob ir‡ identificar imediatamente a transa•‹o de Alice como um pagamento porque ela contŽm outputs que s‹o resgat‡veis pelas chaves do Bob. A carteira de Bob tambŽm pode verificar independentemente que a transa•‹o Ž bem formada, utiliza inputs previamente n‹o-gastos e contŽm taxas de transa•‹o suficientes para ser inclu’da no pr—ximo bloco. Neste momento Bob pode esperar, com um alto grau de probabilidade,, que a transa•‹o ser‡ em breve inclu’da em um bloco e ser‡ confirmada. probabilidade
TIP
12
Uma ideia erroneamente difundida Ž a de que as transa•›es bitcoin, para serem "confirmadas", exigem uma espera de 10 minutos por um novo bloco, ou de atŽ 60 minutos por seis confirma•›es. Embora essas confirma•›es sejam uma garantia de que a transa•‹o foi aceita por toda a rede, a espera por elas Ž desnecess‡ria para itens de pequeno valor, como uma x’cara de cafŽ. Ao aceitar uma transa•‹o de pequeno valor como comprovadamente v‡lida, o comerciante estar‡ correndo um risco menor do que quando recebe um pagamento de cart‹o de crŽdito feito sem assinatura ou carteira de identidade, algo que Ž rotineiramente feito hoje em dia.
Minera•‹o de Bitcoin A transa•‹o foi propagada na rede bitcoin. Ela s— vai tornar-se parte de ledger compartilhado (a blockchain ) quando for verificada e inclu’da em um bloco, atravŽs de um processo chamado [ch8] para para uma explica•‹o mais detalhada. minera•‹o. Veja [ch8] O sistema de confian•a do bitcoin Ž baseado em computa•‹o. As transa•›es s‹o agrupadas em blocos, o que requer uma enorme quantidade de processamento para prov‡-las, mas apenas uma pequena quantidade de processamento para verific‡-las como previamente provadas. O processo de minera•‹o do bitcoin possui dois prop—sitos: ¥ A minera•‹o minera•‹o cria novos bitcoins em cada cada bloco, quase como um banco central central imprimindo imprimindo novas moedas e notas. A quantidade de bitcoin criada por bloco Ž fixa e diminui com o tempo. ¥ A minera•‹o minera•‹o cria confian•a ao garantir que as transa•›es transa•›es sejam confirmadas confirmadas somente se poder poder de processamento suficiente for dedicado ao bloco que as contŽm. Mais blocos requerem mais processamento, o que significa maior confian•a. Uma boa maneira de descrever a minera•‹o Ž como um jogo de sudoku, gigantesco e competitivo, que reinicia cada vez que alguŽm encontra uma solu•‹o e cuja dificuldade se ajusta automaticamente, de maneira que leve cerca de 10 minutos para que uma solu•‹o seja encontrada. Imagine um sudoku gigantesco, com milhares de colunas e linhas de tamanho. Se eu mostrar para voc um sudoku completo, voc pode verificar rapidamente que ele est‡ corretamente preenchido. No entando, se o sudoku tiver apenas alguns quadrados preenchidos e o resto estiver vazio, levar‡ muito trabalho para resolv-lo! A dificuldade do sudoku pode ser ajustada ao mudar o seu tamanho (mais ou menos linhas ou colunas), mas o sudoku ainda pode ser verificado de maneira r‡pida, mesmo que ele seja muito grande. O "quebra-cabe•as" usado no bitcoin Ž baseado em um hash criptogr‡fico, que exibe caracter’sticas semelhantes: ele Ž assimetricamente dif’cil de resolver, mas f‡cil de verificar, e sua dificuldade pode ser ajustada. Em [user-stories] [user-stories],, n—s apresentamos o Jing, um estudante de engenharia da computa•‹o de Shanghai. Ele est‡ participando da rede bitcoin como um minerador. Ë cada 10 minutos em mŽdia, Jing se une a milhares de outros mineradores para uma corrida global para achar uma solu•‹o para um bloco de transa•›es. Encontrar a tal solu•‹o, tambŽm chamada de prova de trabalho, requer quadrilh›es de opera•›es de hashing por segundo ao longo de toda a rede bitcoin. O algoritmo para a prova de trabalho envolve fazer hashing com o cabe•alho do bloco e um nœmero aleat—rio com um algoritmo criptogr‡fico SHA256 atŽ que a solu•‹o correspondente a um determinado padr‹o surja. O primeiro minerador a encontrar uma solu•‹o ganha a rodada da competi•‹o e publica o bloco na blockchain. Jing come•ou a minerar em 2010 usando um computador destktop muito r‡pido para achar provas de trabalho adequadas para novos blocos. Conforme mais mineradores come•aram a se juntar ˆ rede bitcoin, a dificuldade do problema cresceu rapidamente. Logo em seguida, Jing e outros mineradores fizeram upgrade para um hardware mais especializado, como placas com unidades de processamento gr‡fico (GPUs) dedicadas de alta performance, como as placas de v’deo utilizadas para jogos de desktop ou videogames. Nesse momento, a dificuldade est‡ t‹o alta que s— Ž rent‡vel minerar com circuitos integrados espec’ficos para a aplica•‹o (ASIC), que Ž essencialmente centenas de algoritmos de 13
minera•‹o impressos em hardware, rodando em paralelo em um œnico chip de sil’cio. Jing tambŽm se uniu ao "mining pool", que Ž como uma mina coletiva que permite que v‡rios participantes compartilhem seus esfor•os e recompensas. Jing agora roda duas m‡quinas ASIC ligadas a USB para minerar bitcoins 24 horas por dia. Ele paga seus custos de eletricidade com a venda dos seus bitcoins minerados, obtendo algum lucro dos seus bitcoins. Seu computador roda uma c—pia do bitcoind, um cliente bitcoin de referncia, como um backend para seu software de minera•‹o especializado. especializado.
Minerando Transa•›es em Blocos Uma transa•‹o transmitida pela rede n‹o Ž verificada atŽ que ela se torna parte do ledger distribu’do global, a blockchain. A cada 10 minutos em mŽdia, os mineradores geram um novo bloco que contŽm todas as transa•›es que ocorreram desde o œltimo bloco. As novas transa•›es est‹o constantemente sendo adicionadas ˆ rede pelas carteiras e outros aplicativos dos usu‡rios. Quando elas s‹o vistas pelos n—s da rede bitcoin, elas s‹o adicionadas a um pool tempor‡rio de transa•›es n‹o-verificadas que Ž mantida por cada n—. Ao construir um novo bloco, os mineradores adicionam as transa•›es n‹overificadas deste pool para um novo bloco, e tentam resolver um problema (prova de trabalho) muito dif’cil (tambŽm conhecido como prova-de-trabalho) para provar a validade deste novo bloco. O processo de minera•‹o Ž explicado em maiores detalhes em [mining] [mining].. As transa•›es s‹o adicionadas ao novo bloco, recebendo prioridade as transa•›es que possuem as maiores taxas de transa•‹o, alŽm de alguns outros critŽrios. Cada minerador inicia o processo de minera•‹o de um bloco de transa•‹o t‹o logo ele recebe o bloco anterior da rede, sabendo que ele perdeu a rodada anterior da competi•‹o. Ele imediatamente cria um novo bloco, preenche-o com transa•›es e impress›es digitais do bloco anterior, e come•a a calcular a prova-de-trabalho para o novo bloco. Cada minerador inclui uma transa•‹o especial em seu novo bloco, que paga uma recompensa de novos bitcoins recŽm criados (atualmente 25 BTC por bloco), que ser‹o enviados para o endere•o bitcoin do minerador. Se ele encontra uma solu•‹o que torna o bloco v‡lido, ele "ganha" essa recompensa porque seu bloco Ž adicionado ˆ blockchain e a transa•‹o especial de recompensa que ele incluiu se torna gast‡vel. Jing, que participa de um pool de minera•‹o, programou seu software para criar novos blocos que designam uma recompensa para um endere•o de pool. Desta maneira, uma parte da recompensa recebida Ž distribu’da entre Jing e outros mineradores, de acordo com a quantidade de trabalho que cada um contribuiu na œltima rodada. A transa•‹o de Alice foi inclu’da na rede e adicionada no pool de transa•›es n‹o-verificadas. Como ela tinha taxas de transa•‹o suficientes, ela foi inclu’da em novo bloco gerado pela pool de minera•‹o do Jing. Aproximadamente cinco minutos ap—s a transa•‹o ter sido inicialmente transmitida pela carteira de Alice, o equipamento de minera•‹o ASIC do Jing encontrou uma solu•‹o para o bloco e publicou-o como bloco #277316, contendo outras 419 transa•›es. O equipamento de minera•‹o ASIC do Jing publicou o novo bloco na rede bitcoin, onde outros mineradores o validaram e iniciaram uma nova rodada da corrida para gerar o pr—ximo bloco. Voc pode ver o bloco que inclui a transa•‹o de Alice. Alice. Alguns minutos mais tarde, um novo bloco, #277317, Ž minerado por outro minerador. Como esse novo bloco Ž baseado no bloco anterior (#277316) que continha a transa•‹o de Alice, ele adicionou ainda
14
mais processamento computacional neste bloco anterior, desta maneira fortalecendo a confian•a nas transa•›es contidas no bloco. Logo, ap—s esse processamento adicional do bloco contendo a transa•‹o de Alice, considera-se que a transa•‹o da Alice contida no bloco recebeu uma "confirma•‹o". Cada que Ž bloco minerado ap—s um bloco anterior contendo transa•›es, gera uma confirma•‹o adicional para cada uma destas transa•›es. Conforme os blocos se empilham um sobre os outros, torna-se exponencialmente mais dif’cil de se reverter a transa•‹o, dessa maneira tornando-a cada vez mais confi‡vel pela rede. No diagrama em Transa•‹o de Alice inclu’da no bloco #277316 #277316 podemos ver o bloco #277316, que contŽm a transa•‹o de Alice. Abaixo dele h‡ 277316 blocos (incluindo o bloco #0), ligados uns aos outros, formando uma corrente de blocos (blockchain) que se estende atŽ o seu bloco inicial (#0), tambŽm conhecido como bloco gnese. Ao longo do tempo, a "altura" da pilha de blocos aumenta, aumentando a dificuldade de processamento computacional necess‡rio para cada bloco e para toda a corrente. Os bloco minerados ap—s o bloco que contŽm a transa•‹o de Alice s‹o considerados uma garantia adicional, j‡ que eles receberam mais processamento computacional em uma corrente cada vez maior. Por conven•‹o, considera-se irrevog‡vel o bloco que j‡ recebeu seis ou mais confirma•›es, porque seria necess‡ria uma imensa capacidade de poder computacional para invalidar ou recalcular seis blocos. N—s iremos examinar em mais detalhes o processo de minera•‹o e a maneira como ele constr—i a confian•a no [ch8] [ch8]..
15
Figure 9. Transa•‹o Transa•‹o de Alice inclu’da inclu’da no bloco #277316 #277316
Gastando a transa•‹o Agora que a transa•‹o da Alice foi incorporada ˆ blockchain como parte de um bloco, ela faz parte do registro cont‡bil distribu’do do bitcoin e est‡ vis’vel para todos as aplica•›es bitcoin. Cada cliente bitcoin pode verificar independentemente que a transa•‹o Ž v‡lida e que seus fundos podem ser
16
gastos. Clientes de ’ndice completo (full-index) podem rastrear a origem dos fundos desde o in’cio, ou seja, o momento em que os bitcoins foram gerados em um bloco, e, progredindo de transa•‹o a transa•‹o, atŽ chegarem ao endere•o do Bob. Clientes leves (lightweight) podem fazer uma verifica•‹o simplificada de pagamento (ver [spv_nodes] [spv_nodes])) ao confirmar que a transa•‹o est‡ presente na blockchain e que v‡rios blocos foram minerados ap—s ela, garantindo que ela foi aceita pela rede como v‡lida. O Bob agora pode gastar o output desta e de outras transa•›es, ao criar suas pr—prias transa•›es que usam esses outputs como inputs e os designam para um novo dono. Por exemplo, Bob pode pagar um fornecedor ao transferir, para este novo dono, o valor do pagamento da x’cara de cafŽ da Alice. Mais provavelmente, o software de bitcoin do Bob ir‡ agregar v‡rios pequenos pagamentos em um pagamento maior, talvez concentrando em uma œnica transa•‹o todo o lucro em bitcoins obtidos na loja em um dia. Isso moveria todos os pagamentos para um endere•o œnico, usado como uma conta de "checking" geral da loja. Para ver um diagrama de uma transa•‹o agregadora, leia Transa•‹o agregadora de fundos. fundos . Ë medida que o Bob gasta os pagamentos que recebeu de Alice e outros clientes, ele estende a cadeia de transa•›es, que por sua vez s‹o adicionadas ao ledger global do blockchain para que todos possam ver e confiar. Vamos assumir que o Bob paga seu webdesigner Gopesh em Bangalore para desenvolver um novo site. Agora a cadeia de transa•›es ir‡ ficar parecida como na figura Transa•‹o da Alice fazendo parte de uma cadeia de transa•‹o do Joe para o Gopesh .
Figure 10. Transa•‹o Transa•‹o da Alice fazendo fazendo parte de uma cadeia cadeia de transa•‹o do Joe para o Gopesh Gopesh
17
O Cliente Bitcoin Bitcoin Core: A Implementa•‹o de Referncia Em http://www.bitcoin.org http://www.bitcoin.org,, voc pode fazer o download do Bitcoin Core, o cliente de referncia do bitcoin, tambŽm conhecido como o "cliente Satoshi". O cliente de referncia implementa todos os aspectos do sistema bitcoin, incluindo carteiras, mecanismo de verifica•‹o de transa•›es com uma c—pia completa de toda a blockchain (o ledger de transa•›es), e um nodo completo da rede ponto-aponto do bitcoin. Em BitcoinÕs Choose Your Wallet page, page , selecione Bitcoin Core para baixar o cliente de referncia. Dependendo do seu sistema operacional, voc ir‡ fazer o download de um instalador execut‡vel. Para o Windows, ele um arquivo ZIP ou um execut‡vel .exe. Para Mac OS, ele Ž um arquivo de imagem de disco .dmg. As vers›es do Linux incluem um pacote PPA para Ubuntu ou um arquivo tar.gz. A p‡gina bitcoin.org que lista os clientes bitcoins recomendados Ž mostrada em Escolhendo um cliente bitcoin em bitcoin.org. bitcoin.org.
Figure 1. Escolhendo Escolhendo um cliente cliente bitcoin em bitcoin.org bitcoin.org
Executando o Bitcoin Core pela Primeira Vez Se voc baixar um pacote de instala•‹o, como um .exe, .dmg ou PPA, voc pode instal‡-lo da mesma maneira que qualquer aplicativo em seu sistema operacional. Para Windows, execute o .exe e siga a instala•‹o passo-a-passo. Para Mac OS, execute o .dmg e arraste o ’cone Bitcoin-QT para sua pasta Aplicativos. Para Ubuntu, clique duas vezes sobre o PPA em seu Explorador de Arquivos e ele ir‡ abrir o gerenciador de pacotes para instalar o pacote. Uma vez que instala•‹o estiver completa, voc ter‡ um novo aplicativo chamado Bitcoin-Qt em sua lista de aplicativos. D um duplo clique nesse ’cone para iniciar o cliente bitcoin. Na primeira vez que voc executa do Bitcoin Core, ele iniciar‡ o download da Blockchain em um processo que pode demorar v‡rios dias (veja [bitcoin-qt-firstload] [bitcoin-qt-firstload]). ). Deixe ele executando em segundo plano atŽ que ele exiba "Sincronizado" e n‹o mais exiba "Fora de Sincronia" Sincronia" pr—ximo ao valor do saldo.
1
Figure 2. A tela do Bitcoin Core durante durante a inicializa•‹o inicializa•‹o da blockchain blockchain
TIP
O Bitcoin Core mantŽm uma c—pia completa do registro de transa•›es (a blockchain), que contŽm cada transa•‹o transa•‹o que j‡ ocorreu na rede bitcoin desde seu in’cio em 2009. Esse conjunto de dados tem v‡rios gigabytes de tamanho (cerca de 34 GB em maio de 2015) e seu download Ž feito de maneira incremental ao longo de v‡rios dias. O cliente n‹o poder‡ processar transa•›es ou atualizar o saldo da conta a menos que a blockchain completa seja baixada. Durante esse tempo, o cliente ir‡ exibir o texto "n‹o sincronizado" pr—ximo ao saldo da conta e mostrar‡ mostrar‡ "Sincronizando" "Sincronizando" no rodapŽ. Certifique-se de que voc tenha espa•o em disco, conex‹o r‡pida ˆ internet e tempo suficientes para completar a sincroniza•‹o inicial.
Compilando o Bitcoin Core a partir do C—digo-Fonte C—digo-Fonte Para desenvolvedores, ainda h‡ a op•‹o de baixar o c—digo-fonte completo como um arquivo ZIP ou clonar a fonte fonte oficial do reposit—rio do GitHub. Em GitHub bitcoin page, page , selecione Download ZIP na barra lateral. Voc tambŽm pode usar a linha de comando git para criar uma c—pia local do c—digo fonte em seu sistema. No exemplo a seguir, n—s estamo clonando o c—digo fonte de uma linha de comando do tipo Unix, em Linux ou MaC OS:
2
$ git clone https://github.com/bitcoin/bitcoin.gi https://github.com/bitcoin/bitcoin.gitt Clonando para 'bitcoin'... remote: Contando objetos: 31864, conclu ’ do. do. remote: Comprimindo objetos: 100% (12007/12007), conclu ’ do. do. remote: Total 31864 (delta 24480), re-utilizados 26530 (delta 19621) Recebendo objetos: 100% (31864/31864), 18.47 MiB | 119 KiB/s, conclu ’ do. do. Resolvendo deltas: 100% (24480/24480 (24480/24480), ), conclu ’ do. do. $
TIP
As instru•›es e o output resultante podem variar de vers‹o para vers‹o. Siga os passos da documenta•‹o que acompanha o c—digo mesmo que eles sejam diferentes das instru•›es que voc v aqui, e n‹o se surpreenda se o output exibido em sua tela seja levemente diferente dos exemplos desse livro.
Quando a opera•‹o de git clone completar, voc ter‡ uma c—pia local completa do reposit—rio do c—digo-conte na sua pasta bitcoin. Modifique essa pasta ao digitar cd bitcoin no prompt: $ cd bitcoin
Por padr‹o, a c—pia local ser‡ sincronizada com o c—digo mais recente, que pode ser uma vers‹o beta ou inst‡vel do bitcoin. Antes de compilar o c—digo, selecione a vers‹o espec’fica ao checar uma tag de de lan•amento . Isso ir‡ sincronizar a c—pia local com um snapshot espec’fico do resposit—rio do c—digo identificado por uma tag palavra-chave. As tags s‹o usadas pelos desenvolvedores para marcar lan•amentos espec’ficos do c—digo atravŽs de um nœmero de vers‹o. Primeiro, para encontrar as tags dispon’veis, n—s usaremos o comando git tag: $ git tag v0.1.5 v0.1.6test1 v0.2.0 v0.2.10 v0.2.11 v0.2.12 [... muitas outras tags ...] v0.8.4rc2 v0.8.5 v0.8.6 v0.8.6rc1 v0.9.0rc1
A lista de tags exibe todas as vers›es do bitcoin j‡ lan•adas. Por conven•‹o, release candidates, s‹o 3
planejados para testes e contŽm o sufixo "rc". Vers›es est‡veis que possam ser executadas em sistemas de produ•‹o n‹o possuem sufixo. Da lista existente, selecione a vers‹o mais recente, que atŽ este momento era v0.10.2. Para sincronizar o c—digo local com esta vers‹o, use o comando git checkout. $ git checkout v0.9.0rc1 Note: checking out 'v0.9.0rc1'. HEAD is now at 15ec451... Merge pull request #3605 $
O c—digo-fonte inclui uma documenta•‹o, que pode ser encontrada em v‡rios arquivos. Veja a README.md d na pasta bitcoin ao digitar more README.md no documenta•‹o principal localizada em README.m prompt e usando a barra de espa•o para ler a pr—xima p‡gina. Nesse cap’tulo, iremos fazer o build do cliente de bitcoin na linha de comando, tambŽm conhecido como bitcoind no Linux. Veja as instru•›es para compilar o cliente bitcoind em linha de comando na sua plataforma ao digitar more doc/buildunix.md. Instru•›es alternativas para Mac OS X e Windows podem ser encontradas na pasta doc, como build-osx.md ou build-msw.md, respectivamente. Analise cuidadosamente os prŽ-requisitos da vers‹o, presentes na primeira parte da documenta•‹o do mesmo. Estas s‹o as bibliotecas que devem estar presentes em seu sistema antes que voc possa iniciar a compila•‹o do bitcoin. Se estes prŽ-requisitos estiverem ausentes, o processo ir‡ falhar. Logo, voc pode instal‡-los e ent‹o continuar o processo de compila•‹o de onde voc parou. Assumindo que os prŽ-requisitos est‹o instalados, voc inicia o processo de compila•‹o, gerando um conjunto de scripts de constru•‹o que utilizam o script autogen.sh.
TIP
O processo de build do Bitcoin Core foi modificado para usar o sistema autogen/configure/makee a partir da vers‹o 0.9. As vers›es mais antigas usam um Makefile autogen/configure/mak simples e funcionam um pouco diferente do exemplo demonstrado a seguir. Siga as instru•›es para a vers‹o que voc quer compilar. O autogen/configure/make introduzido na 0.0 provavelmente ser‡ o sistema de build usado para todas as vers›es futuras do c—digo e Ž o sistema demonstrado nos exemplos a seguir.
$ ./autogen.sh configure.ac:12: configure.ac :12: configure.ac:12: configure.ac :12: configure.ac:37: configure.ac :37: configure.ac:37: configure.ac :37: src/Makefile.am: src/Makefile .am: $
instalando instalando instalando instalando instalando
`src/build-aux/config.guess' `src/build-aux/config.gue ss' `src/build-aux/config.sub `src/build-a ux/config.sub'' `src/build-aux/install-sh `src/build-a ux/install-sh'' `src/build-aux/missing' `src/build-a ux/missing' `src/build-aux/depcomp' `src/build-a ux/depcomp'
O script autogen.sh cria um conjunto de scripts de configura•‹o autom‡tica que ir‹o interrogar seu sistema a descobrir as configura•›es corretas e garantir que voc tenha todas as bibliotecas necess‡rias para compilar o c—digo. O mais importante desses Ž o script configure que oferece v‡rias
4
op•›es diferentes para customizar o processo de build. Digite ./configure --help para ver as v‡rias op•›es: $ ./configure --help `configure' configura o Bitcoin Core 0.9.0 para se adaptar a muitos tipos de sistemas. Uso: ./configure [OP ‚ÌO]... [VAR=VALOR].. [VAR=VALOR].... Para atribuir as vari ‡veis de ambiente (ex.: CC, CFLAGS...), especifique-as especifique-as como VAR=VALOR. Consulte abaixo descri •›es de algumas vari ‡veis œteis. As op•›es padr ‹o est‹o especificadas em par nteses. Configura•‹o: -h, --help --help exibe exibe essa essa ajuda ajuda e sai --help=short exibe op •›es espec’ ficas ficas para esse pacote --help=recursive --help=recurs ive exibe a ajuda curta (short) de todos os pacotes inclu ’ dos dos -V, --version exibe as informa •›es de vers ‹o e sai [... muitas outras op •›es e vari ‡veis s‹o exibidas abaixo ...] Fun•›es opcionais: --disable-option-checking --disable-op tion-checking ignore unrecognized --enable/--w --enable/--with ith options --disable-FEATURE --disable-FE ATURE n ‹o incluir FEATURE (mesmo que --enable-FEATURE=no) --enable-FEATURE[=ARG] --enable-FEA TURE[=ARG] incluir FEATURE [ARG=yes] [... mais op •›es ...] Use essas vari ‡veis para sobrescrever as escolhas feitas pelo `configure' ou para ajudar a encontrar livrarias e programas com nomes/localiz nomes/localizaa •›es n‹o-padr ›es. Informe bugs para
. $
O script configure permite que voc habilite ou desabilite certas fun•›es do bitcoind atravŽs do uso das flags --enable-FEATURE e --disable-FEATURE, onde FEATURE Ž substitu’da pelo nome de uma fun•‹o, como listado no output do help. Nesse cap’tulo, n—s iremos construir o cliente bitocind com todas as fun•›es padr›es. N—s n‹o iremos usar as flags de configura•›es, mas voc deveria revis‡-las para entender quais fun•›es opcionais fazem parte do cliente. A seguir, rode o script configure para automaticamente descobrir todas as bibliotecas necess‡rias e criar um script de build customizado para o seu sistema:
5
$ ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes [... muitos outros recursos do sistema s ‹o testados ...] configure: creating ./config.sta ./config.status tus config.status: config.statu s: creating Makefile config.status: config.statu s: creating src/Makefile config.status: config.statu s: creating src/test/Mak src/test/Makefile efile config.status: config.statu s: creating src/qt/Makefile config.status: config.statu s: creating src/qt/test/ src/qt/test/Makefile Makefile config.status: config.statu s: creating share/setup.nsi config.status: config.statu s: creating share/qt/Inf share/qt/Info.plist o.plist config.status: config.statu s: creating qa/pull-test qa/pull-tester/run-bitcoi er/run-bitcoind-for-test. nd-for-test.sh sh config.status: config.statu s: creating qa/pull-test qa/pull-tester/build-test er/build-tests.sh s.sh config.status: config.statu s: creating src/bitcoinsrc/bitcoin-config.h config.h config.status: config.statu s: executing depfiles commands $
Se tudo der certo, o comando configure terminar‡ criando os scripts de build customizados que nos permitir‹o compilar o bitcoind. Se houver qualquer livrarias faltando ou erros, o comando configure ir‡ terminar com um erro ao invŽs de criar os script de build. Se um erro ocorrer, mais provavelmente ser‡ devido a uma biblioteca faltando ou incompat’vel. Revise a documenta•‹o do build novamente e certifique-se que voc instalou os prŽ-requisitos que est‹o em falta. Ent‹o execute o configure novamente e veja se isso corrige o erro. Em seguida, voc ir‡ compilar o c—digo fonte, um processo que pode levar atŽ uma hora para ser completado. Durante o processo de compila•‹o voc dever‡ ver um output a cada poucos segundos ou minutos, ou um erro se algo der errado. O processo de compila•‹o pode ser reiniciado a qualquer momento se for interrompido. Digite make para iniciar a compila•‹o:
6
$ make Making all in src make[1]: Entering directory `/home/ubuntu/bitcoin/src' `/home/ubuntu/bitcoin/src' make all-recursive make[2]: Entering directory `/home/ubuntu/bitcoin/src' `/home/ubuntu/bitcoin/src' Making all in . make[3]: Entering directory `/home/ubuntu/bitcoin/src' `/home/ubuntu/bitcoin/src' CXX addrman.o CXX alert.o CXX rpcserver.o CXX bloom.o CXX chainparams.o [... muitas outras mensagens de compila •‹o ...] CXX test_bitcointest_bitcoin-wallet_tests. wallet_tests.oo CXX test_bitcointest_bitcoin-rpc_wallet_te rpc_wallet_tests.o sts.o CXXLD test_bitcoin make[4]: Leaving directory `/home/ubuntu/bitcoin/src/test' `/home/ubuntu/bitcoin/src/test' make[3]: Leaving directory `/home/ubuntu/bitcoin/src/test' `/home/ubuntu/bitcoin/src/test' make[2]: Leaving directory `/home/ubuntu/bitcoin/src' `/home/ubuntu/bitcoin/src' make[1]: Leaving directory `/home/ubuntu/bitcoin/src' `/home/ubuntu/bitcoin/src' make[1]: Entering directory `/home/ubuntu/bitcoin' `/home/ubuntu/bitcoin' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/ubuntu/bitcoin' `/home/ubuntu/bitcoin' $
Se tudo ocorrer dentro do esperado, o bitcoind agora est‡ compilado. O passo final Ž instalar o execut‡vel do bitcoind no caminho do sistema usando o comando make: $ sudo make install Making install in src Making install in . /bin/mkdir -p '/usr/local/ '/usr/local/bin' bin' /usr/bin/install /usr/bin/ins tall -c bitcoind bitcoin-cli '/usr/local/ '/usr/local/bin' bin' Making install in test make install-am /bin/mkdir -p '/usr/local/ '/usr/local/bin' bin' /usr/bin/install /usr/bin/ins tall -c test_bitcoin test_bitcoin '/usr/local '/usr/local/bin' /bin' $
Voc pode confirmar que o bitcoin est‡ corretamente instalado ao perguntar ao sistema pelo caminho dos dois execut‡veis, como demonstrado a seguir:
7
$ which bitcoind /usr/local/bin/bitcoind $ which bitcoin-cli /usr/local/bin/bitcoin-cli /usr/local/bin /bin. Quando voc rodar o bitcoind pela primeira A instala•‹o padr‹o do bitcoind o salva em /usr/local vez, ele ir‡ lembr‡-lo para criar um arquivo de configura•‹o com uma senha forte para a interface JSON-RPC. Execute o bitcoind ao digitar bitcoind no terminal: terminal:
$ bitcoind Erro: Para usar a op •‹o "-server", voc precisa definir uma rpcpassword no arquivo de configura•‹o: /home/ubuntu/.bitcoin/bitcoin.conf ƒ recomendado que voc use a seguinte senha aleat —ria: rpcuser=bitcoinrpc rpcpassword=2XA4DuKNCbtZX rpcpassword= 2XA4DuKNCbtZXsBQRRNDEwEY2n sBQRRNDEwEY2nM6M4H9Tx5dFjo M6M4H9Tx5dFjoAVVbK AVVbK (voc n‹o precisa se lembrar dessa senha) O usu‡rio e senha N ÌO DEVEM ser iguais. Se o arquivo n ‹o existir, crie um com permiss ›es de arquivo owner-somente leitura TambŽm recomenda-se definir um alertnotify, para que voc seja notificado sobre problemas; por exemplo: alertnotify=echo %s | mail -s "Alerta Bitcoin" [email protected] [email protected]
Edite o arquivo de configura•‹o em seu editor de preferncia e defina os par‰metros, substituindo a senha por uma senha forte como recomendado pelo bitcoind. N‹o use a senha mostrada aqui. Crie um arquivo no interior da pasta .bitcoin de maneira que ela fique nomeada como .bitcoin/bitcoin.conf e insira um usu‡rio e senha: rpcuser=bitcoinrpc rpcpassword=2XA4DuKNCbtZX rpcpassword= 2XA4DuKNCbtZXsBQRRNDEwEY2n sBQRRNDEwEY2nM6M4H9Tx5dFjo M6M4H9Tx5dFjoAVVbK AVVbK
Enquanto voc estiver editando esse arquivo de configura•‹o, voc pode querer definir algumas outras op•›es, como a txindex (ver êndice do Banco de Dados de Transa•›es e a Op•‹o txindex ). Para uma listagem completa das op•›es dispon’veis, digite bitcoind --help. Agora, execute o cliente Bitcoin Core. Ao ser executado pela primeira vez, ele ir‡ reconstruir a blockchain do bitcoin ao fazer o download de todos os blocos. Ela Ž um arquivo de v‡rios gigabytes e levar‡ em mŽdia dois dias para ser completamente baixada. Voc pode diminuir o tempo de inicializa•‹o da blockchain ao fazer o download de uma c—pia parcial dela usando um cliente BitTorrent BitTorre nt a partir de SourceForge SourceForge.. Execute o bitcoind em segundo plano com a op•‹o -daemon:range="endofrange", startref="ix_ch03-
8
asciidoc3") $ bitcoind -daemon Bitcoin version v0.9.0rc1-beta (2014-01-31 09:30:15 +0100) _(N.T. A vers ‹o ser‡ diferente de acordo com a vers ‹o baixada no GitHub)_ Using OpenSSL version OpenSSL 1.0.1c 10 May 2012 Default data directory /home/bitcoin/.bitcoin /home/bitcoin/.bitcoin Using data directory /bitcoin/ Using at most 4 connections (1024 file descriptors available) init message: Verifying wallet... dbenv.open LogDir=/bitc LogDir=/bitcoin/database oin/database ErrorFile=/bi ErrorFile=/bitcoin/db.log tcoin/db.log Bound to [::]:8333 Bound to 0.0.0.0:8333 init message: Loading block index... Opening LevelDB in /bitcoin/bloc /bitcoin/blocks/index ks/index Opened LevelDB successfully Opening LevelDB in /bitcoin/chai /bitcoin/chainstate nstate Opened LevelDB successfully [... mais mensagens de inicializa •‹o ...]
Usando a API JSON-RPC do Bitcoin Core a partir da Linha de Comando O cliente Bitcoin Core implementa uma interface JSON-RPC que tambŽm pode ser acessada ao se utilizar o ajudante da linha de comando bitcoin-cli. A linha de comando nos permite experimentar interativamente com as capacidades que tambŽm t ambŽm est‹o dispon’veis programaticamente atravŽs da API. Para iniciar, invoque o comando help para ver uma lista dos comandos bitcoin RPC dispon’veis: $ bitcoin-cli help addmultisigaddress addmultisiga ddress nrequired ["key",...] ( "account" ) addnode "node" "add|remove| "add|remove|onetry" onetry" backupwallet "destination "destination"" createmultisig createmultis ig nrequired ["key",...] createrawtransaction createrawtra nsaction [{"txid":"id" [{"txid":"id","vout":n},. ,"vout":n},...] ..] {"address": {"address":amount,...} amount,...} decoderawtransaction decoderawtra nsaction "hexstring" decodescript "hex" dumpprivkey "bitcoinaddre "bitcoinaddress" ss" dumpwallet "filename" getaccount "bitcoinaddr "bitcoinaddress" ess" getaccountaddress getaccountad dress "account" getaddednodeinfo getaddednode info dns ( "node" ) getaddressesbyaccount getaddresses byaccount "account"
9
getbalance ( "account" minconf ) getbestblockhash getblock "hash" ( verbose ) getblockchaininfo getblockcount getblockhash index getblocktemplate getblocktemp late ( "jsonrequesto "jsonrequestobject" bject" ) getconnectioncount getdifficulty getgenerate gethashespersec getinfo getmininginfo getnettotals getnetworkhashps getnetworkha shps ( blocks height ) getnetworkinfo getnewaddresss ( "account" ) getnewaddres getpeerinfo getrawchangeaddress getrawmempooll ( verbose ) getrawmempoo getrawtransaction getrawtransa ction "txid" ( verbose ) getreceivedbyaccount getreceivedb yaccount "account" ( minconf ) getreceivedbyaddress getreceivedb yaddress "bitcoinaddress" ( minconf ) gettransaction gettransacti on "txid" gettxout "txid" n ( includemempool ) gettxoutsetinfo getunconfirmedbalance getwalletinfo getwork ( "data" ) help ( "command" ) importprivkeyy "bitcoinprivkey" ( "label" rescan ) importprivke importwallet "filename" keypoolrefilll ( newsize ) keypoolrefil listaccounts ( minconf ) listaddressgroupings listlockunspent listreceivedbyaccount listreceived byaccount ( minconf includeempty ) listreceivedbyaddress listreceived byaddress ( minconf includeempty ) listsinceblock listsinceblo ck ( "blockhash" target-confirmations target-confirmations ) listtransactions listtransact ions ( "account" count from ) listunspent ( minconf minconf maxconf maxconf ["address", ["address",...] ...] ) lockunspent unlock [{"txid":"txi [{"txid":"txid","vout":n} d","vout":n},...] ,...] move "fromaccount" "toaccount" "toaccount" amount ( minconf "comment" ) ping sendfrom "fromaccount" "tobitcoinaddress" "tobitcoinaddress" amount ( minconf "comment" "comment-to" ) sendmany "fromaccount" {"address":amount,...} {"address":amount,...} ( minconf "comment" ) sendrawtransaction sendrawtrans action "hexstring" ( allowhighfe allowhighfees es ) sendtoaddresss "bitcoinaddress" amount ( "comment" "comment-to" ) sendtoaddres 10
setaccount "bitcoinaddress" "account" setgenerate generate ( genproclimit ) settxfee amount signmessage "bitcoinaddress" "message" signrawtransaction signrawtrans action "hexstring" ( [{"txid":"id","vout":n,"s [{"txid":"id ","vout":n,"scriptPubKey": criptPubKey":"hex","redeem "hex","redeemScript":"hex" Script":"hex"},...] },...] ["privatekey1",...] ["privatekey 1",...] sighashtype ) stop submitblock "hexdata" ( "jsonparamet "jsonparametersobject" ersobject" ) validateaddress validateaddr ess "bitcoinadd "bitcoinaddress" ress" verifychain ( checklevel numblocks ) verifymessagee "bitcoinaddre verifymessag "bitcoinaddress" ss" "signature" "message" walletlock walletpassphrase walletpassph rase "passphrase" timeout walletpassphrasechange walletpassph rasechange "oldpassphras "oldpassphrase" e" "newpassphra "newpassphrase" se"
Obtendo Informa•›es do Status do Cliente Bitcoin Core Comandos: getinfo O comando RPC getinfo do Bitcoin exibe informa•›es b‡sicas sobre o estado do n— da rede bitcoin, da carteira e do banco de dados da blockchain. Use bitcoin-cli para rod‡-lo: $ bitcoin-cli getinfo
{ "version" : 90000, "protocolversion" "protocolve rsion" : 70002, "walletversion" "walletvers ion" : 60000, "balance" : 0.00000000, "blocks" : 286216, "timeoffset" : -72, "connections" "connection s" : 4, "proxy" : "", "difficulty" : 2621404453.06 2621404453.06461525, 461525, "testnet" : false, "keypoololdest" "keypoololdes t" : 1374553827, "keypoolsize" "keypoolsiz e" : 101, "paytxfee" : 0.00000000, "errors" : "" }
Os dados retornam em JavaScript Object Notation (JSON), um formato que pode ser facilmente "consumido" por todas as linguagens de programa•‹o mas que tambŽm Ž bastante f‡cil de ler por uma
11
pessoa. Entre esses dados n—s vemos os nœmeros de vers‹o do cliente de software (90000), protocolo (70002) e carteira (60000) bitcoin. N—s vemos o saldo atual contido na carteira, que Ž zero. N—s vemos a altura atual do bloco, nos mostrando quantos blocos esse cliente conhece (286216). N—s tambŽm vemos v‡rias estat’sticas sobre a rede bitcoin e as configura•›es relacionadas a esse cliente. N—s iremos explorar essas configura•›es em mais detalhes no resto desse cap’tulo.
TIP
Levar‡ algum tempo, talvez mais de um dia, para o cliente bitcoind "alcan•ar" a altura da blockchain atual ao baixar os blocos de outros clientes bitcoin. Voc pode verificar o seu progresso usando getinfo para ver o nœmero de blocos conhecidos.
Configura•‹o e Criptografia da Carteira Comandos: encryptwallet, walletpassphra walletpassphrase se Antes de voc proceder com a cria•‹o de chaves e outros comandos, voc deve primeiro criptografar a carteira com uma chave. Para esse exemplo, voc ir‡ utilizar o comando encryptwallet com a senha "foo". Obviamente, substitua "foo" por uma senha forte e complexa! $ bitcoin-cli encryptwallet foo carteira criptografada; Parando servidor bitccoin, reinicie para rodar com carteira criptografada. criptografad a. A pool de chaves foi liberada, voc precisa fazer um novo backup. $
Voc pode verificar se a carteira foi criptografada ao executar getinfo novamente. Dessa vez voc ir‡ perceber uma nova entrada chamada unlocked_until. Ela Ž um contador mostrando por quanto tempo a senha de descriptografia da carteira ser‡ armazenada na mem—ria, mantendo a carteira desbloqueada. Inicialmente ela ser‡ definida como zero, significando que a carteira est‡ bloqueada: $ bitcoin-cli getinfo
{ "version" : 90000, #[... outras informa •›es...] "unlocked_until" : 0, "unlocked_until" "errors" : "" } $
Para desbloquear a carteira, use o comando walletpassphra walletpassphrase, se, que carrega dois par‰metrosÑ par‰metrosÑaa senha e o nœmero de segundos atŽ que a carteira seja bloqueada novamente de maneira autom‡tico (um timer regressivo): 12
$ bitcoin-cli walletpassphrase foo 360 $
Voc pode confirmar que a carteira est‡ desbloqueada e ver o tempo restante ao executar getinfo novamente: $ bitcoin-cli getinfo
{ "version" : 90000, #[... outras informa •›es ...] "unlocked_until" : 1392580909, "unlocked_until" "errors" : "" }
Backup da Carteira, Dump em texto-puro e Restaura•‹ Restaura•‹o o Comandos: backupwallet, importwallet, dumpwallet A seguir n—s iremos criar um arquivo de backup da carteira e restauraremos a carteira a partir desse arquivo. Use o comando backupwallet para fazer o backup, fornecendo o nome do arquivo como par‰metro. Aqui n—s iremos fazer backup da carteira para o arquivo wallet.backup: $ bitcoin-cli backupwallet wallet.backup $
Agora, para recuperar o arquivo de backup, utilize o comando importwallet. Se sua carteira estiver bloqueada, voc precisar‡ desbloquea-la antes (ver walletpassphra walletpassphrase se na se•‹o anterior) para importar o arquivo de backup: $ bitcoin-cli importwallet wallet.backup $
O comando dumpwallet pode ser usado para fazer um dump da carteira em um arquivo de texto de leitura f‡cil:
13
$ bitcoin-cli dumpwallet wallet.txt $ more wallet.txt # Dump da carteira criado por Bitcoin v0.9.0rc1-beta (2014-01-31 09:30:15 +0100) # * Criado em 2014-02- 8dT20:34:55Z # * O melhor bloco na Žpoca do backup era 286234 (0000000000000000f74f0bc9 (00000000000 00000f74f0bc9d3c186267bc45 d3c186267bc45c7b91c49a0386 c7b91c49a0386538ac24c0d3a4 538ac24c0d3a44), 4), # minerado em 2014-02- 8dT20:24:01Z KzTg2wn6Z8s7ai5NA9MVX4vstHRsqP26QKJCzL KzTg2wn6Z8s7ai5NA9MVX4vst HRsqP26QKJCzLg4JvFrp6mMaGB g4JvFrp6mMaGB99 2013-07- 4dT04:30:27Z change=1 # addr=16pJ6XkwSQv5ma5FSXMR addr=16pJ6Xk wSQv5ma5FSXMRPaXEYrENCEg47 PaXEYrENCEg47FF Kz3dVz7R6mUpXzdZy4gJEVZxX Kz3dVz7R6mUp XzdZy4gJEVZxXJwA15f198eVui JwA15f198eVui4CUivXotzLBDK 4CUivXotzLBDKYY 2013-07- 4dT04:30:27Z change=1 # addr=17oJds8kaN8LP8kuAkWT addr=17oJds8 kaN8LP8kuAkWTco6ZM7BGXFC3g co6ZM7BGXFC3gkk [... muitas outras chaves ...] $
Endere•os da Carteira e Recebendo Transa•›es Comandos: getnewaddress, getreceivedbyaddress, listtransactions, getaddressesbyaccount, getbalance O cliente referncia do bitcoin mantŽm um pool de endere•os, o tamanho do qual Ž exibido atravŽs do keypoolsize quando voc usa o comando getinfo. Esses endere•os s‹o gerados automaticamente e podem ser utilizados como endere•os pœblicos para receber pagamentos ou como endere•os de troco. Para gerar um desses endere•os, use o comando getnewaddress: $ bitcoin-cli getnewaddress 1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL
Agora n—s podemos usar esse endere•o para enviar uma pequena quantidade de bitcoins para nossa carteira bitcoind a partir de uma carteira externa (assumindo que voc tem alguns bitcoins em uma exchange, carteira web ou outra carteira bitcoind em outro lugar). Para esse exemplo, n—s enviaremos 50 milibits (0,050 bitcoin) para o endere•o anterior. Agora n—s podemos requisitar o cliente bitcoind para a quantia recebida por esse endere•o, e especificar quantas confirma•›es s‹o necess‡rias antes que uma quantia seja contabilizada no saldo. Para esse exemplo, n—s iremos especificar zero confirma•›es. Alguns segundos ap—s enviar o bitcoin de outra carteira, n—s iremos ver isso refletido na carteira. N—s usamos getreceivedbyaddress com o endere•o e o nœmero de confirma•›es definido para zero (0): $ bitcoin-cli getreceivedbyaddress getreceivedbyaddress 1hvzSofGwT8 1hvzSofGwT8cjb8JU7nBsCSf cjb8JU7nBsCSfEVQX5u9CL EVQX5u9CL 0 0.05000000
Se n—s omitirmos o zero do final desse comando, n—s iremos ver somente as quantias que tiveram pelo
14
menos minconf confirma•›es, onde minconf Ž o par‰metro para o nœmero m’nimo de confirma•›es antes que uma transa•‹o seja listada no saldo. O par‰metro minconf Ž especificado no arquivo de configura•‹o do bitcoind. Como a transa•‹o enviando esse bitcoin s— foi enviada nos œltimos poucos segundos, ela ainda n‹o foi confirmada e portanto n—s iremos ver ele listas um saldo zero: $ bitcoin-cli getreceivedbyaddress 1hvzSofGwT8 1hvzSofGwT8cjb8JU7nBsCSf cjb8JU7nBsCSfEVQX5u9CL EVQX5u9CL 0.00000000
As transa•›es recebidas pela carteira tambŽm podem ser exibidas usando o comando listtransactions: $ bitcoin-cli listtransactions listtransactions
[ { "account" : "", "address" : "1hvzSofGwT8 "1hvzSofGwT8cjb8JU7nBsCS cjb8JU7nBsCSfEVQX5u9CL", fEVQX5u9CL", "category" : "receive", "amount" : 0.05000000, "confirmations" "confirmat ions" : 0, "txid" : "9ca8f969bd3 "9ca8f969bd3ef5ec2a868566 ef5ec2a8685660fdbf7a8bd365 0fdbf7a8bd365524c2e1fc66c3 524c2e1fc66c309acbae2c14ae 09acbae2c14ae3", 3", "time" : 1392660908, "timereceived"" : 1392660908 "timereceived } ]
N—s podemos listar todos os endere•os contidos na carteira usando o comando getaddressesbyaccount: $ bitcoin-cli getaddressesbyaccount ""
15
[ ]
"1LQoTPYy1TyERbNV4zZbhEmgyfAipC6eqL", "17vrg8uwMQUibkvS2ECRX4zpcVJ78iFaZS", "1FvRHWhHBBZA8cGRRsGiAeqEzUmjJkJQWR", "1NVJK3JsL41BF1KyxrUyJW5XHjunjfp2jz", "14MZqqzCxjc99M5ipsQSRfieT7qPZcM7Df", "1BhrGvtKFjTAhGdPGbrEwP3xvFjkJBuFCa", "15nem8CX91XtQE8B1Hdv97jE8X44H3DQMT", "1Q3q6taTsUiv3mMemEuQQJ9sGLEGaSjo81", "1HoSiTg8sb16oE6SrmazQEwcGEv8obv9ns", "13fE8BGhBvnoy68yZKuWJ2hheYKovSDjqM", "1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL", "1KHUmVfCJteJ21LmRXHSpPoe23rXKifAb2", "1LqJZz1D9yHxG4cLkdujnqG5jNNGmPeAMD"
Finalmente, o comando getbalance mostrar‡ o saldo total da carteira, somando todas as transa•›es confirmadas com pelo menos minconf confirma•›es: $ bitcoin-cli getbalance 0.05000000
TIP
Se a transa•‹o ainda n‹o foi confirmada, o saldo que getbalance retornar‡ ser‡ de zero. A op•‹o de configura•‹o "minconf" determina o nœmero m’nimo de confirma•›es que s‹o necess‡rias antes de uma transa•‹o aparecer no saldo.
Explorando e Decodificando as Transa•›es Comandos: gettransaction, getrawtransaction, decoderawtransaction Agora n—s iremos explorar a transa•‹o que chega e que foi listada previamente usando o comando gettransaction. N—s podemos coletar a transa•‹o atravŽs de seu hash de transa•‹o, mostrado em txid anteriormente, com o comando gettransaction:
16
{ "amount" : 0.05000000, "confirmations" "confirmati ons" : 0, "txid" : "9ca8f969bd3 "9ca8f969bd3ef5ec2a868566 ef5ec2a8685660fdbf7a8bd365 0fdbf7a8bd365524c2e1fc66c3 524c2e1fc66c309acbae2c14a 09acbae2c14ae3", e3", "time" : 1392660908, "timereceived"" : 1392660908, "timereceived "details" : [ { "account" : "", "address" : "1hvzSofGwT8 "1hvzSofGwT8cjb8JU7nBsCSf cjb8JU7nBsCSfEVQX5u9CL", EVQX5u9CL", "category" : "receive", "amount" : 0.05000000 } ] }
TIP
Os IDs de transa•›es n‹o s‹o "oficiais" atŽ que a transa•‹o tenha sido confirmada. A ausncia de um hash de transa•‹o na blockchain n‹o significa que a transa•‹o n‹o foi processada. Isso Ž conhecido como "maleabilidade da transa•‹o", porque hashes de transa•‹o podem ser modificados antes da confirma•‹o em um bloco. Ap—s a confirma•‹o, o txid Ž imut‡vel e oficial.
A forma de transa•‹o mostrada com o comando gettransaction Ž a forma simplicada. Para adquirir o c—digo de transa•‹o completo e decodific‡-lo, n—s iremos usar dois comandos: getrawtransaction e decoderawtransaction. Primeiro, o getrawtransaction recebe o hash da transa•‹o (txid) como um par‰metro e retorna a transa•‹o completa como uma string hexadecimal "raw", exatamente como ela existe na rede bitcoin: Para decodificar essa string hexadecimal, use o comando decoderawtransaction. Copie e cole o hexadecimal como o primeiro par‰metro de decoderawtransaction para obter o conteœdo completo interpretado como uma estrutura de dados JSON (por quest›es de formata•‹o a string hexadecimal Ž encurtada no seguinte exemplo): A decodifica•‹o da transa•‹o mostra todos os componentes desta transa•‹o, incluindo os inputs e outputs da transa•‹o. Nesse caso n—s vemos que a transa•‹o que creditou nosso novo endere•o com 50 milibits usou um input e gerou dois outputs. O input para essa transa•‹o foi o output de uma transa•‹o previamente confirmada (mostrada como o vin txid iniciando com d3c7). Os dois outputs correspondem ao crŽdito de 50 milibit e a um output com o troco de volta ao remetente. Podemos explorar mais a fundo a blockchain ao examinarmos a transa•‹o anterior referenciada pelo seu txid nesta transa•‹o usando os mesmos comandos (ex: gettransaction). Saltando de transa•‹o em transa•‹o n—s podemos seguir uma corrente de transa•›es de volta na medida em que as moedas s‹o transmitidas entre os endere•os de seus donos. Assim que a transa•‹o que recebemos Ž confirmada ao ser inclu’da em um bloco, o comando
17
gettransaction ir‡ retornar informa•›es adicionais, mostrando o hash do bloco (identificador) no qual a transa•‹o foi inclu’da: Aqui, n—s vemos a nova informa•‹o nas entradas blockhash (o hash do bloco no qual a transa•‹o foi inclu’da), e blockindex com valor 18 (indicando que nossa transa•‹o foi a 18» transa•‹o naquele bloco).
êndice do Banco de Dados de Transa•›es e a Op•‹o txindex Por padr‹o, o Bitcoin Core constr—i um banco de dados contendo apenas as transa•›es relacionadas ˆ carteira do usu‡rio. Se voc quiser ter acesso a qualquer transa•‹o transa•‹o com comandos como gettransaction, voc tem que configurar o Bitcoin Core para construir um ’ndice completo de transa•›es, que pode ser realizado com a op•‹o txindex. Defina txindex=1 no arquivo de configura•‹o do Bitcoin Core (geralmente encontrado em seu diret—rio sob .bitcoin/bitcoin.conf ). Assim que mudar esse par‰metro, voc precisar‡ reiniciar o bitcoind e esperar que ele reconstrua o ’ndice.
Explorando os Blocos Comandos: getblock, getblockhash Agora que n—s sabemos em qual bloco nossa transa•‹o foi inclu’das, n—s podemos fazer uma requisi•‹o nesse bloco. N—s usaremos o comando getblock com o hash do bloco como par‰metro: O bloco contŽm 367 transa•›es e como voc pode ver, a 18» transa•‹o listada (9ca8f9...) Ž o txid de um dos 50 milibits creditados em nosso endere•o. A entrada altura nos informa que esse Ž o 286.384¼ bloco na blockchain. N—s tambŽm podemos adquirir um bloco atravŽs de sua altura de bloco usando o comando getblockhash, que recebe a altura do bloco como par‰metro e retorna o hash do bloco para aquele bloco: Aqui, n—s solicitamos o hash do bloco do "bloco gnese", o primeiro bloco minerado por Satoshi Nakamoto, na altura zero. A solicita•‹o desse bloco mostra: Os comandos getblock, getblockhash e gettransaction podem podem ser usados para explorar explorar o banco banco de dados da blockchain, programaticame programaticamente. nte.
Criando, Assinando e Enviando Transa•›es Baseadas em Outputs N‹o-gastos Comandos: listunspent, gettxout, createrawtransaction, decoderawtransaction, signrawtransaction, sendrawtransaction As transa•›es do Bitcoin s‹o baseadas no conceito de gastar "outputs", que s‹o o resultado de transa•›es prŽvias, para criar uma corrente de transa•›es que transfere a posse de um endere•o para outro endere•o. Nossa carteira agora recebeu uma transa•‹o que designou um desses outputs para
18
nosso endere•o. Uma vez confirmada, n—s podemos gastar esse output. Primeiro, n—s utilizaremos o comando listunspent para mostrar todos os outputs confirmados n‹ogastos em nossa carteira: $ bitcoin-cli listunspent
N—s vemos que a transa•‹o 9ca8f9... criou um output (com o ’ndice vout 0) designado para o endere•o 1hvzSo... para a quantidade de 50 milibits, que atŽ esse momento j‡ recebeu sete confirma•›es. As transa•›es usam outputs criados anteriormente como seus inputs ao us‡-los como referncia atravŽs do txid e ’ndice vout anterior. N—s agora iremos criar uma transa•‹o que ir‡ gastar o vout zero da txid 9ca8f9... como seu input e design‡-la como um novo output que envia um valor para um novo endere•o. Primeiramente, vamos olhar ao output espec’fico em maiores detalhes. N—s usamos gettxout para obter os detalhes desse output n‹o-gasto. Os outputs de transa•‹o s‹o sempre referenciados pelo txid e vout, e esses s‹o os par‰metros que n—s passamos para o gettxout: O que n—s vemos aqui Ž o output que designou 50 milibits para nosso endere•o 1hvz.... Para gastar esse output n—s iremos criar uma nova transa•‹o. Primeiro, vamos fazer um endere•o para o qual n—s iremos enviar o dinheiro: $ bitcoin-cli getnewaddress 1LnfTndy3qzXGN19Jwscj1T8LR3MVe3JDb
N—s enviaremos 25 milibits para o novo endere•o 1LnfTn... que n—s acabamos de criar em nossa carteira. Em nossa nova transa•‹o, n—s iremos gastar o output de 50 milibit e enviar 25 milibits para esse novo endere•o. Como n—s temos que gastar todo o output da transa•‹o anterior, n—s tambŽm devemos gerar algum troco. N—s iremos gerar o troco de volta para o endere•o 1hvz..., enviando o troco de volta para o endere•o do qual o valor se originou. Finalmente, n—s tambŽm teremos que pagar uma taxa para essa transa•‹o. Para pagar a taxa, n—s iremos reduzir o output do troco em 0,5 milibits, e retornar 24,5 milibits em troco. A diferen•a entre a soma dos novos outputs (25 mBTC + 24,5 mBTC = 49,5 mBTC) e o input (50 mBTC) ser‡ ser‡ coletada como uma taxa de transa•‹o pelos mineradores. mineradores. N—s usaremos createrawtransaction para criar essa transa•‹o. Como par‰metros para createnewtransaction n—s forneceremos o input da transa•‹o (o output de 50 milibits n‹o-gastos de nossa transa•‹o confirmada) e os dois outputs de transa•›es (dinheiro enviado para para o novo endere•o e troco enviado de volta para o endere•o anterior): O comando createrawtransaction produz uma string hexadecimal raw que codifica os detalhes da transa•‹o que n—s fornecemos. Vamos confirmar que tudo est‡ correto ao decodificar essa string raw usando o comando decoderawtransaction: decoderawtransaction: Isso parece correto! Nossa nova transa•‹o "consome" o output n‹o gasto de nossa transa•‹o
19
confirmada e ent‹o gasta-o em dois outputs, um de 25 milibits para nosso novo endere•o e outro de 24,5 milibits como troco t roco de volta para o endere•o original. A diferen•a de 0,5 milibits representa a taxa de transa•‹o e ser‡ creditada ao minerador que encontrar o bloco que inclui nossa transa•‹o. Como voc pode perceber, a transa•‹o contŽm um scriptSig vazio porque ainda n‹o foi assinada. Sem uma assinatura, a transa•‹o n‹o tem sentido; n—s ainda n‹o provamos que n—s possu’mos o endere•o que contŽm o output n‹o-gasto. Ao assinar, n—s destravamos o bloqueio no output e provamos que n—s somos donos desse output e que podemos gast‡-lo. N—s usaremos o comando signrawtransaction para assinar a transa•‹o. Esse comando usa a string hexadecimal da transa•‹o raw como par‰metro: TIP
Um carteira criptografada deve ser desbloqueada antes que uma transa•‹o seja assinada, pois a assinatura exige acesso ˆs chaves secretas contidas no interior da carteira.
O comando signrawtransaction retorna outra transa•‹o raw codificada em hex. N—s decodificaremos ela para ver o que mudou, com o comando decoderawtransaction: Agora, o input usado na transa•‹o contŽm um scriptSig, que Ž uma assinatura digital provando a posse do endere•o 1hvz... e removendo a trava t rava no output de maneira que ele possa ser gasto. A assinatura faz com que essa transa•‹o seja verific‡vel por qualquer n— na rede bitcoin. Agora est‡ na hora de enviarmos a transa•‹o recŽm-criada para a rede. N—s faremos isso atravŽs do comando sendrawtransaction, que recebe a string hexadecimal raw produzida pelo signrawtransaction. signrawtr ansaction. Essa Ž a mesma string que n—s recŽm decodificamos: O comando sendrawtransaction retorna um hash de transa•‹o (txid) assim que a transa•‹o Ž enviada para a rede. N—s podemos agora agora consultar esse ID da transa•‹o com gettransaction:
20
{ "amount" : 0.00000000, "fee" : -0.00050000, "confirmations" "confirmati ons" : 0, "txid" : "ae74538baa9 "ae74538baa914f3799081ba7 14f3799081ba78429d5d84f36a 8429d5d84f36a0127438e9f721 0127438e9f721dff584ac17b3 dff584ac17b346", 46", "time" : 1392666702, "timereceived"" : 1392666702, "timereceived "details" : [ { "account" : "", "address" : "1LnfTndy3qz "1LnfTndy3qzXGN19Jwscj1T8 XGN19Jwscj1T8LR3MVe3JDb", LR3MVe3JDb", "category" : "send", "amount" : -0.02500000, "fee" : -0.00050000 }, { "account" : "", "address" : "1hvzSofGwT8 "1hvzSofGwT8cjb8JU7nBsCSf cjb8JU7nBsCSfEVQX5u9CL", EVQX5u9CL", "category" : "send", "amount" : -0.02450000, "fee" : -0.00050000 }, { "account" : "", "address" : "1LnfTndy3qz "1LnfTndy3qzXGN19Jwscj1T8 XGN19Jwscj1T8LR3MVe3JDb", LR3MVe3JDb", "category" : "receive", "amount" : 0.02500000 }, { "account" : "", "address" : "1hvzSofGwT8 "1hvzSofGwT8cjb8JU7nBsCSf cjb8JU7nBsCSfEVQX5u9CL", EVQX5u9CL", "category" : "receive", "amount" : 0.02450000 } ] }
Como anteriormente, n—s tambŽm podemos examinar isso em maiores detalhes usando os comandos getrawtransaction e decodetransaction. Esses comandos ir‹o retornar exatamente a mesma string hexadecimal que n—s produzimos e codificamos anteriormente, logo antes de envi‡-la ˆ rede.
Clientes Alternativos, Bibliotecas e Toolkits AlŽm do cliente de referncia (bitcoind), outros clientes e bibliotecas podem ser usados para interagir com a rede bitcoin e as estruturas de dados. Eles s‹o implementados em v‡rias linguagens de
21
programa•‹o,, oferecendo aos programad programa•‹o programadores ores interfaces nativas em suas pr—prias linguagens. Implementa•›es alternativas: libbitcoin
Bitcoin Cross-Platform C++ Development Toolkit bitcoin explorer
Ferramenta Ferr amenta Linha de comando do Bitcoin bitcoin server
Bitcoin Full Node e Query Server bitcoinj
Uma biblioteca Java de um cliente full-node btcd
Um cliente bitcoin full-node em linguagem Go Bits of Proof (BOP) (BOP)
Uma implementa•‹o Java enterprise-class do bitcoin picocoin
Uma implementa•‹o C de uma biblioteca de cliente lightweight para bitcoin pybitcointools pybitcoin tools
Uma biblioteca Python para bitcoin pycoin
Outra biblioteca bitcoin em Python Muitas outras bibliotecas existem em v‡rias outras linguagens de programa•‹o e muitas mais s‹o criadas a todo momento.
Libbitcoin e Bitcoin Explorer A biblioteca libbitcoin Ž um kit de ferramentas de desenvolvimento C++ de plataforma cruzada que suporta o n— de servidor completo-libbitcoin e a ferramenta de linha de comando Bitcoin Explorer (bx). Os commandos bx oferecem muitas das mesmas capacidades que os comandos do cliente bitcoind que foram ilustrados nesse cap’tulos. Os comandos bx tambŽm oferecem algumas ferramentas de administra•‹o e de manipula•‹o de chaves chaves que n‹o s‹o oferecidas oferecidas pelo bitcoind, incluindo chaves determin’sticas tipo 2 e codifica•‹o mnem™nica de chave, alŽm de endere•o e pagamento camuflados (stealth), e suporte a query.
22
Instalando o Bitcoin Explorer Para usar o Bitcoin Explorer, simplesmente fa•a o download do execut‡vel assinado para seu sistema operacional.. Os builds est‹o dispon’veis para a mainnet e testnet para Linux, OS X e Windows. operacional Digite bx sem nenhum par‰metro para mostrar a lista de todos os comandos dispon’veis (veja [appdx_bx]). [appdx_bx] ). O Bitcoin Explorer tambŽm fornece um instalador para fazer builds a partir de c—digo-fontes em Linux e OS X, assim como projetos VIsual Studio para WIndows. WIndows . TambŽm pode-se fazer build manual dos c—digo-fontes usando-se Autotools. Esses tambŽm instalam a dependncia de biblioteca libbitcoin.
TIP
O Bitcoin Explorer oferece muitos comandos œteis para codifica•‹o e decodifica•‹o de endere•os, e convers‹o para e de diferentes formatos e representa•›es. Use-os para explorar os v‡rios formatos como Base16 (hex), Base58, Base58Check, Base64, etc.
Instalando a Libbitcoin A biblioteca libbitcoin fornece um instalador para building fazer builds a partir de c—digos-fonte em Linux e OS X, assim como em projetos Visual Studio para Windows. Windows . TambŽm Ž poss’vel fazer manualmente o build dos c—digos-fonte usando-se Autotools. Autotools. TIP
O instalador do Bitcoin Explorer instala o bx e a biblioteca libbitcoin, se voc fez o build do bx a partir das fontes, voc pode pular essa etapa.
pycoin A biblioteca Python pycoin, originalmente escrita e mantida por Richard Kiss, Ž uma livraria baseada em Python que suporta a manipula•‹o de chaves e transa•›es bitcoin, e atŽ mesmo suporta a linguagem de script suficiente para lidar adequadamente com transa•›es n‹o-padr›es. A biblioteca pycoin suporta tanto o Python 2 (2.7.x) quanto o Python Python 3 (ap—s 3.3), e vem com algumas utlidades de linhas de comando, ku e tx. Para instalar o pycoin 0.42 sob o Python 3 em um ambiente virtual (venv), utilize o seguinte:
23
$ python3 -m venv /tmp/pycoin $ . /tmp/pycoin/bin/activate /tmp/pycoin/bin/activate $ pip install pycoin==0.42 Baixando/descompactando Baixando/desc ompactando pycoin==0.42 Baixando o pycoin-0.42.tar.gz pycoin-0.42.tar.gz (66kB): 66kB 66kB baixados baixados Executando o setup.py (path:/tmp/pyco (path:/tmp/pycoin/build/pyco in/build/pycoin/setup.py) in/setup.py) egg_info para para o pacote pycoin Instalando pacotes coletados: pycoin Executando instala •‹o setup.py para pycoin Instalando tx script para /tmp/pycoin/b /tmp/pycoin/bin in Instalando cache_tx script para /tmp/pycoin /tmp/pycoin/bin /bin Instalando bu script para /tmp/pycoin/b /tmp/pycoin/bin in Instalandog fetch_unspen fetch_unspentt script para /tmp/pycoin/ /tmp/pycoin/bin bin Instalando block script para /tmp/pycoin/ /tmp/pycoin/bin bin Instalando spend script para /tmp/pycoin/ /tmp/pycoin/bin bin Instalando ku script para /tmp/pycoin/b /tmp/pycoin/bin in Instalando genwallet script para /tmp/pycoin/b /tmp/pycoin/bin in pycoin instalado com sucesso Limpando... $
Aqui est‡ um exemplo de script Python para adquirir e gastar alguns bitcoins usando a biblioteca pycoin:
24
#!/usr/bin/envv python #!/usr/bin/en from pycoin.key import Key from pycoin.key.validate import is_address_va is_address_valid, lid, is_wif_valid from pycoin.servic pycoin.services es import spendables_for_address from pycoin.tx.tx_utils import create_signe create_signed_tx d_tx def get_address(which): get_address(which): while 1: print("enterr the %s address=> " % which, end='') print("ente address = input() is_valid = is_address_v is_address_valid(addres alid(address) s) if is_valid: return address print("invalid print("inval id address, please try again") src_address = get_address( get_address("source") "source") spendables = spendables_fo spendables_for_address(src r_address(src_address) _address) print(spendables) while 1: print("enter the WIF for %s=> " % src_address src_address,, end='') wif = input() is_valid = is_wif_valid( is_wif_valid(wif) wif) if is_valid: break print("invalid print("inva lid wif, please try again") key = Key.from_tex Key.from_text(wif) t(wif) if src_address not in (key.address(use_uncompressed=False) (key.address(use_uncompressed=False),, key.address(use_uncompress key.address(u se_uncompressed=True)): ed=True)): print("** WIF doesn't correspond to %s" % src_address) print("The secret exponent is %d" % key.secret_ key.secret_exponent()) exponent()) dst_address = get_address( get_address("destination" "destination")) tx = create_signed create_signed_tx(spendabl _tx(spendables, es, payables=[d payables=[dst_address], st_address], wifs=[wif]) print("here is the signed output transaction") print(tx.as_hex())
Para exemplos usando os utilit‡rios de linha de comando ku e tx, veja [appdxbitcoinimpproposals] [appdxbitcoinimpproposals]..
25
btcd btcd Ž uma implementa•‹o de bitcoin full-node programado programado em Go. Ela atualmente baixa, valida valida e serve a blockchain usando as regras exatas (incluindo bugs) para aceita•‹o de blocos como a implementa•‹o de referncia, bitcoind. Ela tambŽm propriamente transmite blocos recŽm-minerados, mantŽm um pool de transa•›es e transmite transa•›es individuais que ainda n‹o foram inclu’das em um bloco. Ela garante que todas as transa•›es individuais admitidas ˆ pool sigam as regras exigidas e tambŽm inclui uma vas maioria de verifica•›es mais estreitas que filtram as transa•›es baseadas nas necessidades dos mineradore mineradoress (transa•›es "padr‹o") Uma diferen•a importante entre o btcd e o bitcoind Ž que o btcd n‹o inclui a funcionalidade de carteira, e isso foi uma decis‹o de projeto muito intencional. Isso significa que voc n‹o pode fazer ou receber pagamentos diretamente com o btcd. Essa funcionalidade Ž fornecida pelos projetos btcwallet e btcgui, os quais est‹o ambos sob desenvolvimento ativo. Outras diferen•as not‡veis entre o btcd e o bitcoind incluem suporte no btcd para requisi•›es HTTP POST (como no bitcoind) e os Websockets preferidos, e o fato de que as conex›es RPC do btcd s‹o habilitadas a TLS por padr‹o. Instalando btcd Para instalar o btcd para Windows, baixe e execute o arquivo msi dispon’vel em GitHub GitHub,, ou execute a seguinte linha de comando no Linux, assumindo que voc j‡ tenha instalado a Go language: $ go get github.com/conformal/btcd/... github.com/conformal/btcd/...
Para atualizar o btcd para a œltima vers‹o, simplesmente execute: $ go get -u -v github.com/c github.com/conformal/btcd onformal/btcd/... /...
Controlando o btcd btcd tem v‡rias op•›es de configura•›es, que podem ser vistas ao executar: $ btcd --help
O btcd j‡ inclui alguns itens como o btcctl, que Ž um utilit‡rio de linha de comando que pode ser usado tanto para controlar e requisitar o btcd atravŽs de RPC. O btcd n‹o habilita seu servidor RPC por padr‹o; voc deve configurar pelo menos tanto o usu‡rio quanto a senha do RPC nos seguintes arquivos de configura•‹o: ¥ btcd.conf :
26
[Op•›es da Aplica •‹o] rpcuser=myuser rpcpass=SomeDecentp4ssw0rd
¥ btcctl.conf : [Op•›es da Aplica •‹o] rpcuser=myuser rpcpass=SomeDecentp4ssw0rd
Ou se voc quiser sobrescrever os arquivos de configura•‹o a partir da linha de comando: $ btcd -u myuser -P SomeDecentp4ssw0rd $ btcctl -u myuser -P SomeDecentp4ssw0rd
Para uma lista das op•›es dispon’veis, execute o seguinte: $ btcctl --help
27
Chaves, Endere•os, Carteiras Introdu•‹o A posse do bitcoin Ž estabelecida atravŽs de chaves digitais, endere•os bitcoin e assinaturas digitais. Na realidade, as chaves digitais n‹o s‹o armazenadas na rede, mas ao invŽs disso, s‹o criadas e armazenadas pelo usu‡rio em um arquivo, um banco de dados simples, chamado de wallet (carteira). As chaves digitais em uma carteira de um usu‡rio s‹o completamente independentes do protocolo bitcoin e podem ser geradas e gerenciadas pelo software de carteira do usu‡rio sem qualquer referncia ˆ blockchain ou acesso ˆ internet. As chaves permitem muitas das interessantes propriedadess do bitcoin, incluindo confian•a descentralizada e controle, atesta•‹o de posse e o modelo propriedade de seguran•a por prova criptogr‡fica criptogr‡fica.. Toda transa•‹o de bitcoin requer uma assinatura v‡lida para ser inclu’da na blockchain, as quais s— podem ser geradas com chaves digitais v‡lidas; portanto, qualquer um com uma c—pia destas chaves tem o controle sobre os bitcoins daquela conta. Chaves s‹o apresentadas em pares que consistem em uma chave privada (secreta) e uma chave pœblica. Imagine que a Chave Pœblica Ž similar ao nœmero de uma conta banc‡ria e a Chave Privada similar a um PIN secreto ou uma assinatura em um cheque que prov controle sobre a conta. Estas chaves digitais s‹o raramente vistas pelos usu‡rios do bitcoin. Para a maioria, elas s‹o armazenadas dentro de arquivos de carteiras e gerenciadas por um software de carteira bitcoin. Na por•‹o de pagamento de uma transa•‹o bitcoin, a chave pœblica do destinat‡rio Ž representada pela sua impress‹o digital, denominada endere•o bitcoin, que Ž usada da mesma maneira como o nome de um benefici‡rio em um cheque (ou seja, "Pague ˆ ordem de"). Na maioria dos casos, um endere•o bitcoin Ž gerado a partir de uma chave pœblica correspondente. No entanto, nem todos os endere•os bitcoin representam chaves pœblicas; eles tambŽm podem representar outros benefici‡rios, tais como scripts, como veremos mais adiante neste cap’tulo. Desta forma, os endere•os bitcoin abstraem o destinat‡rio dos fundos, tornando destinos de transa•‹o flex’veis, semelhante a cheques em papel: um œnico instrumento de pagamento pode ser usado para dep—sito em contas pessoais, dep—sito em contas da empresa, pagar contas ou converter em dinheiro. O endere•o bitcoin Ž a œnica representa•‹o das chaves que os usu‡rios v‹o rotineiramente ver porque esta Ž a parte que eles precisam compartilhar com o mundo. Neste cap’tulo iremos apresentar Carteiras, as quais contŽm Chaves Criptogr‡ficas. N—s iremos aprender como as chaves s‹o geradas, armazenadas e gerenciadas. Iremos revisar os v‡rios formatos de codifica•‹o usados para representar chaves privadas e pœblicas, endere•os e endere•os baseados em script. Finalmente iremos considerar usos especiais para as chaves: para assinar mensagens, comprovar propriedade, propriedade, criar endere•os exclusivos e carteiras em papel.
Criptografia de Chave Pœblica e Criptomoeda A criptografia de chave pœblica foi inventada nos anos 1970s e Ž uma base matem‡tica para a seguran•a da computa•‹o e informa•‹o.
1
Desde a inven•‹o da criptografia de chave pœblica, muitas fun•›es matem‡ticas adequadas foram descobertas, como exponencia•‹o de nœmeros primos e multiplica•‹o de curva el’ptica. Essas fun•›es matem‡ticas s‹o praticamente irrevers’veis, significando que elas s‹o f‡ceis de calcular em uma dire•‹o, e invi‡veis de serem calculadas na dire•‹o oposta. Baseada nessas fun•›es matem‡ticas, a criptografia permite a cria•‹o de segredos digitais e assinaturas digitais que n‹o podem ser esquecidas. O bitcoin usa multiplica•‹o de curva el’ptica como base para sua criptografia de chave pœblica. No bitcoin, n—s usamos criptografia de chave pœblica para criar um par de chaves que controla o acesso aos bitcoins. O par de chave consiste em uma chave privada e Ñ e Ñ derivada dessa chave Ñ chave Ñ uma chave pœblica œnica. A chave pœblica Ž usada para receber os bitcoins, e a chave privada Ž usada para assinar transa•›es para gastar esses bitcoins. Existe uma rela•‹o matem‡tica entre a chave pœblica e a privada que permite que a chave privada seja usada para gerar assinaturas nas mensagens. Essa assinatura pode ser validada em rela•‹o ˆ chave pœblica, sem a necessidade de se revelar a chave privada. Ao gastar bitcoins, o atual dono dos bitcoins apresenta sua chave pœblica e uma assinatura (diferente a cada vez, mas criada a partir da mesma chave privada) em uma transa•‹o para gastar esses bitcoins. AtravŽs da apresenta•‹o da chave pœblica e da assinatura, todos na rede bitcoin podem verificar e aceitar a transa•‹o como v‡lida, confirmando que a pessoa que est‡ transferindo os bitcoins realmente os possui no momento da transferncia transferncia..
TIP
Na maioria das implementa•›es de carteira, as chaves privadas e pœblicas s‹o armazenadas juntas como um par de chaves, por convenincia. No entanto, a chave pœblica pode ser calculada a partir da chave privada, ent‹o tambŽm Ž poss’vel se armazenar apenas a chave privada.
Chaves Privada e Pœblica Uma carteira bitcoin contŽm um grupo de pares de chaves, ch aves, cada um consistindo de uma chave privada e uma chave pœblica. A chave privada (k) Ž um nœmero, geralmente escolhido ao acaso. A partir da chave privada, n—s usamos multiplica•‹o em curva el’ptica, uma fun•‹o criptogr‡fica de um œnico sentido, para gerar a chave pœblica (K). A partir da chave pœblica (K), n—s iremos usar uma fun•‹o hash criptogr‡fica de um sentido para gerar um endere•o bitcoin (A). Nessa se•‹o, n—s iniciaremos com a gera•‹o da chave privada, analisaremos a matem‡tica de curva el’ptica que Ž usada para torn‡la em uma chave pœblica e, finalmente, a gera•‹o do endere•o bitcoin a partir da chave pœblica. A rela•‹o entre a chave privada, chave pœblica e endere•o bitcoin est‡ demonstrada em Chave privada, chave pœblica e endere•o bitcoin. bitcoin .
2
Figure 1. Chave privada, privada, chave pœblica pœblica e endere•o bitcoin bitcoin
Chaves Privadas Uma chave privada nada mais Ž do que um nœmero, escolhido ao acaso. A posse e o controle da chave privada Ž tudo o que o usu‡rio precisa para controlar todos os fundos associados ao endere•o bitcoin correspondente. A chave privada Ž usada para criar assinaturas que s‹o necess‡rias para se gastar bitcoins ao comprovar a posse dos fundos usados em uma transa•‹o. A chave privada deve sempre ser mantida em segredo, pois revel‡-la a terceiros Ž equivalente a fornec-los o controle sobre todos os bitcoins protegidos por aquela chave. TambŽm deve ser feito backup da chave privada, alŽm de proteg-la de perdas acidentais, pois ao ser perdida a chave n‹o pode ser recuperad recuperada, a, e todos os fundos protegidos por ela tambŽm ser‹o perdidos para sempre.
TIP
A chave privada bitcoin Ž apenas um nœmero. Voc pode escolher suas chaves privadas aleatoriamente usando uma moeda, um l‡pis e um papel: jogue a moeda 256 vezes e voc ter‡ os d’gitos bin‡rios de uma chave privada aleat—ria que voc pode usar em uma carteira bitcoin. A chave pœblica pode ent‹o ser gerada a partir de sua chave privada.
Gerando uma chave privada a partir de um nœmero aleat—rio
O primeiro e mais importante passo na gera•‹o de chaves Ž encontrar uma fonte segura de entropia, ou aleatoriedade. Criar uma chave bitcoin Ž essencialmente a mesma coisa que pedir para alguŽm "Escolha um nœmero entre 1 e 2 256". O mŽtodo exato que voc usa para escolher esse nœmero n‹o importa, contanto que n‹o seja previs’vel ou repet’vel. O software Bitcoin baseia-se em geradores de nœmeros aleat—rios do sistema operacional subjacente para produzir 256 bits de entropia (aleatoriedade). Normalmente, o gerador de nœmeros aleat—rios do sistema operacional Ž inicializado por uma fonte humana de aleatoriedade, raz‹o pela qual voc pode ser convidado para mexer o mouse por alguns segundos. Para quem Ž paran—ico, nada Ž melhor do que jogar dados e depois anotar os resultados com caneta e papel. Mais precisamente, a chave privada pode ser qualquer nœmero entre 1 e n - 1, onde n Ž uma constante (n = 1,158 * 1077, ligeiramente menor que 2 256), definido como a ordem da curva el’ptica usada no bitcoin (veja Explicando a Criptografia de Curva El’ptica). El’ptica ). Para criar tal chave, n—s escolhemos aleatoriamente um nœmero de 256 bits e verificamos se ele Ž menor do que n - 1. Em termos de programa•‹o, isto Ž geralmente obtido alimentando-se uma seqŸncia maior de bits aleat—rios, coletados a partir de uma fonte de aleatoriedade criptograficamente segura, ao algoritmo de hash SHA256 que ir‡ produzir convenientemente um nœmero de 256 bits. Se o resultado for inferior a n - 1, 3
temos uma chave privada adequada. Caso contr‡rio, n—s simplesmente tentamos novamente com outro nœmero aleat—rio.
TIP
N‹o escreva o seu pr—prio c—digo para criar um nœmero aleat—rio, nem utilize u m gerador de nœmeros aleat—rio "simples" oferecido pela sua linguagem de programa•‹o. Use um gerador de nœmeros pseudo-aleat—rios criptograficamente seguro (CSPRNG) com uma semente com fonte de entropia suficiente. Estude a documenta•‹o da biblioteca geradora de nœmeros aleat—rios que voc escolher para se certificar de que Ž criptograficamente segura. O correto emprego do CSPRNG Ž cr’tico para a seguran•a das chaves.
Abaixo est‡ demonstrada uma chave privada (k) gerada aleatoriamente mostrada em formato hexadecial (256 d’gitos bin‡rios mostrados como 64 d’gitos hexadecimais, cada um com 4 bits): 1E99423A4ED27608A15A2616A 1E99423A4ED2 7608A15A2616A2B0E9E52CED33 2B0E9E52CED330AC530EDCC32C 0AC530EDCC32C8FFC6A526AEDD 8FFC6A526AEDD
TIP
O tamanho do espa•o poss’vel de Chaves Privadas existentes, 2^256 Ž de tamanho imcompreens’vel. ƒ aproximadamente 10^77 na escala decimal. Estima-se que o universo vis’vel contenha 10^80 ‡tomos.
Para gerar uma nova chave com o cliente Bitcoin Core (veja [ch03_bitcoin_client] [ch03_bitcoin_client]), ), Use o comando getnewaddress. Por motivos de seguran•a Ž exibida somente a chave pœblica, n‹o a chave privada. Para pedir ao bitcoind para expor a chave privada, use o comando dumpprivkey. O comando dumpprivkey mostra a chave privada em um formato checksum-codificado em Base58 chamado de privada . Wallet Import Format (WIF), que vamos examinar com mais detalhes em Formatos de chave privada. Aqui est‡ um exemplo da cria•‹o e exibi•‹o uma chave privada usando esses dois comandos: $ bitcoind getnewaddres getnewaddresss 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy $ bitcoind dumpprivkey 1J7mdg5rbQyUH 1J7mdg5rbQyUHENYdx39WVWK7f ENYdx39WVWK7fsLpEoXZy sLpEoXZy KxFC1jmwwCoACiCAWZ3eXa96m KxFC1jmwwCoA CiCAWZ3eXa96mBM6tb3TYzGmf6 BM6tb3TYzGmf6YwgdGWZgawvrt YwgdGWZgawvrtJJ
O comando dumpprivkey abre a carteira e extrai a chave privada que foi gerada pelo comando getnewaddress. N‹o Ž poss’vel que o bitcoind descubra a chave privada a partir da chave pœblica, a menos que ambas estejam armazenadas na carteira.
TIP
O comando dumpprivkey n‹o est‡ gerando uma chave privada a partir de uma chave pœblica, j‡ que isso Ž imposs’vel. O comando simplesmente revela a chave privada que a carteira j‡ conhece e que foi gerada atravŽs do comando getnewaddress.
Voc tambŽm pode usar a ferramenta de linha de comando Bitcoin Explorer (ver [libbitcoin] [libbitcoin])) para gerar e mostrar chaves privadas com os comandos seed, ec-new and ec-to-wif:
4
$ bx seed | bx ec-new | bx ec-to-wif 5J3mBbAH58CpQ3Y5RNJpUKPE6 5J3mBbAH58Cp Q3Y5RNJpUKPE62SQ5tfcvU2Jpb 2SQ5tfcvU2JpbnkeyhfsYB1Jcn nkeyhfsYB1Jcn
Chaves Pœblicas A chave pœblica Ž calculada a partir da chave privada usando uma multiplica•‹o de curva el’ptica, que gerador Ž irrevers’vel: \(K = k * G\) onde k Ž Ž a chave privada, G Ž um ponto constante chamado de ponto gerador e K Ž a chave pœblica resultante. A opera•‹o inversa, conhecida como "encontrando o logaritmo discreto"Ñcalculando k se se voc sabe o K ÑŽ t‹o dif’cil quanto tentar todos os poss’veis valores de k, ou seja, uma busca de for•a bruta. Antes de n—s demonstrarmos como gerar uma chave pœblica a partir de uma chave privada, vamos analisar a criptografia de curva el’ptica em um pouco mais de detalhes.
Explicando a Criptografia de Curva El’ptica A criptografia de curva el’ptica Ž um tipo de criptografia de chave pœblica ou assimŽtrica baseada em um problema logar’timico discreto que Ž expressado pela adi•‹o e multiplica•‹o nos pontos de uma curva el’ptica. Uma curva el’ptica Ž el’ptica Ž um exemplo de uma curva el’ptica, similar ˆ utilizada pelo bitcoin.
5
Figure 2. Uma curva curva el’ptica
O Bitcoin usa uma curva el’ptica espec’fica e um conjunto de constantes matem‡ticas, como definido em um padr‹o chamado secp256k1, estabelecido pelo Instituto Nacional de Padroniza•‹o e Tecnologia (NIST). A curva secp256k1 Ž definida pelas seguintes fun•›es, que produzem uma curva el’ptica: or O mod p (m—dulo de nœmero primo) indica que essa curva est‡ sobre um campo finito de nœmeros primos p tambŽm escrito em formato latex:[\(\mathbb{F}_p\)], onde p = 2 256 Ð 232 Ð 29 Ð 28 Ð 27 Ð 26 Ð 24 Ð 1, um nœmero primo muito grande.
6
Como a curva Ž definida sobre um campo finito de ordem prima ao invŽs de baseada em nœmeros reais, ela parece um padr‹o de pontos espalhados em duas dimens›es, o que a torna dif’cil de ser visualizada. Contudo, a matem‡tica Ž idntica ˆquela de curvas el’pticas sobre nœmeros reais. Como um exemplo, Criptografia de curva el’ptica: visualizando uma curva el’ptica sobre F(p), com p=17 mostra a mesma curva el’ptica sobre um campo muito menor, de ordem prima 17, mostrando um padr‹o de pontos em uma grade. A curva el’ptica secp256k1 pode ser imaginada como um padr‹o muito mais complexo de pontos em uma enorme malha.
Figure 3. Criptografia Criptografia de curva curva el’ptica: visualizando visualizando uma curva curva el’ptica sobre F(p), F(p), com p=17
Ent‹o, por exemplo, a seguir est‡ um ponto P com coordenadas (x,y) que Ž um ponto na curva secp256k1. Voc pode verificar isso por conta pr—pria usando Python: P = (550662630222 (550662630222773436695787 7734366957871889516853432 18895168534326250603453777 62506034537775941755001873 59417550018736038911672924 60389116729240, 0, 3267051002075881697808308 326705100207 58816978083085130507043184 51305070431844712733806592 47127338065924327593890433 4327593890433575733748242 5757337482424) 4)
7
Python 3.4.0 (padr ‹o, Mar 30 2014, 19:23:13) [GCC 4.2.1 Compat ’ vel vel com Apple LLVM 5.1 (clang-503.0.38)] no darwin Digite "help", "copyright", "credits" ou "license" para maiores informa •›es. >>> p = 11579208923731619542357098 1157920892373 16195423570985008687907853 50086879078532699846656405 2699846656405640394575840 6403945758400790883467166 079088346716633 >>> x = 550662630222 550662630222773436695787 7734366957871889516853432 18895168534326250603453777 62506034537775941755001873 59417550018736038911672924 603891167292400 >>> y = 326705100207 326705100207588169780830 5881697808308513050704318 85130507043184471273380659 44712733806592432759389043 24327593890433575733748242 357573374824244 >>> (x ** 3 + 7 - y**2) % p 0
Na matem‡tica de curva el’ptica, existe um ponto chamado "ponto no infinito", que de certo modo corresponde ao papel do 0 em uma adi•‹o. Em computadores, Ž frequentemente representado por x = y = 0 (que n‹o satisfaz a equa•‹o da curva el’ptica, mas Ž um caso isolado que pode ser facilmente verificado). H‡ tambŽm um operador de passe[+], chamado "adi•‹o", que possui umas propriedades similares ˆ adi•‹o tradicional dos nœmeros reais que as crian•as no ensino fundamental aprendem. Dados dois pontos P1 e P2 na curva, h‡ um terceiro ponto P 3= P1 + P2, tambŽm na curva el’ptica. Geometricamente, esse terceiro ponto P 3 Ž calculado ao desenhar uma linha entre P 1e P2. Essa linha far‡ a intersec•‹o com a curva el’ptica exatamente em um lugar adicional. Chame esse ponto P #' = (x,y). Ent‹o reflita no eixo x para obter P 3 = (x, -y). Existem v‡rios casos especiais que explicam a necessidade de um "ponto no infinito." Se P 1 e P2 s‹o o mesmo ponto, a linha "entre" P 1 e P2 deveria estender para ser a tangente na curva no ponto P1. Essa tangente far‡ a intersec•‹o com a curva em um novo ponto exato. Voc pode usar tŽcnicas de c‡lculo para determinar a inclina•‹o da linha tangente. Essas tŽcnicas curiosamente funcionam, mesmo que estejamos restringindo nosso interesse para pontos na curva com duas coordenadas inteiras! Em alguns casos (ex: se P 1 e P2 tm os mesmos valores x mas diferentes valores y), a linha tangente ser‡ exatamente vertical, que no caso P3 = "ponto no infinito". Se P1 Ž o "ponto no infinito", ent‹o a soma P 1 + P2 = P2. De modo similar, se P 2 Ž o ponto no infinito, ent‹o P1 + P2 = P1. Isso mostra como o ponto no infinito faz o papel do 0. De forma que + Ž associativo, que significa que (A + B + C = A + (B + C). O que significa que podemos escrever A + B + C sem parnteses sem qualquer ambiguidade. Agora que definimos adi•‹o, podemos definir multiplica•‹o no modo padr‹o que estende adi•‹o. Para um ponto P na curva el’ptica, se k Ž um nœmero inteiro, ent‹o kP = P + P + P +É + P (k vezes). Note que k Ž algumas vezes confundido como um "expoente" nesse caso.
8
Gerando uma Chave Pœblica Come•ando com uma chave privada na forma de um nœmero k aleatoriamente gerado, o multiplicamos por um ponto predeterminado na curva, chamado de o ponto gerador G gerador G para produzir outro ponto em outro lugar da curva, que ser‡ a chave pœblica K correspondente. correspondente. O ponto gerador Ž especificado como parte do padr‹o secp256k1 e Ž sempre o mesmo para todas as chaves bitcoin: onde k Ž a chave privada, G Ž o ponto gerador e K Ž a chave pœblica resultante, um ponto na curva. Como o ponto gerador Ž sempre o mesmo para todos os usu‡rios bitcoin, uma chave privada k multiplicada por G sempre resultar‡ na mesma chave pœblica K. A rela•‹o entre k e K Ž fixa, mas apenas pode ser calculada em uma dire•‹o, de k para K. ƒ por isso que um endere•o bitcoin (derivado de K) pode ser compartilhado com qualquer um sem que a chave privada (k) do usu‡rio seja revelada.
TIP
Uma chave privada pode ser convertida em uma chave pœblica, mas uma chave pœblica n‹o pode ser convertida de volta em uma chave privada porque a matem‡tica s— funciona em um œnico sentido.
Implementando a multiplica•‹o da curva el’ptica, podemos usar a chave privada k que foi gerada anteriormente e multiplic‡-la pelo ponto gerador G para encontrarmos a chave pœblica K: K = 1E99423A4ED27 1E99423A4ED27608A15A2616A 608A15A2616A2B0E9E52CED33 2B0E9E52CED330AC530EDCC32C 0AC530EDCC32C8FFC6A526AEDD 8FFC6A526AEDD * G
A Chave Pœblica K Ž definida como o ponto K = (x,y): K = (x, y) onde, x = F028892BAD7ED F028892BAD7ED57D2FB57BF33 57D2FB57BF33081D5CFCF6F9E 081D5CFCF6F9ED3D3D7F159C2E D3D3D7F159C2E2FFF579DC341A 2FFF579DC341A y = 07CF33DA18BD734C600B96A72 07CF33DA18BD734C600B96A72BBC4749D5141C BBC4749D5141C90EC8AC328AE5 90EC8AC328AE52DDFE2E505BDB 2DDFE2E505BDB
Para visualizar a multiplica•‹o de um ponto com um nœmero inteiro, usaremos uma curva el’ptica mais simples sobre nœmeros reais reais Ñ lembre-se, a matem‡tica Ž a mesma. mesma. Nosso objetivo Ž descobrir o mœltiplo kG de um ponto gerador G. Isso Ž o mesmo que adicionar G a si mesmo, k vezes seguidas. Nas curvas el’pticas, adicionar um ponto a si mesmo Ž o equivalente a desenhar uma linha tangente no ponto e encontrar onde ela intersecciona novamente a curva, refletindo, ent‹o, o ponto no eixo x. Criptografia de curva el’ptica: Visualizando a multiplica•‹o de um ponto G por um nœmero inteiro k em uma curva el’ptica el’ptica mostra o processo de derivar G, 2G e 4G, enquanto opera•‹o geomŽtrica na curva.
9
TIP
A maior parte das implementa•›es bitcoin utilizam a biblioteca criptogr‡fica OpenSSL para fazer a matem‡tica de curva el’ptica. Por exemplo, para derivar a chave pœblica, Ž utilizada a fun•‹o EC_POINT_mul().
Figure 4. Criptografia Criptografia de curva curva el’ptica: Visualizando Visualizando a multiplica•‹o multiplica•‹o de um ponto ponto G por um nœmero nœmero inteiro k em uma curva el’ptica
Endere•os Bitcoin Um endere•o bitcoin Ž uma string de d’gitos e caracteres que pode ser compartilhada com qualquer pessoa que queira lhe enviar dinheiro. Os endere•os produzidos a partir de chaves pœblicas consistem 10
em uma string de nœmeros e letras, iniciando com o d’gito "1". Aqui est‡ um exemplo de um endere•o bitcoin: 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy
O endere•o bitcoin Ž o que mais comumente aparece como "destinat‡rio" dos fundos em uma transa•‹o. Se f™ssemos comparar uma transa•‹o bitcoin a um cheque de papel, o endere•o bitcoin Ž o benefici‡rio, que Ž o que escrevemos na linha "ˆ ordem de". Num cheque de papel, aquele benefici‡rio pode algumas vezes ser o nome de um possuidor de conta banc‡ria, mas pode tambŽm incluir corpora•›es, institui•›es, e atŽ mesmo dinheiro. E por cheques de papel n‹o precisarem especificar uma conta, ao invŽs disso, usam um nome abstrato como receptor dos fundos, isto torna cheques de papel muito flex’veis como instrumentos de pagamento. As transa•›es bitcoin usam uma abstra•‹o similar - o endere•o bitcoin - para torn‡-las muito flex’veis. Um endere•o bitcoin pode representar outra coisa, como um script de pagamento, como veremos em [p2sh] [p2sh].. Por hora, vamos examinar o caso simples, um endere•o bitcoin que representa uma chave pœblica, e Ž derivado dela. O endere•o bitcoin Ž derivado da chave pœblica atravŽs do uso de hashing criptogr‡fico de uma via. Um "algoritmo de hashing", ou simplesmente "algoritmo de hash" Ž uma fun•‹o injetiva (de uma via) que produz uma impress‹o digital ou "hash" a partir de uma entrada de tamanho arbitr‡rio. Fun•›es de hash criptogr‡ficas s‹o extensivamente usadas em bitcoin: nos endere•os bitcoin, nos endere•os de scripts, e no algoritmo de prova-de-trabalho da minera•‹o. Os algoritmos utilizados para produzir um endere•o bitcoin a partir de uma chave pœblica s‹o Secure Hash Algorithm (SHA) e o RACE Integrity Primitives Evaluation Message Digest (RIPEMD), especificamente SHA256 e RIPEMD160. A partir da chave pœblica K, n—s computamos o hash SHA256, e ent‹o computamos o hash RIPEMD160 do resultado, produzindo um nœmero de 160 bits (20 bytes). onde K Ž a chave pœblica e A Ž o endere•o bitcoin resultante. TIP
Um endere•o bitcoin n‹o Ž a mesma coisa que uma chave pœblica. Endere•os bitcoin s‹o derivados a partir de uma chave pœblica utilizando-se uma fun•‹o de sentido œnico.
Os endere•os bitcoin s‹o quase sempre apresentados aos usu‡rios em uma codifica•‹o chamada "Base58Check" (veja Codifica•‹o Base58 e Base58Check), Base58Check ), que usa 58 caracteres (um sistema numŽrico de Base58) e um checksum para ajudar a legibilidade humana, evitar ambiguidade, e proteger contra erros em transcri•‹o e digita•‹o de endere•os. O Base58Check tambŽm Ž utilizado de v‡rias outras formas no bitcoin, sempre que h‡ a necessidade de um usu‡rio ler e transcrever corretamente um nœmero, tal como um endere•o bitcoin, uma chave privada, uma chave encriptada, ou um hash de um script. Na pr—xima se•‹o, examinaremos a mec‰nica da codifica•‹o e decodifica•‹o Base58Check, e as represetna•›es resultantes. Chave pœblica para endere•o bitcoin: convers‹o de uma chave pœblica em um endere•o bitcoin ilustra bitcoin ilustra a convers‹o de uma chave pœblica em um endere•o bitcoin.
11
Figure 5. Chave pœblica pœblica para endere•o endere•o bitcoin: convers‹o convers‹o de uma chave chave pœblica em um endere•o endere•o bitcoin
Codifica•‹o Base58 e Base58Check A fim de representar nœmeros grandes de uma forma compacta, utilizando poucos s’mbolos, muitos sistemas de computador utilizam uma mistura alfa-nœmerica com base (ou raiz) maior do que 10. Por 12
exemplo, enquanto o sistema decimal tradicional utiliza os 10 numerais de 0 a 9, o sistema hexadecimal utiliza 16, com as letras de A atŽ F como os seis s’mbolos adicionais. Um nœmero representado no formato hexadecimal Ž menor ao equivalente em decimal. Ainda mais compacto, a representa•‹o Base64 utiliza 26 letras em caixa baixa, 26 letras em caixa alta, 10 numerais e mais dois caracteres como "+" e "/" para transmitir dados bin‡rios sobre m’dias baseadas em texto, como o email. A Base64 Ž normalmente utilizada para anexar arquivos bin‡rios em emails. A Base58 Ž a codifica•‹o bin‡ria baseada em texto desenvolvida para o bitcoin e utilizada e muitas outras criptomoedas. Ela oferece um equil’brio entre uma representa•‹o compacta, leitura e detec•‹o de erro e preven•‹o. A Base58 Ž um subconjunto da Base64, utilizando caixa alta, caixa baixa, letras e nœmeros porŽm omitindo alguns caracteres que s‹o frequentemente confundidos e podem parecer idnticos quando mostrados com certas fontes. Sendo espec’fico, a Base58 Ž a Base64 sem o 0 (nœmero zero), O (o maiœsculo), l (ele minœsculo), I (i maiœsculo), e os s’mbolos "\+" e "/". Ou, mais simplesmente, Ž um conjunto de letras maiœsculas e minœsculas mais os nœmeros, sem os quatro caracteres mencionados. mencionados. Example 1. O alfabeto alfabeto Base58 do bitcoin bitcoin
123456789ABCDEFGHJKLMNPQRS 123456789ABCD EFGHJKLMNPQRSTUVWXYZabcdef TUVWXYZabcdefghijkmnopqrst ghijkmnopqrstuvwxyz uvwxyz
Para acrescentar seguran•a extra contra erros de digita•‹o ou transcri•‹o, o Base58Check Ž um formato de codifica•‹o Base58, frequentemente usado em bitcoin, que tem um c—digo de verifica•‹o de erros embutido. O checksum Ž composto de quatro bytes adicionais, acrescidos ao final dos dados sendo codificados. O checksum Ž derivado do hash dos dados codificados e, portanto, poder ser usado para detectar e prevenir erros de transcri•‹o e digita•‹o. Quando o software decodificador se depara com um c—digo Base58Check, ele calcula o checkum dos dados e o compara com o checksum inclu’do no c—digo. Se os dois n‹o corresponderem, tem-se uma indica•‹o de que o erro foi introduzido e o dado Base58Check Ž inv‡lido. Por exemplo, isso previne um endere•o bitcoin mal digitado de ser aceito pelo software da carteira como um destino v‡lido, um erro que, do contr‡rio, resultaria na perda de fundos. Para converter dados (um nœmero) no formato Base58Check, primeiro adicionamos um prefixo aos dados, chamados de "byte de vers‹o", que serve para identificar facilmente o tipo de dado codificado. Por exemplo, no caso de um endere•o bitcoin, o prefixo Ž zero (0x00 em hexa), enquanto o prefixo usado para codificar uma chave privada Ž 128 (0x80 em hexa). Uma lista de prefixos comuns Ž apresentada em Base58Check prefixo de vers‹o e exemplos de resultados codificados . Em seguida, computamos o checksum "duplo-SHA", o que significa que aplicamos o algoritmo de hash SHA256 duas vezes no resultado anterior (prefixo e dados): checksum = SHA256(SHA25 SHA256(SHA256(prefix+data 6(prefix+data)) ))
Pegamos apenas os primeiros quatro bytes do hash de 32 bytes resultante (hash do hash). Esses quatro bytes servem como c—digo de verifica•‹o verifica•‹o de erro, ou checksum. O checksum Ž concatenado ao final. O resultado Ž composto de trs itens: um prefixo, os dados, e um checksum. Esse resultado Ž codificado 13
usando o alfabeto Base58 descrito previamente. Base58Check encoding: um formato para codificar dados do bitcoin de maneira inequ’voca, versionada e verificada. ilustra o processo de codifica•‹o Base58Check.
Figure 6. Base58Check Base58Check encoding: um formato formato para para codificar dados do bitcoin de maneira maneira inequ’voca, inequ’voca, versionada e verificada.
No bitcoin, a maior parte dos dados apresentados ao usu‡rio Ž codificada em Base58Check para torn‡los mais compactos, f‡ceis de ler e para facilitar a detec•‹o de erros. A vers‹o de prefixo na codifica•‹o Base58Check Ž usada para criar formatos facilmente distingu’veis, que quando s‹o codificados em Base58 contŽm caracteres espec’ficos no in’cio do payload codificado em Base58Check. Esses caracteres facilitam a identifica•‹o pelas pessoas do tipo de dado que est‡ sendo codificado e como utiliz‡-lo. Isso Ž o que diferencia, por exemplo, um endere•o bitcoin codificado em Base58Check que come•a com o nœmero 1 de uma chave privada codificada em Base58Check no formato WIF que inicia com o nœmero 5. Alguns exemplos de vers‹o de prefixo e os caracteres Base58 resultantes s‹o demonstrados em Base58Check prefixo de vers‹o e exemplos de resultados codificados . Table 1. Base58Check prefixo de vers‹o e exemplos de resultados codificados
14
Type
Prefixo de vers‹o (hex)
Base58 prefixo de resultado
Endere•o Bitcoin
0x00
1
Endere•o Pay-to-Script-Hash
0x05
3
Endere•o Bitcoin Testnet
0x6F
m ou n
Chave Privada WIF
0x80
5 , K ou L
Chave Privada Criptografada em 0x0142 BIP38
6P
Chave Pœblica Estendida em BIP32
x p ub
0x0488B21E
Vamos ver o processo completo de cria•‹o de um endere•o bitcoin, desde a chave privada, atŽ a chave pœblica (um ponto na curva el’ptica), para um endere•o que sofre hash duplo e, finalmente, a codifica•‹o Base58Check. O c—digo C++ em Criando um endere•o bitcoin codificado em Base58Check a partir de uma chave privada demonstra privada demonstra todo o processo passo-a-passo, desde a chave privada atŽ o endere•o bitcoin codificado em Base58Check. O c—digo de exemplo usa a livraria libbitcoin que foi apresentada em [alt_libraries] [alt_libraries] para para algumas fun•›es auxiliares.
15
Example 2. Criando Criando um endere•o bitcoin codificado codificado em Base58Check a partir de uma chave chave privada
#include oin.hpp> int main() { // Private secret key. bc::ec_secret bc::ec_secr et secret; bool success = bc::decode_ bc::decode_base16(secret base16(secret,, "038109007313a5807b2eccc082c8c3fbb988a973cacf1a7df9ce725c31b14776"); assert(success); // Get public key. bc::ec_pointt public_key = bc::secret_to bc::ec_poin bc::secret_to_public_key(s _public_key(secret); ecret); std::cout << "Public key: " << bc::encode_h bc::encode_hex(public_key ex(public_key)) << std::endl; // Create Bitcoin address. // Normally you can use: // bc::payment_a bc::payment_address ddress payaddr; // bc::set_publi bc::set_public_key(payaddr c_key(payaddr,, public_key); // const std::string address = payaddr.encod payaddr.encoded(); ed(); // Compute hash of public key for P2PKH address. const bc::short_ha bc::short_hash sh hash = bc::bitcoin_s bc::bitcoin_short_hash(pub hort_hash(public_key); lic_key);
bc::data_chunk unencoded_a bc::data_chunk unencoded_address; ddress; // Reserve 25 bytes // [ version:1 ] // [ hash:20 ] // [ checksum:4 ] unencoded_address.reserve(25); // Version byte, 0 is normal BTC address (P2PKH). unencoded_address.push_back(0); // Hash data bc::extend_data(unencode bc::extend_ data(unencoded_address, d_address, hash); // Checksum is computed by hashing data, and adding 4 bytes from hash. bc::append_checksum(unencoded_address); // Finally we must encode the result in Bitcoin's base58 encoding assert(unencoded_address assert(unen coded_address.size() .size() == 25); const std::string address = bc::encode_ba bc::encode_base58(unencode se58(unencoded_address); d_address); std::cout << "Address: " << address << std::endl; return 0;
}
O c—digo usa uma chave privada prŽ-definida, de maneira que ele produz o mesmo endere•o bitcoin
16
cada vez que Ž executado, como demonstrado em Compilando e executando o c—digo addr. addr . Example 3. Compilando Compilando e executando executando o c—digo addr
# Compila o c —digo addr.cpp $ g++ -o addr addr.cpp $(pkg-config --cflags --libs libbitcoin) # Roda o execut ‡vel addr $ ./addr Public key: 0202a4066242 0202a406624211f2abbdc68da 11f2abbdc68da3df929f938c33 3df929f938c3399dd79fac1b5 99dd79fac1b51b0e4ad1d26a4 1b0e4ad1d26a47aa 7aa Address: 1PRTTaJesdNov 1PRTTaJesdNovgne6Ehcdu1fpE gne6Ehcdu1fpEdX7913CK dX7913CK
Formatos de Chave Tanto as chaves privadas quanto as chaves pœblicas podem ser representadas em diversos formatos diferentes. Todas essas representa•›es codificam o mesmo nœmero, apesar de elas parecerem ser diferentes. Esses formatos s‹o primariamente usados para tornar f‡cil para as pessoas lerem e transcreverem transcrevere m as chaves sem que cometam erros. Formatos de chave privada
A chave privada pode ser representada em v‡rios formatos diferentes, os quais todos correspondem ao mesmo nœmero de 256 bits. A Representa•›es de chave privada (formatos de codifica•‹o) demonstra trs formatos comumente usados para representar chaves privadas. Table 2. Representa•›es de chave privada (formatos de codifica•‹o) Tipo
Prefixo
Descri•‹o
Hex
Nenhum
64 d’gitos hexadecimais
WIF
5
Codifica•‹o em Base58Check: Base58 com prefixo de vers‹o de 128 e soma de verifica•‹o (checksum) de 32-bit
Comprimida-WIF
K ou L
Como acima, com a adi•‹o do sufixo 0x01 antes da codifica•‹o
Exemplo: Mesma chave, diferentes formatos demonstra formatos demonstra a chave privada nesses trs formatos. Table 3. Exemplo: Mesma chave, diferentes formatos Formato
Chave Privada
Hex
1e99423a4ed27608a15a2616a2b0e9e52ced330ac53 0edcc32c8ffc6a526aedd
17
Formato
Chave Privada
WIF
5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2Jpbnk eyhfsYB1Jcn
Comprimida-WIF
KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf 6YwgdGWZgawvrtJ
Todas essas representa•›es s‹o diferentes maneiras de se exibir o mesmo nœmero, a mesma chave privada. Elas parecem diferente, mas qualquer um desses formatos pode ser facilmente convertido para qualquer outro formato. N—s usamos o comando wif-to-ec do Bitcoin Explorer (ver [libbitcoin] [libbitcoin])) para demonstrar que ambas as chaves WIF representam a mesma chave privada: $ bx wif-to-ec 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2J 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1J pbnkeyhfsYB1Jcn cn 1e99423a4ed27608a15a2616a 1e99423a4ed2 7608a15a2616a2b0e9e52ced33 2b0e9e52ced330ac530edcc32c 0ac530edcc32c8ffc6a526aedd 8ffc6a526aedd $ bx wif-to-ec KxFC1jmwwCoA KxFC1jmwwCoACiCAWZ3eXa96m CiCAWZ3eXa96mBM6tb3TYzGmf6 BM6tb3TYzGmf6YwgdGWZgawvrt YwgdGWZgawvrtJJ 1e99423a4ed27608a15a2616a 1e99423a4ed2 7608a15a2616a2b0e9e52ced33 2b0e9e52ced330ac530edcc32c 0ac530edcc32c8ffc6a526aedd 8ffc6a526aedd
Decodificando do Base58Check
Os comandos do Bitcoin Explorer (ver [libbitcoin] [libbitcoin])) tornam f‡cil a escrita de scripts shell e "pipes" de linha de comando que manipulam as chaves, endere•os e transa•›es bitcoin. Voc pode usar o Bitcoin Explorer para decodificar o formato Base58Check na linha de comando. N—s usamos o comando base58check-decode para decodificar a chave n‹o-comprimida: $ bx base58checkbase58check-decode decode 5J3mBbAH58Cp 5J3mBbAH58CpQ3Y5RNJpUKPE6 Q3Y5RNJpUKPE62SQ5tfcvU2Jp 2SQ5tfcvU2JpbnkeyhfsYB1Jc bnkeyhfsYB1Jcnn wrapper { checksum 4286807748 payload 1e99423a4ed27 1e99423a4ed27608a15a2616a2 608a15a2616a2b0e9e52ced330 b0e9e52ced330ac530edcc32c8 ac530edcc32c8ffc6a526aedd ffc6a526aedd version 128 }
O resultado contŽm a chave como a carga, o prefixo 128 Note que o "payload" da chave comprimida Ž acrescido com o sufixo 01, sinalizando que a chave pœblica derivada ser‡ comprimida.
18
$ bx base58checkbase58check-decode decode KxFC1jmwwCoA KxFC1jmwwCoACiCAWZ3eXa96m CiCAWZ3eXa96mBM6tb3TYzGmf BM6tb3TYzGmf6YwgdGWZgawvr 6YwgdGWZgawvrtJ tJ wrapper { checksum 2339607926 payload 1e99423a4ed27 1e99423a4ed27608a15a2616a2 608a15a2616a2b0e9e52ced330 b0e9e52ced330ac530edcc32c8 ac530edcc32c8ffc6a526aedd ffc6a526aedd01 01 version 128 }
Codificando de hex para Base58Check
Para codificar em Base58Check (o oposto do comando anterior), n—s usamos o comando base58checkencode do Bitcoin Explorer (ver [libbitcoin] [libbitcoin])) e fornecemos a chave privada em hexadecimal, seguida pelo Wallet Import Format Format (WIF) com prefixo de vers‹o 128: bx base58check base58check-encode -encode 1e99423a4ed2 1e99423a4ed27608a15a2616 7608a15a2616a2b0e9e52ced3 a2b0e9e52ced330ac530edcc32 30ac530edcc32c8ffc6a526aed c8ffc6a526aeddd --version 128 5J3mBbAH58CpQ3Y5RNJpUKPE6 5J3mBbAH58Cp Q3Y5RNJpUKPE62SQ5tfcvU2Jpb 2SQ5tfcvU2JpbnkeyhfsYB1Jcn nkeyhfsYB1Jcn
Codificando de hex (chave comprimida) para Base58Check
Para codificar em Base58Check como uma chave privada "compactada" (veja Chaves privadas comprimidas), comprimidas ), n—s concatenamos o sufixo 01 ˆ chave hexa e em seguida codificamos da forma descrita acima: $ bx base58checkbase58check-encode encode 1e99423a4ed27608a15a2616a 1e99423a4ed2 7608a15a2616a2b0e9e52ced33 2b0e9e52ced330ac530edcc32c 0ac530edcc32c8ffc6a526aedd 8ffc6a526aedd01 01 --version 128 KxFC1jmwwCoACiCAWZ3eXa96m KxFC1jmwwCoA CiCAWZ3eXa96mBM6tb3TYzGmf6 BM6tb3TYzGmf6YwgdGWZgawvrt YwgdGWZgawvrtJJ
O formato comprimida-WIF resultante come•a com um "K". Isso denota que a chave privada contida tem um sufixo de "01" e ser‡ usada para produzir apenas chaves pœblicas comprimidas (ver Chaves pœblicas comprimidas). comprimidas ). Formatos de chave pœblica
As chaves pœblicas tambŽm s‹o apresentadas de diferentes maneiras, principalmente como chaves pœblicas comprimidas ou n‹o-comprimidas. Como vimos anteriormente, a chave pœblica Ž um ponto na curva el’ptica que consiste de um par de coordenadas (x,y). Ela geralmente Ž apresentada com o prefixo 04 seguida por dois nœmeros de 256 bits, um para a coordenada x do ponto, e outro para a coordenada y. O prefixo 04 Ž usado para distinguir as chaves pœblicas n‹o-comprimidas das chaves pœblicas comprimidas que come•am com 02 ou 03. Aqui est‡ a chave pœblica gerada pela chave privada que n—s criamos anteriormente, mostrada como 19
as coordenadas x e y: x = F028892BAD7ED F028892BAD7ED57D2FB57BF33 57D2FB57BF33081D5CFCF6F9E 081D5CFCF6F9ED3D3D7F159C2E D3D3D7F159C2E2FFF579DC341A 2FFF579DC341A y = 07CF33DA18BD734C600B96A72 07CF33DA18BD734C600B96A72BBC4749D5141C BBC4749D5141C90EC8AC328AE5 90EC8AC328AE52DDFE2E505BDB 2DDFE2E505BDB
Aqui est‡ a mesma chave pœblica mostrada como um nœmero de 520 bits (130 d’gitos hexadecimais) com o prefixo 04 seguido pelas coordenadas x e y, como, por exemplo, 04 x y: K = 04F028892BAD7 04F028892BAD7ED57D2FB57BF ED57D2FB57BF33081D5CFCF6F 33081D5CFCF6F9ED3D3D7F159C 9ED3D3D7F159C2E2FFF579DC34 2E2FFF579DC341A07CF33DA18BD734C600B9 cr?>07CF33DA 18BD734C600B96A72BBC4749D5 6A72BBC4749D5141C90EC8AC32 141C90EC8AC328AE52DDFE2E50 8AE52DDFE2E505BDB 5BDB
Chaves pœblicas comprimidas
As chaves pœblicas comprimidas come•aram a ser usadas no bitcoin para reduzirem o tamanho das transa•›es e para conservarem o espa•o em disco que os nodos usam para armazenar a blockchain, que Ž o banco de dados do bitcoin. A maioria das transa•›es incluem a chave pœblica, que Ž necess‡ria para se validar as credenciais do dono e poder gastar os bitcoins. Cada chave pœblica requer 520 bits (prefixo \+ x \+ y), que quando s‹o multiplicados por v‡rias centenas de transa•›es por bloco, ou dezenas de milhares de transa•›es por dia, acabam sendo uma grande quantidade de dados adicionais na blockchain. Como n—s vimos na se•‹o Chaves Pœblicas, Pœblicas, uma chave pœblica Ž um ponto (x,y) em uma curva el’ptica. Como a curva expressa uma fun•‹o matem‡tica, um ponto na curva representa uma solu•‹o para a equa•‹o e, portanto, se n—s soubermos a coordenada x , n—s poderemos calcular a coordenada y ao resolver a equa•‹o y 2 mod p = (x3 + 7) mod p. Isso nos permite armazenar somente a coordenada x do do ponto da chave pœblica, omitindo a coordenada y e reduzindo o tamanho da chave e o espa•o necess‡rio para armazen‡-la em 256 bits. Uma redu•‹o de quase 50% do tamanho de cada transa•‹o economiza a utiliza•‹o de muito espa•o ao longo do tempo! Enquanto as chaves pœblicas n‹o-comprimidas tem um prefixo 04, as chaves pœblicas comprimidas come•am com os prefixos 02 ou 03. Existe um motivo pelo qual s— existem dois prefixos poss’veis: como o lado esquerdo da equa•‹o Ž y 2, isso significa que a solu•‹o para y Ž uma raiz quadrada, que pode ter um valor positivo ou negativo. Visualmente, isso significa que a coordenada y resultante pode estar acima ou abaixo do eixo x. Como voc pode ver no gr‡fico da curva el’ptica em Uma curva el’ptica,, a curva Ž simŽtrica, sendo refletida pelo eixo x, como se fosse um espelho. Ent‹o, enquanto el’ptica n—s podemos omitir a coordenada y, n—s temos que armazenar o sinal do y (positivo ou negativo), ou, em outras palavras, n—s temos que nos lembrar se ele estava acima ou abaixo do eixo x, pois cada uma dessas op•›es representa um ponto diferente e uma chave pœblica diferente. Quando se calcula a curva el’ptica em aritmŽtica bin‡ria no campo finito da ordem prima p, a coordenada y ou Ž par ou Ž ’mpar, o que corresponde c orresponde ao sinal positivo/negativo explicado anteriormente. Portanto, para distinguir entre os dois valores poss’veis de y, y, n—s armazenamos a chave pœblica comprimida com o prefixo 02 se o y Ž par, e 03 se ele Ž ’mpar, permitindo que o software deduza corretamente a coordenada y a partir da coordenada x e descomprima da chave pœblica para as coordenadas completas do ponto. A compress‹o de chave pœblica Ž ilustrada em Compress‹o de chave pœblica. pœblica . 20
Figure 7. Compress‹o Compress‹o de chave pœblica pœblica
Aqui est‡ a mesma chave pœblica gerada anteriormente, exibida como uma chave pœblica comprimida armazenada em 264 bits (66 d’gitos hexadecimais) com o prefixo 03 indicando que a coordenada y Ž ’mpar: 21
K = 03F028892BAD7 03F028892BAD7ED57D2FB57BF ED57D2FB57BF33081D5CFCF6F 33081D5CFCF6F9ED3D3D7F159C 9ED3D3D7F159C2E2FFF579DC34 2E2FFF579DC341A 1A
Essa chave pœblica comprimida corresponde ˆ mesma chave privada, significando que ela Ž gerada a partir da mesma chave privada. Entretanto, ela parece ser diferente da chave pœblica n‹o-comprimida. ƒ importante citar que, se n—s convertermos essa chave pœblica comprimida para um endere•o bitcoin usando uma fun•‹o de hash duplo (RIPEMD160(SHA256(K))) ela ir‡ produzir um endere•o bitcoin diferente. Isso pode parecer confuso, porque isso significa que uma chave privada Ž capaz de produzir uma chave pœblica que Ž expressa em dois formatos diferentes (comprimido e n‹o-comprimido), que produzem dois endere•os bitcoin diferentes. Entretanto, a chave privada Ž idntica para ambos os endere•os bitcoin. As chaves pœblicas comprimidas est‹o gradualmente se tornando o padr‹o nos clientes bitcoins, o que est‡ causando um impacto significativo na redu•‹o do tamanho das transa•›es e, portanto, da blockchain. Entretanto, nem todos os clientes tem suportes j‡ tem suporte ˆs chaves pœblicas comprimidas. Os clientes mais modernos que suportam as chaves pœblicas comprimidas tem que lidar com as transa•›es vindas de clientes antigos que n‹o suportam as chaves pœblicas comprimidas. Isso Ž especialmente importante quando uma aplica•‹o de carteira est‡ importanto chaves privadas a partir de outra aplica•‹o de carteira bitcoin, pois a carteira nova precisa escanear a blockchain para achar as transa•›es correspondentes a essas chaves importadas. Quais endere•os bitcoins a carteira bitcoin deve escanear? Os endere•os bitcoin produzidos pelas chaves pœblicas n‹o-comprimidas, ou os endere•os bitcoins produzidos pelas chaves pœblicas comprimidas? Ambos s‹o endere•os bitcoin v‡lidos, e podem ser assinados pela chave privada, mas eles s‹o endere•os diferentes! diferentes! Para resolver esse problema que acontece quando as chaves privadas s‹o exportadas a partir de uma carteira, o Wallet Import Format que Ž usado para represent‡-las Ž implementado de maneira diferente nas carteiras bitcoin mais modernas, para indicar que essas chaves privadas foram usadas para produzir chaves pœblicas comprimidas e, portanto, endere•os bitcoin comprimidos . Isso permite que a carteira que as est‡ importando possa distinguir as chaves privadas que se originam das carteiras antigas e das modernas, e buscar a blockchain pelas transa•›es com endere•os bitcoin correspondendo ˆs chaves pœblicas n‹o-comprimidas ou comprimidas, respectivamente. N—s iremos aprender como isso funciona em maiores detalhes, na pr—xima se•‹o. Chaves privadas comprimidas
Ironicamente, o termo "chave privada comprimida" pode confundir, pois quando uma chave privada Ž exportada como uma chave comprimida-WIF, na verdade ela Ž um byte maior do que uma chave privada "n‹o-comprimida". Isso acontece porque ela tem o sufixo 01 adicional, o que significa que ela vem de numa carteira mais nova e que s— deveria ser usado para produzir chaves pœblicas comprimidas. As chaves privadas n‹o s‹o comprimidas e n‹o h‡ como comprimi-las. O termo "chave privada comprimida" realmente quer dizer "chave privada a partir da qual as chaves pœblicas comprimidas devem ser derivadas", enquanto o termo "chave privada n‹o-comprimida" quer dizer "chave privada a partir da qual as chaves pœblicas n‹o-comprimidas devem ser derivadas". Voc s— deve se referir ao formato de exporta•‹o como "comprimida-WIF" ou "WIF" e, para evitar maiores confus›es, evite se referir ˆ chave privada como "comprimida".
22
Lembre-se que esses formatos n‹o s‹o intercambi‡veis. Em uma carteira moderna que implementa as chaves pœblicas comprimidas, as chaves privadas s— ser‹o exportadas como comprimidas-WIF (com um prefixo K ou L). Se a carteira Ž uma implementa•‹o antiga e n‹o usa chaves pœblicas comprimidas, as chaves s— ser‹o exportadas como WIF (com o prefixo 5). O objetivo Ž sinalizar para a carteira que est‡ importando essas chaves privadas se ela precisa pesquisar na blockchain as chaves pœblicas comprimidas ou n‹o-comprimidas e os endere•os. Se uma carteira bitcoin Ž capaz de implementar chaves pœblicas comprimidas, ela ir‡ usar esse tipo de chave em todas as transa•›es. As chaves privadas na carteira ser‹o usadas para derivar os pontos de chave pœblica na curva, que ser‹o comprimidas. As chaves pœblicas comprimidas ser‹o usadas para produzir endere•os bitcoin, que ser‹o usados nas transa•›es. Quando se exporta chaves privadas a partir de uma carteira mais moderna, que implementa as chaves pœblicas comprimidas, o Wallet Import Format Ž modificado, com a adi•‹o de um sufixo 01 de um byte para chave privada. A chave privada resultante, codificada em Base58Check, Ž chamada de "Comprimida WIF" e inicia com a letra K ou L, ao invŽs de iniciar com o nœmero "5", que Ž o que acontece com as chaves codificadas em WIF (n‹o-comprimidas) das carteiras mais antigas. Exemplo: Mesma chave, diferentes formatos mostra formatos mostra a mesma chave, codificada nos formatos WIF e Comprimida-WIF. Table 4. Exemplo: Mesma chave, diferentes formatos Formato
Chave Privada
Hex
1E99423A4ED27608A15A2616A2B0E9E52CED330A C530EDCC32C8FFC6A526AEDD
WIF
5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2Jpbnk eyhfsYB1Jcn
Comprimida-Hex
1E99423A4ED27608A15A2616A2B0E9E52CED330A C530EDCC32C8FFC6A526AEDD_01_
Comprimida-WIF
KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf 6YwgdGWZgawvrtJ
TIP
O termo "chaves privadas comprimidas" Ž um termo mal empregado. Elas n‹o s‹o comprimidas; ao invŽs disso, o formato comprimida-WIF significa que elas s— deveriam ser usadas para derivar chaves pœblicas comprimidas e seus endere•os bitcoins correspondentes. Ironicamente, uma chave privada "comprimida-WIF" Ž um byte maior porque ela tem adicionalmente o sufixo 01 para distingui-la de uma chave "n‹ocomprimida".
Implementando Chaves e Endere•os em Python A livraria bitcoin mais completa em Python Ž a pybitcointools pybitcointools feita feita pelo Vitalik Buterin. Em Gera•‹o de chaves e endere•os e formata•‹o com a livraria pybitcointools , n—s usamos a livraria pybitcointools
23
(importada como "bitcoin") para gerar e exibir as chaves e endere•os em v‡rios formatos. Example 4. Gera•‹o Gera•‹o de chaves e endere•os e formata•‹o formata•‹o com a livraria livraria pybitcointool pybitcointoolss
import bitcoin # Generate a random private key valid_private_key valid_private _key = False while not valid_privat valid_private_key: e_key: private_key = bitcoin.rand bitcoin.random_key() om_key() decoded_private_key decoded_pri vate_key = bitcoin.decod bitcoin.decode_privkey(pri e_privkey(private_key, vate_key, 'hex') valid_private_key valid_priva te_key = 0 < decoded_priv decoded_private_key ate_key < bitcoin.N print "Private Key (hex) is: ", private_key print "Private Key (decimal) is: ", decoded_pri decoded_private_key vate_key # Convert private key to WIF format wif_encoded_private_key wif_encoded_p rivate_key = bitcoin.encod bitcoin.encode_privkey(dec e_privkey(decoded_private oded_private_key, _key, 'wif') print "Private Key (WIF) is: ", wif_encoded_p wif_encoded_private_key rivate_key # Add suffix "01" to indicate a compressed private key compressed_private_key compressed_pr ivate_key = private_key + '01' print "Private Key Compressed (hex) is: ", compressed_pr compressed_private_key ivate_key # Generate a WIF format from the compressed private key (WIF-compressed) (WIF-compressed) wif_compressed_private_key wif_compresse d_private_key = bitcoin.enco bitcoin.encode_privkey( de_privkey( bitcoin.decode_privkey(c bitcoin.dec ode_privkey(compressed_pri ompressed_private_key, vate_key, 'hex'), 'wif') print "Private Key (WIF-Compre (WIF-Compressed) ssed) is: ", wif_compressed_private_key wif_compressed_private_key # Multiply the EC generator point G with the private key to get a public key point public_key = bitcoin.fast_ bitcoin.fast_multiply(bitc multiply(bitcoin.G, oin.G, decoded_priv decoded_private_key) ate_key) print "Public Key (x,y) coordinates is:", public_key # Encode as hex, prefix 04 hex_encoded_public_key hex_encoded_p ublic_key = bitcoin.enco bitcoin.encode_pubkey(pub de_pubkey(public_key,'hex lic_key,'hex') ') print "Public Key (hex) is:", hex_encoded_public_key # Compress public key, adjust prefix depending on whether y is even or odd (public_key_x,, public_key_y) = public_key (public_key_x if (public_key_y % 2) == 0: compressed_prefix compressed_ prefix = '02' else: compressed_prefix compressed_ prefix = '03' hex_compressed_public_key hex_compresse d_public_key = compressed_pr compressed_prefix efix + bitcoin.enco bitcoin.encode(public_key de(public_key_x, _x, 16) print "Compressed Public Key (hex) is:", hex_compressed_public_key hex_compressed_public_key # Generate bitcoin address from public key
24
print "Bitcoin Address (b58check) is:", bitcoin.pubkey_to_address(public_ bitcoin.pubkey_to_address(public_key) key) # Generate compressed bitcoin address from compressed public key print "Compressed Bitcoin Address (b58check) is:", \ bitcoin.pubkey_to_address(hex_compressed_public_key)
Executando key-to-address-e key-to-address-ecc-example.py cc-example.py mostra mostra o output ap—s executar esse c—digo. Example 5. Executando Executando key-to-address-ecc-example.p key-to-address-ecc-example.py y
Um script demonstrado a matem‡tica da curva el’ptica usada para as chaves bitcoin Ž outro exemplo, usando a livraria Python ECDSA para a matem‡tica da curva el’ptica e sem usar quaisquer livrarias bitcoin especializadas. Example 6. Um script demonstrado demonstrado a matem‡tica da curva curva el’ptica usada para as chaves bitcoin bitcoin
import ecdsa import os from ecdsa.util import string_to_number, number_to_string # secp256k1, http://www.oi http://www.oid-info.com/ge d-info.com/get/1.3.132.0.1 t/1.3.132.0.100 _p = 0xFFFFFFFFFFF 0xFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFEFFFFFC FFFFFFEFFFFFC2FL 2FL _r = 0xFFFFFFFFFFF 0xFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFEBAAE FFFFFFFFEBAAEDCE6AF48A03BB DCE6AF48A03BBFD25E8CD03641 FD25E8CD0364141L 41L _b = 0x00000000000 0x00000000000000000000000 0000000000000000000000000 00000000000000000000000000 00000000000000000000000000 000000000000007L 07L _a = 0x00000000000 0x00000000000000000000000 0000000000000000000000000 00000000000000000000000000 00000000000000000000000000 000000000000000L 00L _Gx = 0x79BE667EF9 0x79BE667EF9DCBBAC55A062 DCBBAC55A06295CE870B07029 95CE870B07029BFCDB2DCE28D9 BFCDB2DCE28D959F2815B16F81 59F2815B16F81798L 798L _Gy = 0x483ada7726 0x483ada7726a3c4655da4fb a3c4655da4fbfc0e1108a8fd1 fc0e1108a8fd17b448a6855419 7b448a68554199c47d08ffb10d 9c47d08ffb10d4b8L 4b8L curve_secp256k1 curve_secp256 k1 = ecdsa.ellipt ecdsa.ellipticcurve.Curve iccurve.CurveFp(_p, Fp(_p, _a, _b) generator_secp256k1 generator_sec p256k1 = ecdsa.ellipti ecdsa.ellipticcurve.Point ccurve.Point(curve_secp25 (curve_secp256k1, 6k1, _Gx, _Gy, _r) oid_secp256k1 = (1, 3, 132, 0, 10) SECP256k1 = ecdsa.curves ecdsa.curves.Curve("SECP2 .Curve("SECP256k1", 56k1", curve_secp25 curve_secp256k1, 6k1, generator_se generator_secp256k1, cp256k1, oid_secp256k1) ec_order = _r curve = curve_secp25 curve_secp256k1 6k1 generator = generator_se generator_secp256k1 cp256k1 def random_secret(): random_secret(): convert_to_int convert_to_ int = lambda array: int("".join( int("".join(array).encode array).encode("hex"), ("hex"), 16) # Collect 256 bits of random data from the OS's cryptographi cryptographically cally secure random generator byte_array = os.urandom( os.urandom(32) 32) return convert_to_in convert_to_int(byte_array) t(byte_array) 25
def get_point_pubkey(point): get_point_pubkey(point): if point.y() & 1: key = '03' + '%064x' % point.x() else: key = '02' + '%064x' % point.x() return key.decode('h key.decode('hex') ex') def get_point_pubkey_uncompr get_point_pubkey_uncompressed(point): essed(point): key = '04' + \ '%064x' % point.x() + \ '%064x' % point.y() return key.decode('h key.decode('hex') ex')
# Generate a new private key. secret = random_secret random_secret() () print "Secret: ", secret # Get the public key point. point = secret * generator print "EC point:", point print "BTC public key:", get_point_pu get_point_pubkey(point).e bkey(point).encode("hex") ncode("hex") # Given the point (x, y) we can create the object using: point1 = ecdsa.ellipti ecdsa.ellipticcurve.Point( ccurve.Point(curve, curve, point.x(), point.y(), ec_order) assert point1 == point
Instalando a livraria Python ECDSA e executando o script ec_math.py ec_math.py demonstra o output que Ž produzido quando se executa esse script.
NOTE
26
O exemplo acima usa os.urandom, que reflete um gerador de nœmeros aleat—rios criptograficamente seguro (CSRNG) fornecido pelo sistema operacional subjacente. No caso de um sistema operacional do tipo UNIX, como o Linux, ele adquire isso a partir de /dev/urandom; e no caso do Windows, a partir de CryptGenRandom(). Se uma fonte adequada de aleatoriedade n‹o for encontrada, o NotImplementedError ser‡ gerado. Enquanto o gerador de nœmero aleat—rio usado aqui Ž usado para fins demonstrativos, ele _n‹o Ž apropriado para a gera•‹o de chaves bitcoins com qualidade suficiente para serem usadas em produ•‹o, j‡ que eles n‹o Ž implementado com seguran•a suficiente.
Example 7. Instalando Instalando a livraria livraria Python ECDSA ECDSA e executando executando o script ec_math.py ec_math.py
$ # Instala o administrado administradorr de pacotes Python PIP $ sudo apt-get install python-pip $ # Instala a livraria Python ECDSA $ sudo pip install ecdsa $ # Executa o script $ python ec-math.py Secret: 38090835015954358862481132 3809083501595 43588624811326288874439059 62888744390590620499591237 0620499591237827806016870 8278060168703580660294000 3580660294000 EC point: (7004885353186717948985775 (700488535318 67179489857750497606966272 04976069662723825834713229 3825834713229354546245955 3545462459554000726931262 40007269312627, 7, 10526220647868674319106080 1052622064786 86743191060800263479589329 02634795893299202095272858 9202095272858039357360216 0393573602168604554235338 86045542353380) 0) BTC public key: 029ade3effb0 029ade3effb0a67d5c8609850 a67d5c8609850d797366af428f d797366af428f4a0d5194cb221 4a0d5194cb221d807770a1522 d807770a1522873 873
Carteiras As carteiras s‹o recipientes para chaves privadas, geralmente implementadas como arquivos estruturados ou bancos de dados simples. Outro mŽtodo de se fazer chaves Ž atravŽs de gera•‹o determin’stica de chave. Nesse mŽtodo, cada chave privada nova Ž derivada a partir de uma chave privada prŽvia utilizando-se uma fun•‹o de hash de via œnica, que as ligam em sequncia. Contanto que voc possa recriar essa sequncia, voc s— precisa da primeira chave (conhecida como uma semente ou chave mestre) para gerar todas elas. Nessa se•‹o n—s iremos examinar os diferentes mŽtodos de gera•‹o de chaves e as estruturas de carteira que s‹o constru’das com elas.
TIP
As carteiras Bitcoin n‹o contŽm bitcoins, elas contŽm chaves. Cada usu‡rio possui uma carteira que contŽm chaves. As carteiras na verdade s‹o chaveiros que contŽm pares de chaves privadas e pœblicas (veja Chaves Privada e Pœblica). Pœblica ). Os usu‡rios assinam as transa•›es com as chaves, provando que eles s‹o donos dos outputs da transa•‹o, ou seja, provando que s‹o donos de seus bitcoins. Os bitcoins s‹o armazenados na blockchain na forma de outputs de transa•›es (frequentemente denominados como vout ou txout).
Carteiras n‹o-determin’sticas (aleat—rias) Nos primeiros clientes bitcoin, as carteiras eram simplesmente cole•›es de chaves privadas geradas aleatoriamente. Esse tipo de carteira Ž chamado de carteira n‹o-determin’stica tipo 0. Por exemplo, o cliente Bitcoin Core faz uma gera•‹o inicial de 100 chaves privadas aleat—rias quando Ž iniciado pela primeira vez e gera mais chaves conforme a necessidade, usando cada chave apenas uma œnica vez. Esse tipo de carteira Ž apelidada de "Apenas um Monte de Chaves" (em ingls, "Just a Bunch of Keys", ou JBOK), e tais carteiras est‹o sendo substitu’das por carteiras determin’sticas pois elas s‹o dif’ceis de se administrar, fazer fazer backup e importa•›es. A desvantagem das chaves aleat—rias aleat—rias Ž que se voc gerar muitas delas voc precisa manter c—pias de todas elas, ou seja, Ž necess‡rio fazer backups frequentes da carteira. Todas as chaves precisam de backup, ou os fundos que elas controlam ser‹o 27
irrevogavelmente perdidos se a carteira se tornar inacess’vel. Isso entra em conflito direto com o princ’pio de se evitar a reutiliza•‹o de endere•os, utilizando-se cada endere•o bitcoin para uma œnica transa•‹o. A reutiliza•‹o de endere•os reduz a privacidade pois associa mœltiplas transa•›es e endere•os uns com os outros. Uma carteira n‹o-determin’stica tipo-0 Ž uma escolha ruim, especialmente se voc quer evitar a reutiliza•‹o de endere•o porque isso significa ter que administrar mais chaves, o que cria a necessidade de backups mais frequentes. Embora o cliente Bitcoin Core inclua uma carteira Tipo-0, o uso desse tipo de carteira Ž desaconselhado pelos desenvolvedores do Bitcoin Core. demonstra uma carteira n‹o-determin’stica, contendo uma cole•‹o solta de chaves aleat—rias.
Carteiras Determin’sticas (que usam semente) As carteiras determin’sticas, ou carteiras que usam "sementes", contŽm chaves privadas que s‹o todas derivadas a partir de uma semente comum, a semente-mestre, atravŽs do uso de uma fun•‹o de hash de sentido œnico. A semente-mestre Ž um nœmero gerado aleatoriamente que Ž combinado com outros dados, como um nœmero ’ndice ou "c—digo de cadeia" (ver Carteiras Determin’sticas Hier‡rquicas (BIP0032/BIP0044))) para derivar as chaves privadas. Em uma carteira determin’stica, basta ter a (BIP0032/BIP0044) semente para se recuperar todas as chaves derivadas, e portanto Ž necess‡rio apenas um œnico backup feito no momento de sua cria•‹o. A semente tambŽm Ž a œnica coisa necess‡ria para importar e exportar a carteira, permitindo a f‡cil migra•‹o de todas as chaves do usu‡rio entre diferentes implementa•›es de carteira.
28
Figure 8. Carteira Carteira tipo-0 n‹o-determin’sti n‹o-determin’stica ca (aleat—ria): uma cole•‹o cole•‹o de chaves geradas geradas aleatoriamente aleatoriamente
C—digos Mnem™nicos de Palavras Os c—digos mnem™nicos s‹o sequncias (listas) de palavras em ingls que representam (codificam) um nœmero aleat—rio que Ž usado como semente para se derivar uma carteira determin’stica. A sequncia de palavras Ž a œnica coisa necess‡ria para se recriar a semente e, a partir dela, se recriar a carteira e todas as suas chaves derivadas. Um aplicativo de carteiro que implementa carteiras determin’sticas com c—digo mnem™nico ir‡ mostrar ao usu‡rio uma sequncia de 12 a 24 palavras quando ele criar a carteira pela primeira vez. Essa sequncia de palavras Ž a o backup da carteira e pode ser usado para recuperar e recriar todas as chaves no mesmo aplicativo ou em qualquer aplicativo de carteira compat’vel. As palavras dos c—digos mnem™nicos tornam mais f‡cil a cria•‹o de um backup das carteiras, porque elas s‹o f‡ceis de ler e de se anotar corretamente, quando comparadas a uma sequncia de nœmeros aleat—rios. Os c—digos mnem™nicos s‹o definidos na Proposta de Melhoria do Bitcoin 39 (ver [bip0039] [bip0039]), ), atualmente com o status de Rascunho. Note que a BIP0039 Ž uma proposta em estudo e ainda n‹o Ž um padr‹o. Especificamente, existe um padr‹o diferente, com um conjunto diferente de palavras, usado pela carteira Electrum, que j‡ existia antes do BIP0039. O BIP0039 Ž usado pela carteira Trezor e algumas outras poucas carteiras, mas Ž incompat’vel com a implementa•‹o da Electrum. O BIP0039 define a cria•‹o de um c—digo mnem™nico e de uma semente da seguinte maneira:
29
1. Cria uma sequn sequncia cia aleat—ria aleat—ria (entrop (entropia) ia) de 128 a 256 bits. 2. Cria uma soma de de verifica•‹o (checksum) (checksum) da sequncia aleat—ria aleat—ria tomando alguns alguns do primeiros poucos bits de seu hash SHA256. 3. Adiciona a soma de verifica•‹o verifica•‹o (checksum) no final da sequncia sequncia aleat—ria. 4. Divide a sequncia sequncia em se•›es de 11 bits, usando-as para para indexar um dicion‡rio dicion‡rio de 2048 palavras palavras prŽ-definidas. 5. Produz 12 a 24 palavras palavras representando representando o c—digo mnem™nico. C—digos mnem™nicos: entropia e comprimento da palavra mostra palavra mostra a rela•‹o entre o tamanho dos dados de entropia e o comprimento em palavras dos c—digos mnem™nicos. Table 5. C—digos mnem™nicos: entropia e comprimento da palavra Entropia (bits)
Soma de verifica•‹o (checksum) (bits)
Ent ntr rop opia ia+ +ch che ecks ksum um
Compri Comp rim ment nto o de palavras
128
4
132
12
160
5
165
15
192
6
198
18
224
7
231
21
256
8
264
24
O c—digo mnem™nico representa de 128 a 256 bits, que s‹o usados para derivar uma semente maior (de 512-bit) atravŽs da fun•‹o de extens‹o de chave PBKDF2. A semente resultante Ž usada para criar uma carteira determin’stica e todas as suas chaves derivadas. As tabelas e demonstram alguns exemplos de c—digos mnem™nicos e as sementes que eles produzem. c—digo mnem™nico com entropia de .128-bit e a semente resultante Input de entropia (128 bits)
0c1e24e5917779d297e14d45f14e1a1a
Mnem™nico (12 palavras)
army van defense carry jealous true garbage claim echo media make crunch
Semente (512 bits)
3338a6d2ee71c7f28eb5b882159634cd46a898463e9 d2d0980f8e80dfbba5b0fa0291e5fb88 8a599b44b93187be6ee3ab5fd3ead7dd646341b2cd b8d08d13bf7
c—digo mnem™nico com entropia de .256-bit e a semente resultante
30
Input de entropia (256 bits)
2041546864449caff939d32d574753fe684d3c947c33 46713dd8423e74abcf8c
Mnem™nico (24 palavras)
cake apple borrow silk endorse fitness top denial coil riot stay wolf luggage oxygen faint major edit measure invite love trap field dilemma oblige
Semente (512 bits)
3972e432e99040f75ebe13a660110c3e29d131a2c80 8c7ee5f1631d0a977fcf473bee22 fce540af281bf7cdeade0dd2c1c795bd02f1e4049e20 5a0158906c343
Carteiras Determin’sticas Hier‡rquicas (BIP0032/BIP0044) As carteiras determin’sticas foram desenvolvidas para facilitar a deriva•‹o de v‡rias chaves a partir de uma œnica "semente". A forma mais avan•ada de carteiras determin’sticas Ž a carteira determin’stica hier‡rquica ou carteira HD, que Ž definida pelo padr‹o BIP0032. As carteiras HD contm chaves derivadas em uma estrutura de ‡rvore, de tal forma que uma chave pai pode derivar uma sequncia de chaves filhas, cada uma das quais pode derivar uma sequncia de chaves netas, e assim por diante, a uma profundidade infinita. Essa estrutura em ‡rvore Ž ilustrada em Carteira hier‡rquica determin’stica (HD) tipo-2: uma ‡rvore de chaves geradas a partir de uma œnica semente semente..
Figure 9. Carteira Carteira hier‡rquica hier‡rquica determin’stica determin’stica (HD) tipo-2: tipo-2: uma ‡rvore ‡rvore de chaves geradas a partir partir de uma œnica semente
31
TIP
Se voc estiver implementando uma carteira bitcoin, ela deve ser desenvolvida como uma carteira HD seguindo os padr›es BIP0032 e BIP0044.
Carteiras HD fornecem duas grandes vantagens em compara•‹o com chaves rand™micas (n‹o determin’sticas). Primeiro, a estrutura em ‡rvore pode ser usada para expressar significado organizacional adicional, por exemplo quando um ramo espec’fico de subchaves Ž usado para pagamentos recebidos e outro ramo Ž usado para receber troco de pagamentos realizados. Ramos ou chaves tambŽm podem ser usados num cen‡rio corporativo, alocando ramos diferentes a departamentos, subsidi‡rias, fun•›es espec’ficas, espec’ficas, ou centros de custo. A segunda vantagem de carteiras HD Ž que os usu‡rios podem criar uma sequncia de chaves pœblicas sem precisar ter acesso ˆs chaves privadas correspondentes. Isso permite que carteiras HD sejam utilizadas num servidor inseguro, ou numa aplica•‹o de somente recebimento, emitindo uma chave pœblica diferente para cada transa•‹o. As chaves pœblicas n‹o precisam ser previamente carregadas ou derivadas de antem‹o, assim o servidor n‹o detŽm as chaves privadas que possam gastar os fundos. Cria•‹o de carteira HD a partir de semente
Carteiras HD s‹o criadas a partir de uma œnica semente raiz, que Ž um nœmero rand™mico de 128, 256, ou de 512 bits. Tudo mais na carteira HD Ž derivado deterministicamente a partir da sua semente raiz, o que torna poss’vel recriar a carteira HD completa a partir daquela semente em qualquer carteira HD compat’vel. Isso faz com que seja f‡cil realizar backup, restaurar, exportar e importar carteiras HD contendo milhares ou atŽ mesmo milh›es de chaves, simplesmente transferindo apenas a semente raiz. A semente raiz Ž mais frequentemente representada por uma sequncia mnem™nica de palavras, tal como descrito na se•‹o anterior C—digos Mnem™nicos de Palavras, Palavras , para tornar mais f‡cil para as pessoas transcrever e armazenar. O processo de criar as chaves e c—digos de encadeamento mestre para uma carteira HD Ž demonstrado em Criando chaves mestres e c—digo de cadeia a partir da semente raiz .
Figure 10. Criando Criando chaves mestres mestres e c—digo de cadeia a partir da semente raiz
32
A semente raiz Ž usada como input no algoritmo HMAC-SHA512 e o hash resultante Ž usado para criar uma chave privada mestre (m) e um c—digo de corrente mestre. A chave privada mestre (m) ent‹o gera a chave pœblica mestre correspondente (M), usando o processo normal de multiplica•‹o da curva el’ptica m * G que n—s vimos anteriormente nesse cap’tulo. O c—digo de corrente Ž usado para criar entropia na fun•‹o que cria as chaves filhas a partir das chaves pais, como n—s iremos ver na pr—xima se•‹o. Deriva•‹o da chave privada filha
As carteiras hier‡rquicas determin’sticas usam uma fun•‹o de deriva•‹o de chave filha ("child key derivation", derivation ", CKD) para derivar chaves filhas a partir das chaves pais. As fun•›es de deriva•‹o de chave filha s‹o baseadas em uma fun•‹o de hash de sentido œnico, que combina: ¥ Uma chave privada pai pai ou uma chave pœblica (chava n‹o-comprimida n‹o-comprimida ECDSA) ¥ Uma semente semente chamada chamada de de c—digo c—digo de corrente corrente (256 bits) bits) ¥ Um nœmer nœmeroo ’ndice ’ndice (32 (32 bits) bits) O c—digo da corrente Ž usado para introduzir dados aparentemente aleat—rios ao processo, fazendo com que o ’ndice n‹o seja suficiente para derivar outras chaves filhas. Logo, o fato de se ter t er uma chave filha n‹o torna alguŽm capaz de descobrir suas chaves irm‹s, a menos que a pessoa tenha tambŽm o c—digo da corrente. A semente do c—digo da corrente inicial (no n’vel da raiz da ‡rvore) Ž feito a partir de dados aleat—rios, enquando os c—digos de corrente subsequentes s‹o derivadas de cada c—digo de corrente pai. Esses trs ’tens s‹o combinados e s‹o usados para fazer um hash, gerando as chaves filhas. A chave pœblica pai, o c—digo de corrente e o nœmero ’ndice s‹o combinados e sofrem hash com o algoritmo HMAC-SHA512 para produzir um hash de 512-bit. O hash resultante Ž dividido em duas metades. A metade da direita de 256 bits do output do hash se torna o c—digo de corrente da filha. A metade da esquerda de 256 bits do hash e o nœmero ’ndice s‹o adicionados ˆ chave privada pai para produzir a chave privada filha. Em [CKDpriv] [CKDpriv],, n—s vimos isso ilustrado com o ’ndice definido em 0 para produzir a 0¼ (primeiro no ’ndice) filha do pai. 1. Estendendo uma chave chave privada pai para criar image::images/msbt_0411.png["ChildPrivateDerivation"]
uma
chave
privada
filha
Mudar o ’ndice nos permite estender a chave pai e criar a outra chave filha na sequncia. Por exemplo, Filha 0, Filha 1, Filha 2, etc. Cada chave pai pode ter 2 bilh›es de chaves filha. Repetindo o processo em um n’vel abaixo da ‡rvore, cada filha pode virar um pai e criar suas pr—prias filhas, em um nœmero infinito de gera•›es.
33
Usando as chaves filhas derivadas
As chaves privadas filhas s‹o indistingu’veis das chaves n‹o-determin’sticas (aleat—rias). Como a fun•‹o de deriva•‹o Ž uma fun•‹o de via œnica, a chave filha n‹o pode ser usada para se encontrar a chave pai. A chave filha tambŽm n‹o pode ser usada para se encontrar nenhuma chave irm‹. Se voc tem a chave filha n, voc n‹o Ž capaz de descobrir suas irm‹s, como a filha nÐ1 ou a filha n+1, assim como nenhuma outra filha que fa•a parte da sequncia. Somente a chave pai e o c—digo de cadeia podem derivar todas as filhas. Sem o c—digo de corrente da filha, a chave filha tambŽm n‹o pode ser usada para derivar nenhuma chave neta. Voc precisa ter tanto a chave privada filha quando o c—digo de corrente da filha para poder iniciar um novo ramo e derivar as chaves netas. Ent‹o para que serve uma chave filha privada isolada? Ela pode ser usada para fazer uma chave pœblica e um endere•o bitcoin. Ou seja, ela pode ser usada para assinar transa•›es que gastem qualquer valor que aquele endere•o tenha recebido.
TIP
Uma chave privada filha, a chave pœblica e o endere•o bitcoin correspondentes s‹o todos indistingu’veis de chaves e endere•os endere•os criados aleatoriamente. aleatoriamente. NinguŽm sabe sabe que elas fazem parte de uma sequncia, exceto a fun•‹o de carteira HD que as criou. Uma vez criadas, elas operam exatamente como chaves "normais".
Chaves estendidas
Como n—s vimos anteriormente, a fun•‹o de deriva•‹o de chave pode ser usada para criar chaves filhas em qualquer n’vel da ‡rvore, baseando-se em trs entradas (inputs): uma chave, um c—digo de corrente e o ’ndice da filha desejada. Os dois ingredientes essenciais s‹o a chave a o c—digo de cadeia, que combinados s‹o chamados de chave estendida. O termo "chave estendida" tambŽm poderia ser considerado como uma "chave estend’vel", pois esse tipo de chave pode ser usado para derivar chaves filhas. As chaves estendidas s‹o armazenadas e representadas basicamente como uma concatena•‹o da chave de 256-bit e do c—digo de corrente de 256-bit em uma sequncia de 512-bit. Existem dois tipos de chaves estendidas. A chave priva estendida Ž a combina•‹o de uma chave privada e do c—digo de cadeia, e pode ser usada para derivar as chaves privadas filhas (e, a partir delas, as chaves pœblicas filhas). Uma chave pœblica estendida Ž uma chave pœblica e um c—digo de corrente, que pode ser usada para criar as chaves pœblicas filhas, como descrito em Gerando uma Chave Pœblica. Pœblica . Imagina uma chave estendida como a raiz de um ramo na estrutura de ‡rvore da carteira HD. Tendo a raiz do ramo, voc pode derivar o resto do ramo. A chave privada estendida pode criar um ramo completo, enquanto a chave pœblica estendida s— Ž capaz c apaz de criar um ramo de chaves pœblicas.
TIP
Uma chave estendida consiste de uma chave privada ou chave pœblica e um c—digo de corrente. Uma chave estendida pode criar chaves filhas, gerando a sua pr—pria remifica•‹o na estrutura estrutura em ‡rvore. Compartilhar uma chave estendida estendida d‡ acesso a toda a ramifica•‹o.
As chaves estendidas s‹o codificadas com Base58Check, para exportar e importar facilmente entre 34
diferentes carteiras compat’veis com o BIP-0032. A codifica•‹o Base58Check para as chaves estendidas usa um nœmero de vers‹o especial que resulta no prefixo "xprv" e "xpub" quando codificada em caracteres Base58, para torn‡-los mais facilmente reconhec’veis. Como a chave estendida Ž de 512 ou 513 bits, ela Ž muito mais longa do que qualquer um dos strings codificados em Base58Check que n—s j‡ vimos anteriormente. Esse Ž um exemplo de uma chave privada estendida, codificada em Base58Check: xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3h xprv9tyUQV64JT5qs3RSTJkXC WKMyUgoQp7F3hA1xzG6ZGu6u6Q A1xzG6ZGu6u6Q9VMNjGr67Lctv 9VMNjGr67Lctvy5P8oyaYAL9C y5P8oyaYAL9CAWrUE9i6GoNMK AWrUE9i6GoNMK Uga5biW6Hx4tws2six3b9c
Essa Ž a chave pœblica estendida correspondente, correspondente, tambŽm codificada em Base58Check: xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv xpub67xpozcx8pe95XVuZLHXZ eG6XWXHpGq6Qv5cmNfi7cS5mtj 5cmNfi7cS5mtjJ2tgypeQbBs2U J2tgypeQbBs2UAR6KECeeMVKZ AR6KECeeMVKZBPLrtJunSDMst BPLrtJunSDMst weyLXhRgPxdp14sk9tJPW9
Deriva•‹o de chaves pœblicas filhas
Como mencionado anteriormente, uma caracter’stica muito œtil das carteiras determin’sticas hier‡rquicas Ž a habilidade de derivar chaves pœblicas filhas a partir de chaves pœblicas pais, sem que seja necess‡rio saber as chaves privadas. Isso fornece duas maneiras de derivar um chave pœblica filha: a partir da chave privada filha, ou diretamente a partir da chave pœblica pai. Portanto, uma chave pœblica estendida pode ser usada para derivar todas as chaves pœblicas (e somente as chaves pœblicas) naquela ramifica•‹o da estrutura da carteira HD. Esse atalho pode ser usado para criar implanta•›es somente-chave-pœblica muito seguras, onde um servidor ou aplica•‹o possui uma c—pia da chave pœblica estendida e nenhuma chave privada. Esse tipo de implanta•‹o pode produzir um nœmero infinito de chaves pœblicas e endere•os bitcoin, mas n‹o pode gastar nenhum dos bitcoins que forem enviados para para esses endere•os. endere•os. Enquanto isso, em outro servidor mais seguro, a chave privada estendida pode derivar todas as cahves privadas correspondentes para assinar as transa•›es e gastar os bitcoins. Uma utiliza•‹o comum dessa solu•‹o Ž a instala•‹o de uma chave pœblica estendida em um servidor web que seja utilizada em um servi•o de comŽrcio eletr™nico. O servidor web pode usar a fun•‹o de deriva•‹o de chave pœblica para cirar um novo endere•o bitcoin a cada transa•‹o (por exemplo, para um carrinho de compras de um consumidor). O servidor web n‹o ir‡ ter nenhuma chave privada que seriam vulner‡veis a roubo. Sem as carteiras HD, a œnica maneira de se fazer isso seria gerar milhares de endere•os bitcoin em um outro servidor seguro, e ent‹o envi‡-los antecipadamente para o servidor de comŽrcio eletr™nico. Essa abordagem n‹o Ž pr‡tica, pois requer uma manuten•‹o constante para evitar que as chaves do servidor de comŽrcio eletr™nico sejam todas gastas e "acabem". Outra aplica•‹o comum dessa solu•‹o Ž o uso de carteiras de harware ou de armazenamento frio. Nesse cen‡rio, a chave privada estendida pode ser armazenada em uma carteira de papel ou em um
35
dispositivo de hardware (como a carteira de hardware Trezor), enquanto a chave pœblica estendida pode ser mantida online. O usu‡rio pode criar endere•os de "recebimento" ˆ vontade, pois as suas chaves privadas est‹o armazenadas de maneira segura em um ambiente offline. Para gastar os fundos, o usu‡rio pode usar a chave privada estendida em um cliente bitcoin que assine a transa•‹o online, ou ao assinar as transa•›es em um dispositivo de carteira de hardware (por exemplo, o Trezor). Estendendo uma chave pœblica pai para criar uma chave pœblica filha ilustra o mecanismo para estender uma chave pœblica pai para derivar as chaves pœblicas filhas.
Figure 11. Estendendo Estendendo uma chave pœblica pœblica pai para para criar uma chave chave pœblica filha Deriva•‹o endurecida da chave filha
A habilidade de derivar um ramo de chaves pœblicas a partir de uma chave pœblica estendida Ž muito œtil, mas isso traz um risco em potencial. Ter acesso a uma chave pœblica estendida n‹o d‡ acesso ‡s chaves privadas filhas. No entanto, como a chave pœblica estendida contŽm o c—digo de corrente, se a chave privada filha Ž conhecida, ou vazou de alguma maneira, ela pode ser usada com o c—digo de corrente para derivar todas as outras chaves privadas filhas. Uma œnica chave privada filha vazada, junto com um c—digo de corrente pai, Ž suficiente para revelar todas as chaves privadas de todas as filhas. Pior ainda, a chave privada filha junto com o c—digo de corrente pai pode ser usado para deduzir a chave privada pai. Para evitar esse risco, as carteiras HD usam uma fun•‹o de deriva•‹o alternativa chamada deriva•‹o endurecida ("hardened derivation"), que "desfaz" a rela•‹o entre a chave pœblica pai e o c—digo de corrente filho. A fun•‹o de deriva•‹o endurecida usa a chave privada pai para derivar o c—digo de corrente filho, ao invŽs da chave pœblica pai. Isso cria um "firewall" na sequncia pai/filha, com um c—digo de corrente que n‹o pode ser usado para comprometer uma chave privada pai ou irm‹. A fun•‹o de deriva•‹o endurecida parece quase idntica ˆ deriva•‹o de chave privada filha normal, com a exce•‹o de que a chave privada pai Ž usada como input da fun•‹o de hash, h ash, ao invŽs da chave pœblica pai, como demonstrado no diagrama em Deriva•‹o endurecida de uma chave filha; omitindo a chave pœblica pai. pai.
36
Figure 12. Deriva•‹o Deriva•‹o endurecida de de uma chave filha; omitindo omitindo a chave pœblica pœblica pai
Quando a fun•‹o de deriva•‹o privada endurecida Ž utilizada, a chave privada filha e o c—digo de cadeia resultantes s‹o completamente diferentes do que iriam resultar a partir de uma fun•‹o de deriva•‹o normal. O "ramo" de chaves resultante poderia ser usada para produzir chaves pœblicas estendidas que n‹o s‹o vulner‡veis, pois o c—digo de corrente que elas contŽm n‹o pode ser hackeado para revelar as chaves privadas. A deriva•‹o endurecida Ž portanto usada para criar uma lacuna (um "gap") na ‡rvore acima do n’vel onde as chaves pœblicas estendidas s‹o usadas. Em termos simples, se voc quer usar a convenincia de uma chave pœblica estendida para derivar ramos das chaves pœblicas, sem se expor ao risco de deixar o c—digo de corrente vazar, voc deveria deriv‡-la a partir de um pai endurecido, ao invŽs de um pai normal. Como uma pr‡tica recomendada, as filhas do n’vel-1 das chaves mestre s‹o sempre derivadas atravŽs da deriva•‹o endurecida, para evitar o comprometimento das chaves mestre. Nœmeros de ’ndice para a deriva•›es normal e endurecida
O nœmero de ’ndice usado na fun•‹o de deriva•‹o Ž um nœmero de 32-bit. Para diferenciar facilmente entre as chaves derivadas atravŽs da fun•‹o de deriva•‹o normal das chaves derivadas atravŽs da deriva•‹o endurecida, esse nœmero ’ndice Ž dividido em duas faixas. Os nœmeros de ’ndice entre 0 e 231 Ð1 (0x0 a 0x7FFFFFFF) s‹o usados apenas para a deriva•‹o normal. Os nœmeros de ’ndice entre 2 31 e 232 Ð1 (0x80000000 a 0xFFFFFFFF) s‹o usados apenas para a deriva•‹o endurecida. Portanto, se o nœmero de ’ndice Ž menor do que 2 31, isso significa que a filha Ž normal, enquanto se o nœmero de ’ndice Ž maior ou igual a 2 31, a filha Ž endurecida. Para tornar o nœmero de ’ndice mais f‡cil de ler e exibir, o nœmero de ’ndice para as filhas
37
endurecidas Ž exibido iniciando do zero, mas com um ap—strofo. A primeira chave filha normal Ž portanto exibida como um 0, enquanto a primeira chave filha endurecida (’ndice 0x80000000) Ž exibida como 0'. Na sequncia, a segunda chave endurecida teria o ’ndice 0x80000001 e seria exibida como 1', e assim por diante. Quando voc se deparar com um ’ndice de carteira HD i', isso significa 231+i. Identificador (caminho) da chave de uma carteira HD
As chaves em uma carteira HD s‹o identificadas a partir de uma conven•‹o de nomenclatura de "caminho", com cada n’vel sendo separado por uma barra (/) (ver Exemplos de caminhos de carteira HD). HD ). As chaves privadas derivadas a partir da chave privada mestre iniciam com "m". As chaves pœblicas derivadas a partir da chave pœblica mestre iniciam com "M". Portanto, a primeira chave privada filha da chave privada mestre Ž m/0. A primeira chave pœblica filha Ž M/0. A segunda neta da primeira filha Ž m/0/1, e assim por diante. Os "antepassados" de uma chave s‹o lidos da direita para a esquerda, atŽ voc chegar na chave mestre a partir da qual ela foi derivada. Por exemplo, o identificador m/x/y/z descreve a chave que Ž a z» filha da chave m/x/y, que Ž a y» filha da chave m/x, que Ž a x» filha da chave m. Table 6. Exemplos de caminhos de carteira HD Caminho HD
Chave descrita
m/0
A primeira (0) chave privada a partir da chave privada mestre (m)
m/0/0
A primeira chave privada neta da primeira filha (m/0)
m/0'/0
A primeira neta normal da primeira filha endurecida (m/0')
m/1/0
A primeira chave privada neta da segunda filha (m/1)
M/23/17/0/0
A primeira chave pœblica tataraneta da primeira bisneta da 18» neta da 24» filha
Navegando as estrutura de ‡rvore da carteira HD
A estrutura de ‡rvore da carteira HD oferece uma flexibilidade imensa. Cada chave pai estendida pode ter 4 bilh›es de filhas: 2 bilh›es de filhas normais e 2 bilh›es de filhas endurecidas. Cada uma dessas filhas pode ter outras 4 bilh›es de filhas, e assim por diante. A ‡rvore pode ter a profundidade que for necess‡ria, com um nœmero infinito de gera•›es. Com toda essa flexibilidade, entretanto, se torna bastante dif’cil navegar nessa ‡rvore infinita. ƒ especialmente dif’cil transferir carteiras HD entre implementa•›es, porque as possibilidades de organiza•‹o interna em ramos e subramos s‹o infinitas. Duas Propostas de Melhorias para o Bitcoin (BIPs) oferecem uma solu•‹o para essa complexidade, ao criar alguns padr›es propostos para a estrutura das ‡rvores das carteiras HD. A BIP0043 prop›e o uso
38
do ’ndice da primeira filha endurecida como um identificador especial que representa o "prop—sito" da estrutura de ‡rvore. Baseando-se na BIP0043, uma carteira HD deveria usar apenas um ramo de n’vel1 da ‡rvore, com o nœmero de ’ndice identificando a estrutura e o espa•o de nomes para o resto da ‡rvore ao definir o seu prop—sito. Por exemplo, uma carteira HD usando apenas o ramo m/i'/ se destina a um prop—sito espec’fico, e esse prop—sito Ž identificado pelo nœmero ’ndice "i". Estendendo essa especifica•‹o, a BIP0044 prop›e uma estrutura de mœltiplas contas como nœmero de "proposta" 44' sob a BIP0043. Todas as carteiras HD seguindo a estrutura BIP0044 s‹o identificads pelo fato de que elas somente usaram um ramo da ‡rvore: m/44'/. m/44' /. O BIP0044 especifica a estrutura como consistindo de cinco n’veis de ‡rvore prŽ-definidos: m / purpose' / coin_type' / account' / change / address_index A "proposta" ("purpose") do primeiro n’vel Ž sempre definida como 44'. O "tipo_de_moeda" ("coin_type") do segundo n’vel especifica o tipo de criptomoeda, permitindo a existncia de carteiras HD que usem mœltiplas moedas, onde cada moeda possui a sua pr—pria sub‡rvore sob o segundo n’vel. Existem trs moedas definidas atŽ hoje: a Bitcoin Ž m/44'/0', a Bitcoin Testnet Ž m/44'/1'; e a Litecoin Ž m/44'/2'. O terceiro n’vel da ‡rvore Ž a "conta" ("account"), que permite que os usu‡rios subdividam suas carteiras em subcontas separadas l—gicas, para fins de contabilidade e organiza•‹o. Por exemplo, uma carteira HD pode conter duas "contas" bitcion: m/44'/0'/0' e m/44'/0'/1'. Cada conta Ž a raiz de sua pr—pria sub‡rvore. No quarto n’vel, "troco" ("change"), uma carteira HD tem duas sub‡rvores, uma para criar endere•os de recebimento e outra para criar endere•os de troco. Note que enquanto os n’veis anteriores usavam deriva•‹o endurecida, esse n’vel usa deriva•‹o normal. Isso acontece para permitir que esse n’vel da ‡rvore exporte chaves pœblicas estendidas para uso em ambientes n‹o-seguros. Os endere•os utiliz‡veis s‹o derivados pela carteira HD como crian•as no quarto n’vel, tornando o quinto n’vel da ‡rvore o "’ndice_de_endere•o" ("address_index"). Por exemplo, o terceiro endere•o de recebimento para pagamentos bitcoin na conta prim‡ria seria M/44'/0'/0'/0/2. Exemplos de estrutura de carteira HD da BIP0044 demonstra BIP0044 demonstra mais alguns exemplos. Table 7. Exemplos de estrutura de carteira HD da BIP0044 Caminho HD
Chave descrita
M/44'/0'/0'/0/2
A terceira chave pœblica de recebimento para a conta bitcoin prim‡ria
M/44'/0'/3'/1/14
A dŽcima quinta chave pœblica para endere•o de troco para a quarta conta bitcoin
m/44'/2'/0'/0/1
A segunda chave privada na conta principal Litecoin, para assinar transa•›es
39
Experimentando com carteiras HD usando Bitcoin Explorer
Usando a ferramenta de linha de comando Bitcoin Explorer que foi apresentada em [ch03_bitcoin_client],, voc pode fazer um teste gerando e estendendo chaves determin’sticas da [ch03_bitcoin_client] BIP0032, assim como exibi-las em diferentes formatos:
$ bx seed | bx hd-new > m # cria uma nova chave privada mestre a partir da semente e a armazena no arquivo "m" $ cat m # mostra a chave privada mestre estendida xprv9s21ZrQH143K38iQ9Y5p6q xprv9s21ZrQH1 43K38iQ9Y5p6qoB8C75TE71Nfp oB8C75TE71NfpyQPdfGvzghDt3 yQPdfGvzghDt39DHPFpovvtWZ 9DHPFpovvtWZaRgY5uPwV7RpE aRgY5uPwV7RpEgHs7cvdg gHs7cvdg fiSjLjjbuGKGcjRyU7RGGSS8Xa $ cat m | bx hd-public # gera a chave p œblica estendida M/0 xpub67xpozcx8pe95XVuZLHXZe xpub67xpozcx8 pe95XVuZLHXZeG6XWXHpGq6Qv5 G6XWXHpGq6Qv5cmNfi7cS5mtjJ cmNfi7cS5mtjJ2tgypeQbBs2U 2tgypeQbBs2UAR6KECeeMVKZB AR6KECeeMVKZBPLrtJunS PLrtJunS DMstweyLXhRgPxdp14sk9tJPW9 $ cat m | bx hd-private # gera a chave privada estendida m/0 xprv9tyUQV64JT5qs3RSTJkXCW xprv9tyUQV64J T5qs3RSTJkXCWKMyUgoQp7F3hA KMyUgoQp7F3hA1xzG6ZGu6u6Q9 1xzG6ZGu6u6Q9VMNjGr67Lctv VMNjGr67Lctvy5P8oyaYAL9CA y5P8oyaYAL9CAWrUE9i6G WrUE9i6G oNMKUga5biW6Hx4tws2six3b9c $ cat m | bx hd-private | bx hd-to-wif # mostra a chave privada de m/0 como uma WIF L1pbvV86crAGoDzqmgY85xURkz L1pbvV86crAGo DzqmgY85xURkz3c435Z9nirMt5 3c435Z9nirMt52UbnGjYMzKBUN 2UbnGjYMzKBUN $ cat m | bx hd-public | bx hd-to-address # mostra o endere •o bitcoin de M/0 1CHCnCjgMNb6digimckNQ6TBVcTWBAmPHK $ cat m | bx hd-private | bx hd-private --index 12 --hard | bx hd-private --index 4 # generate m/0/12'/4 xprv9yL8ndfdPVeDWJenF18oiH xprv9yL8ndfdP VeDWJenF18oiHguRUj8jHmVrqq guRUj8jHmVrqqD97YQHeTcR3LC D97YQHeTcR3LCeh53q5PXPkLs eh53q5PXPkLsy2kRaqgwoS6YZ y2kRaqgwoS6YZBLatRZRy BLatRZRy UeAkRPe1kLR1P6Mn7jUrXFquUt
Chaves e Endere•os Avan•ados Nas pr—ximas se•›es n—s iremos ver as formas avan•adas de chaves e endere•os, como chaves privadas, scripts e endere•os de mœltiplas assinaturas criptografados, alŽm de endere•os vanity e carteiras em papel.
Chaves Privadas Criptografadas (BIP0038) As chaves privadas sempre tem que ser secretas. A necessidade da confidencialidade das chaves privadas Ž uma obviedade que Ž bastante dif’cil de se conseguir na pr‡tica, porque isso gera conflito com outro fator de seguran•a importante que Ž a disponibilidade. Manter a chave privada de maneira maneira secreta Ž muito dif’cil quando voc precisa armazenar backups de uma chave privada para evitar perd-la. Uma chave privada armazenada em uma carteira que est‡ criptografada por uma senha pode ser segura, mas Ž necess‡rio fazer um backup da carteira. Ës vezes, os usu‡rios precisam mover suas chaves de uma carteira para outra Ñ para fazer atualiza•›es ou substituir o software de carteira, por exemplo. Os backups das chaves privadas tambŽm podem ser armazenados em um papel (veja Carteiras em papel) papel ) ou em uma m’dia de armazenamento externo, como um pendrive USB. Mas o que
40
acontece se o backup for roubado ou perdido? Esses objetivos de seguran•a conflitantes levaram ˆ cria•‹o de um padr‹o conveniente e port‡til de criptografar as chaves privadas de uma maneira que possa ser entendida por muitos clientes e carteiras bitcoins, que foi padronizado pela Proposta de Melhoria do Bitcoin 38 ou BIP0038 (veja [bip0038] [bip0038]). ). A BIP0038 prop›e um padr‹o comum para criptografar as chaves privadas com uma frase secreta e codific‡-las com Base58Check, de maneira que elas possam ser armazenadas de maneira segura em backups, movidas seguramente entre carteiras ou mantidas sob qualquer outras condi•›es onde a chave possa ser exposta. O padr‹o para criptografia usa o Padr‹o Avan•ado Avan•ado de Criptografia (Advanced (Advanced Encryption Standard, AES), um padr‹o estabelecido pelo Instituto Nacional de Padr›es e Tecnologia (National Institute of Standards and Technology, NIST) e usado amplamente em implementa•›es de criptografia de dados para aplica•›es comerciais e militares. Um esquema de criptografia usando a BIP0038 usa como input uma chave privada de bitcoin, geralmente codificada em Wallet Import Format (WIF), como uma string Base58Check com um prefixo de "5". Adicionalmente, o esquema de criptografia com BIP0038 recebe uma frase secretaÑuma senha longaÑgeralmente longaÑgera lmente composta por v‡rias palavras ou uma string complexa de caracteres alfanumŽricos. O resultado do esquema de criptografia com BIP0038 Ž uma chave privada criptografada em Base58Check que come•a com o prefixo 6P. Se voc enxergar uma chave que inicia com 6P, isso significa que ela Ž criptografada e requer uma senha para poder convert-la (descriptograf‡-la) de volta em uma chave privada formatada em WIF (com prefixo 5) que pode ser usada em qualquer carteira. Muitos aplicativos de carteira agora reconhecem as chaves privadas criptografadas em BIP0038 e ir‹o solicitar do usu‡rio uma senha para descriptograf‡-las e importar a chave. Aplicativos de terceiros, como o Bit Address (Aba Address (Aba Detalhes da Carteira), que Ž muito œtil e baseado em browser, podem ser usados para descriptografar as chaves BIP0038. As chaves criptografadas em BIP0038 s‹o mais utilizadas em carteiras de papel que podem ser usadas para fazer backup de chaves privadas em um peda•o de papel. Se o usu‡rio escolher uma u ma frase secreta forte, uma carteira de papel com chaves criptogradas em BIP0038 Ž uma maneira excelente e muito segura de se criar um armazenamento offline de bitcoin (tambŽm conhecido como "armazenamento frio"). Teste as chaves criptografadas em Exemplo de chave privada criptograda em BIP0038 BIP0038 usando o site bitaddress.org para ver como Ž poss’vel obter a chave descriptografada inserindo-se a frase secreta. Table 8. Exemplo de chave privada criptograda em BIP0038 Chave Privada (WIF)
5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2Jpbnk eyhfsYB1Jcn
Frase secreta
MinhaFraseSecretaDeTeste
Chave Criptografada (BIP0038)
6PRTHL6mWa48xSopbU1cKrVjpKbBZxcLRRCdctL J3z5yxE87MobKoXdTsJ
41
Hash Pay-to-Script (P2SH) e Endere•os de mœltiplas assinaturas (Multi-Sig) Como n—s sabemos, os endere•os bitcoin tradicionais come•am com o nœmero "1" e s‹o derivados a partir da chave pœblica, que Ž derivada a partir da chave privada. Embora qualquer pessoa pode enviar bitcoins para um endere•o "1", esse bitcoin s— pode ser gasto ao se apresentar a assinatura da chave privada e o hash da chave pœblica correspondentes. Os endere•os bitcoin que come•am como nœmero "3" s‹o endere•os de hash-de-pagamento-par hash-de-pagamento-para-script a-script (pay-to-script hash, P2SH), e eles ˆs vezes s‹o erroneamente chamados de endere•os de mœltiplas assinaturas ou multi-sig. Ao invŽs de definir o dono da chave pœblica como o hash, eles definem os benefici‡rios de uma transa•‹o bitcoin como o hash de um script. Essa funcionalidade foi inclu’da em Janeiro de 2012 com a Proposta de Melhoria do Bitcoin 16, ou BIP0016 (ver [bip0016] [bip0016]), ), e vem sendo amplamente adotada, pois proporciona uma oportunidade de adicionar funcionalidade para o pr—prio endere•o em si. Ao contr‡rio das transa•›es que "enviam" fundos para endere•os bitcoins "tradicionais" que come•am com 1, tambŽm conhecidos como "hash-de-pagamento-para-chavepœblica" ("pay-to-public-key-hash", P2PKH), os fundos enviados para endere•os que come•am com "3" exigem como prova de posse algo alŽm da apresenta•‹o de um hash de chave pœblica e de uma assinatura de chave privada. As exigncias s‹o definidas dentro do script, no momento em que o endere•o Ž criado, e todos os inputs desse endere•o ser‹o entravados entravados com as mesmas exigncias. Um endere•o com hash pay-to-script Ž criado a partir de um script de transa•‹o, que define quem pode gastar um output de transa•‹o (para maiores detalhes, veja [p2sh] [p2sh]). ). A codifica•‹o de um endere•o com hash pay-to-script envolve a utliza•‹o da mesma fun•‹o de hash duplo que Ž usada durante a cria•‹o de um endere•o bitcoin, porŽm ela Ž aplicada no script ao invŽs de ser aplicada na chave pœblica: script hash = RIPEMD160(SHA256(script)) RIPEMD160(SHA256(script))
O "hash de script" resultante Ž codificado em Base58Check com um prefixo de vers‹o de 5, que resulta em um endere•o codificado que se inicia com um 3. Um exemplo de endere•o P2SH Ž 3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM, 3F6i6kwkevjR7AsAd4te2Y B2zZyASEm1HM, que pode ser ser derivado usando os comandos comandos script-encode, sha256, ripemd160 e base58check-encode (ver [libbitcoin] [libbitcoin])) do Bitcoin Explorer, como demonstrado a seguir: $ echo dup hash160 [ 89abcdefabbaa 89abcdefabbaabbaabbaabbaa bbaabbaabbaabbaabbaabbaab bbaabbaabbaabba ba ] equalverify checksig > script $ bx script-encode < script | bx sha256 | bx ripemd160 | bx base58check-encode --version 5 3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM
TIP
42
O P2SH n‹o Ž necessariamente o mesmo que uma transa•‹o de mœltiplas assinaturas padr‹o. Um endere•o P2SH geralmente representa um script de mœltiplas assinaturas, mas ele tambŽm pode representar um script codificando outros tipos de transa•›es.
Endere•os de mœltiplas assinaturas e P2SH
Atualmente, a implementa•‹o mais comum da fun•‹o P2SH Ž o script de endere•o de mœltiplas assinaturas. Como o nome sugere, o script subjacente exige mais do que uma assinatura para provar a posse e, portanto, gastar os fundos. A fun•‹o de mœltiplas assinaturas do bitcoin Ž projetada para exigir M assinaturas (tambŽm conhecido como o "limiar") de um total de N chaves, tambŽm conhecido como um assinatura mœltipla M-de-N, onde M Ž igual ou menor do que N. Por exemplo, Bob, o dono da cafeteria de [ch01_intro_what_is_bitcoin] [ch01_intro_what_is_bitcoin] poderia poderia usar um endere•o de mœltiplas assinaturas exigindo 1-de-2 assinaturas a partir da chave que o pertence e uma chave que pertence ˆ sua esposa, garantindo que qualquer um deles poderia fazer uma assinatura para gastar um output de transa•‹o travado em seu endere•o. Isso seria semelhante a uma "conta conjunta" em um banco tradicional, onde qualquer um do casal poderia gastar com uma œnica assinatura. Ou Gopesh, o web designer que o Bob contratou para criar um website, website, poderia ter um endere•o endere•o de mœltiplas assinaturas assinaturas do tipo 2-de-3 para o seu neg—cio, para garantir garantir que nenhum fundo pode ser gasto a menos que dois de seus s—cios assinem uma transa•‹o. N—s iremos explorar como criar transa•›es que gastam fundos a partir de endere•os P2SH (e de mœltiplas assinaturas) em [transactions] [transactions]..
Endere•os Vanity Endere•os vanity s‹o endere•os bitcoin v‡lidos que contŽm mensagens poss’veis de serem lidas por pessoas. Por exemplo, 1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33 1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33 Ž um endere•o v‡lido que contŽm as letras formando a palavra "Love" como as primeiras letras de Base-58. Os endere•os vanity exigem a cria•‹o e testagem de bilh›es de chaves privadas candidatas, atŽ que uma derive um endere•o bitcoin o padr‹o desejado. Embora existem algumas otimiza•›es no algoritmo de gera•‹o vanity, o processo essencialmente envolve selecionar uma chave privada aleatoriamente, derivar a chave pœblica, derivar o endere•o bitcoin e verificar se ele corresponde ao padr‹o vanity desejado, repetindo esse processo bilh›es de vezes atŽ que uma correspondncia seja encontrada. Assim que uma correspondncia de um endere•o vanity com um padr‹o desejado for encontrada, a chave privada a partir da qual ele foi derivado agora pode ser usada pelo dono para gastar seus bitcoins da mesma maneira que qualquer outro endere•o. Os endere•os vanity n‹o s‹o mais ou menos seguros do que qualquer outro endere•o. Eles dependem da mesma Curva El’ptica de Criptografia (ECC) e Algoritmo de Hash Seguro (SHA), como qualquer outro endere•o. N‹o Ž mais f‡cil descobrir a chave privada de um endere•o come•ando com um padr‹o vanity, em compara•‹o com qualquer outro endere•o. No [ch01_intro_what_is_bitcoin] [ch01_intro_what_is_bitcoin],, n—s apresentamos a Eugnia, uma diretora de um centro de caridade para crian•as nas Filipinas. Vamos dizer que a Eugnia est‡ organizando uma campanha para arrecadar fundos em bitcoin e quer usar um endere•o bitcoin vanity para divulgar em sua campanha. A Eugnia ir‡ criar um endere•o vanity que comece com "1Kids" para divulgar a campanha do centro de caridade. Vamos ver como esse endere•o vanity ser‡ criado e o que isso significa para a seguran•a do centro de caridade da Eugnia.
43
Gerando endere•os vanity
ƒ importante notar que um endere•o bitcoin Ž simplesmente um nœmero representado por s’mbulos no alfabeto Base58. Uma busca por um padr‹o como "1Kids" pode ser vista como uma buscar por um endere•o na faixa de 1Kids11111111111111111111111111111 atŽ 1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz. Existem aproximadamente 58 29 (aproximadamente 1,4 * 1051) endere•os nessa faixa, todos come•ando com "1Kids". A A amplitude de endere•os vanity iniciando com "1Kids" mostra "1Kids" mostra a faixa de endere•os que tem o prefixo 1Kids. Table 9. A amplitude de endere•os vanity iniciando com "1Kids"
1Kids11111111111111111111111111111
De
1Kids11111111111111111111111111112 1Kids11111111111111111111111111113 ... 1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz
AtŽ
Vamos ver o padr‹o "1Kids" como um nœmero e ver qu‹o frequentemente n—s encontrar’amos esse padr‹o em um endere•o bitcoin (ver A frequncia de um padr‹o vanity (1KidsCharity) e a mŽdia de tempo-para-descobrir em um PC desktop). desktop ). Um computador desktop PC mŽdio, sem nenhum hardware especializado, Ž capaz de buscar cerca de 100.000 chaves por segundo. Table 10. A frequncia de um padr‹o vanity (1KidsCharity) (1KidsCharity) e a mŽdia de tempo-para-desc tempo-para-descobrir obrir em um PC desktop Comprimento
Padr‹o
Frequncia
Tempo mŽdio de busca
1
1K
1 em 58 chaves
< 1 milisegundo
2
1Ki
1 em 3.364
50 milisegundos
3
1Kid
1 em 195.000
< 2 segundos
4
1Kids
1 em 11 milh›es
1 minuto
5
1KidsC
1 em 656 milh›es
1 hora
6
1KidsCh
1 em 38 bilh›es
2 dias
7
1KidsCha
1 em 2,2 trilh›es
3Ð4 meses
8
1KidsChar
1 em 128 trilh›es
13Ð18 anos
9
1KidsChari
1 em 7 quadrilh›es
800 anos
10
1KidsCharit
1 em 400 quadrilh›es
46.000 anos
11
1KidsCharity
1 em 23 quintilh›es
2,5 milh›es de anos
Como voc pode ver, a Eugnia n‹o ir‡ criar um ender•o vanity "1KidsCharity" t‹o cedo, mesmo que
44
ela tivesse acesso a milhares de computadores. Cada caractere adicional aumenta a dificuldade em um fator de 58. Os padr›es com mais de sete caracteres s‹o geralmente encontrados utilizando-se hardware especializado, como desktops montados de maneira customizada com mœltiplas placas de v’deo (GPUs). Esses hardwares hardwares geralmente geralmente s‹o equipamentos equipamentos antigos que eram usados para para a minera•‹o do bitcoin, mas se tornaram obsoletos, e agora s‹o usados para buscar endere•os vanity. As buscas por endere•os vanity em hardwares usando mœltiplas placas de v’deo s‹o muito mais r‡pidas do que as realizadas em um computador desktop comum. Outra maneira de encontrar um endere•o vanity Ž pagando para um pool de mineradores vanity, como por exemplo o Vanity Pool. Pool. Um pool Ž um servi•o que permite que aqueles que tenham hardware com placas de v’deo (GPU) possam ganhar bitcoin por buscarem endere•os vanity para outros usu‡rios. Por uma pequena quantia (0,01 bitcoin, ou aproximadamente 5 d—lares, na Žpoca que esse livro foi escrito), a Eugnia pode pagar para alguŽm fazer a busca de um endere•o vanity com sete caracteres em poucas horas, ao invŽs de ter que usar seu pr—prio computador durante meses. A gera•‹o de um endere•o vanity Ž um exerc’cio de for•a-bruta: s‹o criadas chaves aleat—rias, e verifica-se cada uma se corresponde ao padr‹o desejado. As chaves s‹o criadas repetidamente atŽ que se consiga atingir o padr‹o desejado. Minerador de endere•o vanity vanity mostra um exemplo de um "minerador vanity", um programa projetado para buscar endere•os vanity, escrito em C++. O exemplo usa a livraria libbitcoin, que n—s apresentamos em [alt_libraries] [alt_libraries].. Example 8. Minerador Minerador de endere•o endere•o vanity
#include oin.hpp> // The string we are searching for const std::string search = "1kid"; // Generate a random secret key. A random 32 bytes. bc::ec_secret random_secre random_secret(std::defaul t(std::default_random_engi t_random_engine& ne& engine); // Extract the Bitcoin address from an EC secret. std::string bitcoin_address(const bitcoin_address(const bc::ec_secr bc::ec_secret& et& secret); // Case insensitive comparison with the search string. bool match_found(const std::string& address); int main() { // random_device on Linux uses "/dev/urando "/dev/urandom" m" // CAUTION: Depending on implementati implementation on this RNG may not be secure enough! // Do not use vanity keys generated by this example in production std::random_device std::random _device random; std::default_random_engi std::defaul t_random_engine ne engine(rando engine(random()); m()); // Loop continuously continuously... ... while (true) {
45
// Generate a random secret. bc::ec_secrett secret = random_secre bc::ec_secre random_secret(engine); t(engine); // Get the address. std::string address = bitcoin_addre bitcoin_address(secret); ss(secret); // Does it match our search string? (1kid) if (match_found( (match_found(address)) address)) { // Success! std::cout << "Found vanity address! " << address << std::endl; std::cout << "Secret: " << bc::encode_he bc::encode_hex(secret) x(secret) << std::endl; return 0; } } // Should never reach here! return 0; } bc::ec_secret random_secre random_secret(std::defaul t(std::default_random_engi t_random_engine& ne& engine) { // Create new secret... bc::ec_secret bc::ec_secr et secret; // Iterate through every byte setting a random value... for (uint8_t& byte: secret) byte = engine() % std::numeric_ std::numeric_limits::max(); t>::max(); // Return result. return secret; } std::string bitcoin_address(const bitcoin_address(const bc::ec_secr bc::ec_secret& et& secret) { // Convert secret to pubkey... bc::ec_pointt pubkey = bc::secret_to bc::ec_poin bc::secret_to_public_key(s _public_key(secret); ecret); // Finally create address. bc::payment_address bc::payment _address payaddr; bc::set_public_key(payad bc::set_pub lic_key(payaddr, dr, pubkey); // Return encoded form. return payaddr.encod payaddr.encoded(); ed(); } bool match_found(const std::string& address) { auto addr_it = address.beg address.begin(); in(); // Loop through the search string comparing it to the lower case // character of the supplied address. for (auto it = search.begin search.begin(); (); it != search.end search.end(); (); ++it, ++addr_it) if (*it != std::tolowe std::tolower(*addr_it)) r(*addr_it)) return false; // Reached end of search string, so address matches. 46
return true; }
NOTE
O exemplo acima usa std::random_device. Dependendo da implementa•‹o ele pode repletir um gerador de nœmero aleat—rio criptograficamente seguro fornecido pelo sistema operacional. No caso de um sistema operacional do tipo Unix, como o Linux, ele o obtŽm a partir de /dev/urandom. O gerador de nœmero aleat—rio utilizado aqui Ž usado apenas para fins demonstrativos, n‹o sendo apropriado para gerar chaves de bitcoin com qualidade suficiente para ser usadas em produ•‹o, j‡ que ele n‹o Ž implementado com seguran•a suficiente.
O c—digo de exemplo deve ser compilado usando um compilador C e vinculado ˆ livraria libbitcoin (que deve ser previamente instalada no sistema). Para executar o exemplo, rode o execut‡vel vanityminer++ sem nenhum par‰metro (ver Compilando e executando o exemplo de minerador vanity ) e ele ir‡ tentar encontrar um endere•o vanity que se inicie com "1kid". Example 9. Compilando Compilando e executando executando o exemplo de minerador minerador vanity vanity
$ # Compila o c —digo com g++ $ g++ -o vanity-miner vanity-miner.cpp $(pkg-config $(pkg-config --cflags --libs libbitcoin) $ # Executa o exemplo $ ./vanity-mi ./vanity-miner ner Endere•o vanity encontrado! 1KiDzkG4MxmovZryZRj8tK81oQRhbZ46 1KiDzkG4MxmovZryZRj8tK81oQRhbZ46YT YT Secret: 57cc268a05f8 57cc268a05f83a23ac9d930b 3a23ac9d930bc8565bac4e277 c8565bac4e277055f4794cbd1a 055f4794cbd1a39e5e71c038f3 39e5e71c038f3ff $ # Executa-o novamente para um resultado diferente $ ./vanity-mi ./vanity-miner ner Endere•o vanity encontrado! 1Kidxr3wsmMzzouwXibKfwTYs5Pau8TU 1Kidxr3wsmMzzouwXibKfwTYs5Pau8TUFn Fn Secret: 7f65bbbbe6d8 7f65bbbbe6d8caae74a0c6a0 caae74a0c6a0d2d7b5c6663d7 d2d7b5c6663d71b60337299a1a 1b60337299a1a2cf34c04b2a62 2cf34c04b2a6233 # Use "time" para ver quanto tempo demora para se encontrar um resultado $ time ./vanity-mine ./vanity-minerr Endere•o vanity encontrado! 1KidPWhKgGRQWD5PP5TAnGfDyfWp5yce 1KidPWhKgGRQWD5PP5TAnGfDyfWp5yceXM XM Secret: 2a802e7a53d8 2a802e7a53d8aa237cd05937 aa237cd059377b616d2bfcfa4 7b616d2bfcfa4b0140bc85fa00 b0140bc85fa008f2d3d4b22534 8f2d3d4b2253499 real 0m8.868s user 0m8.828s sys 0m0.035s
O c—digo de exemplo ir‡ levar alguns segundos para encontrar uma correspondncia ao padr‹o de trs caracteres "kid", como n—s podemos ver quando usamos o comando time do Unix para medir o tempo de execu•‹o. Mude o padr‹o search no c—digo-fonte e veja como pode ser mais demorado para se conseguir padr›es de quatro ou cinco caracteres!
47
Seguran•a do endere•o vanity
Os endere•os vanity podem ser usados tanto para melhorar quanto para burlar medidas de seguran•a; eles s‹o literalmente uma faca de dois gumes. Quando usado para melhorar a seguran•a, um endere•o diferenciado torna mais dif’cil para que hackers substituam o seu pr—prio endere•o, fazendo com que seus consumidores a pagarem para eles, ao invŽs de para voc. Infelizmente, os endere•os vanity tambŽm tornam poss’vel que qualquer um cria um endere•o que se pare•a com qualquer endere•o aleat—rio, ou mesmo outro endere•o vanity, vanity, dessa maneira enganando seus consumidores. c onsumidores. A Eugnia poderia divulgar um endere•o gerado aleatoriamente (por exemplo, 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy) para que as pessoas enviem suas doa•›es. Ou ela poderia gerar um endere•o vanity que come•a com 1Kids, para torn‡-lo mais atraente. Em ambos os casos, um dos riscos de se usar um endere•o fixo œnico (ao invŽs de um endere•o din‰mico separado para cada doador) Ž que o ladr‹o pode ser capaz de se infiltrar em seu site e substitu’-lo pelo seu pr—prio endere•o, desviando as doa•›es que voc receberia. Se voc divulgou seu endere•o de doa•‹o em v‡rios lugares diferentes, seus usu‡rios podem inspecionar visualmente o endere•o antes de fazer um pagamento para se assegurarem que ele Ž o mesmo que eles viram em seu site, e-mail ou flyer. No caso de um endere•o aleat—rio como 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy, o usu‡rio comum talvez inspecionar‡ apenas os primeiros caracteres "1J7mdg" e estar‡ satisfeito se o endere•o corresponder. Usando um gerador de endere•os vanity, alguŽm pode roub‡-lo ao rapidamente criar um endere•o que se pare•a com o verdadeiro, com apenas os primeiros caracteres iguais, como demonstrado em Gerando endere•os vanity para corresponder a um endere•o aleat—rio . Table 11. Gerando endere•os vanity para corresponder a um endere•o aleat—rio Endere•o Aleat—rio Original
1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy
Vanity (correspondncia de 4 caracteres)
1J7md1QqU4LpctBetHS2ZoyLV5d6dShhEy
Vanity (correspondncia de 5 caracteres)
1J7mdgYqyNd4ya3UEcq31Q7sqRMXw2XZ6n
Vanity (correspondncia de 6 caracteres)
1J7mdg5WxGENmwyJP9xuGhG5KRzu99BBCX
Um endere•o vanity aumenta a seguran•a? Se Eugenia gerar o endere•o vanity 1Kids33q44erFfpeXrmDSz7zEqG2FesZEN, os usu‡rios provavelmente ir‹o olhar para a palavra com padr‹o vanity e alguns caracteres alŽm, por exemplo percebendo a parte "1Kids33" do endere•o. Isso iria for•ar um hacker a gerar um endere•o vanity que corresponde a pelo menos seis caracteres (dois a mais), tendo que se esfor•ar 3.364 vezes mais (58 × 58) do que o que a Eugenia teve que se esfor•ar para gerar o seu endere•o vanity de quatro caracteres. Essencialmente, o esfor•o que a Eugenia teve que fazer (ou pagar para um pool vanity fazer) acaba exigindo que o hacker produza um padr‹o vanity mais longo. Se a Eugenia pagar para um pool gerar um endere•o vanity de 8 caracteres, o hacker teria que fazer um esfor•o para produzir um endere•o de 10 caracteres, que Ž invi‡vel de ser feito em um computador pessoal e muito caro para ser obtido, atŽ mesmo em equipamentos de minera•‹o vanity ou em um pool de vanity. O que tem um pre•o acess’vel para a Eugenia se torna muito caro para o hacker, especialmente se a recompensa potencial pela fraude n‹o Ž alta o suficiente para cobrir o custo da gera•‹o do endere•o vanity. vanity. 48
Carteiras em papel As carteiras em papel s‹o chaves privadas de bitcoin impressas em papel. Frequentemente as carteiras em papel tambŽm incluem o endere•o bitcoin para convenincia, mas isso n‹o Ž necess‡rio, j‡ que eles podem ser derivados a partir da chave privada. As carteiras em papel s‹o uma maneira muito efetiva para se criar backups ou armazenamento offline de bitcoins, tambŽm conhecidos como "armazenamento frio". Como mecanismo de backup, uma carteira em papel pode fornecer seguran•a contra a perda da chave devido a um problema no computador como uma falha no disco r’gido, roubo ou o apagamento acidental. Como mecanismo de "armazenamento frio", se as chaves da carteira de papel forem geradas offline e nunca forem armazenadas em um computador ou dispositivo, elas estar‹o muito mais protegidas contra hackers, key-loggers e outras amea•as onlines. As carteiras em papel possuem muitos formatos, tamanhos e estilos, mas basicamente elas s‹o apenas uma chave privada e um endere•o impressos no papel. A A forma mais simples de uma carteira em papelÑuma impress‹o contendo um endere•o bitcoin e a sua chave privada. mostra a forma mais simples de carteira em papel. Table 12. A forma mais simples de uma carteira em papelÑuma impress‹o contendo um endere•o bitcoin e a sua chave privada. Endere•o Pœblico
Chave Privada (WIF)
1424 14 24C2 C2F F4b 4bC C9J 9Jid idNj NjjT jTU UZC ZCb bUxv xv6S 6Sa1 a1Mt Mt62 62xx
5J3mB 5J3m BbA bAH5 H58C 8CpQ pQ3Y 3Y5R 5RNJ NJpU pUKP KPE6 E62S 2SQ Q5t 5tffcv cvU2 U2JJpb pbnk nk eyhfsYB1Jcn
Carteiras de papel podem ser geradas facilmente utilizando uma ferramenta como um gerador JavaScript local em bitaddress.org . Essa p‡gina contŽm todo o c—digo necess‡rio para gerar chaves e carteiras de papel, mesmo quando o computador estiver completamente desconectado da internet. Para us‡-la, salve a p‡gina HTML em seu disco local ou em um drive USB externo. Desconecte-se da internet e abra o arquivo em um navegador. ƒ ainda melhor se voc fizer um boot do seu computador usando um sistema operacional primitivo, como um sistema operacional Linux que fa•a boot a partir de CD-ROM. Quaisquer chaves geradas offline com essa ferramenta podem ser impressas com uma impressora local usando-se um cabo USB (n‹o use wi-fi), logo, criando uma carteira de papel cujas chaves existem somente no papel e que nunca foram armazenadas em nenhum sistema online. Guarde essas carteiras de papel em um cofre ˆ prova de incndios e "envie" alguns bitcoins para os endere•os bitcoin contidos nelas, para implementar uma solu•‹o simples de "armazenamento frio (cold)", porŽm muito efetiva. Um exemplo de uma carteira de papel simples originada em bitaddress.org demonstra uma carteira de papel gerada a partir do site bitaddress.org.
49
Figure 13. Um exemplo de uma carteira carteira de papel simples simples originada em bitaddress.org bitaddress.org
A desvantagem desse sistema simples de carteira de papel Ž que as chaves impressas s‹o vulner‡veis a roubos. Um ladr‹o que tenha acesso ao papel poder‡ roubar ou fotografar as chaves, podendo gastar os bitcoins vinculados aos endere•os. Uma sistema mais avan•ado de armazenamento de carteira em papel usa as chaves privadas criptografadas em BIP0038. As chaves impressas na carteira de papel s‹o protegidas por uma senha que o dono memorizou. Sem Sem essa senha, as chaves criptografadas criptografadas s‹o inœteis. No entanto, elas ainda s‹o melhores que uma carteira protegida por uma senha, pois essas chaves nunca estiveram online e ainda precisam ser fisicamente extra’das de um cofre ou outro armazenamento f’sico seguro. Um exemplo de carteira c arteira de papel criptografada no site bitaddress.org. A senha Ž "test". mostra uma carteira carteira de papel com uma chave privada privada criptografada criptografada (BIP0038) criada no site bitaddress.org.
Figure 14. Um exemplo de carteira carteira de papel criptografada criptografada no site bitaddress.org. bitaddress.org. A senha Ž "test". "test".
50
WARNING
Embora voc possa depositar fundos v‡rias vezes em uma carteira de papel, o correto Ž voc sacar todos os fundos uma œnica vez, gastando tudo. Isso acontece porque no processo de destravamento e de gastar os fundos algumas carteiras podem gerar um endere•o de troco se voc gastar menos que toda a quantia contida na carteira de papel. Adicionalmente, se o computador que voc usa para assinar a transa•‹o estiver comprometido (hackeado), voc correr‡ o risco de expor a chave privada. Ao gastar todo o saldo da carteira de papel uma œnica vez, voc reduz o risco de sua chave ser comprometida. Se voc precisa gastar apenas uma pequena quantidade, envie os fundos remanescentes para uma nova carteira de papel na mesma transa•‹o.
As carteiras em papel tem v‡rios designs e tamanhos, alŽm de diferentes caracter’sticas. Algumas s‹o feitas para serem dadas de presente, outras s‹o tem‡ticas, como as de Natal e Ano Novo. Outras s‹o projetadas para armazenar em um cofre do banco com a chave privada escondida em algum lugar, seja atravŽs de adesivos opacos com raspadinhas, ou adesivos dobrados e lacrados. As figuras a mostram v‡rios exemplos de carteiras em papel com diferentes caracter’sticas de seguran•a e backup.
Figure 15. Um exemplo de uma carteira carteira em papel feita feita em bitcoinpaperwallet.com bitcoinpaperwallet.com com a chave privada impressa numa aba dobr‡vel.
Figure 16. Uma Uma carteira de papel papel do site bitcoinpaperwallet.com bitcoinpaperwallet.com com com a chave privada escondida. escondida.
Outros designs apresentam c—pias adicionais da chaves e dos endere•os, na forma de canhotos
51
destac‡veis semelhantes a canhotos de ingressos, permitindo que voc armazene mœltiplas c—pias para proteg-las do fogo, enchentes e outros desastres naturais.
Figure 17. Um exemplo de uma carteira carteira em papel com um canhoto contendo contendo c—pias adicionais adicionais das chaves como backup
52
Transa•›es Introdu•‹o As transa•›es s‹o a parte mais importante do sistema bitcoin. Todo o restante no bitcoin Ž projetado para garantir que as transa•›es possam ser criadas, propagadas na rede, validades e por mim adicionadas ao registro global das transa•›es (a blockchain). As t ransa•›es s‹o estruturas de dados que codificam a transferncia de valor entre os participantes no sistema bitcoin. Cada transa•‹o Ž uma entrada pœblica na blockchain do bitcoin, o registro geral de dupla-entrada. Neste cap’tulo, n—s iremos examinar as v‡rias formas de transa•›es, o que elas contm, como cri‡-las, como elas s‹o verificadas e como elas se tornam parte do registro permanente de todas as transa•›es.
Ciclo de Vida da Transa•‹o O ciclo de vida de uma transa•‹o come•a com a cria•‹o da transa•‹o, tambŽm conhecido como origina•‹o. A transa•‹o Ž ent‹o assinada com uma ou mais assinaturas indicando a autoriza•‹o para gastar os fundos que s‹o indicados pela transa•‹o. A transa•‹o Ž ent‹o transmitida na rede bitcoin, onde cada nodo (participante) da rede a valida e a propaga atŽ que ela atinja (quase) todos os nodos na rede. Por fim, a transa•‹o Ž verificada por um nodo minerador e Ž inclu’da em um bloco de transa•›es que Ž registrado na blockchain. Ao ser registrada na blockchain e confirmada por um nœmero subsequente suficiente de blocos (confirma•›es), a transa•‹o Ž uma parte permanente do registro do bitcoin e Ž aceita como v‡lida por todos os participantes. Os fundos alocados para um novo dono atravŽs da transa•‹o agora podem ser gastos em uma nova transa•‹o, estendendo a cadeia de possa e iniciando novamente o ciclo de vida de uma transa•‹o.
Criando Transa•›es Pode ser œtil pensar em uma transa•‹o da mesma maneira que um cheque de papel. Como um cheque, a transa•‹o Ž um instrumento que expressa a inten•‹o de se transferir dinheiro e ela n‹o Ž vis’vel ao sistema financeiro atŽ que seja enviada para execu•‹o/dep—sito. Como um cheque, quem origina a transa•›a n‹o tem a obriga•‹o de ser aquele que assina a transa•‹o. t ransa•‹o. As transa•›es podem ser criadas online ou offline por qualquer pessoa, mesmo se a pessoa que estiver criando a transa•‹o n‹o seja a pessoa que assinar‡ a autoriza•‹o para gastar os fundos. Por exemplos, um funcion‡rio de contabilidade poder‡ processar cheques pag‡veis pela assinatura do CEO. De maneira similar, um funcion‡rio de contabilidade pode criar transa•›es bitcoin e ent‹o fornec-las para que o CEO aplique suas assinaturas digitais para torn‡-las v‡lidas. Enquanto um cheque tradicional refere-se a uma conta banc‡ria espec’fica como a fonte para os fundos, uma transa•‹o bitcoin refere-se a uma transa•‹o prŽvia como sua fonte, ao invŽs de uma conta banc‡ria. Assim que a transa•‹o for criada, ela Ž assinada pelo dono (ou donos) dos fundos de origem. Ela Ž 1
propriamente formada e assinada, a transa•‹o assinada agora Ž v‡lida e contŽm toda a informa•‹o necess‡ria para executar a transferncia dos fundos. Finalmente, a transa•‹o v‡lida tem que atingir a rede bitcoin para que ela possa ser propagada atŽ atingir um minerador para inclu’-la no registro pœblico (a blockchain).
Transmitindo Transa•›es para a Rede Bitcoin Primeiro, uma transa•‹o precisa chegar ˆ rede bitcoin para que ela seja propagada e inclu’da na blockchain. Basicamente, uma transa•‹o bitcoin Ž simplesmente 300 a 400 bytes de dados e precisa atingir qualquer um das dezenas de milhares de nodos bitcoin. Aqueles que enviam n‹o precisam confiar nos nodos que eles usam para transmitir a transa•‹o, contanto que eles usem mais de um para garantir a sua propaga•‹o. Os nodos n‹o precisam confiar em quem envia, nem precisam saber a "identidade" de quem envia. Como a transa•‹o Ž assinada e n‹o contŽm informa•›es confidenciais, chaves privadas ou credenciais, ela pode ser transmitida publicamente usando qualquer transporte de rede que seja conveniente. Ao contr‡rio das transa•›es de cart›es de crŽdito, por exemplo, que contŽm informa•›es sens’veis e s— podem ser transmitidas em redes criptografadas, uma transa•‹o bitcoin pode ser enviada em qualquer rede. Contanto que a transa•‹o possa atingir um nodo bitcoin que a propague para rede bitcoin, n‹o interessa a maneira como ela ser‡ transportada para o primeiro nodo. Portanto, as transa•›es bitcoin podem ser transmitidas para a rede bitcoin atravŽs de redes inseguras como WiFi, Bluetooth, NFC, Chirp, c—digos de barras ou ao copiar-se e colar a partir de um formul‡rio na internet. Em casos extremos, uma transa•‹o bitcoin poderia ser transmitida atravŽs de um pacote de r‡dio, relay satŽlite ou em ondas curtas usando transmiss‹o burst, espectro amplo ou pulando frequncias para evitar detec•‹o e interferncias. Uma transa•‹o bitcoin poderia ser codificada atŽ mesmo como smileys (emoticons) e postada em um f—rum pœblico ou enviada como uma mensagem de texto ou uma mensagem de chat Skype. O Bitcoin transformou o dinheiro em uma estrutura de dados, tornando praticamente imposs’vel que alguŽm seja impedido de criar e executar uma transa•‹o bitcoin.
Propagando Transa•›es na Rede Bitcoin Assim que a transa•‹o Ž enviada para qualquer nodo conectado ˆ rede bitcoin, a transa•‹o ser‡ validada por aquele nodo. Se for v‡lida, o nodo ir‡ propag‡-la para outros nodos com os quais ele est‡ conectado, e uma mensagem de sucesso ir‡ retornar na mesma hora para quem originou a transa•‹o. Se a transa•‹o for inv‡lida, o nodo ir‡ rejeit‡-la e retornar‡ na mesma hora uma mensagem de rejei•‹o para quem originou a transa•‹o. A rede bitcoin Ž uma rede par-a-par, o que significa que cada n— bitcoin est‡ conectado a alguns outros n—s bitcoin que ele descobre durante a inicializa•‹o atravŽs do protocolo par-a-par. Toda a rede forma uma emaranhado frouxamente conectado sem uma topologia fixa ou qualuqer estrutura, tornando todos os n—s pares iguais. As mensagens, incluindo transa•›es e blocos, s‹o propagadas a de cada n— a todos os pares aos quais ele est‡ conectado, um processo chamado "flooding" (inunda•‹o). Uma transa•‹o recŽm validada e injetada em qualquer n— da rede ser‡ enviada a todos os n—s conectados a ele (vizinhos), cada um dos quais enviar‡ a transa•‹o a todos os seus vizinhos, e assim por diante. Dessa maneira, dentro de alguns segundos uma transa•‹o v‡lida ser‡ propagada numa onda
2
exponencialmente expandida expandida atravŽs da rede atŽ que todos os n—s da rede a recebam. A rede bitcoin Ž projetada para propagar transa•›es e blocos para todos os nodos de uma maneira eficiente e flex’vel que seja resistente a ataques. Para prevenir spam, ataques DOS ou outros ataques maliciosos contra o sistema bitcoin, cada nodo valida independentemente cada transa•‹o antes de propag‡-la adiante. Uma transa•‹o mal formada n‹o ir‡ passar por um nodo sequer. As regras atravŽs das quais as transa•›es s‹o validadas ser‹o explicadas em maiores detalhes em [tx_verification] [tx_verification]..
Estrutura da Transa•‹o Uma transa•‹o Ž uma estrutura de dados que codifica uma transferncia de valor a partir de uma fonte de fundos, chamada de input, para um destino, chamado de output. Os inputs e outputs de transa•‹o n‹o s‹o relacionados a contas ou identidades. Ao invŽs disso, voc deveria imagin‡-los como quantidades de bitcoinÑpeda•os de bitcoinÑque s‹o bloqueados com uma senha secreta espec’fica que somente o dono, ou a pessoa que conhece a senha, pode desbloque‡-los. Uma transa•‹o contŽm v‡rios campos, como demonstrado em A estrutura de uma transa•‹o transa•‹o.. Table 1. A estrutura de uma transa•‹o
Tamanho
Campo
Descri•‹o
4 bytes
Vers‹o
Especifica quais regras essa transa•‹o ir‡ seguir
1Ð9 bytes (VarInt)
Input Counter
Quantos inputs ser‹o inclu’dos
Variable
Inputs
Um ou mais inputs de transa•‹o
1Ð9 bytes (VarInt)
Output Counter
Quantos outputs s‹o inclu’dos
Variable
Outputs
Um ou mais outputs de transa•‹o
4 bytes
Locktime
Data e hora no formato Unix (timestamp) ou nœmero de bloco
3
Locktime da Transa•‹o Locktime (tempo de travamento), tambŽm conhecido como nLockTime, devido ˆ vari‡vel com este nome utilizada no cliente de referncia, define o tempo mais precoce que uma transa•‹o Ž valida e pode ser transmitida na rede ou adicionada ˆ cadeia de blocos (blockchain). Ele Ž definido como zero na maioria das transa•›es, indicando uma propaga•‹o e execu•‹o imediatas. Se o locktime Ž diferente de zero e abaixo de 500 milh›es, ele Ž interpretado como uma altura de bloco, significando que a transa•‹o n‹o Ž v‡lida e que ela n‹o ser‡ transmitida ou inclu’da na cadeia de blocos antes que a altura de bloco especificada seja atingida. Se ele for acima de 500 milh›es, ele Ž interpretado como uma timestamp Unix Epoch (segundos desde 1-Jan-1970) e a transa•‹o n‹o Ž valida atŽ que tal t al tempo seja antingido. As transa•‹o com locktime especificando um bloco ou um tempo no futuro precisam ser mantidas pelo sistema de origem e transmitidas ˆ rede blockchain apenas ap—s elas se tornarem v‡lidas. O uso do locktime Ž o equivalente a assinar um cheque prŽ-datado.
Inputs e Outputs das Transa•›es A matŽria-prima principal de uma transa•‹o bitcoin Ž um output de transa•‹o n‹o-gasto, ou UTXO. Os UTXOs s‹o peda•os indivis’veis da moeda bitcoin vinculados a um dono espec’fico, registrados na blockchain, e reconhecidos como unidades de moeda pela rede. A rede bitcoin rastreia todos os UTXOs dispon’veis (n‹o-gastos), que atualmente s‹o milh›es. Quando um usu‡rio recebe um bitcoin, a quantia Ž registrada na blockchain como um UTXO. Portanto, o bitcoin de um usu‡rio pode estar disperso como UTXOs entre centenas de transa•›es e centenas de blocos. Como efeito, n‹o existe algo como um armazenamento do saldo de um endere•o ou conta bitcoin; existem apenas UTXOs dispersos, vinculados a seus respectivos donos. O conceito de saldo de um usu‡rio de bitcoin Ž algo criado pelos aplicativos de carteira. A carteira calcula o saldo do usu‡rio ao escanear a blockchain e ao somar todos os UTXOs que pertecem ˆquele usu‡rio. TIP
N‹o h‡ contas correntes ou saldos no bitcoin; existem apenas outputs de transa•›es n‹o gastos (UTXO) espalhados na blockchain.
Um UTXO pode ter um valor arbitr‡rio denominado como um mœltiplo de satoshis. Assim como os d—lares podem ser divididos para duas casas decimais (os centavos), os bitcoin podem ser dividos atŽ oito casas decimais (os satoshis). Embora o UTXO possa ser qualquer valor arbitr‡rio, uma vez criado ele Ž indivis’vel assim como uma moeda que n‹o pode ser cortada pela metade. Se um UTXO Ž maior do que o valor desejado de uma transa•‹o, ele precisa ser totalmente consumido e um troco deve ser gerado na transa•‹o. Em outras palavras, se voc possui 20 UTXOs de bitcoin, e voc quer pagar 1 bitcoin, a sua transa•‹o precisa consumir todos os 20 UTXOs de bitcoin e produzir duas sa’das (outputs): uma que paga 1 bitcoin para o recipiente e outra que paga 19 bitcoins em troco de volta para a sua carteira. Como consequncia disso, a maioria das transa•›es de bitcoins ir‹o gerar troco. Imagine um consumidora comprando uma bebida de $1,50, pegando sua carteira e tentando achar uma combina•‹o de moedas e notas para atingir o valor de $1,50. A consumidora poder‡ escolher o
4
troco exato se dispon’vel (uma nota de um d—lar e duas moedas de 25 centavos), ou uma combina•‹o de pequenas denomina•›es (6 moedas de 25 centavos), ou, se necess‡rio, uma unidade maior como uma nota de 5 d—lares. Se ela der dinheiro demais, digamos $5, ao dono da loja, ela esperar‡ um troco de $3,50, o qual ela ir‡ colocar em sua carteira e o ter‡ dispon’vel para para transa•›es futuras. De maneira semelhante, uma transa•‹o bitcoin precisa ser criada a partir de um UTXO do usu‡rio em quaisquer denomina•›es que o usu‡rio tenha dispon’vel. Os usu‡rios n‹o podem dividir um UTXO pela metade, da mesma maneira que eles n‹o podem cortar uma nota de um d—lar pela metade e us‡la no mercado. O aplicativo de carteira do usu‡rio tipicamente ir‡ selecionar entre os UTXOs dispon’veis do usu‡rio v‡rias unidades para compor uma quantia maior ou igual ao valor de transa•‹o desejado. Assim como na vida real, a aplica•‹o bitcoin possui v‡rias estratŽgias para satisfazer a quantia de compra: combinar v‡rias unidades menores, procurar pelo troco exato ou usar uma unidade œnica maior que o valor da transa•‹o e receber o troco. Toda essa administra•‹o completa dos UTXOs gast‡veis Ž feita de maneira autom‡tica pela carteira do usu‡rio, e os usu‡rios sequer tomam conhecimento dela. A administra•‹o das UTXOs s— Ž relevante se voc for um programador construindo transa•›es cruas (raw) a partir de UTXOs. Os UTXOs consumidos por uma transa•‹o s‹o chamados de entradas (inputs) de transa•‹o, e os UTXOs criados por uma transa•‹o s‹o chamados de sa’das (outputs) de transa•‹o. Dessa maneira, partes de valor do bitcoin movem adiante de dono para dono em uma cadeia de transa•›es que consome e cria UTXOs. As transa•›es consomem UTXOs quando os desbloqueiam com a assinatura do dono atual, e criam UTXOs quando os vinculam ao endere•o bitcoin do novo dono. A exce•‹o para a cadeia de output e input Ž um tipo t ipo especial de transa•‹o chamada transa•‹o coinbase, que Ž a primeira transa•‹o em cada bloco. Essa transa•‹o Ž inserida no bloco pelo minerador "vencedor" e cria novos bitcoins que ser‹o pagos para o minerador como uma recompensa por ter conseguido minerar o bloco. ƒ assim que a oferta monet‡ria do bitcoin Ž criada durante o processo de minera•‹o, como veremos no [ch8] [ch8]..
TIP
E o que vem primeiro? Inputs ou outputs, a galinha ou o ovo? Falando estritamente, os outputs vem primeiro porque as transa•›es coinbase, que geram os novos bitcoins, n‹o tem inputs e criam outputs a partir do nada.
Outputs de Transa•›es Toda transa•‹o bitcoin cria sa’das (outputs), que s‹o gravadas no registro do bitcoin (a cadeia de blocos). Quase todas essas sa’das (outputs), com uma exce•‹o (ver Output de dados (OP_RETURN)) (OP_RETURN) ) criam partes de bitcoin gast‡veis chamadas _outputs de transa•‹o n‹o-gastos ou UTXO (do ingls Unspent Transaction Outputs), que s‹o ent‹o reconhecidas por toda a rede e se tornam dispon’veis para que o dono gaste em uma transa•‹o futura. Quando se envia um bitcoin para alguŽm, na verdade se est‡ criando uma output de transa•‹o n‹o-gasto (UTXO) registrado para o endere•o dessa pessoa e tornando-o dispon’vel para ser gasto. Os UTXOs s‹o monitorados por todos os nodos completos de bitcoin como um conjunto de dados 5
chamado de conjunto UTXO ("UXTO set") ou pool UTXO, que Ž armazenado em um banco de dados. As novas transa•›es consomem (gastam) um ou mais desses outputs que est‹o no conjunto UTXO. Os outputs de transa•›es consistem de duas partes: ¥ Uma quantida quantidade de de bitcoin, bitcoin, denomin denominados ados em satoshis, a menor unidade bitcoin ¥ Um script de travamento, tambŽm conhecido como uma "onera•‹o" que "trava" essa quantia ao especificar os requisitos que precisam ser preenchidos para poder se gastar o output. A linguagem de script da transa•‹o, usada no script de travamento mencionado anteriormente, Ž discutida em detalhes em Scripts de Transa•‹o e Linguagem de Script. Script . A estrutura de um output de transa•‹o demonstra transa•‹o demonstra a estrutura de um output de transa•‹o. Table 2. A estrutura de um output de transa•‹o
Tamanho
Campo
Descri•‹o
8 bytes
Quantia
Quantia em Bitcoin designada em satoshis (10-8 bitcoin)
1-9 bytes (VarInt)
Locking-Script Size
Comprimento do script de travamento em bytes, para seguir
Variable
Locking-Script
Um script definindo as condi•›es necess‡rias para se gastar o output
Em Um script que chama o API da blockchain.info para encontrar o UTXO relacionado a um endere•o , n—s usamos o API da blockchain.info para encontrar os outputs n‹o-gastos (UTXO) de um endere•o espec’fico.
6
Example 1. Um script que chama chama o API da blockchain.info blockchain.info para para encontrar o UTXO relacionado relacionado a um endere•o
# get unspent outputs from blockchain API import json import requests # example address address = '1Dorian4RoX '1Dorian4RoXcnBv9hnQ4Y2C1 cnBv9hnQ4Y2C1an6NJ4UrjX' an6NJ4UrjX' # The API URL is https://blockchain.info/unspent?active= # It returns a JSON object with a list "unspent_outputs", containing containing UTXO, like this: #{ "unspent_outputs":[ # { # "tx_hash":"ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad9084062167", # "tx_index":51919767, # "tx_output_n": "tx_output_n ": 1, # "script":"76a9148c7e252f8d64b0b6e313985915110fcfefcf4a2d88ac", # "value": 8000000, # "value_hex": "7a1200", # "confirmations":28691 # }, # ... #]} resp = requests.get( requests.get('https://blo 'https://blockchain.info/ ckchain.info/unspent?activ unspent?active=%s' e=%s' % address) utxo_set = json.loads(re json.loads(resp.text)["uns sp.text)["unspent_outputs" pent_outputs"]] for utxo in utxo_set: print "%s:%d - %ld Satoshis" % (utxo['tx_h (utxo['tx_hash'], ash'], utxo['tx_out utxo['tx_output_n'], put_n'], utxo['value'])
Ao executar o script, n—s enxergamos uma lista de IDs de transa•‹o, uma v’rcula, um nœmero de ’ndice do output de transa•‹o n‹o-gasta (UTXO) espec’fico e o valor daquele UTXO em satoshis. O script de travamento n‹o Ž demonstrado no output em Executando o script get-utxo.py. get-utxo.py .
7
Example 2. Executando Executando o script script get-utxo.py get-utxo.py
$ python get-utxo.py ebadfaa92f1fd29e2fe296eda7 ebadfaa92f1fd 29e2fe296eda702c48bd11ffd5 02c48bd11ffd52313e986e99dd 2313e986e99ddad9084062167 ad9084062167:1 :1 6596fd070679de96e405d52b51 6596fd070679d e96e405d52b51b8e1d64402910 b8e1d644029108ec4cbfe45145 8ec4cbfe451454486796a1ecf 4486796a1ecf:0 :0 Satoshis 74d788804e2aae10891d72753d 74d788804e2aa e10891d72753d1520da1206e6f 1520da1206e6f4f20481cc1555 4f20481cc1555b7f2cb44aca0 b7f2cb44aca0:0 :0 b2affea89ff82557c60d635a2a b2affea89ff82 557c60d635a2a3137b8f88f12e 3137b8f88f12ecec85082f7d0a cec85082f7d0a1f82ee203ac4 1f82ee203ac4:0 :0 Satoshis ...
- 8000000 Satoshis - 16050000 - 5000000 Satoshis - 10000000
Condi•›es para gastar (entravamentos) Os outputs de transa•‹o associam uma quantia espec’fica (em satoshis) a um script espec’fico de travamento ou de onera•‹o que define a condi•‹o que deve ser preenchida para que aquela quantia possa ser gasta. Na maioria dos casos, o script de travamento ir‡ travar o output para um endere•o bitcoin espec’fico, transferindo a posse dessa quantia para o novo dono. Quando a Alice pagou o BobÕs Cafe por uma x’cara de cafŽ, a transa•‹o dela criou um output de 0,015 bitcoins onerados ou travador ao endere•o de bitcoin da cafeteria. Esse output de 0,015 bitcoin foi registrado na blockchain e se tornou parte do conjunto de Output de Transa•‹o N‹o-gasta, ou seja, ele apareceu na carteira do Bob como parte de um saldo dispon’vel. Quando o Bob resolver gastar essa quantia, a transa•‹o dele ir‡ liberar essa onera•‹o, onera•‹o, destravando o output ao forncer um script de destravamento que contenha uma assinatura da chave privada do Bob.
Inputs de transa•›es Em termos simples, os inputs de transa•‹o apontam para os UTXOs. Eles apontam para um UTXO espec’fica atravŽs da referncia ao hash da transa•‹o e o nœmero da sequncia onde o UTXO est‡ registrado na blockchain. Para gastar um UTXO, um input de transa•‹o tambŽm inclui scripts de destravamento para satisfazer as condi•›es de gasto definidas pelo UTXO. O script de destravamento Ž geralmente uma assinatura que comprova a posse do endere•o endere•o bitcoin que est‡ no script de travamento. Quando os usu‡rios fazem um pagamento, a carteira deles constr—i uma transa•‹o ao selecionar a partir do UTXO dispon’vel. Por exemplo, para fazer um pagamento de 0,015 bitcoin, o aplicativo de carteira pode selecionar um UTXO de 0,01 e um UTXO de 0,005, usando ambos para somar a quantia de pagamento desejada. Em Um script para calcular quantos bitcoins totais ser‹o emitidos, emitidos , n—s demonstramos o uso do algoritmo "greedy" para selecionar a partir dos UTXOs dispon’veis, a fim de fazer um pagamento de uma quantia espec’fica. No exemplo, os UTXOs dispon’veis s‹o fornecidos como uma array constante, mas, na realidade, os UTXOs dispon’veis seriam adquiridos com uma chamada RPC ao Bitcoin Core, ou a um API de terceiro como demonstrado em Um script que chama o API da blockchain.info para encontrar o UTXO relacionado a um endere•o endere•o..
8
Example 3. Um script para para calcular quantos quantos bitcoins totais totais ser‹o emitidos emitidos
# Selects outputs from a UTXO list using a greedy algorithm. from sys import argv class OutputInfo: def __init__(self, __init__(self, tx_hash, tx_index, value): self.tx_hashh = tx_hash self.tx_has self.tx_indexx = tx_index self.tx_inde self.value = value
def __repr__(self): __repr__(se lf): return "<%s:%s with %s Satoshis>" % (self.tx_hash, (self.tx_hash, self.tx_inde self.tx_index, x, self.value)
# Select optimal outputs for a send from unspent outputs list. # Returns output list and remaining change to be sent to # a change address. def select_outp select_outputs_greedy(un uts_greedy(unspent, spent, min_value): # Fail if empty. if not unspent: return None # Partition into 2 lists. lessers = [utxo for utxo in unspent if utxo.value < min_value] greaters = [utxo for utxo in unspent if utxo.value >= min_value] key_func = lambda utxo: utxo.value if greaters: # Not-empty. Find the smallest greater. min_greater = min(greaters) change = min_greater min_greater.value .value - min_value return [min_greater] [min_greater],, change # Not found in greaters. Try several lessers instead. # Rearrange them from biggest to smallest. We want to use the least # amount of inputs as possible. lessers.sort(key=key_fun lessers.sor t(key=key_func, c, reverse=True reverse=True)) result = [] accum = 0 for utxo in lessers: result.append(utxo) accum += utxo.value if accum >= min_value: change = accum - min_value return result, "Change: %d Satoshis" % change # No results found. return None, 0 9
def main(): unspent = [ OutputInfo("ebadfaa92f1fd29e2fe296eda70 OutputInfo("ebadfaa92f1fd2 9e2fe296eda702c48bd11ffd52 2c48bd11ffd52313e986e99dd 313e986e99ddad9084062167" ad9084062167",, 1, 8000000), OutputInfo("6596fd070679de96e405d52b51b OutputInfo("6596fd070679de 96e405d52b51b8e1d644029108 8e1d644029108ec4cbfe45145 ec4cbfe451454486796a1ecf" 4486796a1ecf",, 0, 16050000), OutputInfo("b2affea89ff82557c60d635a2a3 OutputInfo("b2affea89ff825 57c60d635a2a3137b8f88f12ec 137b8f88f12ecec85082f7d0a ec85082f7d0a1f82ee203ac4" 1f82ee203ac4",, 0, 10000000), OutputInfo("7dbc497969c7475e45d952c4a87 OutputInfo("7dbc497969c747 5e45d952c4a872e213fb15d45e 2e213fb15d45e5cd3473c386a 5cd3473c386a71a1b0c136a1" 71a1b0c136a1",, 0, 25000000), OutputInfo("55ea01bd7e9afd3d3ab9790199e OutputInfo("55ea01bd7e9afd 3d3ab9790199e777d62a0709cf 777d62a0709cf0725e80a7350 0725e80a7350fdb22d7b8ec6" fdb22d7b8ec6",, 17, 5470541), OutputInfo("12b6a7934c1df821945ee9ee3b3 OutputInfo("12b6a7934c1df8 21945ee9ee3b3326d07ca7a65f 326d07ca7a65fd6416ea44ce8 d6416ea44ce8c3db0c078c64" c3db0c078c64",, 0, 10000000), OutputInfo("7f42eda67921ee92eae5f79bd37 OutputInfo("7f42eda67921ee 92eae5f79bd37c68c9cb859b89 c68c9cb859b899ce70dba68c4 9ce70dba68c48338857b7818" 8338857b7818",, 0, 16100000), ]
if len(argv) > 1: target = long(argv[1 long(argv[1]) ]) else: target = 55000000
print "For transaction amount %d Satoshis (%f bitcoin) use: " % (target, target/10.0**8) print select_outpu select_outputs_greedy(uns ts_greedy(unspent, pent, target) if __name__ == "__main__": main()
Se n—s executarmos os script select-utxo.py sem um par‰metro, ele ir‡ tentar construir um conjunto de UTXOs (e troco) para um pagamento de 55.000.000 satoshis (0,55 bitcoin). Se voc fornecer uma quantia alvo de pagamento como um par‰metro, o script ir‡ selecionar os UTXOs para fazer aquela quantia alvo de pagamento. Em Executando o script select-utxo.py, select-utxo.py , n—s executamos o escript tentando fazer um pagamento de 0,5 bitcoin ou 50.000.000 satoshis.
10
Example 4. Executando Executando o script script select-utxo.py select-utxo.py
$ python select-utxo.p select-utxo.pyy 50000000 Para uma quantia de transa •‹o de 50000000 Satoshis (0.500000 bitcoin), utilize: ([<7dbc497969c7475e45d952c ([<7dbc497969 c7475e45d952c4a872e213fb15 4a872e213fb15d45e5cd3473c3 d45e5cd3473c386a71a1b0c13 86a71a1b0c136a1:0 6a1:0 with 25000000 Satoshis>, <7f42eda67921 <7f42eda67921ee92eae5f79bd ee92eae5f79bd37c68c9cb859b 37c68c9cb859b899ce70dba68 899ce70dba68c48338857b781 c48338857b7818:0 8:0 with 16100000 Satoshis>, <6596fd070679de96e405d52b5 <6596fd070679 de96e405d52b51b8e1d6440291 1b8e1d644029108ec4cbfe4514 08ec4cbfe451454486796a1ec 54486796a1ecf:0 f:0 with 16050000 Satoshis>], 'Change: 7150000 Satoshis')
Assim que o UTXO Ž selecionado, a carteira passa a produzir scripts de destravamento contendo as assinaturas para cada um dos UTXOs, dessa maneira tornando-os gast‡veis, ao satisfazer as condi•›es de seus scripts de travamento. A carteira acrescenta essas referncias dos UTXOs e os scripts de destravamento como inputs da transa•‹o. A estrutura de um input de transa•‹o demonstra transa•‹o demonstra a estrutura de um input de transa•‹o. Table 3. A estrutura de um input de transa•‹o
Tamanho
Campo
Descri•‹o
32 bytes
Transaction Hash
Apontador para a transa•‹o contendo o UTXO para ser gasto
4 bytes
Output Index
O nœmero ’ndice do UTXO para ser gasto; o primeiro Ž 0
1-9 bytes (VarInt)
Unlocking-Script Size
Comprimento do script de destravamento em bytes, para seguir
Vari‡vel
Unlocking-Script
Um script que preenche os critŽrios (condi•›es) para o script de travamento do UTXO
4 bytes
Sequence Number
Funcionalidade de substitui•‹o de transa•‹o, atualmente desabilitada, definida como 0xFFFFFFFF
NOTE
O nœmero de sequncia Ž usado para substituir uma transa•‹o antes da expira•‹o do locktime da transa•‹o, que Ž uma funcionalidade atualmente desabilitada no bitcoin. A maioria das transa•›es definem o valor do nœmero de sequncia para o valor inteiro m‡ximo (0xFFFFFFFF), que Ž ignorado pela rede bitcoin. Se a transa•‹o possuir um locktime diferente de zero, para que o locktime seja habilitado, pelo menos um de seus inputs deve ter um nœmero de sequncia menor que 0xFFFFFFFF .
11
Taxas de Transa•‹o A maioria das transa•›es incluem taxas de transa•‹o, que remuneram os mineradores bitcoin por manterem a seguran•a da rede. A minera•‹o, as taxas e as recompensas coletadas pelos mineradores s‹o discutidas em maiores detalhes em [ch8] [ch8].. Essa se•‹o examina como as taxas de transa•‹o s‹o inclu’das em uma transa•‹o t’pica. A maioria das carteiras calcula e inclui automaticamente as taxas de transa•‹o. Entretanto, se voc estiver construindo transa•›es atravŽs de uma programa•‹o, ou usando uma interface de linha de comando, voc deve contabilizar isso manualmente e incluir essas taxas. As taxas de transa•‹o servem como um incentivo para incluir (minerar) a transa•‹o no pr—ximo bloco e tambŽm como um desestimulador contra transa•›es de "spam" ou qualquer tipo de abuso contra o sistema, ao impor um pequeno custo em cada transa•‹o. As taxas de transa•‹o s‹o coletadas pelo minerador que minerar o bloco que registra a transa•‹o na blockchain. As taxas de transa•‹o s‹o calculadas de acordo com o tamanho da transa•‹o em kilobytes, e n‹o no valor da transa•‹o em bitcoins. De modo geral, as taxas de transa•‹o s‹o definidas baseadas na for•as do mercado na rede bitcoin. Os mineradores priorizam transa•›es baseados em muitos critŽrios diferentes, incluindo taxas, e podem atŽ mesmo processar transa•›es de gra•a sob certas circunst‰ncias. As taxas de transa•›es afetam a prioridade do processamento, significando que uma transa•‹o com taxas suficientes Ž mais prov‡vel de ser inclu’da no pr—ximo bloco mais minerado, enquanto uma transa•‹o sem taxa ou com taxa insuficiente pode ser atrasada, processada em uma base de melhor-esfor•o ap—s alguns blocos, ou nem chegar a ser processada. As taxas de transa•‹o n‹o s‹o obrigat—rias, e as transa•›es sem taxas podem chegar a ser processadas; no entanto, a inclus‹o de taxas de transa•‹o incentiva uma maior prioridade de processamento. Ao longo do tempo, houve evolu•›es na maneira como as taxas s‹o calculadas e no efeito que elas tem na prioridade das transa•›es. Inicialmente, as taxas de transa•‹o eram fixas e constantes ao longo da rede. Gradualmente, a estrutura de taxas foi flexibilizada, de maneira que ela pudesse ser influenciada por for•as do mercado, baseando-se na capacidade da rede e no volume de transa•›es. Atualmente, a taxa de transa•‹o m’nima Ž fixada em 0,0001 bitcoin ou um dŽcido de um milibitcoin por kilobyte, recentemente reduzida de um mili-bitcoin. A maioria das transa•›es tem menos de um kilobyte; no entanto, aquelas que contŽm mœltiplos inputs ou outputs podem ser maiores. Em revis›es futuras do protocolo bitcoin, espera-se que as aplica•›es em carteira ir‹o utilizar an‡lise estat’stica para calcular a taxa mais apropriada para ser inclu’da em uma transa•‹o, de acordo com as taxas mŽdias da transa•›es recentes. O algoritmo atualmente utilizado pelos mineradores para priorizar a inclus‹o no bloco das transa•›es de acordo com suas taxas Ž examinado em detalhes no [ch8] [ch8]..
Adicionando Taxas ˆs Transa•›es A estrutura de dados das transa•›es n‹o tem um campo para taxas. Ao invŽs disso, infere-se que as taxas s‹o a diferen•a entre a soma dos inputs e a soma dos outputs. Qualquer valor em excesso que permanece ap—s todos os outputs terem sido deduzidos de todos os inputs Ž a taxa que Ž coletada pelos mineradores. 12
As taxas de transa•‹o transa•‹o s‹o considerada considerada como a sobra sobra dos inputs subtra’dos subtra’dos dos outputs: outputs:
Taxas = Soma(Inputs) - Soma(Outputs)
Isso Ž um elemento relativamente confuso das transa•›es, e Ž um ponto importante para se compreender, porque se voc est‡ construindo as suas pr—prias transa•›es voc deve se certificar que voc n‹o incluiu uma taxa muito grande ao subutilizar os inputs. Isso significa que voc deve contabilizar todos os inputs, se necess‡rio para criar o troco, caso contr‡rio voc ir‡ acabar dando uma gorjeta grande demais para os mineradore mineradores! s! Por exemplo, se voc consumir um UTXO de 20 bitcoins para fazer um pagamento de 1 bitcoin, voc precisa incluir um output de troco de 20 bitcoins de volta para a sua carteira. Caso contr‡rio, os 19 bitcoins que sobrarem ser‹o contados como uma taxa de transa•‹o e ser‹o coletados pelo minerador que minerar a sua transa•‹o em um bloco. A sua transa•‹o vai receber alta prioridade e o minerador vai ficar muito feliz, mas provavelmente n‹o era isso que voc queria fazer.
WARNING
Se voc se esquecer de adicionar um output de troco em uma transa•‹o t ransa•‹o constru’da manualmente, voc pagar‡ a taxa de transa•‹o com o valor do troco. Pode ser que a sua real inten•‹o n‹o seria dizer "pode ficar com troco!"
Vamos ver como isso funciona na pr‡tica, ao ver novamente a compra do cafŽ da Alice. A Alice quer gastar 0,015 bitcoin para pagar pelo cafŽ. Para garantir que essa transa•‹o ser‡ processada prontamente, ela ter‡ que incluir uma taxa de transa•‹o, que digamos que seja de 0,001. Isso significa que o custo total da transa•‹o ser‡ de 0,016. A carteira dela portanto deve usar um conjunto de UTXOs cuja soma d 0,016 bitcoin ou mais e, se necess‡rio, ter‡ que criar o troco. Digamos que a carteira dela tem uma UTXO de 0,2 bitcoin dispon’vel. Portanto ela precisar‡ consumir esse UTXO, criar um output para o BobÕs Cafe de 0,015 e um segundo output com 0,184 bitcoin de troco de volta para a pr—pria carteira dela, deixando 0,001 bitcoin n‹o-alocado, que Ž uma taxa impl’cita pela transa•‹o. Agora vamos ver um cen‡rio diferente. Eugnia, nossa diretora do centro de caridade para crian•as nas Filipinas, completou uma campanha para arrecada•‹o de fundos para comprar livros escolares para as crian•as. Ela recebeu milhares de pequenas doa•›es de pessoas de todos os lugares do mundo, totalizando 50 bitcoins, ent‹o sua carteira est‡ cheia de pagamentos muito pequenos (UTXOs). Agora ela que comprar centenas de livros escolares da editor local, pagando em bitcoin. Ao tentar construir uma œnica transa•‹o de pagamento com uma quantia maior, o aplicativo de carteira da Eugenia deve utilizar o conjunto de UTXOs dispon’veis, que Ž composto por v‡rias quantias menores. Isso significa que a transa•‹o resultante ir‡ utilizarmais de uma centena de UTXOs de pequeno valor como input, e apenas um œnico output, que ser‡ o pagamento ˆ editora do livro. Uma transa•‹o com tantos inputs ter‡ mais do que um kilobyte, talvez 2 a 3 kilobytes. Como resultado, ela ir‡ exigir uma taxa maior do que a taxa m’nima da de rede, que Ž 0,0001 0 ,0001 bitcoin. O aplicativo de carteira da Eugenia ir‡ calcular a taxa apropriada ao medir o tamanho da transa•‹o e multiplicando-o pela taxa por kilobyte. Muitas carteiras ir‹o pagar taxas extras para transa•›es maiores para assegurar que a transa•‹o seja processada prontamente. A taxa n‹o Ž maior porque a
13
Eugenia est‡ gastando mais dinheiro, mas porque a transa•‹o dela Ž mais complexa e tem um tamanho maiorÑa taxa Ž independente do valor em bitcoins da transa•‹o.
Encadeamento de Transa•›es e Transa•›es îrf‹s Como n—s j‡ vimos, as transa•›es formam uma cadeia, onde uma transa•‹o gasta os outputs da transa•‹o anterior (conhecida como transa•‹o pai) e cria outputs para uma transa•‹o subsequente (conhecida como transa•‹o filha). Ës vezes uma cadeia inteira de transa•›es que s‹o dependentes umas das outrasÑpor exemplo, uma pai, uma filha e uma netaÑs‹o criadas ao mesmo tempo, para preencher um fluxo complexo de transa•›es que exige que as filhas sejam assinadas antes da transa•‹o pai ser assinada. Por exemplo, essa Ž a tŽcnica usada em transa•›es CoinJoin, onde v‡rias pessoas agrupam transa•›es para protegerem a sua privacidade. Quando v‡rias transa•›es s‹o transmitidas na rede, elas nem sempre chegam na mesma ordem. Ës vezes, a transa•‹o filha pode chegar antes da pai. Nesse caso, os nodos que enxergarem a filha primeiro ir‹o ver que ela tem uma referncia a uma transa•‹o pai que ainda n‹o Ž conhecida. Ao invŽs de rejeitar a filha, eles a colocam em uma pool tempor‡ria para aguardar a chegada de sua transa•‹o pai e propag‡-la para todos os outros nodos. A pool de transa•›es sem transa•›es-pais Ž conhecida —rf‹s. Assim que uma transa•‹o pai chega, quaisquer —rf‹s que tenham uma como a pool de transa•›es —rf‹s referncia ao UTXO criado pela pai s‹o liberadas, revalidadas recursivamente, e ent‹o toda a corrente de transa•›es pode ser inclu’da em um pool de transa•›es, pronto para ser minerado em um bloco. As correntes de transa•›es podem ser arbitrariamente longas, com qualquer nœmero de gera•›es transmitidas simultaneamente. O mecanismo que mantŽm as —rf‹s em um pool de —rf‹s garante que transa•›es v‡lidas n‹o sejam rejeitadas apenas porque a transa•‹o pai delas se atrasou e que no final a corrente que elas pertecem ser‡ reconstru’da na ordem correta, independente da ordem de chegada. Existe um limite para o nœmero de transa•›es —rf‹s armazenadas na mem—ria, para prevenir um ataque de nega•‹o de servi•o (ataque DoS) contra os nodos do bitcoin. O limite Ž definido como MAX_ORPHAN_TRANSACTIONS no c—digo-fonte do cliente referncia do bitcoin. Se o nœmero de transa•›es —rf‹s —rf‹s na pool exceder MAX_ORPHAN_TRANS MAX_ORPHAN_TRANSACTIONS, ACTIONS, uma ou ou mais transa•›es transa•›es —rf‹s selecionadas aleatoriamente ser‹o removidas da pool, atŽ que o tamanho da pool volte a estar dentro dos limites.
Scripts de Transa•‹o e Linguagem de Script Os clientes bitcoin validam as transa•›es ao executar um script, escrito em uma linguagem de script parecida com Forth. Tanto o script de travamento (de onera•‹o) colocado em um UTXO quanto o script de destravamento destravamento que geralmente geralmente contŽm uma assinatura assinatura s‹o escritos nessa linguagem linguagem de script. Quando uma transa•‹o Ž validada, o script de destravamento em cada in put Ž executado junto com o script de travamento correspondente para ver se ele satisfaz a condi•‹o para se gastar. Atualmente, a maioria das transa•›es processadas pela rede bitcoin possuem a forma "Alice paga Bob" e s‹o baseadas no mesmo script chamado script de Pagamento-para-Hash-de-Chave-Pœblica ("Pay-toPublic-Key-Hash script"). Entretanto, o uso de scripts para travar outputs e destravar inputs significa que atravŽs do uso de linguagem de programa•‹o, as transa•›es podem conter um nœmero infinito de 14
condi•›es. As transa•›es bitcoin n‹o s‹o limitadas ˆ forma e ao padr‹o "Alice "Alice paga Bob". Essa Ž apenas a ponta do iceberg de possibilidade que podem ser expressadas com essa linguagem de script. Nessa se•‹o, n—s iremos demontrar os componentes da linguagem de scripting de transa•›es bitcoin e mostraremos como isso pode ser usado para expressar condi•›es complexar para se gastar e como essas condi•›es podem ser satisfeitas atravŽs de scripts de destravamento.
TIP
A valida•‹o da transa•‹o bitcoin n‹o Ž baseada em um padr‹o est‡tico, ao invŽs disso, ela Ž obtida atravŽs da execu•‹o de uma linguagem de script. Essa linguagem permite que uma variedade quase infinita de condi•›es seja expressa. Essa Ž a maneira atravŽs da qual o bitcoin recebe o poder do "dinheiro program‡vel". program‡vel".
Constru•‹o do Script (Travame (Travamento nto + Destravament Destravamento) o) O mecanismo de valida•‹o da transa•‹o do Bitcoin depende de dois tipos de scripts para validar as transa•›es: um script de travamento e um de destravamento destravamento.. Um script de travamento Ž uma onera•‹o colocada em um output, e especifica as condi•›es que devem ser preenchidas para se gastar esse output no futuro. Historicamente, o script de travamento era chamado de scriptPubKey , pois ele geralmente continha uma chave pœblica ou um endere•o bitcoin. Nesse livro n—s nos referimos a ele como um "script de travamento", para reconhecer a gama muito maior de possibilidades dessa tecnologia de scripting. Na maioria das aplica•›es bitcoin, aquilo que n—s nos referimos como um script de travamento aparecer‡ aparecer‡ no c—digo-fonte como scriptPubKey scriptPubKey.. Um script de destravamento Ž um script que "resolve", ou satisfaz, as condi•›es que foram colocadas em um ouput por um script de travamento, permitindo que o output seja gaso. Os scripts de destravamento fazem parte de todos os inputs de transa•‹o, e na maioria das vezes eles contŽm uma assinatura digital produzida pela carteira do usu‡rio a partir de sua chave privada. Historicamente, o script de destravamento Ž chamado de scriptSig , porque ele geralmente contŽm um assinatura digital. Na maioria das aplica•›es bitcoins, o c—digo-fonte se refere ao script de destravamento como scriptSig. Nesse livro, n—s nos referimos a ele como um "script de destravamento" para reconhecer a gama muito maior de exigncias dos scripts de travamento, pois nem todos os scripts de destravamento precisam conter assinaturas. Todos os clientes bitcoin ir‹o validar as transa•›es ao executar os scripts de travamento e destravamento juntos. Para cada input na transa•‹o, o software de valida•‹o ir‡ primeiro adquirir as UTXOs referenciadas pelo input. Esses UTXOs contŽm um script de travamento definindo as condi•›es necess‡rias para gast‡-los. O software de valida•‹o ir‡ ent‹o adquirir o script de travamento contido no input que est‡ tentanto gastar essas UTXOs e ir‡ executar os dois scripts. No cliente bitcoin original, os scripts de destravamento e travamento s‹o concatenados e executados em sequncia. Por quest›es de seguran•a, isso foi modificado em 2010, devido a uma vulnerabilidade que permitia que um script de destravamento mal formado adicionasse dados no stack e corrompesse o script de travamento. Na implementa•‹o atual, os scripts s‹o executados separadamente com o stack sendo transferido entre as duas execu•›es, como descrito a seguir.
15
Primeiro, o script de destravamento Ž executando, usando o mecanismo de execu•‹o do stack. Se o script de destravamento foi executado sem erros (por exemplo, ele n‹o possui operadores "pendentes" faltando), o stack principal (e n‹o o stack alternativo) Ž copiado e o script de travamento Ž executado. Se o resultado da execu•‹o do script de travamento com os dados do stack copiados a partir do script de destravamento for "TRU", o script de destravamento teve sucesso em resolver as condi•›es impostas pelo script de travamento e, portanto, o input Ž uma autoriza•‹o v‡lida para gastar o UTXO. Se qualquer resultado diferente de "TRUE" permanecer ap—s a execu•‹o do script combinado, o pinput Ž inv‡lido porque ele n‹o conseguiu satisfazer as condi•›es de gasto impostas no UTXO. Note que o UTXO est‡ permanentemente registrado nablockchain, e portanto Ž invari‡vel e n‹o Ž afetado por mœltiplas tentativas de se gast‡-lo por referncia em uma nova transa•‹o. Somente uma transa•‹o v‡lida que satisfaz corretamente as condi•›es do UTXO resulta em um UTXO sendo marcado como "gasto" e removido do conjunto de UTXOs dispon’veis (n‹o-gastos). Combinando scriptSig e scriptPubKey para avaliar um script de transa•‹o Ž um exemplo de scripts de destravamento e travamento para o tipo mais comum de transa•‹o bitcoin (um pagamento para um hash de endere•o pœblico), demonstrando o script cominando resultando da concatena•‹o dos scripts de destravamento e travamento antes da valida•‹o do script.
Figure 1. Combinando Combinando scriptSig scriptSig e scriptPubKey scriptPubKey para avaliar um script de transa•‹o transa•‹o
Linguagem de Script A linguagem de script das transa•›es bitcoin, chamada de Script, Ž uma linguagem de execu•‹o de nota•‹o polonesa invertida semelhante a Forth baseada em stack. Se isso soa estranho, voc provavelmente n‹o estudou as linguagens de programa•‹o dos anos 1960. O script Ž uma linguagem muito simples que foi projetada para ser limitada em escopo e execut‡vel em v‡rios hdarwares, talvez t‹o simples quando um dispositivo embutido, como uma calculadora de bolso. Ele requer processamento m’nimo e n‹o pode fazer coisas que muitas linguagens de programa•‹o modernas conseguem. No caso do dinheiro program‡vel, isso Ž uma funcionalidade de seguran•a deliberada. deliberada. A linguagem de script do bitcoin Ž chamada de linguagem baseada em stack porque ela usa uma estrutura de dados chamada de stack (pilha). (pilha). Um stack Ž uma estrutura de dados muito simples, que pode ser imaginada como uma pilha de cartas de um baralho. Um stack permite duas opera•›es: empilhar ("push") e desempilhar ("pop"). "Empilhar" ("push") adiciona um item no topo da pilha. Desempilhar ("pop") retira o item que est‡ no topo da pilha.
16
A linguagem de scripting executa o script ao processar cada idem da esquerda para a direita. Nœmeros (constantes de dados) s‹o empurrados para a stack. Os operadores empilham (push) ou desempilham (pop) um ou mais par‰metros do stack, atuam neles e podem empurrar um resultado para pilha. Por exemplo, OP_ADD ir‡ desempilhar dois itens do stack, adicion‡-los e empurrar a soma resultante para o stack. Os operadores condicionais avaliam uma condi•‹o, produzindo um resultado booleano de TRUE (VERDADEIRO) ou FALSE FALSE (F (FALSO). ALSO). Por exemplo, OP_EQUAL OP_EQUAL desempilha (pop) dois dois itens do stack e empurra TRUE (TRUE representado pelo nœmero 1) se eles forem iguais ou FALSE (representado por zero) se eles n‹o forem iguais. Scripts de transa•‹o de bitcoin geralmente contŽm um operador condicional, de maneira que eles possam produzir o resultado TRUE que significa uma transa•‹o v‡lida. Em [simplemath_script] [simplemath_script],, o script 2 3 OP_ADD 5 OP_EQUAL demonstra o operador de adi•‹o aritimŽtica OP_ADD, adicionando dois nœmeros e colocando o resultado no stack, seguido pelo operador condicional OP_EQUAL, que verifica que a soma resultante Ž igual a 5. Para simplificar, o prefixo OP_ Ž omitido no exemplo passo-a-passo. O script a seguir Ž um pouco mais complexo, que calcula 2 + 7 Ð 3 + 1. Note que quando o script contŽm v‡rios operadores em uma linha, o stack permite que os resultados de um operadores ajam no pr—ximo operador; 2 7 OP_ADD 3 OP_SUB 1 OP_ADD 7 OP_EQUAL
Tente voc mesmo validar o script anterior usando papel e caneta. Quando a execu•‹o do script terminar, voc deve terminar com o valor TRUE no stack. Apesar de a maioria dos scripts de travamento se referir a um endere•o bitcoin ou a uma chave pœblica, portanto exigindo a prova de posse para gastar os fundos, o script n‹o precisa ser t‹o complexo. Qualquer combina•‹o de scripts de travamento e destravamento que resultar em um valor TRUE Ž v‡lida. Essa aritmŽtica simples que n—s usamos como exemplo da linguagem de script Ž tambŽm um script de travamento v‡lido que pode ser usado para travar um output de transa•‹o. Usando parte do script de exemplo aritmŽtico como script de travamento: t ravamento: 3 OP_ADD 5 OP_EQUAL
que pode ser satisfeita atravŽs de uma transa•‹o contendo um input com o script de destravamento: 2
O software de valida•‹o combina os scripts de bloqueio e desbloqueio e o script resultante Ž:
17
2 3 OP_ADD 5 OP_EQUAL
Como n—s vimos no exemplo passo-a-passo em [simplemath_script] [simplemath_script],, quando o script Ž executado, o resultado Ž OP_TRUE, fazendo a transa•‹o v‡lida. N‹o apenas esse Ž um script de travamento v‡lido, como tambŽm o UTXO resultante poderia ser gasto por qualquer pessoa que tivesse as habilidades aritimŽticas para saber que o nœmero 2 satisfaz o script. 1. Script de valida•‹o do do bitcoin fazendo fazendo uma image::images/msbt_0502.png["TxScriptSimpleMathExample"]
TIP
conta
matem‡tica
simples
As transa•›es s‹o v‡lidas se o resultado no topo do stack Ž TRUE (definido como {0x01}), qualquer valor diferente de zero ou se o stack estiver vazio ap—s a execu•‹o do script. As transa•›es s‹o inv‡lidas se o valor do topo do stack for FALSE (um valor vazio de comprimento zero, definido como {}) ou se a execu•‹o do script for suspensa por um operador, como o OP_VERIFY, o OP_RETURN ou um terminador condicional como o OP_ENDIF. Veja [tx_script_ops] [tx_script_ops] para para detalhes.
A Incompletude de Turing A linguagem de script da transa•‹o bitcoin contŽm muitos operadores, mas Ž deliberadamente limitada de uma maneira importanteÑn‹o existem loops ou capacidades de controle de fluxo complexa alŽm do controle de fluxo condicional. Isso garante que a linguagem n‹o Ž Turing completa, o que significa que os scripts tem uma complexidade limitada e tempos de execu•‹o previs’veis. O script n‹o Ž uma linguagem de finalidades gerais. Essas limita•›es garantem que a linguagem n‹o pode ser usada para criar um loop infinito ou outra forma de "bomba l—gica" que poderia ser embutida em uma transa•‹o de uma maneira que cause um ataque de nega•‹o de servi•o contra a rede bitcoin. Lembrese, cada transa•‹o Ž validada por todos os nodos completos da rede bitcoin. Uma linguagem limitada previne que o mecanismo de valida•‹o da transa•‹o seja usado como uma vulnerabilidade.
Verifica•‹o sem Monitora•‹o de Estado A linguagem de script de transa•‹o do bitcoin n‹o exige a monitora•‹o de estado, ou seja, n‹o existe um estado anterior ˆ execu•‹o do script, ou estado salvo ap—s a execu•‹o do script. Portanto, toda a informa•‹o que Ž necess‡ria para se executar um script est‡ contida no interior do script. Um script ser‡ executado de maneira previs’vel em qualquer outro sistema. Se o seu sistema verifica um script, voc pode ter certeza que todos os outros sistemas na rede bitcoin tambŽm verificar‹o esse script, ou seja, uma transa•‹o v‡lida ser‡ v‡lida para todos na rede, e todos saber‹o disso. Essa previsibilidade de resultados Ž um benef’cio essencial do sistema bitcoin.
Transa•›es padr‹o Nos primeiros anos do desenvolvimento do bitcoin, os desenvolvedores apresentaram algumas limita•›es nos tipos de scripts que poderia ser processados pelo cliente referncia. Essas limita•›es s‹o
18
codificadas em uma fun•‹o chamada isStandard(), que define cinco tipos de transa•›es "padr‹o" (standard). Essas limita•›es s‹o tempor‡rias e podem ser que j‡ tenham sido removidas no momento em que voc est‡ lendo esse livro. AtŽ ent‹o, os cinco tipos padr›es de scripts de transa•‹o s‹o os œnicos que ser‹o aceitos pelo cliente de referncia e pela maioria dos mineradores que executam o cliente de referncia. Embora seja poss’vel criar uma transa•‹o n‹o-padr‹o contendo um script que n‹o faz parte dos tipos padr›es, voc deve encontrar um minerador que n‹o siga essas limita•›es para minerar essa transa•‹o em um bloco. Verifique o c—digo-fonte do cliente Bitcoin Core (a implementa•‹o de referncia) para ver o que Ž atualmente permitido como um script de transa•‹o v‡lido. Os cinco tipos padr›es de scripts de transa•‹o s‹o pagamento-para-hash-de-chave-pœblica (pay-topublic-key-hash, P2PKH), chave-pœblica (public-key), mœltiplas-assinaturas (multi-signature, limitado a 15 chaves), pagamento-para-hash-de-script (pay-to-script-hash, P2SH) e output de dados (data output, OP_RETURN), que s‹o descritos em maiores detalhes nas se•›es a seguir.
Pay-to-Public-Key-Ha Pay-to-Publi c-Key-Hash sh (P2PKH) A vasta maioria das transa•›es processadas na rede bitcoin s‹o transa•›es P2PKH. Elas contŽm um script de travamento que onera o output com um hash de chave pœblica, mais comumente conhecido como um ender•o bitcoin. As transa•›es que pagam um endere•o bitcoin contŽm scripts P2PKH. Um output travado por um script P2PKH pode ser destravado (gasto) ao se apresenar a chave pœblica e a assinatura digital criada pela chave privada correspondente. Por exemplo, vamos examinar novamente o pagamento da Alice para o BobÕs Cafe. A Alice fez um pagamento de 0,015 bitcoin para o endere•o bitcoin do BobÕs Cafe. Esse output de transa•‹o teria um script de travamento da seguinte forma: OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG
O Hash da Chave Pœblica do CafŽ Ž equivalente ao endere•o bitcoin do cafŽ, sem a codifica•‹o Base58Check. A maioria das aplica•›es iria mostrar o hash da chave pœblica em codifica•‹o hexadecimal e n‹o no formato conhecido de endere•o bitcoin codificado em Base58Check que come•a com um "1". O script de travamento anterior pode ser satisfeito com um script de destavamento desse jeito:
Os dois scripts juntos iriam formar o seguinte script combinado de valida•‹o: OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG
19
Quando executado, esse script combinado ir‡ avaliar para TRUE se, e somente se, o script de destravamento preencher as condi•›es definidas pelo script de travemento. Em outras palavras, o resultado ser‡ TRUE se o script de destravaemento tiver uma assinatura v‡lida da chave privada do cafŽ que corresponde ao hash da chave pœblica definida como uma onera•‹o. As figuras e demonstram (em duas partes) uma execu•‹o passo-a-passo do script combinado, que ir‡ comprovar que essa Ž uma transa•‹o v‡lida.
Figure 2. Avaliando Avaliando um script script para uma transa•‹o P2PKH P2PKH (Parte 1 de 2)
Pay-to-Public-Key Pagamento-para-chave-pœblica Ž uma forma mais simples de um pagamento bitcoin do que um pagamento-para-hash-de-chave-pœblica. pagamento-par a-hash-de-chave-pœblica. Com esse tipo de script, a pr—pria chave pœblica Ž armazenada no script de travamento, ao invŽs de um hash-de-chave-pœblica como Ž feito com o P2PKH, que Ž muito menor. O pagamento-para-hash-de-chave-pœblica foi inventado pelo Satoshi para tornar os endere•os 20
bitcoins mais curtos, facilitando o uso. Atualmente o pagamento-para-chave-pœblica Ž visto com maior frequncia em transa•›es coinbase, geradas por softwares de minera•‹o mais antigos que n‹o foram atualizados para utilizarem o P2PKH. Um script de travamento de pagamento para chave pœblica fica dessa maneira: OP_CHECKSIG
O script de destravamento correspondente que deve ser apresentado para destravar esse tipo de output Ž uma assinatura simples, como essa:
O script combinado, que Ž validado pelo software de valida•‹o de transa•‹o, Ž: OP_CHECKSIG
Esse script Ž uma invoca•‹o simples do operador CHECKSIG, que valida a assinatura como pertencendo ˆ chave correta e retorna TRUE para o stack.
21
Figure 3. Avaliando Avaliando um script script para uma transa•‹o P2PKH P2PKH (Parte 2 de 2)
Mœltiplas assinatura assinaturass Scripts de mœltiplas assinaturas definem uma condi•‹o onde N chaves pœblicas s‹o registradas no script e pelo menos M dessas devem fornecer assinaturas para liberar a onera•‹o. Isso tambŽm Ž conhecido como um esquema M-de-N, onde N Ž o nœmero total de chaves e M Ž o nœmero de assinaturas necess‡rias para a valida•‹o. Por exemplo, um script de mœltiplas assinaturas 2-de-3 Ž um onde trs chaves pœblicas s‹o listadas como assinadores em potencial e pelo menos dois deles devem ser usados para criar assinaturas para para uma transa•‹o transa•‹o v‡lida que gaste os fundos. Atualmente, os
22
scripts de mœltiplas assinaturas padr‹o podem fazer mœltiplas assinaturas desde 1-de-1 a 15-de-15, ou qualquer combina•‹o nessa faixa. A limita•‹o de 15 chaves listadas j‡ deve ter sido removida no momento em que esse livro for publicado, ent‹o verifique verifique a fun•‹o isStandard() para para ver o que est‡ sendo atualmente aceito pela rede. A forma geral usada por um script de travamento para definir uma condi•‹o de mœltiplas assinaturas M-de-N Ž M ... N OP_CHECKMULTI OP_CHECKMULTISIG SIG
onde N Ž o nœmero total de chaves pœblicas listadas e M Ž o limiar de assinaturas necess‡rias para passar a sa’da. Um script de travamento definindo uma condi•‹o de 2-de-3 mœltiplas assinaturas fica desse jeito: 2 3 OP_CHECKMULTI OP_CHECKMULTISIG SIG
O script de bloqueio anterior pode ser satisfeito com um script de desbloqueio contendo pares de chaves pœblicas e assinaturas: OP_0
ou qualquer combina•‹o de duas assinaturas a partir das chaves privadas correspondendo ˆs trs chaves pœblicas listadas.
NOTE
O prefixo Ž exigido OP_0 devido a um bug na implementa•‹o original do CHECKMULTISIG, que faz com que um item a mais seja retirado do stack. Isso Ž ignorado pelo CHECKMULTISIG, CHECKMULTISIG, que Ž usado apenas para resolver esse problema.
Os dois scripts juntos formariam o script de valida•‹o combinado: OP_0 2 3 OP_CHECKMULT OP_CHECKMULTISIG ISIG
Quando executado, o script combinado ser‡ avaliado como TRUE se, e somente se, o script de desbloqueio coincidir com as condi•›es definidas pelo script de bloqueio. Neste caso, a condi•‹o Ž se o script de desbloqueio tem uma assinatura v‡lida entre as duas chaves privadas que correspondem a duas das trs chaves pœblicas definidos como um estorvo.
Output de dados (OP_RETURN) "ledger, storing unrelated information in")A blockchain, ou seja, todos os registros do bitcoin, que s‹o 23
distribu’dos e contŽm data e hora, possui usos potenciais muito alŽm de pagamentos. Muitos desenvolvedores tentaram tentaram usar a linguagem de script de transa•‹o para tirar vantagem da seguran•a e da resilincia do sistema para aplica•›es como servi•os de cart—rios digitais, certificados de a•›es e contratos smart. As primeirs tentativas de se usar a linguagem de script do bitcoin para essas finalidades envolveram envolveram criar outputs de transa•‹o que registravam dados na blockchain; por exemplo, para registrar uma impress‹o digital de um arquivo de uma maneira que qualquer um pudesse estabelecer uma prova-de-existncia daquele arquivo em uma data espec’fica atravŽs de uma referncia ˆquela transa•‹o. O uso da blockchain do bitcoin para armazenar dados n‹o-relacionados ao bitcoin Ž um assunto controverso. Muitos desenvolvedores consideram esse uso abusivo e querem desencoraj‡-lo. Outros acreditam que isso Ž uma demonstra•‹o das capacidades poderosas da tecnologia bitcoin e querem encorajar esse tipo de experincia. Aqueles que s‹o contra a inclus‹o de dados n‹o relacionados a pagamento argumentam que isso causa um "incha•o na blockchain", causando um fardo para aqueles rodando nodos completos do bitcoin, que tem que lidar com o custo do armazenamento em disco para os dados que a blockchain n‹o foi projetada para armazenar. AlŽm disso, essas transa•›es criam UTXOs que n‹o podem ser gastos, usando endere•os bitcoins destin‡rios como um campo de formul‡rio livre de 20 bytes. Como o endere•o Ž usado para dados, ele n‹o corresponde a uma chave privada e o UTXO resultante jamais pode ser gasto; ele Ž um pagamento falso. Essas transa•›es que jamais podem ser gastas portanto nunca s‹o removidas removidas do conjunto UTXO e fazem com que o tamanho do banco de dados UTXO cres•a ou "inche" infinitamente. Na vers‹o 0.9 do cliente Bitcoin Core, um comprometimento foi atingido com a introdu•‹o do operador OP_RETURN. O OP_RETURN permitiu que os desenvolvedores adicionassem 80 bytes de dados de n‹opagamento para um output de transa•‹o. Entretanto, ao contr‡rio do uso de UTXOs falsos, o operador OP_RETURN cria um output que Ž comprovadamente n‹o-gast‡vel de maneira expl’cita, que n‹o precisa ser registrado registrado no conjunto UTXO. Os outputs OP_RETURN s‹o registrados na blockchain, blockchain, ent‹o eles consomem espa•o em disco e contribuem para o aumento do tamanho da blockchain, mas eles n‹o s‹o armazenados no conjunto UTXO e portanto eles n‹o ficam enchendo a pool de mem—ria UTXO e n‹o s‹o um fardo para os nodos completos, pois n‹o exigem mais mem—rias RAM caras. O script OP_RETURN fica assim: OP_RETURN
A parte de dados Ž limitada a 80 bytes e a mais frequentemente representa um hash, como o output do algoritmo SHA256 (32 bytes). Muitas aplica•›es colocam um prefixo na frente dos dados para ajudar a identificar a aplica•‹o. Por exemplo, o servi•o de cart—rio digital Proof of Existence usa o prefixo de 8 bytes "DOCPROOF", "DOCPROOF", que Ž codificado em ACII como 44f4350524f4f46 em hexadecimal. Lembre-se que n‹o existe um "script de destravamento" que corresponde ao OP_RETURN que pudesse ser usado para "gastar" "gastar" um output OP_RETURN. O objetivo do OP_RETURN Ž que voc n‹o possa gastar o dinheiro travado naquele output, e, portanto, ele n‹o precisa ser armazenado no conjunto UTXO como potencialmente gast‡velÑo OP_RETURN Ž comprovadamente n‹o-gast‡vel. O+OP_RETURN+ Ž geralmente um output com uma quantia de zero bitcoin, porque qualquer bitcoin que for vinculado a 24
esse output ser‡ efetivamente perdido para sempre. Se um OP_RETURN for encontrado pelo software de valida•‹o de script, ele resultar‡ imediatamente na suspens‹o do script de valida•‹o e na marca•‹o da transa•‹o como inv‡lida. Portanto, se voc acidentalmente referenciar um output OP_RETURN como um input em uma transa•‹o, aquela transa•‹o ser‡ inv‡lida. Uma transa•‹o padr‹o (que preenche as verifica•›es isStandard()) pode ter apenas um output +OP_RETURN. Entretanto, o output OP_RETURN œnico pode ser combinado em uma transa•‹o com outputs de qualquer outro tipo. Duas novas op•›es de linha de comando foram adicionadas no Bitcoin Core na vers‹o 0.10. A op•‹o datacarrier controla a transmiss‹o e minera•‹o de transa•›es OP_RETURN, cujo padr‹o Ž definido como "1", para permiti-las. permiti-las. A op•‹o datacarriersize recebe um argumento numŽrico especificando especificando o tamanho m‡ximo em bytes para os dados do OP_RETURN, cujo padr‹o Ž 40 bytes.
NOTE
O OP_RETURN foi inicialmente proposto com um limite de 80 bytes, mas o limite foi reduzido para 40 bytes quando a funcionalidade foi lan•ada. Em fevereiro de 2015, na vers‹o 0.10 do Bitcoin Core, o limite foi novamente elevado para 80 bytes. Os nodos podem decidir transmitir ou minerar OP_RETURN, ou apenas transmitir e minerar OP_RETURN contendo menor que 80 bytes de dados.
Pay-to-Script-Hash (P2SH) O pagamento-para-hash-de-script (P2SH) foi apresentado em 2012 como um novo tipo poderoso de transa•‹o que simplifica e muito o uso de scripts complexos de transa•‹o. Para explicar a necessidade do P2SH, vamos dar uma olhada em um exemplo pr‡tico. Em [ch01_intro_what_is_bitcoin] [ch01_intro_what_is_bitcoin],, n—s apresentamos o Mohammed, um importador de eletr™nicos que mora em Dubai. A companhia do Mohammed usa a funcionalidade de mœltiplas assinaturas do bitcoin para suas contas corporativas. Os scripts de mœltiplas assinaturas s‹o um dos usos mais comuns das capacidades avan•adas de scripting do bitcoin e s‹o uma funcionalidade muito poderosa. A companhia do Mohammed usa um script de mœltiplas-assinaturas para todos os pagamentos de clientes, conhecidos em termos de contabilidade como "contas receb’veis", ou CR. Com o esquema de mœltiplas assinaturas, quaisquer pagamentos feitos pelos consumidores s‹o travados de uma maneira que eles exigem pelo menos duas assinaturas para serem liberados, do Mohammed para um de seus s—cios ou do seu advogado que possui uma chave de backup. Um esquema de mœltiplas assinaturas desse tipo oferece controle de governan•a corporativa e protege contra roubo, desvio de fundos ou perdas. O script resultante Ž bastante longo e se parece com isso: 2 5 OP_CHECKMULTISIG
Apesar de os scripts de mœltiplas assinaturas serem uma funcionalidade poderosa, eles podem ser dif’ceis de se usar. Em rela•‹o rela•‹o ao script anterior, o Mohammed Mohammed teria que comunicar esse esse script para cada um de seus consumidores antes do pagamento. Cada consumidor teria que usar um software de 25
carteira bitcoin especial com a habilidade de criar scripts de transa•‹o customizados, e cada consumidor teria que entender como criar uma transa•‹o usando scripts customizados. AlŽm disso, a transa•‹o resultante seria cerca de cinco vezes maior do que uma transa•‹o de pagamento simples, pois esse script contŽm chaves pœblicas muito longas. O fardo dessa transa•‹o extra-grande teria que ser carregado pelo consumidor na forma de taxas. Finalmente, um script grande de transa•‹o como esse seria carregado no conjunto UTXO na RAM de cada nodo completo, atŽ que ele fosse gasto. Todos esses problemas fazem com que o uso de scripts de outputs complexos sejam dif’ceis na pr‡tica. O pagamento-para-hash-de-script (P2SH) foi desenvolvido para resolver essas dificuldades pr‡ticas e para fazer a utiliza•‹o de scripts complexos de uma maneira t‹o f‡cil quanto um pagamento para um endere•o bitcoin. Com pagamentos P2SH, o script de travamento complexo Ž substitu’do pela sua impress‹o digital, que Ž um hash criptogr‡fico. Quando uma transa•‹o tentanto gastar o UTXO Ž apresentada mais tarde, ela deve conter o script que corresponde ao hash, alŽm do script de destravamento. Em termos simples, P2SH significa "pagar para um script que corresponde a esse hash, um script que ser‡ apresentado mais tarde quando esse output for gasto". Nas transa•›es P2SH, o script de travamento que Ž substitu’do por um hash Ž chamado de script de resgate ("redeem script"), pois ele Ž apresentado ao sistema na hora do resgate ao invŽs de ser apresentado como um script de travamento. Script complexo sem P2SH demonstra P2SH demonstra o script sem P2SH e Script complexo como P2SH demonstra P2SH demonstra o mesmo script codificado com P2SH. Table 4. Script complexo sem P2SH
Script de Travamento
2 ChavePub1 ChavePub2 ChavePub3 ChavePub4 ChavePub5 5 OP_CHECKMUL OP_CHECKMULTISIG TISIG
Script de Destravamento
Ass1 Ass2
Table 5. Script complexo como P2SH
Script de Resgate
2 ChavePub1 ChavePub2 ChavePub3 ChavePub4 ChavePub5 5 OP_CHECKMUL OP_CHECKMULTISIG TISIG
Script de Travamento
OP_HASH160 OP_EQUAL
Script de Destravamento
Ass1 Ass2 script de resgate
Como voc pode ver nas tabelas, com P2SH, o complexo script que detalha as condi•›es para gastar o output (o script de resgate) n‹o Ž apresentado ao script de travamento. Ao invŽs disso, somente um hash disso est‡ no script de travamento e o pr—prio scrit de resgate Ž apresentado depois, como parte do script de destravamento quando o output Ž gasto. Isso I sso passa o fardo das taxas e da complexidade do pagador para o recipiente (que gasta) da transa•‹o. Vamos dar uma olhada na companhia do Mohammed, um script complexo de mœltiplas assinaturas e os scripts P2SH resultantes. Primeiro, o script de mœltiplas assinaturas que a companhia de Mohammed usa para todos os pagamentos que recebe de seus clientes: 26
2 5 OP_CHECKMULTISIG
Se os marcadores forem substitu’dos por chaves pœblicas de verdade (demonstradas aqui como nœmeros de 520 bits come•ando com 04), voc ver‡ que esse script se torna muito longo: 2 04C16B8698A9ABF84250A7C3E 04C16B8698A9 ABF84250A7C3EA7EEDEF9897D1 A7EEDEF9897D1C8C6ADF47F06C C8C6ADF47F06CF73370D74DCCA F73370D74DCCA01CDCA79DCC5 01CDCA79DCC5C395D7EEC6984 C395D7EEC6984 D83F1F50C900A24DD47F569FD D83F1F50C900 A24DD47F569FD4193AF5DE762C 4193AF5DE762C58704A2192968 58704A2192968D8655D6A935BE D8655D6A935BEAF2CA23E3FB8 AF2CA23E3FB87A3495E7AF308 7A3495E7AF308 EDF08DAC3C1FCBFC2C75B4B0F EDF08DAC3C1F CBFC2C75B4B0F4D0B1B70CD242 4D0B1B70CD2423657738C0C2B1 3657738C0C2B1D5CE65C97D78D D5CE65C97D78D0E3422485800 0E34224858008E8B49047E632 8E8B49047E632 48B75DB7379BE9CDA8CE5751D 48B75DB7379B E9CDA8CE5751D16485F431E461 16485F431E46117B9D0C1837C9 17B9D0C1837C9D5737812F393D D5737812F393DA7D4420D7E1A A7D4420D7E1A9162F0279CFC1 9162F0279CFC1 0F1E8E8F3020DECDBC3C0DD38 0F1E8E8F3020 DECDBC3C0DD389D99779650421 9D99779650421D65CBD7149B25 D65CBD7149B255382ED7F78E94 5382ED7F78E946580657EE6FD 6580657EE6FDA162A187543A9 A162A187543A9 D85BAAA93A4AB3A8F044DADA6 D85BAAA93A4A B3A8F044DADA618D0872274406 18D087227440645ABE8A35DA8C 45ABE8A35DA8C5B73997AD343B 5B73997AD343BE5C2AFD94A50 E5C2AFD94A5043752580AFA1E 43752580AFA1E CED3C68D446BCAB69AC0BA7DF CED3C68D446B CAB69AC0BA7DF50D56231BE0AA 50D56231BE0AABF1FDEEC78A6A BF1FDEEC78A6A45E394BA29A1E 45E394BA29A1EDF518C022DD6 DF518C022DD618DA774D207D1 18DA774D207D1 37AAB59E0B000EB7ED238F4D8 37AAB59E0B00 0EB7ED238F4D800 00 5 OP_CHECKMULT OP_CHECKMULTISIG ISIG
Todo esse script pode, no entanto, ser representado por um hash criptogr‡fico de 20 bytes, ao aplicarse primeito o algoritmo de hashing SHA256 e ent‹o aplicando-se o algoritmo RIPEMD160 no resultado. O hash de 20 bytes do script anterior Ž: 54c557e07dde5bb6cb791c7a5 54c557e07dde 5bb6cb791c7a540e0a4796f5e9 40e0a4796f5e97e 7e
Uma transa•‹o P2SH trava o output nesse hash, e n‹o no script maior, atravŽs do script de travamento: OP_HASH160 54c557e07dde 54c557e07dde5bb6cb791c7a5 5bb6cb791c7a540e0a4796f5e9 40e0a4796f5e97e 7e OP_EQUAL
o qual, como voc pode ver, Ž muito menor. Ao invŽs de "pagar para esse script de mœltiplas assinaturas de 5 chaves", a transa•‹o equivalente P2SH Ž "pagar para um script com esse hash". Um cliente fazendo um pagamento ˆ companhia do Mohammed precisa apenas incluir no seu pagamento esse script de travamento muito menor. Quando o Mohammed quiser gastar esse UTXO, eles precisam apresentar o script de resgate original (aqueles cujo hash travou o UTXO) e as assinaturas necess‡rias para destrav‡-lo, dessa maneira: <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG>
Os dois scripts s‹o combinados em dois est‡gios. Primeiro, o script de resgate Ž verificado em rela•‹o ao script de travamento, para garantir que os hashes correspondem: <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASH160 scriptHash> OP_EQUAL
27
Se o hash do script de resgate corresponder, o script de destravemento Ž executado por conta pr—pria, para destavar o script de resgate: 2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG
Endere•os Pay-to-script-hash Outra parte importante da funcionalidade P2SH Ž a habilidade de codificar um hash de script como um endere•o, que foi definido na BIP0013. Os endere•os P2SH s‹o codifica•›es Base58Check do hash de 20 bytes de um script, da mesma maneira que endere•os bitcoin s‹o codifica•›es Base58Check do hash de 20 bytes de uma chave pœblica. Os endere•os P2SH usam o prefixo de vers‹o "5", que resulta em endere•os codificados em Base58Check que iniciam com um "3". Por exemplo, o script complexo do Mohammed, "hashado" e codificado em Base58Check, como um endere•o P2SH se torna 39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw. Agora, o Mohammed pode fornecer o seu "endere•o" para seus consumidores e eles podem us‡-lo em quase qualquer carteira bitcoin para fazer um pagamento simples, como se ele fosse um endere•o bitcoin. O prefixo 3 lhes d‡ a dica de que esse Ž um tipo especial de endere•o, um que corresponde a um script, ao invŽs de uma chave pœblica, mas fora isso ele funciona exatamente da mesma maneira que um pagamento para um endere•o bitcoin. Os endere•os P2SH escondem toda essa complexidade, de maneira que a pessoa que est‡ fazendo o pagamento n‹o enxerga o script. Benef’cios do pay-to-script-hash A funcionalidade pagar-para-hash-de-script oferece os seguintes benef’cios em compara•‹o ao uso direto de scripts complexos para travar outputs: ¥ Scripts complexos s‹o substitu’dos por impress›es impress›es digitais menores menores no output output da transa•‹o, transa•‹o, tornando a transa•‹o menor. ¥ Os scripts podem ser codificados como um endere•o, endere•o, de maneira que o pagador e a carteira carteira do do pagador n‹o precisem fazer modifica•›es complexas para implementar o P2SH. ¥ O P2SH faz com que o fardo fardo de se construir o script seja do recipiente, recipiente, e n‹o do do pagador ¥ O P2SH passa o fardo fardo do armazenamento armazenamento de dados para para o script longo longo do output (que est‡ no conjunto UTXO) para o input (armazenado na blockchain) ¥ O P2SH faz com que o fardo do do armazenamento de de dados para para o script longo deixe de estar no tempo presente (pagamento) e passe a estar no tempo futuro (quando ele Ž gasto). ¥ O P2SH faz com que que o custo da taxa de transa•‹o de um script longo deixe de ser do pagador e passe a ser do recipiente, que tem que incluir o longo script de resgate para poder gast‡-lo. Script de Resgate e valida•‹o isStandard Antes da vers‹o 0.9.2 do cliente Bitcoin Core, o pagamento-para-hash-de-script era limitado a tipos padr›es de scripts de transa•‹o bitcoin, pela fun•‹o isStandard(). Isso significa que o script de resgate
28
apresentado na transa•‹o de gasto poderia ser de apenas um dos tipos padr›es: P2PK, P2PKH ou de mœltiplas assinaturas, excluindo o OP_RETURN e o pr—prio P2SH. A partir da vers‹o 0.9.2 do cliente Bitcoin Core, as transa•›es P2SH podem conter qualquer script v‡lido, tornando o padr‹o P2SH muito mais flex’vel e permitindo a experimenta•‹o de muitos tipos novos e complexos de transa•›es. Note que voc n‹o consegue colocar um P2SH dentro de um script de resgate P2SH, porque a especifica•‹o P2SH n‹o Ž recursiva. Voc tambŽm n‹o consegue usar o OP_RETURN em um script de resgate porque, por por defini•‹o, o OP_RETURN n‹o pode pode ser resgatado. Como o script de regaste n‹o Ž apresentado para a rede atŽ que voc tente gastar o output P2SH, se voc travar um output com o hash de uma transa•‹o inv‡lida, ela ser‡ processada independente disso. Entretanto, voc n‹o ser‡ capaz de gast‡-lo, pois a transa•‹o de gasto, que inclui o script de resgate, n‹o ser‡ aceita, pois o script Ž inv‡lido. Isso cria um risco, porque voc pode travar um bitcoin em um P2SH que n‹o poder‡ ser gasto mais tarde. A rede ir‡ aceitar a onera•‹o P2SH mesmo que ela corresponda a um script de resgate inv‡lido, pois o hash do script n‹o d‡ nenhuma indica•‹o do script que ele representa.
WARNING
Os scripts de travamento P2SH contŽm o hash de um script de resgate, que n‹o d‡ dicas do conteœdo do script de resgate. A transa•‹o P2SH ser‡ considerada v‡lida e ser‡ aceita mesmo se o script de resgate for inv‡lido. Dessa maneira, voc pode travar bitcoins acidentalmente, que n‹o poder‹o ser gastos mais tarde.
29
A Rede Bitcoin A Arquitetura de Rede Ponto-a-Pon Ponto-a-Ponto to O Bitcoin Ž estruturado como uma arquitetura de rede ponto-a-ponto em cima da Internet. O termo ponto-a-ponto, ou P2P (do ingls peer-to-peer), significa que os computadores que participam da rede s‹o pontos uns para os outros, que eles s‹o todos iguais, que n‹o h‡ nodos "especiais" e que todos os nodos compartilham o trabalho de fornecer servi•os na rede. Os nodos da rede se interconectam em uma rede mesh com uma topologia "plana". N‹o h‡ nenhum servidor, nenhum servi•o centralizado ou hierarquia na rede. Os nodos em uma rede ponto-a-ponto tanto fornecem quanto consomem servi•os ao mesmo tempo com a reciprocidade atuando como o incentivo para a participa•‹o. Redes ponto-aponto s‹o inerentemente resilientes, descentralizadas e abertas. O exemplo proeminente de uma arquitetura de rede P2P foi a Internet em seu in’cio, onde os nodos na rede IP eram iguais. A arquitetura de Internet hoje Ž mais hier‡rquica, mas o Protocolo da Internet ainda mantŽm sua essncia de topologia plana. AlŽm do bitcoin, a aplica•‹o mais difundida e de maior sucesso das tecnologias P2P Ž o compartilhamento de arquivos, com o Napster sendo o pioneiro e o BitTorrent como a evolu•‹o mais recente da arquitetura. A arquitetura de rede P2P do Bitcoin Ž muito mais do que uma escolha de topologia. O bitcoin Ž projetado como um sistema de dinheiro digital ponto-a-ponto, e a arquitetura da rede Ž tanto um reflexo e uma base fundamental dessa caracter’stica chave. Descentraliza•‹o do controle Ž um princ’pio chave do projeto e ela s— pode ser obtida e mantida atravŽs de uma rede de consenso P2P descentralizada. O termo "rede bitcoin" refere-se ˆ cole•‹o de nodos executando o protocolo ponto-a-ponto (P2P) bitcoin. AlŽm do protocolo P2P bitcoin, existem outros protocolos como o Stratum, que s‹o usados para minera•‹o e carteiras leves ou m—veis. Esses protocolos adicionais s‹o fornecidos por servidores de roteamento de gateway que acessam a rede bitcoin usando o protocolo P2P bitcoin, e ent‹o estendem essa rede aos nodos executando outros protocolos. Por exemplo, os servidores Stratum se conectam os nodos mineradores Stratum atravŽs do protocolo Stratum ˆ rede bitcoin principal e fazem um bridge do protocolo Statum com o protocolo P2P bitcoin. N—s usamos o termo "rede bitcoin estendida" para referirmos ˆ rede geral que inclui o protocolo P2P bitcoin, protocolos de minera•‹o-pool, o protocolo Stratum e qualquer outros protocolos relacionados que conectem os componentes do sistema bitcoin.
Tipos e PapŽis dos Nodos Embora os nodos na rede P2P do bitcoin s‹o iguais, eles podem assumir diferentes papŽis dependendo da funcionalidade que eles estejam suportando. Um nodo bitocin Ž uma cole•‹o de fun•›es: roteamento, o banco de dados da blockchain, minera•‹o e servi•os de carteira. Um nodo completo com todas essas quatro fun•›es Ž demonstrado em Um nodo da rede Bitcoin com todas as quatro fun•›es: carteira, minerador, minerador, banco de dados completo da blockchain e roteador da rede .
1
Figure 1. Um nodo nodo da rede Bitcoin com com todas as quatro quatro fun•›es: carteira, carteira, minerador, minerador, banco de dados dados completo da blockchain e roteador da rede
Todos os nodos nodos incluem a fun•‹o de roteamento roteamento para participar participar na rede e podem podem incluir outras funcionalidades. Todos os nodos validam e propagam as transa•›es e blocos, e descobrem e mantŽm conex›es com os pontos. No exemplo do nodo completo em Um nodo da rede Bitcoin com todas as quatro fun•›es: carteira, minerador, banco de dados completo da blockchain e roteador da rede , a fun•‹o de roteamento Ž indicada por um c’rculo laranja chamado de "Nodo de Roteamento de Rede." Alguns nodos, chamados de n—s completos, tambŽm mantŽm uma c—pia completa e atualizada do blockchain. Nodos completos podem verificar verificar de maneira maneira aut™noma e autorit‡ria autorit‡ria qualquer transa•‹o sem referncia externa. Alguns nodos mantm somente uma parte do blockchain e verifica transa•›es utilizando um mŽtodo chamado verifica•‹o de pagamento simplificada, ou SPV. Estes nodos s‹o conhecidos como SPV ou nodos peso-leve. No exemplo exemplo nodos completos da figura, a fun•‹o base base de dados blockchain nodo completo est‡ indicado por um c’rculo azul denominado "Blockchain 2
Completo". Em A rede bitcoin estendida mostrando v‡rios tipos de nodos, gateways e protocolos , nodos SPV est‹o representados sem o c’rculo azul, indicando que estes n‹o tm uma c—pia completa do blockchain. Os nodos de minera•‹o competem para criar novos blocos ao utilizarem hardware especializado para resolver os algoritmos de prova-de-tr prova-de-trabalho. abalho. Alguns nodos de minera•‹o tambŽm s‹o nodos completos, mantendo uma c—pia completa da blockchain, enquanto outros s‹o nodos peso leve (lightweight) que participam de um pool de minera•‹o e dependem de um servidor de pool para manter um nodo completo. A fun•‹o de minera•‹o Ž demonstrada no nodo completo como um c’rculo preto chamado de "Minerador." As carteiras de usu‡rios podem fazer parte de um nodo completo, que Ž o que geralmente ocorre em clientes desktop do bitcoin. Cada vez mais as carteiras de usu‡rio s‹o nodos VSP, especialmente aquelas sendo executadas em dispositivos com poucos recursos como smartphones. A fun•‹o carteira Ž demonstrada Um nodo da rede Bitcoin com todas as quatro fun•›es: carteira, minerador, banco de dados completo da blockchain e roteador da rede em rede em como um c’rculo verde chamado de "Carteira" "Carteira" AlŽm dos tipos de nodos principais no protocolo P2P bitcoin, existem servidores e nodos executando outros protocolos, como protocolos especializados em minera•‹o-pool e protocolos de acesso de clientes com aplicativos leves (lightweight). Diferentes tipos de nodos na rede bitcoin estendida mostra os tipos mais comuns de nodos na rede bitcoin estendida.
A Rede Bitcoin Estendida A rede bitcoin principal, executando o protocolo P2P bitcoin, consistem entre 7.000 e 10.000 nodos ativos rodando v‡rias vers›es do cliente bitcoin de referncia (Bitcoin Core) e algumas centenas de nodos rodando v‡rias outras implementa•›es do protoclo P2P bitcoin, como o BitconJ, Libbitcoin e btcd. Uma pequena porcentagem dos nodos na rede bitcoin P2P tambŽm s‹o nodos mineradores, competindo em um processo de minera•‹o, validando transa•›es e criando novos blocos. V‡rias grandes companhias participam da rede bitcoin ao rodas clientes de nodo completos no cliente Bitcoin Core, com c—pias completas da blockchain e um nodo da rede, mas sem fun•›es de minera•‹o ou de carteira. Esses nodos atuam como roteadores de borda da rede, permitindo que v‡rios outros servi•os (exchanges, carteiras, exploradores de bloco, processamento de pagamentos a comerciantes) sejam constru’dos em seu topo. A rede bitcoin estendida inclui a rede executando o protocolo P2P bitcoin, descrita anteriormente, assim como nodos executando protocolos especializados. Ligados a essa rede P2P bitcoin principal existem v‡rios servidores pool e gateways de protocolo que conectam nodos executando outros protocolos. Esses nodos usando outros protocolos protocolos s‹o em sua maioria nodos de de pool de minera•‹o minera•‹o (ver [ch8])e [ch8] )e clientes de carteira leves (lightweight), que n‹o carregam uma c—pia completa de blockchain. A rede bitcoin estendida mostrando v‡rios tipos de nodos, gateways e protocolos demonstra a rede bitcoin estendida com os v‡rios tipos de nodos, servidores gateway, roteadores edge e clientes de carteira, alŽm dos v‡rios protocolos que eles usam para conectar-se uns com os outros. 3
4
Figure 2. Diferentes Diferentes tipos de nodos na na rede bitcoin estendida estendida
5
6
Figure 3. A rede bitcoin bitcoin estendida mostrando mostrando v‡rios v‡rios tipos de nodos, gateways e protocolos protocolos
Descoberta da Rede Quando um novo nodo Ž ligado, ele deve descobrir outros nodos bitoins na rede para que possa participar. Para iniciar esse processo, um nodo novo deve descobrir pelo menos um nodo existente na rede para conectar-se a ele. A localiza•‹o geogr‡fica dos outros nodos Ž irrelevante; a t opologia da rede bitcoin n‹o Ž definida geograficamente. Logo, qualquer nodo bitcoin existente pode ser selecionado aleatoriamente. Para se conectar a um ponto conhecido, os nodos estabelecem uma conex‹o TCP, geralmente na porta 8333 (a porta geralmente conhecida como uma das usadas pelo bitcoin), ou a uma porta alternativa caso tenha sido fornecida. Ao estabelecer a conex‹o, o nodo iniciar‡ um "aperto de m‹o" (ver O aperto de m‹os inicial entre os pontos) pontos ) ao transmitir uma mensagem de vers‹o, que contŽm basicamente informa•›es de identifica•‹o, incluindo: PROTOCOL_VERS PROT OCOL_VERSION ION
Uma constante que define a vers‹o do protocolo P2P do bitcoin atravŽs da qual o cliente se "comunica" (ex: 70002) nLocalServices
Uma lista dos servi•os locais suportados pelo nodo, atualmente apenas NODE_NETWORK nTime
A hora atual addrYou
O endere•o IP do nodo remoto da maneira que Ž visto por esse nodo addrMe
O endere•o IP do nodo local, da maneira que Ž descoberto pelo nodo local subver
Uma sub-vers‹o mostrando o tipo de software sendo executado nesse nodo (ex: "/Satoshi:0.9.2.1/")+ BestHeight
A altura dos blocos da blockchain deste nodo (Veja GitHub GitHub para para um exemplo da mensagem de rede version.) O nodo ponto responde com verack para reconhecer e estabelecer uma conex‹o, e opcionalmente envia sua pr—pria mensagem vers‹o caso ele desejar estabelecer uma conex‹o rec’proca e se conectar como um ponto. Como um nodo novo encontra seus pontos (peers)? O primeiro mŽtodo Ž solicitar o DNS usando v‡rias
7
"sementes (seeds) de DNS," que s‹o servidores DNS que fornecem uma lista de endere•os IP dos nodos bitcoin. Algumas dessas sementes DNS fornecem uma lista est‡tica de endere•os IPs de nodos bitcoin de escuta. Algumas dessas sementes DNS s‹o implementa•›es customizadas de BIND (Berkeley Internet Name Daemon) que retornam um conjunto aleat—rio a partir de uma lista de endere•os de nodo bitcoin coletada por um crawler ou um nodo bitcoin de longa-execu•‹o. O cliente Bitcoin Core contŽm os nomes de cinco sementes DNS diferentes. A diversidade de donos e a diversidade de implementa•‹o das diferentes sementes DNS oferece um alto n’vel de confiabilidade para o processo de bootstrapping inicial. No cliente Bitcoin Core, a op•‹o para usar as sementes DNS Ž controlada pela op•‹o switch -dnsseed (definida como 1 por padr‹o, para usar a semente DNS). De maneira alternativa, um nodo bootstrapping que n‹o saiba nada da rede deve receber o endere•o IP de pelo menos um nodo bitcoin, a partir do qual ele poder‡ estabelecer conex›es atravŽs de novas introdu•›es. O argumento de linha de comando -seednode pode ser usado para conectar a um nodo somente para introdu•›es, utilizando-o como uma semente (seed). Ap—s o nodo semente inicial ser usado para formar as introdu•›es, o cliente ir‡ se desconectar dele e usar‡ os novos pontos recŽmdescobertos.
8
Figure 4. O aperto aperto de m‹os inicial entre entre os pontos
Assim que uma ou mais conex›es s‹o estabelecidas, o novo nodo ir‡ enviar uma mensagem addr contendo seu pr—prio endere•o IP para seus vizinhos. Seus vizinhos ir‹o, por sua vez, retransmitir a mensagem addr para seus vizinhos, garantindo que os novos nodos conectados se tornem bem conhecidos e melhor conectados. Adicionalmente, o novo nodo conectado pode enviar getaddr para os vizinhos, solictando-os que retornem uma lista de endere•os IP de seus pontos. Dessa maneira, um nodo pode encontrar pontos para conectar-se e divulgar sua existncia na rede para que outros nodos o encontrem. Propaga•‹o e descoberta do endere•o demonstra endere•o demonstra o protocolo de descoberta de endere•o.
9
Figure 5. Propaga•‹o Propaga•‹o e descoberta do endere•o endere•o
Um nodo precisa conectar-se a alguns poucos peers diferentes para estabelecer v‡rios caminhos na rede bitcoin. Os caminhos n‹o s‹o confi‡veisÑos nodos ficam online e offlineÑe ent‹o o nodo precisa continuar a descobrir novos nodos ˆ medida que ele perde conex›es antigas, assim como auxilia outros nodos quando eles fazem bootstrap. Somente uma conex‹o Ž necess‡ria para fazer bootstrap, porque o primeiro nodo pode oferecer apresenta•›es para seus nodos pontos e esses pontos podem oferecer novas apresenta•›es subsequentes. Conectar-se a mais de alguns nodos tambŽm Ž desnecess‡ria e desperdi•a recursos da rede. Ap—s fazer bootstrap, um nodo ir‡ se lembrar de suas conex›es de sucesso mais recentes com pontos, de maneira que se reiniciado ele poder‡ rapidamente reestabelecer conex›es com sua rede de pontos prŽvia. Se nenhum dos antigos pontos responder ˆ sua solicita•‹o de conex‹o, o nodo pode usar os nodos sementes para fazer bootstrap novamente. novamente.
10
Em um nodo executando o cliente Bitcoin Core, voc pode listar as conex›es com os peers atravŽs do comando getpeerinfo: $ bitcoin-cli getpeerinfo
[ { "addr" : "85.213.199. "85.213.199.39:8333", 39:8333", "services" : "00000001", "lastsend" : 1405634126, "lastrecv" : 1405634127, "bytessent" : 23487651, "bytesrecv" : 138679099, "conntime" : 1405021768, "pingtime" : 0.00000000, "version" : 70002, "subver" : "/Satoshi:0.9 "/Satoshi:0.9.2.1/", .2.1/", "inbound" : false, "startingheight" "startingheig ht" : 310131, "banscore" : 0, "syncnode" : true }, { "addr" : "58.23.244.2 "58.23.244.20:8333", 0:8333", "services" : "00000001", "lastsend" : 1405634127, "lastrecv" : 1405634124, "bytessent"" : 4460918, "bytessent "bytesrecv"" : 8903575, "bytesrecv "conntime" : 1405559628, "pingtime" : 0.00000000, "version" : 70001, "subver" : "/Satoshi:0.8 "/Satoshi:0.8.6/", .6/", "inbound" : false, "startingheight" "startingheig ht" : 311074, "banscore" : 0, "syncnode" : false } ]
Para desativar a administra•‹o autom‡tica dos pontos e especificar uma lista de endere•os IP, os usu‡rios podem usar a op•‹o -connect= e especificar um ou mais endere•os IP. Se essa op•‹o for utilizada, o nodo ir‡ conectar-se somente aos endere•os IP selecionados, ao invŽs de automaticamente descobrir e manter conex›es com pontos.
11
Se n‹o houver tr‡fico em uma conex‹o, os nodos ir‹o periodicamente enviar uma mensagem para manter a conex‹o. Se um nodo n‹o se comunicar em uma conex‹o por mais de 90 minutos, assume-se que ele esteja desconectado e um novo ponto ser‡ procurado. Logo, a rede dinamicamente ajusta-se aos nodos transit—rios e aos problemas da rede, e pode crescer e diminuir organicamente conforme necess‡rio, sem a necessidade de um controle central.
Nodos completos Os nodos completos s‹o nodos que mantŽm uma blockchain completa com todas as transa•›es. Mais precisamente, eles provavelmente deveriam ser chamados de "nodos com a blockchain completa". Nos anos iniciais do bitcoin, todos os nodos eram nodos completos e atualmente o cliente Bitcoin Core Ž um nodo com a blockchain completa. Nos œltimos dois anos, no entanto, novas formas de clientes bitcoins foram introduzidas que n‹o precisam manter uma blockchain completa, mas s‹o executandos como clientes leves ("lightweight"). N—s examinaremos esses clientes em mais detalhes na pr—xima se•‹o. Os nodos com a blockchain completa mantŽm uma c—pia completa e atualizada da blockchain do bitcoin com todas as transa•›es, a qual eles independentemente construiram e verificaram, iniciando desde o primeiro bloco (bloco gnese) e adicionando atŽ o œltimo bloco conhecido da rede. O nodo com a blockchain completa pode verificar independentemente e com autoridade qualquer transa•‹o sem depender de qualquer outro nodo ou fonte de informa•‹o. O nodo completo depende da rede para receber atualiza•›es sobre novos blocos de transa•›es, as quais ele verifica e incorpora em sua c—pia local da blockchain. Executar um nodo com a blockchain completa proporciona a experincia bitcoin pura: verifica•‹o independente de todas as transa•›es, sem a necessidade de dependncia ou confian•a em qualquer outro sistema. ƒ f‡cil dizer se voc est‡ executando um nodo completo porque ele requer mais de 20 gigabytes de armazenamento persistente (espa•o em diasco) para armazenar a blockchain completa. Se voc precisa de muito espa•o e ele leva dois a trs dias para sincronizar com a rede, voc est‡ executando um nodo completo. Esse Ž o pre•o que se paga para uma liberdade completa e total independncia de uma autoridade central. Existem algumas poucas implementa•›es alternativas dos clientes de bitcoin com a blockchain completa, constru’das usando-se diferentes linguagens de programa•‹o e arquiteturas de software. No entanto, a implementa•‹o mais comum Ž o cliente de referncia Bitcoin Core, tambŽm conhecido como o cliente Satoshi. Mais de 90% dos noso na rede bitcoin executam v‡rias vers›es do Bitcoin Core. Ele Ž identificado como "Satoshi" na string sub-version enviada na mensagem version e Ž mostrado pelo comando getpeerinfo como n—s vimos anteriormente; por exemplo, /Satoshi:0.8.6/.
Trocando o "Invent‡rio" A primeira coisa que um nodo completo far‡ assim que se conectar aos pontos Ž tentar construir uma blockchain completa. Se ele for um nodo recŽm criado que n‹o tenha nenhuma parte da blockchain, ele s— ter‡ um bloco, o bloco gnese, que Ž inclu’do estaticamente no software do cliente. Iniciando com o bloco #0 (o bloco gnese), o novo nodo ter‡ que fazer o download de centenas de milhares de blocos para sincronizar-se com a rede e re-estabelecer a blockchain completa. 12
O processo de sincroniza•‹o da blockchain Ž iniciado a partir da mensagem version, pois ela contŽm o BestHeight, a altura atual (nœmero de blocos) da blockchain de um nodo. Ao ver a mensagem version de seus pontos, um nodo saber‡ quantos blocos cada um deles tem, e ser‡ capaz de comparar com o nœmero de blocos que existem em sua pr—pria blockchain. Os nodos pareados ir‹o trocar uma mensagem getblocks, a qual contŽm o hash (impress‹o digital) do bloco mais alto de suas blockchains locais. A seguir, um ponto ser‡ capaz de identificar que o hash recebido pertence ao bloco que n‹o est‡ no topo, mas que pertence a um bloco antigo, logo deduzindo que sua blockchain local Ž mais comprida do que a de seus pontos. O ponto que tem a blockchain mais longa possui mais blocos que o outro nodo e pode identificar quais blocos o outro nodo precisa para ficar "em dia". Ele ir‡ identificar os primeiros 500 blocos para compartilhar e transmitir‡ transmitir‡ seus hashes hashes usando uma mensagem inv (inventory) . O nodo nodo que estiver com esses blocos faltando ir‡ ent‹o receb-los ao emitir uma sŽrie de mensagens getdata solicitando os dados completos dos blocos e identificando os blocos solicitados usando os hashes da mensagem inv. Vamos assumir, por exemplo, que um nodo tenha apenas o bloco gnese. Ele ir‡ ent‹o receber uma mensagem inv de seus pontos contendo os hashes dos pr—ximos 500 blocos na cadeia. Ele ir‡ come•ar a solicitar blocos de todos os seus pontos conectados, espalhando a carga e garantindo que ele n‹o sobrecarregue nenhum de seus pontos com requisi•›es. O nodo mantŽm um registro de quantos blocos est‹o "em tr‰nsito" por conex‹o com ponto, significando os blocos que ele solicitou mas n‹o recebeu, certificando-se que ele n‹o exceda um limite (MAX_BLOCKS_IN_TRANSIT_PER_PEER). Dessa maneira, se ele precisar de muitos blocos, ele ir‡ somente ir‡ solicitar novos quando as solicita•›es prŽvias forem completadas, permitindo que os pontos controlem o ritmo de updates e n‹o sobrecarregando a rede. Ë medida que cada bloco Ž recebido, ele Ž adicionado ˆ blockchain, como n—s iremos ver em [blockchain].. Ë medida que a blockchain Ž gradultamente constru’da, mais blocos s‹o solicitados e [blockchain] recebidos, e o processo continua atŽ que o nodo alcance o resto da rede. Esse processo de comparar a blockchain local com os pontos e adquirir quaisquer blocos em falta acontece sempre que um bloco fica offline por algum per’odo de tempo. Tenha um nodo ficado offline por alguns minutos e esteja com alguns pouco blocos em falta, ou tenha t enha ficado um ms offeline e esteja com milhares de blocos em falta, ele come•a ao enviar getblocks, recebeuma resposta inv e inicia baixando os blocos remanescentes. Nodo sincronizando a blockchain ao adquirir blocos de um ponto demonstra o invent‡rio e o protocolo de propaga•‹o dos blocos.
Nodos de Verifica•‹o Simplificada de Pagamento (VSP) Nem todos os nodos tem a habilidade de armazenar a blockchain completa. Muitos clientes bitcoin s‹o projetados para serem executados em dispositivos com limita•›es de armazenamento e energia, como smartphones, tablets ou sistemas embutidos. Para esses dispositivos, um mŽtodo de verifica•‹o simplificada de pagamento Ž usado para permit’-los que operem sem terem que armazenar a blockchain completa. Esses tipos de clientes s‹o chamados clientes VSP (em ingls, SPV) ou clientes leves. Conforme a adoa•‹o do bitcoin aumenta, o nodo VSP est‡ se tornando a forma mais comum de nodo bitcoin, especialmente para carteiras bitcoin. Os nodos VSP baixam apenas os cabe•alhos dos blocos e n‹o baixam as transa•›es inclu’das em cada
13
bloco. A cadeia de blocos resultante, sem as transa•›es, Ž 1.000 vezes menor do que a blockchain completa. Os nodos VSP n‹o podem construir um figura completa de todas as UTXOs que est‹o dispon’veis para serem gastas porque eles n‹o conhecem todas as transa•›es da rede. Os nodos VSP verificam as transa•›es usando uma metodologia levemente diferente, a qual se baseia nos pontos que fornecem, sob demanda, consultas de apenas algumas partes relevantes da blockchain.
14
15
Figure 6. Nodo sincronizand sincronizando o a blockchain blockchain ao adquirir blocos blocos de um ponto ponto
Como uma analogia, um nodo completo Ž como um turista em uma cidade estranha, equipado com um mapa detalhado de cada rua e cada endere•o. Em compara•‹o, um nodo de VSP Ž como um turista em uma cidade estranha perguntando a desconhecidos aleat—rios na rua por orienta•›es de como chegar a um lugar, enquanto ele sabe apenas o nome de uma avenida principal. Embora ambos os turistas possam verificar a existncia de uma rua ao visit‡-la, o turista sem o mapa n‹o sabe o que se passa em cada rua colateral e n‹o sabe quais outras ruas existem. Posicionado na frente da Rua da Igreja 23, o turista sem o mapa n‹o tem como saber se existem uma dœzia de outros endere•os "Rua da Igreja 23" na cidade e se ele est‡ no endere•o correto. A melhor chance de um turista sem mapa Ž perguntar para um nœmero suficiente de pessoas e torcer para que alguns deles n‹o estejam tentando lhe passar a perna. A verifica•‹o simplificada de pagamento verifica as transa•›es atravŽs de referncias ˆs suas profundidades na blockchain, ao invŽs de sua altura. Enquanto um nodo com a blockchain completa ir‡ construir uma cadeia completamente verificada de milhares de blocos e transa•›es que siga pela blockchain (retrospectivamente (retrospectivamente no tempo) atŽ o bloco gnese, um nodo de VSP ir‡ verificar a cadeia de todos os blocos (mas n‹o todas as transa•›es) e ir‡ ligar essa cadeia ˆ transa•‹o de interesse. Por exemplo, ao examinar uma transa•‹o no bloco 300.000, um nodo completo segue todos os 300.000 blocos atŽ o bloco gnese e constr—i um banco de dados completo de UTXO, estabelecendo a validade da transa•‹o ao confirmar que a UTXO ainda n‹o foi gasta. Um nodo de VSP n‹o pode validar se a UTXO ainda n‹o foi gasta. Ao invŽs disso, o nodo de VSP ir‡ estabelecer uma conex‹o entre a transa•‹o e o bloco que a contŽm, usando um caminho de Merkle (veja [merkle_trees] [merkle_trees]). ). Ent‹o, o nodo de VSP aguarda atŽ ver os seis blocos do 300.0001 atŽ o 300.006 empilhados sobre o topo do bloco ontendo a transa•‹o e verifica-a ao estabelecer sua profundidade sob os blocos 300.006 a 300.001. O fato de que outros nodos na rede aceitaram o bloco 300.000 e ent‹o fizeram o trabalho necess‡rio para produzir mais seis blocos no seu topo Ž a prova, atravŽs de proxy, proxy, que a transa•‹o n‹o foi um gasto duplo. Um nodo de VSP n‹o pode ser convencido de que uma transa•‹o existe em um bloco quando a transa•‹o de fato n‹o existe. O nodo de VSP estebelece que uma transa•‹o existe em um bloco ao solicitar um caminho de merkle como prova e ao validar a prova de trabalho na cadeia de blocos. Entretanto, a existncia de uma transa•‹o pode ser "escondida" de um nodo de VSP. Um nodo de VSP pode provar definitivamente que uma transa•‹o existe, mas n‹o pode verificar que uma transa•‹o, como um gasto duplo de uma mesma UTXO, n‹o existe porque ele n‹o tem um registro de todas as transa•›es. Essa vulnerabilidade pode ser usada em um ataque de nega•‹o de servi•o (DOS) ou para um ataque de gasto duplo contra os nodos de VSP. Para defender-se contra isso, um nodo de VSP precisa se conectar aleatoriamente a v‡rios nodos, para aumentar a probabilidade de que ele esteja em contato com pelo menos um nodo honesto. Essa necessidade de se conectar aleatoriamente significa que os nodos de VSP tambŽm s‹o vulner‡veis a ataques de particionamento de rede ou ataques Sybil, onde eles s‹o conectados a nodos ou redes fakes e n‹o tem acesso a nodos honestos ou ˆ rede bitcoin verdadeira. Para a maioria das fun•›es pr‡ticas, os nodos VPS bem-conectados s‹o seguros o suficiente, demonstrando um equil’brio ideal entre necessidade de recursos, praticidade e seguran•a. Para seguran•a infal’vil, no entanto, nada Ž superior do que executar um nodo com a blockchain completa. 16
TIP
Um nodo que tem a blockchain completa verifica a transa•‹o ao fazer uma pesquisa em sua cadeia inteira de milhares de blocos, para se certificar de que a UTXO j‡ n‹o foi gasta previamente, enquanto um nodo VSP verifica ao pesquisar qu‹o profundo o bloco est‡ "enterrado"" sob os v‡rios blocos acima dele. "enterrado
Para receber os cabe•alhos dos blocos, os nodos de VSP usam uma mensagem getheaders ao invŽs de getblocks. O ponto que responder ir‡ enviar atŽ 2.000 cabe•alhos de blocos usando uma mensagem headers œnica. O processo Ž o mesmo que o utilizado por um nodo completo receber os blocos completos. Os nodos de VSP tambŽm definem um filtro na conex‹o com os pontos, para filtrar a transmiss‹o de blocos futuros e transa•›es enviadas pelos pontos. Quaisquer transa•›es de interesse s‹o recebidas usando uma requisi•‹o getdata. Em resposta, os pontos geram uma mensagem tx contendo as transa•›es. Nodo SPV sincronizando os cabe•alhos dos blocos mostra blocos mostra a sincroniza•‹o dos cabe•alhos dos blocos.
17
Figure 7. Nodo SPV sincronizando sincronizando os cabe•alhos cabe•alhos dos blocos
Como os nodos de VSP precisam baixar transa•›es espec’ficas para verific‡-las seletivamente, eles tambŽm criam um risco de privacidade. Ao contr‡rio dos nodos com a blockchain completa, que baixam todas as transa•›es no interior de cada bloco, as solicita•›es por dados espec’ficos que s‹o feitas pelos nodos de VSP podem inadvertidamente revelar os endere•os em suas carteiras. Por exemplo, um terceiro monitorando monitorando uma rede poderia monitorar monitorar todas as transa•›es transa•›es solicitadas por
18
uma carteira em um nodo de VSP e us‡-las para associar endere•os bitcoins com o usu‡rio dessa carteira, destruindo a privacidade do usu‡rio. Logo ap—s a introdu•‹o dos nodos VSP/peso leve, os desenvolvedores bitcoin adicionaram uma funcionalidade chamada filtros bloom para resolver os riscos de privacidade dos nodos VSP. Os filtros bloom permitem que os nodos VSP recebam um conjunto de transa•›es sem que revelem precisamente quais endere•os eles est‹o interessados, atravŽs de um mecanismo de filtros que utiliza probabilidadess ao invŽs de padr›es fixos. probabilidade
Filtros Bloom Um filtro bloom Ž um filtro de busca probabil’stico, uma maneira de descrever um padr‹o desejado sem especific‡-lo exatamente. Os filtros bloom oferecem uma maneira eficiente de expressar um padr‹o de brusca enquanto protegem a privacidade. Eles s‹o usados pelos nodos VSP para requisitar seus pontos por transa•›es coincidindo com um padr‹o espec’fico, sem revelar exatamente quais endere•os eles est‹o procurando. Na analogia prŽvia, uma turista sem um mapa est‡ perguntando por orienta•›es para um endere•o espec’fico, na "Rua Church 23". Se ela perguntar por orienta•›es para estrangeiros nessa rua, ela inadvertidamente revelar‡ seu destino. Um filtro bloom Ž como se perguntasse, "Existem ruas nessa vizinhan•a cujo nome termina em R-C-H?" Uma pergunta como essa revela um pouco menos sobre o destino desejado do que perguntando por "Rua Church 23". Usando essa tŽcnica, a turista poderia especificar o endere•o desejado em mais detalhes como "termina em U-R-C-H" ou menos detalhe como "termina em H". Ao variar a precis‹o de sua busca, a tursta revela mais ou menos informa•›es, ˆs custas de resultados mais ou menos espec’ficos. Se ela perguntar um padr‹o menos espec’fico, ela receber‡ muito mais endere•os poss’veis e ter‡ uma privacidade maior, mas muitos dos resultados ser‹o irrelevantes. Se ela perguntar por um padr‹o muito espec’fico, ela receber‡ poucos resultados, mas perder‡ em privacidade. Os filtros bloom servem essa fun•‹o ao permitir que um nodo VSP especifique um padr‹o de busca para transa•›es que possa ser refinado de acordo com precis‹o ou privacidade. Um filtro bloom mais espec’fico ir‡ produzir resultados precisos, mas ˆs custas de revelar quais endere•os s‹o usados na carteira do usu‡rio. Um filtro bloom menos espec’fico ir‡ produzir mais dados sobre mais transa•›es, muitas irrelevantes para o nodo, mas permitir‡ ao nodo que mantenha uma privacidade maior. Um nodo de VSP ir‡ inicializar um filtro bloom como "vazio" e nesse estado o filtro bloom n‹o ir‡ corresponder a nenhum padr‹o. O nodo de VSP ir‡ ent‹o fazer uma lista de todos t odos os endere•os em sua carteira e criar‡ um padr‹o de b usca que corresponda ao output da transa•‹o correspondente a cada endere•o. Geralmente, Geralmente, o padr‹o de busca Ž um script pay-to-public-key-hash pay-to-public-key-hash que Ž o script de locking esperado que estar‡ presente em qualquer transa•‹o pagando ao public-key-hash (endere•o). Se o nodo de VSP estiver registrando o saldo de um endere•o P2SH, o padr‹o de busca ser‡ um script payto-script-hash. O nodo de VSP adiciona ent‹o cada um dos padr›es de busca ao filtro bloom, de maneira que o filtro bloom possa reconhecer o padr‹o de busca se ele estiver presente em uma transa•‹o. Por fim, o filtro bloom Ž enviado ao ponto e o ponto o utiliza para corresponder as transa•›es para transmiss‹o para o nodo de VSP.
19
Os filtros bloom s‹o implementados como uma array de tamanho vari‡vel de N d’gitos bin‡rios (um campo bit) e um nœmero vari‡vel de M fun•›es hash. As fun•›es hashes s‹o projetadas para sempre produzir um output entre 1 e N, correspondendo ˆ array de d’gitos bin‡rios. As fun•›es hash s‹o geradas deterministicamente, de maneira que qualquer nodo implementando um filtro bloom sempre usar‡ as mesmas fun•›es hash e receber‡ os mesmos resultados para um input espec’fico. Ao escolher filtros bloom de diferentes comprimentos (N) e um nœmero diferente (M) de fun•›es hash, o filtro bloom pode ser melhorado, variando o n’vel de acur‡cia, e, portanto, de privacidade. Em Um exemplo de um filtro bloom simpl’stico, com um campo de 16-bit e trs fun•›es hash , n—s usamos um array muito pequeno de 16 bits e um conjunto c onjunto de trs fun•›es hash para demonstrar como os filtros bloom funcionam.
Figure 8. Um exemplo exemplo de um filtro filtro bloom simpl’stico, simpl’stico, com um campo de 16-bit e trs trs fun•›es hash
O filtro bloom Ž inicializado de maneira que a array de bits seja toda de zeros. Para adicionar um padr‹o ao filtro bloom, o padr‹o Ž "hashado" por cada fun•‹o hash em cada vez. A aplica•‹o da primeira fun•‹o de hash nos resultados do input resulta em um nœmero entre 1 e N. O bit correspondente na array (indexado de 1 a N) Ž encontrado e definido como 1, logo, registrando o output da fun•‹o hash. Logo, a pr—xima fun•‹o hash Ž usada para para definir outro bit, e assim por diante. diante. Uma vez que todas as fun•›es hash M forem aplicadas, o padr‹o de busca ser‡ "registrado" no filtro bloom como M bits que mudaram de 0 para 1. Adicionando um padr‹o "A" para o nosso filtro bloom simples Ž um exemplo da adi•‹o de um padr‹o "A" para o filtro bloom simples mostrado em Um exemplo de um filtro bloom simpl’stico, com um campo de 16-bit e trs fun•›es hash. hash. Adicionar um segundo padr‹o Ž t‹o simples quanto repetir esse processo. O padr‹o Ž "hashado" por cada fun•‹o hash de cada vez e o resultado Ž registrado ao definir os bits como 1. Note que ˆ medida que o filtro bloom Ž preenchido com mais padr›es, um resultado de fun•‹o hash pode coincidir com um bit que j‡ esteja definido como 1, neste caso o bit n‹o Ž modificado. Em essncia, ˆ medida que mais padr›es gravam em bits sobreponentes, o filtro bloom come•a a se tornar saturado com mais bits definidos como 1 e a acur‡cica do filtro diminui. ƒ por isso que o filtro Ž uma estrutura de dados
20
probabil’sticaÑele se torna menos acurado conforme mais padr›es s‹o adicionados. A acur‡cica depende do nœmero de fun•›es hash (M). Uma array de bit maior e mais fun•›es hashes podem registrar mais padr›es com maior acur‡cica. Uma array de bit menor ou menos fun•›es hash ir‡ registrar menos padr›es e ter‡ menor acur‡cia.
Figure 9. Adicionando Adicionando um padr‹o padr‹o "A "A" para o nosso nosso filtro bloom bloom simples
Adicionando um segundo padr‹o "B" para o nosso filtro bloom simples Ž um exemplo da adi•‹o de um segundo padr‹o "B" para o filtro bloom simples.
21
Figure 10. Adicionando Adicionando um segundo padr‹o "B" para o nosso nosso filtro bloom bloom simples
Para testar se um padr‹o faz parte de um filtro bloom, o padr‹o Ž "hashado" por cada fun•‹o hash e o padr‹o bit resultante Ž testado contra a bit array. Se todos os bits indexados pelas fun•›es hash s‹o definidas para 1, ent‹o o padr‹o Ž provavelmente registrado no filtro bloom. Como os bits podem ser definidos devido a sobreposi•‹o de mœltiplos padr›es, a resposta n‹o Ž certa, ao invŽs disso, ela Ž probabil’stica. Em termos simples, uma correspondncia positiva em filtro bloom Ž um "Talvez "Talvez,, Sim." Testando a existncia de um padr‹o "X" no filtro bloom. O resultado Ž uma correspondncia positiva probabil’stica, significando "Talvez." Ž "Talvez." Ž um exemplo de teste da existncia do padr‹o "X" no filtro bloom simples. Os bits correspondentes est‹o definidos como 1, ent‹o o padr›a Ž provavelmente uma correspondncia.
22
Figure 11. Testando Testando a existncia existncia de um padr‹o "X" "X" no filtro bloom. O resultado resultado Ž uma correspondncia correspondncia positiva probabil’stica, probabil’stica, significando significando "Talvez." "Talvez."
Por outro lado, se um padr‹o for testado contra um filtro bloom e qualquer um dos bits estiver definido como 0, isso prova que o padr‹o n‹o foi registrado no filtro bloom. O resultado negativo n‹o Ž uma probabilidade, ele Ž uma certeza. Em termos simples, uma correspondncia negativa em um filtro bloom Ž um "Definitivamente N‹o!" Testando a existncia do padr‹o "Y" no filtro bloom. O resultado Ž uma correspondncia negativa definitiva, significando "Definitivamente N‹o!" Ž N‹o!" Ž um exemplo de um teste da existncia do padr‹o "Y" em um filtro bloom simples. Um dos bits correspondentes est‡ definido como 0, ent‹o o padr‹o definitivamente n‹o Ž uma correspondncia.
23
Figure 12. Testando Testando a existncia existncia do padr‹o "Y" "Y" no filtro bloom. bloom. O resultado resultado Ž uma correspondncia correspondncia negativa definitiva, significando "Definitivamente N‹o!"
A implementa•‹o de filtros bloom do Bitcoin Ž descrita em Bitcoin Improvement Proposal 37 (BIP0037). Veja [appdxbitcoinimpproposals] [appdxbitcoinimpproposals] ou ou acesse o GitHub GitHub..
Filtros Bloom e Atualiza•›es de Invent‡rio Filtros Bloom s‹o usados para filtrar as transa•›es (e os blocos que as contŽm) que um nodo VPS recebe de seus pontos. Os nodos VPS ir‹o criar um filtro que corresponde somente aos endere•os contidos na carteira do nodo VPS. O nodo VPS ir‡ ent‹o enviar uma mensagem filterload para o ponto, contendo o filtro bloom para ser usado na conex‹o. Ap—s um filtro ser estabelecido, o ponto ir‡ ent‹o etestar cada output da transa•‹o contra o filtro bloom. Somente as transa•›es que correspondem ao filtro ser‹o enviadas para o nodo. Em resposta a uma mensagem getdata vindo do nodo, os pontos ir‹o enviar uma mensagem merkleblock que contŽm somente os cabe•alhos de bloco para os blocos correspondentes ao filtro e um caminho merkle (ver [merkle_trees] [merkle_trees])) para cada transa•‹o correspondente. O ponto tambŽm enviar‡ mensagens tx contendo as transa•›es que correspondem ao filtro. O nodo definindo o filtro bloom pode adicionar padr›es ao filtro de maneira interativa ao enviar uma mensagem filteradd. filteradd. Para limpar o filtro bloom, o nodo pode enviar uma mensagem filterclear. Como n‹o Ž poss’vel remover um padr‹o de um filtro bloom, um nodo tem que limpar e reenviar um novo filtro bloom se um padr‹o n‹o Ž mais desejado.
24
Pools de Transa•›es Quase todo nodo na rede bitcoin mantŽm uma lista tempor‡ria de transa•›es n‹o-confirmadas chamada de pool de mem—ria, mempool ou pool de transa•›es. Os nodos usam esse pool para manter um acompanhamento das transa•›es que s‹o conhecidas pela rede mas que ainda n‹o foram inclu’das na blockchain. Por exemplo, um nodo contendo uma carteira de usu‡rio utilizar‡ um pool de transa•‹o para acompanhar os pagamentos para essa carteira que foram recebidos na rede, mas que ainda n‹o foram confirmados. As transa•›es s‹o recebidas e verificadas, sendo adicionadas ao pool de transa•›es e transmitidas aos nodos vizinhos para serem propagadas para a rede. Algumas implementa•›es de nodos tambŽm mantŽm um pool separado de transa•›es —rf‹s. Caso um input de transa•‹o referir-se a uma transa•‹o que ainda n‹o Ž conhecida, como um pai desconhecido, a transa•‹o —rf‹ ser‡ armazenada temporariamente no pool —rf‹o atŽ que a transa•‹o pai chegue. Quando uma transa•‹o Ž adicionada ao pool de transa•›es, verifica-se o pool —rf‹o para quaisquer —rf‹os que sejam referenciados para esses outputs de transa•‹o (seus filhos). Quaisquer —rf‹os correspondentes s‹o ent‹o validados. Se v‡lidos, eles s‹o removidos do pool —rf‹o e adicionados ao pool de transa•‹o, completando a cadeia que iniciou com a transa•‹o pai. Na presen•a de uma transa•‹o recŽm-adicionada, recŽm-adicionada, que n‹o Ž mais uma —rf‹, o processo Ž repetido recursivamente em busca de quaisquer outros descendentes, atŽ que n‹o se encontre mais nenhum descendente. AtravŽs desse processo, a chegada de uma transa•‹o pai desencadeia uma reconstru•‹o em cascata de uma cadeia completa de transa•›es interdependentes interdependentes ao reunir os —rf‹os com seus pais ao longo de toda a cadeia. Tanto o pool de transa•‹o quanto o pool de —rf‹s (quando implementado) s‹o armazenados na mem—ria local e n‹o s‹o salvos em um armazenamento persistente; ao invŽs disso, eles s‹o populados dinamicamente a partir das mensagens de rede que chegam. Quando um nodo Ž iniciado, ambas as pools s‹o esvaziadas e s‹o gradualmente populadas com as novas transa•›es t ransa•›es recebidas na rede. Algumas implementa•›es do cliente bitcoin tambŽm mantŽm um banco de dados de UTXO (um pool de UTXO), que Ž o conjunto de todos os outputs da blockchain que n‹o foram gastos. Embora o nome "pool de UTXO" pare•a semelhante ao pool de transa•›es, ele representa um conjunto de dados diferente. Ao contr‡rio dos pools de transa•‹o e —rf‹s, o pool UTXO n‹o Ž inicializado vazio, ao invŽs disso contŽm milh›es de entradas de outputs de transa•›es n‹o gastos, incluindo alguns antigos, que datam de 2009. O pool UTXO pode ser armazenado na mem—ria local ou como uma tabela de banco de dados indexada em um armazenamento persistente. Enquanto a transa•‹o transa•‹o e os pools —rf‹os —rf‹os representam uma perspectiva perspectiva local de um nodo nodo isolado, e podem variar significativamente de nodo para nodo dependendo de quando o nodo foi iniciado ou reiniciado, a pool de UTXO representa o consenso emergente da rede e logo ir‡ variar pouco entre os nodos. AlŽm disso, a transa•‹o e as pools —rf‹s contŽm somente transa•›es n‹o-confirmadas, enquanto a pool UTXO contŽm somente outputs confirmados.
25
Mensagens de Alerta As mensagens de alerta s‹o uma fun•‹o raramente utilizada, mas mesmo assim s‹o implementadas na maioria dos nodos. As mensagens de alerta s‹o um "sistema de alerta de emergncias" do bitcoin, um meio atravŽs do qual os desenvolvedores do bitcoin core podem enviar uma mensagem de texto de emergncia para todos os nodos bitcoin. Essa funcionalidade foi implementada para permitir que a equipe de desenvolvedores do core possa notificar todos os usu‡rios bitcoin de problemas graves na rede bitcoin, como um bug cr’tico que exija a a•‹o do usu‡rio para ser corrigido. O sistema de alerta s— foi utilizado poucas vazes, mais notavelmente no in’cio de 2013, quando um bug cr’tico de banco de dados causou uma bifurca•‹o de mœltiplos blocos na blockchain do bitcoin. As mensagens de alerta s‹o propagadas pela mensagem alert. A mensagem de alerta contŽm v‡rios campos, incluindo: ID
Um identifica•‹o do alerta, de maneira que alertas duplicados possam ser detectados Expiration Expirat ion
Uma hora a partir da qual o alerta expira RelayUntil
Uma hora ap—s a qual o alerta n‹o deve mais ser transmitido MinVer, MinV er, MaxVer MaxVer
A faixa de vers›es do protocolo bitcoin a qual esse alerta se aplica subVer
A vers‹o do software de cliente a qual esse alerta se aplica Priority
Um n’vel de prioridade para o alerta, atualmente n‹o sendo utilizado Os alertas s‹o assinados criptograficamente por uma chave pœblica. A chave privada correspondente Ž controlada por alguns membros selecionados do time de desenvolvimento do core. A assinatura digital garante que alertas falsos n‹o sejam propagados na rede. Cada nodo que receber essa mensagem de alerta ir‡ verific‡-la, checar pela expira•‹o e propag‡-la para todos os seus pontos, dessa maneira garantindo garantindo a r‡pida propaga•‹o atravŽs de toda a rede. AlŽm de propagar o alerta, os nodos podem implementar uma fun•‹o de interface de usu‡rio para apresentar o alerta para o usu‡rio. No cliente Bitcoin Core, o alerta Ž configurado com a op•‹o da linha de comando -alertnotify, que especifica um comando para ser executado quando um alerta for recebido. A mensagem de alerta Ž passada como um par‰metro para o comando alertnotify. Mais comumente, o comando alertnotify Ž definido para gerar gerar uma mensagem de e-mail para o administrador do nodo, contendo a mensagem de
26
alerta. O alerta tambŽm Ž exibido como uma caixa de di‡logo pop-up na interface gr‡fica do usu‡rio (bitcoin-Qt), caso ela esteja sendo executada. Outras implementa•›es do protocolo bitcoin podem manejar o alerta em maneiras diferentes. Muitos sistemas de minera•‹o de bitcoin que usam hardware n‹o implementam a fun•‹o de mensagem de alerta porque eles n‹o tem uma interface de usu‡rio. ƒ fortemente recomendado que os mineradores que executem esses sistemas de minera•‹o inscrevam-se nesses alertas atravŽs de um operador de pool de minera•› ou ao executar um nodo de peso leve (lightweight) apenas com o prop—sito de ter a fun•‹o do alerta.
27
A Blockchain Introdu•‹o A estrutura de dados da blockchain Ž uma lista ordenada de blocos de transa•›es, com cada bloco sendo ligado ao bloco anterior. A blockchain pode ser armazenada como um arquivo simples ou em um banco de dados simples. O cliente Bitcoin Core armazena os metadados da blockchain usando o banco de dados do LevelDB do Google. Os blocos s‹o interligados de frente para tr‡s, ou seja, cada um se refere ao bloco anterior na corrente. A blockchain Ž frequentemente visualizada como um empilhamento empilhamen to vertical, com os blocos empilhados uns sobre os outros e com o primeiro bloco servindo como funda•‹o que suporta a pilha. A visualiza•‹o dos blocos empilhados uns sobre os outros resulta no uso de termos como "altura" para se referir ˆ dist‰ncia em rela•‹o ao primeiro bloco, e "topo" ou "ponta" para se referir ao bloco adicionado mais recentemente. Cada bloco contido na blockchain Ž identificado no cabe•alho do bloco por um hash, que Ž gerado utilizando-se o algoritmo criptogr‡fico de hash SHA256. Cada bloco tambŽm contŽm uma referncia ao bloco anterior, conhecido como o bloco pai bloco pai,, atravŽs do campo "hash do bloco anterior (previous block hash)" que existe no cabe•alho do bloco. Em outras palavras, cada bloco contŽm o hash de seu blocopai no interior de seu pr—prio cabe•alho. A sequncia de hashes ligando cada bloco ao seus pai cria uma corrente que pode ser seguida retrogradamente atŽ o primeiro bloco que j‡ foi criado, que Ž conhecido como o bloco gnese. gnese. Embora um bloco tenha apenas um bloco "pai", ele pode temporariamente ter mœltiplos blocos "filhos". Cada um dos blocos "filhos" refere-se ao mesmo bloco "pai" e contŽm o mesmo hash (o hash do bloco "pai") no campo "hash do bloco anterior". Mœltiplos blocos filhos surgem quando h‡ uma "bifurca•‹o" da blockchain, uma situa•‹o tempor‡ria que ocorre quando diferentes blocos s‹o descobertos quase que simultaneamente por diferentes mineradores (veja [forks] [forks]). ). No final, somente um bloco filho se tornar‡ parte da blockchain e a "bifurca•‹o" deixar‡ de existir. Apesar de cada bloco poder ter mais que um filho, cada bloco pode ter somente um pai. Isso ocorre porque um bloco possui apenas um œnico campo de "hash do bloco anterior", que Ž uma referncia ao seu bloco pai œnico. O campo "hash do bloco anterior" est‡ dentro do cabe•alho do bloco e portanto afeta o hash do bloco atual.. A identidade de um filho muda se a identidade de seu pai mudar. Quando o pai Ž modificado de atual qualquer maneira, o hash do pai muda. O hash modificado do pai exige uma mudan•a no apontador "hash do bloco anterior" do filho. Isso por sua vez faz com que o hash do filho mude, o que requer uma mudan•a no apontador do neto, o que por sua vez muda o (hash do) neto, e assim por diante. Esse efeito domin— garante que, assim que um bloco tenha muitas gera•›es o sucedendo, ele n‹o pode ser modificado sem que haja um novo c‡lculo for•ado de todos os blocos subsequentes. Como um novo c‡lculo exigiria um processamento computacional enorme, a existncia de uma longa corrente de blocos faz com que a hist—ria profunda da blockchain seja imut‡vel, o que Ž uma caracter’stica chave para a seguran•a do bitcoin. Uma maneira de imaginar a blockchain seria como um solo, onde os blocos seriam camadas de uma forma•‹o geol—gica, ou como uma amostra do nœcleo de uma geleira. As camadas da superf’cie podem
1
mudar com as esta•›es, ou mesmo serem destru’das antes de terem tempo para se assentarem. Mas quanto mais profundo escavarmos, veremos que maior ser‡ a estabilidade das camadas geol—gicas. Quando voc escavar algumas centenas de metros de profundidade, voc estar‡ olhando para uma fotografia do passado que permaneceu intocada por milh›es de anos. Na blockchain, pode acontecer de os poucos blocos mais recentes tenham que ser revisados/corrigidos, caso haja um novo c‡lculo da corrente devido a uma bifurca•‹o. Os seis blocos do topo s‹o como os cent’metros mais superficiais do solo. Mas quanto mais fundo voc penetrar na blockchain, alŽm dos seis blocos, se cada vez menor se torna a probabilidade desses blocos se modificarem. Ap—s 100 blocos de profundidade h‡ tanta estabilidade que a transa•‹o coinbase - a transa•‹o contendo os bitcoins recŽm-minerados - pode ser gasta. Alguns milhares de blocos atr‡s (um ms) e a blockchain Ž uma hist—ria estabelecida, para todos os fins pr‡ticos. Apesar de o protocolo sempre permitir que uma corrente seja desfeita por uma corrente mais comprida, e apesar de sempre existir a possibilidade de qualquer bloco ser revertido, a probabilidade de ocorrncia de um evento como esse diminui ˆ medida que o tempo passo, atŽ que ela se torne ’nfima.
Estrutura de um Bloco Um bloco Ž uma estrutura contendo dados que agrega as transa•›es para a inclus‹o no registro pœblico, a blockchain. O bloco Ž composto por um cabe•alho, contendo metadados, e por uma longa lista de transa•›es que constituem a maior parte de seu tamanho. O cabe•alho do bloco tem 80 bytes, enquanto uma transa•‹o em mŽdia tem pelo menos 250 bytes e um bloco em mŽdia contŽm mais de 500 transa•›es. Um bloco completo, com todas as transa•›es, consequentemente Ž 1.000 vezes maior do que o cabe•alho do bloco. A estrutura de um bloco descreve bloco descreve a estrutura de um bloco. Table 1. A estrutura de um bloco
Tamanho
Campo
Descri•‹o
4 bytes
Tamanho do Bloco
O tamanho do bloco, em bytes, ap—s esse campo
80 bytes
Cabe•alho do Bloco
V‡rios campos formam o cabe•alho do bloco
1-9 bytes (VarInt)
Contador de Transa•›es
Quantas transa•›es seguem
Vari‡vel
Transa•›es
As transa•›es registradas nesse bloco
Cabe•alho (header) do Bloco O cabe•alho do bloco consiste de trs conjuntos de metadados de bloco. Primeiro, existe uma referncia ao hash do bloco anterior, que conecta esse bloco ao bloco anterior na blockchain. O segundo conjunto de metadados, a dificuldade dificuldade,, a data e hora (timestamp) e (timestamp) e o nonce nonce,, est‡ relacionado ˆ competi•‹o da minera•‹o, como ser‹o detalhados no [ch8] [ch8].. A terceira parte dos metadados Ž a raiz da ‡rvore de merkle, uma estrutura de dados usada para resumir de maneira eficiente todas as transa•›es contidas no bloco. A estrutura do cabe•alho do bloco descreve bloco descreve a estrutura de um cabe•alho
2
de bloco. Table 2. A estrutura do cabe•alho do bloco
Tamanho
Campo
Descri•‹o
4 bytes
Vers‹o
Um nœmero de vers‹o para servir como referncia nas atualiza•›es de software/protocolo.
32 bytes
Hash do Bloco Anterior
Uma referncia ao hash do bloco anterior (bloco pai) na blockchain
32 bytes
Raiz de Merkle
Um hash da raiz da ‡rvore de merkle das transa•›es desse bloco
4 bytes
Data e Hora (timestamp)
O momento aproximado em que este bloco foi criado (em segundos, usando Unix Epoch)
4 bytes
Dificuldade Alvo
O alvo de dificuldade do algoritmo de prova-de-tra prova-de-trabalho balho deste bloco
4 bytes
Nonce
Um contador usado para o algoritmo de prova-de-tra prova-de-trabalho balho
O nonce, a dificuldade alvo e a data e hora (timestamp) s‹o usados no processo de minera•‹o e ser‹o discutidos em maiores detalhes no [ch8] [ch8]..
Identificadores dos Blocos: Hash do Cabe•alho do Bloco e Altura do Bloco O identificador prim‡rio de um bloco Ž o seu hash criptogr‡fico, uma impress‹o digital eletr™nica que Ž criada ao se fazer um duplo hashing do cabe•alho do bloco atravŽs do algoritmo SHA256. O hash resultante de 32-bytes Ž chamado de hash do bloco, bloco, mas Ž mais precisamente o hash do cabe•alho do bloco,, porque apenas o cabe•alho do bloco Ž usado para comput‡-lo. Por exemplo, bloco 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f Ž o hash do bloco do primeiro bloco bitcoin que j‡ foi criado. O hash do bloco identifica o bloco de maneira œnica e sem ambiguidades, e pode ser independentemente derivado por qualquer nodo que fizer um hashing do cabe•alho do bloco. Note que o hash do bloco n‹o est‡ inclu’do no interior da estrutura de dados do bloco, nem quando o bloco Ž transmitido na rede, nem quando ele Ž armazenado em um armazenamento persistente de um nodo como parte da blockchain. Ao invŽs disso, o hash do bloco Ž processado por cada nodo assim que o bloco Ž recebido vindo da rede. O hash do bloco pode ser armazenado em uma tabela de banco de
3
dados separada como parte dos metadados do bloco, para facilitar a indexa•‹o e uma coleta mais r‡pida de blocos a partir do disco. Uma segunda maneira de se identificar um bloco Ž atravŽs de sua posi•‹o na blockchain, que Ž chamada de altura do bloco. O primeiro bloco criado est‡ na altura de bloco 0 (zero) e Ž o mesmo bloco que foi referncia anteriomente ao seguinte hash de bloco 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. Logo, um bloco pode ser identificado de duas maneiras: usando as referncias do hash do bloco ou da altura do bloco. Cada bloco que Ž adicionado a seguir "em cima" daquele bloco inicial est‡ uma posi•‹o "mais alta" na blockchain, como se fossem caixas empilhadas uma sobre as outras. A altura do bloco em 1¼ de Janeiro de 2014 era aproximadamente 278.000, significando que havia 278.000 blocos empilhados sobre o primeiro bloco que foi criado em Janeiro de 2009. Ao contr‡rio do hash do bloco, a altura do bloco n‹o Ž um identificador œnico. EMbora um bloco individual sempre ter‡ uma altura de bloco espec’fica e fixa, o inverso nem sempre Ž verdade - a altura do bloco nem sempre identifica um bloco individual. Dois ou mais blocos podem ter a mesma altura de bloco, competindo pela mesma posi•‹o na blockchain. Esse cen‡rio Ž discutido em detalhes na se•‹o [forks].. A altura do bloco tambŽm n‹o faz parte da estrutura de dados do bloco; ela n‹o Ž armazenada [forks] no interior do bloco. Cada nodo identifica dinamicamente uma posi•‹o do bloco (altura) na blockchain quando ele Ž recebido da rede bitcoin. A altura do bloco pode tambŽm ser armazenada como metadados em uma tabela de banco de dados indexada para uma leitura mais r‡pida.
TIP
Um hash do bloco bloco de um determinado bloco sempre identifica um bloco œnico individualmente. Um bloco tambŽm sempre tem uma altura do bloco bloco espec’fica. Entretanto, nem sempre uma altura de bloco espec’fica pode identificar um bloco œnico. Na verdade, dois ou mais blocos podem competir por uma posi•‹o œnica na blockchain.
O Bloco Gnese O primeiro bloco na blockchain Ž chamado de bloco gnese e foi criado em 2009. Ele Ž o ancestral comum de todos os blocos na blockchain, significando significando que se voc iniciar em qualquer bloco e seguir a cadeia retrogradamente retrogradamente no tempo, voc ir‡ atigir o bloco gnese no final. Cada nodo sempre come•a com uma blockchain de pelo menos um bloco porque o bloco gnese est‡ estaticamente codificado no interior do software do cliente bitcoin, de maneira que ele n‹o pode ser alterado. Cada nodo sempre "conhece" o hash do bloco gnese e sua estruura, o tempo exato em que ele foi criado e atŽ mesmo a transa•‹o œnica que ele contŽm. Logo, cada nodo possui o ponto inicial da blockchain, uma "raiz" "raiz" segura a partir da qual ele pode construir uma blockchain de confian•a. Veja o bloco gnese codificado estaticamente no interior do cliente Bitcoin Core, em chainparams.cpp chainparams.cpp.. O seguinte hash identificador pertence ao bloco gnese:
000000000019d6689c085ae16 000000000019 d6689c085ae165831e934ff763 5831e934ff763ae46a2a6c172b ae46a2a6c172b3f1b60a8ce26f 3f1b60a8ce26f
4
Voc pode procurar por esse hash do bloco em qualquer site explorador de blocos, como o blockchain.info, e voc ir‡ encontrar uma p‡gina que descrever‡ o conteœdo desse bloco, com uma URL contendo o hash: https://blockchain.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f https://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce 26f Usando o cliente de referncia Bitcoin Core na linha de comando:
$ bitcoind getblock 000000000019 000000000019d6689c085ae1 d6689c085ae165831e934ff76 65831e934ff763ae46a2a6c172 3ae46a2a6c172b3f1b60a8ce26 b3f1b60a8ce26ff
{
"hash" : "00000000001 "000000000019d6689c085ae1 9d6689c085ae165831e934ff76 65831e934ff763ae46a2a6c172 3ae46a2a6c172b3f1b60a8ce2 b3f1b60a8ce26f", 6f", "confirmations" "confirmation s" : 308321, "size" : 285, "height" : 0, "version" : 1, "merkleroot" : "4a5e1e4baab8 "4a5e1e4baab89f3a32518a88 9f3a32518a88c31bc87f618f7 c31bc87f618f76673e2cc77ab2 6673e2cc77ab2127b7afdeda33 127b7afdeda33b", b", "tx" : [ "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b" ], "time" : 1231006505, "nonce" : 2083236893, "bits" : "1d00ffff", "difficulty" : 1.00000000, "nextblockhash" "nextblockhas h" : "00000000839 "00000000839a8e6886ab595 a8e6886ab5951d76f41147542 1d76f411475428afc90947ee32 8afc90947ee320161bbf18eb60 0161bbf18eb6048" 48"
} O bloco gnese contŽm uma mensagem escondida em seu interior. O input da transa•‹o coinbase contŽm o texto "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.", que poderia ser traduzida como "The Times 03/Jan/2009 Chanceler est‡ prestes a realizar um segundo resgate dos bancos." Essa mensagem tinha a inten•‹o de oferecer prova da data mais precoce em que esse bloco foi criado, ao usar como referncia a manchete de um jornal Brit‰nico, o The Times. Times. Ela tambŽm serve como um lembrete da import‰ncia de um sistema monet‡rio independente, com o lan•amento do bitcoin ocorrendo ao mesmo tempo em que ocorria uma crise monet‡ria internacional sem precedentes. A mensagem foi embutida no primeiro bloco por Satoshi Nakamoto, o criador do bitcoin.
Conectando os Blocos na Blockchain Os nodos bitcoin completos mantŽm uma c—pia local da blockchain, iniciando pelo bloco gnese. A c—pia local da blockchain Ž constantemente atualizada ˆ medida que novos blocos s‹o encontrados e s‹o usados para estender a corrente. Assim que um nodo recebe os blocos vindo da rede, ele ir‡ validar
5
esses blocos e ent‹o lig‡-los ˆ blockchain existente. Para estabelecer essa liga•‹o, o nodo ir‡ examinar o cabe•alho do bloco vindo da rede e procurar pelo "hash do bloco anterior". Vamos assumir, por exemplo, que o nodo tem 277.314 blocos na c—pia local da blockchain. O œltimo bloco que o nodo conhece Ž o bloco 277.314, com um cabe•alho do bloco contendo o hash 00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249. O nodo bitcoin ent‹o recebe um novo bloco da rede, que ent‹o o analisa da seguinte maneira:
{
"size" : 43560, "version" : 2, "previousblockhash" "previousbloc khash" : "00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249", "merkleroot" : "5e049f4030e0ab2debb92378f53c0a6e09548aea083f3ab25e1d94ea1155e29d", "time" : 1388185038, "difficulty" : 1180923195.25 1180923195.25802612, 802612, "nonce" : 4215469401, "tx" : [ "257e7497fb8bc68421eb2c7b699dbab234831600e7352f0d9e6522c7cf3f6c77",
#[... muitas outras transa •›es omitidas ...]
"05cfd38f6ae6aa83674cc99e4d75a1458c165b7ab84725eda41d018a09176634" ]
} Olhando para esse novo bloco, o nodo encontra o campo previousblockhash, que contŽm o hash de seu bloco pai. Ele Ž um hash conhecido ao nodo, aquele do œltimo bloco na corrente, que est‡ na altura 277.314. Logo, esse novo bloco Ž um bloco filho do œltimo bloco na corrente e estende a blockchain existente. O nodo adiciona esse novo bloco ao fim da corrente, aumentando o comprimento da blockchain, que agora tem uma nova altura de 277.315. Blocos ligados em uma cadeia, pela referncia ao hash do cabe•alho do bloco anterior anterior mostra a corrente de trs blocos, ligados atravŽs das referncias contidas no campo previousblockhash. previousblockhash.
çrvores de Merkle Cada bloco na blockchain do bitcoin contŽm um resumo de todas as transa•›es no bloco, usando uma ‡rvore de merkle. merkle. Uma ‡rvore de merkle, merkle, tambŽm conhecida como uma ‡rvore de hash bin‡rio, Ž uma estrutura de dados usadas para resumir eficientemente e verificar a integridade da grandes conjuntos de dados. As ‡rvores de merkle s‹o ‡rvores bin‡rias contendo hashes criptogr‡ficos. O termo "‡rvore" Ž usado na cincia da computa•‹o para descrever uma estrutura de dados ramificada, mas essas ‡rvores
6
geralmente s‹o exibidas de cabe•a para baixo com a "raiz" no topo e com as "folhas" na por•‹o inferior de um diagrama, como voc ver‡ nos exemplos a seguir.
7
8
Figure 1. Blocos Blocos ligados em uma cadeia, cadeia, pela referncia ao hash hash do cabe•alho do bloco anterior As ‡rvores de Merkle s‹o usadas no bitcoin para resumir todas as transa•›es em um bloco, produzindo uma impress‹o digital eletr™nica geral de todo o conjunto de transa•›es, fornecendo um processo muito efeiciente para verificar se uma transa•‹o foi inclu’da em um bloco. Uma ‡rvore de Merkle Ž constru’da atravŽs do hashing recursivo de pares de nodos atŽ que haja apenas um hash, conhecido como a raiz ou raiz de merkle. merkle. O algoritmo de hash criptogr‡fico usado nas ‡rvores de merkle do bitcoin Ž o SHA256 aplicado duas vezes, tambŽm conhecido como SHA256-duplo. SHA256-duplo. Quando N elementos de dados sofrem hashing e s‹o resumidos em uma ‡rvore merkle, voc pode verificar para ver se qualquer elemento de dados foi inclu’do na ‡rvore com no m‡ximo 2*log~2~(N) c‡lculos, o que demonstra que a ‡rvore merkle Ž uma estrutura de dados muito eficiente. A ‡rvore de merkle Ž constru’da de baixo para cima. No exemplo a seguir, n—s iniciamos com quatro transa•›es, A, B, C e D, que formam as folhas folhas da da ‡rvore de Merkle, como demonstrado em Calculando os nodos em uma ‡rvore de merkle. merkle . As transa•›es n‹o s‹o armazenadas na ‡rvore de merkle; ao invŽs disso, seus dados s‹o "hashed" e o hash resultante Ž armazenado em cada nodo folha como H A, HB, HC e HD:
H~A~ = SHA256(SHA25 SHA256(SHA256(Transa 6(Transa •‹o A)) Os pares consecutivos de nodos folhas s‹o ent‹o resumidos em um nodo pai, ao se concatenar dois hashes e fazendo um hashing dos dois juntos. Por exemplo, para construir um nodo pai HAB, os dois hashes de 32-bytes dos filhos s‹o concatenados para criar uma string de 64-bytes. Essa string sofre ent‹o um duplo hashing para produzir o hash do nodo pai:
H~AB~ = SHA256(SHA256(H~A~ + H~B~)) O processo continua atŽ que haja apenas um nodo no topo, o nodo conhecideo como a raiz Merkle. Esse hash de 32-bytes Ž armazenado no cabe•alho do bloco e resume todos os dados em todas as quatro transa•›es.
9
Figure 2. Calculando Calculando os nodos em uma uma ‡rvore de merkle merkle Como a ‡rvore de merkle Ž uma ‡rvore bin‡ria, ela precisa de um nœmero par de nodos folha. Se existir um nœmero ’mpar de transa•›es para ser resumido, o hash da œltima transa•‹o ser‡ duplicado para criar uma ‡rvore equilibr equilibrada ada,, ou seja, uma ‡rvore que contŽm um nœmero par de nodos folhas. Isso Ž demonstrado em A duplica•‹o de um elemento de dados gera um nœmero par de elementos de dados,, onde a transa•‹o C Ž duplicada. dados
Figure 3. A duplica•‹o duplica•‹o de um elemento de dados gera um nœmero nœmero par de elementos elementos de dados O mesmo mŽtodo para construir uma ‡rvore a partir de quatro transa•›es pode ser generalizado para construir ‡rvores de qualquer tamanho. No bitcoin Ž comum que haja v‡rias centenas a mais de
10
milhares de transa•›es em um œnico bloco, que podem ser resumidas exatamente da mesma maneira, ao produzir apenas 32 bytes de dados como uma ‡rvore de merkle œnica. Em Uma ‡rvore de merkle resumindo muitos elementos de dados, dados, voc ver‡ uma ‡rvore constru’da a partir de 16 transa•›es. Note que embora a raiz aparente ser maior do que os nodos-folha no diagrama, ela tem exatamente o mesmo tamanho, apenas 32 bytes. Independente de um bloco ter apenas uma ou centenas de milhares de transa•›es, a raiz de merkle sempre as resume em 32 bytes. Para provar que uma transa•‹o espec’fica est‡ inclu’da em um bloco, um nodo precisa apenas produzir log~2~(N) hashes de 32 bytes, constituindo um caminho de autentica•‹o ou caminho merkle conectando a transa•‹o espec’fica ˆ raiz da ‡rvore. Isso Ž especialmente importante ˆ medida que o nœmero de transa•›es cresce, porque o logaritmo de base 2 do nœmero de transa•›es aumenta muito mais lentamente. Isso permite que os nodos de bitcoin produzam de maneira eficiente caminhos de 10 ou 12 hashes (320-384 bytes), que podem fornecer uma prova de uma transa•‹o individual em um meio de milhares de transa•›es contidas em um bloco com tamanho de megabytes.
Figure 4. Uma ‡rvore ‡rvore de merkle resumindo resumindo muitos elementos elementos de dados Em Um trajeto de merkle usado para provar a inclus‹o de um elemento de dados, dados , um nodo pode provar que uma transa•‹o K Ž inclu’da em um bloco ao produzir um caminho merkle que tenha apenas quatro hashes de 32-bytes (128 bytes no total). O caminho consiste em quatro hashes (identificados em azul em Um trajeto de merkle usado para provar a inclus‹o de um elemento de dados)) HL, HIJ, HMNOP e HABCDEFGH. Com esses quatro dados quatro hashes hashes fornecidos fornecidos como um um caminho caminho de autentica•‹o, qualquer qualquer nodo nodo pode provar provar que HK (identificado em verde no diagrama) est‡ incluso na raiz de merkle ao computar quatro hashes pair-wise H KL, HIJKL, HIJKLMNOP, e a raiz da ‡rvore de merkle (contornada com uma linha pontilhada no diagram diagrama). a).
11
Figure 5. Um trajeto trajeto de merkle usado para para provar a inclus‹o inclus‹o de um elemento elemento de dados O c—digo em Construindo uma ‡rvore de Merkle demonstra Merkle demonstra o processo de cria•‹o de uma ‡rvore de merkle desde os hashes dos nodos folha atŽ a raiz, usando a livraria libbitcoin para algumas fun•›es auxiliares. Example 1. Construindo Construindo uma uma ‡rvore de Merkle
#include oin.hpp> bc::hash_digest create_merkl bc::hash_digest create_merkle(bc::hash_li e(bc::hash_list& st& merkle) { // Stop if hash list is empty. if (merkle.empty (merkle.empty()) ()) return bc::null_hash bc::null_hash;; else if (merkle.size (merkle.size() () == 1) return merkle[0];
// While there is more than 1 hash in the list, keep looping... while (merkle.siz (merkle.size() e() > 1) { // If number of hashes is odd, duplicate last hash in the list. if (merkle.size( (merkle.size()) % 2 != 0) merkle.push_back(merkle.back()); // List size is now even. assert(merkle.size() assert(merk le.size() % 2 == 0); // New hash list. bc::hash_listt new_merkle; bc::hash_lis // Loop through hashes 2 at a time. for (auto it = merkle.begin merkle.begin(); (); it != merkle.end(); it += 2) { // Join both current hashes together (concatenat (concatenate). e).
12
bc::data_chunk concat_data( bc::data_chunk concat_data(bc::hash_size bc::hash_size * 2); auto concat = bc::make_seri bc::make_serializer(concat alizer(concat_data.begin( _data.begin()); )); concat.write_hash(*it); concat.write_hash(*(it concat.write _hash(*(it + 1)); assert(concat.iterator() assert(conca t.iterator() == concat_data. concat_data.end()); end()); // Hash both of the hashes. bc::hash_digest bc::hash_dig est new_root = bc::bitcoin_h bc::bitcoin_hash(concat_d ash(concat_data); ata); // Add this to the new list. new_merkle.push_back(new_root); } // This is the new list. merkle = new_merkle; // DEBUG output ----------------------------------------------------------------------std::cout << "Current merkle hash list:" << std::endl; for (const auto& hash: merkle) std::cout << " " << bc::encode_h bc::encode_hex(hash) ex(hash) << std::endl; std::cout << std::endl; // -----------------------------------------------------------------------------------------------} // Finally we end up with a single item. return merkle[0];
} int main() { // Replace these hashes with ones from a block to reproduce the same merkle root. bc::hash_list bc::hash_li st tx_hashes{{ bc::hash_literal("00000000 bc::hash_lite ral("000000000000000000000 00000000000000000000000000 0000000000000000000000000 0000000000000000000000000 000000000000000000"), 00000"), bc::hash_literal("00000000 bc::hash_lite ral("000000000000000000000 00000000000000000000000000 0000000000000000000000000 0000000000000000000000000 000000000000000011"), 00011"), bc::hash_literal("000000000000000000000 bc::hash_literal("00000000 00000000000000000000000000 0000000000000000000000000 0000000000000000000000000 000000000000000022"), 00022"), }}; const bc::hash_dig bc::hash_digest est merkle_root = create_merkl create_merkle(tx_hashes) e(tx_hashes);; std::cout << "Result: " << bc::encode_h bc::encode_hex(merkle_roo ex(merkle_root) t) << std::endl; return 0; }
Compilando e executando o c—digo de exemplo merkle mostra merkle mostra o resultado da compila•‹o e execu•‹o do c—digo de merkle
13
Example 2. Compilando Compilando e executando executando o c—digo de exemplo exemplo merkle
$ # Compilar o c —digo merkle.cpp $ g++ -o merkle merkle.cpp $(pkg-config --cflags --libs libbitcoin) $ # Rodar o execut ‡vel merkle $ ./merkle Hash list de merkle atual: 32650049a0418e4380db0af81788635d8b65424d397170b8499cdc28c4d27006 30861db96905c8dc8b99398ca1cd5bd5b84ac3264a4e1b3e65afa1bcee7540c4 Hash list de merkle atual: d47780c084bad3830bcdaf6eace035e4c6cbf646d103795d22104fb105014ba3 Resultado: d47780c084bad d47780c084bad3830bcdaf6eac 3830bcdaf6eace035e4c6cbf64 e035e4c6cbf646d103795d221 6d103795d22104fb105014ba3 04fb105014ba3
A eficincia da ‡rvore de merkle se torna —bvia na medida que ela cresce em escala. Eficincia da ‡rvore de Merkle mostra Merkle mostra a quantidade de dados que precisa ser trocada como um caminho de merkle para provar que uma transa•‹o faz parte de um bloco. Table 3. Eficincia da ‡rvore de Merkle
Nœmero Nœm ero de trans transa•› a•›es es Taman Tamanho ho apro aprox. x. do bloco
Tamanho do caminho (hashes)
Tamanho do caminho (bytes)
16 transa•›es
4 kilobytes
4 hashes
128 bytes
512 transa•›es
128 kilobytes
9 hashes
288 bytes
2.048 transa•›es
512 kilobytes
11 hashes
352 bytes
65.535 transa•›es
16 megabytes
16 hashes
512 bytes
Como voc pode ver na tabela, enquanto o tamanho do bloco aumenta rapidamente, de 4 KB com 16 transa•›es atŽ um tamanho de bloco de 16 MB, para comportar 65.535 transa•›es, o caminho merkle necess‡rio para provar a inclus‹o de uma transa•‹o cresce muito mais lentamente, de 128 bytes para somente 512 bytes. Com ‡rvores merkle, um nodo pode fazer apenas o download dos cabe•alhos dos blocos (80 bytes por bloco) e ainda ser capaz de identificar a inclus‹o de uma transa•‹o em um bloco ao adquirir um pequeno caminho merkle a partir de um nodo completo, sem armazenar ou transmitir a vasta maioria da blockchain, que pode ter v‡rios gigabytes de tamanho. Os nodos que n‹o mantŽm uma blockchain completa, chamados de nodos de verifica•‹o simplificada de pagamento (nodos VSP), usam caminhos merkle para verificar as transa•›es sem ter que fazer o download dos blocos completos.
14
çrvores de Merkle e Verifica•‹o Simplificada de Pagamento (VSP) As ‡rvores de Merkle s‹o muito usadas por nodos VSP. Os nodos VSP n‹o tem todas as transa•›es e n‹o fazem o download de todos os blocos, fazem apenas dos cabe•alhos dos blocos. Para verificar que uma transa•‹o foi inclu’da em um bloco, sem ter que fazer download de todas as transa•›es no bloco, eles usam um caminho de autentica•‹o, ou um caminho merkle. Considere, por exemplo, que um nodo de VSP esteja interessado em receber pagamentos para um endere•o contido em sua carteira. O nodo VSP ir‡ estabelecer um filtro bloom em suas conex›es aos pontos para limitar as transa•›es para somente aquelas que contenham os endere•os de interesse. Quando um ponto v uma transa•‹o que corresponde ao filtro bloom, ele ir‡ enviar para aquele bloco uma mensagem merkleblock. A mensagem merkleblock contŽm o cabe•alho do bloco assim como o caminho merkle que liga a transa•‹o de interesse ˆ raiz merkle no bloco. O nodo VSP pode usar esse caminho merkle para conectar a transa•‹o ao bloco e verificar que a transa•‹o foi inclu’da no bloco. O nodo VSP tambŽm usa o cabe•alho do bloco para ligar o bloco ao resto da blockchain. A combina•‹o dessas duas liga•›es, entre a transa•‹o e o bloco, e entre o bloco e a blockchain, prova que a transa•‹o foi registrada na blockchain. No final das contes, o nodo VSP ter‡ recebido menos que um kilobyte de dados que Ž mais do que mil vezes menos do que um bloco completo (cerca de 1 megabyte atualmente).
15
Minera•‹o e Consenso Introdu•‹o Minera•‹o Ž o processo atravŽs do qual um novo bitcoin Ž adicionado ˆ oferta de dinheiro. A minera•‹o tambŽm serve para proteger o sistema bitcoin contra transa•›es fraudulentas ou transa•›es gastando a mesma quantia de bitcoin mais de uma vez, o que Ž conhecido como gasto duplo. Os mineradores fornecem poder de processamento ˆ rede bitcoin em troca da oportunidade de serem recompensados em bitcoin. Mineradores validam novas transa•›es e as gravam no Livro Raz‹o global. Um novo bloco, contendo transa•›es que ocorreram desde o œltimo bloco Ž "minerado" em mŽdia a cada 10 minutos, assim adicionando estas transa•›es a Cadeia de Blocos. Transa•›es que se tornam parte de um bloco e s‹o adicionadas a Cadeia de Blocos s‹o consideradas "confirmadas", o que permite os novos propriet‡rios de bitcoin a gastarem os bitcoins recentemente recebidos nestas transa•›es. Mineradores recebem dois tipos de recompensa pela minera•‹o: novas moedas criadas a cada novo bloco, e taxas de transa•‹o em todas as as transa•›es inclu’das no bloco. Para Para ganhar essa recompensa, os mineradores competem entre si para resolver um complexo problema matem‡tico baseado em um algoritmo de hash criptogr‡fico. A solu•‹o para o problema, chamada de proof-of-work (prova de trabalho), Ž inclu’da no novo bloco e serve como prova de que o minerador gastou uma significativa quantidade de esfor•o computacional. A competi•‹o para resolver o algoritmo de proof-of-work a fim de obter as recompensas e o direito de registrar transa•›es no blockchain Ž a base do modelo de seguran•a da rede bitcoin. O processo de gera•‹o de novas moedas Ž chamado de minera•‹o porque a recompensa Ž projetada para simular retornos cada vez menores, da mesma maneira que a minera•‹o de metais preciosos. A oferta monet‡ria do bitcoin Ž criada atravŽs da minera•‹o, semelhante ˆ maneira como um banco central emite emite dinheiro atravŽs da impress‹o impress‹o de cŽdulas (notas de dinheiro). dinheiro). A quantia de bitcoin recŽm-criado que um minerador pode acrescentar em cada bloco diminui a cada 4 anos em mŽdia (ou precisamente a cada 210.000 blocos). No in’cio do bitcoin, em janeiro de 2009, 50 bitcoins eram gerados a cada bloco, e esse nœmero caiu pela metade (25 bitcoins por bloco) em novembro de 2012. Ele ir‡ cair pela metade (12,5 bitcoins por bloco) no ano 2016. Como Ž baseada nessa f—rmula, a remunera•‹o da minera•‹o do bitcoin diminuir‡ exponencialmente atŽ aproximadamente o ano de 2140, quando todos os bitcoins (20,99999998 milh›es) ter‹o sido emitidos. Ap—s 2140, mais nenhum bitcoin ser‡ criado. Os mineradores de bitcoin tambŽm ganham taxas das transa•›es. Cada transa•‹o pode incluir uma taxa de transa•‹o, na forma de um excedente de bitcoins entre as entradas (inputs) e sa’das (outputs) da transa•‹o. O minerador de bitcoin que vencer ir‡ receber as taxas das transa•›es que est‹o inclu’das no bloco que ele minerou. Atualmente, as taxas representam 0,5% ou menos da renda de um minerador de bitcoin, ou seja, a maior parte da renda vem dos bitcoins recŽm-minerados. No entanto, ˆ medida que a recompensa diminui ao longo do tempo e o nœmero de transa•›es por bloco aumenta, uma propor•‹o maior da renda dos mineradores vir‡ das taxas das transa•›es. Ap—s 2140, tudo o que os mineradores ir‹o ganhar vir‡ na forma de taxas de transa•›es.
1
A palavra "minera•‹o" pode causar confus‹o. Pela analogia com a extra•‹o se metais preciosos, ela foca nossa aten•‹o na recompensa pela minera•‹o, ou seja, os novos bitcoins gerados em cada bloco. Embora a minera•‹o seja incentivada por essa recompensa, a proposta prim‡ria da minera•‹o n‹o Ž a recompensa ou a gera•‹o de novas moedas. Se voc ver minera•‹o somente como o processo atravŽs do qual as moedas s‹o criadas, voc est‡ confundindo os meios (incentivos) como um objetivo do processo. Minera•‹o Ž o processo principal da c‰mara de compensa•‹o descentralizada, atravŽs do qual as transa•›es s‹o apuradas e validadas. A minera•‹o garante a seguran•a do sistema bitcoin e permite a existncia de um consenso em toda a rede sem a necessidade de uma autoridade central. Minera•‹o Ž a inven•‹o que torna o bitcoin especial, Ž um mecanismo de seguran•a descentralizado que Ž a base para o dinheiro digital ponto-a-ponto. A recompensa por moedas recŽm-mineradas e as taxas de transa•›es s‹o um esquema de incentivo que alinha as a•›es dos mineradores com a seguran•a da rede, enquanto simultaneamente implementa a oferta monet‡ria. Nesse cap’tulo, n—s iremos primeiramente examinar a minera•‹o como um mecanismo de oferta monet‡ria e ent‹o olharemos para a mais importante fun•‹o da minera•‹o: o mecanismo de consenso emergergente descentralizado descentralizado subjacente da seguran•a do bitcoin.
A Economia do Bitcoin e a Cria•‹o de Moedas Os bitcoins s‹o minerados durante a cria•‹o de cada bloco em uma taxa fixa e que s— diminui. Cada bloco, gerado a cada 10 minutos em mŽdia, contŽm bitcoins completamente novos, que foram criados do nada. A cada 210.000 blocos, ou aproximadamente a cada 4 anos, a taxa de emiss‹o da moeda Ž diminu’da em 50%. Nos primeiros 4 anos de opera•‹o da rede, cada bloco continha 50 bitcoins novos. Em novembro de 2012, a taxa de emiss‹o de bitcoins foi diminu’da para 25 bitcoins/bloco, e ela ir‡ reduzir novamente para 12,5 bitcoins/bloco no bloco 420.000, que s— ser‡ minerado aproximadamente em 2016. A taxa de novas moedas diminui exponencialmente em 64 "divis›es por dois" atŽ o bloco 13.230.000 (que ser‡ minerado aproximadamente no ano 2137), quando ela atingir‡ a unidade m’nima de 1 satoshi. Finalmente, ap—s 13,44 milh›es de blocos, aproximadamente no ano de 2140, quase 2.099.999.997.690.000 de satoshis, ou quase 21 milh›es de bitcoins, ter‹o sido emitidos. Depois disso, os blocos n‹o ir‹o conter novos bitcoins, e os mineradores ser‹o recompensados apenas com as taxas de transa•›es. Oferta de moedas bitcoin ao longo do tempo, que Ž baseada em uma taxa de emiss‹o com decrŽscimo geomŽtrico geomŽtrico demonstra o nœmero total de bitcoins em circula•‹o ao longo do tempo, na medida que a emiss‹o da moeda diminui.
2
Figure 1. Oferta Oferta de moedas bitcoin ao ao longo do tempo, que Ž baseada em uma taxa taxa de emiss‹o com decrŽscimo geomŽtrico
NOTE
O nœmero m‡ximo de "coins" mineradas Ž o limite superior das recompensas de minera•‹o poss’veis do bitcoin. Na pr‡tica, um minerador pode intencionalmente minerar um bloco recebendo menos do que a recompensa completa. Tais blocos j‡ foram minerados e mais podem ser minerados no futuro, resultando em uma menor emiss‹o total de moedas.
No c—digo de exemplo em Um script para calcular quanto de bitcoins totais ser‹o emitidos , n—s calculamos a quantidade total de bitcoins que ser‡ emitida.
3
Example 1. Um script para para calcular quanto quanto de bitcoins totais totais ser‹o emitidos emitidos
# Original block reward for miners was 50 BTC start_block_reward start_block_r eward = 50 # 210000 is around every 4 years with a 10 minute block interval reward_interval reward_interv al = 210000 def max_money(): max_money(): # 50 BTC = 50 0000 0000 Satoshis current_reward current_rew ard = 50 * 10**8 total = 0 while current_rew current_reward ard > 0: total += reward_inte reward_interval rval * current_rewa current_reward rd current_reward current_rewa rd /= 2 return total print "Total BTC to ever be created:", max_money(), "Satoshis"
Executando o script max_money.py mostra max_money.py mostra o output produzido ao executar-se esse script. Example 2. Executando Executando o script script max_money.py max_money.py
$ python max_money.py Total de BTCs que ser ‹o criados: 209999999769 2099999997690000 0000 Satoshis
A emiss‹o decrescente e finita cria uma oferta monet‡ria fixa que resiste ˆ infla•‹o. Ao contr‡rio das moedas fiduci‡rias, que podem ser impressas em nœmeros infitos por um banco central, o bitcoin jamais sofrer‡ infla•‹o causada por impress‹o impress‹o de moedas. moedas.
4
Dinheiro deflacion‡rio A consequncia mais importante e debatida de uma emiss‹o monet‡ria fixa e descrescente Ž que a moeda tender‡ a ser inerentemente deflacion‡ria. A defla•‹o Ž o fen™meno da perda de valor devido a um defasamento entre a oferta e a demanda que aumenta o valor (e a taxa de c‰mbio) de uma moeda. A defla•‹o dos pre•os, o contr‡rio da infla•‹o, significa que o dinheiro tem mais poder de compra com o passar do tempo. Muitos economistas argumentam que uma economia deflacion‡ria Ž um desastre e deveria ser evitada a todo custo. Isso porque em um per’odo de r‡pida defla•‹o, as pessoas tendem a guardar dinheiro ao invŽs de gast‡-lo, na esperan•a de que os pre•os ir‹o cair. Tal fen™meno ocorrer durante a "DŽcada Perdida" do Jap‹o, quando um colapso completo da demanda levou a moeda para um espiral deflacion‡rio. Os especialistas em Bitcoin argumentam que a defla•‹o n‹o Ž algo ruim por si s—. Ao invŽs disso, os economistas associam a defla•‹o a um colapso na demanda porque este foi o œnico exemplo de defla•‹o que n—s temos dispon’vel para estudar. Em uma moeda fiduci‡ria com a possibilidade de impress‹o ilimitada, Ž muito dif’cil de se entrar em uma espiral deflacion‡ria a menos que exista um colapso completo na demanda e um desinteresse em imprimir dinheiro. A defla•‹o do bitcoin n‹o Ž causada por um colapso na demanda, mas por uma oferta restrita previs’vel. Na pr‡tica, se tornou evidente que o instinto de acumular causado pela moeda deflacion‡ria pode ser superado atravŽs de descontos dos vendedores, atŽ que o desconto supere o instinto de acumular do comprador. Como o vendedor tambŽm est‡ motivado a acumular, o desconto se torna o pre•o de equil’brio no qual os dois instintos de acumular se correspondem. Com descontos de 30% no pre•o do bitcoin, a maior parte dos comerciantes de bitcoin n‹o est‹o tendo dificuldades em superar o instinto de acumular e est‹o gerando renda. Ainda n‹o se sabe se o aspecto deflacion‡rio da moeda Ž realmente um problema quando ele n‹o Ž conduzido por uma r‡pida retra•‹o econ™mica.
Consenso Descentralizado No cap’tulo anterior, n—s aprendemos sobre a blockchain, o registro pœblico (lista) global de todas as transa•›es, que todos participantes da rede bitcoin aceitam como um registro oficial das posses dos bitcoins. Mas como Ž poss’vel que todas as pessoas na rede concordem em uma "verdade" œnica universal sobre quem Ž dono do que, sem ter que confiar em alguŽm? Todos os sistemas de pagamento tradicionais dependem de um modelo de confian•a que possui uma autoridade central fornecendo um servi•o de c‰mara de compensa•‹o, basicamente verificando e compensando todas as transa•›es. O Bitcoin n‹o possui uma autoridade central no entanto de certa forma todos os nodos completos possuem uma c—pia completo do registro pœblico, no qual eles podem confiar como um registro confi‡vel. A blockchain n‹o Ž criada por uma autoridade central, mas Ž criada independentemente por cada nodo 5
da rede. De alguma maneira, cada nodo na rede, agindo com as informa•›es que s‹o transmitidas atravŽs das conex›es de rede inseguras, conseguem chegar ˆ mesma conclus‹o e fabricar o mesmo registro pœblico que todos os outros nodos. Essa cap’tulo examina o processo atravŽs do qual a rede bitcoin atinge um consenso global sem a necessidade de uma autoridade central. A principal inven•‹o de Satoshi Nakamoto Ž o mecanismo descentralizado para o consenso emergente. Diz-se emergente, pois o consenso n‹o Ž atingido de maneira expl’cita Ñ n‹o existe uma elei•‹o ou um momento fixo no qual o consenso ocorre. Ao invŽs disso, o consenso Ž um artefato que emerge da intera•‹o ass’ncrona de milhares de nodos independentes, todos seguindo regras simples. Todas as propriedades do bitcoin, incluindo a moeda, as transa•›es, os pagamentos e o modelo de seguran•a que n‹o depende de confian•a ou de uma autoridade central, derivam dessa inven•‹o. O consenso descentralizado do Bitcoin emerge da intera•‹o de quatro processos que ocorrem independentemente nos nodos pela rede: ¥ Verifica•‹o Verifica•‹o independente independente de cada transa•‹o, realizada realizada por cada nodo completo, que Ž baseada em uma extensa lista de critŽrios ¥ Agrega•‹o independente dessas dessas transa•›es em blocos novos pelos nodos mineradores, mineradores, associado ˆ demonstra•‹o de que um processo computacional foi realizado atravŽs de um algoritmo de provade-trabalho. ¥ Ver Verifica•‹o ifica•‹o independente independente dos novos novos blocos por cada cada nodo e inclus‹o deles em em uma cadeia ¥ Sele•‹o independente, independente, por cada nodo, da corrente de blocos com a maior computa•‹o acumulada demonstrada atravŽs da prova de trabalho Nas pr—ximas se•›es n—s iremos examinar os processos e como eles interagem para criar uma propriedade emergente de consenso amplo na rede que permite que qualquer nodo monte a sua pr—pria c—pia do registro global, pœblico, confi‡vel e seguro.
Verifica•‹o Independente de Transa•›es Em [transactions] [transactions],, n—s vimos como o software de carteira cria transa•›es ao coletar UTXO, fornecendo os scripts de destravamento apropriados e ent‹o construindo novos outputs designados para um novo dono. A transa•‹o resultando Ž ent‹o enviada para os nodos da rede bitcoin que est‹o mais pr—ximos, para que possa ser propagada ao longo de toda a rede bitcoin. Entretanto, antes de propagar as transa•›es para seus nodos vizinhos, cada nodo bitcoin que recebe uma transa•‹o ir‡ primeiro verific‡-la. Isso garante que somente transa•›es v‡lidas ser‹o propagadas para a rede, enquanto as transa•›es inv‡lidas ser‹o logo descartadas pelo primeiro nodo que as encontrarem. Cada nodo verifica todas as transa•›es contra uma lista de verifica•‹o (checklist) com v‡rios critŽrios: ¥ A sintaxe da transa•‹o e a estrutura de dados devem devem estar corretas. corretas. ¥ Nem a lista lista de entradas entradas (inputs), (inputs), nem a de sa’das (outputs) est‹o vazias.
6
¥ O tamanho da transa•‹o transa•‹o em bytes bytes Ž menor menor do que que o MAX_BLOCK_SIZE. MAX_BLOCK_SIZE. ¥ Cada valor de output, assim como o total, deve estar dentro dentro da faixa de valores permitida permitida (menos do que 21 milh›es de bitcoins e mais do que 0 bitcoins). ¥ Nenhum dos inputs tem hash=0, N=Ð1 (transa•›es (transa•›es coinbase n‹o devem ser transmitidas). transmitidas). ¥ O nLockTime nLockTime Ž menor menor ou igual igual ao ao INT_MAX. INT_MAX. ¥ O tamanho tamanho da transa•‹ transa•‹oo em bytes bytes Ž maior ou igual igual a 100. ¥ O nœmero de opera•›es opera•›es de assinatura assinatura contidas na transa•‹o Ž menor menor do que o limite de de opera•›es opera•›es de assinatura ¥ O script de destravamento destravamento (scriptSig) (scriptSig) s— pode empurrar nœmeros para para o stack, e o script de travamento (scriptPubkey) deve coincidir com as formas isStandard (isso rejeita transa•›es "nonstandard", n‹o-padr›es). ¥ Deve existir uma transa•‹o correspondente correspondente no pool, ou em um bloco bloco na corrente principal. ¥ Para cada input, input, se o output referenciado referenciado existir em qualquer qualquer outra transa•‹o transa•‹o no pool, a transa•‹o transa•‹o deve ser rejeitada. ¥ Para cada cada input, buscar no ramo principal principal e no pool pool de transa•›es transa•›es pelo output de de transa•‹o referenciado. Se o output de transa•‹o estiver faltando para qualquer input, essea ser‡ uma transa•‹o —rf‹. Adiciona ao pool de transa•›es —rf‹s, se uma transa•‹o correspondente j‡ n‹o estiver no pool. ¥ Para cada input, se o output de transa•‹o referenciado referenciado for um output coinbase, ele deve ter pelo pelo menos COINBASE_MATURITY COINBASE_MATURITY (100) (100 ) confirma•›es. ¥ Para cada entrada entrada (input), a sa’da sa’da (output) de referncia referncia deve existir e n‹o pode ter sido gasta previamente. ¥ Ao usar os outputs de transa•›es transa•›es referenciados referenciados para adquirir adquirir os valores de input, input, verificar que cada valor de input, assim como a soma, est‹o na faixa permitida de valores (menos que 21 milh›es de bitcoin, maior do que 0). ¥ Rejeitar se a soma dos valores de entrada entrada (input) seja seja menor do que a soma dos valores de sa’da (output). ¥ Rejeitar se a taxa de transa•‹o transa•‹o seria muito baixa para para entrar entrar em um bloco vazio. ¥ Os scripts de destravamento para cada cada input devem ser ser validados em em rela•‹o aos scripts de travamento dos outputs correspondentes. Essas condi•›es podem ser vistas em detalhes nas fun•›es AcceptToMemoryPool, CheckTransaction e CheckInputs no cliente de referncia bitcoin. Note que as condi•›es mudam ao longo do tempo, para lidar com novos tipos de ataques de nega•‹o de servi•o (DOS) ou ˆs vezes para tornar algumas regras menos r’gidas, com o objetivo de incluir mais tipos de transa•‹o. Ao verificar cada transa•‹o independentemente ˆ medida que ela Ž recebida e antes de propag‡-la, cada nodo constroi um pool de transa•›es v‡lidas (mas ainda n‹o-confirmadas) conhecido como pool de transa•›es, pool de mem—ria ou mempool.
7
Nodos Mineradores Alguns dos nodos da rede bitcoin s‹o nodos especializados chamados de mineradores . Em [ch01_intro_what_is_bitcoin] n—s [ch01_intro_what_is_bitcoin] n—s apresentamos o Jing, um estudante de engenharia da computa•‹o em Shangai, na China, que Ž um minerador bitcoin. O Jing ganha bitcoins por ter um "mining rig," "equipamento de minera•‹o", que Ž um sistema de hardware computadorizado projetado para minerar bitcoins. O hardware especializado de mienra•‹o do Jing Ž conectado a um servidor executando um nodo bitcoin completo. Ao contr‡rio do Jing, alguns mineradores mineram sem ter um nodo completo, como n—s veremos em Pools de Minera•‹o. Minera•‹o . Assim como todos os outros nodos completos, o nodo de Jing recebe e propaga transa•›es n‹o-confirmadas na rede bitcoin. O nodo do Jing, no entanto, tambŽm agrega agrega essas transa•›es transa•›es em blocos novos. O nodo do Jing fica monitorando os novos blocos que s‹o propagados na rede bitcoin, assim como todos os nodos fazem. No entanto, a chegada de um novo bloco tem um significado especial para um nodo de mienra•‹o. A competi•‹o entre os mineradores efetivamente termina com a propaga•‹o de um novo bloco, agindo como se fosse o anœncio de um vencedor. Para os mineradores, receber um novo bloco significa que alguma outra pessoa ganhou a competi•‹o e que eles perderam. No entanto, o fim de uma rodada de competi•‹o tambŽm Ž o in’cio da pr—xima rodada. O novo bloco n‹o Ž apenas uma bandeira quadriculada, que marca o final da corrida; ele tambŽm Ž o disparo de largada na corrida para o pr—ximo bloco.
Agregando Transa•›es em Blocos Ap—s validas as transa•›es, um nodo bitcoin ir‡ adicion‡las ao pool de mem—ria, ou pool de transa•›es, onde as transa•›es aguardam atŽ elas serem inclu’das (mineradas) em um bloco. O nodo do Jing coleta, valida e transmite novas transa•›es assim como qualquer outro nodo. Ao contr‡rio dos outros nodos, entretanto, o nodo do Jing ir‡ agregar essas transa•›es em um bloco candidato. Vamos seguir os blocos que foram criados durante o per’odo em que a Alice comprou uma x’cara de cafŽ do BobÕs Cafe (ver [cup_of_coffee] [cup_of_coffee]). ). A transa•‹o da Alice foi inclu’da no bloco 277.316. Para fins de demonstrar os conceitos nesse cap’tulo, vamos assumir que o bloco foi minerado pelo sistema de minera•‹o do Jing e vamos seguir a transa•‹o da Alice ˆ medida que ela Ž integrada a esse novo bloco. O nodo de minera•‹o do Jing contŽm uma c—pia local da blockchain, a lista de todos os blocos criados desde o in’cio do sistema bitcoin em 2009. 20 09. No momento em que a Alice compra a x’cara de cafŽ, o nodo do Jing montou uma cadeia atŽ o bloco 277.314. O nodo do Jing est‡ monitorando novas transa•›es, tentanto minerar um novo bloco e tambŽm monitorando os blocos descobertos pelos outros nodos. Ë medida que o nodo do Jing minera, ele recebe o bloco 277.315 atravŽs da rede bitcoin. A chegada desse bloco significa o fim da competi•‹o pelo bloco 277.315 e o in’cio da competi•‹o para a cria•‹o do bloco 277.316. Durante os œltimos 10 minutos, enquanto o nodo do Jing procurava uma solu•‹o para o bloco 277.315, ele tambŽm estava coletando transa•›es para se preparar para o pr—ximo bloco. Agora ele j‡ coletou algumas centenas de transa•›es no pool de mem—ria. Ao receber o bloco 277.315 e validando-o, o nodo do Jing tambŽm ir‡ verificar todas as transa•›es no pool de mem—ria e remover‡ qualquer uma que j‡ 8
tiver sido inclu’da no bloco 277.315. 2 77.315. Quaisquer transa•›es que permanecerem no pool de mem—ria s‹o transa•›es n‹o-confirmadas e est‹o aguardando para serem registradas em um novo bloco. O nodo do Jing imediatamente constroi um novo bloco vazia, um candidato para o bloco 277.316. Esse bloco Ž chamado de bloco candidato pois ele ainda n‹o Ž um bloco v‡lido, j‡ que ele n‹o contŽm uma prova de trabalho v‡lida. O bloco s— se torna v‡lido se o minerador tiver sucesso em encontrar uma solu•‹o para o algoritmo de prova de trabalho.
Idade da transa•‹o, Taxas e Prioridade Para construir um bloco candidato, o nodo de bitcoin do Jing seleciona as transa•›es a partir do pool de mem—ria ao aplicar uma mŽtrica de prioridade para cada transa•‹o e ao adicionar primeiro as transa•›es com maior prioridade. As transa•›es s‹o priorizadas de acordo com a "idade" do UTXO que est‡ sendo gasto em suas entradas (inputs), permitindo que inputs antigos e de alto valor recebam maior prioridade que inputs novos e de menores valores. As transa•›es que tem prioridade podem ser enviadas sem nenhuma taxa, se houver espa•o suficiente no bloco. A prioridade de uma transa•‹o Ž calculada como a soma dos valores e da idade dos inputs dividida pelo tamanho total da transa•‹o: Prioridade = Soma (Valor da entrada * Idade da entrada) / Tamanho da Transa •‹o
Nessa equa•‹o, o valor de um input Ž medido na unidade de base, satoshis (1/100m, a centŽsima milionŽsima parte de um bitcoin). A idade de um UTXO Ž o nœmero de blocos que j‡ foram minerados desde que a UTXO foi registrada na blockchain, medindo a quantos blocos de "profundidade" ela est‡ na blockchain. O tamanho da transa•‹o Ž medido em bytes. Para que uma transa•‹o seja considerada de "alta prioridade", sua prioridade deve ser maior do que 57.600.000, o que corresponde a um bitcoin (100 milh›es de satoshis), tenha um dia de idade (144 blocos), em uma transa•‹o com tamanho total de 250 bytes: Alta Prioridade > 100.000.000 satoshis * 144 blocos / 250 bytes = 57.600.000
Os primeiros 50 kilobytes do espa•o de uma transa•‹o em um bloco s‹o reservados para transa•›es de alta prioridade. O nodo do Jing ir‡ preencher os primeiros 50 kilobytes, dando prioridade para as transa•›es de alta prioridade primeiro, independente das taxas. Isso permite que as transa•›es de alta prioridade sejam processadas processadas mesmo que elas n‹o tenham taxa alguma. O nodo de minera•‹o do Jing preenche ent‹o o resto do bloco atŽ o tamanho m‡ximo de bloco (MAX_BLOCK_SIZE no c—digo), com transa•›es que carregam pelo menos a taxa m’nima, priorizando aquelas que tem a maior taxa por kilobyte de transa•‹o. Se houver algum espa•o remanescente no bloco, o nodo de minera•‹o do Jing pode escolher preenchlo com transa•›es sem taxas. Alguns mineradores decidem minerar as transa•›es sem taxas baseando-
9
se em um melhor esfor•o. Outros mineradores podem decidir ignorar as transa•›es sem t axas. Quaisquer transa•›es que sobrarem no pool de mem—ria, ap—s o bloco ter sido preenchido, permanecer‹o no pool para inclus‹o no pr—ximo bloco. Ë medida que as transa•›es permanecem no pool de mem—ria, a "idade" de suas entradas (inputs) aumenta, pois o UTXO que elas gastam se aprofunda cada vez mais na blockchain que vem recebendo novos blocos acima dele. Como a prioridade da transa•‹o depende da idade de suas entradas (inputs), as transa•›es remanescentes na pool ir‹o envelhecer e, portanto, aumentar‹o de prioridade. Por fim, uma transa•‹o pode atingir uma prioridade alta o suficiente para ser inclu’da grauitamente em um bloco. As transa•›es Bitcoin n‹o possuem um tempo limite de expira•‹o. Uma transa•‹o que Ž v‡lida agora ser‡ v‡lida para sempre. No entanto, se uma transa•‹o s— for propagada na rede uma œnica vez, ela ir‡ persistir contanto que ela seja mantida em um pool de mem—ria de um nodo minerador. Quando um nodo minerador Ž reiniciado, o seu pool de mem—ria Ž apagado, porque ele Ž uma forma de armazenamento transit—rio, n‹o-persistente. Embora uma transa•‹o v‡lida possa ter sido propagada pela rede, se ela n‹o for executada ela pode chegar a n‹o residir no pool de mem—ria de nenhum minerador. Espera-se que o software de carteira retransmita tais transa•›es ou as reconstrua com taxas maiores se elas n‹o forem executadas com sucesso em uma quantia de tempo razo‡vel. Quando o nodo do Jing agrega todas as transa•›es originadas do pool de mem—ria, o novo bloco candidato tem 418 transa•›es com um total de taxa de transa•›es de 0,09094928 bitcoin. Voc pode ver esse bloco na blockchain usando a interface em linha de comando do cliente Bitcoin Core, como demonstrado em Bloco 277,316. 277,316.
$ bitcoin-cli getblockhash 277316 0000000000000001b6b9a13b09 0000000000000 001b6b9a13b095e96db41c4a92 5e96db41c4a928b97ef2d944a9 8b97ef2d944a9b31b2cc7bdc4 b31b2cc7bdc4 $ bitcoin-cli getblock 0000000000000001b6b9a13b09 0000000000000 001b6b9a13b095e96db41c4a92 5e96db41c4a928b97ef2d944a9 8b97ef2d944a9b31b2cc7bdc4 b31b2cc7bdc4
10
Example 3. Bloco Bloco 277,316
{ "hash" : "000000000000 "0000000000000001b6b9a13b0 0001b6b9a13b095e96db41c4a9 95e96db41c4a928b97ef2d944 28b97ef2d944a9b31b2cc7bdc a9b31b2cc7bdc4", 4", "confirmations" "confirmati ons" : 35561, "size" : 218629, "height" : 277316, "version" : 2, "merkleroot"" : "merkleroot "c91c008c26e50763e9f548bb8 "c91c008c26e5 0763e9f548bb8b2fc323735f73 b2fc323735f73577effbc55502 577effbc55502c51eb4cc7cf2 c51eb4cc7cf2e", e", "tx" : [ "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f", "b268b45c59b39d759614757718b9918caf0ba9d97c56f3b91956ff877c503fbe", ... 417 outras transa •›es ... ], "time" : 1388185914, "nonce" : 924591752, "bits" : "1903a30c", "difficulty"" : 1180923195. "difficulty 1180923195.25802612, 25802612, "chainwork" : "00000000000 "000000000000000000000000 00000000000000000000000000 00000000000000000000093469 00000000934695e92aaf53afa1 5e92aaf53afa1a", a", "previousblockhash" "previousbl ockhash" : "0000000000000002a7bbd25a4 "000000000000 0002a7bbd25a417c0374cc5526 17c0374cc55261021e8a9ca744 1021e8a9ca74442b01284f056 42b01284f0569", 9", "nextblockhash" "nextblockh ash" : "000000000000000010236c269 "000000000000 000010236c269dd6ed714dd5db dd6ed714dd5db39d36b3395907 39d36b33959079d78dfd431ba 9d78dfd431ba7" 7" }
A Transa•‹o de Gera•‹o A primeira transa•‹o adicionada ao bloco Ž uma transa•‹o special, chamada de transa•‹o de gera•‹o ou transa•‹o coinbase Essa transa•‹o Ž constru’da no nodo de Jing e Ž a sua recompensa pelos seus esfor•os de minera•‹o. O nodo de Jing cria a transa•‹o de gera•‹o como um pagamento para a sua pr—pria carteira: "Page para o endere•o de Jing 25.09094928 bitcoin." A quantia total da recompensa que o Jing coleta por minerar um bloco Ž a soma da recompensa da transa•‹o de gera•‹o (25 novos bitcoins) com as taxas de transa•‹o (0.09094928) de todas as transa•›es inclu’das no bloco, como demonstrado em Gera•‹o da transa•‹o: transa•‹o :
$ bitcoin-cli getrawtransaction getrawtransaction d5ada064c6417ca25c4308bd15 d5ada064c6417 ca25c4308bd158c34b77e1c0ec 8c34b77e1c0eca2a73cda16c73 a2a73cda16c737e7424afba2f 7e7424afba2f 1
11
Example 4. Gera•‹o Gera•‹o da transa•‹o transa•‹o
{ "hex" : "0100000001000000000000000 "010000000100 00000000000000000000000000 00000000000000000000000000 0000000000000000000000000 00000000000000000000000ff 00000000000ffffffff0f ffffff0f 03443b0403858402062f503253 03443b0403858 402062f503253482fffffffff0 482fffffffff0110c08d950000 110c08d9500000000232102aa 0000232102aa970c592640d19 970c592640d19de03ff6f de03ff6f 329d6fd2eecb023263b9ba5d1b 329d6fd2eecb0 23263b9ba5d1b81c29b523da8b 81c29b523da8b21ac00000000" 21ac00000000",, "txid" : "d5ada064c641 "d5ada064c6417ca25c4308bd1 7ca25c4308bd158c34b77e1c0e 58c34b77e1c0eca2a73cda16c ca2a73cda16c737e7424afba2 737e7424afba2f", f", "version" : 1, "locktime" : 0, "vin" : [ { "coinbase" : "03443b04038 "03443b0403858402062f5032 58402062f503253482f", 53482f", "sequence" : 4294967295 } ], "vout" : [ { "value" : 25.09094928, "n" : 0, "scriptPubKey" "scriptPubK ey" : { "asm" : "02aa970c592640d19de03ff6f "02aa970c5926 40d19de03ff6f329d6fd2eecb0 329d6fd2eecb023263b9ba5d1b 23263b9ba5d1b81c29b523da8 81c29b523da8b21OP_CHECKSI b21OP_CHECKSIG", G", "hex" : "2102aa970c592640d19de03ff "2102aa970c59 2640d19de03ff6f329d6fd2eec 6f329d6fd2eecb023263b9ba5d b023263b9ba5d1b81c29b523d 1b81c29b523da8b21ac", a8b21ac", "reqSigs" : 1, "type" : "pubkey", "addresses" : [ "1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N" ] } } ], "blockhash" : "00000000000 "0000000000000001b6b9a13b 00001b6b9a13b095e96db41c4a 095e96db41c4a928b97ef2d944 928b97ef2d944a9b31b2cc7bdc a9b31b2cc7bdc4", 4", "confirmations" "confirmati ons" : 35566, "time" : 1388185914, "blocktime" : 1388185914 }
Ao contr‡rio das transa•›es comuns, a transa•‹o de gera•‹o n‹o consome (gasta) UTXO como inputs. Ao invŽs disso, ela possui um œnico input, chamado de coinbase, que cria bitcoins a partir do nada. A transa•‹o de gera•‹o possui um œnico output, que Ž pago a um endere•o bitcoin do pr—prio minerador. O output da transa•‹o transa•‹o de gera•‹o gera•‹o envia o valor de 25,09094928 bitcoins para o endere•o bitcoin do do minerador, nesse caso para 1MxTkeEP2PmHSMze5tUZ1hA 1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N. V3YTKu2Gh1N.
12
Recompensa da Coinbase e Taxas Para construir uma transa•‹o de gera•‹o, o nodo do Jing primeiro calcula a quantia total de taxas de transa•‹o ao somar todos os inputs e outputs das 418 transa•›es que foram acrescentadas ao bloco. As taxas s‹o calculadas assim: Total de Taxas = Soma(Inputs) - Soma(Outputs)
No bloco 277.316, o total de taxas de transa•‹o Ž de 0,09094928 bitcoins. A seguir, o nodo do Jing calcula a recompensa correta para o novo bloco. A recompensa Ž calculada baseando-se na altura do bloco, iniciando em 50 bitcoins por bloco e reduzindo pela metade a cada 210.000 blocos. Como esse bloco est‡ na altura 277.316, a recompensa correta Ž de 25 bitcoins. O c‡lculo pode ser visto na fun•‹o GetBlockSubsidy no cliente Bitcoin Core, Core, como demonstrado em em Calculando a recompensa do bloco Ñ Fun•‹o GetBlockSubsidy, GetBlockSubsidy, Cliente Bitcoin Core, main.cpp. main.cpp . Example 5. Calculando Calculando a recompensa recompensa do bloco Ñ Fun•‹o Fun•‹o GetBlockSubsidy GetBlockSubsidy,, Cliente Bitcoin Bitcoin Core, main.cpp main.cpp
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams) { int halvings = nHeight / consensusPa consensusParams.nSubsi rams.nSubsidyHalvingInt dyHalvingInterval; erval; // For•a a recompensa do bloco para zero quando a mudan •a para a direita (right shift)est‡ indefinida if (halvings >= 64) return 0; CAmount nSubsidy = 50 * COIN; // O subs’ dio dio Ž dividido pela metade a cada 210.000 blocos, o que ir ‡ acontecer, em mŽdia, a cada 4 anos. nSubsidy >>= halvings; return nSubsidy; }
O subs’dio inicial Ž calculado em satoshis ao se multiplar 50 com a constante COIN (100.000.000 satoshis). Isso define a recompensa inicial (nSubsidy) em 5 bilh›es de satoshis. A seguir, a fun•‹o calcula o nœmero de halvings que ocorreram ao dividir a altura do bloco atual pelo intervalo de halving (SubsidyHalvingInterva (SubsidyHalvingInterval). l). No caso do bloco 277.316, com um intervalo de halving a cada 210.000 blocos, o resultado Ž 1 halving. O nœmero m‡ximo permitido de halvings (divis›es da recompensa pela metade) Ž 64, ent‹o o c—digo imp›e uma recompensa zero (retornando apenas o valor das taxas) se as 64 halvings forem excedidas.
13
A seguir, a fun•‹o usa o operador de deslocamento bin‡rio ˆ direita ("right-shift") para dividir a recompensa (nSubsidy) por dois a cada rodada de halving. No caso do bloco 277.316, isso faria um deslocamento bin‡rio ˆ direita da recompensa de 5 bilh›es de satoshi uma vez (um halving) e resultaria em 2,5 bilh›es de satoshis, ou 25 bitcoins. O operador de deslocamento bin‡rio ˆ direita Ž usado porque ele Ž mais eficiente na divis‹o por dois do que a divis‹o de nœmeros inteiros ou a divis‹o de ponto flutuante. Finalmente, a recompensa coinbase (nSubsidy) Ž adicionada ˆs taxas de transa•‹o (nFees), (nFees), e retorna-se o valor da soma.
Estrutura da Gera•‹o da Transa•‹o Com esses c‡lculos, o nodo do Jing constroi ent‹o a transa•‹o de gera•‹o para pagar 25,09094928 bitcoins para ele pr—prio. Como voc pode ver em Gera•‹o da transa•‹o, transa•‹o, a transa•‹o de gera•‹o possui um formato especial. Ao invŽs de um input de transa•‹o especificando um UTXO prŽvio para gastar, ela possui um input "coinbase". N—s examinamos os inputs de transa•‹o em [tx_in_structure] [tx_in_structure].. Vamos comparar o input de uma transa•‹o comum com o input de uma transa•‹o de gera•‹o. A estrutura de um input de transa•‹o "normal" "normal" demonstra a estrutura de uma transa•‹o comum, enquando A estrutura da gera•‹o de um input de transa•‹o demonstra a estrutura estrutura de um input de uma transa•‹o transa•‹o de gera•‹o. gera•‹o. Table 1. A estrutura de um input de transa•‹o "normal" Tamanho
Campo
Descri•‹o
32 bytes
Hash da Transa•‹o
Apontador para a transa•‹o contendo o UTXO para ser gasto
4 bytes
êndice do Output
O nœmero ’ndice do UTXO para ser gasto, o primeiro Ž 0
1-9 bytes (VarInt)
Tamanho do Script de Destravamento
Comprimento do script de destravamento em bytes, para seguir
Vari‡vel
Script de Destravamento
Um script que preenche os critŽrios (condi•›es) para o script de travamento da UTXO
4 bytes
Nœmero Sequencial
Funcionalidade de substitui•‹o de transa•‹o, atualmente desabilitada, definida como 0xFFFFFFFF
Table 2. A estrutura da gera•‹o de um input de transa•‹o
14
Tamanho
Campo
Descri•‹o
32 bytes
Hash da Transa•‹o
Todos os bits s‹o zeros: N‹o Ž uma referncia a um hash de transa•‹o
4 bytes
êndice do Output
Todos os bits s‹o um: 0xFFFFFFFF
1-9 bytes (VarInt)
Tamanho dos Dados Coinbase
Comprimento dos dados coinbase, de 2 a 100 bytes
Vari‡vel
Dados Coinbase
Dados arbitr‡rios usados para o nonce extra e tags de minera•‹o nos blocos v2, deve come•ar com a altura do bloco
4 bytes
Nœmero Sequencial
Definido para 0xFFFFFFFF
Em uma transa•‹o de gera•‹o, os dois primeiros campos s‹o definidos para valores que n‹o representam uma referncia UTXO. Ao invŽs de um "Hash de Transa•‹o", o primeiro campo Ž preenchido com 32 bytes, todos definidos para zero. O "êndice de Output" Ž preenchido com 4 bytes todos definidos para 0xFF (255 em decimais). O "Script de Destravamento" Ž substitu’do pelos dados coinbase, um campo de dados arbitr‡rios usado pelos mineradores.
Dados Coinbase As transa•›es de gera•‹o n‹o possuem um campo de script de destravamento (tambŽm conhecido como scriptSig). Ao invŽs disso, o campo Ž substitu’do pelos dados coinbase, que devem ter entre 2 e 100 bytes. Exceto pelos primeiros poucos bytes iniciais, o resto dos dados coinbase podem ser usados pelos minerados da maneira que eles quiserem; eles s‹o dados arbitr‡rios. No bloco gnese, por exemplo, o Satoshi Nakamoto adicionou o texto "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" ("The Times 03/Jan/2009 Chanceler prestes a conceder segundo resgate aos bancos") nos dados coinbase, usando isso como prova da data e para transmitir uma mensagem. Atualmente os mineradores usam os dados da coinbase para adicionar valores nonce extra e strings identificando o pool de minera•‹o, como n—s veremos nas se•›es a seguir. Os primeiros poucos bytes da coinbase costumavam ser arbitr‡rios, mas hoje em dia n‹o s‹o mais. A partir da Proposta de Melhoria do Bitcoin 34 (BIP0034), os blocos vers‹o-2 (blocos com o campo de vers‹o definido como 2) devem conter o ’ndice da altura do bloco como uma opera•‹o "push" de script no in’cio do campo coinbase. No bloco 277.315 n—s vemos que a coinbase (ver Gera•‹o da transa•‹o), transa•‹o ), que est‡ no campo "Unlocking Script" ou scriptSig do input da transa•‹o, contŽm o valor hexadecimal 03443b0403858402062f503253482f. 03443b0403858402062f50325348 2f. Vamos decodificar esse valor. O primeiro byte, 03, instrui o motor de execu•‹o do script a empurrar os pr—ximos trs bytes para o stack do script (ver [tx_script_ops_table_pushdata] [tx_script_ops_table_pushdata]). ). Os pr—ximos trs bytes, 0x443b04, s‹o a altura do 15
bloco codificada em formato little-endian (ao contr‡rio, o byte menos significante primeiro). A ordem reversa dos bytes e o resultado Ž 0x043b44, que Ž 277.316 em decimais. Os pr—ximos poucos d’gitos hexadecimais (03858402062) (03858402062 ) s‹o usados para codificar um nonce extra (ver A Solu•‹o do Nonce Extra), Extra), ou um valor aleat—rio, usado para achar uma solu•‹o de prova de trabalho adequada. A parte final dos dados coinbase (2f503253482f) Ž a string /P2SH/ codificada em ASCII, que indica que o nodo minerador que minerou esse bloco suporta a melhoria hash-pagamento-para-script (P2SH) definida pela BIP0016. A introdu•‹o da capacidade P2SH exigiu um "voto" pelos mineradores para apoiar o BIP0016 ou o BIP0017. Aqueles que apoiaram a implementa•‹o do BIP0016 iriam incluir /P2SH/ em seus dados coinbase. Aqueles que apoiaram a implementa•‹o BIP0017 do P2SH iriam incluir a string p2sh/CHV em seus dados coinbase. A BIP0016 foi eleita como a vencedora, e muitos mineradores continuaram a incluir a string /P2SH/ em sua coinbase para indicar que eles apoiavam essa funcionalidade. Extra•‹o dos dados coinbase a partir do bloco gnese usa a livraria libbitcoin apresentada em [alt_libraries] para extrair os dados coinbase a partir do bloco gnese, exibindo a mensagem do [alt_libraries] Satoshi. Note que a livraria libbitcoin contŽm uma c—pia est‡tica do bloco gnese, portanto o c—digo exemplo pode adquirir o bloco gnese diretamente da livraria.
16
Example 6. Extra•‹o Extra•‹o dos dados dados coinbase a partir partir do bloco gnese
/* Display the genesis genesis block block message by Satoshi. Satoshi. */ #include #include oin.hpp> int main() { // Create genesis block. bc::block_type bc::block_ty pe block = bc::genesis bc::genesis_block(); _block(); // Genesis block contains a single coinbase transaction. assert(block.transaction assert(bloc k.transactions.size() s.size() == 1); // Get first transaction in block (coinbase). const bc::transact bc::transaction_type& ion_type& coinbase_tx = block.transa block.transactions[0]; ctions[0]; // Coinbase tx has a single input. assert(coinbase_tx.input assert(coin base_tx.inputs.size() s.size() == 1); const bc::transact bc::transaction_input_typ ion_input_type& e& coinbase_inp coinbase_input ut = coinbase_tx. coinbase_tx.inputs[0]; inputs[0]; // Convert the input script to its raw format. const bc::data_chu bc::data_chunk& nk& raw_message = save_script( save_script(coinbase_inp coinbase_input.script); ut.script); // Convert this to an std::string. std::string message; message.resize(raw_message.size()); std::copy(raw_message.be std::copy(r aw_message.begin(), gin(), raw_message. raw_message.end(), end(), message.begin message.begin()); ()); // Display the genesis block message. std::cout << message << std::endl; return 0; }
N—s compilamos o c—digo com o compilador GNU C++ e rodamos o execut‡vel resultante, como demonstrado em Compilando e executando o c—digo de exemplo satoshi-words. satoshi-words . Example 7. Compilando Compilando e executando executando o c—digo de exemplo exemplo satoshi-words
$ # Compila o c —digo $ g++ -o satoshi-words satoshi-words satoshi-words.cpp satoshi-words.cpp $(pkg-config --cflags --libs --libs libbitcoin) libbitcoin) $ # Roda o execut ‡vel $ ./satoshi-w ./satoshi-words ords ^D ^A^DEThe Times 03/Jan/2009 03/Jan/2009 Chancellor on brink of second bailout for banks
17
Construindo o Cabe•alho (Header) do Bloco Para construir o cabe•alho do bloco, o nodo minerador precisa preench-lo em seis campos, como listado em A estrutura do cabe•alho do bloco. bloco . Table 3. A estrutura do cabe•alho do bloco Tamanho
Campo
Descri•‹o
4 bytes
Vers‹o
Um nœmero de vers‹o para servir como referncia nas atualiza•›es de software/protocolo.
32 bytes
Hash do Bloco Anterior
Uma referncia ao hash do bloco anterior (bloco pai) na blockchain
32 bytes
Raiz de Merkle
Um hash da raiz da ‡rvore de merkle das transa•›es desse bloco
4 bytes
Data e Hora (timestamp)
O momento aproximado em que este bloco foi criado (em segundos, usando Unix Epoch)
4 bytes
Dificuldade Alvo
O alvo de dificuldade do algoritmo de prova-de-tra prova-de-trabalho balho deste bloco
4 bytes
Nonce
Um contador usado para o algoritmo de prova-de-tra prova-de-trabalho balho
No momento em que o bloco 277.316 foi minerado, o nœmero de vers‹o descrevendo a estrutura do bloco Ž a vers‹o 2, que Ž codificada em formato little-endian em 4 bytes como 0x02000000. A seguir, o nodo nodo de minera•‹o minera•‹o precisa adicionar adicionar o "Hash do Bloco Anterior". Esse Ž o hash do cabe•alho do bloco 277.315, o bloco anteriormente recebido pela rede, que o nodo do Jing aceitou e selecionou como pai do bloco candidato 277.316. O hash do cabe•alho do bloco 277.315 Ž: 0000000000000002a7bbd25a4 000000000000 0002a7bbd25a417c0374cc5526 17c0374cc55261021e8a9ca744 1021e8a9ca74442b01284f0569 42b01284f0569
O pr—ximo passo Ž fazer um resumo de todas as transa•›es com uma ‡rvore de merkle, para adicionar a raiz de merkle ao cabe•alho do bloco. A transa•‹o de gera•‹o Ž listada como a primeira transa•‹o do bloco. Ent‹o, mais 418 transa•›es s‹o adicionadas ap—s ela, totalizando 419 transa•›es no bloco. Como n—s vimos em [merkle_trees] [merkle_trees],, deve haver um nœmero par de nodos "folhas" na ‡rvore, de maneira que a œltima transa•‹o seja duplicada, criando 420 nodos, cada um contendo o hash de uma transa•‹o. Os hashes das transa•›es s‹o ent‹o combinados, em pares, criando cada n’vel da ‡rvore, atŽ que todas as
18
transa•›es sejam resumidas em um nodo œnico na "raiz" da ‡rvore. A raiz da ‡rvore de merkle Ž um resumo de todas as transa•›es em um valor œnico de 32 bytes, que voc pode ver listado como "merkle root" em Bloco 277,316, 277,316, e aqui: c91c008c26e50763e9f548bb8 c91c008c26e5 0763e9f548bb8b2fc323735f73 b2fc323735f73577effbc55502 577effbc55502c51eb4cc7cf2e c51eb4cc7cf2e
O nodo de minera•‹o ir‡ ent‹o adicionar uma estampa de tempo de 4-bye, codificada como uma estampa de tempo Unix "Epoch", que Ž baseada no nœmero de segundos decorridos desde ˆ meia noite de 1¼ de janeiro de 1970 UTC/GMT. O tempo 1388185914 Ž igual a sexta-feira, 27 Dez 2013, 23:11:54 UTC/GMT. O nodo ent‹o preenche a dificuldade alvo, que define a dificuldade prova-de-trabalho exigida para tornar esse bloco v‡lido. A dificuldade Ž armazenada no bloco utilizando-se a mŽtrica "bits de dificuldade" ("difficulty bits"), que Ž uma codifica•‹o mantissa-expoente do alvo. A codifica•‹o tem um expoente de 1 byte, seguido por uma mantissa (coeficiente) de 3 bytes. No bloco 277.316, por exemplo, o valor dos bits de dificuldade Ž 0x1903a30c. A primeira parte 0x19 Ž um expoente hexadecimal, enquanto a pr—xima parte, 0x03a30c, Ž o coeficiente. O conceito de um alvo de dificuldade Ž explicado em Alvo de Dificuldade e Reajustando o Alvo e a representa•‹o "bits de dificuldade" Ž explicada em Representa•‹o da Dificuldade. Dificuldade . O campo final Ž o nonce criptogr‡fico, que Ž come•a com zero. Com todos os outros campos preenchidos, o cabe•alho do bloco agora est‡ completo e o processo de minera•‹o pode come•ar. O objetivo agora Ž encontar um valor para o nonce que resulta em um hash de cabe•alho de bloco que Ž menor do que a dificuldade alvo. O nodo de minera•‹o ter‡ que testar bilh›es ou trilh›es de valores de nonce atŽ que encontre um nonce que satisfa•a as exigncias.
Minerando o Bloco Agora que um bloco candidato foi constru’do pelo nodo do Jing, Ž hora do equipamento de minera•‹o do Jing minerar o bloco, ou seja, encontrar uma solu•‹o para o algoritmo de prova de trabalho que far‡ com que o bloco seja v‡lido. Ao longo desse livro, n—s estudamos quais s‹o as fun•›es de hash criptogr‡ficas usadas em v‡rios aspectos do sistema bitcoin. A fun•‹o de hash SHA256 Ž a fun•‹o usada no processo de minera•‹o do bitcoin. Explicando de maneira simples, a minera•‹o Ž o processo de se ficar fazendo hashing do cabe•alho do bloco de maneira repetida, atŽ que o hash resultante corresponda a um alvo espec’fico. Os resultados da fun•‹o de hash n‹o podem ser determinados previamente, nem Ž poss’vel criar um padr‹o que ir‡ produzir um valor de hash espec’fico. Essa funcionalidade das fun•›es de hash significa que a œnica maneira de se produzir um resultado de hash que corresponde a um alvo espec’fico Ž atravŽs de sucessivas tentativas, modificando aleatoriamente o input atŽ que o hash resultante deseja apare•a por acaso.
19
Algoritmo de Prova-de-Trabalho Um algoritmo de hash pega um input de dados de comprimento arbitr‡rio e produz um resultado determin’stico de comprimento fixo, uma impress‹o digital do input. Para cada input espec’fico, o hash resultante sempre ser‡ o mesmo e pode ser facilmente calculado e verificado por qualquer pessoa que implementar o mesmo algoritmo de hash. A caracter’stica chave de um algoritmo de hash criptogr‡fico Ž que Ž virtualmente imposs’vel encontrar dois inputs diferentes que produzem a mesma impress‹o digital. Como complemento, tambŽm Ž virtualmente imposs’vel selecionar-se um input de uma maneira a produzir uma impress‹o digital desejada, a menos que fique se tentando inputs aleat—rios. Com SHA256, o output sempre tem 256 bits de comprimento, independente do tamanho do input. Em Exemplo de SHA256, SHA256, n—s iremos usar o intŽrprete Python para calcular o hash SHA256 da frase, "I am Satoshi Nakamoto." Example 8. Exemplo Exemplo de SHA256 SHA256
$ python
Python 2.7.1 >>> import hashlib >>> print hashlib.sha2 hashlib.sha256("I 56("I am Satoshi Nakamoto").hexdigest() Nakamoto").hexdigest() 5d7c7ba21cbbcd75d14800b100 5d7c7ba21cbbc d75d14800b100252d5b428e5b1 252d5b428e5b1213d27c385bc1 213d27c385bc141ca6b47989e 41ca6b47989e
Exemplo de SHA256 demonstra SHA256 demonstra o resultado de se calcular o hash da frase "I am Satoshi Nakamoto": 5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e. Esse nœmero Ž o hash ou a compila•‹o (" digest") da frase e ele Ž dependente de cada parte da frase. A adi•‹o de uma œnica letra, uma pontua•‹o ou qualquer outro caractere ir‡ produzir um hash diferente. Agora, se n—s mudarmos a frase, n—s dever’amos ver hashes completamente diferentes. Vamos experimentar isso ao adicionar um nœmero ao final de nossa frase, usando o script Python simples em SHA256 Um script para gerar muitos hashes ao fazer itera•‹o com um nonce .
20
Example 9. SHA256 SHA256 Um script script para gerar gerar muitos hashes hashes ao fazer itera•‹o itera•‹o com um nonce nonce
# example of iterating a nonce in a hashing algorithm's input import hashlib text = "I am Satoshi Nakamoto" # iterate nonce from 0 to 19 for nonce in xrange(20): # add the nonce to the end of the text input = text + str(nonce) # calculate the SHA-256 hash of the input (text+nonce (text+nonce)) hash = hashlib.sha25 hashlib.sha256(input).hexd 6(input).hexdigest() igest() # show the input and hash result print input, '=>', hash
A execu•‹o desse exemplo ir‡ produzir os hashes de v‡rias frases, que ser‹o diferentes devido ˆ adi•‹o de um nœmero no final do texto. Ao incrementar o nœmero, n—s podemos obter hashes diferentes, como demonstrado em Output SHA256 de um script para gerar muitos hashes fazendo itera•‹o com um nonce. nonce.
21
Example 10. Output Output SHA256 SHA256 de um script para para gerar muitos muitos hashes fazendo fazendo itera•‹o com com um nonce
$ python hash_example. hash_example.py py
I I I I I I I I I I I I I I I I I I I I
am am am am am am am am am am am am am am am am am am am am
Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi Satoshi
Nakamoto0 => a80a81401765c a80a81401765c8eddee25df367 8eddee25df36728d732... 28d732... Nakamoto1 => f7bc9a6304a46 f7bc9a6304a4647bb41241a677 47bb41241a677b5345f... b5345f... Nakamoto2 => ea758a8134b11 ea758a8134b115298a1583ffb8 5298a1583ffb80ae629... 0ae629... Nakamoto3 => bfa9779618ff0 bfa9779618ff072c903d773de3 72c903d773de30c99bd... 0c99bd... Nakamoto4 => bce8564de9a83 bce8564de9a83c18c31944a66b c18c31944a66bde992f... de992f... Nakamoto5 => eb362c3cf3479 eb362c3cf3479be0a97a201635 be0a97a20163589038e... 89038e... Nakamoto6 => 4a2fd48e3be42 4a2fd48e3be420d0d28e202360 0d0d28e202360cfbaba... cfbaba... Nakamoto7 => 790b5a1349a5f 790b5a1349a5f2b909bf74d0d1 2b909bf74d0d166b17a... 66b17a... Nakamoto8 => 702c45e5b15aa 702c45e5b15aa54b625d68dd94 54b625d68dd947f1597... 7f1597... Nakamoto9 => 7007cf7dd40f5 7007cf7dd40f5e933cd89fff5b e933cd89fff5b791ff0... 791ff0... Nakamoto10 => c2f38c81992f c2f38c81992f4614206a21537 4614206a21537bd634a... bd634a... Nakamoto11 => 7045da6ed8a9 7045da6ed8a914690f087690e 14690f087690e1e8d66... 1e8d66... Nakamoto12 => 60f01db30c1a 60f01db30c1a0d4cbce2b4b22 0d4cbce2b4b22e88b9b... e88b9b... Nakamoto13 => 0ebc56d59a34 0ebc56d59a34f5082aaef3d66 f5082aaef3d66b37a66... b37a66... Nakamoto14 => 27ead1ca85da 27ead1ca85da66981fd9da01a 66981fd9da01a8c6816... 8c6816... Nakamoto15 => 394809fb809c 394809fb809c5f83ce97ab554 5f83ce97ab554a2812c... a2812c... Nakamoto16 => 8fa4992219df 8fa4992219df33f50834465d3 33f50834465d3047429... 047429... Nakamoto17 => dca9b8b4f8d8 dca9b8b4f8d8e1521fa4eaa46 e1521fa4eaa46f4f0cd... f4f0cd... Nakamoto18 => 9989a401b2a3 9989a401b2a3a318b01e9ca9a a318b01e9ca9a22b0f3... 22b0f3... Nakamoto19 => cda56022ecb5 cda56022ecb5b67b2bc93a2d7 b67b2bc93a2d764e75f... 64e75f...
Cada frase produz um resultado de hash completamente diferente. Eles parecem ser completamente aleat—rios, mas voc Ž capaz de reproduzir exatamente os mesmos resultados desse exemplo em qualquer computador com Python e ver exatamente os mesmos hashes. O nœmero usado como uma vari‡vel nesse cen‡rio Ž chamado de nonce. O nonce Ž usado para variar o output de uma fun•‹o criptogr‡fica, nesse caso para variar a impress‹o digital SHA256 da frase. Para fazer um desafio com esse algoritmo, vamos definir um alvo arbitr‡rio: encontra uma frase que produza um hash hexadecimal que come•a com um zero. Felizmente, isso n‹o Ž dif’cil! Output SHA256 de um script para gerar muitos hashes fazendo itera•‹o com um nonce demonstr demonstraa que a frase frase "I am Satoshi Nakamoto13" produz o hash 0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5, que preenche nossos critŽrios. Levaria 13 tentativas atŽ ach‡-lo. Em termos de probabilidades, se o output da fun•‹o de hash Ž distribu’do igualmente, n—s esperar’amos encontrar um resultado com um zero como prefixo hexadecimal uma vez a cada 16 hashes (um em cada 16 d’gitos hexadecimais 0 atŽ F). Em termos numŽricos, isso significa achar um valor de hash que Ž menor que 0x1000000000000000000000000000000000000000000000000000000000000000. N—s chamamos esse limite de alvo e o objetivo Ž encontrar um hash que Ž numericamente menor que o alvo. Se n—s
22
diminuirmos o alvo, a tarefa de encontrar um hash que Ž menor que o alvo se torna cada vez mais dif’cil. Para usarmos uma analogia, imagine um jogo onde os jogadores lan•am um par de dados repetidamente, tentando tirar uma soma menor do que um alvo especificado. Na primeira rodada, o alvo da soma Ž 12. A menos que voc tire dois seis, voc ganha. Na pr—xima rodada o alvo Ž 11. Os jogadores devem tirar uma soma menor ou igual a 10 para ganhar, o que tambŽm Ž uma tarefa t arefa f‡cil. Digamos que algumas rodadas depois o alvo Ž 5. Agora, mais do que a metade dos lan•amentos ir‹o somar mais do que 5 e, portanto, ser‹o inv‡lidos. O nœmero de lan•amentos necess‡rios para se ganhar aumenta exponencialmente, quanto menor for o alvo. Por fim, quando o alvo Ž 2 (o menor poss’vel), somente um lan•amento a cada 36, ou 2% deles, ir‡ produzir um resultado vencedor. Em Output SHA256 de um script para gerar muitos hashes fazendo itera•‹o com um nonce, nonce , o "nonce" vencedor Ž 13 e esse resultado pode ser confirmado por qualquer pessoa de maneira independente. Qualquer um pode adicionar o nœmero 13 como sufixo da frase "I am Satoshi Nakamoto" e computar o hash, verificando que ele Ž menor do que o alvo. A confirma•‹o do resultado (do "nonce") tambŽm Ž uma prova de trabalho, pois ela comprova que n—s trabalhamos para encontrar esse nonce. Enquanto a verifica•‹o exige a computa•‹o de apenas um hash, foi necess‡ria a computa•‹o de 13 hashes atŽ que encontr‡ssemos um nonce que funcionasse. Se n—s tivŽssemos um alvo menor (uma dificuldade maior), seria necess‡ria a computa•‹o de muito mais hashes atŽ encontrar um nonce compat’vel, mas continuaria sendo necess‡ria a computa•‹o de apenas um hash para verific‡-lo. AlŽm disso, ao ter o conhecimento do alvo, qualquer um pode estimar a dificuldade usando estat’sticas, e portanto saber‡ quanto de trabalho foi necess‡rio para se descobrir o "nonce". A prova de trabalho do bitcoin Ž muito semelhante ao desafio demonstrado em Output SHA256 de um script para gerar muitos hashes fazendo itera•‹o com um nonce . O minerador constroi um bloco candidado preenchido com transa•›es. A seguir, o minerador calcula o hash do cabe•alho desse bloco e verifica se ele Ž menor do que o alvo atual. Se o hash n‹o for menor do que o alvo, o minerador ir‡ modificar o nonce (geralmente somando o nœmero 1) e tentar‡ novamente. Na dificuldade atual da rede bitcoin, os mineradores tem que fazer quadrilh›es de tentativas atŽ achar um nonce que resulte em um hash de cabe•alho de bloco baixo o suficiente. Um algoritmo muito simplificado de prova-de-trabalho Ž implementado em Python em Implementa•‹o simplificada de prova-de-trab prova-de-trabalho alho.. Example 11. Implementa•‹o Implementa•‹o simplificada simplificada de prova-de-trabalho prova-de-trabalho
#!/usr/bin/env python #!/usr/bin/env # example of proof-of-work algorithm algorithm import hashlib import time max_nonce = 2 ** 32 # 4 billion def proof_of_wo proof_of_work(header, rk(header, difficulty_bits): 23
# calculate the difficulty target target = 2 ** (256-difficu (256-difficulty_bits) lty_bits) for nonce in xrange(max_n xrange(max_nonce): once): hash_result = hashlib.sha25 hashlib.sha256(str(header 6(str(header)+str(nonce)) )+str(nonce)).hexdigest() .hexdigest() # check if this is a valid result, below the target if long(hash_res long(hash_result, ult, 16) < target: print "Success with nonce %d" % nonce print "Hash is %s" % hash_result return (hash_resul (hash_result,nonce) t,nonce) print "Failed after %d (max_nonce) tries" % nonce return nonce
if __name__ == '__main__': nonce = 0 hash_result = '' # difficulty from 0 to 31 bits for difficulty_b difficulty_bits its in xrange(32): difficulty = 2 ** difficulty_bi difficulty_bits ts print "Difficulty "Difficulty:: %ld (%d bits)" % (difficulty (difficulty,, difficulty_ difficulty_bits) bits) print "Starting search..." # checkpoint the current time start_time = time.time() # make a new block which includes the hash from the previous block # we fake a block of transactions - just a string new_block = 'test block with transactions' + hash_result # find a valid nonce for the new block (hash_result,, nonce) = proof_of_wor (hash_result proof_of_work(new_block, k(new_block, difficulty_bi difficulty_bits) ts) # checkpoint how long it took to find a result end_time = time.time() elapsed_tim e = end_time - start_time elapsed_time print "Elapsed Time: %.4f seconds" % elapsed_time if elapsed_time > 0:
24
# estimate the hashes per second hash_power = float(long(n float(long(nonce)/elapsed once)/elapsed_time) _time) print "Hashing Power: %ld hashes per second" % hash_power
Ao executar esse c—digo, voc pode definir a dificuldade desejada (em bits, a quantidade de bits inicias deve ser zero) e ver quanto tempo leva para seu computador encontrar uma solu•‹o. Em Executando o exemplo de prova de trabalho para v‡rias dificuldades , voc pode ver como isso funciona em um laptop comum. Example 12. Executando Executando o exemplo exemplo de prova de trabalho trabalho para para v‡rias dificuldades dificuldades
$ python proof-of-work-example.py* proof-of-work-example.py*
Dificuldade: 1 (0 bits) [...] Dificuldade: 8 (3 bits) Iniciando a busca... Sucesso com o nonce 9 O hash Ž 1c1c105e65b47 1c1c105e65b47142f028a8f93d 142f028a8f93ddf3dabb926049 df3dabb9260491bc644747381 1bc64474738133ce5256cb3c1 33ce5256cb3c1 Tempo Decorrido: 0,0004 segundos Poder de Hashing: 25.065 hashes por segundo Dificuldade: 16 (4 bits) Iniciando a busca... Sucesso com o nonce 25 O hash Ž 0f7becfd3bcd1 0f7becfd3bcd1a82e06663c971 a82e06663c97176add89e7cae0 76add89e7cae0268de46f94e7 268de46f94e7e11bc3863e148 e11bc3863e148 Tempo Decorrido: 0,0005 segundos Poder de Hashing: 52.507 hashes por segundo Dificuldade: 32 (5 bits) Iniciando a busca... Sucesso com o nonce 36 O hash Ž 029ae6e500430 029ae6e5004302a120630adcbb 2a120630adcbb808452346ab1c 808452346ab1cf0b94c5189ba f0b94c5189ba8bac1d47e7903 8bac1d47e7903 Tempo Decorrido: 0,0006 segundos Poder de Hashing: 58.164 hashes por segundo [...] Dificuldade: 4194304 (22 bits) Iniciando a busca... Sucesso com o nonce 1759164 O hash Ž 0000008bb8f0e 0000008bb8f0e731f0496b8e53 731f0496b8e530da984e85fb3c 0da984e85fb3cd2bd81882fe8 d2bd81882fe8ba3610b6cefc3 ba3610b6cefc3 Tempo Decorrido: 13,3201 segundos Poder de Hashing: 132.068 hashes por segundo
25
Dificuldade: 8388608 (23 bits) Iniciando a busca... Sucesso com o nonce 14214729 O hash Ž 000001408cf12 000001408cf12dbd20fcba6372 dbd20fcba6372a223e098d5878 a223e098d58786c6ff93488a9 6c6ff93488a9f74f5df4df0a3 f74f5df4df0a3 Tempo Decorrido: 110,1507 segundos Poder de Hashing: 129.048 hashes por segundo Dificuldade: 16777216 (24 bits) Iniciando a busca... Sucesso com o nonce 24586379 O hash Ž 0000002c3d6b3 0000002c3d6b370fccd699708d 70fccd699708d1b7cb4a943885 1b7cb4a94388595171366b944 95171366b944d68b2acce8b95 d68b2acce8b95 Tempo Decorrido: 195,2991 segundos Poder de Hashing: 125.890 hashes por segundo [...] Dificuldade: 67108864 (26 bits) Iniciando a busca... Sucesso com o nonce 84561291 O hash Ž 0000001f0ea21 0000001f0ea21e676b6dde5ad4 e676b6dde5ad429b9d131a9f2b 29b9d131a9f2b000802ab2f16 000802ab2f169cbca22b1e21a 9cbca22b1e21a Tempo Decorrido: 665,0949 segundos Poder de Hashing: 127.141 hashes por segundo
Como voc pode ver, aumentar a dificuldade em 1 bit causa um aumento exponencial no tempo que leva para se encontrar uma solu•‹o. Se voc pensar em todo o espa•o numŽrico de 256-bits, cada vez que voc limite um bit a mais para zero, voc diminui o espa•o de busca pela metade. Em Executando o exemplo de prova de trabalho para v‡rias dificuldades , leva 84 milh›es de tentativas de hash para se encontrar um nonce que produza um hash com 26 bits iniciais como zero. Mesmo em uma velocidade de mais de 120.000 hashes por segundo, ainda s‹o necess‡rios 10 minutos para encontrar essa solu•‹o em um notebook comum . Na Žpoca em que esse livro foi escrito, a rede estava tentanto achar um bloco cujo hash do cabe•alho fosse menor que 000000000000004c296e6376db3a241271f43fd3f5de7ba18986e517a243baa7. Como voc pode ver, existem v‡rios zeros no in’cio desse hash, significando que a faixa aceit‡vel de hashes Ž muito menor, portanto Ž mais dif’cil de se encontrar um hash v‡lido. Levar‡ em mŽdia mais de 150 quadrilh›es de c‡lculos hash por segundo para que a rede descubra o pr—ximo bloco. Isso parece uma tarefa quase imposs’vel, mas felizmente a rede j‡ est‡ com um poder de processamento de 100 petahashes por segundo (PH/seg), que ser‹o capazes de encontrar um bloco em cerca de 10 minutos em mŽdia.
Representa•‹o da Dificuldade Em Bloco 277,316, 277,316, n—s vimos que o bloco contŽm a dificuldade alvo, em uma nota•‹o chamada "bits de dificuldade" ou apenas "bits", que no bloco 277.316 tinha o valor de 0x1903a30c. Esse nota•‹o expressa a dificuldade alvo em um formato coeficiente/expoente, com os primeiros dois d’gitos hexadecimais sendo o expoente e os pr—ximos seis d’gitos hexadecimais sendo o coeficiente. Nesse bloco, portanto, o
26
expoente Ž 0x19 e o coeficiente Ž 0x03a30c. A f—rmula para calcular a dificuldade-alvo a partir dessa representa•‹o Ž: alvo = coeficiente * 2^(8 * (expoente Ð 3))
Usando essa f—rmula, e o valor 0x1903a30c 0x1903 a30c para os bits de dificuldade, n—s obtemos: alvo = 0x03a30c * 2^(0x08 * (0x19 - 0x03))^ => alvo = 0x03a30c * 2^(0x08 * 0x16)^ => alvo = 0x03a30c * 2^0xB0^
que em decimal Ž: => alvo = 238,348 * 2^176^ => alvo = 22,829,202,94 22,829,202,948,393,929,850 8,393,929,850,749,706,076, ,749,706,076,701,368,331, 701,368,331,072,452,018,3 072,452,018,388,575,715,32 88,575,715,3288
transformando de volta para hexadecimal: => alvo = 0x00000000000 0x0000000000000003A30C0000 00003A30C00000000000000000 0000000000000000000000000 0000000000000000000000000 000000000000000 00
Isso significa que um bloco v‡lido para a altura 277.316 Ž um quer tem um hash de cabe•alho de bloco que Ž menor do que o alvo. Em bin‡rios esse nœmero teria mais do que os primeiros 60 bits definidos como zero. Com esse n’vel de dificuldade, um œnico minerador processando 1 trilh‹o de hases por segundo (1 tera-hash por segundo ou 1 TH/seg) encontraria uma solu•‹o, em mŽdia, somente uma vez a cada 8.496 blocos ou uma vez a cada 59 dias.
Alvo de Dificuldade e Reajustando o Alvo Como vimos anteriormente, o alvo determina a dificuldade e portanto afeta qu‹o demora ser‡ para encontrar uma solu•‹o para o algortimo de prova-de-trabalho. Isso nos levanta quest›es —bvias: Por que a dificuldade Ž ajust‡vel, quem a ajusta e como? Os blocos do Bitcoin s‹o gerados a cada 10 minutos, em mŽdia. Essa Ž a "frequncia card’aca" do bitcoin e Ž a base da frequncia de emiss‹o de moeda e a velocidade de confirma•‹o das transa•›es. Ela tem que permanecer constante n‹o apenas a curto prazo, mas tambŽm a prazos muito longos, como dŽcadas. Ao longo desse tempo, espera-se que o poder de processamento ir‡ aumentar em um ritmo muito r‡pido. AlŽm disso, o nœmero de paricipantes na minera•‹o e os computadores que eles usam tambŽm ir‡ mudar constantemente. Para manter o tempo de gera•‹o de blocos em 10 minutos, a
27
dificuldade da minera•‹o deve ser ajustada para contabilizar essas mudan•as. De fato, a dificuldade Ž um par‰metro din‰mico que ser‡ ajustado periodicamente para atingir o alvo de um bloco a cada 10 minutos. Simplificando, o alvo de dificuldade Ž definido para qualquer poder de minera•‹o que resulte em um intervalo de 10 minutos entre a gera•‹o dos blocos. Como, ent‹o, tal ajusta Ž feito em uma rede completamente descentralizada? O reajuste do alvo da dificuldade ocorre automaticamente e em cada nodo completo de maneira independente. A cada 2.016 blocos, todos os nodos reajustam o alvo da dificuldade de prova de trabalho. A equa•‹o para reajustar o alvo mede o tempo que levou para encontrar os œltimos 2.016 blocos e o compara com o tempo esperado de 20.160 minutos (duas semanas, baseando-se em um tempo desejado de 10 minutos para gerar um bloco). A raz‹o entre os per’odos de tempo atual e o desejado Ž calculada, e um ajuste correspondente (para cima ou para baixo) Ž feito ˆ dificuldade. Simplificando: Se a rede estiver encontrando blocos mais r‡pido do que a cada 10 minutos, a dificuldade ir‡ aumentar. E se a descoberta de blocos estiver mais lenta que o esperado esperado,, a dificuldade ir‡ diminuir. A equa•‹o pode ser resumida como: Nova Dificuldade = Dificuldade Antiga * (Tempo dos œltimos 2.016 blocos / 20.160 minutos)
Mudando a dificuldade alvo da prova-de-trabalho Ñ CalculateNextWorkRequired() in pow.cpp demonstra o c—digo usado no cliente Bitcoin Core.
28
Example 13. Mudando Mudando a dificuldade dificuldade alvo da prova-de-trabalho prova-de-trabalho Ñ CalculateNextW CalculateNextWorkRequired() orkRequired() in pow.cpp pow .cpp
// Limita o passo de ajuste int64_t nActualTimes nActualTimespan pan = pindexLast->G pindexLast->GetBlockTime() etBlockTime() - nFirstBlockT nFirstBlockTime; ime; LogPrintf(" nActualTimes nActualTimespan pan = %d before bounds\n", nActualTime nActualTimespan); span); if (nActualTimes (nActualTimespan pan < params.nPowTa params.nPowTargetTimespan/ rgetTimespan/4) 4) nActualTimespan nActualTimes pan = params.nPowTa params.nPowTargetTimespan/ rgetTimespan/4; 4; if (nActualTimes (nActualTimespan pan > params.nPowTa params.nPowTargetTimespan* rgetTimespan*4) 4) nActualTimespan nActualTimes pan = params.nPowTa params.nPowTargetTimespan* rgetTimespan*4; 4;
//Reestabelecer o alvo //Reestabelecer const arith_uint25 arith_uint2566 bnPowLimit = UintToArith25 UintToArith256(params.pow 6(params.powLimit); Limit); arith_uint256 arith_uint2 56 bnNew; arith_uint256 arith_uint2 56 bnOld; bnNew.SetCompact(pindexLast->nBits); bnOld = bnNew; bnNew *= nActualTimesp nActualTimespan; an; bnNew /= params.nPowTa params.nPowTargetTimespan; rgetTimespan; if (bnNew > bnPowLimit) bnNew = bnPowLimit;
NOTE
Enquanto a calibragem da dificuldade acontece a cada 2.016 blocos, a existncia de um erro off-by-one (OBOE, "erro por um") no cliente Bitcoin Core original faz com que ela seja baseada no tempo total dos 2.015 blocos anteriores (e n‹o 2.016, como deveria ser), o que resulta em uma dificuldade 0,05% maior na modifica•‹o do alvo.
Os par‰metros Interval (2.016 blocos) e TargetTimespan (duas semanas ou 1.209.600 segundos) s‹o definidos em chainparams.cpp . Para evitar uma volatilidade extrema na dificuldade, o ajusto do alvo deve ser menor do que um fator de quatro (4) por ciclo. Se o ajuste de dificuldade necess‡rio Ž maoir do que um fator de quatro, ele ser‡ ajustado atŽ o m‡ximo, e n‹o mais do que isso. Qualquer ajuste adicional ser‡ realizado no pr—ximo per’odo de ajuste do alvo, pois o desequil’brio ir‡ persistir durante os pr—ximos 2.016 blocos. Portanto, grandes discrep‰ncias entre o poder de hashing e a dificuldade podem levar v‡rios ciclos de 2.016 blocos para se equilibrarem.
TIP
A dificuldade de se achar um bloco bitcoin Ž de aproximadamente '10 minutos de processamento' para toda a rede, baseando-se no tempo que levou para encontrar os œltimos 2.016 blocos, ajustada a cada 2.016 blocos.
Perceba que a dificuldade alvo Ž independente do nœmero de transa•›es ou do valor das transa•›es. Isso significa que o alvo do poder de hashing e, portanto, a eletricidade gasta para manter a seguran•a 29
da rede bitcoin Ž tambŽm totalmente independente do nœmero de transa•›es. O bitcoin pode se expandir, atingir uma ado•‹o maior e se manter seguro sem nenhum aumento no poder de hashing que j‡ existe hoje. O aumento no poder de hashing representa as for•as do mercado ˆ medida que novos mineradores entram no mercado para competir pela recompensa. Enquanto houver um poder de hashing suficiente sob o controle de mineradores agindo honestamente em busca da recompensa, ele ser‡ suficiente para prevenir ataques de "assumir o controle" ("takeover") e, portanto, ser‡ suficiente para manter o bitcoin seguro. A dificuldade-alvo Ž intimamente relacionada com o custo da eletricidade e a taxa de c‰mbio do bitcoin em rela•‹o ˆ moeda usada para pagar pela eletricidade. Sistemas de minera•‹o de alta performance s‹o o mais eficientes poss’veis com a gera•‹o atual que Ž fabricada em sil’cio, convertendo a eletricidade em computa•‹o de hashes na taxa mais alta poss’vel. A principal influncia no mercado de minera•‹o Ž o pre•o de um kilowatt-hora em bitcoin, porque ele determina a rentabilidade da minera•‹o e, portanto, os incentivos para se entrar ou sair do mercado de minera•‹o.
Minerando um Bloco com Sucesso Como n—s vimos anteriormente, o nodo do Jing construiu um bloco candidato e o preparou para a minera•‹o. O jing possui v‡rios equipamentos de minera•‹o em hardware com circuitos integrados de aplica•‹o especifica (CIAE ou ASICs), onde centenas de milhares de circuitos integrados executam a velocidades incr’veis o algoritmo SHA256 em paralelo. Essas m‡quinas especializadas s‹o conectadas ao seu nodo de minera•‹o atravŽs de USB. A seguir, o nodo de minera•‹o sendo executado no desktop do Jin transmite o cabe•alho do bloco para seu hardware de minera•‹o, que come•a as tentativas de trilh›es de nonces por segundo. Quase 11 minutos depois de come•ar a minerar o bloco 277.316, uma das m‡quinas de minera•‹o encontra uma solu•‹o a enviar de volta ao n— de minera•‹o. Quando inserida no cabe•alho do bloco, o nonce 4.215.469.401 produz um bloco de hash de: 0000000000000002a7bbd25a4 000000000000 0002a7bbd25a417c0374cc5526 17c0374cc55261021e8a9ca744 1021e8a9ca74442b01284f0569 42b01284f0569
que Ž menor do que o alvo: 0000000000000003A30C00000 000000000000 0003A30C000000000000000000 00000000000000000000000000 00000000000000000000000000 0000000000000
Imediatamente, o nodo de minera•‹o do Jing transmite o bloco para todos os seus pontos. Eles recebem, validam e ent‹o propagam o novo bloco. Ë medida que o bloco Ž disseminado na rede, cada nodo o adiciona ˆ sua pr—pria c—pia da blockchain, estendendo-a para uma nova altura de 277.316 blocos. Conforme os nodos de minera•‹o v‹o recebendo e validando o bloco, eles abandonam seus esfor•os de encontrar um bloco com a mesma altura e imediatamente passam a computar o pr—ximo bloco na corrente. Na pr—xima se•‹o, n—s iremos aprender sobre o processo que cada nodo usa para validar um bloco e
30
selecionar a cadeia mais longa, criando o consenso que forma a cadeia de blocos descentralizada (blockchain).
Validando um Novo Bloco O terceiro passo no mecanismo de consenso do bitcoin Ž a valida•‹o independente de cada bloco novo, que Ž realizada por cada nodo da rede. Ë medida que os blocos recŽm-descobertos s‹o propagados pela rede, cada nodo realiza uma sŽrie de testes para valid‡-lo antes de propag‡-lo para seus pares. Isso garente que somente blocos v‡lidos ser‹o propagados na rede. A valida•‹o independente tambŽm garante que os mineradores que agirem honestamente ter‹o seus blocos incorporados na blockchain, e, portanto, receber‹o sua recompensa. Os mineradores que agirem desonestamente ter‹o seus blocos rejeitados e n‹o apenas perder‹o sua recompensa, como tambŽm ter‹o desperdi•ado o esfor•o despendido para encontrar encontrar uma solu•‹o de prova-de-tra prova-de-trabalho, balho, ou seja, ter‹o t er‹o gasto com energia elŽtrica sem obter nenhuma compensa•‹o. Quando um nodo recebe um bloco novo, ele ir‡ validar o bloco ao verific‡-lo contra uma longa lista de critŽrios que precisam ser preenchidos; caso contr‡rio, o bloco ser‡ rejeitado. Esses critŽrios podem ser vistos no cliente Bitcoin Core nas fun•›es CheckBlock e CheckBlockHeader e incluem: ¥ A estrutura estrutura do bloco bloco de dados Ž sintatica sintaticamente mente v‡lida. v‡lida. ¥ O hash do cabe•alho cabe•alho do bloco Ž menor do que a dificuldade de destino (garante (garante a prova de trabalho) ¥ O timestamp do bloco Ž menos do que duas horas no futuro (permitindo erros de tempo) tempo) ¥ O tamanho tamanho do bloco bloco est‡ dentro dentro dos limites limites aceit‡ aceit‡veis veis ¥ A primeira primeira transa•‹o (e somente a primeira) primeira) Ž uma transa•‹o de gera•‹o gera•‹o coinbase ¥ Todas as transa•›es contidas no bloco s‹o v‡lidas usando usando o checklist de transa•›es discuto discuto em Verifica•‹o Independente de Transa•›es A valida•‹o independente de cada bloco novo feita por todos os nodos da rede garante que os mineradores n‹o podem trapacear. Nas se•›es anteriores n—s vimos como os mineradores conseguem escrever uma transa•‹o que os recompensa com os novos bitcoins criados no interior do bloco e os paga as taxas de transa•‹o. Por que os mineradores n‹o escrevem para eles pr—prios uma transa•‹o com mil bitcoins de recompensa, ao invŽs de usar a recompensa correta? Porque todos os nodos validam os blocos de acordo com as mesmas regras. Uma transa•‹o coinbase inv‡lida tornaria inv‡lido todo o bloco, o que resultaria em um bloco sendo rejeitado e, portanto, a transa•‹o jamais seria inclu’da na blockchain. Os mineradores tem que construir um bloco perfeito, baseado nas regras compartilhadas que todos os nodos seguem, e miner‡-lo com uma solu•‹o correta para a prova de trabalho. Para fazer isso, eles gastam muita energia elŽtrica na minera•‹o, e se eles trapacear t rapacearem, em, todos os seus gastos com energia elŽtrica e todo o seu esfor•o ser‹o desperdi•ados. Esse Ž o motivo pelo qual a valida•‹o independente Ž o componente chave do consenso descentralizad descentralizado. o.
31
Montando e Selecionando Cadeias de Blocos O passo final no mecanismo de consenso descentralizado do bitcoin Ž a uni‹o dos blocos em cadeias e a sele•‹o da cadeia que possui a maior prova de trabalho. Assim que o nodo validar um bloco novo, ele ir‡ tentar montar uma cadeia ligando o bloco ˆ blockchain existente. Os nodos mantŽm trs conjuntos de blocos: aqueles conectados ˆ blockchain principal, aqueles que foram ramifica•›es da blockchain principal (correntes secund‡rias), e, finalmente, os blocos que n‹o tem um pai conhecido nas correntes conhecidas (—rf‹os). Os blocos inv‡lidos s‹o rejeitados assim que qualquer critŽrio de valida•‹o falhar e, portanto, n‹o s‹o inclu’dos em nenhuma corrente. A "corrente principal" a qualquer momento Ž a corrente de blocos que tiver a maior dificuldade acumulada associada a ela. Sob a maioria das circunst‰ncias ela tamŽm ser‡ a corrente que tiver o maior nœmero de blocos, a menos que existam outras duas correntes de comprimento semelhante e uma delas tiver mais prova prova de trabalho. trabalho. A corrente principal principal tambŽm ter‡ ramifica•›es ramifica•›es com blocos que s‹o "irm‹os" dos blocos que est‹o na corrente principal. Eles s‹o mantidos para referncia futura, caso uma dessas correntes for estendida e passar a apresentar maior dificuldade que a corrente principal. Na pr—xima se•‹o (Forks ( Forks (bifurca•›es) da Blockchain), Blockchain ), n—s iremos ver como as correntes secund‡rias surgem quando h‡ uma minera•‹o quase simult‰nea de blocos em uma mesma altura. Quando um bloco novo Ž recebido, um nodo ir‡ tentar acrescent‡-lo na blockchain existente. O nodo ir‡ procurar no bloco pelo campo "hash do bloco anterior", que Ž a referæncia ao pai do bloco novo. Ent‹o, o nodo ir‡ tentar encontrar esse pai na blockchain existente. Na maioria das vezes, o pai ser‡ o "topo" da corrente principal, ou seja, esse bloco novo ir‡ estender a corrente principal. Por exemplo, o novo bloco 277.316 tem uma referncia ao hash de seu bloco pai 277.315. A maioria dos nodos que recebem o 277.316 j‡ ter‹o o bloco 277.315 como o topo de suas corrente principal e, portanto, vincular‹o o bloco novo e estender‹o a corrente. Ës vezes, como n—s veremos em Forks (bifurca•›es) da Blockchain, Blockchain , o bloco novo estende um corrente que n‹o est‡ na corrente principal. Nesse caso, o nodo ir‡ anexar o bloco novo ˆ corrente secund‡ria que ele estende e ent‹o ir‡ comparar a dificuldade da corrente secund‡ria com a dificuldade da corrente principal. Se a corrente secund‡ria possuir uma dificuldade acumulada maior do que a da corrente principal, o nodo ir‡ convergir novamente para a corrente secund‡ria, ou seja, ele ir‡ selecionar a corrente secund‡ria como sua nova corrente principal, fazendo com que a corrente principal anterior se torne uma corrente secund‡ria. Se o nodo for um minerador, ele ir‡ construir um bloco ao estender essa corrente nova, que Ž mais longa. Se um bloco v‡lido Ž recebido e nenhum pai Ž encontrado na correntes existentes, o bloco Ž considerado um "—rf‹o". Os blocos —rf‹os s‹o salvos no pool de blocos —rf‹os, onde eles ficam atŽ que o seus pais sejam recebidos. Assim que o bloco pai Ž recebido e vinculado ˆs correntes existentes, o bloco —rf‹o pode ent‹o sair do pool e ser vinculado a seu bloco pai, passando a fazer parte da corrente. Os blocos —rf‹os geralmente surgem quando dois blocos que foram minerados em um curto espa•o de tempo s‹o recebidos em ordem inversa, ou seja, o bloco filho Ž recebido antes do bloco pai. Como selecionam a corrente com mais dificuldade, todos os nodos acabam atingindo um consenso
32
disseminado na rede. As discrep‰ncias tempor‡rias entre as correntes acabam sendo resolvidas ˆ medida que se adiciona mais prova-de-trabalho, estendendo uma das poss’veis correntes. Os nodos mineradoress "votam" com seu poder de minera•‹o ao escolher qual corrente eles ir‹o estender atravŽs mineradore da minera•‹o do pr—ximo bloco. Ao minerar um bloco novo e estender a corrente que eles escolheram, os mineradores est‹o votando nessa corrente. Na pr—xima se•‹o iremos ver como discrep‰ncias entre cadeias em competi•‹o (forks) s‹o resolvidas atravŽs da sele•‹o independente da cadeia de maior dificuldade.
Forks (bifurca•›es) da Blockchain Como a blockchain Ž uma estrutura de dados descentralizada, descentralizada, as diferentes c—pias dela n‹o s‹o sempre iguais. Os blocos podem chegar em diferentes nodos em momentos diferentes, fazendo com que os nodos tenham diferentes perspectivas da blockchain. Para resolver isso, cada nodo sempre seleciona e tenta estender a corrente de blocos que representa a maior prova de trabalho, tambŽm conhecida como a corrente mais longa, ou a corrente com a maior dificuldade acumulada. Ao somar a dificuldade registrada em cada bloco de uma corrente, um nodo pode calcular a quantia total da prova de trabalho que foi despendida para criar aquela corrente. Enquanto todos os nodos selecionarem a corrente mais longa, que tem a maior dificuldade acumulada, a rede global do bitcoin ir‡ convergir para um estado consistente, onde as diferentes c—pias s‹o iguais. As bifurca•›es ocorrem devido a inconsistncias tempor‡rias entre as vers›es da blockchain, que s‹o acabam sendo resolvidas com a reconvergncia, ˆ medida que mais blocos s‹o adicionados a uma das ramifica•›es da bifurca•‹o. Nos pr—ximos diagramas, n—s iremos ver como ocorre o evento de uma "bifurca•‹o" ao longo da rede. O diagrama Ž uma representa•‹o simplificada do bitcoin como uma rede global. Na verdade, a topologia da rede bitcoin n‹o Ž organizada geograficamente. Ao invŽs disso, ela forma uma rede em malha de nodos interconectados, que podem estar localizados geograficamente muito longe uns dos outros. A representa•‹o de uma topologia geogr‡fica Ž uma simplifica•‹o usada com o objetivo de ilustrar uma bifurca•‹o. Na rede bitcoin verdadeira, a "dist‰ncia" entre os nodos Ž medida em "saltos" ("hops") de um nodo para o outro, e n‹o em sua localiza•‹o f’sica. Para fins ilustrativos, diferentes blocos s‹o exibidos como cores diferentes, espalhados ao longo da rede e colorindo as conex›es que eles cruzam. No primeiro diagrama (Visualiza•‹o ( Visualiza•‹o de um evento de bifurca•‹o da blockchainÑantes da bifurca•‹o ), a rede possui uma perspectiva unificada da blockchain, com o bloco azul sendo o topo da cadeia principal.
33
Figure 2. Visualiza•‹o Visualiza•‹o de um evento de bifurca•‹o da blockchainÑa blockchainÑantes ntes da bifurca•‹o
Uma "bifurca•‹o" ocorre sempre que houver dois blocos candidatos competindo para formarem a blockchain mais longa. Isso ocorre sob condi•›es normais sempre que dois minerados resolvem o algoritmo de prova de trabalho com uma diferen•a de tempo muito pequena. Quando ambos os mineradores descobrem uma solu•‹o para seus respectivos blocos candidatos, eles imediatamente transmitem o seu bloco "vencedor" para seus vizinhos imediatos que come•am a propagar o bloco pela rede. Cada nodo que recebe um bloco v‡lido ir‡ incorpor‡-lo ˆ sua blockchain, estendendo a blockchain em um bloco. Se aquele nodo descobrir mais tarde outro bloco candidato estendendo o mesmo bloco pai, ele conectar‡ o segundo candidato em uma corrente secund‡ria. Como resultado, alguns nodos ir‹o "enxergar" um bloco candidato primeiro, enquanto outros nodos ir‹o enxergar o outro bloco candidato, surgindo duas vers›es concorrentes da blockchain. Em Visualiza•‹o de um evento de bifurca•‹o da blockchain: dois blocos s‹o encontrados simultaneamente,, n—s podemos ver dois mineradores que mineram dois blocos diferentes quase que simultaneamente simultaneamente. Esses dois blocos s‹o filhos do bloco azul, e s‹o destinados a estender a cadeia ao serem adicionados no topo do bloco azul. Para facilitar o nosso acompanhamento, um deles Ž visualizado como um bloco vermelho se originando do Canad‡, e o outro Ž marcado como um bloco verde se originando da Austr‡lia. Vamos assumir, por exemplo, que um minerador no Canad‡ encontra uma solu•‹o de prova de trabalho para um bloco "vermelho" que estende a blockchain, sendo adicionado no topo do bloco pai "azul". Quase simultaneamente, um minerador australiano que tambŽm est‡ estendendo o bloco "azul" encontra uma solu•‹o para o bloco "verde", o seu bloco candidato. Agora, existem dois blocos poss’veis, um "vermelho", se originando no Canad‡, e outro "verde", se originando na Austr‡lia. Ambos os blocos s‹o v‡lidos, ambos os blocos contŽm uma solu•‹o v‡lida para a prova de trabalho e ambos os blocos estendem o mesmo pai. Provavelmente a maioria das transa•›es de ambos os blocos Ž semelhante, com apenas algumas diferen•as na ordem das transa•›es.
34
Figure 3. Visualiza•‹o Visualiza•‹o de um evento de bifurca•‹o da blockchain: blockchain: dois dois blocos s‹o encontrados encontrados simultaneamente
Ë medida que os dois blocos s‹o propagados, alguns nodos recebem o bloco "vermelho" antes e alguns recebem o bloco "verde" antes. Como demonstrado em Visualiza•‹o de um evento de bifurca•‹o da blockchain: dois blocos s‹o propagados, dividindo a rede , a rede se bifurca em duas perspectivas diferentes da blockchain, um lado coberto com um bloco vermelho, e outro lado coberto com um bloco verde.
Figure 4. Visualiza•‹o Visualiza•‹o de um evento de bifurca•‹o da blockchain: blockchain: dois dois blocos s‹o propagados, propagados, dividindo a rede
35
A partir desse momento, os nodos da rede bitcoin que estiverem mais pr—ximos (topologicamente, e n‹o geograficamente) ao nodo canadense ir‹o ficar sabendo sobre o bloco "vermelho" antes e ir‹o criar uma nova blockchain com a maior dificuldade acumulada, que tem o bloco "vermelho" como œltimo bloco na corrente (por exemplo, azul-vermelho), ignorando o bloco candidato "verde" que chegar um pouco depois. Enquanto isso, os nodos mais pr—ximos do nodo australiano ir‹o considerar aquele bloco como o vencedor e ir‹o estender a blockchain com o bloco "verde" como o œltimo bloco (por exemplo, azul-verde), ignorando o bloco candidato "vermelho" quando ele chegar alguns segundos depois. Qualquer minerador que enxergar o bloco "vermelho" antes ir‡ imediatamente construir blocos candidatos que usam o "vermelho" como referncia para o pai, e come•ar‹o a tentar resolver a prova de trabalho para esses blocos candidatos. Por outro lado, os mineradores que aceitaram o bloco "verde" ir‹o come•ar a construir no topo do "verde", estendendo aquela corrente. As bifurca•›es quase sempre s‹o resolvidas em um bloco. Como parte do poder de hashing da rede Ž dedicado a construir no topo do "vermelho" como pai, outra parte do poder de hashing Ž focado em construir no topo do "verde". Mesmo que o poder de minera•‹o esteja dividido quase igualmente, Ž prov‡vel que um conjunto de mineradores ir‡ encontrar uma solu•‹o e propag‡-la antes que outro conjunto de mineradores tenha encontrado algumas solu•›es. Digamos que, por exemplo, os mineradores construindo no topo do "verde" encontra um novo bloco "rosa" que estende a corrente (por exemplo, azul-verde-rosa). Eles imediatamente propagam esse bloco novo e toda a rede o enxerga como uma solu•‹o v‡lida, como demonstrado em Visualiza•‹o de um evento de bifurca•‹o da blockchain: um novo bloco estende uma das bifurca•›es. bifurca•›es .
Figure 5. Visualiza•‹o Visualiza•‹o de um evento de bifurca•‹o da blockchain: blockchain: um novo bloco estende estende uma das bifurca•›es
Todos os nodos que escolheram o "verde" como vencedor na rodada anterior ir‹o simplesmente estender a corrente em mais um bloco. Os nodos que escolheram o "vermelho" como vencedor, entretanto, enxergar‹o agora duas correntes: azul-verde-rosa e azul-vermelho. A corrente azul-verde-
36
rosa agora Ž maior (mais dificuldade acumulada) do que a corrente azul-vermelho. Como resultado, aqueles nodos ir‹o definir a corrente azul-verde-rosa como a corrente principal e passar‹o a considrar a corrente azul-vermelha como sendo a corrente secund‡ria, como demonstrado em Visualiza•‹o de um evento de bifurca•‹o da blockchain: a rede reconverge em uma nova cadeia mais longa . Isso se chama de reconvergncia da corrente, pois aqueles nodos s‹o for•ados a revisar sua vis‹o da blockchain para incorporar a nova evidncia de uma corrente mais longa. Qualquer minerador que estiver trabalhando em estender a corrente azul-vermelho ter‡ que parar o trabalho porque o seu bloco candidato Ž um "—rf‹o", j‡ que o seu pai "vermelho" n‹o est‡ mais na corrente mais longa. As transa•›es contidas no "vermelho" s‹o enfileiradas novamente para processar o pr—ximo bloco, pois aquele bloco n‹o est‡ mais na corrente principal. Toda a rede reconverge para uma œnica blockchain azul-verde-rosa, com o "rosa" sendo o œltimo bloco na corrente. Todos os mineradores imediatamente come•am a trabalhar nos blocos candidatos que referenciam o "rosa" como seu pai, para estender a corrente azul-verde-rosa.
Figure 6. Visualiza•‹o Visualiza•‹o de um evento de bifurca•‹o da blockchain: blockchain: a rede rede reconverge em uma nova nova cadeia mais longa
ƒ teoricamente possivel que uma bifurca•‹o se estenda em dois blocos, se os dois blocos forem encontrados quase que simultaneamente por mineradores nos "lados" opostos da bifurca•‹o anterior. Entretanto, a chance disso acontecer Ž muito baixa. Enquanto uma bifurca•‹o de um bloco pode ocorrer semanalmente, uma bifucarca•‹o de dois blocos Ž extremamente rara. O intervalo de bloco de 10 minutos do bitcoin Ž um ajuste equilibrado entre tempos de confirma•‹o r‡pidos (liquida•‹o das transa•›es) e a probabilidade de uma bifurca•‹o. Um tempo de bloco mais r‡pido tornaria faria com que as transa•›es fossem liquidadas mais rapidamente, mas isso causaria bifurca•›es da blockchain mais frequentes, enquanto um tempo de bloco mais lento iria diminuir o nœmero de bifurca•›es, mas faria com que as transa•›es fossem liquidadas mais lentamente.
37
Minera•‹o e a Corrida do Hashing A minera•‹o do bitcoin Ž uma indœstria extremamente competitiva. O poder de hashing aumentou exponencialmente a cada ano de existncia do bitcoin. Em alguns anos o aumento do poder de hashing foi resultado de uma mudan•a completa na tecnologia de minera•‹o, como em 2010 e 2011, quando muitos mineradores deixaram de usar a minera•‹o com CPU (processadores comuns) e passaram a usar minera•‹o com GPU (placas de v’deo) e minera•‹o com arranjo de portas program‡vel em campo (FPGA). Em 2013, a introdu•‹o da minera•‹o com circuitos integrados de aplica•‹o especifica especifica (ASIC) foi mais um salto gigante no poder de minera•‹o, ao colocar a fun•‹o SHA256 diretamente no interior de chips de sil’cio constru’dos especialmente para o prop—sito de minera•‹o. O primeiro desses chips era capaz de fornecer, em uma pequena caixinha, um poder de minera•‹o maior do que o poder que toda a rede bitcoin tinha em 2010. A lista a seguir mostra o poder de hashing total da rede bitcoin, ao longo dos primeiros cinco anos de opera•‹o: 2009
0,5 MH/sÐ8 MH/s (crescimento de 16x) 2010
8 MH/sÐ116 GH/s (crescimento de 14.500x) 2011
16 GH/sÐ9 TH/s (crescimento de 562x) 2012
9 TH/sÐ23 TH/s (crescimento de 2.5x) 2013
23 TH/sÐ10 PH/s (crescimento de 450x) 2014
10 PH/sÐ150 PH/s em Agosto (crescimento de 15x) No diagrama em, n—s vemos que o poder de hashing da rede bitcoin aumento ao longo dos œltimos dois anos. Como voc pode ver, a competi•‹o entre os mineradores e o crescimento do bitcoin resultou em um aumento exponencial no poder de hashing (total de hashes por segundo ao longo da rede).
38
Figure 7. Poder de hashing hashing total, em gigahashes gigahashes por segundo, ao longo de dois anos anos
Ë medida que a quantidade de poder de hashing aplicado ˆ minera•‹o do bitcoin explodiu, a dificuldade cresceu para acompanh‡-la. A mŽtrica de dificuldade no gr‡fico mostrado em MŽtrica de dificuldade de minera•‹o do Bitcoin, ao longo de dois anos Ž medida como a raz‹o da dificuldade atual pela dificuldade m’nima (a dificuldade do primeiro bloco).
Figure 8. MŽtrica MŽtrica de dificuldade de minera•‹o minera•‹o do Bitcoin, Bitcoin, ao longo de de dois anos
Nos œltimos dois anos, os chips de minera•‹o ASIC se tornaram cada vez mais densos, se aproximando da tecnologia de ponta na fabrica•‹o em sil’cio, com um tamanho (resolu•‹o) de 22 nan™metros (nm). Atualmente, os fabricantes de ASIC est‹o tentando superar os fabricantes de chips de CPU, projetando chips com 16 nm, pois a rentabilidade dos mineradores est‡ fazendo com que essa indœstria se torne atŽ mais r‡pida do que a indœstria de inform‡tica. N‹o existem mais passos gigantes para se dar na minera•‹o em bitcoin, bitcoin, pois a indœstria atingiu o limite da Lei de Moore, que estipula estipula que a capacidade de computa•‹o ir‡ dobrar a cada 18 meses. Entretanto, o poder de minera•‹o da rede continua a avan•ar em um ritmo exponencial, ˆ medida que a corrida por chips de maior densidade Ž combinada
39
com uma corrida por data center de maior densidade, onde milhares desses chips podem ser empregados. Agora n‹o Ž mais uma quest‹o de quanta minera•‹o pode ser feita em um chip, mas quantos chips podem ser espremidos em um prŽdio, enquanto o prŽdio ainda Ž capaz de dissipar o calor e fornecer energia adequada.
A Solu•‹o do Nonce Extra Desde 2012, a minera•‹o do bitcoin evoluiu para resolver uma limita•‹o fundamental na estrutura do cabe•alho do bloco. No in’cio do bitcoin, um minerador podia encontrar um bloco ao ficar tentando descobrir o nonce atŽ que o hash resultante estivesse abaixo do alvo. Ë medida que a dificuldade cresceu, os mineradores frequentemente ciclavam por todos os 4 bilh›es de valores do nonce sem encontrar um bloco. Entretanto, isso foi facilmente resolvido ao se atualizar a estampa de tempo do bloco para contabilizar pelo tempo decorrido. Como a estampa de tempo faz parte do cabe•alho do bloco, essa mudan•a permitiu que os mineradores fizessem suas buscas pelo valor do nonce novamente com resultados diferentes. No entanto, quando o hardware de minera•‹o excedeu 4 GH/s, essa abordagem se tornou cada vez mais dif’cil, pois os valores do nonce se esgotavam em menos de um segundo. Ë medida que os equipamentos de minera•‹o ASIC come•aram a ampliar e exceder a taxa de hashes (TH/s), o software de minera•‹o precisou de mais espa•o para os valores de nonce. A estampa de tempo podia ser estendida um pouco, mas ficar empurrando-a muito para o futuro iria fazer com que o bloco se tornasse inv‡lido. O cabe•alho do bloco precisava de um novo lugar nele para ser usado como fonte para os valores de nonce. A solu•‹o foi usar a transa•‹o coinbase como uma fonte para valores extra de nonce. Como o script da coinbase pode armazenar entre 2 e 100 bytes de dados, os mineradores come•aram a usar esse espa•o como espa•o extra para o nonce, o que permitiu que eles explorassem uma faixa muito maior de valores de cabe•alhos de blocos, para encontrar blocos v‡lidos. A transa•‹o coinbase Ž inclu’da na ‡rvore de merkle, ou seja, qualquer mudan•a no script coinbase faz com que a raiz de merkle mude. Os 8 bytes extras do nonce, mais os 4 bytes do nonce "padr‹o" permitem aos mineradores explorarem um total de 2 96 (8 seguidos de 28 zeros) possibilidades por segundo sem ter que modificar a estampa de tempo. Se, no futuro, os mineradores conseguirem ciclar atravŽs de todas essas possibilidades, eles poder‹o ent‹o modificar a estampa de tempo. TambŽm h‡ mais espa•o no script da coinbase para futuras expans›es do espa•o extra de nonce.
Pools de Minera•‹o Nesse ambiente altamente competitivo, os mineradores individuais trabalhando sozinho (tambŽm conhecido como mineradores solo) n‹o tem chance de vencer. A probabilidade de um deles encontrar um bloco Ž t‹o baixa, que n‹o compensa os custos que eles ter‹o com eletricidade e hardware, ou seja, acaba virando uma aposta, como ganhar numa loteria. Nem mesmo o sistema de minera•‹o ASIC mais r‡pido Ž capaz de competir com os sistemas comerciais que empilham dezenas de milhares desses chips em galp›es pr—ximos de esta•›es de energia hidrelŽtrica. Os mineradores agora colaboram para formar pools de minera•‹o, agrupando o seu pode de hashing e compartilhando as recompensas entre os milhares de participantes da pool. Ao participar de uma pool, os mineradores recebem uma pequena cota da recompensa total, mas tipicamente s‹o recompensados diariamente, reduzindo as incertezas.
40
Vamos dar uma olhada em um exemplo espec’fico. Assuma que um minerador comprou hardware de minera•‹o com uma taxa de hashing combina de 6.000 gigahashes por segundo (GH/s), ou 6 TH/s. Em agosto de 2014, esse equipamento custava aproximadamente 10.000 d—lares. O hardware consome 3 kilowatts (kW) de eletricidade quando est‡ ligado, 72 kw-horas por dia, a um custo de 7 ou 8 d—lares por dia, em mŽdia. Na dificuldade atual do bitcoin, o minerador ser‡ capaz de minerar sozinho um bloco aproximadamente a cada 155 dias, ou a cada 5 meses. Se o minerador encontrar um œnico bloco nesse per’odo de tempo, a recompensa de 25 bitcoins, com a taxa de c‰mbio de 600 d—lares por bitcoin, iria resultar em um pagamento œnico de 15.000 d—lares, que ir‡ cobrir todos os custos do hardware e da eletricidade consumidos durante todo o per’odo de tempo, deixando um rendimento l’quido de cerca de 3.000 d—lares. Entretanto, a chance de encontrar um bloco em um per’odo de cinco meses depende da sorte do minerador. Ele pode encontrar dois blocos em cinco meses e ter um lucro muito grande. Ou ele pode n‹o encontrar nenhum bloco em 10 meses e ter preju’zo financeiro. Pior ainda, se a taxa de crescimento atual do poder de hashing se mantiver, a dificuldade do algoritmo de prova-detrabalho do bitcoin provavelmente ir‡ aumentar significativamente nesse per’odo, ou seja, o minerador ter‡, no m‡ximo, seis meses para equilibrar seus gastos com seu lucro, antes que o hardware esteja efetivamente obsoleto e tenha que ser substitu’do pode um hardware de minera•‹o mais poderoso. Se esse minerador participar de um pool de minera•‹o, ao invŽs de aguardar por uma chance œnica a cada cinco meses de ganhar 15.000 d—lares, ele ser‡ capaz de ganhar aproximadamente aproximadamente 500 a 750 d—lares por semana. Os pagamentos regulares do pool de minera•‹o o ajudar‹o a amortizar os custos do harware e da eletricidade ao longo do tempo, sem fazer com que ele assuma um risco enorme. O harware ainda estar‡ obsoleto em seis a nove meses, e o risco ainda ser‡ alto, mas pelo menos o rendimento ser‡ regular e confi‡vel naquele per’odo. Os pools de minera•‹o coordenam centenas a milhares de mineradores, atravŽs de protocolos especializados de minera•‹o em pool. Cada minerador configura o seu equipamento de minera•‹o para se conectar ao servidor do pool, ap—s criar uma conta no pool. O hardware de minera•‹o do minerador permanece conectado ao servidor do pool enquanto est‡ minerando, sincronizando seus esfor•os com os dos outros mineradores. Portanto, os mineradores do pool compartilham o esfor•o necess‡rio para minerar um bloco, e, ent‹o, comparilham as recompensas da minera•‹o. Os blocos com sucesso pagam a recompensa para um endere•o bitcoin da pool, ao invŽs de pagar individualmente para os mineradores. O servidor do pool far‡ pagamentos periodicamente para os endere•os bitcoin dos mineradores, assim que a sua cota da recompensa atingir um valor m’nimo. Tipicamente, o servidor do pool cobra uma taxa percentual das recompensas por fornecer o servi•o de minera•‹o em pool. Os mineradores que paricipam de uma pool dividem o trabalho de buscar uma solu•‹o para um bloco candidato, cada um deles ganhando "cotas" pela sua contribui•‹o com a minera•‹o. O pool de minera•‹o define um alvo de dificuldade menor para ganhar uma cota, tipicamente mais do que 1.000 vezes mais f‡cil que a dificuldade da rede bitcoin. Quando alguŽm do pool minera um bloco com sucesso, a recompensa Ž destinada ao pool e ent‹o Ž redistribu’da para todos os mineradores, de acordo com o nœmero de cotas que cada um deles contribuiu para o esfor•o coletivo. Qualquer minerador pode participar das pools, grande ou pequeno, amador ou profissional. Uma pool portanto ir‡ tem alguns participantes com uma œnica pequena m‡quina de minera•‹o, e outros com
41
uma garagem repleta de hardware de minera•‹o de œltima œlt ima gera•‹o. Alguns ir‹o minerar com algumas dezenas de kilowatts de eletricidade, outros ir‹o executar um data center consumindo um megawatt de energia. Como que a pool de minera•‹o quantifica as contribui•›es individuais, para que as recompensas sejam distribu’das de maneira justa, sem a possibilidade de trapa•as? A solu•‹o Ž usar o algoritmo de prova-de-trabalho do bitcoin para medir a contribui•‹o de cada minerador da pool, mas definir uma dificuldade menor, de maneira que atŽ mesmo os menores mineradores da pool ganhem uma cota com frequncia suficiente para que valha a pena contribuir para a pool. Ao definir uma dificuldade menor para se ganhar as cotas, a pool mede a quantidade de trabalho que Ž feita por cada minerador. Cada vez que um minerador da pool encontra um hash de cabe•alho de bloco que Ž menor do que a dificuldade da pool, ele comprova que ele fez o trabalho de hashing para encontrar esse resultado. Mais importante, o trabalho para encontrar as cotas contribui, de uma maneira que pode ser mensurada estatisticamente, para o esfor•o de toda a pool para encontrar um hash menor do que o alvo da rede bitcoin. Milhares de mineradores tentando encontrar hashes de valor baixo uma hora acabar‹o encontrado encontrado um baixo o suficiente que satisfa•a o alvo da rede bitcoin. Vamos voltar ˆ analogia do jogo de dados. Se os jogadores estiverem lan•ando os dados com o objetivo de tirar menos do que quatro (a dificuldade geral da rede), uma pool definiria um alvo mais f‡cil, contanto quantas vezes os jogadores da pool conseguiram tirar menos do que oito. Quando os jogadores da pool tirarem menos que oito (o alvo da cota da pool), eles ganham cotas, mas eles n‹o ganham o jogo porque eles n‹o atingiram o alvo do jogo (menos do que quatro). Os jogadores da pool ir‹o atingir o alvo mais f‡cil da pool muito mais frequentemente, frequentemente ganhando muitas cotas, mesmo que eles n‹o atinjam o alvo mais dif’cil de se ganhar o jogo. De vez em quando, um dos jogadores da pool ir‡ lan•ar dois dados combinados e ir‡ tirar menos do que quatro, fazendo com que a pool ven•a. Ent‹o, os ganhos podem ser distribu’dos para os jogadores da pool baseando-se nas cotas que eles ganharam. Apesar de o alvo de oito ou menos n‹o ser uma vit—ria, ele Ž uma maneira justa de se medir os lan•amentos de dados dos jogadores, e isso ocasionalmente produz um lan•amento menor do que quatro. De maneira semelhante, um pool de minera•‹o ir‡ definir uma dificuldade do pool que ir‡ garantir que um minerador individual do pool possa achar, com frequncia, os hashes dos cabe•alhos de bloco que s‹o menores do que a dificuldade do pool, ganhando cotas. De vez em quando, uma dessas tentativas ir‡ produzir um hash de cabe•alho de bloco que Ž menor do que o alvo da rede bitcoin, tornando-o um bloco v‡lido, e toda a pool ganhar‡. Pools gerenciadas
A maioria das pools de minera•‹o s‹o "gerenciadas", ou seja, existe uma companhia ou indiv’duo executando um servidor de pool. O dono do servidor da pool Ž chamado de operador da pool, e ele cobra dos mineradores uma taxa percentual dos lucros. O servidor da pool executa software especializado e um protocolo de minera•‹o em pool que coordena as atividades dos mineradores da pool. O servidor da pool Ž tambŽm conectado a um ou mais nodos completos de bitcoin e tem acesso direto ˆ c—pia completa do banco de dados da blockchain. Isso permite que o servidor da pool valide blocos e transa•›es em nome dos mineradores da pool, aliviando-os do fardo de se executar um nodo completo. Para os mineradores da pool, isso Ž uma considera•‹o importante, importante, pois um nodo completo exige um computador dedicado com pelo menos 15 a 42
20 GB de armazenamento permanente (disco r’gido) e pelo menos 2 GB de mem—ria (RAM). ALŽm disso, o software bitcoin sendo executado no nodo completo precisa ser monitorado, mantido e atualizado frequentemente. Qualquer per’odo de inatividade causado por uma falta de manuten•‹o ou falta de recursos ir‡ comprometer os rendimentos do minerador. Para muitos mineradores, a habilidade de minerar sem ter que executar um nodo completo Ž outro grande benef’cio de se associar a uma pool gerenciada. Os mineradores da pool se conectam ao servidor da pool usando um protocolo de minera•‹o como o Stratum (STM) (STM) ou o GetBlockTempla GetBlockTemplate te (GBT). Um Um padr‹o padr‹o mais antigo chamado GetWork (GWK) j‡ Ž obsoleto desde 2012, porque ele n‹o suporta de maneira f‡cil a minera•‹o em taxas de hash maiores que 4 GH/s. Tanto o protocolo STM quanto o GBT criam modelos de blocos que contŽm um modelo de um cabe•alho de bloco candidato. O servidor da pool constr—i um bloco candidato ao agregar as transa•›es, acrescentando uma transa•‹o coinbase (com espa•o extra de nonce), calculando a ‡rvore de merkle e vinculando ao hash do bloco anterior. O cabe•alho do bloco candidato Ž enviado para cada um dos mineradores da pool como um modelo. Cada minerador da pool minera o bloco modelo, em uma dificuldade menor do que a dificuldade da rede bitcoin, e envia quaisquer resultados de sucesso de volta ao servidor do pool para ganhar cotas. P2Pool
As pools gerenciadas criam a possibilidade de se trapacear o operador da pool, que pode direcionar os esfor•os da pool para transa•›es de duplo-gasto ou blocos inv‡lidos (ver Ataques de Consenso). Consenso ). AlŽm disso, os servidores de pool centralizados representam um ponto œnico de falha. Se o servidor da pool ficar inativo ou for lentificado por ataques de nega•‹o de servi•o (DoS), os mineradores da pool n‹o conseguem minerar. Em 2011, para resolver esses problemas causados pela centraliza•‹o, um novo mŽtodo de minera•‹o em pool foi proposto e implementado: a P2Pool Ž uma pool de minera•‹o pontoa-ponto, sem um operador central. A P2Pool funciona ao descentralizar as fun•›es do servidor de pool, implementando um sistema paralelo parecido com a blockchain chamado de corrente de cotas ("share chain"). Uma corrente de cotas Ž uma blockchain que Ž executada em uma dificuldade menor do que a blockchain do bitcoin. A corrente de cotas permite que os mineradores da pool colaborem em uma pool descentralizada, ao minerar as cotas na corrente de cotas em uma taxa de um bloco de cotas a cada 30 segundos. Cada um dos blocos na corrente de cotas registra uma cota proporcional de recompensa para os mineradores da pool que contribu’rem com o trabalho, recebendo as cotas do bloco de cotas anterior. Quando um dos blocos de cotas tambŽm atinge o alvo de dificuldade da rede bitcoin, ele Ž propagado e inclu’do na rede bitcoin, recompensando todos os mineradores da pool que contribu’ram com todas as cotas que precederam o bloco de cotas vencedor. Essencialmente, ao invŽs de ter um servidor de pool mantendo um registro das cotas e recompensas dos mineradores da pool, a corrente de cotas permite que todos os mineradores da pool mantenham um registro de todas as cotas utilizando um mecanismo de consenso descentralizado, semelhante ao mecanismo de consenso descentraliza descentralizado do do bitcoin. A minera•‹o em P2Pool Ž mais complexa do que a minera•‹o em pool porque ela exige que os mineradores da pool executem um computador dedicado com espa•o em disco, mem—ria e banda de internet suficientes para suportarem um nodo completo de bitcoin e o software do nodo da P2Pool. Os mineradores P2Pool conectam o seu hardware de minera•‹o ao seu nodo local de P2Pool, que simula 43
as fun•›es de um servidor pool ao enviar modelos de bloco para o hardware de minera•‹o. Os mineradoress do P2Pool constr—em seus pr—prios blocos candidatos, agregando as transa•›es da mesma mineradore maneira que os mineradores solo fazem, mas ent‹o ele mineram colaborativamente na corrente compartilhada. O P2Pool Ž uma abordagem h’brida que tem a vantagem de ter pagamentos muito mais detalhados do que a minera•‹o solo, mas sem dar muito controle ao operador da pool, como acontece nas pools gerenciadas. Recentemente, a participa•‹o em P2Pool aumentou significativamente, ˆ medida que a concentra•‹o de minera•‹o em pools de minera•‹o atingiram n’veis que geraram um temor de um ataque de 51% (ver Ataques de Consenso). Consenso ). A continua•‹o do desenvolvimento do protocolo P2Pool mantŽm a expectativa de remover a necessidade de se executar um nodo completo e, portanto, tornando a minera•‹o descentralizada descentralizada ainda mais f‡cil de se utilizar. Apesar de a P2Pool reduzir a concentra•‹o de poder dos operadores das pools de minera•‹o, ela Ž vulner‡vel a ataques de 51% contra a pr—pria cota da corrente. Uma ado•‹o muito maior da P2Pool n‹o resolve o risco que o bitcoin tem de sofrer um ataque de 51%. No entanto, a P2Pool torna o bitcoin mais robusto de maneira geral, como parte de um ecossistema de minera•‹o diversificado.
Ataques de Consenso O mecanismo de consenso do bitcoin Ž, pelo menos teoricamente, vulner‡vel a ataques de mineradores (ou pools) que tentarem usar o seu poder de hashing com finalidades desonestas ou destrutivas. Como n—s j‡ vimos, o mecanismo de consenso depende de se ter uma maioria de mineradores agindo honestamente por interesse pr—prio. Entretanto, se um minerador ou um grupo de mineradores conseguir atingir uma cota significativa de poder de minera•‹o, eles podem atacar o mecanismo de consenso, de maneira que comprometam a seguran•a e a disponibilidade da rede bitcoin. ƒ importante citar que os ataques de consenso s— podem afetar consensos futuros, ou, no m‡ximo, os mais recentes (dezenas de blocos). O registro do bitcoin se torna mais e mais imut‡vel ˆ medida que o tempo passo. Apesar de que, em teoria, uma bifurca•‹o pode ocorrer em qualquer profundidade, na pr‡tica, o poder computacional necess‡rio para se for•ar uma bifurca•‹o muito profunda Ž imenso, tornando os blocos antigos praticamente imut‡veis. Os ataques de consenso tambŽm n‹o afetam a seguran•a das chaves privadas e do algoritmo de assinatura (ECDSA). Um ataque de consenso n‹o Ž capaz de roubar bitcoin, gastar bitcoins sem assinaturas, redirecionar bitcoin ou modificar transa•›es antigas ou registros de posse. Os ataques de consenso s— s‹o capazes de afetar os b locos mais recentes e causar distœrbios de nega•‹o de servi•o na cria•‹o de blocos futuros. Um cen‡rio de ataque contra o mecanismo de consenso Ž chamado de "ataque de 51%". Nesse cen‡rio, um grupo de mineradores, controlando uma maioria (51%) do poder de hashing total da rede, conspira para atacar o bitcoin. Com a habilidade de minerar a maioria dos blocos, os mineradores atacantes podem gerar "bifurca•›es" deliberadas na blockchain, gerar transa•›es de duplo gasto ou executar ataques de nega•‹o de servi•o (DoS) contra endere•os ou transa•›es espec’ficas. Um ataque de bifurca•‹o/duplo gasto Ž um ataque onde o atacante faz com que blocos j‡ confirmados sejam invalidados ao fazer uma bifurca•‹o em um n’vel abaixo deles, com uma posterior reconvergncia em uma corrente alternativa. Com poder suficiente, um atacante pode invalidar seis ou mais blocos em
44
uma sequncia, invalidando transa•›es que antes eram consideradas imut‡veis (com seis confirma•›es). Note que o duplo gasto s— pode ser feito nas transa•›es do pr—prio atacante, para as quais o atacante pode produzir uma assinatura v‡lida. Fazer um duplo gasto da pr—pria transa•‹o Ž rent‡vel quando, ao invalidar uma transa•‹o, o atacante puder receber um pagamento irrevers’vel ou um produto sem ter que pagar por isso. Vamos examinar examinar um exemplo pr‡tico de um ataque de 51%. No primeiro cap’tulo, n—s analisamos uma transa•‹o entre Alice e Bob por uma x’cara de cafŽ. Bob, o dono da cafeteria, est‡ disposto a aceitar pagamentos pelas suas x’caras de cafŽ sem esperar por uma confirma•‹o (a inclus‹o da transa•‹o em um bloco minerado), porque o risco de um duplo gasto com uma x’cara de cafŽ Ž baixo se comparado com a convenincia de se oferecer um servi•o r‡pido ao consumidor. Isso Ž semelhante ˆ pr‡tica das cafeterias que aceitam pagamentos de cart‹o de crŽdito sem uma assinatura do cliente em valores abaixo de 25 d—lares, porque o risco de um reembolso de um pagamento com cart‹o de crŽdito Ž baixo, enquanto o custo de atrasar um transa•‹o para se obter uma assinatura Ž comparativamente maior. Em contraste, vender um item mais caro por bitcoins aumenta o risco de um ataque de duplo gasto, onde o comprador transmite uma transa•‹o competidora que gasta os mesmos inputs (UTXO) e cancela o pagamento do comerciante. Um ataque de duplo gasto pode ocorrer de duas formas: ou antes de uma transa•‹o ser confirmada, ou se o ataque utilizar uma bifurca•‹o da blockchain para desfazer v‡rios blocos. Um ataque de 51% permite que os atacantes fa•am duplos gastos de suas pr—prias transa•›es em uma nova corrente, portanto desfazendo a transa•‹o correspondente na corrente antiga. Em nosso exemplo, Mallory, um atacante malicioso, vai atŽ a galeria da Carol e compra um lindo tr’ptico de pinturas retratando o Satoshi Nakatomo como Prometeus. A Carol vende as pinturas "O Grande Fogo" para o Mallory por 250.000 d—lares em bitcoin. Ao invŽs de aguardar por seis ou mais confirma•›es da transa•‹o, a Carol embala e entrega as pinturas para o Mallory ap—s uma œnica confirma•‹o ter ocorrido. O Mallory tem um cœmplice, o Paul, que opera uma grande pool de minera•‹o, e o seu cœmplice faz um ataque de 51% 5 1% assim que a transa•‹o do Mallory Ž inclu’da em um bloco. O Paul direciona a pool de minera•‹o para reminerar a mesma altura de bloco em que est‡ o bloco contendo a transa•‹o do Mallory, substituindo o pagamento do Mallory para a Carol por uma transa•‹o que faz um duplo gasto do mesmo input do pagamento do Mallory. A transa•‹o de duplo gasto consome o mesmo UTXO e o paga de volta para a carteira do Mallory, ao invŽs de pagar para a Carol, essencialmente permitindo que o Mallory permane•a com os seus bitcoins. O Paul ent‹o direciona a pool de minera•‹o para minerar um bloco adicional, para tornar a corrente contendo a transa•‹o de duplo gasto maior do que a corrente original (causando uma bifurca•‹o abaixo do bloco contendo a transa•‹o do Mallory). Quando a bifurca•‹o da blockchain se resolver em favor da nova corrente (mais longa), a transa•‹o de duplo gasto substituir‡ o pagamento original ˆ Carol. A Carol agora est‡ sem as suas trs pinturas e tambŽm n‹o tem nenhum pagamento bitcoin. Durante toda essa atividade criminosa, os participantes da pool de minera•‹o do Paul permanecem sem estar cientes da tentativa de duplo gasto, pois a minera•‹o que eles fazem Ž automatizada e eles n‹o conseguem monitorar todas as transa•›es ou blocos. Para proteger contra esse tipo de ataque, um comerciante vendendo itens de alto valor deve esperar por pelo menos seis confirma•›es antes de entregar o produto ao comprador. Outra alternativa seria o comerciante usar uma conta de mœltiplas assinaturas como cau•‹o, novamente esperando por v‡rias confirma•›es ap—s que a conta cau•‹o receba os fundos. Quanto mais confirma•›es tiver a transa•‹o,
45
mais dif’cil ser‡ invalid‡-la com um ataque de 51%. Para itens de alto valor, o pagamento com bitcoin ainda ser‡ conveniente e eficiente mesmo que o comprador tenha que aguardar por 24 horas para a entrega, o que corresponderi c orresponderiaa a aproximadamente 144 confirma•›es. AlŽm de um ataque de duplo-gasto, o outro cen‡rio para um ataque de consenso Ž a nega•‹o de servi•o para participantes bitcoin espec’ficos (endere•os bitcoin espec’ficos). Um atacante com uma maioria de poder de minera•‹o pode simplesmente ignorar transa•›es espec’ficas. Se elas forem inclu’das em um bloco minerado por outro minerador, o atacante pode deliberadamente fazer uma bifurca•‹o e reminerar aquele bloco, novamente excluindo as transa•›es espec’ficas. Esse tipo de ataque pode resultar em uma nega•‹o de servi•o sustentada contra um endere•o ou conjunto de endere•os espec’ficos, que se manter‡ enquanto o atacante controlar a maioria do poder de minera•‹o. Apesar do nome, o cen‡rio de uma ataque de 51% n‹o exige um poder de hashing de 51%. De fato, esse ataque pode ser tentado com uma pequena porcentagem de poder de hashing. O limite de 51% Ž simplesmente o n’vel em que esse tipo de ataque tem sucesso quase garantido. Um ataque de consenso Ž basicamente um cabo-de-guerra para o pr—ximo bloco e o grupo "mais forte" tem maior probabilidade de vencer. Com menos poder de hashing, a probabilidade de sucesso Ž reduzida, pois outros mineradores controlam a gera•‹o de alguns blocos com o seu poder "honesto" de minera•‹o. Uma maneira de se olhar isso Ž que, quanto mais poder de hashing um atacante tem, mais longa ser‡ a ramifica•‹o da bifurca•‹o que ele poder‡ criar deliberadamente, mais blocos no passado recente ele poder‡ invalidar ou mais blocos no futuro ele poder‡ controlar. Grupos de pesquisa de seguran•a usaram modelos estat’sticos para alegar que v‡rios tipos de ataques de consenso j‡ s‹o poss’veis a partir de apenas 30% de poder de hashing. O aumento maci•o no poder de hashing total tornou o bitcoin imperme‡vel a ataques feitos por um minerador isolado. N‹o h‡ mais como um minerador solo controlar mais do que uma pequena percentagem do poder total de minera•‹o. Entretanto, a centraliza•‹o do controle causada pelas pools de minera•‹o trouxe o risco da existncia de ataques lucrativos sendo feitos pelo operador do pool de minera•‹o. O operador do pool de uma pool gerenciada controla a constru•‹o dos blocos candidatos e tambŽm controla as transa•›es que s‹o inclu’das nos blocos. Isso d‡ ao operador da pool o poder de excluir transa•›es ou acrescentar transa•›es de gasto duplo. Se esse abuso de poder for feito de uma maneira limitada e sutil, um operador de pool seria capaz de lucrar com um ataque de consenso, sem ser descoberto. Entretanto, nem todos os atacantes s‹o motivados pelo lucro. Um cen‡rio potencial de ataque seria um onde o atacante pretende derrubar a rede bitcoin sem que ele tenha a possibilidade de lucrar com esse ataque. Um ataque malicioso que tenha o objetivo de destruir o bitcoin iria exigir um investimento enorme e um planejamento secreto, mas poderia ser lan•ado por um atacante com muitos recursos financeiros, muito provavelmente patrocinado por um governo. Alternativamente, um atacante com muitos recursos financeiros poderia atacar o consenso do bitcoin ao acumular simultaneamente hardware de minera•‹o, comprometendo operadores de pool e atacando outras pools com nega•‹o de servi•o. Todos esses cen‡rios s‹o teoricamente poss’veis, mas se tornam cada vez menos pratic‡veis ˆ medida que o poder de hashing total da rede bitcoin continua a crescer exponencialmente. Sem dœvida, um ataque de consenso grave poderia arruinar a confi‰ncia no bitcoin a curto prazo, possivelmente causando uma queda significativa no pre•o. No entanto, a rede e o software bitcoin 46
est‹o evoluindo constantemente, e a comunidade bitcoin iria tomar medidas contr‡rias aos ataques de consenso, tornando o bitcoin mais fortalecido, protegido e robusto do que nunca.
47
Cadeias, Moedas e Aplica•›es Alternativas Bitcoin foi o resultado de 20 anos de pesquisa em sistemas distribu’dos e moedas, trazendo uma nova tecnologia revolucion‡ria: o mecanismo de consenso descentralizado baseado em prova de trabalho. Essa inven•‹o no nœcleo do bitcoin marcou o in’cio de uma onda de inova•›es em moedas, servi•os financeiros, economia, sistemas distribu’dos, sistemas de vota•‹o, administra•‹o corporativa e contratos. Neste cap’tulo iremos examinar muitos ramos das inven•›es do bitcoin e do blockchain: as cadeias alternativas, moedas e aplica•›es constru’das desde a introdu•‹o dessa tecnologia em 2009. Principalmente iremos olhar para as moedas alternativas, ou alt coins, que s‹o moedas digitais implementadas que usam o mesmo padr‹o de design que o bitcoin, mas com uma blockchain e uma rede completamente separadas separadas.. Para cada alt coin mencionada nesse cap’tulo, 50 ou mais n‹o ser‹o mencionadas, provocando gritos de raiva em seus criadores e f‹s. A proposta desse cap’tulo n‹o Ž avaliar ou qualificar as alt coins, ou mesmo mencionar as mais significativas baseando-se em alguma avalia•‹o subjetiva. Ao invŽs disso, n—s iremos destacar alguns exemplos que mostram a amplitude e variedade do ecosistema, mostrando a primeira de cada tipo de inova•‹o ou diferencia•‹o significativa. Alguns dos exemplos mais interessantes de alt coins s‹o de fato fracassos completos do ponto de vista monet‡rio. Isso talvez as torne ainda mais interessantes de se estudar e destaca o fato que esse cap’tulo n‹o Ž para ser usado como um guia de investimento. Com novas moedas sendo lan•adas a cada dia, seria imposs’vel n‹o deixar de falar de alguma moeda importante, talvez uma que mude a hist—ria. A taxa de inova•‹o Ž o que faz com que esse espa•o seja t‹o empolgante e garante que esse cap’tulo j‡ ser‡ incompleto e desatualizado assim que ele for publicado.
Uma Taxonomia de Moedas e Cadeias Alternativas O Bitcoin Ž um projeto de c—digo-aberto, e seu c—digo tem sido usado como a base para muitos outros projetos de software. A forma mais comum de software gerado a partir do c—digo-fonte do bitcoin s‹o moedas descentralizadas alternativas, ou alt coins, que usam os mesmos blocos de constru•‹o b‡sicos para implementar as moedas digitais. Existem v‡rias camadas de protocolos implementadas sobre a blockchain do bitcoin. Essas meta coins, meta chains ou apps de blockchai blockchain n usam a blockchain como uma plataforma de aplica•›es ou estendem o protocolo bitcoin ao adicionar camadas de protocolos. Alguns exemplos incluem Colored Coins, Mastercoin, NXT e Counterparty. Na pr—xima se•‹o, examinaremos algumas alt coins not‡veis, como a Litecoin, Dogecoin, Freicoin, Primecoin, Peercoin, Darkcoin e Zerocoin. Essas alt coins s‹o not‡veis por quest›es hist—ricas ou porque elas s‹o bons exemplos para um tipo espec’fico de inova•‹o de alt coin, e n‹o porque elas s‹o mais valiosas ou porque s‹o as "melhores" alt coins.
1
AlŽm das alt coins, existem v‡rias implementa•›es alternativas da blockchain que n‹o s‹o "moedas", que eu as chamo de alt chains. Essas alt chains implementam um algoritmo de consenso e um registro distribu’do como uma plataforma para contratos, registro de nomes e outras aplica•›es. As alt chains usam os mesmos blocos b‡sicos de constru•‹o e ˆs vezes tambŽm usam uma moeda ou um token como mecanismo de pagamento, mas sua proposta prim‡ria n‹o Ž ser moeda. N—s iremos apresender sobre a Namecoin e o Ethereum como exemplos de alt chains. Por fim, existem v‡rios aspirantes a bitcoin que oferecem moeda digital ou redes de pagamento digital, mas sem usar um registro descentralizada ou mecanismo de consenso baseado em prova de trabalho, como o Ripple e outros. Essas tecnologias n‹o-blockchain est‹o fora do ‰mbito desse livro e n‹o ser‹o tratadas nesse cap’tulo.
Plataformas Meta Coin Plataformas meta coin e meta chains s‹o camadas de software implementados no topo do bitcoin, seja implementando uma moeda-dentro-de-uma-moeda, ou uma sobrecamada de plataforma/protocolo dentro do sistema bitcoin. Essas camadas funcionais estendem o protocolo principal do bitcoin e adiciona funcionalidades e capacidade de codificar dados adicionais dentro das transa•›es e endere•os de bitcoin. As primeiras implementa•›es de meta coins (meta-moedas) usaram v‡rios hacks para adicionar metadados ˆ blockchain do bitcoin, tais como usar um endere•o bitcoin para codificar dados ou utilizar campos de transa•›es vazios (por ex: o campo sequncia de transa•‹o) para codificar metadados sobre a camada de protocolo adicional. J‡ que a introdu•‹o do opcode do script de transa•‹o OP_RETURN, as meta moedas s‹o capazes de gravar metadados mais diretamente na blockchain, e a maioria est‡ migrando para esse uso.
Colored Coins Colored coins ou Moedas Coloridas Ž um meta protocolo que superp›e a informa•‹o de pequenas
quantidades de bitcoin. Uma moeda "colorida" Ž uma quantidade de bitcoin que teve seu prop—sito redefinido para expressar expressar outro ativo. Imagine, por exemplo, pegar uma nota de R$1 e colocar um selo que diz "Esse Ž 1 certificado de a•›es de uma a•‹o da Acme Acme Ltda." Agora a nota de R$1 R$1 serve para dois prop—sitos: ƒ uma nota de dinheiro e tambŽm um certificado de a•›es. Como ela Ž mais valiosa como uma a•‹o, voc n‹o vai querer us‡-la para comprar bala, de forma que ela n‹o Ž mais œtil como dinheiro. Moedas coloridas funcionam da mesma forma, convertendo uma pequena e espec’fica quantidade de bitcoin em um certificado negoci‡vel que representa outro ativo. O termo "color" ou "cor" refere ˆ ideia de dar um significado especial atravŽs da adi•‹o de um atributo tal como uma cor Ñ Ž uma met‡fora, met‡fora, n‹o uma associa•‹o a uma cor real. real. N‹o h‡ cores nas moedas moedas coloridas. Moedas coloridas s‹o gerenciadas por carteiras especializadas que gravam e interpretam os metadados anexados aos bitcoins coloridos. Usando tal carteira, o usu‡rio ir‡ converter uma quantidade de bitcoins comuns para moedas coloridas ao adicionar uma etiqueta que possui um significado especial. Por exemplo, a etiqueta poderia representar certificados de a•›es, cupons, propriedades reais, commodities ou tokens colecion‡veis. Fica a critŽrio do usu‡rio de moedas coloridas designar e interpretar o significado da "cor" associada com moedas espec’ficas. Para colorir as moedas, o usu‡rio define o metadado associado, tal como o tipo de emiss‹o, se pode ser subdividida 2
ou n‹o. um s’mbolo e descri•‹o ou outra informa•‹o relacionada. Uma vez colorida, essas moedas podem ser compradas e vendidas, subdivididas e agregadas, alŽm de poder receber dividendos. As moedas coloridas tambŽm podem ser "descoloridas" ao se remover a associa•‹o especial e assim, ter seu valor novamente em bitcoin. Para demonstrar o uso das colored coins, n—s criamos um conjunto de 20 colored coins com o s’mbolo "MasterBTC" que representa cupons para uma c—pia gratuite desse livro demonstrado em [example_91].. Cada unidade de MasterBTC, representada por essas colored coins, agora pode ser vendida ou 1] doada para qualquer usu‡rio bitcoin com uma carteira compat’vel com colored-coins, que agora poder‡ transfer’-las para outros ou regast‡-las com a editora para receber uma c—pia gratuita desse livro. Esse exemplo das colored coins pode ser visto aqui aqui.. 1. O perfil de metadados metadados das colored coins coins registrado como um cupom cupom para uma c—pia gr‡tis do livro
{ "source_addresses": [ "source_addresses": "3NpZmvSPLmN2cVFw1pY7gxEAVPCVfnWfVD" ], "contract_url": "https://www.coinprism.inf "https://www. coinprism.info/asset/3NpZm o/asset/3NpZmvSPLmN2cVFw1p vSPLmN2cVFw1pY7gxEAVPCVfn Y7gxEAVPCVfnWfVD", WfVD", "name_short": "name_short ": "MasterBTC", "name": "Free copy of \"Masterin \"Masteringg Bitcoin\"", "issuer": "Andreas M. Antonopoulos" Antonopoulos",, "description": "descriptio n": "This token token is redeemable redeemable for a free free copy of the the book \"Mastering \"Mastering Bitcoin\"", "description_mime": "descriptio n_mime": "text/x-markd "text/x-markdown; own; charset=UTFcharset=UTF-8", 8", "type": "Other", "divisibility": "divisibili ty": 0, "link_to_website": "link_to_web site": false, "icon_url": null, "image_url":: null, "image_url" "version": "1.0" }
Mastercoin Masteroin Ž uma camada de protocolo sobre o bitcoin que d‡ suporte a uma plataforma para v‡rias aplica•›es que extendem o sistema bitcoin. Mastercoin usa a moeda MST como um token para conduzir transa•›es Mastercoin, mas n‹o Ž primariamente uma moeda. Ao invŽs disso, Ž uma plataforma para construir outras coisas, como moedas de usu‡rio, tokens de propriedade smart, meios descentralizados de troca de ativos, e contratos. Pense na Mastercoin como um protocolo em camada de aplica•‹o sobre a camada de transporte de transa•›es financeiras do bitcoin, da mesma forma que HTTP roda por cima do TCP.
3
A Mastercoin operada primariamente atravŽs de transa•›es enviadas de e para um endere•o bitcoin especial chamado de endere•o "exodus" 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P), da mesma maneira que o HTTP usa uma porta TCP espec’fica (porta 80) para diferenciar seu tr‡fego do resto do tr‡fego TCP. TCP. O protocolo Mastercoin est‡ gradualmente se transformando, deixando de usar endere•os endere•os exodus especializados e multi-assinaturas para usar o operador bitcoin OP_RETURN para codificar os metadados de transa•‹o.
Counterparty Counterparty Ž outra camada de protocolo implementada sobre o bitcoin. A Counterparty possibilita moedas de usu‡rios, tokens negoci‡veis, instrumentos financeiros, transa•›es descentralizadas de ativos e outras funcionalidades. A Counterpary Ž implementada primariamente usando o operador OP_RETURN na linguagem de script do bitcoin para registrar metadados que aprimoram as transa•›es bitcoin com significados adicionais. A Counterparty usa a moeda XCP como um token para conduzir as transa•›es Counterparty.
Alt Coins A vasta maioria das alt coins s‹o derivadas do c—digo-fonte do bitcoin, tambŽm conhecidas como "forks" (bifurca•›es). Algumas s‹o implementadas do zero, baseando-se no modelo blockchain, mas sem utilizar nenhum c—digo-fonte do bitcoin. As alt coins e alt chains (leia mais na pr—xima se•‹o) s‹o implementa•›es separadas da tecnologia blockchain e ambas as formas usam sua pr—pria blockchain. Usamos termos diferentes para indicar que as alt coin s‹o primariamente usadas como moeda, enquanto as alt chain s‹o usadas para outras propostas, mas n‹o como moeda primariamente. Falando mais precisamente, o primeiro fork "alt" principal do c—digo do bitcoin n‹o foi uma alt coin, mas a alt chain Namecoin, que n—s iremos discutir na pr—xima se•‹o. Baseando-se na data de divulga•‹o, a primeira alt coin que foi uma bifurca•‹o (fork) do bitcoin apareceu em agosto de 2011; ela foi chamada de IXCoins. A IXCoin modificou alguns par‰metros do bitcoin, acelerando a cria•‹o da moeda ao aumentar a recompensa para 96 moedas por bloco. Em setembro de 2011, a Tenebrix foi foi lan•ada. A Tenebrix foi a primeira criptomoeda a implementar um algoritmo de prova-de-trabalho alternativo, um scrypt , um algoritmo originalmente projetado para refor•ar senhas (resistncia a ataques de for•a bruta). O objetivo da Tenebrix era fazer uma moeda que fosse resistente ˆ minera•‹o com GPUs e ASICs, ao usar um algoritmo com uso intenso de mem—ria. A Tenebrix n‹o teve sucesso como uma moeda, mas ela foi a base para a Litecoin, que obteve grande sucesso e disseminou centenas de clones. A Litecoin, alŽm de usar um script como algoritmo de prova-de-trabalho, tambŽm implementou um tempo de gera•‹o de blocos maior, com alvo de 2,5 minutos ao invŽs dos 10 minutos do bitcoin. A moeda resultante Ž aclamada como a "prata do bitcoin-ouro" e tem como objetivo ser uma moeda alternativa de peso leve (light-weight). Devido ao tempo de confirma•‹o mais r‡pido e o limite de moedas total de 84 milh›es, muitos adeptos do Litecoin acreditam que ela Ž mais adequada para opera•›es de varejo do que o bitcoin.
4
As alt coins continuaram a proliferar-se em 2011 e 2012, baseadas em bitcoin ou no Litecoin. Em 2013, existiam 20 alt coins disputando por uma posi•‹o no mercado. No final de 2013, esse nœmero explodiu para 200, com 2013 rapidamente se tornando o "ano das alt coins". O crescimento das alt coins continuou em 2014, com mais de 500 alt coins em existncia no momento que esse livro foi escrito. Mais de metade das alt coins atuais s‹o clones do Litecoin. Criar uma alt coin Ž f‡cil, por isso existem agora mais de 500 delas. A maioria das alt coins diferem muito pouco do bitcoin e n‹o oferecem nada que mere•a um estudo. Muitas s‹o de fato apenas tentativas de enriquecer seus criadores. Entre as c—pias baratas e os esquemas de pump-and-dump (aumentar o valor da moeda e depois vender), existem, entretando, algumas exce•›es not‡veis e inova•›es muito importantes. Essas alt coins usam abordagens radicalmente diferentes ou adicionam inova•‹o significativa ao padr‹o de projeto do bitcoin. Existem E xistem trs ‡reas principais nas quais essas alt coins se diferenciam do bitcoin: ¥ Pol’t Pol’tica ica monet monet‡ria ‡ria dife diferente rente ¥ Meca Mecanismo nismo de consenso consenso ou de prova prova de trabalho trabalho difere diferente nte ¥ Car Caracter acter’stica ’sticass espec’ficas, espec’ficas, como forte anonimidad anonimidadee Para maiores informa•›es, veja esse gr‡fico de linha do tempo das alt coins e alt chains. chains .
Avaliando uma Alt Coin Com tantas alt coins dispon’veis, como alguŽm pode decidir quais s‹o merecedoras de aten•‹o? ALgumas alt coins tentam conseguir distribui•‹o ampla e uso como moedas. Outras s‹o laborat—rios para experincias com recursos e modelos monet‡rios diferentes. Muitas s‹o apenas esquemas para enriquecimento r‡pido de seus criadores. Para avaliar alt coins, eu analiso suas caracter’sticas definidores e suas mŽtricas de mercado. Aqui est‹o algumas quest›es para se perguntar sobre o quanto uma alt coin se diferencia do bitcoin: ¥ A alt coin introdu introduzz uma inova•‹o inova•‹o signifi significativ cativa? a? ¥ A diferen•a Ž estimuladora estimuladora o suficiente para afastar afastar os usu‡rios do bitcoin? ¥ A alt coin coin se presta presta a um mercado de nicho ou aplica•‹o aplica•‹o interessantes? interessantes? ¥ A alt coin conseguir‡ conseguir‡ atrair mineradores suficientes para para ser protegida protegida contra ataques ataques de consenso? Aqui est‹o algumas mŽtricas de mercado e financeiras vitais para serem consideradas: ¥ Qual Ž a capitali capitaliza•‹ za•‹oo de mercado mercado total dessa dessa alt coin? coin? ¥ Quant Quantos os usu‡rios/ca usu‡rios/carteir rteiras as estima-se estima-se que a alt coin tenha? ¥ Quant Quantos os comercian comerciantes tes aceitam aceitam a alt alt coin? ¥ Quantas transa•›es transa•›es di‡rias di‡rias (volume) s‹o executadas executadas com a alt coin? ¥ Quant Quantoo valor Ž transfe transferido rido diaria diariamente mente??
5
Nesse cap’tulo, n—s iremos nos concentrar primariamente primariamente nas caracter’sticas tŽcnicas e no potencial de inova•‹o das alt coins representadas pelo primeiro conjunto de quest›es.
Alternativas de Par‰metro Monet‡rio: Litecoin, Dogecoin, Freicoin O Bitcoin possui alguns par‰metros monet‡rios que o fornecem caracter’sticas distintas de moeda de emiss‹o-fixa deflacion‡ria. Ele Ž limitado a 21 milh›es de unidades principais (ou 21 quadrilh›es de unidades menores), ele possui uma taxa de emiss‹o com decl’nio em progress‹o geomŽtrica e tem uma "frequncia card’aca" de um bloco a cada 10 minutos, que controla a velocidade de confirma•‹o das transa•›es e a gera•‹o da moeda. Muitas alt coins modificaram os par‰metros prim‡rios para obter pol’ticas monet‡rias diferentes. Entre as centenas de alt coins, alguns dos exemplos mais not‡veis incluem os seguintes. Litecoin
Uma das primeiras alt coins, lan•ada em 2011, a Litecoin Ž a segunda moeda digital de maior sucesso ap—s o bitcoin. Suas inova•›es prim‡rias foram o uso de script para o algoritmo de prova-de-trabalho (herdado do Tenebrix) e seus par‰metros de moeda mais r‡pidos/leves. ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 2,5 2,5 minutos minutos ¥ To Total tal de moedas moedas:: 84 milh›es milh›es de moedas moedas em em 2140 ¥ Algo Algoritmo ritmo de consenso consenso:: Prova de trabalh trabalhoo Scrypt ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $160 milh›es milh›es na metade metade de 2014 Dogecoin
A Dogecoin foi lan•ada em Dezembro de 2013, baseada em um fork da Litecoin. A Dogecoin Ž not‡vel porque ela possui uma pol’tica monet‡ria de r‡pida emiss‹o e um limite de moedas muito alto, para estimular o gasto e as doa•›es. A Dogecoin tambŽm Ž not‡vel porque ela come•ou como uma piada, mas se tornou bastante popular, com uma comunidade numerosa e ativa, antes de diminuir rapidamente em 2014. ¥ Te Tempo mpo de gera gera•‹o •‹o de bloco: bloco: 60 segund segundos os ¥ To Total tal de moedas: moedas: 100.000.000. 100.000.000.000 000 (100 bilh›es) bilh›es) de Doge Doge em 2015 ¥ Algo Algoritmo ritmo de consenso consenso:: Prova de trabalh trabalhoo Scrypt ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $12 milh›es milh›es na metade metade de 2014 Freicoin
Freicoin foi introduzida em julho de 2012. Ela Ž uma moeda demurrage, o que significa que ela tem uma taxa de juros negativa para o valor armazenado. O valor guardado na Freicoin Ž deduzido de uma taxa APR de 4,5%, para encorajar o consumo e desencorajar a acumula•‹o de dinheiro. A Freicoin Ž not‡vel por implementar uma pol’tica monet‡ria que Ž o oposto exato da pol’tica deflacion‡ria do Bitcoin. A Freicoin n‹o experimentou sucesso enquanto moeda, mas Ž um exemplo intessante da
6
variedade de pol’ticas monet‡rias que podem ser expressadas por alt coins. ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 10 minutos minutos ¥ To Total tal de moedas moedas:: 100 milh›es milh›es de moedas moedas em em 2140 ¥ Algo Algoritmo ritmo de consenso consenso:: Prova de trabalh trabalhoo em SHA256 ¥ Capi Capitaliz taliza•‹o a•‹o de mercad mercado: o: $130.000 na metade metade de 2014 2014
Inova•‹o no Consenso: Peercoin, Myriad, Blackcoin, Vericoin, Vericoin, NXT O mecanismo de consenso do Bitcoin Ž baseado em prova-de-trabalho usando o algoritmo SHA256. As primeiras alt coins introduziram scrypt como um algoritmo alternativo de prova de trabalho, como forma de tornar a minera•‹o mais amig‡vel a CPUs e menos sucet’vel a centraliza•‹o com ASICs. Desde ent‹o, inova•›es no mecanismo de consenso tm surgido num ritmo frenŽtico. V‡rias alt coins adotaram uma variedade de algoritmos tais como scrypt, scrypt-N, Skein, Groestl, SHA3, X11, Blake, e outros. Algumas alt coins combinam mœltiplos algoritmos para prova-de-trabalho. Em 2013, vimos a inven•‹o da alternativa ˆ prova-de-trabalho, chamada prova de participa•‹o, que forma a base de diversas alt coins modernas. Prova-de-trabalho Ž um sistema por meio do qual os atuais donos de uma moeda podem "comprometer" moeda como um colateral para aferimento de juros. Mais ou menos como um dep—sito garantido, os participantes podem reservar uma por•‹o de suas moedas possu’das, enquanto ganham um retorno do investimento em forma de novas moedas (emitidas como pagamento de juros) e taxas de transa•‹o. Peercoin
A Peercoin foi introduzida em agosto de 2012 e foi a primeira alt coin a usar um algoritmo h’brido de prova-de-trabalho prova-de-tra balho e proof-of-stake para emitir novas unidades da moeda. ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 10 minutos minutos ¥ To Total tal de de moedas moedas:: Sem Sem limite limite ¥ Algoritmo de consenso: (H’brido) (H’brido) proof-of-stake proof-of-stake com uma prova-de-trabalho prova-de-trabalho inicial ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $14 milh›es milh›es na metade metade de 2014 Myriad
Myriad foi introduzida em fevereiro de 2014 e Ž not‡vel porque usa, simultaneamente, cinco algoritmos diferentes de prova-de-trabalho (SHA256d, Scrypt, Qubit, Skein, or Myriad-Groestl), com dificuldades variadas para cada algoritmo dependendo da participa•‹o do minerador. A inten•‹o Ž tornar a Myriad imune a especializa•‹o e centraliza•‹o ASIC, e tambŽm muito mais resistente a ataques de consenso, porque mœltiplos algoritmos de minera•‹o precisariam ser atacados simultaneamente. ¥ Gera•‹o de de blocos: mŽdia de 30 segundos (alvo de 2,5 minutos atravŽs de algoritmo de minera•‹o) minera•‹o)
7
¥ To Total tal de unida unidades: des: 2 bilh›es bilh›es em 2024 ¥ Algoritmo de consenso: Multi-algoritmo de prova-de-tra prova-de-trabalho balho ¥ Capi Capitaliz taliza•‹o a•‹o de mercad mercado: o: $120.000 na metade metade de 2014 2014 Blackcoin
A Blackcoin foi apresentada em fevereiro de 2014 e utiliza um algoritmo de consenso de proof-of-stake. Ela tambŽm Ž not‡vel por ter introduzido "multipools", um tipo de pool de minera•‹o que pode alternar entre diferentes alt coins automaticamente, dependendo do lucro de cada. ¥ Te Tempo mpo de ger gera•‹o a•‹o do do bloco: bloco: 1 minuto minuto ¥ To Total tal de de moedas moedas:: Sem Sem limite limite ¥ Algo Algoritmo ritmo de de consenso: consenso: Proof-o Proof-of-sta f-stake ke ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $3,7 milh›es milh›es na metade metade de 2014 VeriCoin
A VeriCoin foi lan•ada em maio de 2014. Ela usa um algoritmo de consenso de proof-of-stake com uma taxa de juros vari‡vel que se ajusta dinamicamente baseada nas for•as da oferta e demanda do mercado. Ela tambŽm foi a primeira altcoin a apresentar convers‹o autom‡tica para bitcoin, para realiza•‹o de pagamentos em bitcoins a partir de sua carteira. ¥ Te Tempo mpo de ger gera•‹o a•‹o do do bloco: bloco: 1 minuto minuto ¥ To Total tal de de moedas moedas:: Sem Sem limite limite ¥ Algo Algoritmo ritmo de de consenso: consenso: Proof-o Proof-of-sta f-stake ke ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $1,1 milh‹o milh‹o na metade metade de 2014 NXT
NXT (pronunciado "Next") Ž uma alt coin de prova-de-participa•‹o "pura", no sentido de que n‹o usa minera•‹o para prova-de-trabalho. NXT Ž uma implementa•‹o de criptomoeda do zero, e n‹o uma deriva•‹o do bitcoin ou qualquer outra alt coin. NXT implementa muitas funcionalidades avan•adas, incluindo um registro de nomes (similar a Namecoin), um meio de troca de ativos descentralizado (similar ˆs Colored Coins), tendo integrada mensageria descentralizada descentralizada e segura (similar a Bitmessage), e delega•‹o de participa•‹o (para delegar a prova-de-participa•‹o a outros). Adeptos da NXT a chamam de criptomoeda de "nova-gera•‹o" ou 2.0. ¥ Te Tempo mpo de ger gera•‹o a•‹o do do bloco: bloco: 1 minuto minuto ¥ To Total tal de de moedas moedas:: Sem Sem limite limite ¥ Algo Algoritmo ritmo de de consenso: consenso: Proof-o Proof-of-sta f-stake ke ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $30 milh›es milh›es na metade metade de 2014
8
Inova•‹o com Minera•‹o de Dupla-Proposta: Primecoin, Curecoin, Gridcoin O algoritmo de prova-de-trabalho do Bitcoin tem uma œnica proposta: trazer seguran•a ˆ rede bitcoin. Comparado com a seguran•a do sistema de pagamentos tradicional, o custo de minera•‹o n‹o Ž muito alto. Entretanto, ele foi criticado por muitos por ser pouco econ™mico. A gera•‹o seguinte de alt coins tentou trabalhar esse aspecto. Os algoritmos de prova-de-trabalho de dupla proposta resolve um problema "œtil" espec’fico, enquanto produzem prova de trabalho para trazer seguran•a ˆ rede. O risco de adicionar um uso externo ˆ seguran•a da moeda Ž que isso tambŽm adiciona influncia externa ˆ curva de oferta e demanda. Primecoin
A Primecoin foi anunciada em julho de 2013. Seu algoritmo de prova-de-trabalho busca por nœmeros primos, computando cadeias de Cunningham e nœmeros primos primos gmeos. Os nœmeros primos s‹o œteis para v‡rias disciplinas cient’ficas. A blockchain da Primecoin contŽm os nœmeros primos descobertos, logo produzindo um registro pœblico de descoberta cient’fica em paralelo ao registro pœblico das transa•›es. ¥ Te Tempo mpo de ger gera•‹o a•‹o do do bloco: bloco: 1 minuto minuto ¥ To Total tal de de moedas moedas:: Sem Sem limite limite ¥ Algortimo de consenso: Prova de trabalho com descoberta de cadeia de nœmeros nœmeros primos ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $1,3 milh›es milh›es na metade metade de 2014 Curecoin
A Curtecoin foi anunciada em maio de 2013. Ela combina um algoritmo de prova de trabalho com SHA256 associado a pesquisa de envolamento de prote’nas atravŽs do projeto Folding@Home. O enovelamento de prote’nas Ž uma simula•‹o computadorizada que exige muito poder computacional, que avalia as intera•›es bioqu’micas das prote’nas, sendo usada para descobrir novos alvos moleculares para medicamentos, que ser‹o usados para curar doen•as. ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 10 minutos minutos ¥ To Total tal de de moedas moedas:: Sem Sem limite limite ¥ Algoritmo de consenso: Prova de trabalho com pesquisa de enovelamento de prote’nas ¥ Capi Capitaliz taliza•‹o a•‹o de mercad mercado: o: $58.000 na metade metade de 2014 2014 Gridcoin
A Gridcoin foi introduzida em outubro de 2013. Ela substitui a prova-de-trabalho baseada em scripts por subs’dios ˆ participa•‹o em computa•‹o em grid aberta BOINC. BOINC-Berkeley Open Infrastructure for Network Computing - Ž um protocolo aberto para computa•‹o em grid voltada para pesquisa cient’fica, que permite aos participantes compartilhar seu tempo ocioso de ciclos de computa•‹o para uma vasta gama de computa•›es de pesquisa acadmica. Gridcoin usa BOINC como uma plataforma genŽrica de computa•‹o, ao invŽs de resolver problemas cient’ficos espec’ficos, tais
9
como nœmeros primos ou enovelamento de prote’nas. ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 150 150 segundos segundos ¥ To Total tal de de moedas moedas:: Sem Sem limite limite ¥ Algoritmo de Consenso: Consenso: Prova-de-trabalho Prova-de-trabalho (Proof-of-work) (Proof-of-work) com subs’dio de rede computacional computacional BOINC ¥ Capi Capitaliz taliza•‹o a•‹o de mercad mercado: o: $122.000 na metade metade de 2014 2014
Alt Coins focadas no Anonimato: CryptoNote, Bytecoin, Monero, Zerocash/Zerocoin, Darkcoin O Bitcoin frequentemente Ž caracterizado como uma moeda "an™nima". De fato, Ž relativamente f‡cil conectas as identidades das pessoas aos endere•os bitcoin e, usando an‡lise de dados, conectar os ednere•os uns aos outros para formar uma vis‹o geral dos h‡bitos de consumo de bitcoins de uma pessoa. V‡rias alt coins buscaram resolver essa quest‹o diretamente ao focar fortemente em anonimidade. A primeira dessas tentativas foi mais provavelmente a Zerocoin, um protocolo de metacoin para preservar a anonimidade no topo do bitcoin, introduzida como um papel no Simp—sio de Seguran•a e Privacidade IEEE de 2013. A Zerocoin ser‡ implementada como uma alt coin completamente separada chamada Zerocash, que ainda est‡ em desenvolvimento enquanto esse livro estava sendo escrito. Uma abordagem alternativa para o anonimato foi lan•ada com a CryptoNote em um paper publicado em outubro de 2013. A CryptoNote Ž uma tecnologia de base que Ž implementada por v‡rios forks de alt coin que ser‹o discutidos a seguir. AlŽm do Zerocash e das Cryptonotes, existem v‡rias outras moedas an™nimas independentes, como a Darkcoin, que usa endere•os stealth ou rearranjo de transa•›es para fornecer anonimato. Zerocoin/Zerocash
A Zerocoin Ž uma abordagem te—rica de anonimidade em moeda digital apresentada em 2013 por pesquisadores da Johns Hopkins. A Zerocash Ž uma implementa•‹o de alt-coin da Zerocoin que est‡ em desenvolvimento e ainda n‹o foi lan•ada. CryptoNote
A CryptoNote Ž uma alt coin de implementa•‹o de referncia que fornece a base para o dinheiro digital an™nimo. Ela foi introduzida em outubro de 2013. Ela foi projetada para ser bifurcada em v‡rias implementa•›es diferentes e possui um mecanismo embutido de reinicializa•‹o que a torna inutiliz‡vel como moeda por si s—. V‡r V‡rias ias alt coins surgiram a partir da CryptoNote, incluindo: Bytecoin (BCN), Aeon (AEON), Boolberry (BBR), duckNote (DUCK), Fantomcoin (FCN), Monero (XMR), MonetaVerde (MCN) e Quazarcoin (QCN). A CryptoNote tambŽm Ž not‡vel por ter sido uma implementa•‹o completamente nova de cripto-moeda, n‹o tendo sido uma bifurca•‹o do bitcoin. Bytecoin
Bytecoin foi a primeira implementa•‹o brotada da CryptNote, fornecendo uma moeda an™nima vi‡vel baseada na tecnologia CryptoNote. Bytecoin foi lan•ada em Julho de 2012. Perceba que havia 10
previamente uma alt coin chamada Bytecoin com o s’mbolo monet‡rio BTE, enquanto a Bytecoin derivada da CryptNote tem o s’mbolo BCN. Bytecoin usa o algoritmo de prova-de-trabalho Cryptonight, Cryptonight, que requer acesso a ao menos 2 MB de RAM por inst‰ncia, tornando-o inadequado para minera•‹o por GPU ou ASIC. Bytecoin herda assinaturas em anel, transa•›es irrastre‡veis, e anonimato resistente ˆ an‡lise do blockchain do CryptoNote. ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 2 minutos minutos ¥ To Total tal de moed moedas: as: 184 bilh›e bilh›ess de BCN BCN ¥ Algo Algoritmo ritmo de consenso: consenso: Prova de trabalh trabalhoo Cryptonight Cryptonight ¥ Capi Capitaliz taliza•‹o a•‹o de mervado mervado:: $3 milh›es na metade metade de 2014 Monero
A Monero Ž uma outra implementa•‹o do CryptoNote. Ela possui uma curva de emiss‹o levemente mais achatada que a Bytecoin, emitindo 80% da moeda em seus primeiros quatro anos. Ela oferece as mesmas caracter’sticas de anonimato herdadas da CryptoNote. ¥ Te Tempo mpo de ger gera•‹o a•‹o do do bloco: bloco: 1 minuto minuto ¥ To Total tal de moed moedas: as: 18,4 milh›e milh›ess de XMR XMR ¥ Algo Algoritmo ritmo de consenso: consenso: Prova de trabalh trabalhoo Cryptonight Cryptonight ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $5 milh›es milh›es na metade metade de 2014 Darkcoin
A Darkcoin foi lan•ada em janeiro de 2014. Ela implementa uma moeda an™nima usando um protocolo de mistura de moedas em todas as transa•›es, chamado de DarkSend. O Darkcoin tambŽm Ž not‡vel por usar 11 varia•›es varia•›es de diferentes fun•›es fun•›es hash (blake, bmw, bmw, groestl, jh, keccak, keccak, skein, luffa, cubehash, shavite, simd, echo) para o algoritmo de prova de trabalho. ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 2,5 2,5 minutos minutos ¥ To Total tal de moedas moedas:: M‡ximo M‡ximo de 22 milh›es milh›es de de DRK ¥ Algoritmo de de consenso: Prova de trabalho multi-algortimo e multi-varia•›es ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $19 milh›es milh›es na metade metade de 2014
Alt Chains n‹o-moedas Alt chains s‹o implementa•›es alternativas do padr‹o de design da blockchain, que n‹o s‹o primariamente utilizadas como moeda. Muitas incluem uma moeda, mas a moeda Ž usada como um token para alocar alguma outra coisa, como um recurso ou um contrato. A moeda, em outras palavras, n‹o Ž o ponto principal da plataforma; ela Ž uma funcionalidade secund‡ria.
11
Namecoin Namecoin foi o primeiro fork no c—digo bitcoin. Namecoin Ž um registro descentralizado de valor e plataforma de transferncia usando a blockchain. Ela suporta um registro global de nome de dom’nio similar ao sistema de registro de nome de dom’nio na Internet. Namecoin Ž atualmente usada como um servi•o de nome de dom’nio (DNS) alternativo, para o dom’nio de n’vel raiz .bit. Namecoin tambŽm pode ser usado para registrar nomes e pares de valores-chave em outros namespaces; para armazenar coisas como endere•os de email, chaves de encripta•‹o, certificados SSL, assinatura de arquivos, sistemas de vota•‹o, certificados de a•›es; e uma mir’ade de outras aplica•›es. O sistema Namecoin inclui a moeda Namecoin (s’mbolo NMC), que Ž usada para pagar taxas de transa•‹o pelo registro e transferncia de nomes. Nos pre•os atuais, a taxa para registrar um nome Ž 0,01 NMC ou aproxidamente US$0,01. Assim como no bitcoin, as taxas s‹o coletadas pelos mineradores namecoin. Os par‰metros b‡sicos do Namecoin s‹o os mesmos do bitcoin: ¥ Te Tempo mpo de gera gera•‹o •‹o do bloco: bloco: 10 minutos minutos ¥ To Total tal de moedas moedas:: 21 milh›es milh›es de NMC NMC em 2140 ¥ Algo Algoritmo ritmo de consenso consenso:: Prova de trabalh trabalhoo em SHA256 ¥ Capi Capitaliz taliza•‹o a•‹o de mercado: mercado: $10 milh›es milh›es na metade metade de 2014 Os nomes de espa•o da Namecoin n‹o s‹o restritos, e qualquer um pode usar qualquer nome de espa•o da maneira que quiser. Entretanto, alguns nomes de espa•o possui uma especifica•‹o acordada de maneira que quando ele Ž lido a partir da blockchain, o software a n’vel de aplica•‹o sabe como ler e processar a partir disso. Se ele for mal formado, ent‹o n‹o importa qual software voc user para ler a partir de um nome de espa•o espec’fico, ele ir‡ resultar em um erro. Alguns nomes de espa•o populares s‹o: ¥ d/ Ž o namespace namespace de nome nome de dom’nio dom’nio para para dom’nios dom’nios .bit .bit ¥ id/ Ž o namespace para armazenar armazenar identificadores identificadores de pessoa como endere•os de email, email, chaves PGP, PGP, etc. ¥ u/ Ž uma especifica•‹o especifica•‹o adicional, adicional, mais estruturada, estruturada, para para armazenar identidades (basead (basead em openspecs) O cliente Namecoin Ž muito semelhante ao Bitcoin Core, porque ele Ž derivado do mesmo c—digo fonte. Ap—s a instala•‹o, o cliente ir‡ baixar uma c—pia completa da blockchain Namecoin e ent‹o estar‡ pronto para requisitar e registrar nomes. Existem trs comandos principais: name_new
Solicitar ou prŽ-registrar um nome name_firstupdate
Registra um nome e torna pœblico o registro
12
name_update
Modifica os detalhes ou atualiza um registro de nome Por exemplo, para registrar o dom’nio mastering-bitcoin.bit, n—s usaremos o comando name_new, como demonstrado a seguir: $ namecoind name_new d/mastering-bitcoin d/mastering-bitcoin
[ ]
"21cbab5b1241c6d1a6ad70a2416b3124eb883ac38e423e5ff591d1968eb6664a", "a05555e0fc56c023"
O comando name_new registra uma reivindica•‹o no nome, ao criar um hash do nome com uma chave aleat—ria. As duas strings que retornam com o name_new s‹o o hash e a chave aleat—ria (a05555e0fc56c023 no exemplo anterior) que podem ser usadas para fazer o registro pœblico do nome. Uma vez que a reivindica•‹o foi registrada na blockchain da Namecoin, ela pode ser convertida para um registro pœblico com o comando name_firstupdate, ao fornecer-se a chave aleat—ria: $ namecoind name_firstupdate d/mastering-bitcoin d/mastering-bitcoin a05555e0fc56c023 "{"map": {"www": {"ip":"1.2.3.4"}}}}" b7a2e59c0a26e5e2664948946 b7a2e59c0a26 e5e2664948946ebeca1260985c ebeca1260985c2f616ba579e6b 2f616ba579e6bc7f35ec234b01 c7f35ec234b01
Esse exemplo ir‡ mapear o nome de dom’nio www.mastering-bitcoin.bit ao endere•o IP 1.2.3.4. O hash que retornou Ž o ID da transa•‹o que pode ser usado para seguir esse registro. Voc pode ver quais nomes est‹o registrados para voc ao executar o comando name_list: $ namecoind name_list
[ { "name" : "d/masterin "d/mastering-bitcoin", g-bitcoin", "value" : "{map: {www: {ip:1.2.3.4 {ip:1.2.3.4}}}}", }}}}", "address" : "NCccBXrRUah "NCccBXrRUahAGrisBA1BLPWQ AGrisBA1BLPWQfSrups8Geh", fSrups8Geh", "expires_in"" : 35929 "expires_in } ]
Os registros da Namecoin precisam ser atualizados a cada 36.000 blocos (aproximadamente 200 a 250
13
dias). O comando name_update n‹o possui taxas e portanto a renova•‹o de dom’nios na Namecoin Ž gratuita. Terceiros Terceiros podem fornecer o servi•o de administrar o registro, renova•‹o autom‡tica e update atravŽs de uma interface web, por uma pequena taxa. Com um servi•o sendo oferecido por terceiros, voc n‹o precisa rodar um cliente Namecoin, mas voc perde o controle independente de um registro de nome descentraliza descentralizado do oferecido pela Namecoin.
Ethereum Ethereum Ž um processamento de contrato em linguagem Turing completa e uma plataforma de execu•‹o baseada na blockchain. Ele n‹o Ž um clone do Bitcoin, mas sim uma implementa•‹o completamente independente tanto em estrutura quanto em design. Ethereum possui uma moeda interna chama ether , que Ž necess‡ria para pagar a execu•‹o dos contratos. A blockchain do Ethereum registra contratos, que s‹o expressos em uma linguagem Turing completa, que Ž de baixo-n’vel e com c—digos em bytes. Essencialmente, um contrato Ž um programa que roda em cada n— no sistema Ethereum. Contratos Ethereum podem armazenar dados, enviar e receber pagamentos em ether, armazenar ether e executar uma variedade infinita (da’ ser Turing completa) de a•›es comput‡veis, agindo como softwares agentes aut™nomos e descentralizados. Ethereum pode implementar sistemas bastante complexos que s‹o, de outra forma, implementados como alt-chains pr—prias. Por exemplo, o seguinte Ž um contrato de registro de nome estilo Namecoin escrito em Ethereum (ou, mais precisamente, escrito em linguagem de alto-n’vel que pode ser compilada para o c—digo Ethereum): if !contract.storage[msg.data[0]]: # A key ainda n ‹o foi pega? # Ent‹o pegue ela! contract.storage[msg.data contract.stor age[msg.data[0]] [0]] = msg.data[1] return(1) else: return(0) // Caso contr ‡rio, n‹o fazer nada
Futuro das Moedas O futuro das moedas criptogr‡ficas como um todo Ž ainda mais brilhante que o futuro do bitcoin. O bitcoin introduziu uma forma completamente nova de organiza•‹o e consenso descentralizado que desenvolveu centenas de inova•›es incr’veis. Essas inven•›es provavelmente afetar‹o amplos setores da economia, desde sistemas distribu’dos de cincia ˆ finan•a, economia, moedas, bancos centrais e administra•‹o corporativa. Muitas atividades humanas que antigamente exigiam institui•›es ou organiza•›es centralizadas para funcionar como pontos de autoridade ou confian•a agora podem ser descentralizada. A inven•‹o da blockchain e o sistema de consenso ir‡ reduzir significativamente o custo da organiza•‹o e coordena•›a em sistemas de grande escala, ao mesmo tempo que remover‡ oportunidades para concentra•‹o concentra•‹o de poder, corrup•‹o e capta•‹o regulat—ria.
14
A Seguran•a do Bitcoin Manter bitcoins de maneira segura Ž desafiador porque o bitcoin n‹o Ž a referncia abstrata de um valor, da mesma forma que Ž o saldo em uma conta banc‡ria. Em sua essncia, o Bitcoin Ž como dinheiro digital ou o ouro. Voc provavelmente j‡ escutou o ditado "A posse Ž 90% da lei". Bem, no mundo do bitcoin, a posse Ž 100% da lei. A posse das chaves para desbloquear o bitcoin Ž equivalente a posse de notas de dinheiro ou de uma barra de um metal precioso. Voc pode perd-las, esquecer onde as guardou, ser roubado ou dar acidentalmente uma quantia errada para outra pessoa. Em cada uma dessas situa•›es, da mesma maneira como se tivessem deixado cair notas de dinheiro na cal•ada, os usu‡rios n‹o tem a quem recorrer. Entretanto, o bitcoin possui capacidades que o dinheiro, o ouro e as contas banc‡rias n‹o tm. Como qualquer arquivo de computador, pode-se realizar um backup (c—pia de seguran•a) de uma carteira de bitcoin contendo suas chaves. Ela pode ser armazenada em mœltiplas c—pias, e atŽ mesmo impressa em papel para fazer um backup offline n‹o-digital. Voc n‹o pode fazer um backup das suas notas de dinheiro, de ouro ou de suas contas banc‡rias. O bitcoin Ž t‹o diferente de tudo que j‡ existiu, que tambŽm precisamos encarar sua seguran•a de uma maneira diferente daquela que j‡ estamos acostumados.
Princ’pios de Seguran•a O princ’pio fundamental do bitcoin Ž a descentraliza•‹ descentraliza•‹o o e isso traz implica•›es importantes para a sua seguran•a. Um modelo centralizado - como o dos bancos tradicionais e da redes de pagamento depende de controles de acesso e comprova•›es de seguran•a para manter o sistema livre de criminosos. Em compara•‹o, um sistema descentralizado como o bitcoin atribui a responsabilidade e o controle aos usu‡rios. Como a rede Ž baseada em prova de trabalho - e n‹o em controle de acesso - a rede pode ser aberta, n‹o exigindo criptografi criptografia a para o tr‡fego de bitcoins. Em uma rede de pagamentos tradicional, como o sistema de cart›es de crŽdito, o pagamento Ž openended porque o sistema j‡ contŽm o identificador privado do usu‡rio (o nœmero do cart‹o de crŽdito). Dessa forma, ap—s a cobran•a inicial, qualquer pessoa com acesso ao identificador pode repetidamente repetidamente sacar fundos e fazer cobran•as ao dono do cart‹o. Logo, a rede de pagamento deve ser criptografada em toda sua extens‹o (end-to-end) e deve garantir que nenhum bisbilhoteiro ou intermedi‡rios possam comprometer o tr‡fego de pagamento, quando em tr‰nsito ou quando estiver armazenado. Se um criminoso burlar o controle de acesso ao sistema, ele pode comprometer as transa•›es atuais e os tokens de pagamentos - que podem ser usados para criar novas transa•›es. Ou, pior ainda, quando os dados dos consumidores s‹o comprometidos, os consumidores s‹o expostos a roubo de identidade e devem tomar medidas para prevenir o uso fraudulento de suas contas comprometida comprometidas. s. Com o bitcoin, a hist—ria Ž completamente diferente. Uma transa•‹o transa•‹o bitcoin autoriza somente um valor espec’fico e somente para um destinat‡rio espec’fico, alŽm de n‹o poder ser forjada ou modificada. Ela n‹o revela nenhuma informa•‹o privada - como as identidades dos usu‡rios - e n‹o pode ser utilizada para autorizar pagamentos adicionais. Dessa forma, uma rede de pagamentos bitcoin n‹o precisa ser encriptada ou protegida de bisbilhoteiros. De fato, voc pode transmitir transa•›es em bitcoin usando
1
um canal pœblico aberto, como redes WiFi sem senha ou Bluetooth - sem comprometer a seguran•a da transa•‹o. O modelo de seguran•a descentralizado do bitcoin coloca muito poder nas m‹os dos usu‡rios. E com esse poder, vem a responsabilidade de manter o sigilo das chaves. Para a maioria dos usu‡rios isso n‹o Ž uma tarefa f‡cil, especialmente em dispositivos comuns como smartphones ou laptops conectados a internet. Embora o modelo descentralizado do bitcoin impe•a o tipo de comprometimento em massa observado com os cart›es de crŽdito, muitos usu‡rios n‹o s‹o capazes de guardar suas chaves com a devida seguran•a e, um a um, acabam sendo hackeados.
Desenvolvendo Sistemas Bitcoin de Maneira Segura O princ’pio mais importante para os desenvolvedores em bitcoin Ž a descentraliza•‹o. A maioria dos desenvolvedores s‹o acostumados com modelos de seguran•a centralizados e podem ter a tenta•‹o de aplicar estes modelos em seus aplicativos bitcoin, com resultados desastrosos. A seguran•a do Bitcoin depende do controle descentralizado das chaves e da valida•‹o independente das transa•›es - uma atribui•‹o dos mineradores. Se voc quiser alavancar a seguran•a do Bitcoin, precisa se assegurar que permane•a dentro do modelo de seguran•a do Bitcoin. Em termos simples: n‹o retire dos usu‡rios o controle de suas chaves e n‹o realize transa•›es fora da blockchain. Por exemplo, muitas das primeiras exchanges de bitcoin concentravam todos os bitcoins dos usu‡rios em uma œnica carteira "quente" que tinha as chaves armazenadas em um œnico servidor. Esse tipo de design retira o controle dos usu‡rios e centraliza o controle das chaves em um œnico sistema. Muitos destes sistemas foram hackeados, com consequncias desastrosas para seus consumidores. Outro erro comum Ž o de realizar transa•›es fora da blockchain, numa tentativa desastrada de reduzir taxas de transa•‹o ou de acelerar o processamento das transa•›es. Um sistema "fora da blockchain" geralmente grava as transa•›es em um ledger interno, centralizado e somente ocasionalmente realiza uma sincroniza•‹o com a blockchain do bitcoin. Essa pr‡tica, novamente, substitui a seguran•a descentralizada do bitcoin por uma abordagem propriet‡ria e centralizada. Quando as transa•›es s‹o realizadas fora da blockchain, os ledgers centralizados com pouca seguran•a podem ser falsificados, possibilitando que intrusos possam, sem chamar a aten•‹o, desviar fundos e esvaziar reservas. A menos que voc esteja preparado para investir pesado em seguran•a operacional, mœltiplas camadas de controle de acesso e auditorias (como os bancos tradicionais fazem), voc deveria pensar com muito cuidado antes de retirar os fundos do contexto de seguran•a descentralizada do Bitcoin. Mesmo que voc tenha condi•›es e disciplina para implementar um modelo de seguran•a robusto, este tipo de modelo apenas replica a fragilidade das redes financeiras tradicionais - infestadas por roubo de identidade, corrup•‹o e fraude. Para aproveitar o modelo œnico de seguran•a descentralizada do Bitcoin, voc deve evitar a tenta•‹o das arquiteturas centralizadas pois, apesar de serem familiares, acabam por fim subvertendo a seguran•a do Bitcoin.
A Raiz de Confian•a A arquitetura de seguran•a tradicional Ž baseada em um conceito conhecido como a raiz de confian•a, confian•a,
2
que Ž um nœcleo de confian•a usado como base para a seguran•a de todo o sistema ou aplica•‹o. A arquitetura de seguran•a Ž desenvolvida ao redor da raiz de confian•a atravŽs de uma sŽrie de c’rculos concntricos, como as camadas de uma cebola, estendendo a confian•a do centro para a periferia. Cada camada usa como suporte a camada interna de maior confian•a, usando controles de acesso, assinaturas digitais, criptografia e outros elementos de seguran•a. Conforme os sistemas de software se tornam mais complexos, aumenta a chance de eles possu’rem bugs, que podem torn‡-los vulner‡veis ˆ falhas de seguran•a. Como resultado, quanto mais complexo se torna um sistema de software, mais dif’cil se torna a tarefa de mant-lo seguro. O conceito da raiz de confian•a garante que a maior parte da confian•a seja depositada na parte menos complexa do sistema, ou seja, nas partes menos vulner‡veis do sistema, enquanto o software mais complexo Ž desenvolvido ao redor. Essa arquitetura de seguran•a Ž repetida em diferentes escalas, primeiro estabelecendo uma raiz de confian•a no interior do hardware de um sistema œnico, para depois estender essa raiz de confian•a no sistema operacional para servi•os de maior n’vel e, finalmente, atravŽs de mœltiplos servidores dispostos em camadas de c’rculos concntricos com diminui•‹o progressiva da confian•a. A arquitetura de seguran•a do Bitcoin Ž diferente. No Bitcoin, o sistema de consenso cria um ledger pœblico de confian•a que Ž completamente descentralizado. Uma blockchain corretamente validada usa o bloco gnese como a raiz de confian•a, construindo uma corrente de confian•a a partir deste bloco atŽ o mais atual. Os sistemas Bitcoin podem e devem usar a blockchain como sua raiz de confian•a. Ao projetar uma aplica•‹o bitcoin complexa que consiste em servi•os em diversos sistemas diferentes, voc deve examinar cuidadosamente a arquitetura de seguran•a de maneira a se assegurar do local onde a confian•a est‡ sendo depositada. Em œltima an‡lise, o œnico elemento que deve ser considerado explicitamente como confi‡vel Ž uma blockchain validada em sua totalidade. Se a sua aplica•‹o deposita confian•a em qualquer elemento que n‹o seja a blockchain, isso deveria ser motivo de preocupa•‹o, pois abre as portas para a vulnerabilidade. Um bom mŽtodo para avaliar a seguran•a da arquitetura de sua aplica•‹o Ž considerar cada componente individual e avaliar um cen‡rio hipotŽtico no qual este componente est‡ completamente comprometido e sob o controle de um usu‡rio mal intencionado. Considere cada componente de sua aplica•‹o, um a um, e avalie os impactos na seguran•a geral se este componente for comprometido. Se a sua aplica•‹o n‹o for mais segura com o comprometimento comprometime nto de um desses componentes, isso demonstra que voc depositou equivocadamente a confian•a nestes componentes. Uma aplica•‹o bitcoin sem vulnerabilidades deveria ser vulner‡vel somente a um comprometimento do mecanismo de consenso do bitcoin, significando que a sua raiz de confian•a Ž baseada no elemento mais forte da arquitetura de seguran•a do bitcoin. Os numerosos exemplos de bolsas de bitcoins que foram hackeadas servem de exemplo para enfatizar esse ponto, pois, mesmo com uma simples an‡lise superficial, identificar’amos que o projeto e arquitetura de seguran•a destes servi•os eram falhos. Estes servi•os usaram implementa•›es centralizadas que depositaram confian•a em mœltiplos componentes fora da blockchain do bitcoin, como carteiras quentes, bancos de dados de ledger centralizados, chaves de criptografia vulner‡veis e esquemas similares.
Melhores Pr‡ticas na Seguran•a do Usu‡rio Por milhares de anos, os seres humanos humanos tm feito uso de sistemas f’sicos de controle de seguran•a. seguran•a. Em compara•‹o, a seguran•a digital tem sido usada h‡ menos de 50 anos. Os sistemas operacionais
3
modernos usados para atividades gerais n‹o s‹o muito seguros e n‹o s‹o adequados para o armazenamento de dinheiro digital. Por estarem sempre conectados ˆ internet, nossos computadores est‹o constantemente expostos a amea•as externas. Eles rodam milhares de componentes de softwares desenvolvidos por centenas de programadores diferentes, os quais frequentemente possuem acesso irrestrito aos arquivos do usu‡rio. Um œnico bug ou c—digo malicioso em um œnico software, entre os milhares instalados em seu computador, pode ser suficiente para comprometer a seguran•a do que voc digita em seu teclado e de todos os seus arquivos, permitindo que criminosos roubem seus bitcoins armazenados em aplicativos de carteiras. Para complicar, o n’vel de manuten•‹o necess‡ria para manter o computador livre de v’rus e trojans Ž uma tarefa dif’cil para a grande maioria dos usu‡rios de computador. Apesar de dŽcadas de pesquisas e avan•os na seguran•a da informa•‹o, os ativos digitais lamentavelmente ainda s‹o vulner‡veis ˆ um advers‡rio determinado. Mesmo os sistemas mais restritos e protegidos, utilizados em companhias de servi•os financeiros, agncias de inteligncia e de defesa, s‹o frequentemente burlados. O Bitcoin cria ativos digitais que possuem valor intr’nseco, que podem ser roubados e transferidos para usu‡rios criminosos de maneira instant‰nea e irrevers’vel. Essa possibilidade criou um forte incentivo para a a•‹o de hackers. AtŽ recentemente, ap—s terem acesso a contas banc‡rias/cart›es de crŽdito, os hackers tinham que sacar, transferir ou lavar o dinheiro roubado. E, apesar da dificuldade crescente de se realizar estas atividades, elas continuam ocorrendo cada vez mais. O Bitcoin traz um novo aspecto a ser considerado nesse problema, pois agora o dinheiro roubado n‹o precisa mais ser lavado; Ž um valor intr’nseco contido em um ativo digital. Felizmente, o bitcoin tambŽm criou incentivos para o aperfei•oamento da seguran•a dos computadores. Se antigamente o risco de um computador ser comprometido era vago e indireto, com o bitcoin esse risco se torna claro Ž —bvio. O fato de manter bitcoins em um computador aumenta a conscientiza•‹o dos usu‡rios em manterem seus computadores mais seguros. Como resultado direto da prolifera•‹o e maior ado•‹o do bitcoin e outras moedas digitais, tem se observado uma evolu•‹o nas tŽcnicas de hacking e nas solu•›es de seguran•a. Em termos simples, agora os hackers tem um alvo muito tentador, enquanto os usu‡rios tm um bom motivo para se defenderem. Ao longo dos œltimos trs anos, como resultado direto da ado•‹o ao bitcoin, temos observado grandes inova•›es na ‡rea da seguran•a da informa•‹o, na forma de criptografia em hardware, armazenamento de chaves e carteiras de hardware, tecnologia de mœltiplas assinaturas e cust—dias (escrow) digitais. Nas pr—ximas se•›es n—s iremos examinar as melhores pr‡ticas para a seguran•a do usu‡rio.
Armazenamento F’sico de Bitcoins Como a maior parte dos usu‡rios ficam muito mais confort‡veis com seguran•a f’sica do que com seguran•a da informa•‹o, um mŽtodo muito efetivo para proteger bitcoins Ž convert-los para uma forma f’sica. As chaves de bitcoins nada mais s‹o do que longos nœmeros. Isso significa que elas podem ser armazenadas em uma forma f’sica, como, por exemplo, impressas em um papel ou gravadas em uma moeda de metal. Dessa maneira, manter a seguran•a das chaves torna-se t‹o simples quanto manter seguro um papel com chaves de bitcoin impressas. Um conjunto de chaves de bitcoin impressas em papel Ž chamado de "carteira em papel" (paper wallet), e existem muitas ferramentas
4
gratuitas que podem ser usadas para cri‡-las. Eu pessoalmente mantenho a grande maioria dos meus bitcoins (99% ou mais) armazenados em carteiras de papel, criptografadas com BIP0038, com mœltiplas c—pias trancadas em cofres. Manter bitcoins offline Ž conhecido como armazenamento frio frio (cold storage) e Ž uma das tŽcnicas de seguran•a mais efetivas. Em um sistema de armazenamento frio, as chaves s‹o geradas e armazenadas de maneira offline (sem nunca se conectar ˆ internet). As chaves s‹o armazenadas em papel (impressas) ou em uma m’dia digital, c omo um pendrive.
Carteiras em Hardware Em longo prazo, a seguran•a do bitcoin ter‡ cada vez mais a forma de carteiras em hardware ˆ prova de falsifica•‹o. Diferente dos smartphones ou computadores de mesa, a carteira de bitcoin em hardware possuem apenas um œnico prop—sito: armazenar bitcoins de forma segura. Com interfaces limitadas e sem o risco de comprometimento por softwares de mœltiplos prop—sitos, essas carteiras podem fornecer um n’vel alt’ssimo de seguran•a para os usu‡rios comuns, n‹o especialistas. Eu espero ver as carteiras de hardware se tornando o principal mŽtodo de armazenamento de bitcoins. Para conhecer um exemplo deste tipo de carteira, pesquise sobre a carteira Trezor Trezor..
Balanceando o Risco Embora a maioria dos usu‡rios se preocupe, com raz‹o, em evitar que seus bitcoins sejam roubados, existe um risco ainda maior. Arquivos de computador s‹o constantemente perdidos. Se eles contiverem bitcoins, a perda ser‡ muito mais dolorosa. Ao usar medidas de seguran•a para suas carteiras de bitcoin, os usu‡rios devem ter muito cuidado para n‹o exagerarem na prote•‹o e acabarem perdendo suas moedas. Em julho de 2011, uma conhecida organiza•‹o, respons‡vel por um projeto de divulga•‹o do bitcoin, perdeu quase 7.000 bitcoins. Ao tentar prevenir roubos, os donos da organiza•‹o implementaram implementaram mœltiplos backups (c—pias de seguran•a) criptografados. criptografados. Infelizmente, as chaves da criptografia acabaram sendo perdidas, inutilizando os backups e, assim, perdendo uma fortuna. Da mesma forma que enterrar dinheiro no meio do deserto, proteger demais seus bitcoins pode fazer com que voc nunca mais consiga ach‡-los.
Diversificando o Risco Voc carregaria todas as suas economias em notas de dinheiro guardadas na sua carteira? A maioria das pessoas consideraria isso imprudente, no entanto os usu‡rios de bitcoin frequentemente mantm todos os seus bitcoins em uma œnica carteira. Ao invŽs disso, os usu‡rios deveriam distribuir o risco de perd-los entre mœltiplas carteiras de bitcoin, de diferentes tipos. Usu‡rios prudentes mantŽm somente uma pequena por•‹o de seus bitcoins, talvez menos de 5%, em uma carteira online ou de smartphone, para us‡-los nas compras do dia-a-dia, como "trocados no bolso." O resto deveria ser dividido em diferentes formas de armazenamento, como em uma carteira em desktop e offline (armazenamento frio).
Mœltiplas Assinaturas e Governan•a Sempre que uma empresa ou pessoa armazena grandes quantidades de bitcoin, a op•‹o de usar endere•os com mœltiplas assinaturas deveria ser considerada. Esse endere•os multi-sig s‹o mais
5
seguros porque exigem mais de uma assinatura para que um pagamento seja realizado. Idealmente, as chaves usadas nas assinaturas devem ser armazenadas em diferentes locais e sob o controle de diferentes pessoas. Em um ambiente corporativo, por exemplo, as chaves deveriam ser geradas independentemente e guardadas por diferentes executivos da empresa, garantindo que nenhuma pessoa sozinha consiga comprometer as economias da empresa. Os endere•os com mœltiplas assinaturas tambŽm podem oferecer redund‰ncia, quando uma pessoa sozinha possuir mœltiplas chaves que s‹o armazenadas em diferentes locais.
Legado Uma importante considera•‹o sobre seguran•a frequentemente ignorada Ž a disponibilidade especialmente no contexto de invalidez, doen•a ou morte da pessoa que possui as chaves. Para evitar roubos, frequentemente os usu‡rios de bitcoin s‹o orientados a usarem senhas complexas e a manterem suas chaves em seguran•a, longe do alcance de terceiros. Infelizmente, essa pr‡tica torna quase imposs’vel a recupera•‹o dos bitcoins pela fam’lia do usu‡rio. Na maioria dos casos, as fam’lias dos usu‡rios sequer tem conhecimento da existncia de poupan•as feitas em moeda digital. Se voc tiver uma grande quantidade de bitcoins, considere a ideia de compartilhar detalhes de acesso com um familiar de confian•a ou com um advogado. Uma estratŽgia mais complexa para o seu legado pode ser obtida utilizando endere•os de mœltiplas assinaturas ou atravŽs de um planejamento de heran•a com um advogado especializado em ativos digitais.
Conclus‹o O bitcoin Ž uma tecnologia nova, complexa e sem precedentes. Com o passar do tempo, iremos desenvolver melhores ferramentas de seguran•a, bem como pr‡ticas que ser‹o mais f‡ceis de serem utilizadas por pessoas comuns, n‹o especialistas. Enquanto isso, os usu‡rios de bitcoin podem usar muitas das dicas discutidas nesse cap’tulo para aproveitarem uma experincia com bitcoins segura e livre de problemas.
6
Appendix A: Comandos do Bitcoin Explorer (bx) Uso: bx COMANDO [--help] Info: Os comandos bx s ‹o: address-decode address-embed address-encode address-validate base16-decode base16-encode base58-decode base58-encode base58check-decode base58check-encode base64-decode base64-encode bitcoin160 bitcoin256 btc-to-satoshi ec-add ec-add-secrets ec-multiply ec-multiply-secrets ec-new ec-to-address ec-to-public ec-to-wif fetch-balance fetch-header fetch-height fetch-history fetch-stealth fetch-tx fetch-tx-index hd-new hd-private hd-public hd-to-address hd-to-ec hd-to-public hd-to-wif 1
help input-set input-sign input-validate message-sign message-validate mnemonic-decode mnemonic-encode ripemd160 satoshi-to-btc script-decode script-encode script-to-address seed send-tx send-tx-node send-tx-p2p settings sha160 sha256 sha512 stealth-decode stealth-encode stealth-public stealth-secret stealth-shared tx-decode tx-encode uri-decode uri-encode validate-tx watch-address wif-to-ec wif-to-public wrap-decode wrap-encode Para maiores informa•›es, veja a p‡gina do Bitcoin Explorer e Explorer e a documenta•‹o do usu‡rio do Bitcoin Explorer.. Explorer
Exemplos de uso de comandos bx Vamos dar uma olhada em alguns exemplos usando comandos do Bitcoin Explorer para trabalharmos com chaves e endere•os: Gera um valor "semente" aleat—rio usando o comando seed, que usa o gerador de nœmeros aleat—rios
2
do sistema operacional. operacional. Passe a semente para o comando ec-new para gerar gerar uma nova chave privada. N—s salvaremos o output padr‹o no arquivo private_key:
$ bx seed | bx ec-new > private_key $ cat private_key 73096ed11ab9f1db613585795 73096ed11ab9 f1db6135857958ece7d73ea7c3 8ece7d73ea7c30862145bcc4bb 0862145bcc4bbc7649075de474 c7649075de474 Agora, gere a chave pœblica a partir da chave privada usando o comando ec-to-public. N—s passaremos o arquivo private_key no input padr‹o e salvaremos o output padr‹o do comando em um novo arquivo public_key:
$ bx ec-to-public < private_key > public_key $ cat public_key 02fca46a6006a62dfdd2dbb21 02fca46a6006 a62dfdd2dbb2149359d0d97a04 49359d0d97a04f430f12a7626d f430f12a7626dd409256c12be5 d409256c12be500 00 N—s podemos reformatar a public_key como um endere•o endere•o usando o comando ec-to-address. ec-to-address. N—s passamos a public_key no input padr‹o:
$ bx ec-to-addres ec-to-addresss < public_key 17re1S4Q8ZHyCP8Kw7xQad1Lr6XUzWUnkG Chaves geradas dessa maneira produzem uma carteira n‹o-determin’stica tipo-0. Isso significa que cada chave Ž gerada a partir de uma semente independente. Os comandos do Bitcoin Explorer tambŽm podem gerar chaves deterministicamente, deterministicamente, de acordo com o BIP0032. Nesse caso, uma chave "mestre" Ž criada a partir da semente e ent‹o Ž estendida deterministicamente para produzir uma ‡rvore de subchaves, resultando em uma carteira determin’stica tipo-2. Primeiro, usaremos os seed and comandos seed e hd-new para gerar uma chave mestre que ser‡ usada como a base para derivar uma hierarquia de chaves.
$ bx seed > seed $ cat seed eb68ee9f3df6bd4441a9feadec179ff1 $ bx hd-new < seed > master $ cat master xprv9s21ZrQH143K2BEhMYpNQ xprv9s21ZrQH 143K2BEhMYpNQoUvAgiEjArAVa oUvAgiEjArAVaZaCTgsaGe6LsA ZaCTgsaGe6LsAnwubeiTcDzd23 nwubeiTcDzd23mAoyizm9cApe mAoyizm9cApe51gNfLMkBqkYo 51gNfLMkBqkYo WWMCRwzfuJk8RwF1SVEpAQ N—s agora iremos usar o comando hd-private para gerar uma chave de "conta" dificultada e uma sequncia de duas chaves privadas no interior da conta.
3
$ bx hd-private --hard < master > account $ cat account xprv9vkDLt81dTKjwHB8fsVB5 xprv9vkDLt81 dTKjwHB8fsVB5QK8cGnzveChzS QK8cGnzveChzSrtCfvu3aMWvQa rtCfvu3aMWvQaThp59ueufuyQ8 Thp59ueufuyQ8Qi3qpjk4aKsb Qi3qpjk4aKsbmbfxwcgS8PYbg mbfxwcgS8PYbg oR2NWHeLyvg4DhoEE68A1n $ bx hd-private --index 0 < account xprv9xHfb6w1vX9xgZyPNXVgA xprv9xHfb6w1 vX9xgZyPNXVgAhPxSsEkeRcPHE hPxSsEkeRcPHEUV5iJcVEsuUEA UV5iJcVEsuUEACvR3NRY3fpGhc CvR3NRY3fpGhcnBiDbvG4Lgnd nBiDbvG4LgndirDsia1e9F3DW irDsia1e9F3DW PkX7Tp1V1u97HKG1FJwUpU $ bx hd-private --index 1 < account xprv9xHfb6w1vX9xjc8XbN4GN xprv9xHfb6w1 vX9xjc8XbN4GN86jzNAZ6xHEqY 86jzNAZ6xHEqYxzbLB4fzHFd6V xzbLB4fzHFd6VqCLPGRZFsdjsu qCLPGRZFsdjsuMVERadbgDbzi MVERadbgDbziCRJru9n6tzEWr CRJru9n6tzEWr ASVpEdrZrFidt1RDfn4yA3 A seguir usaremos o comando hd-public para gerar a sequncia correspondente de duas chaves pœblicas.
$ bx hd-public --index 0 < account xpub6BH1zcTuktiFu43rUZ2gX xpub6BH1zcTu ktiFu43rUZ2gXqLgzu5F3tLEeT qLgzu5F3tLEeTQ5t6iE3aQtM2V Q5t6iE3aQtM2VMTxMcyLN9fYHi MTxMcyLN9fYHiGhGpQe9QQYmq GhGpQe9QQYmqL2eYPFJ3vezHz L2eYPFJ3vezHz 5wzaSW4FiGrseNDR4LKqTy $ bx hd-public --index 1 < account xpub6BH1zcTuktiFx6CzhPbGj xpub6BH1zcTu ktiFx6CzhPbGjG3UYQ13WR16Cm G3UYQ13WR16CmtbPiagEKpEVtp tbPiagEKpEVtpyjshWyMaMV1cn yjshWyMaMV1cn7nUPUkgQHPVX 7nUPUkgQHPVXJVqsrA8xWbGQD JVqsrA8xWbGQD hohEcDFTEYMvYzwRD7Juf8 As chaves pœblicas tambŽm podem ser derivadas a partir de suas chaves privadas correspondentes ao utilizar-se o comando hd-to-public.
$ bx hd-private --index 0 < account | bx hd-to-public xpub6BH1zcTuktiFu43rUZ2gX xpub6BH1zcTu ktiFu43rUZ2gXqLgzu5F3tLEeT qLgzu5F3tLEeTQ5t6iE3aQtM2V Q5t6iE3aQtM2VMTxMcyLN9fYHi MTxMcyLN9fYHiGhGpQe9QQYmq GhGpQe9QQYmqL2eYPFJ3vezHz L2eYPFJ3vezHz 5wzaSW4FiGrseNDR4LKqTy $ bx hd-private --index 1 < account | bx hd-to-public xpub6BH1zcTuktiFx6CzhPbGj xpub6BH1zcTu ktiFx6CzhPbGjG3UYQ13WR16Cm G3UYQ13WR16CmtbPiagEKpEVtp tbPiagEKpEVtpyjshWyMaMV1cn yjshWyMaMV1cn7nUPUkgQHPVX 7nUPUkgQHPVXJVqsrA8xWbGQD JVqsrA8xWbGQD hohEcDFTEYMvYzwRD7Juf8 N—s podemos gerar um nœmero praticamente ilimitado de chaves em uma cadeia determin’stica, todas derivadas de uma œnica semente. Essa tŽcnica Ž usada em muitas aplica•›es de carteira para gerar chaves que podem ser usadas em back ups e restauradas com um valor œnico de semente. Isso Ž mais f‡cil do que ter que fazer back up de toda a carteira com todas suas chaves geradas aleatoriamente cada vez que uma nova chave for criada. A semente pode ser codificada usando o comando mnemonic-encode.
4
$ bx hd-mnemonic < seed > words adore repeat vision worst especially veil inch woman cast recall dwell appreciate A semente pode ent‹o ser decodificada usando o comando mnemonic-decode.
$ bx mnemonic-dec mnemonic-decode ode < words eb68ee9f3df6bd4441a9feadec179ff1 A codifica•‹o do mnem™nico pode facilitar a grava•‹o da semente e atŽ mesmo a recorda•‹o dela.
5
Appendix A: Propostas de Melhorias ao Bitcoin Propostas de Melhorias ao Bitcoin (ou BIP - Bitcoin improvement proposals) s‹o documentos de design que fornecem informa•›es para a comunidade bitcoin, ou descreve uma nova fun•‹o para o bitcoin, seus processos ou ambiente. Conforme a BIP0001 Prop—sitos BIP0001 Prop—sitos e Guias Guias das BIP, BIP, existem trs tipos de BIP: BIP Padr‹o (Standard) (Standard) Descreve qualquer mudan•a que afete a maioria ou a totalidade das implementa•›es do bitcoin, tais como uma mudan•a no protocolo da rede, uma mudan•a nas regras de valida•‹o de transa•›es e blocos ou qualquer mudan•a ou adi•‹o que afete a inter-operabilidade de aplicativos usando bitcoin. BIP Informativa Informativa Descreve uma quest‹o relacionada ao design do bitcoin ou fornece guias gerais ou informa•›es para a comunidade bitcoin, mas n‹o prop›es uma nova caracter’stica ou fun•‹o. BIPs informativas n‹o necessariamente representam um consenso da comunidade bitcoin ou uma recomenda•‹o, de forma que usu‡rios e implementadores podem ignorar ou seguir as orienta•›es das BIPs Informativas. BIP de Processo Descreve um processo do bitcoin, ou prop›e uma mudan•a de (ou um evento em um) processo. BIPs de Processo s‹o como BIPs Padr‹o mas se aplicam a outras ‡reas que n‹o o protocolo bitcoin em si. Elas podem propor uma implementa•‹o, mas n‹o para o c—digo do Bitcoin; elas frequentemente requerem o consenso da comunidade; e diferente de BIPs Informativas, as BIPs de Processo s‹o mais do que recomenda•›es - e usu‡rios n‹o s‹o livres para as ignorar. Exemplos incluem procedimentos, guias gerais, mudan•as no processo de tomada de decis‹o e mudan•as nas ferramentas ou ambiente usado para desenvolvimento do Bitcoin. Qualquer meta-BIP tambŽm Ž considerada uma BIP de Processo. As vers›es das Propostas de Melhorias do Bitcoin s‹o gravadas em um reposit—rio no GitHub GitHub.. Retrato das BIPs mostra BIPs mostra um exemplo de BIPs vigentes em 2014. Consulte o reposit—rio oficial para informa•‹o atualizada sobre as BIPs existentes e seus conteœdos. Table 1. Retrato das BIPs
1
BIP#
Link
1
Tipo
Status
https://github.c BIP Proposta e Amir Taaki om/bitcoin/bip Diretrizes s/blob/master/b ip0001.mediawik i
Padr‹o
Ativo
10
https://github.c om/bitcoin/bip s/blob/master/b ip0010.mediawik i
Informativo
Rascunho
11
https://github.c M-de-N om/bitcoin/bip Transa•›es s/blob/master/b Padr›es ip0011.mediawik i
Gavin Andresen
Padr‹o
Aceito
12
https://github.c OP_EVAL om/bitcoin/bip s/blob/master/b ip0012.mediawik i
Gavin Andresen
Padr‹o
Removido
13
https://github.c om/bitcoin/bip s/blob/master/b ip0013.mediawik i
Formato de Gavin Endere•o para Andresen pay-to-scripthash
Padr‹o
Final
14
https://github.c om/bitcoin/bip s/blob/master/b ip0014.mediawik i
Vers‹o de Protocolo e Agente de Usu‡rio
Amir Taaki, Patrick Strateman
Padr‹o
Aceito
15
https://github.c Aliases om/bitcoin/bip s/blob/master/b ip0015.mediawik i
Amir Taaki
Padr‹o
Removida
2
T’tulo
Propriet‡rio
Distribui•‹o de Alan Re Reiner Transa•‹o com Mœltiplas Assinaturas (Multi-Sig)
BIP#
Link
T’tulo
Propriet‡rio
Tipo
Status
16
https://github.c om/bitcoin/bip s/blob/master/b ip0016.mediawik i
Pagamento Para Script Hash (Pay To Script)
Gavin Andresen
Padr‹o
Aceito
17
https://github.c OP_CHECKHAS Luke Dashjr om/bitcoin/bip HVERIFY (CHV) s/blob/master/b ip0017.mediawik i
Removido
Rascunho
18
https://github.c hashScriptChec Luke Dashjr om/bitcoin/bip k s/blob/master/b ip0018.mediawik ilink:: ilink
Padr‹o
Rascunho
19
https://github.c Transa•›es Luke Dashjr om/bitcoin/bip Padr‹o M-de-N s/blob/master/b (Low SigOp) ip0019.mediawik i
Padr‹o
Rascunho
20
https://github.c Esquema de om/bitcoin/bip URI s/blob/master/b ip0020.mediawik i
Luke Dashjr
Padr‹o
Substitu’do
21
https://github.c Esq squ uem ema a URI URI om/bitcoin/bip s/blob/master/b ip0021.mediawik i
Nils Sch Schne neiide der, r, Padr‹o Matt Corallo
22
https://github.c getblocktempla Luke Dashjr om/bitcoin/bip te s/blob/master/b Fundamentos ip0022.mediawik i
Padr‹o
Aceito
Aceito
3
BIP#
Link
23
Tipo
Status
https://github.c getblocktempla Luke Dashjr om/bitcoin/bip te - Minera•‹o s/blob/master/b em Pools ip0023.mediawik i
Padr‹o
Aceito
30
https://github.c Transa•›es om/bitcoin/bip duplicadas s/blob/master/b ip0030.mediawik i
Pieter Wuille
Padr‹o
Aceito
31
https://github.c Mensagem om/bitcoin/bip pong s/blob/master/b ip0031.mediawik i
Mike Hearn
Padr‹o
Aceito
32
https://github.c Carteiras Pieter Wuille om/bitcoin/bip Determin’stica s/blob/master/b s Hier‡rquicas ip0032.mediawik i
Informativo
Aceito
33
https://github.c Nodos om/bitcoin/bip Stratizados s/blob/master/b ip0033.mediawik i
Amir Taaki
Padr‹o
Rascunho
34
https://github.c Block v2, om/bitcoin/bip Altura na s/blob/master/b coinbase ip0034.mediawik i
Gavin Andresen
Padr‹o
Aceito
35
https://github.c mensagem om/bitcoin/bip mempool s/blob/master/b ip0035.mediawik i
Jeff Garzik
Padr‹o
Aceito
4
T’tulo
Propriet‡rio
BIP#
Link
T’tulo
Propriet‡rio
Tipo
Status
36
https://github.c Servi•os om/bitcoin/bip Customizados s/blob/master/b ip0036.mediawik i
Stefan Thomas Padr‹o
Rascunho
37
https://github.c Filtragem om/bitcoin/bip Bloom s/blob/master/b ip0037.mediawik i
Mike Hearn e Matt Corallo
Padr‹o
Aceito
38
https://github.c Chave privada Mike Caldwell om/bitcoin/bip protegida por s/blob/master/b frase secreta ip0038.mediawik i
Padr‹o
Rascunho
39
https://github.c om/bitcoin/bip s/blob/master/b ip0039.mediawik i
C—digo mnem™nico para gerar chaves chaves
Slush
Padr‹o
Rascunho
40
Protocolo de comunica•‹o Stratum
Slush
Padr‹o
Nœmero BIP alocado
41
Protocolo de minera•‹o Stratum
Slush
Padr‹o
Nœmero BIP alocado
Pieter Wuille
Padr‹o
Rascunho
Padr‹o
Rascunho
42
https://github.c om/bitcoin/bip s/blob/master/b ip0042.mediawik i
Uma oferta monet‡ria finita para o bitcoin
43
https://github.c om/bitcoin/bip s/blob/master/b ip0043.mediawik i
Proposta de Slush Campo para Carteiras Determin’stica s
5
BIP#
Link
T’tulo
Propriet‡rio
Tipo
Status
44
https://github.c om/bitcoin/bip s/blob/master/b ip0044.mediawik i
Hierarquia de Mœltiplas Contas para Carteiras Carteiras
Slush
Padr‹o
Rascunho
50
https://github.c om/bitcoin/bip s/blob/master/b ip0050.mediawik i
Fork PostGavin Mortem da Andresen Chain de Mar•o de 2013
Informativo
Rascunho
60
https://github.c om/bitcoin/bip s/blob/master/b ip0060.mediawik i
Mensagem "vers‹o" de Comprimento FIxo (Campo RelayTransactions)
Padr‹o
Rascunho
61
https://github.c mensagem P2P Gavin om/bitcoin/bip "reject" Andresen s/blob/master/b ip0061.mediawik i
Padr‹o
Rascunho
62
https://github.c Lidando com Pieter Wuille om/bitcoin/bip maleabilidade s/blob/master/b ip0062.mediawik i
Padr‹o
Rascunho
Peter Todd
Padr‹o
Nœmero BIP alocado
Mike Hearn
Padr‹o
Rascunho
63
64
6
Endere•os Camuflados (Stealth) https://github.c mensagem om/bitcoin/bip getutxos s/blob/master/b ip0064.mediawik i
Amir Taaki
BIP#
Link
T’tulo
Propriet‡rio
Tipo
Status
70
https://github.c Protocolo de om/bitcoin/bip pagamento s/blob/master/b ip0070.mediawik i
Gavin Andresen
Padr‹o
Rascunho
71
https://github.c Tipos MIME do Gavin om/bitcoin/bip protocolo de Andresen s/blob/master/b pagamento ip0071.mediawik i
Padr‹o
Rascunho
72
https://github.c URIs do om/bitcoin/bip Protocolo de s/blob/master/b Pagamento ip0072.mediawik i
Padr‹o
Rascunho
73
https://github.c om/bitcoin/bip s/blob/master/b ip0073.mediawik i
Padr‹o
Rascunho
Gavin Andresen
Uso do Stephen Pair cabe•alho "Accept" com a Requisi•‹o de Pagamento URLs
7
Appendix A: pycoin, ku e tx A livraria Python pycoin pycoin,, originalmente escrita e mantida por Richard Kiss, Ž uma livraria baseada em Python que suporta a manipula•‹o de chaves e transa•›es bitcoin, suportando atŽ a linguagem de script suficiente para lidar apropriadam apropriadamente ente com transa•›es n‹o-padr›es. A livraria pycoin suporta tanto o Python 2 (2.7.x) quanto o Python 3 (ap—s 3.3), e vem com alguns utilit‡rios de linha de comando œteis, o ku e o tx.
Utilit‡rio de Chave (Key Utility, KU) O utilit‡rio de linha de comando ku ("key utility, utilit‡rio de chave") Ž um canivete su’•o para a manipula•‹o de chaves. Ele suporta chaves BIP32, WIF e endere•os (bitcoin e alt coins). A seguir, alguns exemplos: Cria uma chave BIP32 usando fontes de entropia padr‹o de GPG e /dev/rando e /dev/random m:
1
$ ku create input : create network : Bitcoin wallet key : xprv9s21ZrQH xprv9s21ZrQH143K3LU5ctPZT 143K3LU5ctPZTBnb9kTjA5Su9D Bnb9kTjA5Su9DcWHvXJemiJBsY cWHvXJemiJBsY7VqXUG7hipgdW 7VqXUG7hipgdWaU aU m2nhnzdvxJf5KJo9vjP2nABX65c5sFsWsV8oXcbpehtJi public version version : xpub661MyMwAqRbcFpYYi xpub661MyMwAqRbcFpYYiuvZpKjKhnJDZY uvZpKjKhnJDZYAkWSY76JvvD7 AkWSY76JvvD7FH4fsG3Nqiov2 FH4fsG3Nqiov2CfxzxY8 CfxzxY8 DGcpfT56AMFeo8M8KPkFMfLUtvwjwb6WPv8rY65L2q8Hz tree depth : 0 fingerprint : 9d9c6092 parent f'print : 00000000 child index : 0 chain code : 80574fb260ed 80574fb260edaa4905bc86c9a aa4905bc86c9a47d30c697c500 47d30c697c50047ed466c0d4a5 47ed466c0d4a5167f6821e8f3c 167f6821e8f3c private key : yes secret exponent : 11247153859015565068860475 1124715385901 55650688604752840386134637 28403861346372319745469068 2319745469068472023892940 4720238929409656780684486 965678068448622 hex : f8a8a28b28a9 f8a8a28b28a916e1043cc0aca 16e1043cc0aca52033a18a13ca 52033a18a13cab1638d5440064 b1638d544006469bc171fddfbe 69bc171fddfbe wif : L5Z54xi6qJus L5Z54xi6qJusQT42JHA44mfPV QT42JHA44mfPVZGjyb4XBRWfxA ZGjyb4XBRWfxAzUWwRiGx1kV4s zUWwRiGx1kV4sPP uncompressed : 5KhoEavGNNH4 5KhoEavGNNH4GHKoy2Ptu4Kfd GHKoy2Ptu4KfdNp4r56L5B5un8 Np4r56L5B5un8FP6RZnbsz5Nmb FP6RZnbsz5Nmb public pair x : 76460638240546478364843397 7646063824054 64783648433974782784681018 47827846810187711776787346 7711776787346212702156036 2127021560368290114016034 8290114016034 public pair y : 59807879657469774102040120 5980787965746 97741020401202982722077309 29827220773092129173663324 2129173663324773707740675 7737077406753676825777701 3676825777701 x as hex : a90b30087924 a90b3008792432060fa043659 32060fa04365941e09a8e4adf9 41e09a8e4adf928bdbdb9dad41 28bdbdb9dad41131274e379322 131274e379322 y as hex : 843a0f6ed9c0 843a0f6ed9c0eb1962c745337 eb1962c74533795406914fe3f1 95406914fe3f1957c5238951f4 957c5238951f4fe245a4fcd625 fe245a4fcd625 y parity : odd key pair as sec : 03a90b300879 03a90b3008792432060fa0436 2432060fa04365941e09a8e4ad 5941e09a8e4adf928bdbdb9dad f928bdbdb9dad41131274e3793 41131274e379322 22 uncompressed : 04a90b300879 04a90b3008792432060fa0436 2432060fa04365941e09a8e4ad 5941e09a8e4adf928bdbdb9dad f928bdbdb9dad41131274e3793 41131274e379322 22 843a0f6ed9c0eb1962c74533795406914fe3f1957c5238951f4fe245a4fcd625 hash160 : 9d9c60924717 9d9c609247174ae323acfc96c 4ae323acfc96c852753fe3c881 852753fe3c8819d 9d uncompressed : 8870d869800c 8870d869800c9b91ce1eb460f 9b91ce1eb460f4c60540f87c15 4c60540f87c15d7 d7 Bitcoin address : 1FNNRQ5fSv1w 1FNNRQ5fSv1wBi5gyfVBs2rkN Bi5gyfVBs2rkNheMGt86sp heMGt86sp uncompressed : 1DSS5isnH4Fs 1DSS5isnH4FsVaLVjeVXewVSp VaLVjeVXewVSpfqktdiQAM fqktdiQAM
Cria uma chave BIP32 a partir de uma frase secreta (passphrase): WARNING
2
A frase-passe nesse exemplo Ž f‡cil demais para ser descoberta.
$ ku P:foo input : P:foo network : Bitcoin wallet key : xprv9s21ZrQ xprv9s21ZrQH143K31AgNK5p H143K31AgNK5pyVvW23gHnkBq2 yVvW23gHnkBq2wh5aEk6g1s496 wh5aEk6g1s496M8ZMjxncCKZKg M8ZMjxncCKZKgb5j b5j ZoY5eSJMJ2Vbyvi2hbmQnCuHBujZ2WXGTux1X2k9Krdtq public version version : xpub661MyMwAqRbcFVF9UL xpub661MyMwAqRbcFVF9ULcqLdsEa5WnCCu cqLdsEa5WnCCugQAcgNd9iEMQ3 gQAcgNd9iEMQ31tgH6u4DLQWo 1tgH6u4DLQWoQayvtS QayvtS VYFvXz2vPPpbXE1qpjoUFidhjFj82pVShWu9curWmb2zy tree depth : 0 fingerprint : 5d353a2e parent f'print : 00000000 child index : 0 chain code : 5eeb1023fd6 5eeb1023fd6dd1ae52a005ce dd1ae52a005ce0e73420821e1d 0e73420821e1d90e08be980a85 90e08be980a85e9111fd7646bb e9111fd7646bbcc private key : yes secret exponent : 6582573054709730571605716 658257305470 97305716057160437970790220 04379707902201238642997619 12386429976190894874683588 0894874683588600779399827 60077939982755 hex : 91880b0e301 91880b0e3017ba586b735fe7 7ba586b735fe7d04f1790f3c46 d04f1790f3c46b818a2151fb2d b818a2151fb2def5f14dd2fd9c ef5f14dd2fd9c33 wif : L26c3H6jEPV L26c3H6jEPVSqAr1usXUp9qt SqAr1usXUp9qtQJw6NHgApq6Ls QJw6NHgApq6Ls4ncyqtsvcq2Mw 4ncyqtsvcq2MwKH KH uncompressedd : 5JvNzA5vXDo uncompresse 5JvNzA5vXDoKYJdw8SwwLHxU KYJdw8SwwLHxUxaWvn9mDea6k1 xaWvn9mDea6k1vRPCX7KLUVWa7 vRPCX7KLUVWa7WW public pair x : 8182198271938110406177734 818219827193 81104061777349269130419024 92691304190244936166509935 49361665099358939455340434 8939455340434777439316819 77743931681911 public pair y : 5899421806960542427832070 589942180696 05424278320703250689780154 32506897801547850995092776 78509950927769172312632505 9172312632505120045903829 12004590382900 x as hex : b4e599dfa44 b4e599dfa44555a4ed38bcff 555a4ed38bcfff0071d5af676a f0071d5af676a86abf123c5b4b 86abf123c5b4b4e8e67a0b0b13 4e8e67a0b0b13ff y as hex : 826d8b4d301 826d8b4d3010aea16ff4c1c1 0aea16ff4c1c1d3ae68541d9a0 d3ae68541d9a04df54a2c48cc2 4df54a2c48cc241c2983544de5 41c2983544de522 y parity : even key pair as sec : 02b4e599dfa 02b4e599dfa44555a4ed38bc 44555a4ed38bcfff0071d5af67 fff0071d5af676a86abf123c5b 6a86abf123c5b4b4e8e67a0b0b 4b4e8e67a0b0b13f 13f uncompressedd : 04b4e599dfa uncompresse 04b4e599dfa44555a4ed38bc 44555a4ed38bcfff0071d5af67 fff0071d5af676a86abf123c5b 6a86abf123c5b4b4e8e67a0b0b 4b4e8e67a0b0b13f 13f 826d8b4d3010aea16ff4c1c1d3ae68541d9a04df54a2c48cc241c2983544de52 hash160 : 5d353a2ecdb 5d353a2ecdb262477172852d 262477172852d57a3f11de0c19 57a3f11de0c19286 286 uncompressedd : e5bd3a7e6cb uncompresse e5bd3a7e6cb62b4c820e5120 62b4c820e51200fb1c148d79e6 0fb1c148d79e67da 7da Bitcoin address : 19Vqc8uLTfU 19Vqc8uLTfUonmxUEZac7fz1 onmxUEZac7fz1M5c5ZZbAii M5c5ZZbAii uncompressedd : 1MwkRkogzBR uncompresse 1MwkRkogzBRMehBntgcq2aJh MehBntgcq2aJhXCXStJTXHT XCXStJTXHT
Adquire informa•›es como JSON:
$ ku P:foo -P -j
3
{ "y_parity": "even", "public_pair_y_hex": "826d8b4d3010aea16ff4c1c1 "826d8b4d301 0aea16ff4c1c1d3ae68541d9a0 d3ae68541d9a04df54a2c48cc2 4df54a2c48cc241c2983544de5 41c2983544de52", 2", "private_key": "private_ke y": "no", "parent_fingerprint": "parent_fin gerprint": "00000000", "tree_depth": "tree_depth ": "0", "network": "Bitcoin", "btc_address_uncompresse "btc_addres s_uncompressed": d": "1MwkRkogzB "1MwkRkogzBRMehBntgcq2aJ RMehBntgcq2aJhXCXStJTXHT", hXCXStJTXHT", "key_pair_as_sec_uncompressed": "04b4e599dfa44555a4ed38bc "04b4e599dfa 44555a4ed38bcfff0071d5af67 fff0071d5af676a86abf123c5b 6a86abf123c5b4b4e8e67a0b0b 4b4e8e67a0b0b13f826d8b4d3 13f826d8b4d3010aea16ff4c1 010aea16ff4c1 c1d3ae68541d9a04df54a2c48 c1d3ae68541d 9a04df54a2c48cc241c2983544 cc241c2983544de52", de52", "public_pair_x_hex": "b4e599dfa44555a4ed38bcff "b4e599dfa44 555a4ed38bcfff0071d5af676a f0071d5af676a86abf123c5b4b 86abf123c5b4b4e8e67a0b0b13 4e8e67a0b0b13f", f", "wallet_key": "xpub661MyMwAqRbcFVF9ULcq "xpub661MyMw AqRbcFVF9ULcqLdsEa5WnCCugQ LdsEa5WnCCugQAcgNd9iEMQ31t AcgNd9iEMQ31tgH6u4DLQWoQay gH6u4DLQWoQayvtSVYFvXz2vP vtSVYFvXz2vPPpbXE1qpjoUFi PpbXE1qpjoUFi dhjFj82pVShWu9curWmb2zy", "chain_code": "chain_code ": "5eeb1023fd6 "5eeb1023fd6dd1ae52a005ce dd1ae52a005ce0e73420821e1d 0e73420821e1d90e08be980a85 90e08be980a85e9111fd7646bb e9111fd7646bbc", c", "child_index": "child_index ": "0", "hash160_uncompressed": "hash160_un compressed": "e5bd3a7e6cb6 "e5bd3a7e6cb62b4c820e51200 2b4c820e51200fb1c148d79e67 fb1c148d79e67da", da", "btc_address": "btc_addres s": "19Vqc8uLTf "19Vqc8uLTfUonmxUEZac7fz UonmxUEZac7fz1M5c5ZZbAii", 1M5c5ZZbAii", "fingerprint": "fingerprin t": "5d353a2e", "hash160": "5d353a2ecdb2 "5d353a2ecdb262477172852d5 62477172852d57a3f11de0c192 7a3f11de0c19286", 86", "input": "P:foo", "public_pair_x": "818219827193811040617773 "81821982719 38110406177734926913041902 49269130419024493616650993 44936166509935893945534043 5893945534043477743931681 47774393168191", 91", "public_pair_y": "589942180696054242783207 "58994218069 60542427832070325068978015 03250689780154785099509277 47850995092776917231263250 6917231263250512004590382 51200459038290", 90", "key_pair_as_sec": "02b4e599dfa44555a4ed38bc "02b4e599dfa 44555a4ed38bcfff0071d5af67 fff0071d5af676a86abf123c5b 6a86abf123c5b4b4e8e67a0b0b 4b4e8e67a0b0b13f" 13f" }
Chave pœblica BIP32:
$ ku -w -P P:foo xpub661MyMwAqRbcFVF9ULcqL xpub661MyMwA qRbcFVF9ULcqLdsEa5WnCCugQA dsEa5WnCCugQAcgNd9iEMQ31tg cgNd9iEMQ31tgH6u4DLQWoQayv H6u4DLQWoQayvtSVYFvXz2vPP tSVYFvXz2vPPpbXE1qpjoUFid pbXE1qpjoUFid hjFj82pVShWu9curWmb2zy
Gerar uma subchave:
4
$ ku -w -s3/2 P:foo xprv9wTErTSkjVyJa1v4cUTFM xprv9wTErTSk jVyJa1v4cUTFMFkWMe5eu8ErbQ FkWMe5eu8ErbQcs9xajnsUzCBT cs9xajnsUzCBT7ykHAwdrxvG3g 7ykHAwdrxvG3g3f6BFk7ms5hH 3f6BFk7ms5hHBvmbdutNmyg6i BvmbdutNmyg6i ogWKxx6mefEw4M8EroLgKj
Subkey dificultada (hardened):
$ ku -w -s3/2H P:foo xprv9wTErTSu5AWGkDeUPmqBc xprv9wTErTSu 5AWGkDeUPmqBcbZWX1xq85ZNX9 bZWX1xq85ZNX9iQRQW9DXwygFp iQRQW9DXwygFp7iRGJo79dsVct 7iRGJo79dsVctcsCHsnZ3XU3D csCHsnZ3XU3DhsuaGZbDh8iDk hsuaGZbDh8iDk BN45k67UKsJUXM1JfRCdn1
WIF:
$ ku -W P:foo L26c3H6jEPVSqAr1usXUp9qtQ L26c3H6jEPVS qAr1usXUp9qtQJw6NHgApq6Ls4 Jw6NHgApq6Ls4ncyqtsvcq2MwK ncyqtsvcq2MwKHH
Endere•o:
$ ku -a P:foo 19Vqc8uLTfUonmxUEZac7fz1M5c5ZZbAii
Gerar v‡rias subchaves:
$ ku P:foo -s 0/0-5 -w xprv9xWkBDfyBXmZjBG9EiXBp xprv9xWkBDfy BXmZjBG9EiXBpy67KK72fphUp9 y67KK72fphUp9utJokEBFtjsji utJokEBFtjsjiuKUUDF5V3TU8U uKUUDF5V3TU8U8cDzytqYnSek 8cDzytqYnSekc8bYuJS8G3bhX c8bYuJS8G3bhX xKWB89Ggn2dzLcoJsuEdRK xprv9xWkBDfyBXmZnzKf3bAGi xprv9xWkBDfy BXmZnzKf3bAGifK593gT7WJZPn fK593gT7WJZPnYAmvc77gUQVej YAmvc77gUQVej5QHckc5Adtwxa 5QHckc5Adtwxa28ACmANi9XhC 28ACmANi9XhCrRvtFqQcUxt8r rRvtFqQcUxt8r UgFz3souMiDdWxJDZnQxzx xprv9xWkBDfyBXmZqdXA8y4SW xprv9xWkBDfy BXmZqdXA8y4SWqfBdy71gSW9sj qfBdy71gSW9sjx9JpCiJEiBwSM x9JpCiJEiBwSMQyRxan6srXUPB QyRxan6srXUPBtj3PTxQFkZJA tj3PTxQFkZJAiwoUpmvtrxKZu iwoUpmvtrxKZu 4zfsnr3pqyy2vthpkwuoVq xprv9xWkBDfyBXmZsA85GyWj9 xprv9xWkBDfy BXmZsA85GyWj9uYPyoQv826YAa uYPyoQv826YAadKWMaaEosNrFB dKWMaaEosNrFBKgj2TqWuiWY3z Kgj2TqWuiWY3zuqxYGpHfv9cn uqxYGpHfv9cnGj5P7e8EskpzK Gj5P7e8EskpzK L1Y8Gk9aX6QbryA5raK73p xprv9xWkBDfyBXmZv2q3N66hh xprv9xWkBDfy BXmZv2q3N66hhZ8DAcEnQDnXML Z8DAcEnQDnXML1J62krJAcf7Xb 1J62krJAcf7Xb1HJwuW2VMJQrC 1HJwuW2VMJQrCofY2jtFXdiEY ofY2jtFXdiEY8UsRNJfqK6DAd 8UsRNJfqK6DAd yZXoMvtaLHyWQx3FS4A9zw xprv9xWkBDfyBXmZw4jEYXUHY xprv9xWkBDfy BXmZw4jEYXUHYc9fT25k9irP87 c9fT25k9irP87n2RqfJ5bqbjKd n2RqfJ5bqbjKdT84Mm7Wtc2xmz T84Mm7Wtc2xmzFuKg7iYf7XFH FuKg7iYf7XFHKkSsaYKWKJbR5 KkSsaYKWKJbR5 4bnyAD9GzjUYbAYTtN4ruo
5
Gerar os endere•os correspondentes:
$ ku P:foo -s 0/0-5 -a 1MrjE78H1R1rqdFrmkjdHnPUdLCJALbv3x 1AnYyVEcuqeoVzH96zj1eYKwoWfwte2pxu 1GXr1kZfxE1FcK6ZRD5sqqqs5YfvuzA1Lb 116AXZc4bDVQrqmcinzu4aaPdrYqvuiBEK 1Cz2rTLjRM6pMnxPNrRKp9ZSvRtj5dDUML 1WstdwPnU6HEUPme1DQayN9nm6j7nDVEM
Gerar os WIFs correspondentes:
$ ku P:foo -s 0/0-5 -W L5a4iE5k9gcJKGqX3FWmxzBYQ L5a4iE5k9gcJ KGqX3FWmxzBYQc29PvZ6pgBaeP c29PvZ6pgBaePLVqT5YByEnBom LVqT5YByEnBomxx Kyjgne6GZwPGB6G6kJEhoPbmy Kyjgne6GZwPG B6G6kJEhoPbmyjMP7D5d3zRbHV jMP7D5d3zRbHVjwcq4iQXD9QqK jwcq4iQXD9QqKQQ L4B3ygQxK6zH2NQGxLDee2H9v L4B3ygQxK6zH 2NQGxLDee2H9v4Lvwg14cLJW7Q 4Lvwg14cLJW7QwWPzCtKHdWMaQ wWPzCtKHdWMaQzz L2L2PZdorybUqkPjrmhem4Ax5 L2L2PZdorybU qkPjrmhem4Ax5EJvP7ijmxbNoQ EJvP7ijmxbNoQKnmTDMrqemY8U KnmTDMrqemY8UFF L2oD6vA4TUyqPF8QG4vhUFSgw L2oD6vA4TUyq PF8QG4vhUFSgwCyuuvFZ3v8SKH CyuuvFZ3v8SKHYFDwkbM765Nrf YFDwkbM765Nrfdd KzChTbc3kZFxUSJ3Kt54cxsog KzChTbc3kZFx USJ3Kt54cxsogeFAD9CCM4zGB2 eFAD9CCM4zGB22si8nfKcThQn8 2si8nfKcThQn8CC
Verifica que isso funciona ao escolher uma string BIP32 (a que corresponde ˆ subchave 0/3):
$ ku -W xprv9xWkBDfyBXmZsA85GyWj9 xprv9xWkBDfy BXmZsA85GyWj9uYPyoQv826YAa uYPyoQv826YAadKWMaaEosNrFB dKWMaaEosNrFBKgj2TqWuiWY3z Kgj2TqWuiWY3zuqxYGpHfv9cn uqxYGpHfv9cnGj5P7e8EskpzK Gj5P7e8EskpzK L1Y8Gk9aX6QbryA5raK73p L2L2PZdorybUqkPjrmhem4Ax5 L2L2PZdorybU qkPjrmhem4Ax5EJvP7ijmxbNoQ EJvP7ijmxbNoQKnmTDMrqemY8U KnmTDMrqemY8UFF $ ku -a xprv9xWkBDfyBXmZsA85GyWj9 xprv9xWkBDfy BXmZsA85GyWj9uYPyoQv826YAa uYPyoQv826YAadKWMaaEosNrFB dKWMaaEosNrFBKgj2TqWuiWY3z Kgj2TqWuiWY3zuqxYGpHfv9cn uqxYGpHfv9cnGj5P7e8EskpzK Gj5P7e8EskpzK L1Y8Gk9aX6QbryA5raK73p 116AXZc4bDVQrqmcinzu4aaPdrYqvuiBEK
Sim, isso parece familiar. A partir de um exponente secreto:
6
$ ku 1 input : 1 network : Bitcoin secret exponent : 1 hex : 1 wif : KwDiBf89QgG KwDiBf89QgGbjEhKnhXJuH7L bjEhKnhXJuH7LrciVrZi3qYjgd rciVrZi3qYjgd9M7rFU73sVHno 9M7rFU73sVHnoWn Wn uncompressedd : 5HpHagT65TZ uncompresse 5HpHagT65TZzG1PH3CSu63k8 zG1PH3CSu63k8DbpvD8s5ip4nE DbpvD8s5ip4nEB3kEsreAnchuD B3kEsreAnchuDff public pair x : 5506626302227734366957871 550662630222 77343669578718895168534326 88951685343262506034537775 25060345377759417550018736 9417550018736038911672924 03891167292400 public pair y : 3267051002075881697808308 326705100207 58816978083085130507043184 51305070431844712733806592 47127338065924327593890433 4327593890433575733748242 57573374824244 x as hex : 79be667ef9d 79be667ef9dcbbac55a06295 cbbac55a06295ce870b07029bf ce870b07029bfcdb2dce28d959 cdb2dce28d959f2815b16f8179 f2815b16f817988 y as hex : 483ada7726a 483ada7726a3c4655da4fbfc 3c4655da4fbfc0e1108a8fd17b 0e1108a8fd17b448a68554199c 448a68554199c47d08ffb10d4b 47d08ffb10d4b88 y parity : even key pair as sec : 0279be667ef 0279be667ef9dcbbac55a062 9dcbbac55a06295ce870b07029 95ce870b07029bfcdb2dce28d9 bfcdb2dce28d959f2815b16f81 59f2815b16f81798 798 uncompressedd : 0479be667ef uncompresse 0479be667ef9dcbbac55a062 9dcbbac55a06295ce870b07029 95ce870b07029bfcdb2dce28d9 bfcdb2dce28d959f2815b16f81 59f2815b16f81798 798 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 hash160 : 751e76e8199 751e76e8199196d454941c45 196d454941c45d1b3a323f1433 d1b3a323f1433bd6 bd6 uncompressedd : 91b24bf9f52 uncompresse 91b24bf9f5288532960ac687 88532960ac687abb035127b1d2 abb035127b1d28a5 8a5 Bitcoin address : 1BgGZ9tcN4r 1BgGZ9tcN4rm9KBzDn7KprQz m9KBzDn7KprQz87SZ26SAMH 87SZ26SAMH uncompressedd : 1EHNa6Q4Jz2 uncompresse 1EHNa6Q4Jz2uvNExL497mE43 uvNExL497mE43ikXhwF6kZm ikXhwF6kZm
Vers‹o Litecoin:
7
$ ku -nL 1 input : 1 network : Litecoin secret exponent : 1 hex : 1 wif : T33ydQRKp4FCW T33ydQRKp4FCW5LCLLUB7deio 5LCLLUB7deioUMoveiwekdwUw UMoveiwekdwUwyfRDeGZm76aUj yfRDeGZm76aUjVV uncompressedd uncompresse : 6u823ozcyt2rj 6u823ozcyt2rjPH8Z2ErsSXJB PH8Z2ErsSXJB5PPQwK7VVTwwN 5PPQwK7VVTwwN4mxLBFrao69XQ 4mxLBFrao69XQ public pair x : 5506626302227734366957871 550662630222 77343669578718895168534326 88951685343262506034537775 25060345377759417550018736 9417550018736038911672924 03891167292400 public pair y : 3267051002075881697808308 326705100207 58816978083085130507043184 51305070431844712733806592 47127338065924327593890433 4327593890433575733748242 57573374824244 x as hex : 79be667ef9dcb 79be667ef9dcbbac55a06295c bac55a06295ce870b07029bfc e870b07029bfcdb2dce28d959f db2dce28d959f2815b16f81798 2815b16f81798 y as hex : 483ada7726a3c 483ada7726a3c4655da4fbfc0 4655da4fbfc0e1108a8fd17b4 e1108a8fd17b448a68554199c4 48a68554199c47d08ffb10d4b8 7d08ffb10d4b8 y parity : even key pair as sec : 0279be667ef9dcbbac55a06 0279be667ef9dcbbac55a06295ce870b0702 295ce870b07029bfcdb2dce28d 9bfcdb2dce28d959f2815b16f8 959f2815b16f81798 1798 uncompressedd uncompresse : 0479be667ef9d 0479be667ef9dcbbac55a0629 cbbac55a06295ce870b07029b 5ce870b07029bfcdb2dce28d95 fcdb2dce28d959f2815b16f817 9f2815b16f81798 98 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 hash160 : 751e76e819919 751e76e8199196d454941c45d 6d454941c45d1b3a323f1433b 1b3a323f1433bd6 d6 uncompressedd uncompresse : 91b24bf9f5288 91b24bf9f5288532960ac687a 532960ac687abb035127b1d28 bb035127b1d28a5 a5 Litecoin address : LVuDpNCSSj6pQ LVuDpNCSSj6pQ7t9Pv6d6sUkL 7t9Pv6d6sUkLKoqDEVUnJ KoqDEVUnJ uncompressedd uncompresse : LYWKqJhtPeGyB LYWKqJhtPeGyBAw7WC8R3F7ov Aw7WC8R3F7ovxtzAiubdM xtzAiubdM
Dogecoin WIF:
$ ku -nD -W 1 QNcdLVw8fHkixm6NNyN6nVwxK QNcdLVw8fHki xm6NNyN6nVwxKek4u7qrioRbQm ek4u7qrioRbQmjxac5TVoTtZuo jxac5TVoTtZuott
A partir de um par pœblico (na Testnet):
8
$ ku -nT 5506626302227734366957871 550662630222 77343669578718895168534326 88951685343262506034537775 25060345377759417550018736 9417550018736038911672924 0389116729240,even 0,even input : 5506626302227734366957871 550662630222 77343669578718895168534326 88951685343262506034537775 25060345377759417550018736 941755001873603 03 89116729240,even network : Bitcoin testnet public pair x : 5506626302227734366957871 550662630222 77343669578718895168534326 88951685343262506034537775 25060345377759417550018736 9417550018736038911672924 03891167292400 public pair y : 3267051002075881697808308 326705100207 58816978083085130507043184 51305070431844712733806592 47127338065924327593890433 4327593890433575733748242 57573374824244 x as hex : 79be667ef9dcbbac55a06295c 79be667ef9dc bbac55a06295ce870b07029bfc e870b07029bfcdb2dce28d959f db2dce28d959f2815b16f81798 2815b16f81798 y as hex : 483ada7726a3c4655da4fbfc0 483ada7726a3 c4655da4fbfc0e1108a8fd17b4 e1108a8fd17b448a68554199c4 48a68554199c47d08ffb10d4b8 7d08ffb10d4b8 y parity : even key pair as sec : 0279be667ef9dcbbac55a0629 0279be667ef9 dcbbac55a06295ce870b07029b 5ce870b07029bfcdb2dce28d95 fcdb2dce28d959f2815b16f817 9f2815b16f81798 98 uncompressedd uncompresse : 0479be667ef9dcbbac55a0629 0479be667ef9 dcbbac55a06295ce870b07029b 5ce870b07029bfcdb2dce28d95 fcdb2dce28d959f2815b16f817 9f2815b16f81798 98 483ada7726a3c4655da4fbfc0e1108a8fd17b4 483ada7726a3c4655da4fbfc0 e1108a8fd17b448a68554199c4 48a68554199c47d08ffb10d4b8 7d08ffb10d4b8 hash160 : 751e76e81991 751e76e8199196d454941c45d 96d454941c45d1b3a323f1433b 1b3a323f1433bd6 d6 uncompressedd uncompresse : 91b24bf9f528 91b24bf9f5288532960ac687a 8532960ac687abb035127b1d28 bb035127b1d28a5 a5 Bitcoin testnet address : mrCDrCybB6J1 mrCDrCybB6J1vRfbwM5hemdJz vRfbwM5hemdJz73FwDBC8r 73FwDBC8r uncompressedd uncompresse : mtoKs9V381UA mtoKs9V381UAhUia3d7Vb9GNa hUia3d7Vb9GNak8Qvmcsme k8Qvmcsme
A partir de hash160:
$ ku 751e76e81991 751e76e8199196d454941c45 96d454941c45d1b3a323f1433 d1b3a323f1433bd6 bd6 input network hash160 Bitcoin address
: : : :
751e76e8199196d454941c45d1b3a323f1433 751e76e8199196d454941c45 d1b3a323f1433bd6 bd6 Bitcoin 751e76e8199196d454941c45 751e76e8199 196d454941c45d1b3a323f1433 d1b3a323f1433bd6 bd6 1BgGZ9tcN4rm9KBzDn7KprQz 1BgGZ9tcN4r m9KBzDn7KprQz87SZ26SAMH 87SZ26SAMH
Como um endere•o Dogecoin:
9
$ ku -nD 751e76e81991 751e76e8199196d454941c45d 96d454941c45d1b3a323f1433 1b3a323f1433bd6 bd6 input network hash160 Dogecoin address
: : : :
751e76e8199196d454941c45d1b3a323f1433b 751e76e8199196d454941c45d 1b3a323f1433bd6 d6 Dogecoin 751e76e8199196d454941c45d 751e76e819919 6d454941c45d1b3a323f1433b 1b3a323f1433bd6 d6 DFpN6QqFfUm3gKNaxN6tNcab1 DFpN6QqFfUm3g KNaxN6tNcab1FArL9cZLE FArL9cZLE
Utilit‡rio de Transa•‹o (Transacion Utility, Utility, TX) O utilit‡rio de linha de comando tx ir‡ mostrar as transa•›es de uma maneira f‡cil, fazer fetch de transa•›es base a partir do cache de transa•›es do pycoin ou de servi•os web (blockchain.info, blockr.io e biteasy.com s‹o os suportados atualmente), mesclar transa•›es, adicionar ou remover inputs ou outputs e assinar transa•›es. A seguir temos alguns exemplos. Veja a famosa transa•‹o "pizza" [PIZZA]:
$ tx 49d2adb6e476f 49d2adb6e476fa46d8357babf a46d8357babf78b1b501fd39e 78b1b501fd39e177ac7833124b 177ac7833124b3f67b17c40c2a 3f67b17c40c2a aviso: considere definir a vari ‡vel de ambiente PYCOIN_CACHE_DIR=~/.pycoin_ca PYCOIN_CACHE_DIR=~/.pycoin_cache che para fazer o cache das transa •›es adquiridas atrav Žs de servi •os web aviso: n ‹o foram encontrados provedores de servi •o para get_tx; considere definir a vari‡vel de ambiente PYCOIN_SERVICE_PROVIDERS=B PYCOIN_SERVIC E_PROVIDERS=BLOCKR_IO:BLOC LOCKR_IO:BLOCKCHAIN_INFO:B KCHAIN_INFO:BITEASY:BLOCK ITEASY:BLOCKEXPLORER EXPLORER uso: tx [-h] [-t TRANSACTION_VERSION] TRANSACTION_VERSION] [-l LOCK_TIME] [-n NETWORK] [-a] [-i endere•o] [-f caminho-para-chaves-privadas] caminho-para-chaves-privadas] [-g ARGUMENTO_GP ARGUMENTO_GPG] G] [--remove-tx-in [--remove-tx -in tx_in_index_t tx_in_index_to_delete] o_delete] [--remove-tx-out [--remove-t x-out tx_out_inde tx_out_index_to_delete x_to_delete]] [-F transaction transaction-fee] -fee] [-u] [-b URL_DO_BITCO URL_DO_BITCOIND] IND] [-o caminho-para caminho-para-o-arquivo-ou -o-arquivo-output] tput] argumento [argumento ...] tx: erro: n ‹o foi poss ’ vel vel encontrar o Tx com o id 49d2adb6e476fa46d8357babf7 49d2adb6e476f a46d8357babf78b1b501fd39e1 8b1b501fd39e177ac7833124b3 77ac7833124b3f67b17c40c2a f67b17c40c2a
Opa! N—s n‹o definimos os servi•os web. Vamos fazer isso agora:
$ PYCOIN_CACH PYCOIN_CACHE_DIR=~/.pyco E_DIR=~/.pycoin_cache in_cache $ PYCOIN_SERV PYCOIN_SERVICE_PROVIDERS ICE_PROVIDERS=BLOCKR_IO:BL =BLOCKR_IO:BLOCKCHAIN_INFO OCKCHAIN_INFO:BITEASY:BLO :BITEASY:BLOCKEXPLORER CKEXPLORER $ export PYCOIN_CACHE_DIR PYCOIN_SERVICE_PROVIDERS PYCOIN_SERVICE_PROVIDERS
Isso n‹o Ž feito automaticamente de maneira que uma ferramenta de linha de comando n‹o ir‡ vazar
10
para um website de terceiros informa•›es potencialmente privadas sobre as transa•›es que voc est‡ interessado. Se voc n‹o se importar com isso, voc pode inserir essas linhas em seu .profile .profile.. Vamos tentar novamente:
$ tx 49d2adb6e476f 49d2adb6e476fa46d8357babf a46d8357babf78b1b501fd39e 78b1b501fd39e177ac7833124b 177ac7833124b3f67b17c40c2a 3f67b17c40c2a Version: 1 tx hash 49d2adb6e47 49d2adb6e476fa46d8357bab 6fa46d8357babf78b1b501fd39 f78b1b501fd39e177ac7833124 e177ac7833124b3f67b17c40c2 b3f67b17c40c2aa 159 bytes TxIn count: 1; TxOut count: 1 Lock time: 0 (v ‡lido a qualquer momento) Input: 0: (desconhecido)) de (desconhecido 1e133f7de73ac7d074e2746a3d 1e133f7de73ac 7d074e2746a3d6717dfc99ecaa 6717dfc99ecaa8e9f9fade2cb8 8e9f9fade2cb8b0b20a5e0441 b0b20a5e0441:0 :0 Output: 0: 1CZDM6oTttND6WPdt 1CZDM6oTttND6WPdt3D6bydo7DYKzd 3D6bydo7DYKzd9Qik 9Qik recebe recebe 10000000.00000 10000000.00000 mBTC Output total 10000000.00000 mBTC incluindo os n ‹o-gastos no dump hex, j ‡ que a transa •‹o n‹o est‡ completamente assinada 010000000141045e0ab2b0b82c 0100000001410 45e0ab2b0b82cdefaf9e9a8ca9 defaf9e9a8ca9ec9df17673d6a ec9df17673d6a74e274d0c73a 74e274d0c73ae77d3f131e000 e77d3f131e000000004a4 000004a4 93046022100a7f26eda8749319 93046022100a7 f26eda874931999c90f87f01ff 99c90f87f01ff1ffc76bcd058f 1ffc76bcd058fe16137e0e63f e16137e0e63fdb6a35c2d7802 db6a35c2d78022100a61e 2100a61e 9199238eb73f07c8f209504c84 9199238eb73f0 7c8f209504c84b80f03e30ed81 b80f03e30ed8169edd44f80ed1 69edd44f80ed17ddf451901ff 7ddf451901ffffffff010010a ffffff010010a5d4e8000 5d4e8000 0001976a9147ec1003336542ca 0001976a9147e c1003336542cae8bded8909cdd e8bded8909cdd6b5e48ba0ab68 6b5e48ba0ab688ac00000000 8ac00000000 ** n‹o foi poss ’ vel vel validar a transa •‹o, pois as transa •›es-fonte est ‹o faltando
A œltima linha aparece porque para validar as assinaturas das transa•›es, voc tecnicamente precisa das transa•›es-fonte. Ent‹o vamos adicionar -a para acrescentar ˆs transa•›es uma informa•‹o de fonte:
11
$ tx -a 49d2adb6e476 49d2adb6e476fa46d8357bab fa46d8357babf78b1b501fd39 f78b1b501fd39e177ac7833124 e177ac7833124b3f67b17c40c2 b3f67b17c40c2aa aviso: as recomenda •›es de taxas de transa •‹o calculadas casualmente e estimativas podem estar incorretas aviso: a taxa de transa •‹o Ž menor que o valor experado de 0,1 mBTC (casualmente calculado). A transa •‹o pode n ‹o se propagar. Version: 1 tx hash 49d2adb6e47 49d2adb6e476fa46d8357bab 6fa46d8357babf78b1b501fd39 f78b1b501fd39e177ac7833124 e177ac7833124b3f67b17c40c2 b3f67b17c40c2aa 159 bytes TxIn count: 1; TxOut count: 1 Lock time: 0 (v ‡lido a qualquer momento) Input: 0: 17WFx2GQZUmh6 17WFx2GQZUmh6Up2NDNCEDk3d Up2NDNCEDk3deYomdNCfk eYomdNCfk de 1e133f7de73ac7d074e2746a3d 1e133f7de73ac 7d074e2746a3d6717dfc99ecaa 6717dfc99ecaa8e9f9fade2cb8 8e9f9fade2cb8b0b20a5e0441 b0b20a5e0441:0 :0 10000000.000 10000000.00000 00 mBTC sig ok Output: 0: 1CZDM6oTttND6WPdt 1CZDM6oTttND6WPdt3D6bydo7DYKzd 3D6bydo7DYKzd9Qik 9Qik recebe recebe 10000000.00000 10000000.00000 mBTC Input total 10000000,0000 10000000,000000 mBTC Output total 10000000.00000 mBTC Total de taxas 0,00000 mBTC 010000000141045e0ab2b0b82cdefaf9e9a8ca9 010000000141045e0ab2b0b82c defaf9e9a8ca9ec9df17673d6a ec9df17673d6a74e274d0c73a 74e274d0c73ae77d3f131e000 e77d3f131e000000004a4 000004a4 93046022100a7f26eda8749319 93046022100a7 f26eda874931999c90f87f01ff 99c90f87f01ff1ffc76bcd058f 1ffc76bcd058fe16137e0e63f e16137e0e63fdb6a35c2d7802 db6a35c2d78022100a61e 2100a61e 9199238eb73f07c8f209504c84 9199238eb73f0 7c8f209504c84b80f03e30ed81 b80f03e30ed8169edd44f80ed1 69edd44f80ed17ddf451901ff 7ddf451901ffffffff010010a ffffff010010a5d4e8000 5d4e8000 0001976a9147ec1003336542ca 0001976a9147e c1003336542cae8bded8909cdd e8bded8909cdd6b5e48ba0ab68 6b5e48ba0ab688ac00000000 8ac00000000 todos os valores de transa •‹o recebidas foram validados
Agora, vamos ver os outputs n‹o-gastos para um endere•o espec’fico (UTXO). No bloco #1, n—s vemos uma transa•‹o coinbase para 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX. Vamos usar fetch_unspent para encontrar todas as moedas (bitcoins) nesse endere•o:
12
$ fetch_unspe fetch_unspent nt 12c6DSiU4Rq3 12c6DSiU4Rq3P4ZxziKxzrL5L P4ZxziKxzrL5LmMBrzjrJX mMBrzjrJX a3a6f902a51a2cbebede144e48 a3a6f902a51a2 cbebede144e48a88c05e608c2c a88c05e608c2cce28024041a5b ce28024041a5b9874013a1e2a 9874013a1e2a/0/76a914119b /0/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/333000 2688ac/333000 cea36d008badf5c7866894b191 cea36d008badf 5c7866894b191d3239de9582d8 d3239de9582d89b6b452b596f1 9b6b452b596f1f1b76347f8cb f1b76347f8cb/31/76a914119 /31/76a914119b098e2e9 b098e2e9 80a229e139a9ed01a469e518e6 80a229e139a9e d01a469e518e6f2688ac/10000 f2688ac/10000 065ef6b1463f552f675622a5d1 065ef6b1463f5 52f675622a5d1fd2c08d6324b4 fd2c08d6324b4402049f68e767 402049f68e767a719e2049e8d a719e2049e8d/86/76a914119 /86/76a914119b098e2e9 b098e2e9 80a229e139a9ed01a469e518e6 80a229e139a9e d01a469e518e6f2688ac/10000 f2688ac/10000 a66dddd42f9f2491d3c336ce55 a66dddd42f9f2 491d3c336ce5527d45cc5c2163 27d45cc5c2163aaed3158f81dc aaed3158f81dc054447f447a2 054447f447a2/0/76a914119b /0/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/10000 2688ac/10000 ffd901679de65d4398de90cefe ffd901679de65 d4398de90cefe68d2c3ef073c4 68d2c3ef073c41f7e8dbec2fb5 1f7e8dbec2fb5cd75fe71dfe7 cd75fe71dfe7/0/76a914119b /0/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/100 2688ac/100 d658ab87cc053b8dbcfd4aa271 d658ab87cc053 b8dbcfd4aa2717fd23cc3edfe9 7fd23cc3edfe90ec75351fadd6 0ec75351fadd6a0f7993b461d a0f7993b461d/5/76a914119b /5/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/911 2688ac/911 36ebe0ca3237002acb12e1474a 36ebe0ca32370 02acb12e1474a3859bde0ac84b 3859bde0ac84b419ec4ae373e6 419ec4ae373e63363ebef731c 3363ebef731c/1/76a914119b /1/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/100000 2688ac/100000 fd87f9adebb17f4ebb1673da76 fd87f9adebb17 f4ebb1673da76ff48ad29e64b7 ff48ad29e64b7afa02fda0f2c1 afa02fda0f2c14e43d220fe24 4e43d220fe24/0/76a914119b /0/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f2688ac/1 dfdf0b375a987f17056e5e919e dfdf0b375a987 f17056e5e919ee6eadd87dad36 e6eadd87dad36c09c4016d4a03 c09c4016d4a03cea15e5c05e3 cea15e5c05e3/1/76a914119b /1/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/1337 2688ac/1337 cb2679bfd0a557b2dc0d8a6116 cb2679bfd0a55 7b2dc0d8a6116822f3fcbe281c 822f3fcbe281ca3f3e18d3855a a3f3e18d3855aa7ea378fa373 a7ea378fa373/0/76a914119b /0/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/1337 2688ac/1337 d6be34ccf6edddc3cf69842dce d6be34ccf6edd dc3cf69842dce99fe503bf632b 99fe503bf632ba2c2adb0f95c6 a2c2adb0f95c63f6706ae0c52 3f6706ae0c52/1/76a914119b /1/76a914119b098e2e98 098e2e98 0a229e139a9ed01a469e518e6f 0a229e139a9ed 01a469e518e6f2688ac/200000 2688ac/20000000 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1 0e3e2357e806b6cdb1f70b54c3 a3a17b6714ee1f0e68bebb44a7 f0e68bebb44a74b1efd512098 4b1efd512098/0/410496b538 /0/410496b538e853519c e853519c 726a2c91e61ec11600ae139081 726a2c91e61ec 11600ae1390813a627c66fb8be 3a627c66fb8be7947be63c52da 7947be63c52da7589379515d4 7589379515d4e0a604f814178 e0a604f8141781e622947 1e622947 21166bf621e73a82cbf2342c85 21166bf621e73 a82cbf2342c858eeac/5000000 8eeac/5000000000 000
13
Appendix A: Operadores de Linguagem de Script de Transa•‹o, Constantes e S’mbolos Adiciona um valor no stack demonstra os operadores operadores para adicionar adicionar valor no stack (pilha). Table 1. Adiciona um valor no stack S’mbolo
Valor (hex)
Descri•‹o
OP_0 or OP_FALSE
0x00
Um array vazio Ž adicionado no stack
1-75
0x01-0x4b
Adiciona os pr—ximos N bytes no stack, quando N Ž 1 a 75 bytes
OP_PUSHDATA1
0x4c
O pr—ximo script byte contŽm N, adiciona os seguintes N bytes no stack
OP_PUSHDATA2
0x4d
Os pr—ximos dois script bytes contŽm N, adiciona os seguintes N bytes no stack
OP_PUSHDATA4
0x4e
Os pr—ximos quatro script bytes contŽm N, adiciona os seguintes N bytes no stack
OP_1NEGATE
0x4f
Adiciona o valor "Ð1" no stack
OP_RESERVED
0x50
Suspenso - Transa•‹o inv‡lida a menos que seja encontrada em uma cl‡usula OP_IF n‹oexecutada
OP_1 or OP_TRUE
0x51
Adiciona o valor "1" no stack
OP_2 to OP_16
0x52 to 0x60
Para OP_N, adiciona o valor "N" no stack. Por exemplo, OP_2 adiciona "2"
Controle de fluxo condicional mostra os operadores operadores de controle de de fluxo condicionais. Table 2. Controle de fluxo condicional S’mbolo
Valor (hex)
Descri•‹o
OP_NOP
0x61
N‹o fazer nada
1
S’mbolo
Valor (hex)
Descri•‹o
OP_VER
0x62
Suspenso - Transa•‹o inv‡lida a menos que seja encontrada em uma cl‡usula OP_IF n‹oexecutada
OP_IF
0x63
Executa as declara•›es a seguir se o topo do stack n‹o for 0
OP_NOTIF
0x64
Executa as declara•›es a seguir se o topo do stack n‹o for 0
OP_VERIF
0x65
Pare - Transa•‹o inv‡lida
OP_VERNOTIF
0x66
Pare - Transa•‹o inv‡lida
OP_ELSE
0x67
Executa apenas se as declara•›es anteriores n‹o foram executadas
OP_ENDIF
0x68
Termina o bloco OP_IF, OP_NOTIF, OP_ELSE
OP_VERIFY
0x69
Verifica o topo do stack, suspende e invalida a transa•‹o t ransa•‹o se n‹o for TRUE
OP_RETURN
0x6a
Interrompe e invalida a transa•‹o
Opera•›es de stack demonstra stack demonstra os operadores usados para manipular o stack. Table 3. Opera•›es de stack S’mbolo
Valor (hex)
Descri•‹o
OP_TOALTSTACK
0x6b
Exibe o item do topo do stack e o empurra para o stack alternativo
OP_FROMALTSTACK
0x6c
Exibe o item do topo do stack alternativo e o empurra para o stack
OP_2DROP
0x6d
Exibe os dois itens do topo do stack
OP_2DUP
0x6e
Duplica os dois itens no topo do stack
OP_3DUP
0x6f
Duplica os trs itens no topo do stack
2
S’mbolo
Valor (hex)
Descri•‹o
OP_2OVER
0x70
Copia o terceiro e quarto itens do stack para o topo
OP_2ROT
0x71
Move o quinto e sexto itens no stack para o topo
OP_2SWAP
0x72
Troca os dois pares de itens no topo do stack
OP_IFDUP
0x73
Duplica o item no topo do stack se ele n‹o for 0
OP_DEPTH
0x74
Conta os itens no stack e empurra o resultado da contagem
OP_DROP
0x75
Exibe o item do topo do stack
OP_DUP
0x76
Duplica o item no topo do stack
OP_NIP
0x77
Exibe o segundo item do stack
OP_OVER
0x78
Copia o segundo item do stack e o empurra para o topo
OP_PICK
0x79
Exibe o valor N do topo, ent‹o copia o N¼ item para o topo do stack
OP_ROLL
0x7a
Exibe o valor N do topo, ent‹o move o N¼ item para o topo do stack
OP_ROT
0x7b
Inverte os trs itens do topo do stack
OP_SWAP
0x7c
Permuta os trs itens do topo no stack
OP_TUCK
0x7d
Copia o item do topo e insere entre o topo e o segundo item.
Opera•›es de peda•os de string demonstra string demonstra as opera•›es de string. Table 4. Opera•›es de peda•os de string S’mbolo
Valor (hex)
Descri•‹o
OP_CAT
0x7e
Desativado (concatena os dois itens do topo)
OP_SUBSTR
0x7f
Desativado (retorna substring)
3
S’mbolo
Valor (hex)
Descri•‹o
OP_LEFT
0x80
Desativado (retorna left substring)
OP_RIGHT
0x81
Desativado (retorna right substring)
OP_SIZE
0x82
Calcula o comprimento da string do item do topo e empurra o resultado
AritmŽtica bin‡ria e condicionais demonstra condicionais demonstra os operadores de aritimŽtica bin‡ria e de l—gica booleana. Table 5. AritmŽtica bin‡ria e condicionais S’mbolo
Valor (hex)
Descri•‹o
OP_INVERT
0x83
Desativado (Inverte os bits do item do topo)
OP_AND
0x84
Desativado (Booleano AND dos dois itens do topo)
OP_OR
0x85
Desativado (Booleano OR dos dois itens do topo)
OP_XOR
0x86
Desativado (Booleano XOR dos dois itens do topo)
OP_EQUAL
0x87
Empurra TRUE (1) se os dois itens do topo forem exatamente iguais, caso contr‡rio empurra FALSE (0)
OP_EQUALVERIFY
0x88
O mesmo que o OP_EQUAL, mas executa o OP_VERIFY ap—s para para suspender se n‹o for TRUE
OP_RESERVED1
0x89
Suspenso - Transa•‹o inv‡lida a menos que seja encontrada em uma cl‡usula OP_IF n‹oexecutada
OP_RESERVED2
0x8a
Suspende - Transa•‹o inv‡lida a menos que seja encontrada em uma cl‡usula OP_IF n‹oexecutada
Operadores numŽricos demonstra numŽricos demonstra os operadore operadoress numŽricos (aritmŽticos). Table 6. Operadores numŽricos
4
S’mbolo
Valor (hex)
Descri•‹o
OP_1ADD
0x8b
Adiciona 1 ao item do topo
OP_1SUB
0x8c
Subtrai 1 do item do topo
OP_2MUL
0x8d
Desativado (multiplica o item do topo por 2)
OP_2DIV
0x8e
Desativado (divide o item do topo por 2)
OP_NEGATE
0x8f
Inverte o sinal do item do topo
OP_ABS
0x90
Muda o sinal do item do topo para positivo
OP_NOT
0x91
Se o item do topo Ž 0 ou 1 Booleano o inverte, caso contr‡rio retorna 0
OP_0NOTEQUAL
0x92
Se o item do topo Ž zero, retorna 0, caso contr‡rio retorna 1
OP_ADD
0x93
Exibe os dois itens do topo, soma os dois e empurr empurra a o resultado
OP_SUB
0x94
Exibe os dois itens do topo, subtrai o primeiro do segundo e empurra o resultado
OP_MUL
0x95
Desativado (multiplica os dois itens do topo)
OP_DIV
0x96
Desativado (divide o segundo item pelo primeiro item)
OP_MOD
0x97
Desativado (a sobra divide o segundo item pelo primeiro item)
OP_LSHIFT
0x98
Desativada (muda o segundo item esquerdo pelo primeiro nœmero de bits do primeiro)
OP_RSHIFT
0x99
Desativado (muda o segundo item direito pelo nœmero de bits do primeiro)
OP_BOOLAND
0x9a
Booleano AND dos dois itens do topo
OP_BOOLOR
0x9b
Booleano OR dos dois itens do topo
5
S’mbolo
Valor (hex)
Descri•‹o
OP_NUMEQUAL
0x9c
Retorna TRUE se os dois itens do topo s‹o iguais a nœmeros
OP_NUMEQUALVERIFY
0x9d
O mesmo que o NUMEQUAL, ent‹o OP_VERIFY para suspender se n‹o for TRUE
OP_NUMNOTEQUAL
0x9e
Retorna TRUE se os dois itens do topo n‹o s‹o iguais a nœmeros
OP_LESSTHAN
0x9f
Retorna TRUE se o segundo item for menor que o item do topo
OP_GREATERTHAN
0xa0
Retorna TRUE se o segundo item for maior do que o item do topo
OP_LESSTHANOREQUAL
0xa1
Retorna TRUE se o segundo item for menor ou igual ao item do topo
OP_GREATERTHANOREQUAL
0xa2
Retorna TRUE se o segundo item for maior ou igual ao item do topo
OP_MIN
0xa3
Retorna o menor dos dois itens do topo
OP_MAX
0xa4
Retorna o maior dos dois itens do topo
OP_WITHIN
0xa5
Retorna TRU se o terceiro item estiver entre o segundo item (ou for igual) e o primeiro item
Opera•›es criptogr‡ficas criptogr‡ficas e de hashing demonstra hashing demonstra os opera•›es de fun•‹o criptogr‡fica. Table 7. Opera•›es criptogr‡ficas e de hashing S’mbolo
Valor (hex)
Descri•‹o
OP_RIPEMD160
0xa6
Retorna o hash RIPEMD160 do item do topo
OP_SHA1
0xa7
Retorna o hash SHA1 do item do topo
OP_SHA256
0xa8
Retorna o hash SHA256 do item do topo
OP_HASH160
0xa9
Retorna o hash RIPEMD160(SHA256(x)) RIPEMD160(S HA256(x)) do item do topo
6
S’mbolo
Valor (hex)
Descri•‹o
OP_HASH256
0xaa
Retorna o hash SHA256(SHA256(x)) do item do topo
OP_CODESEPARATOR
0xab
Marca o in’cio dos dados verificados pela assinatura
OP_CHECKSIG
0xac
Exibe uma chave pœblica e assinatura e valida a assinatura para os dados hashados da transa•‹o, retorna TRUE se corresponde
OP_CHECKSIGVERIFY
0xad
O mesmo que o CHECKSIG, ent‹o OP_VERIFY para suspender se n‹o for TRUE
OP_CHECKMULTISIG
0xae
Executa o CHECKSIG para cada par de assinatura e chave pœblica fornecido. Todos devem corresponder. Um bug na implementa•‹o exibe um valor extra, use o prefixo OP_NOP como uma solu•‹o tempor‡ria
OP_CHECKMULTISIGVERIFY
0xaf
O mesmo que o CHECKMULTISIG, ent‹o OP_VERIFY para suspender se n‹o for TRUE
N‹o-operadores demonstra N‹o-operadores demonstra os s’mbolos n‹o-operadores Table 8. N‹o-operadores S’mbolo
Valor (hex)
Descri•‹o
OP_NOP1-OP_NOP10
0xb0-0xb9
N‹o faz nada, ignorado
C—digos OP reservados para uso interno pelo parser parser demonstra demonstra os c—digos de operador reservado para o parser interno de script. Table 9. C—digos OP reservados para uso interno pelo parser S’mbolo
Valor (hex)
Descri•‹o
OP_SMALLDATA
0xf9
Representa o campo de dados pequeno
OP_SMALLINTEGER
0xfa
Representa um campo pequeno de dados numerais
7
S’mbolo
Valor (hex)
Descri•‹o
OP_PUBKEYS
0xfb
Representa os campos de chave pœblica
OP_PUBKEYHASH
0xfd
Representa o campo do hash da chave pœblica
OP_PUBKEY
0xfe
Representa um campo de chave pœblica
OP_INVALIDOPCODE
0xff
Representa qualquer c—digo OP que n‹o est‡ atualmente designado
8
