——Bitcoin

Bitcoin ——
Um Sistema de
Um Sistema de
Dinheiro Eletrônico
Dinheiro Eletrônico
Ponto-a-Ponto
Ponto-a-Ponto
Satoshi Nakamoto
Satoshi Nakamoto
 SUMÁRIO

Sumário ii

Resumo iii

1 Introdução 1

2 Sistema da Moeda 3
2.1 Transações . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Servidor de Estampa Temporal . . . . . . . . . . . 5
2.3 Prova-de-Trabalho . . . . . . . . . . . . . . . . . . 6
2.4 Rede . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Incentivo . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Recuperando Espaço em Disco . . . . . . . . . . . 10
2.7 Verificação de Pagamento Simplificada . . . . . . . 12
2.8 Combinando e dividindo valores . . . . . . . . . . 13
2.9 Privacidade . . . . . . . . . . . . . . . . . . . . . . 15
2.10 Cálculos . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Conclusão 23

ii
 RESUMO

ma forma puramente ponto-a-ponto de dinheiro eletrô-

U nico permitiria que pagamentos pela internet fossem

feitos de uns aos outros sem passar por uma instituição
financeira. Assinaturas digitais proporcionam parte da solução,
mas os principais benefícios são perdidos se um terceiro de confi-
ança ainda for necessário para se prevenir os gastos-duplos.
Propomos uma solução para o problema do gasto-duplo usando
uma rede ponto-a-ponto. A rede temporalmente estampa as tran-
sações ao armazenar seus hashes em uma cadeia contínua de
prova-de-trabalho baseada em hash, formando um registro que
não pode ser alterado sem que a prova-de-trabalho seja refeita.
A cadeia mais longa não só serve de prova da sequência dos acon-
tecimentos testemunhados, mas também prova que tem origem
no grupo de maior capacidade de processamento.
Desde que a maioria da capacidade de processamento seja con-
trolada por nodos que não estejam em conluio contra a rede, eles
Do documento chamado Bitcoin Whitepaper∗ , com a tradução de @rhlinden† , revisão de
∼

@swfsql‡ , imagem de fundo por Ken S.§ .

∗
⟨https://bitcoin.org/bitcoin.pdf⟩ † ⟨https://github.com/rhlinden/⟩
‡
⟨https://github.com/swfsql/⟩
§
⟨https://www.meetup.com/Tokyo-Bitcoin-Meetup-Group/photos/3091592/345785282/⟩

iii
 RESUMO

produzirão a cadeia mais longa e prevalecerão sobre os atacantes.

A rede em si exige pouco em termos de estrutura. As mensagens
são difundidas sem muito compromisso, e os nodos podem aban-
donar e retornar à rede à vontade, aceitando a cadeia mais longa
de prova-de-trabalho como prova do que aconteceu enquanto
estiveram fora. 2

iv
 capítulo 1

INTRODUÇÃO

comércio na internet vem dependendo quase que exclu-

O sivamente das instituições financeiras atuando como

terceiros de confiança para o processamento de paga-
mentos eletrônicos. Mesmo que o sistema funcione bem o sufici-
ente para a maioria das transações, ele ainda sofre das fraquezas
inerentes ao modelo baseado na confiança.
Transações totalmente irreversíveis não são realmente possíveis,
uma vez que as instituições financeiras não podem escapar da
mediação das disputas. O custo da mediação aumenta os custos
das transações, limitando o tamanho mínimo praticável delas e
restringindo a possibilidade de pequenas transações casuais, e
há um custo mais alargado pela impossibilidade de se efetuar
pagamentos irreversíveis por serviços irreversíveis. Com a possi-
bilidade do reembolso, a necessidade por confiança aumenta. Os
comerciantes devem ser cautelosos com os seus clientes, exigindo
mais informação do que precisaríam. Uma certa porcentagem de
fraude é aceita como inevitável.
Estes custos e incertezas do pagamento podem ser evitados, pes-
soalmente, pelo uso do dinheiro físico, mas não há um mecanismo
para fazer pagamentos por um meio de comunicação sem ter um
terceiro de confiança.
1
 CAPÍTULO 1. INTRODUÇÃO

O que é necessário é um sistema de pagamento eletrônico

