Topic: [TRADUÇÂO] Paper bmoney - Wei Dai (Read 294 times)
Obrigado pelo contribudo! Afinal esse testo è um pouco o avò do Bitcoin em sì, entao tem relevancia pra quem quer descubrir mais sobre o nascimento da moeda.
Sim, o site foi ao ar em Outubro. Mas está evoluindo rapidamente 
Atualmente, nosso grupo do telegram é fechado, devido à demanda muito alta que tivemos com as divulgações. Mas se você estiver interessado em participar e colaborar com traduções, me avisa que eu te coloco no grupo.
Atualmente, nosso grupo do telegram é fechado, devido à demanda muito alta que tivemos com as divulgações. Mas se você estiver interessado em participar e colaborar com traduções, me avisa que eu te coloco no grupo.
Oi Pessoal, vocês já conhecem o https://cypherpunks.com.br/ ?
Temos traduzido textos históricos do cyperpunks para o português, inclusive o b money já está lá. Se vocês quiserem ajudar com as traduções, dêem uma olhada no nosso github https://github.com/cypherpunksbr/cypherpunks.com.br
Já traduzimos dezenas de textos e tem vários ainda na lista aguardando tradução.
Temos traduzido textos históricos do cyperpunks para o português, inclusive o b money já está lá. Se vocês quiserem ajudar com as traduções, dêem uma olhada no nosso github https://github.com/cypherpunksbr/cypherpunks.com.br
Já traduzimos dezenas de textos e tem vários ainda na lista aguardando tradução.
Náo conhecia, mas parece que é novo. Muito legal. Parabéns pela iniciativa.
Oi Pessoal, vocês já conhecem o https://cypherpunks.com.br/ ?
Temos traduzido textos históricos do cyperpunks para o português, inclusive o b money já está lá. Se vocês quiserem ajudar com as traduções, dêem uma olhada no nosso github https://github.com/cypherpunksbr/cypherpunks.com.br
Já traduzimos dezenas de textos e tem vários ainda na lista aguardando tradução.
Temos traduzido textos históricos do cyperpunks para o português, inclusive o b money já está lá. Se vocês quiserem ajudar com as traduções, dêem uma olhada no nosso github https://github.com/cypherpunksbr/cypherpunks.com.br
Já traduzimos dezenas de textos e tem vários ainda na lista aguardando tradução.
Por isso q o Andreas Antonopoulos sempre fala que a grande invenção do Satoshi é o proof of work, pois foi o que permitiu que esse sistema funcionasse (e que não foi previsto nesse artigo do wei daí).
Eu vejo o PoW do BTC como um milagre, era muito fácil fazer um 51% no começo (não sei se já sabiam disso e por quanto tempo o BTC teve um hashrate ínfimo).. Qualquer troll poderia ter acabado com o sonho lá no começo
Mas o principal problema do 51% é o do gasto duplo ou reversão de transações. Isso é um problema quando existem transações que não são apenas testes. Ou melhor, os incentivos para um ataque desse tipo existem quando é possivel vislumbrar uma recompensa. Hoje um ataque 51% uma pessoa poderia dobrar as moedas com transações envolvendo exchanges.
Mas no começo era tudo teste. Acho que os desenvolvedores odiavam os primeiros sites de Dice por isso. Eles não necessitavam de confirmações o que abria diversas possibilidades que poderiam prejudicar a rede.
Por isso q o Andreas Antonopoulos sempre fala que a grande invenção do Satoshi é o proof of work, pois foi o que permitiu que esse sistema funcionasse (e que não foi previsto nesse artigo do wei daí).
Eu vejo o PoW do BTC como um milagre, era muito fácil fazer um 51% no começo (não sei se já sabiam disso e por quanto tempo o BTC teve um hashrate ínfimo).. Qualquer troll poderia ter acabado com o sonho lá no começo
Eu realmente sempre ignorei as referências do white paper do bitcoin.
Tem um post do Satoshi onde ele fala que gastou a maior parte do tempo imaginando situações e pouca parte esrevendo código. Não lembro a proporção, mas era algo como 80%-20%. Isso durante os dois anos antes de enviar o primeiro email. Acredito que ele tenha também lido bem mais artigos e textos do que comentou, mas só colocou referencias daqueles que parecem essenciais para compreender como funcionaria o Bitcoin.
A filosofia muitas vezes é ignorada, mas nesses momentos de queda ajuda a compreender por qual razão as cripto-moedas ainda poderiam ter um valor no futuro.
Bastante interessante. Eu realmente sempre ignorei as referências do white paper do bitcoin. É inegável a semelhança com o blockchain.
Por isso q o Andreas Antonopoulos sempre fala que a grande invenção do Satoshi é o proof of work, pois foi o que permitiu que esse sistema funcionasse (e que não foi previsto nesse artigo do wei daí). Vou estudar mais sobre esse assunto.
Cada vez mais encontramos só desinformação e notícias repetidas por aí. Bom ver algo real e de qualidade.
Por isso q o Andreas Antonopoulos sempre fala que a grande invenção do Satoshi é o proof of work, pois foi o que permitiu que esse sistema funcionasse (e que não foi previsto nesse artigo do wei daí). Vou estudar mais sobre esse assunto.
Cada vez mais encontramos só desinformação e notícias repetidas por aí. Bom ver algo real e de qualidade.
Wei Dai publicou em 1998 um paper intitulado bmoney. Muitos atribuem a este paper a base do inicio de um interesse em cripto-moedas. É um paper bem simples e de fácil compreensão que foi citado por Satoshi inumeras vezes incluindo no paper do Bitcoin, embora não se saiba ao certo se Satoshi foi inspirado por esse texto ou se o conheceu quando já estava trabalhando na ideia do Bitcoin. Eu procurei na internet uma versão traduzida e não encontrei facilmente. Provavelmente existem diversas traduções por ai, então esse tópico poderia servir para discutirmos essa idea.
Eu sou fascinado pelo manifesto crypto-anarquista do Tim May. Ao contrário das comunidades
tradicionalmente associadas à palavra "anarquia", em uma cripto-anarquia, o
governo não é temporariamente destruído, mas permanentemente proibido e
permanentemente desnecessário. É uma comunidade onde a ameaça da violência é
impotente porque a violência é impossível e a violência é impossível
porque seus participantes não podem ser ligados a seus nomes verdadeiros ou localizações físicas.
Até hoje, não está claro, mesmo teoricamente, como tal comunidade poderia
operar. Uma comunidade é definida pela cooperação de seus participantes,
cooperação eficiente requer um meio de troca (dinheiro) e uma forma de
para executar contratos. Tradicionalmente, esses serviços foram fornecidos pelo
governo ou instituições patrocinadas pelo governo e apenas para
entidades legalizadas. Neste artigo, eu descrevo um protocolo pelo qual esses serviços
podem ser fornecidos para e por entidades não rastreáveis.
Na verdade, vou descrever dois protocolos. O primeiro é impraticável, porque faz uso pesado
de um canal de transmissão anônimo síncrono e não inflamável. No entanto, vai motivar o segundo,
um protocolo mais prático. Em ambos os casos, eu vou assumir a existência de uma rede não rastreável,
onde os remetentes e destinatários são identificados apenas por pseudônimos (ou seja, chaves públicas)
e todas as mensagens são assinadas pelo remetente e criptografado para o seu receptor.
No primeiro protocolo, cada participante mantém um banco de dados (separado)
de quanto dinheiro pertence a cada pseudônimo. Essas contas coletivamente
definem a propriedade do dinheiro, e como essas contas são atualizadas é o
tópico principal deste protocolo.
1. A criação de dinheiro. Qualquer um pode criar dinheiro transmitindo a
solução de um problema computacional anteriormente não resolvido. As únicas
condições são que deve ser fácil determinar quanto esforço de computação
demorou para resolver o problema e a solução não deve ter
valor, seja prático ou intelectual. O número de unidades monetárias
criada é igual ao custo do esforço de computação em termos de um
cesta padrão de commodities. Por exemplo, se um problema demorar 100 horas
para resolver no computador que resolve mais economicamente, e leva 3
cestas padrão para comprar 100 horas de tempo de computação naquele computador
no mercado aberto, em seguida, após a transmissão da solução para esse
problema todo mundo credita a conta da emissora 3 unidades.
2. A transferência de dinheiro. Se Alice (proprietária do pseudônimo K_A) desejar
transferir X unidades de dinheiro para Bob (dono do pseudônimo K_B), ela transmite
a mensagem "Eu dou X unidades de dinheiro para K_B" assinado por K_A. Após a
transmissão desta mensagem, todos debitam a conta do K_A em X unidades e
creditam a conta de K_B em X unidades, a menos que isso crie uma
saldo negativo na conta de K_A, neste caso, a mensagem é ignorada.
3. A efetivação de contratos. Um contrato válido deve incluir um valor máximo de
indenização em caso de inadimplência de um dos participante. Devá,
também, incluir uma parte que irá realizar a arbitragem se houver uma
disputa. Todas as partes de um contrato, incluindo o árbitro, devem transmitir
suas assinaturas antes de se tornar efetiva. Após a transmissão de
contrato e todas as assinaturas, cada participante debita a conta de
cada parte pelo montante da sua reparação máxima e credita uma conta especial
identificada por um hash seguro do contrato, pela soma do máximo em
reparações. O contrato torna-se efetivo se os débitos forem bem sucedidos para
cada parte, sem produzir um saldo negativo, caso contrário, o contrato
é ignorado e as contas são revertidas. Um exemplo de contrato:
K_A concorda em enviar para K_B a solução para o problema P antes de 0:0:0 1/1/2000.
K_B concorda em pagar K_A 100 MU (unidades monetárias) antes de 0:0:0 1/1/2000.
K_C concorda em realizar arbitragem em caso de litígio.
K_A concorda em pagar um máximo de 1000 MU em caso de descomprir o acordo.
K_B concorda em pagar um máximo de 200 MU em caso de descomprir o acordo.
K_C concorda em pagar um máximo de 500 MU em caso de descomprir o acordo.
4. A conclusão dos contratos. Se um contrato for concluído sem contestação,
cada parte transmite uma mensagem assinada "O contrato com SHA-1 hash H
foi concluido sem reparações." ou possivelmente "O contrato com hash SHA-1
H conclui com as seguintes reparações: ... " Após a transmissão de todas as
assinaturas, todo participante credita a conta de cada parte pelo
quantidade de sua reparação máxima, remove a conta do contrato, então
credita ou debita a conta de cada parte de acordo com a agenda de reparação, se houver uma.
5. A execução de contratos. Se as partes de um contrato não puderem concordar
em uma conclusão apropriada, mesmo com a ajuda do árbitro, cada
parte transmite uma sugestão agendada de reparação/multa sugerida e quaisquer argumentos ou
provas a seu favor. Cada participante faz uma determinação quanto a atual demanda de reparações
e multas. Modificando sua conta de acordo.
No segundo protocolo, as contas de quem tem quanto dinheiro é guardado por
um subconjunto dos participantes (chamados servidores a partir de agora) ao invés de
todos. Esses servidores são vinculados por um canal de difusão no estilo da Usenet.
O formato das mensagens de transação transmitidas neste canal permanece o
mesmo que no primeiro protocolo, mas os participantes afetados de cada
transação deve verificar se a mensagem foi recebida e
processado com sucesso por um subconjunto de servidores selecionado aleatoriamente.
Como os servidores devem ser confiáveis em certo grau, é necessário algum mecanismo que os
mantenha honestos. Cada servidor é obrigado a depositar uma certa quantia de
dinheiro em uma conta especial para ser usado no pagamento de eventuais multas ou recompensas para
prova de má conduta. Além disso, cada servidor deve publicar periodicamente e
comprometer-se com a sua atual base de criação de dinheiro e propriedade monetária. Cada
participante deve verificar se os saldos de sua própria contas estão corretas e
que a soma dos saldos das contas não é maior que a quantia total
de dinheiro criado. Isso impede que os servidores, mesmo em conluio total,
expandam permanente e sem custos a oferta monetária. Novos servidores também podem
usar o banco de dados publicado para sincronizar com os servidores existentes.
O protocolo proposto neste artigo permite que entidades pseudo-anônimas não rastreáveis pssam
cooperar entre si de maneira mais eficiente, fornecendo-lhes
um meio de troca e um método de execução de contratos. O protocolo provavelmente
pode ser mais eficiente e seguro, mas eu espero que isso seja um passo para tornar a cripto-anarquia uma
possibilidade prática, bem como uma possibilidade teórica.
Eu sou fascinado pelo manifesto crypto-anarquista do Tim May. Ao contrário das comunidades
tradicionalmente associadas à palavra "anarquia", em uma cripto-anarquia, o
governo não é temporariamente destruído, mas permanentemente proibido e
permanentemente desnecessário. É uma comunidade onde a ameaça da violência é
impotente porque a violência é impossível e a violência é impossível
porque seus participantes não podem ser ligados a seus nomes verdadeiros ou localizações físicas.
Até hoje, não está claro, mesmo teoricamente, como tal comunidade poderia
operar. Uma comunidade é definida pela cooperação de seus participantes,
cooperação eficiente requer um meio de troca (dinheiro) e uma forma de
para executar contratos. Tradicionalmente, esses serviços foram fornecidos pelo
governo ou instituições patrocinadas pelo governo e apenas para
entidades legalizadas. Neste artigo, eu descrevo um protocolo pelo qual esses serviços
podem ser fornecidos para e por entidades não rastreáveis.
Na verdade, vou descrever dois protocolos. O primeiro é impraticável, porque faz uso pesado
de um canal de transmissão anônimo síncrono e não inflamável. No entanto, vai motivar o segundo,
um protocolo mais prático. Em ambos os casos, eu vou assumir a existência de uma rede não rastreável,
onde os remetentes e destinatários são identificados apenas por pseudônimos (ou seja, chaves públicas)
e todas as mensagens são assinadas pelo remetente e criptografado para o seu receptor.
No primeiro protocolo, cada participante mantém um banco de dados (separado)
de quanto dinheiro pertence a cada pseudônimo. Essas contas coletivamente
definem a propriedade do dinheiro, e como essas contas são atualizadas é o
tópico principal deste protocolo.
1. A criação de dinheiro. Qualquer um pode criar dinheiro transmitindo a
solução de um problema computacional anteriormente não resolvido. As únicas
condições são que deve ser fácil determinar quanto esforço de computação
demorou para resolver o problema e a solução não deve ter
valor, seja prático ou intelectual. O número de unidades monetárias
criada é igual ao custo do esforço de computação em termos de um
cesta padrão de commodities. Por exemplo, se um problema demorar 100 horas
para resolver no computador que resolve mais economicamente, e leva 3
cestas padrão para comprar 100 horas de tempo de computação naquele computador
no mercado aberto, em seguida, após a transmissão da solução para esse
problema todo mundo credita a conta da emissora 3 unidades.
2. A transferência de dinheiro. Se Alice (proprietária do pseudônimo K_A) desejar
transferir X unidades de dinheiro para Bob (dono do pseudônimo K_B), ela transmite
a mensagem "Eu dou X unidades de dinheiro para K_B" assinado por K_A. Após a
transmissão desta mensagem, todos debitam a conta do K_A em X unidades e
creditam a conta de K_B em X unidades, a menos que isso crie uma
saldo negativo na conta de K_A, neste caso, a mensagem é ignorada.
3. A efetivação de contratos. Um contrato válido deve incluir um valor máximo de
indenização em caso de inadimplência de um dos participante. Devá,
também, incluir uma parte que irá realizar a arbitragem se houver uma
disputa. Todas as partes de um contrato, incluindo o árbitro, devem transmitir
suas assinaturas antes de se tornar efetiva. Após a transmissão de
contrato e todas as assinaturas, cada participante debita a conta de
cada parte pelo montante da sua reparação máxima e credita uma conta especial
identificada por um hash seguro do contrato, pela soma do máximo em
reparações. O contrato torna-se efetivo se os débitos forem bem sucedidos para
cada parte, sem produzir um saldo negativo, caso contrário, o contrato
é ignorado e as contas são revertidas. Um exemplo de contrato:
K_A concorda em enviar para K_B a solução para o problema P antes de 0:0:0 1/1/2000.
K_B concorda em pagar K_A 100 MU (unidades monetárias) antes de 0:0:0 1/1/2000.
K_C concorda em realizar arbitragem em caso de litígio.
K_A concorda em pagar um máximo de 1000 MU em caso de descomprir o acordo.
K_B concorda em pagar um máximo de 200 MU em caso de descomprir o acordo.
K_C concorda em pagar um máximo de 500 MU em caso de descomprir o acordo.
4. A conclusão dos contratos. Se um contrato for concluído sem contestação,
cada parte transmite uma mensagem assinada "O contrato com SHA-1 hash H
foi concluido sem reparações." ou possivelmente "O contrato com hash SHA-1
H conclui com as seguintes reparações: ... " Após a transmissão de todas as
assinaturas, todo participante credita a conta de cada parte pelo
quantidade de sua reparação máxima, remove a conta do contrato, então
credita ou debita a conta de cada parte de acordo com a agenda de reparação, se houver uma.
5. A execução de contratos. Se as partes de um contrato não puderem concordar
em uma conclusão apropriada, mesmo com a ajuda do árbitro, cada
parte transmite uma sugestão agendada de reparação/multa sugerida e quaisquer argumentos ou
provas a seu favor. Cada participante faz uma determinação quanto a atual demanda de reparações
e multas. Modificando sua conta de acordo.
No segundo protocolo, as contas de quem tem quanto dinheiro é guardado por
um subconjunto dos participantes (chamados servidores a partir de agora) ao invés de
todos. Esses servidores são vinculados por um canal de difusão no estilo da Usenet.
O formato das mensagens de transação transmitidas neste canal permanece o
mesmo que no primeiro protocolo, mas os participantes afetados de cada
transação deve verificar se a mensagem foi recebida e
processado com sucesso por um subconjunto de servidores selecionado aleatoriamente.
Como os servidores devem ser confiáveis em certo grau, é necessário algum mecanismo que os
mantenha honestos. Cada servidor é obrigado a depositar uma certa quantia de
dinheiro em uma conta especial para ser usado no pagamento de eventuais multas ou recompensas para
prova de má conduta. Além disso, cada servidor deve publicar periodicamente e
comprometer-se com a sua atual base de criação de dinheiro e propriedade monetária. Cada
participante deve verificar se os saldos de sua própria contas estão corretas e
que a soma dos saldos das contas não é maior que a quantia total
de dinheiro criado. Isso impede que os servidores, mesmo em conluio total,
expandam permanente e sem custos a oferta monetária. Novos servidores também podem
usar o banco de dados publicado para sincronizar com os servidores existentes.
O protocolo proposto neste artigo permite que entidades pseudo-anônimas não rastreáveis pssam
cooperar entre si de maneira mais eficiente, fornecendo-lhes
um meio de troca e um método de execução de contratos. O protocolo provavelmente
pode ser mais eficiente e seguro, mas eu espero que isso seja um passo para tornar a cripto-anarquia uma
possibilidade prática, bem como uma possibilidade teórica.
Jump to: