Resumo
Uma versão puramente ponto a ponto de dinheiro eletrônico permitiria online
pagamentos a serem enviados diretamente de uma parte para outra, sem passar por um instituição financeira. As assinaturas digitais fornecem parte da solução, mas o principal os benefícios são perdidos se um terceiro de confiança ainda for necessário para evitar gastos duplos.
Propomos uma solução para o problema do gasto duplo usando uma rede ponto a ponto.
As transações de carimbo de data / hora da rede, hashing-los em uma cadeia contínua de prova de trabalho baseada em hash, formando um registro que não pode ser
alterado sem refazer a prova de trabalho. A cadeia mais longa não serve apenas como prova da seqüência de eventos testemunhados, mas prova de que veio do maior pool de energia da CPU. Como contanto que a maior parte do poder da CPU seja controlada por nós que não cooperam com atacar a rede, eles irão gerar a cadeia mais longa e atacar o espaço. A própria rede requer uma estrutura mínima. As mensagens são transmitidas da melhor maneira possível base, e os nós podem deixar e reingressar na rede à vontade, aceitando o mais longo cadeia de prova de trabalho como prova do que aconteceu enquanto eles estavam fora.
1 - Introdução
O comércio na Internet passou a depender quase exclusivamente de instituições financeiras que atuam como terceiros de confiança para processar pagamentos eletrônicos. Embora o sistema funcione bem o suficiente para na maioria das
transações, ainda sofre com as fraquezas inerentes do modelo baseado em confiança.
Transações totalmente irreversíveis não são realmente possíveis, uma vez que as instituições financeiras não podem evitar mediar disputas. O custo da mediação aumenta os custos de transação, limitando o tamanho mínimo de transação prática e eliminando a possibilidade de pequenas transações casuais, e há um custo mais amplo na perda de capacidade de fazer pagamentos não reversíveis por serviços reversíveis.
Com a possibilidade de reversão, a necessidade de confiança se espalha.
Comerciantes devem Desconfiar de seus clientes, importunando-os para obter mais informações do que de outra forma precisariam.
Uma certa porcentagem de fraude é aceita como inevitável. Esses custos e incertezas de pagamento pode ser evitado pessoalmente usando moeda física, mas não existe nenhum mecanismo para fazer pagamentos através de um canal de comunicação sem uma parte confiável.
BaadalCoin: A Peer-to-Peer Electronic Cash System
Nordeste Serviços e Mídias Digitais Ltda.
[email protected] baadallottery.com
O que é necessário: um sistema de pagamento eletrônico baseado em prova
criptográfica em vez de confiança, permitindo que quaisquer das partes interessadas negociem diretamente uma com a outra, sem a necessidade de um confiável terceiro.
As transações que são computacionalmente impraticáveis para reverter protegem os vendedores de fraude, e mecanismos de garantia de rotina podem ser facilmente implementados para proteger os compradores. No neste artigo, propomos uma solução para o problema de gasto duplo usando um sistema peer-to-peer distribuído servidor de carimbo de data / hora para gerar prova computacional da ordem cronológica das transações. o sistema é seguro, desde que nós honestos controlem coletivamente mais poder da CPU do que qualquer grupo cooperante de nós do atacante.
2 - Transações
Definimos uma moeda eletrônica como uma cadeia de assinaturas digitais. Cada proprietário transfere a moeda para o próximo em seguida, assinando digitalmente um hash da transação anterior e a chave pública do próximo proprietário e adicioná-los ao final da moeda. Um beneficiário pode verificar as assinaturas para verificar a cadeia de propriedade.
Transaction Owner 1's Public Key
Owner 0's Signature
Hash
Transaction Owner 2's Public Key
Owner 1's Signature
Hash Verif
y
Transaction Owner 3's Public Key
Owner 2's Signature
Hash Verify
Owner 2's Private Key Owner 1's
Private Key
Sign Sign
Owner 3's Private Key
O problema, claro, é que o beneficiário não pode verificar se um dos proprietários não gastou o dobro da moeda. Uma solução comum é introduzir uma autoridade central confiável, ou casa da moeda, que verifica cada transação para gastos em dobro. Após cada transação, a moeda deve ser devolvida à casa da moeda para emitir uma nova moeda, e apenas moedas emitidas diretamente da casa da moeda são confiáveis para não serem gastas duas vezes.
O problema com esta solução é que o destino de todo o sistema monetário depende da empresa que administra a casa da moeda, com cada transação tendo que passar por ela, como um banco.
Precisamos de uma maneira para o beneficiário saber que os proprietários anteriores não assinaram nenhum transações. Para nossos propósitos, a primeira transação é a que conta, então não nos importamos sobre tentativas posteriores de gastar o dobro. A única maneira de confirmar a ausência de uma transação é esteja ciente de todas as transações. No modelo baseado na casa da moeda, a casa da moeda estava ciente de todas as transações e decidiu o que chegou primeiro. Para conseguir isso sem uma parte confiável, as transações devem ser anunciado publicamente [1], e precisamos de um sistema para que os participantes concordem em uma única história da ordem em que foram recebidos. O beneficiário precisa de uma prova de que, no momento de cada transação, a maioria dos nós concordou que foi o primeiro recebido.
3 - Servidor de carimbo de data / hora
A solução que propomos começa com um servidor de carimbo de data / hora. Um servidor de carimbo de data / hora funciona tomando um hash de um bloco de itens a serem marcados com data e hora e publicando amplamente o hash, como em um jornal ou postagem da Usenet [2-5]. O carimbo de data / hora prova que os dados devem ter existido no tempo, obviamente, para entrar no hash. Cada carimbo de data / hora inclui o carimbo de data / hora anterior em seu hash, formando uma cadeia, com cada
carimbo de data / hora adicional reforçando os anteriores.
4 - Prova de Trabalho
Para implementar um servidor de carimbo de data / hora distribuído em uma base ponto a ponto, precisaremos usar uma provasistema de trabalho semelhante ao Hashcash de Adam Back [6], em vez de publicações de jornais ou da Usenet. A prova de trabalho envolve a verificação de um valor que, quando hash, como com SHA-256, o o hash começa com um número de bits zero. O trabalho médio necessário é exponencial em número de zero bits necessários e podem ser verificados executando um único
hash.Para nossa rede de carimbo de data / hora, implementamos a prova de trabalho incrementando um nonce no bloco até que seja encontrado um valor que forneça ao hash do bloco os bits zero necessários. Uma vez que a CPU esforço foi despendido para fazê-lo satisfazer a prova de trabalho, o bloco não pode ser alterado sem refazer o trabalho. Como os blocos posteriores são encadeados depois dele, o trabalho para mudar o bloco incluiria refazer todos os blocos depois disso.
A prova de trabalho também resolve o problema de determinar a representação na decisão da maioria fazer. Se a maioria fosse baseada em um endereço IP, um voto, ele poderia ser subvertido por qualquer pessoa capaz de alocar muitos IPs. A prova de trabalho é essencialmente um-CPU-um-voto. A maioria decisão é representada pela cadeia mais longa, que tem o maior esforço de prova de trabalho investido iniciar. Se a maior parte do poder da CPU for controlada por nós honestos, a cadeia honesta
aumentará o mais rápido e mais rápido do que quaisquer cadeias concorrentes. Para modificar um bloco anterior, um invasor teria que refazer a prova de trabalho do bloco e todos os blocos posteriores e, em seguida, alcançar e superar o trabalho dos nós honestos. Mostraremos mais tarde que a probabilidade de um atacante mais lento alcançar diminui exponencialmente à medida que os blocos subsequentes são adicionados. Para compensar o aumento da velocidade do hardware e o interesse variado na execução de nós ao longo do tempo, a dificuldade de prova de trabalho é determinada por uma média móvel visando um número médio de blocos por hora. Se eles forem gerados muito rápido, a dificuldade aumenta.
Block
Item Item ...
Hash
Block
Item Item ...
Hash
5 - Rede
As etapas para operar a rede são as seguintes:
1) Novas transações são transmitidas para todos os nós.
2) Cada nó coleta novas transações em um bloco.
3) Cada nó trabalha para encontrar uma prova de trabalho difícil para seu bloco.
4) Quando um nó encontra uma prova de trabalho, ele transmite o bloco para todos os nós.
5) Os nós aceitam o bloqueio apenas se todas as transações nele são válidas e ainda não foram gastas.
6) Os nós expressam sua aceitação do bloco trabalhando na criação do próximo bloco no cadeia, usando o hash do bloco aceito como o hash anterior.
Os nós sempre consideram a cadeia mais longa como a correta e continuarão
trabalhando estendendo-o. Se dois nós transmitem versões diferentes do próximo bloco simultaneamente, alguns os nós podem receber um ou outro primeiro. Nesse caso, eles trabalham no primeiro que receberam, mas salve o outro ramo para o caso de se tornar mais longo. O empate será desfeito na próxima prova de trabalho é encontrado e um ramo torna-se mais longo; os nós que estavam trabalhando no outro branch, então, mudará para o mais longo.
As novas transmissões de transações não precisam necessariamente atingir todos os nós. Contanto que eles alcancem muitos nós, eles entrarão em um bloco em pouco tempo. As transmissões em bloco também são tolerantes a descartadas mensagens. Se um nó não receber um bloco, ele irá solicitá-lo quando receber o próximo bloco e
percebe que perdeu um.
6 - Incentivo
Por convenção, a primeira transação em um bloco é uma transação especial que inicia uma nova moeda de propriedade pelo criador do bloco. Isso adiciona um incentivo para que os nós apoiem a rede e fornece uma forma de inicialmente distribuir as moedas em circulação, uma vez que não existe uma autoridade central para emiti-las.
A adição constante de uma constante de quantidade de novas moedas é análogo ao gasto de garimpeiros recursos para adicionar ouro à circulação. Em nosso caso, é o tempo de CPU e a eletricidade que são gastos.
O incentivo também pode ser financiado com taxas de transação. Se o valor de saída de uma transação for menor que seu valor de entrada, a diferença é uma taxa de transação que é adicionada ao valor de incentivo de o bloco que contém a transação.
Uma vez que um número predeterminado de moedas tenha entrado circulação, o incentivo pode mudar inteiramente para taxas de transação e ser completamente inflação gratuitamente.
O incentivo pode ajudar a encorajar os nós a permanecerem honestos. Se um invasor ganancioso for capaz de reunir mais poder de CPU do que todos os nós honestos, ele teria que escolher entre usá-lo para defraudar pessoas roubando seus pagamentos ou usando-os para gerar novas moedas. Ele deveria achar mais lucrativo jogar de acordo com as regras, regras que o favorecem com mais moedas novas do que todos os outros combinados, do que minar o sistema e a validade de sua própria riqueza.
7 - Recuperando espaço em disco
Uma vez que a última transação em uma moeda é enterrada sob blocos suficientes, as transações gastas antes ele pode ser descartado para economizar espaço em disco.
Para facilitar isso sem quebrar o hash do bloco, as transações são hash em uma árvore Merkle [7] [2] [5], com apenas a raiz incluída no hash do bloco.
Os blocos antigos podem ser compactados removendo os galhos da árvore. Os hashes internos fazem não precisa ser armazenado.
Block Block
Block Header (Block Hash) Prev Hash Nonce
Hash01
Hash0 Hash1 Hash2 Hash3 Hash23 Root Hash
Hash01
Hash2
Tx3 Hash23 Block Header (Block Hash)
Root Hash
Transactions Hashed in a Merkle Tree After Pruning Tx0-2 from the Block Prev Hash Nonce
Hash3
Tx0 Tx1 Tx2 Tx3
Um cabeçalho de bloco sem transações teria cerca de 80 bytes. Se supormos que os blocos são gerado a cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4,2 MB por ano. Com sistemas de computador normalmente vendendo com 2 GB de RAM a partir de 2008, e a Lei de Moore prevendo o crescimento atual de 1,2 GB por ano, o armazenamento não deve ser um problema, mesmo que os cabeçalhos dos blocos devam ser mantidos em memória.
8 - Verificação de pagamento simplificada
É possível verificar os pagamentos sem executar um nó de rede completo. Um usuário só precisa manter uma cópia dos cabeçalhos de bloco da mais longa cadeia de prova de trabalho, que ele pode obter consultando nós da rede até que ele esteja convencido de que tem a cadeia mais longa e obtenha o ramal Merkle vinculando a transação ao bloco em que está marcada a data e hora. Ele não pode verificar a transação para ele mesmo, mas ao ligá-lo a um lugar na cadeia, ele pode ver que um nó da rede o aceitou, e os blocos adicionados depois disso confirmam que a rede o aceitou.
Hash01
Hash2 Hash3
Hash23 Block Header
Merkle Root Prev Hash Nonce Block Header
Merkle Root Prev Hash Nonce
Block Header
Merkle Root Prev Hash Nonce
Merkle Branch for Tx3 Longest Proof-of-Work Chain
Tx3
Como tal, a verificação é confiável, desde que nós honestos controlem a rede, mas é mais vulnerável se a rede for dominada por um invasor. Embora os nós da rede possam verificar transações por si próprios, o método simplificado pode ser enganado por um invasor fabricado transações enquanto o invasor puder continuar a dominar a rede.
Uma estratégia para proteger contra isso seria aceitar alertas de nós da rede quando eles detectam um bloco, solicitando que o software do usuário baixe o bloco completo e as transações alertadas para confirmar a inconsistência. As empresas que recebem pagamentos frequentes provavelmente ainda vão querer execute seus próprios nós para uma segurança mais independente e verificação mais rápida.
9 - Combinando e dividindo o valor
Embora fosse possível lidar com moedas individualmente, seria difícil de fazer um transação separada para cada centavo em uma transferência. Para permitir que o valor seja dividido e combinado, as transações contêm várias entradas e saídas.
Normalmente, haverá uma única entrada de uma transação anterior maior ou várias entradas combinando valores menores, e no máximo dois saídas: uma para o pagamento e outra devolvendo o troco, se houver, ao remetente.
Deve-se notar que fan-out, onde uma transação depende de várias transações, e aquelas as transações dependem de muitos mais, não é um problema aqui. Nunca há necessidade de extrair um cópia autônoma completa do histórico de uma transação.
10 - Privacidade
O modelo bancário tradicional atinge um nível de privacidade, limitando o acesso às informações ao partes envolvidas e o terceiro de confiança. A necessidade de anunciar todas as transações publicamente impede este método, mas a privacidade ainda pode ser mantida interrompendo o fluxo de informações em outro lugar: mantendo as chaves públicas anônimas. O público pode ver que alguém está enviando uma quantia para outra pessoa, mas sem informações que vinculem a transação a ninguém. Isto é
semelhante ao nível de informação divulgado pelas bolsas de valores, onde o tempo e o tamanho do as negociações individuais, a "fita", são tornadas públicas, mas sem dizer quem eram as partes.
Como um firewall adicional, um novo par de chaves deve ser usado para cada
transação para mantê-los de ser vinculado a um proprietário comum. Alguns links ainda são inevitáveis com entradas múltiplas transações, que necessariamente revelam que seus insumos pertenciam ao mesmo proprietário. O risco é que se o proprietário de uma chave for revelado, a vinculação pode revelar outras transações que pertenciam a o mesmo proprietário.
Transaction
In ...
In Out
...
Identities Transactions Trusted
Third Party Counterparty Public
Identities Transactions Public
New Privacy Model Traditional Privacy Model
11 - Cálculos
Consideramos o cenário de um invasor tentando gerar uma cadeia alternativa mais rápido do que o honesto cadeia. Mesmo que isso seja feito, não deixa o sistema aberto a mudanças arbitrárias, como como criar valor do nada ou tirar dinheiro que nunca pertenceu ao invasor. Nós são não aceitará uma transação inválida como pagamento, e nós honestos nunca aceitarão um bloqueio contendo-os. Um invasor só pode tentar alterar uma de suas próprias transações para retomar dinheiro que ele gastou recentemente.
A corrida entre a cadeia honesta e uma cadeia do atacante pode ser caracterizada como um Binômio Caminhada aleatória. O evento de sucesso é a cadeia honesta sendo estendida em um bloco, aumentando seu liderado por +1, e o evento de falha é a
cadeia do invasor sendo estendida em um bloco, reduzindo o gap por -1.
A probabilidade de um atacante recuperar de um dado déficit é análoga à de um jogador Problema de arruinar. Suponha que um jogador com crédito ilimitado comece com um déficit e jogue potencialmente um número infinito de tentativas para tentar chegar ao ponto de equilíbrio. Podemos calcular a probabilidade de ele alguma vez atinge o ponto de equilíbrio, ou que um invasor sempre alcança a cadeia honesta, como segue [8]:
p = probabilidade de um nó honesto encontrar o próximo bloco q = probabilidade de o atacante encontrar o próximo bloco qz = probabilidade de o atacante alcançar os blocos z atrás
Dada a nossa suposição de que p> q , a probabilidade cai exponencialmente conforme o número de blocos que o atacante tem que acompanhar os aumentos. Com as
probabilidades contra ele, se ele não tiver sorte pule para a frente logo no início, suas chances tornam-se cada vez menores à medida que ele fica para trás.
Agora consideramos quanto tempo o destinatário de uma nova transação precisa esperar antes de ser suficientemente certo de que o remetente não pode alterar a transação. Presumimos que o remetente é um invasor que quer fazer o destinatário acreditar que o pagou por um tempo, então mude para pagar de volta para depois de algum tempo. O receptor será alertado quando isso acontecer, mas o remetente espera que seja tarde demais. O receptor gera um novo par de chaves e dá a chave pública ao remetente pouco antes assinando. Isso evita que o remetente prepare uma cadeia de blocos com antecedência, trabalhando em continuamente até que ele tenha a sorte de avançar o suficiente, então, executando a transação em aquele momento. Assim que a transação é enviada, o remetente desonesto começa a trabalhar em segredo em um cadeia paralela contendo uma versão alternativa de sua transação.
O destinatário espera até que a transação seja adicionada a um bloco e z blocos foram vinculado depois dele. Ele não sabe a quantidade exata de progresso que o invasor fez, mas assumindo que os blocos honestos levaram o tempo médio esperado por bloco, o potencial do invasor o progresso será uma distribuição de Poisson com valor esperado:
Para obter a probabilidade de o invasor ainda conseguir alcançar agora, multiplicamos a densidade de Poisson por cada quantidade de progresso que ele poderia ter feito pela probabilidade de conseguir alcançá-lo a partir desse ponto:
qz=
{
q/1p z if p≤if p qq}
=z q p
∑
k=0
∞ k
e−
k! ⋅
{
q/p1 z−k if k≤if k zz}
Reorganizando para evitar somar a cauda infinita da distribuição ...
1−
∑
k=0
z k
e−
k! 1− q/p z−k
Converting to C code...
#include <math.h>
double AttackerSuccessProbability(double q, int z) {
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++) {
double poisson = exp(-lambda);
for (i = 1; i <= k; i++) poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Running some results, we can see the probability drop off exponentially with z.
q=0.1
z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3
z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006
Solving for P less than 0.1%...
P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340
12 - Conclusão
Propusemos um sistema para transações eletrônicas sem depender de confiança.
Começamos com a estrutura usual de moedas feitas de assinaturas digitais, que fornece forte controle de propriedade, mas está incompleta sem uma forma de evitar gastos duplos. Para resolver isso, nós propôs uma rede ponto a ponto usando prova de trabalho para registrar um histórico público de transações que rapidamente se torna computacionalmente impraticável para um invasor alterar se nós honestos controlar a maior parte do poder da CPU. A rede é robusta em sua simplicidade não estruturada.
Nós trabalhe tudo de uma vez com pouca coordenação. Eles não precisam ser
identificados, uma vez que as mensagens são não é encaminhado para nenhum local específico e só precisa ser entregue com base no melhor esforço. Nós podem sair e reingressar na rede à vontade, aceitando a cadeia de prova de trabalho como prova do que aconteceu enquanto eles estavam fora. Eles votam com seu poder de CPU,
expressando sua aceitação de blocos válidos, trabalhando em estendê-los e rejeitando blocos inválidos, recusando-se a trabalhar em eles. Quaisquer regras e incentivos necessários podem ser aplicados com este mecanismo de consenso.
Com estas mesmas regras e sistema, iremos criar a primeira loteria descentralizada do mundo, na qual cada sorteio será antecipadamente definido a numeração do vencedor com base de criação e distribuição das moedas, assim, nem o participante e nem a plataforma conseguirá burlar as regras dos sorteios, evitando fraudes, levando transparência e aumentando as chances de ser um ganhador.
References
[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.
[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
[3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.
[4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping,"
In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
[5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.
[6] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.
[8] W. Feller, "An introduction to probability theory and its applications," 1957.
