Algorista,
Tentando entender aqui a sequencia...
3. Os apostadores criam "chaves privadas distribuidas"* (Bitcoin address) e fazem os envios do valor das apostas para essas chaves.
Você está se referindo ao conceito de VanityGen distribuido ou Multi-sig?
O procedimento do VanityGen distribuido permite alcançar um address resultante sem saber a private key completa, mas o único que consegue fazer isso é quem tem o seed original.
Exemplo:
Se (A + B + C) = (a + b + c) * G
E eu gerei
a, você gerou
b e o Zé gerou
c nós 3 só vamos saber pra qual endereço enviar a aposta
depois que eu receber B e C e mandar A pra você e para o Zé.
O problema disso é que quando o endereço final depende de todos avisarem primeiro qual a chave pública, para da combinação das chaves gerar o endereço de aposta, um mal-intencionado pode ficar sempre mandando uma chave pública e nunca fazer a aposta ou divulgar a chave privada, travando as coins que todo mundo mandar pra lá.
O mais próximo que vi de resolver esse problema está aqui:
http://eprint.iacr.org/2013/784E exige que todos os participantes façam um "deposito de segurança" de N(N-1) bitcoins da aposta, onde N é o número total de jogadores esperados, então para 10 jogadores seria um deposito igual a 90x o valor da aposta... esse valor de deposito volta pro jogador no final do jogo, mas eu acho impraticável com o crescimento exponencial. Jogo com 100 jogadores e quer apostar 1BTC? Deposito custa 9.900BTCs...
Você entendeu bem a ideia, que é emprestar o conceito da Vanitypool e expandí-lo para a geração distribuída dos address de pagamentos, assim evitando que qualquer dos participantes possuam uma private key capaz de sacar o valor das apostas, exceto o vencedor.
https://bitcointalk.org/index.php?topic=84569.0https://vanitypool.appspot.com/Toda a arquitetura da loteria depende que a construção da address de pagamento da aposta possa ser realizada somando as Public Keys de três apostas anteriores, e fazendo força bruta de uma quarta Key até que o somatório produza um address valido.
Esse procedimento de força bruta na quarta parte teoricamente é bastante rápido custando sempre menos de 1 segundo, e não depende de conhecer as outras três Private Keys, só é preciso conhecimento das Public Keys.
O gerador da aposta não precisa conhecer as private keys para gerar um address, e cada aposta tem um address exclusivo.
Public Key Private Key
(A + B + C + D) = (? + ? + ? + d) * G
A Private Key (quarta parte) da aposta só é revelada ao vencedor, no final, portanto o apostador não consegue reverter o valor que ele pagou pela aposta, já que ele tem apenas um address e uma quarta parte da private key.
Já o vencedor receberá os pedaços de private key de todas as apostas e juntando tudo conseguirá resgatar os valores das apostas.
Eventualmente alguma aposta se perderá, pois alguns participantes terão abandonado o concurso, ou alterado o software para intencionalmente se recusar a entregar a PrivateKey.
A arquitetura inclui uma redundância dessa entrega, mas ainda é um ponto fraco que precisará ser melhorado no futuro.
Será possível construir relatórios bem precisos quanto a esses valores destruídos no processo, mas sua recuperação* não será possível.
*Existe uma possibilidade teórica de utilização de números primos como seed do gerador randômico do procedimento de força bruta, com isso permitindo que numa década futura essa keys pudessem ser recuperadas com um investimento justificável, considerando uma valorização extrema do BitcoinAs private keys jamais são informadas aos databases, que mesmo sendo os criadores da loteria ainda não terão meios para "roubar" o valor das apostas.
Uma vez apostado, o valor do pagamento vai para um limbo e só volta a existir no momento do sorteio, e apenas para o sorteado.
Caso o sorteado não recolha o premio em um prazo estipulado então o premio poderá ser entregue a um segundo colocado, assim evitando a destruição de grande quantidade de moedas.
Quanto ao seu questionamento sobre um potencial ataque:Os participantes não tem como sugerir uma chave publica sem juntamente fazer uma aposta, pois isso é um dos campos da aposta em si mesma, dessa forma não é possível executar o potencial ataque que você identificou na sua analise. Mas para a defesa funcionar corretamente os databases precisam validar as apostas e rejeitar registros inválidos ou pagamentos não confirmados.
Quanto ao pré conhecimento das Public Keys:Eu reservei um tipo de registro especial que chamei de "bootstrap" que serve para apresentar as primeiras chaves publicas que serão usadas nas primeiras apostas, pois a primeira aposta já necessitaria referenciar outras três anteriores.
Esse registro "bootstrap" é criado pelo database publicador da loteria, que de certa forma ganha poder de resgate sobre a primeira aposta real, mas isso é uma coisa que não consegui evitar, por enquanto.
A escolha das três keys dentro do total de apostas deverá ser randômica e regida por um algorítimo.
O modelo de escolha das três keys ainda é um algorítimo pendente, e a solução encontrada poderá alterar esse procedimento quanto aos registros bootstrap.
Obrigado pelo link, vou estudá-lo.
