Como ganhar dinheiro na Web usando o Bitcoin - a maneira como ele foi projetado

Em 2009, o Bitcoin usou um recurso que permitia a troca de informações de IP para IP. A carteira de 2009 não era mais que uma prova de conceito, e muitos dos melhores aspectos do Bitcoin foram desativados porque os que desenvolviam o software não conseguiram entendê-lo.

Na semana passada, discuti como uma chave poderia ser usada em um cartão inteligente, enquanto a privacidade era mantida usando o modelo de identidade do firewall do Bitcoin. Para a próxima semana, mostrarei um método que permite que um servidor da Web aceite pagamentos com segurança em bitcoin ingenuamente e um método que permite que tributos fiduciários e outros tokens sejam trocados, mantendo um nível absoluto de privacidade.

Certificados PKI - o processo

Tal - e não a mineração - é o aspecto ponto a ponto do Bitcoin, e é uma das primeiras coisas que os desenvolvedores do Core removeram.

Em 2009, ainda era necessário muito trabalho.

Em 2009, o sistema ainda não estava completo. Vários métodos possíveis precisavam ser testados, e o método usado no cliente de 2009 deixou muito a desejar. Por outro lado, era apenas uma prova de conceito.

Para corrigir esses problemas, precisamos começar entendendo que nós e carteiras são separados. Nós são mineradores e carteiras são usadas pelo usuário para permitir uma transação P2P. Na publicação de hoje, explicarei como um certificado da Web baseado em ECDSA, um certificado de servidor SSL / TLS que permite navegar na Internet com segurança, pode ser a base de um sistema de pagamento comercial - um sistema que permanece seguro e privado, e ainda é construído de tal forma que envia um pagamento para um endereço específico apenas uma vez.

Em outras palavras, nunca reutiliza chaves.

Existem duas maneiras de enviar dinheiro. Se o destinatário estiver online, você
pode digitar seu endereço IP e ele irá se conectar, obter um novo público
chave e envie a transação com comentários. Se o destinatário estiver
não online, é possível enviar para o endereço Bitcoin, que
é um hash da chave pública que eles fornecem. Eles receberão
a transação na próxima vez que se conectar e pegar o bloco é
Este método tem a desvantagem de que nenhuma informação de comentário
é enviado e um pouco de privacidade pode ser perdido se o endereço for usado
várias vezes, mas é uma alternativa útil se os dois usuários não puderem
estar on-line ao mesmo tempo ou o destinatário não pode receber
conexões.

O certificado é algo que pode ser usado em S / MIME e HTTPS.

Se pegarmos a chave associada a um certificado registrado pela CA, podemos criar um registro público de todas as moedas enviadas ao comerciante e, ao mesmo tempo, manter a privacidade.

Começaremos com Alice, uma consumidora, e Bob, um comerciante da Web com um certificado da Web baseado em ECDSA para seu site HTTPS://www.bob.com.

Alice tem uma chave mestra do Bitcoin. A chave mestra não é usada para enviar ou receber bitcoin e pode ser um método para criar uma chave de identidade (e pode até estar em um cartão inteligente). Essa é a chave que chamaremos de P (Alice).

O site de Bob (deixarei para outras pessoas pensarem em como é simples estender o mecanismo para o e-mail com S-MIME) tem uma chave mestra P (Bob).

Alice tem um conjunto de moedas (ou seja, referências UTXO) que podem não ter relação com P (Alice) e que não têm nenhuma relação com sua chave principal. Vamos chamá-lo de P (A-1-i); aqui, (i) refere-se ao número da moeda usada.

Alice pode criar um segredo comum (s1) usando o processo documentado no seguinte documento:

DETERMINAR UM SEGREDO COMUM PARA O TROCAMENTO SEGURO DE INFORMAÇÃO E AS CHAVES CRIPTOGRÁFICAS DETERMINÍSTICAS HIERARQUICAS

Para usar esse mecanismo (um dos muitos exemplos), Alice vai à loja virtual de Bob e agora tenta pagar. Alice pode calcular um segredo compartilhado com Bob. Para ser mais seguro, Alice pode usar o ID da sessão da Web que ela compartilha com Bob, o número da fatura ou qualquer outra coisa. Ele pode ser usado em um valor baseado em HMAC para adicionar mais segurança e privacidade, mas por hoje vou usar um hash simples para tornar o processo mais simples de entender.

Alice e Bob podem calcular um valor S, que está vinculado às chaves que Alice e Bob usam na Web. Alice pode ter uma chave de identidade e autenticação que não se vincule publicamente às suas compras, mas protege todas as suas comunicações com Bob.

Alice envia uma mensagem para Bob criptografada em uma transação de Bitcoin. A transação pode ser concluída usando um processo offline ou online. Se Bob estiver online, ele poderá armazenar o valor de um nonce de Alice como parte do check-out na web.

Se Bob não estiver online e tiver um site bastante simples, ele poderá usar o blockchain para registrar informações sobre o pagamento e verificá-lo.

Alice envia a Bob uma transação para P (Bob). Bob não usa esse endereço, então o pagamento é pequeno; sem o limite de poeira, um mero satoshi será suficiente. Alice envia a mensagem para o pagamento ao endereço P (Bob), e Bob não a usa para obter fundos. Podemos dizer que Bob ONLY gastará a partir do endereço (aquele associado à chave pública P (Bob)) quando o certificado estiver marcado como expirado. O processo atua como uma forma de "lista de revogação" distribuída, na qual Bob pode controlar sua própria chave. Além disso, se a chave e o certificado de Bob forem atacados e as transações de poeira aqui forem gastas por um invasor, ele atua como um alerta automatizado. Bob poderia manter uma pequena quantia de fundos na conta como forma de permitir que os hackers pensassem que era um endereço válido para uso (por exemplo, US $ 2.000) que só seria perdido se a conta fosse invadida, mas também alerta todos os clientes de Bob para o ataque.

Bob pode tornar a conta mais privada usando uma subchave - veja a Fig. 9 na patente:

Fig. 9 da patente 42

Bob pode até ter um processo em que o número da fatura está associado a uma subchave.

Alice agora envia para o endereço associado a P (Bob) - e no script ou como um valor OP_RETURN inclui um valor que foi criptografado (como com o uso de um algoritmo de criptografia AES). Usando o método mencionado acima, Bob pode calcular (S). Os dados na mensagem para Bob enviados com um único satoshi (mais taxas de mineração) contêm tudo o que Bob precisa saber para descobrir para onde Alice enviou o pagamento. Bob usa a chave simétrica (S) para descriptografar os dados na mensagem:

  • Criptografar (S) [M]

o que dá a Bob a mensagem de Alice, M.

  • Descriptografar (S) [M]

Bob agora pode calcular um endereço de chave a partir da chave derivada:

  • P (pago por Bob) = P (Bob) + HMAC (M ~ S) xG
  • A chave da mensagem é P (Mensagem Compartilhada) = HMAC (M ~ S) xG

APENAS Bob e Alice conhecerão o novo segredo HMAC (M ~ S).

Alice pode provar que enviou um pagamento a Bob. Bob pode encontrar o dinheiro de Alice e verificar a transação.

Ao mesmo tempo, nenhuma parte externa pode determinar o endereço para o qual Alice enviou seu pagamento de - P (A-1-i) para Bob em P (Bob-Pago).

Como Bob tem um registro no blockchain em P (Bob), e tem uma trilha de auditoria completa de todos os endereços de pagamento que ele recebeu. O registro pode ser vinculado a faturas, pedidos de compra e muito mais, permitindo que Bob construa uma trilha de auditoria completa de todas as trocas e uma que não possa ser excluída, alterada ou manipulada. O método atende a todos os problemas contábeis legislativos necessários para Bob e ele pode ter um endereço dividido em que o IVA e outros impostos sobre vendas são enviados ao governo quando ele é pago. Em outras palavras, Bob não precisa passar por auditorias caras, e a autoridade tributária pode ser paga imediatamente, sem demora.

Tokens e Bitcoin

Usando um protocolo como o Tokenized ou um dos vários para os quais o nChain registrou patentes, Alice e Bob também podem trocar autorização tokenizada. Isso significa que Alice poderia pagar a Bob usando um token de GBP emitido por um banco no Reino Unido. Esse token é transmitido usando o processo listado acima, permitindo que Alice e Bob efetuem transações com segurança usando dinheiro digital na moeda local de sua escolha, enquanto ainda usam o Bitcoin como o "canalizador" da troca.

