https://area31.net.br/wiki/api.php?action=feedcontributions&user=Crlsgms&feedformat=atomÁrea31 Hackerspace - Contribuições do usuário [pt-br]2024-03-29T09:49:38ZContribuições do usuárioMediaWiki 1.41.0https://area31.net.br/wiki/index.php?title=Bitcoin:_Um_sistema_de_dinheiro_eletr%C3%B4nico_Ponto-a-Ponto_(P2P)&diff=3825Bitcoin: Um sistema de dinheiro eletrônico Ponto-a-Ponto (P2P)2018-07-26T17:10:08Z<p>Crlsgms: /* Referências */</p>
<hr />
<div><pre><br />
Autor:<br />
<br />
Satoshi Nakamoto<br />
satoshin@gmx.com<br />
[www.bitcoin.org]<br />
Horiginalmente Traduzido por: Eduardo Abreu [www.mestretrader.com]<br />
Revisão: Área31 Hackspace<br />
</pre><br />
<br />
__TOC__<br />
<br />
=== Prefácio ===<br />
<br />
Uma versão puramente ponto-a-ponto (P2P) de dinheiro eletrônico permitiria o envio de<br />
pagamentos online diretamente de uma pessoa para outra, sem ter que passar por uma instituição<br />
financeira. Assinaturas digitais fornecem parte da solução, mas os principais benefícios são<br />
perdidos se um intermediário confiável ainda for necessário para prevenir [https://jus.com.br/artigos/66683/o-que-e-gasto-duplo-e-como-o-bitcoin-e-capaz-de-evita-lo gasto duplo]. Propomos uma solução para o problema de gasto duplo utilizando uma rede ponto-a-ponto.<br />
A rede registra data e hora das transações transformando-as em um hash dentro de uma corrente contínua codificada de<br />
prova de trabalho, formando um registro que não pode ser alterado sem que a prova<br />
de trabalho seja refeita. A corrente mais longa serve não somente como prova da sequência dos<br />
eventos testemunhados, mas tembém prova de que eles vieram de um conjunto maior de poder de CPU.<br />
Enquanto a maior parte do poder de processamento for controlado por nodes (pontos) que não<br />
estão cooperando para atacar a rede, eles irão gerar a corrente mais longa e superar os invasores.<br />
A rede em si requer uma estrutura mínima. Mensagens são transmitidas na base do melhor esforço,<br />
e os nodes podem sair e se juntar novamente a rede à vontade, aceitando a corrente com a maior<br />
“prova de trabalho” como prova do que aconteceu enquanto eles estiveram fora.<br />
<br />
<br />
=== Introdução ===<br />
O comércio pela Internet veio a depender quase que exclusivamente de instituições financeiras servindo<br />
como intermediários confiáveis para processar pagamentos eletrônicos. Enquanto o sistema funciona bem<br />
o suficiente para grande parte das transações, ainda assim, ele sofre da fraqueza inerente desse modelo<br />
baseado em confiança. Na realidade, transações completamente irreversíveis não são possíveis, já que as<br />
instituições financeiras não podem evitar a mediação de disputas. O custo desta mediação aumenta os custos<br />
transacionais, limitando o valor mínimo para uma transação ser viável e eliminando a possibilidade de<br />
transações pequenas e casuais, e há um custo maior na perda da habilidade de fazer pagamentos nãoestornáveis<br />
para serviços nãoestornáveis. Com a possibilidade do estorno, a necessidade de confiança se<br />
torna ainda maior. Comerciantes devem desconfiar de seus clientes, incomodando-os por mais informações<br />
do que seriam realmente necessárias. Um certo percentual de fraude é aceita como inevitável. Estes custos<br />
e incertezas de pagamentos podem ser evitados pessoalmente usando uma moeda física, mas não existe<br />
mecanismo que faça pagamentos em canais de comunicação sem um intermediário confiável.<br />
O que é preciso é um sistema de pagamentos eletrônicos baseado em provas criptográficas ao invés de<br />
confiança, que permita que duas partes interessadas em fazer transações diretamente, as façam sem a<br />
necessidade de um intermediário confiável. Transações que são computacionalmente impraticáveis de<br />
reverter protegeriam vendedores de fraude, e mecanismos de garantia poderiam ser facilmente<br />
implementados para proteger os compradores. Neste artigo, nós propomos uma solução para o problema do<br />
gasto duplo usando um servidor de “carimbos de tempo” (timestamp) distribuído ponto-a-ponto para gerar<br />
uma prova computacional da ordem cronológica das transações. O sistema é seguro desde que os nodes<br />
honestos coletivamente controlem mais poder de processamento do que qualquer grupo cooperante de nodes<br />
do invasor. <br />
<br />
<br />
=== Transações ===<br />
Nós definimos uma moeda eletrônica como uma cadeia de assinaturas digitais. Cada proprietário transfere<br />
a moeda para o próximo, assinando digitalmente um hash das transações anteriores e a chave pública do<br />
próximo proprietário e as adicionando ao fim da moeda. Um beneficiário pode conferir as assinaturas para<br />
verificar a cadeia de propriedade.<br />
<br />
[[Arquivo:Transaction.png]]<br />
<br />
O problema, obviamente, é que o beneficiário não pode verificar se um dos proprietários não gastou<br />
duas vezes a moeda. Uma solução comum é introduzir uma autoridade central confiável, ou uma “Casa da<br />
Moeda”, que verificaria cada transação por gasto duplo. Após cada transação, a moeda seria retornada a<br />
Casa da Moeda que emitiria então uma nova moeda, e apenas moedas emitidas diretamente da Casa da<br />
Moeda seriam confiáveis de não terem sido gastas duas vezes. O problema com esta solução é que o destino<br />
de todo o sistema monetário dependeria da empresa que toma conta da Casa da Moeda, com toda transação<br />
tendo que passar por ela, exatamente como um banco.<br />
<br />
Nós precisamos de uma forma na qual o beneficiário saiba que os donos anteriores não assinaram<br />
nenhuma transação prévia. Para nosso propósito, a transação mais antiga é a transação que conta, então nós<br />
não nos importamos com tentativas subsequentes de gasto duplicado. A única forma de confirmar a ausência<br />
de uma transação é estar ciente de todas as transações. Em um modelo baseado em uma Casa da Moeda, a<br />
casa estava ciente de todas as transações e decidia qual delas chegou primeiro. Para que isso seja feito sem<br />
um intermediário confiável, as transações precisam ser publicamente anunciadas [1], e nós precisamos de<br />
um sistema para os participantes concordarem em um único histórico da ordem na qual elas foram<br />
recebidas. O beneficiário precisa de prova que na hora de cada transação, a maioria dos nodes concordaram<br />
que ela foi a primeira recebida.<br />
<br />
<br />
==== Servidor de Carimbos de tempo ====<br />
A solução que nós propomos começa com um servidor de carimbos de tempo. Um servidor de carimbos de<br />
tempo funciona pegando um hash de um bloco de itens para serem carimbados e publicando amplamente<br />
este hash, assim como em um jornal ou um post na Usenet [2-5]. O carimbo de tempo prova que os dados<br />
precisam ter existido naquele momento, obviamente, para que sejam incluídos no hash. Cada carimbo de<br />
tempo inclui o carimbo de tempo anterior em seu hash, formando uma corrente, com cada carimbo de tempo<br />
adicional reforçando os anteriores. <br />
<br />
[[Arquivo:Timestampserver.png]]<br />
<br />
=== Prova de trabalho ===<br />
Para implementar um servidor de carimbo de tempo distribuído baseado em ponto-a-ponto (P2P), nós utilizaremos um sistema de prova de trabalho similar ao Adam Back’s’ Hashcash [6], em vez de um<br />
jornal ou um post da Usenet. A prova de trabalho envolve procurar por um valor que quando transformado<br />
em hash, como com SHA-256, o hash começa com um número de zero bits. O trabalho médio necessário é<br />
exponencial no número de zero bits necessários e este pode ser verificado executando um único hash.<br />
Para a nossa rede de carimbos de tempo, nós implementamos a prova de trabalho incrementando um<br />
[https://en.bitcoin.it/wiki/Nonce nonce] no bloco até que seja encontrado um valor que dê ao hash do bloco a quantidade requerida de zero bits. Uma vez que o esforço da CPU foi gasto para satisfazer a prova de trabalho, o bloco não pode<br />
ser modificado sem refazer o trabalho. Como os blocos posteriores são inseridos na corrente logo em seguida,<br />
o trabalho para modificar o bloco inclui refazer todos os blocos após este.<br />
<br />
[[Arquivo:ProofOfWork.png]]<br />
<br />
A prova de trabalho também resolve o problema de determinar representação na tomada de decisão da<br />
maioria. Se a maioria estivesse baseada em “um-endereço-IP-um-voto”, ela poderia ser subvertida por<br />
qualquer um capaz de alocar muitos IPs. Prova de trabalho é essencialmente “uma-CPU-um-voto”. A<br />
decisão da maioria é representada pela corrente mais longa, que tem o maior esforço de prova de trabalho<br />
investido nela. Se a maior parte do poder de processamento é controlado por nodes honestos, a corrente<br />
honesta irá crescer mais rapidamente e ultrapassar qualquer corrente competidora. Para modificar um bloco<br />
antigo, um invasor teria que refazer a prova de trabalho do bloco e de todos os blocos posteriores e então<br />
recuperar o atraso e ultrapassar o trabalho dos nodes honestos. Mostraremos adiante que a probabilidade de<br />
um invasor mais lento recuperar o atraso diminui exponencialmente, à medida que blocos subsequentes são<br />
adicionados.<br />
Para compensar o aumento da velocidade do hardware e o interesse variável em rodar os nodes com o<br />
passar do tempo, a dificuldade da prova de trabalho é determinada por uma média móvel visando um<br />
número de blocos por hora. Se os blocos forem gerados muito rápido, a dificuldade aumenta.<br />
<br />
=== Rede ===<br />
Os passos para executar a rede são os seguintes: <br />
<br />
* Novas transações são transmitidas para todos os nodes.<br />
<br />
* Cada node coleta novas transações em um bloco.<br />
<br />
* Cada node trabalha para encontrar uma prova de trabalho difícil para o seu bloco.<br />
<br />
* Quando um node encontra uma prova de trabalho, ele transmite o bloco para todos os nodes.<br />
<br />
* Os nodes aceitam o bloco somente se todas as transações nele são válidas e ainda não foram usadas.<br />
<br />
* Os nodes expressam sua aceitação do bloco trabalhando na criação do próximo bloco da corrente,<br />
usando o hash do bloco aceito como o hash anterior.<br />
<br />
Nodes sempre consideram a maior corrente como a corrente correta e vão continuar trabalhando nela para<br />
estendê-la. Se dois nodes transmitem versões diferentes do mesmo bloco simultaneamente, alguns nodes vão<br />
receber um ou outro primeiro. Neste caso, eles trabalham no primeiro que receberam, mas vão salvar a<br />
outra ramificação no caso dela se tornar a maior. O impasse será solucionado quando a próxima prova de<br />
trabalho for encontrada e uma das ramificações se tornar maior; os nodes que estavam trabalhando na outra<br />
ramificação irão então mudar para a mais longa.<br />
Transmissões de novas transações não necessariamente precisam alcançar todos os nodes. Desde que elas<br />
alcancem muitos nodes, elas vão entrar em algum bloco em breve. As transmissões de blocos também são<br />
tolerantes a mensagens perdidas. Se um node não receber um bloco, ele irá solicitá-lo quando receber o<br />
próximo bloco e perceber que faltou um.<br />
<br />
=== Incentivo ===<br />
Por convenção, a primeira transação de um bloco é uma transação especial que inicia uma nova moeda de<br />
propriedade do criador do bloco. Isso adiciona um incentivo para os nodes suportarem a rede, e estabelece<br />
uma forma de inicialmente distribuir moedas em circulação, já que não existe uma autoridade central para<br />
emitir essas moedas. A adição regular de uma constante de quantidade de novas moedas é análoga a dos<br />
mineradores de ouro gastando recursos para colocar mais ouro em circulação. No nosso caso, tempo de<br />
CPU e eletricidade que são gastos.<br />
O incentivo também pode ser financiado com taxas de transação. Se o valor de saída de uma transação<br />
é menor que o valor de entrada, a diferença é uma taxa de transação que é adicionada ao valor de incentivo<br />
do bloco contendo a transação. Uma vez que um número pré-determinado de moedas estiver entrado em<br />
circulação, o incentivo pode mudar integralmente para taxas de transação e estar completamente livre de<br />
inflação.<br />
O incentivo pode ajudar encorajar os nodes a permanecerem honestos. Se um invasor ganancioso é capaz<br />
de reunir mais poder de processamento do que todos os nodes honestos juntos, ele teria que escolher entre usar esse<br />
poder para fraudar as pessoas roubando de volta os pagamentos, ou usá-lo para gerar novas moedas. Ele<br />
deverá achar mais lucrativo trabalhar conforme as regras, já que elas vão lhe gerar mais moedas do que<br />
todos os outros juntos, do que prejudicar o sistema e a validade de sua própria riqueza.<br />
<br />
=== Recuperando espaço em disco ===<br />
Uma vez que a última transação de uma moeda é enterrada em blocos o suficiente, as transações gastas<br />
anteriormente podem ser descartadas para salvar espaço em disco. Para facilitar esse ato sem quebrar o hash<br />
do bloco, transações são transformadas em hash em uma árvore de Merkle [7][2][5], apenas com a raiz<br />
incluída no hash dos blocos. Os hashes interiores não precisam ser armazenados.<br />
<br />
[[Arquivo:ReclaimingDiskSpace.png]]<br />
<br />
Um cabeçalho de bloco sem transações deve ter em torno de 80 bytes. Se supormos que os blocos são<br />
gerados a cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4.2MB por ano. Com os sistemas de computador<br />
típicos sendo vendidos em 2008 com 2GB de RAM, e a lei de Moore prevendo um aumento de 1.2GB por<br />
ano, armazenamento não deve ser um problema mesmo se os cabeçalhos dos blocos sejam mantidos<br />
em memória.<br />
<br />
=== Verificação simplificada de pagamento ===<br />
É possível verificar pagamentos sem ter que rodar um node de rede inteiro. Um usuário precisa apenas manter<br />
uma cópia dos cabeçalhos dos blocos da maior corrente de prova de trabalho, que ele pode obter consultando<br />
os nodes da rede até se convencer de que ele tem a maior corrente, e obter a ramificação da arvore de Merkle<br />
ligando a transação ao bloco onde ela está carimbada. Ele não pode verificar a transação para ele mesmo,<br />
mas ao liga-la a um local na corrente, ele pode ver que um node aceitou a transação, e blocos adicionados<br />
após este irão confirmar ainda mais que a rede a aceitou.<br />
<br />
[[Arquivo:SPV.png]]<br />
<br />
Como sempre, a verificação é confiável desde que os nodes honestos controlem a rede, mas é mais<br />
vulnerável se a rede for dominada por um invasor. Enquanto os nodes da rede podem verificar transações por<br />
si próprios, o método simplificado pode ser enganado por uma transação fabricada por um invasor enquanto<br />
o invasor continuar a dominar a rede. Uma estratégia para proteger-se contra este problema seria aceitar <br />
alertas dos nodes da rede quando eles detectam um bloco inválido, induzindo o software do usuário a baixar<br />
o bloco completo e as transações alertadas para confirmar a inconsistência. Negócios que recebem<br />
pagamentos frequentes vão provavelmente querer rodar seus próprios nodes para uma segurança mais<br />
independente e verificações mais rápidas.<br />
<br />
<br />
=== Combinando e dividindo valor ===<br />
Embora seja possível manipular as moedas individualmente, seria complicado fazer uma transação separada<br />
para cada centavo em uma transferência. Para permitir que o valor seja dividido e combinado, transações<br />
contém múltiplas entradas e saídas. Normalmente haverá ou uma única entrada de uma grande transação<br />
anterior ou múltiplas entradas combinando pequenos valores, e no máximo duas saídas: Uma para o<br />
pagamento e uma para devolução de troco, se houver, de volta para o remetente.<br />
<br />
[[Arquivo:CandSV.png]]<br />
<br />
Deve-se notar que dispersão, onde uma transação depende de váriastransações, e estas transações dependem<br />
de muitas outras, não é um problema aqui. Nunca haverá a necessidade de extrair uma cópia independente<br />
completa do histórico de uma transação.<br />
<br />
<br />
=== Privacidade ===<br />
O modelo bancário tradicional atinge um nível de privacidade limitando o acesso à informação às partes<br />
envolvidas e ao intermediário confiável. A necessidade de anunciar todas as transações publicamente<br />
inviabiliza este método, mas a privacidade ainda pode ser mantida quebrando o fluxo da informação em<br />
outro local: mantendo as chaves públicas anônimas. O público pode ver que alguém está enviando um<br />
montante de dinheiro para outra pessoa, mas sem informações ligando a transação a qualquer pessoa. Isso<br />
é parecido com o nível de informação liberado no mercado de ações, onde o tempo e o tamanho das vendas<br />
individuais, a “fita”, são tornados públicos, porém sem dizer quem são as partes envolvidas.<br />
<br />
[[Arquivo:Privacy.png]]<br />
<br />
Como um firewall adicional, um novo par de chaves deve ser usado para cada transação para evitar que<br />
sejam associadas a um proprietário comum. Alguma associação ainda é inevitável com transações de muitas<br />
entradas, que necessariamente revelam que suas entradas pertenciam ao mesmo proprietário. O risco é que<br />
se o proprietário de uma chave for revelado, associações poderiam revelar outras transações que pertenciam<br />
ao mesmo proprietário. <br />
<br />
<br />
=== Cálculos ===<br />
Nós consideramos o cenário de um invasor tentando gerar uma corrente alternativa mais rápido do que a<br />
corrente honesta. Mesmo que isso seja bem-sucedido, não irá tornar o sistema aberto para mudanças<br />
arbitrárias, como criar valor do nada ou tomar dinheiro que nunca pertenceu ao invasor. nodes não irão aceitar<br />
uma transação inválida como pagamento, e nodes honestos nunca aceitarão um bloco contendo-as. Um invasor<br />
pode apenas tentar modificar uma de suas próprias transações para pegar de volta o dinheiro que ele gastou<br />
recentemente.<br />
A corrida entre a corrente honesta e a corrente do invasor pode ser caracterizada como uma Caminhada<br />
Aleatória Binomial. O evento de sucesso é a corrente honesta sendo estendida por um bloco, aumentando<br />
sua liderança em +1, e o evento de falha é a corrente do invasor ser estendida por um bloco, reduzindo a<br />
diferença em -1.<br />
A probabilidade de um invasor alcançar de um determinado déficit é análoga ao problema da Ruina do<br />
Apostador. Suponha que um apostador com créditos ilimitados comece em déficit e jogue potencialmente<br />
um infinito número de vezes para tentar empatar. Nós vamos calcular a probabilidade de ele nunca<br />
conseguir isso, ou que um invasor simplesmente alcance a corrente honesta, como segue [8]:<br />
p = probabilidade de um node honesto encontrar o próximo bloco<br />
q = probabilidade de um invasor encontrar o próximo bloco<br />
qz = probabilidade algum dia o invasor alcançar estando z blocos atrás<br />
<br />
Assumindo que p > q, a probabilidade cai exponencialmente a medida que o número de blocos que o invasor<br />
tem que alcançar aumenta. Com a probabilidade contra ele, se ele não levar sorte logo no início, suas<br />
chances vão desaparecendo e ele acaba ficando muito atrasado.<br />
<br />
Nós agora consideramos quanto tempo o destinatário de uma nova transação precisa esperar antes que seja<br />
suficientemente seguro de que o pagador não poderá alterar a transação. Nós assumimos que o remetente<br />
seja um invasor que quer fazer seu destinatário acreditar que ele o pagou por algum tempo, então mudar a<br />
transação para receber o dinheiro de volta depois que algum tempo se passou. O destinatário vai ser alertado<br />
quando isso acontecer, mas o remetente espera que seja tarde demais.<br />
O destinatário gera um novo par de chaves e dá a chave pública para o remetente logo antes de assinar. Isso<br />
previne que o remetente prepare uma cadeia de blocos antes do tempo trabalhando nele continuamente até<br />
que ele seja sortudo o suficiente para avançar o suficiente a frente, então executando a transação naquele<br />
momento. Uma vez que a transação seja enviada, o remetente desonesto começa a trabalhar em segredo em<br />
uma cadeia paralela contendo uma versão alternativa da transação.<br />
O destinatário aguarda até que a transação seja adicionada ao bloco e z blocos já tenham sido ligados após<br />
ele. Ele não sabe a quantidade exata do progresso que o invasor fez, mas assumindo que os blocos honestos<br />
tomaram a média esperada de tempo por bloco, o progresso potencial do invasor sera uma distribuição de<br />
Poisson com o valor esperado: <br />
<br />
[[Arquivo:Lambida.png]]<br />
<br />
Para obter a probabilidade de um invasor ainda alcançar neste momento, nós multiplicamos a densidade de<br />
Poisson por cada quantidade de progresso que ele poderia ter feito pela probabilidade de ele conseguir<br />
alcançar a partir daquele ponto:<br />
<br />
[[Arquivo:Probcatchup.png]]<br />
<br />
Reorganizando para evitar a soma de uma cauda infinita da distribuição...<br />
<br />
[[Arquivo:Avoidtailsum.png]]<br />
<br />
=== Convertendo em código C ===<br />
<br />
<pre><br />
#include <math.h> double<br />
AttackerSuccessProbability(double q, int z)<br />
{ double p = 1.0 - q; double<br />
lambda = z * (q / p); double<br />
sum = 1.0; int i, k;<br />
for (k = 0; k <= z; k++)<br />
{ double poisson = exp(-lambda); for (i = 1; i<br />
<= k; i++) poisson *= lambda / i; sum -=<br />
poisson * (1 - pow(q / p, z - k));<br />
} return<br />
sum;<br />
}<br />
</pre><br />
<br />
Executando alguns resultados, podemos ver a probabilidade cair exponencialmente com z.<br />
<pre><br />
q=0.1<br />
z=0 P=1.0000000<br />
z=1 P=0.2045873<br />
z=2 P=0.0509779<br />
z=3 P=0.0131722<br />
z=4 P=0.0034552<br />
z=5 P=0.0009137<br />
z=6 P=0.0002428<br />
z=7 P=0.0000647<br />
z=8 P=0.0000173<br />
z=9 P=0.0000046<br />
z=10 P=0.0000012<br />
q=0.3<br />
z=0 P=1.0000000<br />
z=5 P=0.1773523<br />
z=10 P=0.0416605<br />
z=15 P=0.0101008<br />
z=20 P=0.0024804<br />
z=25 P=0.0006132<br />
z=30 P=0.0001522<br />
z=35 P=0.0000379 <br />
<br />
z=40 P=0.0000095<br />
z=45 P=0.0000024<br />
z=50 P=0.0000006<br />
Para P menor que 0.1%<br />
P < 0.001<br />
q=0.10 z=5<br />
q=0.15 z=8<br />
q=0.20 z=11<br />
q=0.25 z=15<br />
q=0.30 z=24<br />
q=0.35 z=41<br />
q=0.40 z=89<br />
q=0.45 z=340<br />
</pre><br />
<br />
=== Conclusão ===<br />
Nós propusemos um sistema de transações eletrônicas sem depender de confiança. Nós começamos com a<br />
estrutura comum de moedas feitas a partir de assinaturas digitais, que oferecem forte controle de<br />
propriedade, mas é incompleta sem um sistema de prevenção de gasto duplo. Para resolver isso, nós<br />
propusemos uma rede p2p usando provas de trabalho para registrar um histórico público de transações que<br />
rapidamente se torna computacionalmente imprático para um invasor modificar se os nodes honestos<br />
controlarem a maior parte do poder de processamento. A rede é robusta em sua simplicidade não<br />
estruturada. nodes trabalham todos ao mesmo tempo com pouca coordenação. Eles não precisam ser<br />
identificados, já que as mensagem não são encaminhadas para nenhum local em particular e apenas<br />
precisam ser entregues na base da “melhor esforço”. nodes podem sair e voltar a rede a vontade, aceitando a<br />
cadeia de prova de trabalho como prova do que aconteceu enquanto ele esteve fora. Eles votam com seu<br />
poder de processamento, expressando sua aceitação dos blocos válidos ao trabalhar em estende-los e<br />
rejeitando blocos inválidos ao recusar a trabalhar neles. Quaisquer regras e incentivos necessários podem<br />
ser forçados com este mecanismo de consenso. <br />
<br />
=== Referências ===<br />
[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.<br />
<br />
[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal<br />
trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.<br />
<br />
[3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no<br />
2, pages 99-111, 1991.<br />
<br />
[4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital timestamping,"<br />
In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993. <br />
[5]<br />
S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on<br />
Computer and Communications Security, pages 28-35, April 1997. <br />
[6] A. Back, "Hashcash - a denial of<br />
service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002.<br />
<br />
[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on<br />
Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.<br />
<br />
[8] W. Feller, "An introduction to probability theory and its applications," 1957.<br />
<br />
[9]JUS - O que é "gasto duplo" e como o Bitcoin é capaz de evitá-lo? Disponível em https://jus.com.br/artigos/66683/o-que-e-gasto-duplo-e-como-o-bitcoin-e-capaz-de-evita-lo Jun, 2018 - Acesso em 20 de julho de 2018.<br />
<br />
[10] N. Satoshi, "Bitcoin: A Peer-to-Peer Electronic Cash System" Disponível em https://bitcoin.org/bitcoin.pdf</div>Crlsgmshttps://area31.net.br/wiki/index.php?title=Usu%C3%A1rio:Crlsgms&diff=3384Usuário:Crlsgms2016-05-06T20:43:35Z<p>Crlsgms: </p>
<hr />
<div>[[Image:Area31-icon.png|thumb|180px|]]<br />
<br />
'''Nome completo:''' Carlos Gomes<br />
<br />
'''Nick:''' crlsgms<br />
<br />
'''Site:''' <br />
<br />
'''Linkedin:''' https://br.linkedin.com/in/crlsgms<br />
<br />
'''Twitter:''' [https://twitter.com/crlsgms @crlsgms]<br />
<br />
'''Facebook:''' https://www.facebook.com/crlsgms<br />
<br />
'''Jabber (XMPP):''' <br />
<br />
'''Membro desde:''' 12/04/2016<br />
<br />
'''Indicado por:''' [[Raphael Bastos - Coffnix|Raphael Bastos]]<br />
<br />
'''Cidade:''' Franca - SP<br />
<br />
'''Mini CV:'''<br />
<pre><br />
</pre><br />
[[Categoria:Membros]]</div>Crlsgmshttps://area31.net.br/wiki/index.php?title=Usu%C3%A1rio:Crlsgms&diff=3383Usuário:Crlsgms2016-05-06T20:41:41Z<p>Crlsgms: </p>
<hr />
<div>[[Image:Area31-icon.png|thumb|180px|]]<br />
<br />
'''Nome completo:''' Carlos Gomes<br />
<br />
'''Nick:''' crlsgms<br />
<br />
'''Site:''' <br />
<br />
'''Linkedin:''' <br />
<br />
'''Twitter:''' [https://twitter.com/crlsgms @]<br />
<br />
'''Facebook:''' https://www.facebook.com/crlsgms<br />
<br />
'''Jabber (XMPP):''' <br />
<br />
'''Membro desde:''' 12/04/2016<br />
<br />
'''Indicado por:''' [[Raphael Bastos - Coffnix|Raphael Bastos]]<br />
<br />
'''Cidade:''' <br />
<br />
'''Mini CV:'''<br />
<pre><br />
</pre><br />
[[Categoria:Membros]]</div>Crlsgms