baseado na prova criptográfica ao invés da confiança, permitindo
que qualquer um transacione com outro de forma direta e sem
a necessidade de um terceiro de confiança. Transações cujas re-
versões forem computacionalmente impraticáveis protegeríam
os vendedores das fraudes, e mecanismos de garantia podem ser
facilmente implementados para proteger os consumidores.
Neste trabalho, propomos uma solução para o problema do gasto-
duplo usando um servidor distribuído e ponto-a-ponto de es-
tampas temporais para gerar provas computacionais da ordem
cronológica das transações. O sistema é seguro enquanto os no-
dos honestos coletivamente controlarem mais capacidade de pro-
cessamento do que qualquer outro grupo coordenado de nodos
atacantes. 2

2
 capítulo 2

SISTEMA DA MOEDA

2.1 Transações

efinimos uma moeda eletrônica como uma cadeia de

D assinaturas digitais. Cada proprietário transfere a mo-

eda para o próximo assinando digitalmente um hash da
transação anterior e a chave pública do próximo proprietário e
adicionando estas ao final da moeda. Um beneficiário pode ve-
rificar as assinaturas para verificar a cadeia de propriedade. Ver
Figura 2.1 – Cadeia de Propriedade.
O problema obviamente é que o beneficiário não pode verificar
se um dos proprietários anteriores não fez algum gasto-duplo da
moeda.
Uma solução comum é introduzir uma autoridade central de confi-
ança, ou um fabricante, que inspecione cada transação para evitar
o gasto-duplo. A cada transação, a moeda deveria retornar ao
fabricante que então forjaria uma nova moeda, e apenas as moe-
das forjadas diretamente por ele seriam confiáveis de não serem
gasto-duplos. O problema desta solução é que o destino de todo o
sistema monetário dependeria da empresa que for o fabricante, e
cada transação teria que passar por ele, tal como acontece em um
banco.
3
 CAPÍTULO 2. SISTEMA DA MOEDA

Figura 2.1: Cadeia de Propriedade

Precisamos de uma forma do beneficiário poder saber que os

proprietários anteriores não assinaram nenhuma transação an-
teriormente. Para este propósito, a transação mais antiga é a
que conta, então não precisamos nos importar com tentativas
posteriores de gasto-duplo.
A única forma de se confirmar a ausência de uma transação é
pelo conhecimento de todas as transações.
No modelo baseado num fabricante, ele conhecia todas as tran-
sações e saberia qual chegou primeiro. Para conseguir isso sem
uma terceiro de confiança, as transações precisam ser anunciadas
4
 2.2. SERVIDOR DE ESTAMPA TEMPORAL

publicamente1, e precisamos de um sistema para que os partici-

pantes possam concordar em um único histórico da ordem em que
as transações foram recebidas. O beneficiário precisa da prova de
que na data destacada por cada transação, a maioria dos nodos
concordou de que ela foi a primeira a ser recebida.

2.2 Servidor de Estampa Temporal

A solução que propomos começa com um servidor de estampa
temporal.
Um servidor de estampa temporal funciona por pegar o hash de
um bloco de itens a serem temporalmente estampados e ampla-
mente publicar tal hash, como em um jornal ou em uma publicação
no Usenet 2345.
A estampa temporal prova que o dado deve ter existido naquela
hora, para que, obviamente, tenha sido parte do hash. Cada es-
tampa temporal adquire a estampa temporal anterior em seu hash,
formando uma corrente, com cada estampa temporal adicional
1
W. Dai, b-money∗ , 1998. 2
2
H. Massias, X.S. Avila, e J.-J. Quisquater, Design of a secure timestamping service with minimal
trust requirements, em 20th Symposium on Information Theory in the Benelux, Maio de 1999. 2
3
S. Haber, W.S. Stornetta, How to time-stamp a digital document, em Journal of Cryptology, vol
3, num 2, páginas 99-111, 1991. 2
4
D. Bayer, S. Haber, W.S. Stornetta, Improving the efficiency and reliability of digital time-
stamping, em Sequences II: Methods in Communication, Security and Computer Science, páginas
329-334, 1993. 2
5
S. Haber, W.S. Stornetta, Secure names for bit-strings, em Proceedings of the 4th ACM Conference
on Computer and Communications Security, páginas 28-35, Abril de 1997. 2

∗
⟨http://www.weidai.com/bmoney.txt⟩

5
 CAPÍTULO 2. SISTEMA DA MOEDA

Figura 2.2: Servidor de Estampa Temporal

reforçando a anterior. Ver Figura 2.2 – Servidor de Estampa Tem-

poral.

2.3 Prova-de-Trabalho
Para implementar um servidor distribuído de estampas temporais
que seja também ponto-a-ponto, precisaremos usar um sistema de
prova-de-trabalho similar ao Hashcash6 de Adam Back, ao invés
de um jornal ou de publicações na Usenet. A prova-de-trabalho
significa procurar por um valor que quando hasheado, como por
pelo SHA-256, o hash comece por uma quantidade de bits zerados.
Na média, o trabalho necessário é exponencial com a quantidade
de bits zerados necessários e pode ser verificado por um único
hasheamento.
Para a nossa rede de estampas temporais, implementamos
a prova-de-trabalho pelo incremento de um número-consumível
6
A. Back, Hashcash - a denial of service counter-measure∗ , 2002. 2

∗
⟨http://www.hashcash.org/papers/hashcash.pdf⟩

6
2.3. PROVA-DE-TRABALHO

Figura 2.3: Corrente de Prova-de-Trabalho

no bloco até que um valor seja encontrado que dê ao hash do

bloco os bits zerados necessários. Uma vez despendido o esforço
de processamento para satisfazer a prova-de-trabalho, o bloco
não pode ser alterado sem se refazer o trabalho. Como blocos
posteriores são encadeados após ele, o trabalho para a alteração do
bloco incluiria refazer todos aqueles blocos após ele. Ver Figura 2.3
– Corrente de Prova-de-Trabalho.
A prova-de-trabalho também resolve o problema de determi-
nar a representatividade na tomada de decisão guiada pela maioria.
Se a maioria fosse baseada em um-endereço-IP-um-voto, ela po-
deria ser subvertida por alguém capaz de reservar muitos IPs. A
prova-de-trabalho é essencialmente um-processador-um-voto.
A decisão da maioria é representada pela corrente mais longa, que
tem a maior prova-de-trabalho investida em si.
Se a maioria da capacidade de processamento for controlada por
nodos honestos, a corrente honesta crescerá mais rapidamente e
ultrapassará qualquer outra corrente. Para modificar um bloco
antigo, um atacante teria que refazer a prova-de-trabalho daquele
7
 CAPÍTULO 2. SISTEMA DA MOEDA

bloco e de todos os blocos posteriores e ainda alcançar e ultrapas-

sar o trabalho dos nodos honestos. Vamos mostrar adiante que a
probabilidade de um atacante lento conseguir alcançar diminui
exponencialmente à medida em que blocos subsequentes forem
adicionados.
Para compensar a velocidade do hardware crescente e a va-
riação de interesse em manter nodos em execução ao longo do
tempo, a dificuldade da prova-de-trabalho é determinada por uma
média móvel que visa uma quantidade média de blocos por hora.
Se forem gerados muito rápido, a dificuldade aumenta.

2.4 Rede
Os passos para manter a rede são os seguintes:
1. Novas transações são difundidas para todos os nodos.
2. Cada nodo recolhe novas transações para um bloco.
3. Cada nodo trabalha em encontrar uma difícil prova-de-trabalho
para o seu bloco.
4. Quando um nodo encontra uma prova-de-trabalho, ele di-
funde o bloco para todos os nodos.
5. Os nodos aceitam o bloco apenas se todas as transações
neste são válidas e se não foram ainda gastas.
6. Os nodos expressam a aceitação do bloco ao trabalhar na
criação do próximo bloco na cadeia, usando o hash do bloco
aceito como o hash anterior.
Os nodos sempre consideram a cadeia mais longa como a cor-
8
2.5. INCENTIVO

reta e continuarão trabalhando para estendê-la. Se dois nodos

simultaneamente difundirem versões diferentes do próximo bloco,
alguns nodos podem receber um ou o outro em primeiro lugar.
Neste caso, trabalham no primeiro que receberam, mas guardam
a outra ramificação caso ela se torne a maior. O desempate acon-
tece quando a próxima prova-de-trabalho for encontrada e uma
ramificação crescer; os nodos que estavam trabalhando na outra
ramificação vão então trocar para a maior.
A difusão de novas transações não precisa alcançar a todos
os nodos. Desde que chegue a bastantes nodos, elas acabarão
entrando em algum bloco. As difusões de blocos também toleram
a perda de mensagens. Se um nodo não receber um bloco, ele irá
solicitá-lo quando receber o próximo e constatar que faltou um.

2.5 Incentivo
Por convenção, a primeira transação de um bloco é uma transação
especial que dá início à uma nova moeda, de propriedade do cria-
dor do bloco. Isto dá um incentivo para os nodos apoiarem a rede,
e constitui uma forma de se introduzir moedas em circulação uma
vez que não há uma autoridade central para emiti-las.
A adição regular de uma quantia fixa de novas moedas é seme-
lhante a mineradores de ouro gastando recursos para adicionar
ouro em circulação. No nosso caso, tempo de processamento e
eletricidade são gastos.
O incentivo também pode ser financiado por taxas sobre as
9
 CAPÍTULO 2. SISTEMA DA MOEDA

transações. Se o valor de saída de uma transação for menor do

que o valor de entrada, a diferença é a taxa sobre a transação que é
adicionada ao valor de incentivo do bloco que contém a transação.
Quando uma certa quantia de moedas estiver em circulação, o
incentivo pode passar a ser integralmente provido pelas taxas
sobre as transações e estar livre de inflação.
O incentivo pode encorajar os nodos a permanecerem hones-
tos. Se um ganancioso atacante conseguir reunir mais capacidade
de processamento que todos os nodos honestos, terá ainda que
escolher entre usá-la para enganar as pessoas tomando seus pa-
gamentos de volta, ou usá-las para gerar novas moedas. Deverá
achar mais rentável cumprir as regras, as mesmas que o favore-
cem com maior quantia de novas moedas do que todos os outros
juntos, do que comprometer o sistema e a fundamentação da sua
própria riqueza.

2.6 Recuperando Espaço em Disco

Depois que a última transação de uma moeda estiver enterrada

abaixo de blocos o suficiente, as transações anteriores podem ser
descartadas para poupar espaço em disco. Para facilitar isso sem
comprometer o hash do bloco, as transações são hasheadas em
10
 2.6. RECUPERANDO ESPAÇO EM DISCO

Figura 2.4: Poda de uma Árvore de Markle

uma Árvore de Markle789, onde somente a raíz é incluída no hash

do bloco. Blocos antigos podem ser compactados pela remoção dos
ramos da árvore. Os hashes interiores não precisam ser mantidos.
Ver Figura 2.4 – Poda de uma Árvore de Markle.
Um cabeçalho de bloco sem transações deverá ter cerca de
80 bytes. Se considerarmos blocos gerados a cada 10 minutos,
80 bytes 1 cabeçalho 60 minutos horas dias MB
cabeçalho ∗ 10 minutos ∗ hora ∗ 24 dia ∗ 365ano = 4.2ano . Com
7
H. Massias, X.S. Avila, e J.-J. Quisquater, Design of a secure timestamping service with minimal
trust requirements, em 20th Symposium on Information Theory in the Benelux, Maio de 1999. 2
8
S. Haber, W.S. Stornetta, Secure names for bit-strings, em Proceedings of the 4th ACM Conference
on Computer and Communications Security, páginas 28-35, Abril de 1997. 2
9
R.C. Merkle, Protocols for public key cryptosystems, em Proc. 1980 Symposium on Security and
Privacy, IEEE Computer Society, páginas 122-133, Abril de 1980. 2

11
 CAPÍTULO 2. SISTEMA DA MOEDA

computadores geralmente vendidos com 2 GB de RAM em 2008,

e a Lei de Moore prevendo o crescimento de 1.2 GB/ano, o arma-
zenamento não deverá ser um problema mesmo que os blocos
tenham que ser mantidos em memória.

2.7 Verificação de Pagamento

