<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="pt-BR">
	<id>https://area31.net.br/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mace</id>
	<title>Área31 Hackerspace - Contribuições do usuário [pt-br]</title>
	<link rel="self" type="application/atom+xml" href="https://area31.net.br/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mace"/>
	<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/Especial:Contribui%C3%A7%C3%B5es/Mace"/>
	<updated>2026-06-07T18:40:32Z</updated>
	<subtitle>Contribuições do usuário</subtitle>
	<generator>MediaWiki 1.45.1</generator>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_e_jogos_online&amp;diff=4339</id>
		<title>Avaliação e projeto de interação no desenvolvimento de jogos educativos e jogos online</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_e_jogos_online&amp;diff=4339"/>
		<updated>2019-03-11T21:46:11Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Responsável:&lt;br /&gt;
 * [[Usuário:Eliane Vidal|Eliane Ferreira Vidal]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Contato:&#039;&#039;&#039; macevidal@gmail.com&lt;br /&gt;
&lt;br /&gt;
Este artigo está em desenvolvimento.&lt;br /&gt;
&lt;br /&gt;
Podemos supor que os jogos nasceram junto com a raça humana.&lt;br /&gt;
&lt;br /&gt;
Por sua necessidade de se comunicar e entreter, bem como evoluir sua própria inteligência, o homem passou a desenvolver jogos para estes fins. Provavelmente antes mesmo das escritas rupestres ou da comunicação verbal.&lt;br /&gt;
&lt;br /&gt;
É possível encontrar registros da existência de jogos em praticamente todas as partes do mundo, provenientes das mais diversas civilizações, e verificar que quanto mais avançada a civilização, mais complexos e mais diversa a variedade de jogos praticados pela mesma. Um desses registros data de aproximadamente 3500 a.C. referentes aos restos de um jogo de tabuleiro chamado Senet(zn.t n.t H&#039;b), um jogo de estratégia que tinha como objetivo &amp;quot;fazer a passagem da alma&amp;quot; antes de seu adversário, e que mais tarde recebeu uma conotação religiosa, onde o jogador teria por adversário Osíris(Ousir ou Unen-Nefer).&lt;br /&gt;
&lt;br /&gt;
É fato que aos jogos têm desempenhado papel de grande importância, principalmente na atualidade, sendo de alguma forma parte da vida de quase todos os seres humanos. Eles têm perdido o estigma de simples passatempo para tornarem-se objeto praticamente fundamental para educação nos dias de hoje, sobretudo nas modalidades a distância onde estes se fazem necessários para garantir que a atenção do aluno está voltada ao conteúdo que está sendo aplicado, uma vez que não existe uma pessoa o incentivando presencialmente.&lt;br /&gt;
&lt;br /&gt;
Uma avaliação dos objetivos que se espera ao projetar um jogo podem e devem garantir uma interação entre jogo e jogador priorizando esses objetivos, modificando a experiência do jogador de forma que seu tempo em jogo seja proveitoso e focado. Dependendo do tipo de jogo o aluno pode começar a se focar em  itens secundários ao passo que os prioritários passam praticamente despercebidos, um bom projeto de interação garante que esse tipo de comportamento (não desejado) seja minimizado.&lt;br /&gt;
&lt;br /&gt;
Este artigo mostra como essa interação pode ser mais valorosa do ponto de vista educacional, influenciando o modo como o aluno passa a ver o cenário que está sendo apresentado de forma focada e criativa formando um aluno mais interessado e participativo.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Escrever sobre a usabilidade nos jogos educacionais.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Brenda Laurel (1990) afirma que a &amp;quot;direção correta&amp;quot;, em designing de software, é a que leva o usuário a se sentir no controle, sentir que possui poder.&lt;br /&gt;
&lt;br /&gt;
Escrever sobre se sentir desafiado.&lt;br /&gt;
&lt;br /&gt;
Escrever sobre uma das regras da usabilidade (nao fazer o usuario pensar demais).&lt;br /&gt;
&lt;br /&gt;
Ou seja, a direção ideal para o projeto da interface do jogo educacional é a que alie a simplicidade no entendimento de como o aluno vai interagir com o jogo, que a compreensão de como o jogo funciona seja intuitiva, em contrapartida, o jogo em si deve possuir elementos que desafiem o aluno a pensar sobre como resolver os problemas propostos no jogo em questão.&lt;br /&gt;
Basicamente, o usuário não precisa pensar demais para supor o que um determinado elemento faz, seu raciocínio está em saber onde aplicar tal elemento e quando.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
EGYPT PAST - Osiris - Disponível em http://www.egyptpast.com/gods/osiris.html. Acesso em 03 de março de 2019.&lt;br /&gt;
LAUREL, Brenda. The Art of Humam-Computer Interface Design. Reading. Adson-Wesley. Massachusettes, 1990.&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4239</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4239"/>
		<updated>2019-02-02T16:07:05Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Rootfs_over_encrypted_lvm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Signed_kernel_module_support&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Hardening_Concepts&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/gracldoc.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://en.wikibooks.org/wiki/Grsecurity&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/PaX-presentation_files/frame.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/researchpaper.pdf&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Package:Nftables&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4238</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4238"/>
		<updated>2019-02-02T16:06:30Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Rootfs_over_encrypted_lvm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Signed_kernel_module_support&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Hardening_Concepts&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/gracldoc.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://en.wikibooks.org/wiki/Grsecurity&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/PaX-presentation_files/frame.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/researchpaper.pdf&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Package:Nftables&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4237</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4237"/>
		<updated>2019-02-02T16:05:26Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Rootfs_over_encrypted_lvm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Signed_kernel_module_support&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Hardening_Concepts&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/gracldoc.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://en.wikibooks.org/wiki/Grsecurity&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/PaX-presentation_files/frame.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/researchpaper.pdf&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Package:Nftables&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4236</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4236"/>
		<updated>2019-02-02T16:04:14Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[http://www.funtoo.org/Rootfs_over_encrypted_lvm]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Signed_kernel_module_support&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Hardening_Concepts]&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/gracldoc.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://en.wikibooks.org/wiki/Grsecurity&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/PaX-presentation_files/frame.htm&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://grsecurity.net/researchpaper.pdf&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;http://www.funtoo.org/Package:Nftables&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4235</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4235"/>
		<updated>2019-02-02T16:02:05Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[http://www.funtoo.org/Rootfs_over_encrypted_lvm]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[https://wiki.gentoo.org/wiki/Signed_kernel_module_support]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt; [http://www.funtoo.org/Hardening_Concepts]&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://grsecurity.net/gracldoc.htm]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[https://en.wikibooks.org/wiki/Grsecurity]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[http://grsecurity.net/PaX-presentation_files/frame.htm]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[http://grsecurity.net/researchpaper.pdf]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[http://www.funtoo.org/Package:Nftables]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4234</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4234"/>
		<updated>2019-02-02T16:00:52Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[http://www.funtoo.org/Rootfs_over_encrypted_lvm]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://wiki.gentoo.org/wiki/Signed_kernel_module_support]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt; [http://www.funtoo.org/Hardening_Concepts]&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://grsecurity.net/gracldoc.htm]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://en.wikibooks.org/wiki/Grsecurity]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 [https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 [http://grsecurity.net/PaX-presentation_files/frame.htm]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://grsecurity.net/researchpaper.pdf]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://www.funtoo.org/Package:Nftables]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4233</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4233"/>
		<updated>2019-02-02T15:58:21Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://www.funtoo.org/Rootfs_over_encrypted_lvm]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://wiki.gentoo.org/wiki/Signed_kernel_module_support]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt; [http://www.funtoo.org/Hardening_Concepts]&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://grsecurity.net/gracldoc.htm]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[https://en.wikibooks.org/wiki/Grsecurity]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 [https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 [http://grsecurity.net/PaX-presentation_files/frame.htm]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://grsecurity.net/researchpaper.pdf]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;&amp;lt;tt&amp;gt;&amp;gt;&amp;lt;nowiki&amp;gt;&amp;gt;[http://www.funtoo.org/Package:Nftables]&amp;lt;&amp;lt;/nowiki&amp;gt;&amp;gt;&amp;lt;&amp;lt;/tt&amp;gt;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4232</id>
		<title>HackForge</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=HackForge&amp;diff=4232"/>
		<updated>2019-02-02T15:55:17Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Autor: &lt;br /&gt;
 * [[Raphael Bastos - Coffnix|Raphael Bastos]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Defesa&#039;&#039;&#039;, do latim &#039;&#039;defensa&#039;&#039;, é o ato de proteção do próprio corpo ou grupo, significa auxílio, proteção, resistência; é o emprego dos meios necessários para proteção de alguém ou de algo.&lt;br /&gt;
&lt;br /&gt;
* Defesa - No caso das guerras a defesa é a ação contrária ao ataque;&lt;br /&gt;
* Defesa - Nos Estados, são as forças armadas;&lt;br /&gt;
* Defesa - Nos esportes coletivos, como na guerra a linha de defesa é na retaguarda;&lt;br /&gt;
* Defesa - Na jurisprudência, defesa é alegar em favor próprio;&lt;br /&gt;
* Defesa - Uma abertura de xadrez jogada pelas pretas;&lt;br /&gt;
* Defesa - Defensivo Agrícola - Uso de produtos e de técnicas na agricultura para proteger de pragas.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize criptografia pra tudo =&lt;br /&gt;
&lt;br /&gt;
== Rootfs over encrypted lvm ==&lt;br /&gt;
&lt;br /&gt;
É obrigatório o uso de criptografia de disco, principalmente do rootfs e da SWAP via LVM + cryptoLUKS.&lt;br /&gt;
&lt;br /&gt;
 [http://www.funtoo.org/Rootfs_over_encrypted_lvm]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;EX:&#039;&#039;&#039; &lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##cryptsetup --cipher twofish-xts-plain64 --hash sha512 --key-size 256 luksFormat /dev/sda3}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize módulo do kernel assinado =&lt;br /&gt;
Ao ativar a funcionalidade &amp;quot;Signed kernel module support&amp;quot; no seu Linux, permitrá que você tenha mais uma camada de proteção em seu sistema (hardening), não permitindo o carregamento de módulos do kernel não assinados (via modprobe), ou módulos do kernel assinados com a chave errada. Módulos do kernel maliciosos são métodos comuns para uso de &#039;&#039;&#039;rootkits&#039;&#039;&#039; em um sistema Linux.&lt;br /&gt;
&lt;br /&gt;
Em sistemas Funtoo/Gentoo:&lt;br /&gt;
&lt;br /&gt;
 [https://wiki.gentoo.org/wiki/Signed_kernel_module_support]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Assinando módulos manualmente ==&lt;br /&gt;
&lt;br /&gt;
 [https://wiki.hackstore.com.br/Assinando_m%C3%B3dulos_do_kernel]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Utilize profile Hardened/Grsecurity2 =&lt;br /&gt;
&lt;br /&gt;
Para aumentar sua defesa, adicione patches em seu kernel (hardened) para monitorar mudanças em tempo de compilação, proteção da pilha, alterações de tempo de execução mais invasivos, controle de acesso obrigatório, dentre outras camadas. Hardened em si não é uma correção a qualquer questão específica. Não é uma &amp;quot;&#039;correção de bug&#039;&amp;quot;. Hardened basicamente fornece um meio para mitigar uma ameaça de um exploit que utilizou com sucesso determinada vulnerabilidade. Hardened é melhor usado em forma de camadas, sem depender de qualquer técnica, já que podem haver falhas em quaisquer técnicas.&lt;br /&gt;
&lt;br /&gt;
 [http://www.funtoo.org/Hardening_Concepts]&lt;br /&gt;
&lt;br /&gt;
 [https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart]&lt;br /&gt;
&lt;br /&gt;
 [http://grsecurity.net/gracldoc.htm]&lt;br /&gt;
&lt;br /&gt;
 [https://en.wikibooks.org/wiki/Grsecurity]&lt;br /&gt;
&lt;br /&gt;
{{Note|Em algumas distribuições conhecidas, temos soluções semelhantes como o SELINUX (RHEL/CentOS) ou APPARMOR (SELS/OpenSUSE)}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Utilize PaX ==&lt;br /&gt;
&lt;br /&gt;
PaX é um patch para o kernel Linux que fornece hardening de três maneiras:&lt;br /&gt;
&lt;br /&gt;
* Judicious enforcement of non-executable memory&lt;br /&gt;
* Address Space Layout Randomization (ASLR)&lt;br /&gt;
* Miscellaneous hardening on stack- and memory handling&lt;br /&gt;
&lt;br /&gt;
{{tip|&lt;br /&gt;
Mais infos:&lt;br /&gt;
 [https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart]&lt;br /&gt;
&lt;br /&gt;
 [http://grsecurity.net/PaX-presentation_files/frame.htm]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
== Utilize RBAC ==&lt;br /&gt;
&lt;br /&gt;
Increasing Performance and Granularity in Role-Based Access Control Systems&lt;br /&gt;
&lt;br /&gt;
 [http://grsecurity.net/researchpaper.pdf]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Firewall =&lt;br /&gt;
== NFtables ==&lt;br /&gt;
&lt;br /&gt;
Já que não temos no Linux um firewall de verdade como o PF (FreeBSD), recomendamos abandonarem o iptables e utilizarem o NFtables:&lt;br /&gt;
&lt;br /&gt;
 [http://www.funtoo.org/Package:Nftables]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Dicas =&lt;br /&gt;
&lt;br /&gt;
== Retire o SSHD da porta padrão (22) ==&lt;br /&gt;
&lt;br /&gt;
Altere para porta &#039;&#039;&#039;666&#039;&#039;&#039; ou &#039;&#039;&#039;2424&#039;&#039;&#039;, mas por favor retire o servidor SSH da porta 22. Experimente abrir um TCPDUMP na escuta da porta 22 de qualquer IP no mundo pra ver o motivo.&lt;br /&gt;
&lt;br /&gt;
{{console|body=&lt;br /&gt;
$ ##i##echo -e &amp;quot;Port 666\nPort 2424&amp;quot; &amp;gt;&amp;gt; /etc/ssh/sshd_config&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Docs =&lt;br /&gt;
&lt;br /&gt;
Hardened Gentoo http://www.gentoo.org/proj/en/hardened/&lt;br /&gt;
&lt;br /&gt;
Security-Enhanced Linux http://en.wikipedia.org/wiki/Security-Enhanced_Linux&lt;br /&gt;
&lt;br /&gt;
RSBAC http://en.wikipedia.org/wiki/RSBAC&lt;br /&gt;
&lt;br /&gt;
Hardened/Toolchain https://wiki.gentoo.org/wiki/Hardened/Toolchain#RELRO&lt;br /&gt;
&lt;br /&gt;
Hardened/PaX Quickstart https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart&lt;br /&gt;
&lt;br /&gt;
checksec.sh http://www.trapkit.de/tools/checksec.html&lt;br /&gt;
&lt;br /&gt;
Advanced Portage Features http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;amp;chap=6&lt;br /&gt;
&lt;br /&gt;
Elfix http://dev.gentoo.org/~blueness/elfix/&lt;br /&gt;
&lt;br /&gt;
Avfs: An On-Access Anti-Virus File System http://www.fsl.cs.sunysb.edu/docs/avfs-security04/&lt;br /&gt;
&lt;br /&gt;
Eicar Download, http://www.eicar.org/85-0-Download.html&lt;br /&gt;
&lt;br /&gt;
Gentoo Security Handbook, https://gentoo-handbook.lugons.org/doc/en/security/&lt;br /&gt;
&lt;br /&gt;
[[Categoria:KnowledgeBase]]&lt;br /&gt;
[[Categoria:HackingDocs]]&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Bitcoin:_Um_sistema_de_dinheiro_eletr%C3%B4nico_Ponto-a-Ponto_(P2P)&amp;diff=3828</id>
		<title>Bitcoin: Um sistema de dinheiro eletrônico Ponto-a-Ponto (P2P)</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Bitcoin:_Um_sistema_de_dinheiro_eletr%C3%B4nico_Ponto-a-Ponto_(P2P)&amp;diff=3828"/>
		<updated>2018-08-01T12:31:36Z</updated>

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

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

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

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:Probcatchup.png&amp;diff=3822</id>
		<title>Arquivo:Probcatchup.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:Probcatchup.png&amp;diff=3822"/>
		<updated>2018-07-26T16:52:22Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:Lambida.png&amp;diff=3821</id>
		<title>Arquivo:Lambida.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:Lambida.png&amp;diff=3821"/>
		<updated>2018-07-26T16:51:18Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Bitcoin:_Um_sistema_de_dinheiro_eletr%C3%B4nico_Ponto-a-Ponto_(P2P)&amp;diff=3820</id>
		<title>Bitcoin: Um sistema de dinheiro eletrônico Ponto-a-Ponto (P2P)</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Bitcoin:_Um_sistema_de_dinheiro_eletr%C3%B4nico_Ponto-a-Ponto_(P2P)&amp;diff=3820"/>
		<updated>2018-07-25T19:40:28Z</updated>

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

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

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

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

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

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

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

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

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:Timestampserver.png&amp;diff=3811</id>
		<title>Arquivo:Timestampserver.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:Timestampserver.png&amp;diff=3811"/>
		<updated>2018-07-20T19:47:59Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:ProofOfWork.png&amp;diff=3810</id>
		<title>Arquivo:ProofOfWork.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:ProofOfWork.png&amp;diff=3810"/>
		<updated>2018-07-20T19:47:49Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:ReclaimingDiskSpace.png&amp;diff=3809</id>
		<title>Arquivo:ReclaimingDiskSpace.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:ReclaimingDiskSpace.png&amp;diff=3809"/>
		<updated>2018-07-20T19:47:40Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:SPV.png&amp;diff=3808</id>
		<title>Arquivo:SPV.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:SPV.png&amp;diff=3808"/>
		<updated>2018-07-20T19:47:28Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:CandSV.png&amp;diff=3807</id>
		<title>Arquivo:CandSV.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:CandSV.png&amp;diff=3807"/>
		<updated>2018-07-20T19:47:17Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Arquivo:Transaction.png&amp;diff=3806</id>
		<title>Arquivo:Transaction.png</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Arquivo:Transaction.png&amp;diff=3806"/>
		<updated>2018-07-20T19:46:52Z</updated>

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Bitcoin:_Um_sistema_de_dinheiro_eletr%C3%B4nico_Ponto-a-Ponto_(P2P)&amp;diff=3805</id>
		<title>Bitcoin: Um sistema de dinheiro eletrônico Ponto-a-Ponto (P2P)</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Bitcoin:_Um_sistema_de_dinheiro_eletr%C3%B4nico_Ponto-a-Ponto_(P2P)&amp;diff=3805"/>
		<updated>2018-07-20T19:43:44Z</updated>

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

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

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

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

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

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

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

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

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

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

		<summary type="html">&lt;p&gt;Mace: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Responsável:&lt;br /&gt;
 * [[Usuário:Eliane Vidal|Eliane Ferreira Vidal]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Contato:&#039;&#039;&#039; macevidal@gmail.com&lt;br /&gt;
&lt;br /&gt;
Este artigo está em desenvolvimento.&lt;br /&gt;
&lt;br /&gt;
Podemos supor que os jogos nasceram junto com a raça humana.&lt;br /&gt;
&lt;br /&gt;
Por sua necessidade de se comunitar e entreter, bem como evoluir sua própria inteligência, o homem passou a desenvolver jogos para estes fins. Provavelmente antes mesmo das escritas rupestres ou da comunicação verbal.&lt;br /&gt;
&lt;br /&gt;
É possível encontrar registros da existência de jogos em praticamente todas as partes do mundo, provenientes das mais diversas civilizações, e verificar que quanto mais avançada a civilização, mais complexos e mais diversa a variedade de jogos praticados pela mesma. Um desses registros data de aproximadamente 3500 a.C. referentes aos restos de um jogo de tabuleiro chamado Senet(zn.t n.t H&#039;b), um jogo de estratégia que tinha como objetivo &amp;quot;fazer a passagem da alma&amp;quot; antes de seu adversário, e que mais tarde recebeu uma conotação religiosa, onde o jogador teria por adversário Osíris(Ousir ou Unen-Nefer).&lt;br /&gt;
&lt;br /&gt;
É fato que aos jogos têm desempenhado papel de grande importância, principalmente na atualidade, sendo de alguma forma parte da vida de quase todos os seres humanos. Eles têm perdido o estigma de simples passatempo para tornarem-se objeto praticamente fundamental para educação nos dias de hoje, sobretudo nas modalidades a distância onde estes se fazem necessários para garantir que a atenção do aluno está voltada ao conteúdo que está sendo aplicado, uma vez que não existe uma pessoa o incentivando presencialmente.&lt;br /&gt;
&lt;br /&gt;
Uma avaliação dos objetivos que se espera ao projetar um jogo podem e devem garantir uma interação entre jogo e jogador priorizando esses objetivos, modificando a experiência do jogador de forma que seu tempo em jogo seja proveitoso e focado. Dependendo do tipo de jogo o aluno pode começar a se focar em  itens secundários ao passo que os prioritários passam praticamente despercebidos, um bom projeto de interação garante que esse tipo de comportamento (não desejado) seja minimizado.&lt;br /&gt;
&lt;br /&gt;
Este artigo mostra como essa interação pode ser mais valorosa do ponto de vista educacional, influenciando o modo como o aluno passa a ver o cenário que está sendo apresentado de forma focada e criativa formando um aluno mais interessado e participativo.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Osiris: http://www.egyptpast.com/gods/osiris.html&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_e_jogos_online&amp;diff=3691</id>
		<title>Avaliação e projeto de interação no desenvolvimento de jogos educativos e jogos online</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_e_jogos_online&amp;diff=3691"/>
		<updated>2017-07-25T21:32:17Z</updated>

		<summary type="html">&lt;p&gt;Mace: /* Resumo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; Responsável:&lt;br /&gt;
 * [[Usuário:Eliane Vidal|Eliane Ferreira Vidal]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Contato:&#039;&#039;&#039; macevidal@gmail.com&lt;br /&gt;
&lt;br /&gt;
Este artigo está em desenvolvimento.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Resumo&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
É fato que aos jogos têm desempenhado papel de grande importância, principalmente na atualidade, sendo de alguma forma parte da vida de quase todos os seres humanos. Eles têm perdido o estigma de simples passatempo para tornarem-se objeto praticamente fundamental para educação nos dias de hoje, sobretudo nas modalidades a distância onde estes se fazem necessários para garantir que a atenção do aluno está voltada ao conteúdo que está sendo aplicado, uma vez que não existe uma pessoa o incentivando presencialmente.&lt;br /&gt;
&lt;br /&gt;
Uma avaliação dos objetivos que se espera ao projetar um jogo podem e devem garantir uma interação entre jogo e jogador priorizando esses objetivos, modificando a experiência do jogador de forma que seu tempo em jogo seja proveitoso e focado. Dependendo do tipo de jogo o aluno pode começar a se focar em  itens secundários ao passo que os prioritários passam praticamente despercebidos, um bom projeto de interação garante que esse tipo de comportamento (não desejado) seja minimizado.&lt;br /&gt;
&lt;br /&gt;
Este artigo mostra como essa interação pode ser mais valorosa do ponto de vista educacional, influenciando o modo como o aluno passa a ver o cenário que está sendo apresentado de forma focada e criativa formando um aluno mais interessado e participativo.&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_e_jogos_online&amp;diff=3690</id>
		<title>Avaliação e projeto de interação no desenvolvimento de jogos educativos e jogos online</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_e_jogos_online&amp;diff=3690"/>
		<updated>2017-07-25T21:30:47Z</updated>

		<summary type="html">&lt;p&gt;Mace: Criou página com &amp;#039;==Resumo==  É fato que aos jogos têm desempenhado papel de grande importância, principalmente na atualidade, sendo de alguma forma parte da vida de quase todos os seres hum...&amp;#039;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Resumo==&lt;br /&gt;
&lt;br /&gt;
É fato que aos jogos têm desempenhado papel de grande importância, principalmente na atualidade, sendo de alguma forma parte da vida de quase todos os seres humanos. Eles têm perdido o estigma de simples passatempo para tornarem-se objeto praticamente fundamental para educação nos dias de hoje, sobretudo nas modalidades a distância onde estes se fazem necessários para garantir que a atenção do aluno está voltada ao conteúdo que está sendo aplicado, uma vez que não existe uma pessoa o incentivando presencialmente.&lt;br /&gt;
&lt;br /&gt;
Uma avaliação dos objetivos que se espera ao projetar um jogo podem e devem garantir uma interação entre jogo e jogador priorizando esses objetivos, modificando a experiência do jogador de forma que seu tempo em jogo seja proveitoso e focado. Dependendo do tipo de jogo o aluno pode começar a se focar em  itens secundários ao passo que os prioritários passam praticamente despercebidos, um bom projeto de interação garante que esse tipo de comportamento (não desejado) seja minimizado.&lt;br /&gt;
&lt;br /&gt;
Este artigo mostra como essa interação pode ser mais valorosa do ponto de vista educacional, influenciando o modo como o aluno passa a ver o cenário que está sendo apresentado de forma focada e criativa formando um aluno mais interessado e participativo.&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
	<entry>
		<id>https://area31.net.br/wiki/index.php?title=O_estudo_de_IHC_no_desenvolvimento_de_jogos_educacionais:_Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_contextualizados_pra_alunos_de_3_e_4_anos_%E2%80%93_Maternal_II&amp;diff=3684</id>
		<title>O estudo de IHC no desenvolvimento de jogos educacionais: Avaliação e projeto de interação no desenvolvimento de jogos educativos contextualizados pra alunos de 3 e 4 anos – Maternal II</title>
		<link rel="alternate" type="text/html" href="https://area31.net.br/wiki/index.php?title=O_estudo_de_IHC_no_desenvolvimento_de_jogos_educacionais:_Avalia%C3%A7%C3%A3o_e_projeto_de_intera%C3%A7%C3%A3o_no_desenvolvimento_de_jogos_educativos_contextualizados_pra_alunos_de_3_e_4_anos_%E2%80%93_Maternal_II&amp;diff=3684"/>
		<updated>2017-07-18T16:57:18Z</updated>

		<summary type="html">&lt;p&gt;Mace: Criou página com &amp;#039; &amp;#039;&amp;#039;&amp;#039;Autora: Eliane Ferreira Vidal&amp;#039;&amp;#039;&amp;#039;  macevidal@gmail.com   &amp;#039;&amp;#039;Este artigo foi desenvolvido como critério de avaliação da disciplina de  Metodologia de Pesquisa Científica...&amp;#039;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&#039;&#039;&#039;Autora: Eliane Ferreira Vidal&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
macevidal@gmail.com&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Este artigo foi desenvolvido como critério de avaliação da disciplina de  Metodologia de Pesquisa Científica no curso Sistemas de Informação do Instituto de Ciência da Computação – Universidade Federal Fluminense (ICC-UFF) em 2014&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Abstract.&#039;&#039;&#039; This work attempts to understand how the game should be made, taking into consideration the age group (3 and 4 years), to the concepts, he proposes, to be more easily assimilated by students. How and how much, is this method is effective, or not. This article shows how the interaction between game and player can be valuable, from an educational standpoint, influencing how the student comes to see the scenario being presented in a way focused and creative, forming a more participative and interested student. What justifies the use of IHC techniques in game development so called educational or instructional game.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Resumo.&#039;&#039;&#039; Este trabalho busca entender como o jogo deve ser apresentado, levando sempre em consideração a faixa etária abordada (3 e 4 anos), para que os conceitos, por ele proposto, sejam mais facilmente assimilados pelos alunos. Se, como e quanto, este método é, ou não, efetivo. Este artigo mostra como a interação entre jogo e jogador pode ser valorosa, do ponto de vista educacional, influenciando o modo como o aluno passa a ver o cenário que está sendo apresentado de forma centrada e criativa, formando um aluno mais interessado e participativo. O que justifica o emprego de técnicas de IHC no desenvolvimento de jogos chamados educacionais, ou didáticos.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Considerações Gerais ==&lt;br /&gt;
&lt;br /&gt;
É fato que os jogos têm desempenhado um papel de grande importância, em especial, mas não exclusivamente, na atualidade, sendo de alguma forma parte da vida de&lt;br /&gt;
praticamente todos os seres humanos. Eles têm perdido o estigma de ser apenas um passatempo para tornarem-se objeto fundamental para a educação nos dias de hoje. Com seu objetivo voltado para o conteúdo que deve ser aplicado.&lt;br /&gt;
&lt;br /&gt;
Os professores da creche e a pedagoga Elaine Resende afirmam que eles podem e devem ser instrumento pedagógico de grande valia para o aprendizado, pois “tudo que envolve o lúdico, auxilia a aprendizagem”, observa a professora Vera Florenzano.&lt;br /&gt;
&lt;br /&gt;
A Pedagoga Elaine Resende nos conta ainda que, &amp;quot;os jogos de associação e relação signo/significado auxiliam na aprendizagem da língua e rendem bons resultados”. Tudo “o que leva a criança a levantar hipóteses resulta em melhores resultados na aprendizagem”. Eles “estimulam o raciocínio e aborda de maneira transversal conteúdo, dando a eles a ludicidade que torna a aprendizagem prazerosa”.&lt;br /&gt;
&lt;br /&gt;
Porém, uma avaliação dos objetivos que se espera alcançar ao projetar um jogo e podem garantir uma interação entre jogo e jogador que priorizem estes objetivos,&lt;br /&gt;
modificando a experiência do jogador de forma que seu tempo de jogo seja proveitoso e focado na aprendizagem de um ou mais conceitos predeterminados.&lt;br /&gt;
&lt;br /&gt;
Vale lembrar que, Piaget defende o emprego de jogos como recurso para que o desenvolvimento do indivíduo aconteça a partir da concepção interacionista.&lt;br /&gt;
&lt;br /&gt;
Podemos, ainda, considerar o estudo da construção do conhecimento espacial (citado por Souza) que postula que o espaço é uma propriedade pela qual se enquadram o sujeito, os objetos e seus deslocamentos possibilitados pelas ações deste. Através desta relação o jogador consegue construir conhecimento espacial.&lt;br /&gt;
&lt;br /&gt;
No entanto, se faz necessário atentar para o fato de que, dependendo do tipo de jogo o aluno pode começar a focar em itens secundários, ao passo que os prioritários passem até mesmo despercebidos, um bom projeto de interação pode garantir que esse tipo de comportamento (não desejado) seja minimizado.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Hipóteses ==&lt;br /&gt;
&lt;br /&gt;
Neste sentido, o IHC pode ser de fundamental ajuda no desenvolvimento do jogo contextualizado, uma vez que considera os modelos mentais dos usuários (alunos) e os&lt;br /&gt;
padrões por eles desenvolvidos na construção do conhecimento.&lt;br /&gt;
&lt;br /&gt;
Partindo da hipótese de que o uso do estudo, na fase pré-desenvolvimento, e avaliação dos resultados desses estudos, e implantação de técnicas de IHC no&lt;br /&gt;
desenvolvimento desse tipo de jogo, ou simuladores, possam auxiliar na apresentação dos conceitos curriculares aos alunos, pois, ao mesmo passo que atrai a atenção dos alunos para si, também podem identificar padrões que virão a ser útil para a construção do saber organizado, criativo e interessante, já que os padrões gesto-comportamentais são levados em consideração em sua elaboração.&lt;br /&gt;
&lt;br /&gt;
Entender como os alunos interagem com o ambiente computacional pode auxiliar a produção de um jogo que ajude a apresentar conceitos, causa e efeito, e ainda, sentimentos de atração e repulsa, conforme seja pertinente na cultura em que estão inseridos.&lt;br /&gt;
&lt;br /&gt;
Para entender melhor nossa hipótese devemos considerar alguns objetivos que compõem o currículo do Maternal II (crianças de 3 e 4 anos) que foram abordados pelos&lt;br /&gt;
jogos propostos: Desenvolver a capacidade da criança de identificar objetos iguais e diferentes; Identificação da primeira letra do próprio nome; Coordenação motora das mãos; Discriminação visual e auditiva; Memorização; Estimulação do raciocínio; Classificação e nomeação de objetos pelas cores primárias; Quantificação 1-5; Identificar formas iguais (sombra do animal); Incentivar atividades em grupo, ao passo que se respeite “a vez” do outro.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Metodologia ==&lt;br /&gt;
&lt;br /&gt;
Foi realizada pesquisa com professores e alunos na Creche Municipal Jader Ullmann, com prévia autorização da Secretaria de Educação e Cultura, no Município de&lt;br /&gt;
Magé – RJ. Foi também consultada a Pedagoga Elaine Resende, que possui vasto conhecimento na área de educação e experiência de anos de trabalho neste seguimento de atuação.&lt;br /&gt;
&lt;br /&gt;
São instrumentos nesta pesquisa: questionário com as crianças com objetivo de identificar padrões que possam influenciar no desenvolvimento dos jogos; questionário com os pedagogos que tem por objetivo levantar a relevância do jogo para a aprendizagem, bem como a melhor forma de abordar o currículo com seu auxilio; a plataforma de desenvolvimento dos jogos é a ferramenta da MIT Scratch (disponível para uso livre em http://scratch.mit.edu/) e um notebook tanto para o desenvolvimento dos softwares quanto para a interação entre a criança e o jogo.&lt;br /&gt;
&lt;br /&gt;
Foram feitas pesquisas através de questionário, com alunos e pedagogos, assim como, o teste de jogabilidade dos protótipos para levantar a relevância do uso das técnicas de IHC para o desenvolvimento dos jogos educacionais e se, e quais, mudanças nos protótipos se fazem necessárias para uma melhor interação do aluno com o jogo.&lt;br /&gt;
&lt;br /&gt;
Participaram da fase de entrevistas 3 pedagogos, com diferentes tempos de experiência em educação infantil, e 13 alunos. E as dinâmicas envolveram 20 alunos de 3 e 4 anos de idade.&lt;br /&gt;
&lt;br /&gt;
Durante a fase de prototipação foram desenvolvidos jogos elaborados com base no currículo para as idades de 3 e 4 anos, e criados os seguintes protótipos: : Cores; Bee; Letra; Poney; IssoNaoEDaqui; Puzzle; Memo e Sombra. A plataforma de desenvolvimento escolhida foi o Scratch, que é uma plataforma web gráfica para criação de jogos e animações.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Considerações sobre a pesquisa bibliográfica e pesquisa pré-desenvolvimento para elaboração de protótipos ==&lt;br /&gt;
&lt;br /&gt;
Na primeira entrevista pré-desenvolvimento, tanto a professora Luciana Ferreira, quanto a pedagoga Elaine Resende nos fazem entender como e porque algumas das ideias precisariam ser modificadas para atender ao público alvo, crianças de 3 e 4 anos, destes jogos.&lt;br /&gt;
&lt;br /&gt;
Em um primeiro contato com a pedagoga Elaine Resende já foi possível observar como uma das etapas do estudo da IHC, a análise de requisitos (onde se buscam ouvir e entender todos stakeholders dos jogos em questão) pode mudar o desenvolvimento, e mesmo parte da ideia inicial, de um jogo educacional, uma vez que, foram constatadas várias peculiaridades sobre como a criança na faixa etária entre 3 e 4 anos constrói seu conhecimento social, linguístico, lógico e matemático, que poderiam ser, e foram, inicialmente ignoradas pelo desenvolvedor dos jogos, aqui abordados.&lt;br /&gt;
&lt;br /&gt;
Quanto à aparência dos jogos, as alterações propostas levam em conta as preferências das crianças na atualidade em relação a personagens e cores. Com este propósito buscamos e identificamos quais os personagens e as cores mais populares entre as crianças. Obtivemos, ainda, uma listagem de lugares que as crianças mais gostam de estar, que podem ser utilizadas de tema ou plano de fundo dos jogos para despertar maior interesse do aluno.&lt;br /&gt;
&lt;br /&gt;
Quando questionada sobre a que atividades os alunos são apresentados e desenvolvem na escola nesta faixa etária, a professora Luciana Ferreira conta sobre alguns&lt;br /&gt;
dos planos de aula que desenvolve, e nos faz entender que, não se deve reaproveitar tudo o que foi passado para uma turma de ano para ano, pois as crianças mudam, assim como as experiências das mesmas em relação acontecimentos, moral e sociedade também mudam com o tempo. O que nos leva a entender que, além de desenvolver um jogo utilizando as técnicas de IHC, é necessário também buscar a atualização da forma como o mesmo é apresentado, de tempos em tempos, para o aproveitamento e interesse no mesmo seja sempre mantido.&lt;br /&gt;
&lt;br /&gt;
Alguns jogos inicialmente idealizados sofreram alterações drásticas ou, ainda, foram descartados completamente após este primeira entrevista. Assim como, outros jogos&lt;br /&gt;
puderam ser pensados e desenvolvidos para atender ao currículo desta faixa etária.&lt;br /&gt;
&lt;br /&gt;
Alguns exemplos de modificações já identificadas nesta etapa da pesquisa são: nos jogos que forem apresentar conceitos linguísticos (como o reconhecimento da primeira letra de seu nome pelo aluno), não se deve utilizar opções com grafia de formatos parecidos para esta faixa de idade; nos que desenvolvem a coordenação motora poderiam ser utilizadas “brincadeiras de caminho”, porém os caminhos muito estreitos e sinuosos ainda devem ser evitados; já os jogos de cores e puzzles devem ser apresentados de forma simplista,utilizando cores primárias apenas e jogos com poucas opções e peças. Jogos com 4 a 6 peças/opções apenas, ao menos até que a criança já esteja habituada com esta quantidade, então a dificuldade pode ser aumentada, mas este deve ser um processo gradual.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Da fase de prototipação ==&lt;br /&gt;
&lt;br /&gt;
Foram seguidas as boas práticas ao desenhar uma interface do Portal Usability adaptadas ao contexto dos jogos:&lt;br /&gt;
&lt;br /&gt;
* Mantenha a interface simples;&lt;br /&gt;
* Crie ele consistência e utilize elementos comuns na interface com o usuário;&lt;br /&gt;
* Seja objetivo no layout;&lt;br /&gt;
* Use cores e texturas estrategicamente;&lt;br /&gt;
* Use tipografia para obter clareza e hierarquia;&lt;br /&gt;
* Tenha certeza que o sistema comunica o que está acontecendo;&lt;br /&gt;
* Pense no padrão (qual o objetivo do jogo?).&lt;br /&gt;
&lt;br /&gt;
Uma equipe multidisciplinar de desenvolvimento foi pontuada pelos pedagogos em entrevista como o melhor método de desenvolvimento, pois levam em conta os saberes dos professores e dos psicólogos em relação a como a criança aprende, o que pode ser algo que vai além do conhecimento do designer de jogos.&lt;br /&gt;
&lt;br /&gt;
* Buscou-se ao desenvolver os jogos em relação aos aspectos gráficos:&lt;br /&gt;
* Envolver o jogador;&lt;br /&gt;
* Ser de fácil assimilação;&lt;br /&gt;
* Não distrair o jogador sobre seu objetivo principal, evitando elementos secundários;&lt;br /&gt;
* Utilizar recursos como associações e linguagens metafóricas, conforme proposto por uma das pedagogas entrevistadas.&lt;br /&gt;
&lt;br /&gt;
Foram feitos testes de usabilidade, de acordo com um dos fundamentos do IHC, inicialmente apenas com desenvolvedores e testadores, após isto, durante o uso dos&lt;br /&gt;
protótipos pelos alunos, foi possível observar que pontos precisam ser melhorados.&lt;br /&gt;
êm agora seus objetivos voltados ao conteúdo exigido pelo currículo para esta faixa etária.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Da observação da interação com protótipos ==&lt;br /&gt;
&lt;br /&gt;
Todas as crianças demonstraram interesse em jogar os jogos no computador, mesmo as que sentiram dificuldades no manuseio e/ou entendimento do funcionamento do mouse.&lt;br /&gt;
&lt;br /&gt;
As crianças de 3 anos tinham mais dificuldade de entendimento do funcionamento do mouse que as crianças de 4 anos, no entanto, a dificuldade motora variou de criança para criança não respeitando o sexo e/ou idade. Tendo a maioria, desta idade, tentado interagir com os dedinhos direto na tela, o que nos leva a entender que o tablet seria a interface mais adequada para crianças de 3 anos.&lt;br /&gt;
&lt;br /&gt;
Algumas crianças de tiveram problemas com o uso do mouse clicando continuamente, sem entender como ele propiciava a interação com os objetos na tela de um&lt;br /&gt;
lado para o outro, ou pra cima e pra baixo. Tentando criar ações apenas clicando ininterruptamente com o botão, sem mexer o mouse do lugar. Nestes casos, foi necessário um esforço extra de explicação de como funcionava o mouse, ajudavam-se as crianças colocando a mão sobre as delas e fazendo os movimentos e interações e mostrando como o objeto se mexia na tela, ou seja, foi necessário que estas crianças jogassem o mesmo jogo 2 ou mais vezes, sendo a última sempre sem este tipo de auxílio. &lt;br /&gt;
&lt;br /&gt;
Outro fato que podemos ressaltar, diz respeito à observação de uma das crianças que acabaram de completar 3 anos de idade, que a pesar de ter dificuldades em se expressar oralmente, teve desempenho nos jogos equivalente ao das crianças de 4 anos. Ou seja, foi possível medir o entendimento que a criança obteve dos objetivos do jogo, sem exigir que ela tivesse que expressar oralmente este entendimento.&lt;br /&gt;
&lt;br /&gt;
Um ponto interessante que pôde ser observado é que, através dos jogos digitais é possível verificar a tendência da criança em ser destra ou canhota. Pôde-se identificar esta tendência principalmente em jogos de percurso. A princípio, ao utilizar os jogos em suas versões de demonstração, apenas alternam-se entre os botões de acordo com a facilidade de cada criança. O mesmo deverá ser feito em versões melhoradas dos softwares que continuem a rodar em desktops.&lt;br /&gt;
&lt;br /&gt;
Este item de discussão nos trás duas possibilidades: continuar a versão em desktop que possibilita um trabalho motor mais refinado; criar uma versão dos jogos para tablet, que ao passo que torna o trabalho menos cansativo para o professor, precisa alternar entre os botões sempre que identificada uma dificuldade do aluno em utilizar a mão para a qual o mouse está configurado no momento, também se têm menor refinamento do trabalho motor da criança.&lt;br /&gt;
&lt;br /&gt;
A partir do questionário que foi utilizado com os alunos e da observação enquanto jogando as versões de demonstração, foi possível identificar que as crianças gostam de&lt;br /&gt;
jogar na escola, porém os jogos motores são os que elas têm maior dificuldade.&lt;br /&gt;
&lt;br /&gt;
Outra questão importante a ser explorada é que praticamente todas as crianças têm tablets em casa, ainda que a localização da creche leve a crer que são de famílias de baixa renda. Este é um item de grande valia que deve ser explorado quando confeccionando jogos educacionais, pois os mesmos podem ser disponibilizados para download ou distribuídos na escola para instalação, para que, deste modo, as crianças possam praticar e aprender em suas residências.&lt;br /&gt;
&lt;br /&gt;
A escolha dos dispositivos foi feita de acordo com o material à disposição (notebook e mouse), no entanto, o que se pôde observar é que se obteria um melhor resultado se fossem escolhidos levando em consideração as capacidades e familiaridade dos alunos com o mesmo (um tablet se adequaria melhor em nosso caso).&lt;br /&gt;
&lt;br /&gt;
Foi possível observar que os alunos que já haviam jogado um jogo de mesmo objetivo curricular (motor, matemático, etc), tiveram melhor desempenho no jogo seguinte&lt;br /&gt;
que os alunos que jogaram apenas jogos de objetivos distintos. O que leva a supor que se deve encorajar a criança a jogar mais vezes jogos de mesmo objetivo para  melhor assimilação. Podendo ser pela interação no mesmo jogo diversas vezes, ou alternando entre jogos de mesmos objetivos curriculares.&lt;br /&gt;
&lt;br /&gt;
Foi observado que o uso do mouse, para considerável percentagem de alunos, é feita com grande dificuldade, no entanto, foi possível observar que pelos jogos, Letra, Memo e Sombra, que as crianças têm grande familiaridade com o tablet, tendo muitos deles tentado interagir diretamente com a tela do notebook. Com este dado e, aliado ao fato de quase a totalidade dos alunos terem acesso a tablets em casa, como observado nos questionários, uma proposta de melhor interação para estes jogos seria portá-los para este tipo de dispositivo.&lt;br /&gt;
&lt;br /&gt;
Outro ponto importante que pôde ser observado foi que os alunos constantemente clicavam no botão de funções do mouse muitas vezes interrompendo o jogo, este&lt;br /&gt;
contratempo pode ser evitado utilizando um mouse que possui apenas 1 botão, que serviria apenas para interagir com os objetos do jogo.&lt;br /&gt;
Infelizmente, estas duas últimas propostas não puderam ser testadas, por falta de recursos do pesquisador.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Pontos que foram ajustados após observação da interação do aluno com os protótipos: ==&lt;br /&gt;
&lt;br /&gt;
* No jogo Bee, se a criança clicar na abelha a mesma deve seguir o mouse sem que ela precise segurar o botão do mouse, pois este processo exige uma coordenação&lt;br /&gt;
composta ainda não adquirida. Sendo ideal que a criança adquira a habilidade de levar a abelha até a flor e que este processo já seja familiar para ela, aí então o processo de o botão precisar ficar pressionado poderá ser introduzido como um desafio para ela. Porém não ainda nesta etapa de aprendizagem.&lt;br /&gt;
&lt;br /&gt;
* Nos jogos, Poney e Cores principalmente, foi possível identificar a destreza do aluno. Tendo sido observada uma dificuldade extra do aluno canhoto em percorrer os&lt;br /&gt;
percursos, ou tentado interagir com o objeto preferencialmente no botão direito. Para prevenir que continuasse a ocorrer os botões do mouse foram alternados e o mesmo foi passado para a mão esquerda deste aluno. Os botões foram alternados sempre que se fez necessário.&lt;br /&gt;
&lt;br /&gt;
* Para o jogo Cores foi proposto pela professora Luciana Ferreira, que se&lt;br /&gt;
&lt;br /&gt;
utilizem objetos maiores e preferencialmente quadrados para facilitar o manuseio do aluno, uma vez que a proposta deste jogo é aprender as cores, não o de treinar a coordenação motora mais afinada.&lt;br /&gt;
&lt;br /&gt;
Outra providência foi deixar a seta do mouse maior e mais chamativa, o que ajudou a criança a visualizar o que ela estava fazendo e como. A criança teve menos problemas para saber como interagir com os objetos.&lt;br /&gt;
&lt;br /&gt;
A modificação no tema de alguns jogos para o tema “Copa do mundo” também foi muito interessante. Alguns alunos ficaram muito mais motivados nestes. Mesmo as crianças que não estavam bem, doentinhas ou chorosas, se animaram para jogá-lo.&lt;br /&gt;
&lt;br /&gt;
Neste sentido, um novo jogo de contar, ou seja, de mesmo objetivo do jogo Bee, foi criado. O jogo Gol, que aleatoriamente exigia que o aluno fizesse 1 a 5 gols. E ia contando o número de gols já marcados até que o aluno vencesse.&lt;br /&gt;
&lt;br /&gt;
Este jogo, a pesar de parecer totalmente diferente, sofreu poucas modificações em códigos em relação ao Bee, e teve a aparência completamente alterada, é claro.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Conclusão ==&lt;br /&gt;
&lt;br /&gt;
Este artigo debateu como uso de técnicas de IHC pode melhorar a experiência do aluno na interação com jogos educacionais, teve como base conceitual a investigação&lt;br /&gt;
bibliográfica e debates com profissionais de educação durante todo o processo de desenvolvimento, e mesmo a observação da interação dos alunos com jogos na fase de&lt;br /&gt;
prototipagem, bem como na fase dos jogos em suas versões já melhoradas.&lt;br /&gt;
&lt;br /&gt;
Mostrou como o uso das técnicas de IHC pode melhorar a experiência do aluno com o jogo e, desta forma, auxiliar o aluno a construir o saber organizado e levantar hipóteses. E que, através dos jogos é possível alcançar diversos objetivos como, por exemplo, trabalhar os seguintes aspectos: a afeição; a criatividade; a socialização; a cognição e a motivação.&lt;br /&gt;
&lt;br /&gt;
Ou seja, foi uma experiência bastante proveitosa ter utilizado técnicas de IHC no desenvolvimento do jogo e a abordagem multidisciplinar que foi utilizada. Levou a uma&lt;br /&gt;
interação realmente estimulante e valorosa.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Bibliografia ==&lt;br /&gt;
&lt;br /&gt;
ALVES, Renan. Gosto de Ler: A importância do jogo na aprendizagem. -&lt;br /&gt;
http://www.gostodeler.com.br/materia/14786/a_importancia_do_jogos_na_aprendizagem.ht&lt;br /&gt;
ml - Último acesso em 02 de junho de 2014.&lt;br /&gt;
&lt;br /&gt;
Jogos na educação: http://www.br30.org.br/noticia/96-confer-ncia-debate-jogoseducacionais-para-crian-as-com-s-ndrome-de-down.html&lt;br /&gt;
- Último acesso em 03 de maio de&lt;br /&gt;
2014.&lt;br /&gt;
&lt;br /&gt;
Mundinho da criança: O que trabalhar com crianças do Maternal II (3 a 4 anos) -&lt;br /&gt;
http://mundinhodacrianca.blogspot.com/2009/10/o-que-trabalhar-com-criancas-do_05.html&lt;br /&gt;
- Último acesso em 26 de maio de 2014.&lt;br /&gt;
&lt;br /&gt;
O que é IHC: http://ppgcc.dc.ufscar.br/pesquisa/linhas-de-pesquisa/engenharia-de-software&lt;br /&gt;
- Último acesso em 15 de maio de 2014.&lt;br /&gt;
&lt;br /&gt;
PIAGET, Jean. A construção do real na criança. 2ªedição. Rio de Janeiro: Zahar, 1975.&lt;br /&gt;
Portal Usability: User Interface Design Basics - http://www.usability.gov/what-andwhy/user-interface-design.html&lt;br /&gt;
- Último acesso em 03 de junho de 2014.&lt;br /&gt;
&lt;br /&gt;
Simulação: O que é Simulação de processos/sistemas? -&lt;br /&gt;
http://www.erlang.com.br/simulacao.asp - Último acesso em 03 de junho de 2014.&lt;br /&gt;
&lt;br /&gt;
SOUZA, Fabrícia Ferreira de. Desenvolvimento de Jogos Computacionais como Objetos de&lt;br /&gt;
Aprendizagem para Pessoas com Necessidades Educativas Especiais - Dissertação, Itajubá -&lt;br /&gt;
MG, Outubro de 2010.&lt;br /&gt;
&lt;br /&gt;
SOUZA, Kênia Bomtempo de – Piaget e a construção de conceitos geométricos.&lt;br /&gt;
Palhoça, 2006.&lt;/div&gt;</summary>
		<author><name>Mace</name></author>
	</entry>
</feed>