Metanet ligando

Assim, mesmo que Bob esteja executando um site offline - ou seja, um sistema simples sem um banco de dados de back-end - os registros recebidos na tecla P (Bob) agora podem atuar como uma forma de armazenamento de dados imutáveis.

A mensagem que Alice criptografa para Bob pode ser o pedido completo.

Pode ser concluído usando os tipos de mensagens EDI existentes. Ao contrário do EDI, o método é seguro, seguro e privado.

Melhor, o registro é imutável. Não há lugar para fraudes contábeis. Você pode reverter as transações, mas isso requer um retorno de fundos para a fonte de origem.

Alice e Bob podem gravar todo o processo comercial.

Bob pode conter uma série de endereços hierárquicos que registram todos os estágios do pedido - do faturamento e pagamento ao envio e entrega. Se Bob agora possui uma chave de submestre para cada cliente (consulte a patente acima e a Fig. 9), ele também pode construir uma subchave separada, conhecida por ele, pelo cliente e pela autoridade tributária para fins de auditoria, mas não outros, permitindo que ele mantenha um nível absoluto de privacidade, onde outros clientes e fornecedores nem sabem quantas transações ele está fazendo. Além disso, ele pode criar pagamentos de uma maneira que lhe permita isolar funcionários internos e que eles saibam apenas as informações relacionadas aos seus próprios departamentos.

Enquanto a chave vinculada à CA não for tocada, as contas podem ser enviadas para o endereço antigo. Uma chave de sub-CA pode ser vinculada ao exercício contábil e rolada a cada período de imposto também. Você fecha o certificado, coleta todos os pagamentos feitos como poeira e, ao mesmo tempo, fecha os livros prontos para o novo ano contábil.

Mensagem EDI

EDI é um esquema de codificação existente para o comércio.

Podemos ver os formatos de mensagem ANSI e EDIFACT na imagem abaixo:

ANSI vs EDIFACT

Em nosso sistema, usamos a chave de criptografia para os dados na mensagem (não o pagamento) como a "mensagem de grupo". Não há necessidade de uma mensagem de troca. Esse seria um intermediário e, no Bitcoin, removemos a necessidade dele.

EDI padrão

O novo modelo de comércio é aquele em que todos os registros são imutáveis, não podem ser perdidos e permitem que Alice e Bob negociem em particular.

Intercâmbio de Dados Bitcoin

E, ferramentas para mapear EDI para uma transação de Bitcoin simplesmente pareceriam ferramentas de EDI como são hoje.

Mesmo incorporado a uma transação de Bitcoin, o formato XML EDI criptografado pode ser simplesmente extraído e exibido ou impresso como qualquer outra fatura ou pedido:

Fatura exibida

No mundo EDI existente, os clientes são cobrados usando modelos que operam dentro de faixas de preço com base em volumes previstos de Kilo-Characters (KCs) ou documentos. Também existem cobranças ocultas, como comprimentos mínimos de registro, com muitos provedores especificando um comprimento de registro de 128 a 512 caracteres. O resultado é que, se você enviar 12 documentos de 12 caracteres, você será cobrado por até 5.120 caracteres, mesmo enviando apenas 144 caracteres.

Para comerciantes com um grande volume de pequenas transações, eles podem adicionar uma quantia substancial à sua cobrança mensal.

Tal coisa não é um problema com o Bitcoin.

Embora o tamanho máximo permitido para mensagens NACCS EDI seja de 500.000 bytes, a realidade é que o EDI e outras mensagens relacionadas geralmente estão na ordem de 150 bytes. O envio de um sistema de faturamento e contabilidade imutável, privado e seguro por frações de um centavo por fatura - compare isso com 2 a 3 dólares para algumas soluções EDI e até US $ 0,20 para uma transação simples do Visa, e… é hora de começar a repensar como você faz negócios.

Nesse modelo, nenhum endereço Bitcoin precisa ser usado mais de uma vez e os pagamentos e faturas são vinculados de forma privada - o que pode até ser pseudônimo, pois o ID não precisa estar em um certificado de usuário.