Simplificada
É possível verificar os pagamentos sem operar um nodo de rede
completo. O usuário só precisa manter uma cópia dos cabeçalhos
dos blocos da cadeia mais longa de provas-de-trabalhos, que pode
ser obtida através de requisições aos nodos da rede até que esteja
convencido de que obteve a cadeia mais longa, e então obter o
ramo de Markle que atrela a transação ao bloco em que ela esteja
temporalmente estampada. Ele não pode conferir a transação por
si só, mas por estar atrelada a algum ponto da cadeia, pode verificar
que um nodo da rede a aceitou, e blocos posteriores confirmam
ainda mais que a rede a aceitou. Ver Figura 2.5 – Observação de
Transação Aceita.
Assim a verificação é confiável desde que os nodos honestos
controlem a rede, mas é mais vulnerável se a rede for dominada
por um atacante. Apesar dos nodos da rede poderem eles próprios
verificarem as transações, o método simplificado pode ser enga-
nado por transações fabricadas por um atacante enquanto este
puder continuar dominando a rede. Uma estratégia de mitigação
seria aceitar alertas dos nodos da rede quando estes detectarem
12
2.8. COMBINANDO E DIVIDINDO VALORES

Figura 2.5: Observação de Transação Aceita

um bloco inválido, sugerindo ao programa do usuário que o bloco

inteiro e as transações sujeitas ao alerta sejam baixados para con-
firmar a inconsistência. Empresas que frequentemente recebam
pagamentos provavelmente ainda vão querer operar os seus pró-
prios nodos para terem uma segurança mais independente e uma
verificação mais rápida.

2.8 Combinando e dividindo valores

Embora fosse possível lidar com as moedas separadamente, seria
inconveniente fazer uma transação para cada parte de uma transfe-
13
 CAPÍTULO 2. SISTEMA DA MOEDA

Figura 2.6: Múltiplas Entradas e Saídas

rência. Para permitir dividir e combinar as quantias, as transações

contêm múltiplas entradas e saídas. Normalmente haverá ou uma
única entrada de uma transação anterior de montante maior, ou
múltiplas entradas combinando montantes menores, e no máximo
duas saídas: uma para o pagamento, e outra retornando o troco,
se houver, de volta para o remetente. Ver Figura 2.6 – Múltiplas
Entradas e Saídas.
Note-se que uma dependência ser dispersa, como quando uma
transação depende de várias outras, e estas dependem de ainda
mais, não é um problema. Nunca há a necessidade de se extrair
uma cópia completamente independente da história de uma tran-
sação.

14
2.9. PRIVACIDADE

Figura 2.7: Modelos de Privacidade

2.9 Privacidade
O modelo bancário tradicional fornece uma certa privacidade ao
limitar o acesso à informação às partes envolvidas e ao terceiro
de confiança. A necessidade de se anunciar publicamente todas as
transações inviabiliza este método, mas a privacidade ainda poder
ser mantida quebrando o fluxo de informação em um outro ponto:
por manter-se as chaves públicas anônimas. O público pode ver
que alguém está enviando uma quantia a outra pessoa, mas sem a
informação que possa relacionar transação a alguém. Isto é similar
ao nível de informação publicado pelas bolsas de valores, onde
data e montante das trocas individuais, a "fita", é tornada pública,
mas sem divulgar quem eram as partes. Ver Figura 2.7 – Modelos
de Privacidade.
Como proteção adicional, um novo par de chaves deveria ser
utilizado para cada transação a fim de evitar que fossem vinculadas
15
 CAPÍTULO 2. SISTEMA DA MOEDA

a um proprietário em comum. Uma certa vinculação é inevitá-

vel nas transações com múltiplas entradas, que necessariamente
revelam que suas entradas pertencem a um mesmo proprietário.
O risco é que, se o proprietário de uma chave for descoberto, é
possível revelar outras transações que pertenceram ao mesmo
proprietário.

2.10 Cálculos
Consideremos o cenário em que um atacante tenta gerar uma ca-
deia alternativa mais rápido do que a cadeia honesta. Mesmo que
consiga, não deixa o sistema exposto à mudanças arbitrárias, como
pela criação de quantidades a partir do nada, ou pela apropriação
de montantes que nunca pertenceram ao atacante. Os nodos não
aceitarão uma transação inválida como um pagamento, e os nodos
honestos nunca aceitarão um bloco que as contenham. Um ata-
cante pode apenas tentar mudar uma de suas próprias transações
para recuperar uma quantia que tenha gasto recentemente.
A corrida entre a cadeia honesta e uma cadeia atacante pode
ser caracterizada como um Passeio Aleatório Binomial. O evento
de sucesso é da cadeia honesta ser estendida por um bloco, au-
mentando a sua liderança em +1, e o evento de falha é da cadeia
do atacante ser estendida por um bloco, reduzindo a distância em
−1.
A probabilidade de um atacante alcançar a partir de um de-
terminado déficit é semelhante ao problema da Ruína do Jogador.
16
 2.10. CÁLCULOS

