forex.wf forex forum binary options trade - Forex - Duas Propostas Para Dinheiro Digital.
  • Welcome to forex.wf forex forum binary options trade. Please login or sign up.
 

Duas Propostas Para Dinheiro Digital.

Started by admin, Aug 11, 2020, 01:41 pm

Previous topic - Next topic

admin

Duas Propostas Para Dinheiro Digital.
Neste texto discutiremos duas propostas diferentes para o Dinheiro digital : o DigiCash e o Millicent. A principal diferença entre os dois reside no valor das transações paro qual eles são indicados. O DigiCash, assim como a maioria dos outros sistemas , é voltado para transações não muito baratas. Devido ao fato dele usar uma forte cripografia, o custo das tansações faz com as mesmas devam ser para valores de, pelo menos, 5 dolares. Já o Millicent (como seu próprio nome diz) possibilita transações de até decimos de cents.
O FБCIL USO DO ECASH.
As funзхes do usuбrio sгo as mesmas para todas as plataformas embora as janelas possam ser diferentes.
Ecash foi desenhado para ser fбcil de usar. Clientes usam simples interfaces grбficas mais fбceis que muitas de bancos ATM.
COMO ECASH TRABALHA INTERNAMENTE ?
Como bancos comuns, ecash pode ser retirado e depositado para contas. Um pessoa pode transferir seus valores em qualquer quantidade para qualquer pessoa. Mas, quando um cliente paga outro cliente, o banco eletrфnico verifica se nгo nenhum obstбculo para a transaзгo.
Para mostrar como se trabalha ilustraremos com uma retirada e um pagamento. Combinando essas duas transaзхes, podemos entender porque o cliente percebe que o ecash й pago de pessoa a pessoa sem o envolvimento do banco. Finalmente, a retirada й explicada atravйs do conceito de assinatura cega, o qual estб fundamentado na privacidade, e explica porque o banco nгo pode rastrear seus prуprio dinheiro.
RETIRADA SIMPLES DE ECASH :
Dois participantes da retirada o banco e o cliente. As moedas digitais podem ser retiradas da conta do cliente no banco e armazenadas no seu prуprio PC. Quando elas chegam, sгo armazenadas juntas com as outras moedas jб disponнveis no disco rнgido.
Nenhuma moeda fнsica estб envolvida no sistema em curso, mas as mensagens incluem strings de digнtos, e cada string corresponde a uma moeda digital diferente. Cada moeda tem um denominaзгo, ou valor, entгo a carteira de moedas digitais й gerenciada automaticamente pela software local do PC. Ele decide qual denominaзгo deve ser retirada e qual deve ser gasta em pagamentos particulares.
UMA COMPRA COM ECASH :
Agora que o usuбrio jб tem algum ecash em seu disco rнgido, ele pode comprar coisas nas lojas.
Tendo recebido uma requisiзгo de pagamento de uma loja, o usuбrio concorda com o pagamento. O software ecash escolhe as moedas digitais com o valor exato da compra no seu disco rнgido. Entгo ele remove essas moedas e as envia para a loja atravйs da rede. Quando a loja recebe as moedas, o seu software automaticamente as envia para o banco e aguarda pelo aceite antes do envio da mercadoria para o cliente.
Para assegurar que cada moeda й usada apenas uma vez, os registros do banco guardam o nъmero serial de cada moeda em seu banco de dados. Se um nъmero serial jб foi gravado, o banco detecta que alguйm estб tentando gastar a mesma moeda mais de uma vez e informa a loja que a moeda se trata de uma cуpia. Se, o nъmero de sйrie nгo tiver sido usado, o banco grava esse nъmero de sйrie na posiзгo correta e informa a loja que a moeda й vбlida e o depуsito й aceito.
Quando um usuбrio recebe um pagamento, o processo pode ser o mesmo. Mas se alguma pessoa prefere receber o dinheiro imediatamente em seu disco rнgido, isto pode ser realizado.
A ъnica diferenзa entre esse pagamento e o anterior, acontece apуs o banco ter aceito o dinheiro. O software do usuбrio faz a requisiзгo imediata do envio das moedas digitais correspondentes para o computador do cliente, o que o banco faz tгo logo aceite o dinheiro.
COMO A PRIVACIDADE Й PROTEGIDA ?
O banco cria uma caixa de moedas digitais ъnicas, validadas com um selo digital especial, e fornece para o cliente. Isso poderia permitir que banco (pelo menos no princнpio) pudesse reconhecer as moedas particulares quando elas fossem mais tarde aceitas em pagamentos. Isso poderia rastrear os pagamentos feitos por clientes.
Pelo uso de assinaturas cegas, uma caracterнstica ъnica do ecash, o banco pode se prevenir do reconhecimento de moedas de cada usuбrio. Ao invйs do banco criar uma caixa de moedas, o computador do usuбrio cria uma moeda ele prуpria atravйs de um nъmero randфmico. Entгo esconde essa moeda em um envelope e envia para o banco. O banco remove o valor da moeda da conta do usuбrio e faz uma validaзгo digital da moeda que й colocada no envelope antes de retornar para o computador do usuбrio.
Como realзado, o mecanismo da assinatura cega faz a validaзгo da assinatura atravйs do envelope. Quando o usuбrio remove o envelope, ele obtйm a sua prуpria moeda, validada pelo selo do banco. Quando ele gasta a moeda, o banco deve honrar o pagamento porcausa do selo. Mas o banco й incapaz de reconhecer a moeda, porque ela estava escondida no envelope quando este foi validado, o banco nгo pode entгo saber que fez o pagamento.
Quando um usuбrio cria uma caixa de moedas ele escolhe um nъmero randфmico. O selo de validaзгo do banco nas moedas й uma assinatura de chave pъblica digital codificada pelo banco com o nъmero randфmico de moeda servindo como uma mensagem para ser codificada. Checagem das validaзхes de moedas envolve a verificaзгo da assinatura digital usando chave pъblica correspondente do banco. A operaзгo para esconder й um tipo especial de criptografia que so pode ser removida pela parte que a colocou. Ela pode ser revertida usando o processo de assinatura de chave pъblica digital, e entгo pode ser removida sem perda da assinatura.
COMO OS FUNDOS FLUEM ?
Embora ecash trabalhe como dinheiro nas mгos do consumidor, para o banvo suas propriedades sгo muito diferentes. O primeiro passo nesse caso ocorre quando um valor sai da conta do cliente. Em um transaзгo ATM, o dinheiro dado ao cliente constitue uma reduзгo no caixa de dinheiro. Numa retirada de ecash, entretanto, o valor й movido no banco, e torna-se um risco do ecash, que poderб ser revertido quando o ecash for apresentado para depуsito.
O segundo passo й o gasto do valor, quando dinheiro e ecash sгo muito similares. No caso do ecash o comerciante pode escolher receber novas moedas ou fazer um depуsito para sua conta de ecash. Quando o comerciante chega ao passo final e deposita o tradicional dinheiro, este constitui um acrйscimo no caixa de moedas, aonde o depуsito de ecash reduz o risco do ecash e aumenta o do depуsito.
O Millicent é a proposta da Digital para dinheiro eletrônico. Esta proposta difere das demais no sentido de que ela permite transações muito baratas e seguras (mais baratas ainda que as outras, ou seja, da ordem de frações de centavos).
A proposta da Digital está baseada no que ela chama de Scrip. E em corretores(brokers) para servirem de mediadores entre os consumidores e os comerciantes. A idéia é que, ao invés de existir uma conta para cada par consumidor-comerciante, exista uma conta entre cada consumidor e um corretor (ou alguns corretores) e entre cada comerciante e um (ou alguns) corretores.
O Scrip possui as seguintes características : Tem um valor para um vendedor específico - No texto do Scrip existe campos que definem o valor do mesmo e o comerciante. Só pode ser gasto uma vez - O Scrip tem um número de série que previne o uso mais que uma vez. Só pode ser gasto pelo proprio dono - O consumidor assina cada uso do Scrip com uma chave secreta que está associada com o mesmo. Pode ser eficientemente produzidoe validado - o sistema de segurança está baeado em funções rápidas de hash (tipo MD5 ou SHA). Existem três chaves envolvidas na produção, validação, e gasto do Scrip. O consumidor manda uma chave, a 'customer-secret', para provar que o dono do Scrip. O comerciante usa uma chave, a 'master-customer-secret', para derivar a chave do usuário a partir do Scrip. A terceira chave, a 'master-scrip-secret', é usada pelo comerciante para se evitar a falsificação de Scrip.
O Scrip possui os seguintes campos (figura 1) : Vendor - Indentifica o comerciante; Value - Da o valor do Scrip; ID# - é o número de série do Scrip. Algumas partes dele são usadas para derivar o 'master-scrip-secret', usado para certificar o Scrip; Cust_ID# - Identifica o consumidor. É usado para gerar o 'customer-secret'. Uma parte dele é usada para para derivar o 'master-customer-secret', que por sua vez é usado para produzir o 'customer-secret'. Expires - Data de validade do Scrip. Usada para evitar a necessidade de se manter os dados sobre o Scrip por tempo indeterminado na base de dados do vendedor; Props - Dados extras do consumidor, tipo data de nascimento, endereco, etc. Certificate - é a assinatura do Scrip, emitida pelo vendedor. Esta assinatura é gerada a partir da aplicação de uma função de hash em cima da concatenação dos campos anteriores do Scrip com o 'master-scrip-secret'.

admin

Figura 1 - Estrutura de um Scrip.
O Scrip é a base para três protocolos propostos pelo Millicent : Scrip limpo.
O mais simple protocolo da Millicent. O consumidor manda para o vendedor um Scrip limpo (ou seja, sem criptografia ou proteção de espécie alguma) junto com sua requisição. O vendedor retorna o resultado desejado para o cliente junto com um Scrip (tambem limpo) com o novo valor.
Este protocolo não &uacutetil na prática, pois não oferece nenhum tipo de segurança. Qualquer um pode interceptar o Scrip e usa-lo. Neste caso, o consumidor só saberia quando fosse utilizar o seu Scrip e o comerciante lhe respondesse que o mesmo não é válido, pois já tinha sido gasto.
Scrip secreto e seguro.
Para adicionar segurança e privacidade ao protocolo, foi estabelecida uma chave compartilhada entre as duas partes envolvidas (consimidor, comerciante) e o uso da mesma para produzir um canal seguro e privado de comunicação usando um seguro e eficiente algoritmo de critografia (tipo DES , RC4 ou IDEA).
No Millicent, o Scrip pode ser usado para estabelecer esta . Quando um consumidor compra um dado Scrip de um comerciante, a chave é gerada baseada na identificação do consumidor e retornada para o mesmo de forma segura, junto com o Scrip.
O comerciante não grava de forma direta a chave associada ao Scrip. Mas o campo identificador do consumidor (Cust_ID#) do Scrip permite gerar-se rapidamente a chave. O identificador do consumidor, portanto, deve ser único mas nã precisa (e nã deve) ter qualquer conexão com a identidade do consumidor.
Quando o comerciante recebe uma requisição ele deriva o 'customer-secret' da identificação do consumidor, depois deriva a chave do 'customer-secret' e, finalmente, descriptografa a mensagem usado a chave. (figura 2)a.
Neste protocolo, a requisição e a resposta são feita de modo totalmente privado; a memos que alguem conheça o 'customer-secret' ninguem poderá descriptografar a mensagem. Além disso, ninguem tambem poderá roubar o Scrip, pois nã poderá gasta-lo, a menos que conheca o 'customer-secret'.
Figura 2 - Como é gerado o 'customer-secret'
Scrip sem Criptografia.
O protocolo anterior serve bem quando é altamente desejada a privacidade, dadas as suas características. Mas, quando a privacidade não é tão importante, o protolocose mostra mais caro do que o necessário. Chegando a custar o suficiente para inviabilizar as propostas iniciais do Millicent.
Para utilizar o Milicent de forma segura, mas sem privacidade, foi desenvolvido o terceiro protocolo, qeu nada mais é do que o segundo protocolo sem a parte da criptografia.
Como no protocolo anterior, o consumidor recebe (de forma segura) o Scrip e o 'customer-secret'. Para fazer uma compra, ele manda a requisição, o Scrip, e uma assinatura da requisição para o comerciante. A assinatura é produzida do mesmo modo que o certificado do Scrip. O Scrip e a requisição são concatenados com o 'customer-secret', sendo o resutado desta concatenação passado através de uma função de hash, obtendo-se assim a assinatura.
Quando o vendedor recebe a requisição, ele obtem o 'customer-secret' do Scrip e recalcula a assinatura. Se o resultado for igual à assinatura mandada pelo consumidor então a requisição é aceita (figura 3)
Figura 3 - Validando uma requisição.
O comerciante entao atende a requisição e retorna para o consumidor um novo Scrip. Este novo Scrip possui o mesmo identicador do consumidor, de tal modo que o 'customer-secret' original ainda possa ser gerado pelo comerciante quando este novo Scrip for gasto. Não é necessário nenhum tipo de criptografia, pois a assinatura do Scrip não pode ser feita sem se conhecer o customer-secret. Com isso o prtocolo pode ser seguro e eficiente, pois necessita de apenas uns poucos hashs. 3.4. Testes e aplicações potenciais.
A Digital implementou uma versão inicial do sistema e testou atravé da rede (usando TCP-IP). Como resultado, eles chegaram à concluão de o sitema possibilita transações abaixo de centavos. Os testes mostraram que o comerciante, por exemplo, pode validar cerca de 1000 requisições por segundo (em uma Dgitial AlphaStation 400 4/233), sendo, obviamete, que a mairoia do tempo é gasta na conexão.
O baixíssimo custo das transações possibilita uma vairada gama de possibilidades para o uso do Millicent. As mais imediatas são o uso para a venda de qualquer tipo de publicações : artigos de resvistas, livros para se ler comprando p&aacutegina a página, ect. O principal filão do Millicent está ai : coisas que sã muito baratas e que não poderia ser adquiridas usando os outros tipos de Digtal Cash, a menos que fossem compradas em um volume maior.
Dentre os teste realizados pela Digital com o Millicent esá o uso do mesmo para autenticação de serviços de rede. A ideia é que o usuá recebe um Scrip do servidor principal (que faz o papel do corretor) e o usa para adquirir Scrip dos diversos serviç (os 'comerciantes').
Outro teste da Digital se refere ao uso da WWW para as transações Millicent. A idéia é a seguinte : eles desenvolvem uma pseudo-proxy local que intercepta todas as requisições do browser do cliente e modifica o cabeçalho HTTP, acrescentando o Scrip quando necess&aacuter;io. O servidor WWW (do comerciante) checa a requisição, e se o Scrip for suficiente e válido, realiza a transação, retornando o novo Scrip no cabeçalho da página requisitada. Quando a página chega ao cliente, a pseudo-proxy intercepta novamente a resposta, retira o Scrip, e manda para o usuário a página que ele havia pedido. Isto funcionaria transparente para o usuário, mas, mesmo assim, possui o incoveniente da necessidade da pseudo-proxy. A idéia da Digital é que com a popularização do Milicent o proprio browser poderia incorporar esta função.
Das duas propostas vistas o DigiCash é a que mais se aproxima do dinheiro normal (e do que se espera do dinheiro digital ) : é seguro,privado e nao rastreável. Ele não é prenamente satisfatório em um aspecto : o custo. Apesar de já ser um avanço em relação aos sistemas de cartõs de credito (custo menor),o DigiCash ainda possui um custo (adivindo principalmente da alta criptogra fia empregada) que inviabiliza o seu uso para transações muito pequenas. O Millicent, por sua vez, resolve este problema sacrificando as propriedades de privacidade e nao rastreamento.
Tudo leva a crer que são dois tipos de sistemas complementares : para compras muito pequenas, a privacidade e o nao rastreamento dos gastos pode ser algo desnecessário, o que não acontece com as compras maiores. Sendo assim, pode ser que, no futuro, usaremos sistemas dos dois tipos (que poderiam ser implementados por uma única companhia) ou mesmo um único sistema que trabalhe de forma diferente de acordo com o valor dos gastos.