Imagine um jogador com crédito ilimitado que comece com déficit

e que jogue uma quantidade potencialmente infinita de vezes para
tentar alcançar o empate. Podemos calcular a probabilidade dele
alguma vez chegar ao empate, ou que um atacante alguma vez
alcance a cadeia honesta, como se segue10:
• 𝑝 = probabilidade de um nodo honesto encontrar o próximo
bloco.
• 𝑞 = probabilidade de um atacante encontrar o próximo bloco.
• 𝑞𝑧 = probabilidade de que o atacante irá alguma vez recupe-
rar de 𝑧 blocos de atraso.
{
1, se 𝑝 ≤ 𝑞
𝑞𝑧 =
(𝑞/𝑝)𝑧 , se 𝑝 > 𝑞
Dado a nossa suposição de que 𝑝 > 𝑞, a probabilidade cai
exponencialmente com o aumento da quantidade de blocos que
o atacante tem que alcançar. Dada a maré contrária, se ele não
der um salto de sorte para frente bem cedo, suas chances vão se
desvanecendo enquanto vai ficando mais para trás.
Consideremos agora quanto tempo o beneficiário de uma nova
transação deverá esperar até estar suficientemente certo de que
o remetente não poderá modificar a transação. Assumimos que
o remetente é um atacante que pretende que o beneficiário acre-
dite momentaneamente que lhe pagou, e que após algum tempo
reverterá o pagamento para ser reembolsado. O beneficiário será
alertado quando isso acontecer, mas o remetente espera que isso
10
W. Feller, An introduction to probability theory and its applications, 1957. 2

17
 CAPÍTULO 2. SISTEMA DA MOEDA

seja tarde demais para ele.

O beneficiário gera um novo par de chaves e entrega a chave
pública ao remetente pouco tempo antes da assinatura. Isso im-
pede o remetente de preparar uma cadeia de blocos antecipada-
mente, de trabalhar nela continuamente até ter a sorte de ficar à
frente o suficiente para então efetuar a transação neste momento.
Assim que a transação é enviada, o remetente desonesto começa a
trabalhar secretamente em uma cadeia paralela contendo a versão
alternativa da sua transação.
O beneficiário aguarda até que a transação esteja adicionada a
um bloco e que 𝑧 blocos tenham sido posteriormente encadeados.
Ele não sabe exatamente o progresso atingido pelo atacante, mas
assumindo que os blocos honestos levaram o tempo médio já
esperado para cada bloco, o potencial progresso do atacante será
uma distribuição Poisson com o valor esperado:

𝜆 = 𝑧𝑞/𝑝

Para obter a probabilidade de que o atacante ainda poderia al-

cançar, multiplicamos a densidade de Poisson para cada progresso
que ele poderia ter feito pela probabilidade dele ainda alcançar
daquele ponto:
{
+∞
𝜆𝑘 𝑒 −𝜆 (𝑞/𝑝)𝑧−𝑘 se 𝑘 ≤ 𝑧
∑ ∗
𝑘=0
𝑘! 1 se 𝑘 > 𝑧

Reorganizando para evitar a cauda infinita da distribuição...

18
2.10. CÁLCULOS

𝑧
𝜆𝑘 𝑒 −𝜆 𝑘 𝑧−𝑘
1−∑ (1 − )
𝑘=0
𝑘! 𝑝

Convertendo para código em 𝐶...

# include <math.h>
double AttackerSuccessProbability(double q, int z) {
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; i <= k; k++>) {
double poisson = exp(-lambda);
for (i = 1; i <= k; i++>) poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}

Obtendo alguns resultados, podemos ver que a probabilidade

cai exponencialmente com 𝑧.
19
 CAPÍTULO 2. SISTEMA DA MOEDA

⎧
⎪ 𝑃 = 1.0000000, se 𝑧 =0
⎪
⎪
⎪
⎪ 𝑃 = 0.2045873, se 𝑧 =1
⎪
⎪
⎪ 𝑃 = 0.0509779, se 𝑧 =2
⎪
⎪
⎪
⎪ 𝑃 = 0.0131722, se 𝑧 =3
⎪
⎪
⎪ 𝑃 = 0.0034552, se 𝑧 =4
⎪
para 𝑞 = 0.1.. ⎨𝑃 = 0.0009137, se 𝑧 =5
⎪
⎪
⎪
⎪ 𝑃 = 0.0002428, se 𝑧 =6
⎪
⎪
⎪ 𝑃 = 0.0000647, se 𝑧 =7
⎪
⎪
⎪ 𝑃 = 0.0000173, se 𝑧 =8
⎪
⎪
⎪
⎪ 𝑃 = 0.0000046, se 𝑧 =9
⎪
⎪
⎩𝑃 = 0.0000012, se 𝑧 = 10

⎧
⎪ 𝑃 = 1.0000000, se 𝑧 =0
⎪
⎪
⎪
⎪ 𝑃 = 0.1773523, se 𝑧 =5
⎪
⎪
⎪ 𝑃 = 0.0416605, se 𝑧 = 10
⎪
⎪
⎪
⎪ 𝑃 = 0.0101008, se 𝑧 = 15
⎪
⎪
⎪ 𝑃 = 0.0024804, se 𝑧 = 20
⎪
para 𝑞 = 0.3.. ⎨𝑃 = 0.0006132, se 𝑧 = 25
⎪
⎪
⎪
⎪ 𝑃 = 0.0001522, se 𝑧 = 30
⎪
⎪
⎪ 𝑃 = 0.0000379, se 𝑧 = 35
⎪
⎪
⎪ 𝑃 = 0.0000095, se 𝑧 = 40
⎪
⎪
⎪
⎪ 𝑃 = 0.0000024, se 𝑧 = 45
⎪
⎪
⎩𝑃 = 0.0000006, se 𝑧 = 50
20
2.10. CÁLCULOS

⎧
⎪ 𝑧 = 5, se 𝑞 = 0.10
⎪
⎪
⎪
⎪ 𝑧 = 8, se 𝑞 = 0.15
⎪
⎪
⎪ 𝑧 = 11, se 𝑞 = 0.20
⎪
⎪
⎪𝑧 = 15, se 𝑞 = 0.25
para 𝑃 < 0.1%.. ⎨
⎪
⎪ 𝑧 = 24, se 𝑞 = 0.30
⎪
⎪
⎪ 𝑧 = 41, se 𝑞 = 0.35
⎪
⎪
⎪
⎪ 𝑧 = 89, se 𝑞 = 0.40
⎪
⎪
⎩𝑧 = 340, se 𝑞 = 0.45
2

21
 capítulo 3

CONCLUSÃO

ropusemos um sistema para transações eletrônicas sem

P depender da confiança.
Começamos com a estrutura usual de moedas baseadas
em assinaturas digitais, que proporcionam um grande controle de
propriedade, mas que é incompleta sem uma forma de prevenir o
gasto-duplo.
Para resolver isso, propomos uma rede ponto-a-ponto usando
prova-de-trabalho para registrar um histórico público de tran-
sações que rapidamente se torna impraticável de se manipular
por um atacante caso os nodos honestos controlem a maioria da
capacidade de processamento.
A rede é robusta dada a sua simplicidade desestruturada. Os no-
dos trabalham em simultâneo com pouca coordenação. Eles não
necessitam ser identificados, uma vez que as mensagens não são
encaminhadas para para uma localização em particular e só preci-
sam ser entregues sem maiores compromissos.
Os nodos podem abandonar e retornar à rede à vontade, acei-
tando a cadeia de prova-de-trabalho como prova do que aconteceu
enquanto estiveram ausentes. Votam com a sua capacidade de
processamento, evidenciando tanto a sua aceitação dos blocos
válidos por trabalhar na extensão deles quanto a sua rejeição dos
23
 CAPÍTULO 3. CONCLUSÃO

blocos inválidos por se recusar a trabalhar nestes outros.

Quaisquer regras ou incentivos necessários podem ser aplicados
com base neste mecanismo de consenso.

24