Esboço da proposta:
A minha ideia é criar uma rede "P2P" onde cada participante seria ao mesmo tempo o apostador, o gerenciador do sorteiro, e responsável pela entrega do premio, tudo de forma distribuída e protegido pelas leis da criptografia.
Basicamente funcionaria da seguinte forma:
CRIAÇÃO DA LOTERIA:
1. Alguém cria uma loteria e registra em um ou vários sites (que chamei de "databases").
2. Apostadores munidos do software de apostas localizam a loteria publicada em um desses sites.
APOSTA:
3. Os apostadores criam "chaves privadas distribuidas"* (Bitcoin address) e fazem os envios do valor das apostas para essas chaves.
4. Para cada aposta é registrado junto uma chave RSA publica unica, e também uma chave ECDSA publica unica.
5. O software dos apostadores deve guardar a contraparte privada dessas chaves até o final da loteria.
6. As chaves publicas ECDSA publicadas junto com as apostas são utilizadas em outras apostas para formar as "chaves privadas distribuidas"*.
7. As chaves publicas RSA publicadas junto com as apostas são utilizadas para o envio das chaves privadas ECDSA ao ganhador do sorteio.
8. O ganhador do sorteio receberá as chaves privadas ECDSA de cada apostador, criptografadas com a chave publica RSA de sua aposta sorteada.
9. Tendo posse das chaves privadas ECDSA de cada aposta o vencedor poderá então coletar o total premiado.
10. O vencedor é o unico que tem posse das chaves privadas ECDSA que permitirão transferir os valores, pois nenhum apostador unico possui sequer uma chave privada ECDSA inteira, os apostadores tem apenas partes das chaves privadas ECDSA, pois essas foram construidas de forma distribuida. Mesmo o site database não tem as chaves, pois apesar de armazenar o envelope de comunicação, este site não possui a chave RSA privada que abre o envelope.
SORTEIO:
11. Para realizar o sorteio todos os apostadores monitoram o blockchain até obter o hash do "bloco alvo"*.
12. O hash do "bloco alvo" é submetido a um algoritimo que escolhe um vencedor dentre todas as apostas (o algoritimo ainda não foi criado)
13. A aposta do vencedor é conferida, verificando a validade da transação no blockchain, assim como a validade da construção distribuida dos address de pagamento.
14. Cada apostador envia as suas "chaves privadas ECDSA parciais" ao apostador vencedor (criptografando com a chave publica RSA deste).
Caso o apostador falhe em apresentar sua chave parcial, o valor da aposta será destruido pela própria natureza do blockchain.
Não existe incentivo algum em falhar com essa etapa pois não há maneira alguma do valor da aposta retornar ao apostador.
Caso o apostador abandone a loteria antes do sorteio e venha a ser sorteado então o premio se perde em definitivo, mas poderia eventualmente existir um prazo para coleta do premio e em seguida sortear outro vencedor.
15. O vencedor então coleta as "chaves ECDSA parciais" e juntando-as poderá coletar seu premio.
DATABASES:
16. Os sites "databases" são intermediários nas conversas protocolares entre apostadores.
17. Devem operar sem login ou qualquer meio de identificação dos apostadores.
18. Podem exigir uma execução de PoW para evitar DDoS.
19. Devem permitir replicação anonima por leitura ou escrita, mas não substituição ou exclusão.
20. Os registros não são ordenados ou encadeados, apenas anotados, como se cada registro fosse um arquivo.
21. São responsáveis por anotar cada aposta efetuada.
22. E também por anotar os envios de chaves privadas ao vencedor.
23. Todos os apostadores devem ter cópias do database.
24. O vencedor utilizará a copia local para receber as chaves privadas ECDSA, assim evitando uma identificação de origem.
O modelo de sites databases foi pensado para simplificar a arquitetura e poder operacionalizar tudo a partir de celulares android.
Um modelo P2P de databases seria o ideal, mas seria necessário abrir portas tcp/ip nos computadores clientes, o que poderia ser um problema para a maioria dos usuarios.
Vou acabar escrevendo uma arquitetura mista que opere das duas formas simultaneamente.
CHAVES DISTRIBUIDAS:
Quase toda a segurança do protocolo se baseia na utilização de chaves privadas distribuidas, que são address cuja chave privada é formada por diversos participantes sem necessidade de confiança mutua.
O principio é relativamente simples e foi apresentada pela primeira vez pelo usuário ThePiachu no post
https://bitcointalksearch.org/topic/vanity-pool-vanity-address-generator-pool-84569 e que estou adaptando para a implementação dessa loteria distribuida, dentre outros projetos.
O fundamento é que uma chave publica ECDSA é formada pela formula:
K = k * G
K = chave publica
k = chave privada
G = constante do ponto na curva eliptica.
Portanto um par de chaves também poderia (suponho) ser construido de forma distribuida pelos participantes A, B e C com a formula:
(A + B + C) = (a + b + c) * G
Assim os address de pagamento das apostas seriam formados por multiplos participantes que divulgariam apenas a "chave publica parcial", mas só revelariam a "chave privada parcial" ao vencedor.
Outro detalhe, os participantes da construção das address de pagamentos não saberiam de quais address eles participariam, pois a escolha será regida por um algoritimo que se alimente de dados não fabricáveis, como a hash da transação de pagamento (algoritimo ainda não desenvolvido).
A construção desses address também ocorrerá de maneira não interativa, pois as chaves publicas parciais são geradas em excesso no momento de cada aposta, e ficam disponiveis, mesmo que nunca venham a ser utilizadas.
Os pagamentos dos participantes precisam ser conferidos, e a validade da construção dos address destes também precisa ser conferida.
Não tenho certeza da necessidade de fazer essa conferencia prosseguir recursivamente de forma infinita, isso precisa ser validado.
A escolha dos participantes da construção dos address não poderá ser arbitrária, e deverá realmente ser regida por um algoritimo, pois a escolha arbitrária permitiria que um apostador fornecesse todos os participantes e com isso tivesse o potencial de recuperar o valor da aposta caso não fosse o vencedor, o que é uma fraude inaceitável.
Outro detalhe a se observar é que nem toda chave privada ECDSA produz um address Bitcoin valido, portanto a soma A+B+C poderia gerar uma chave inutilizável, então para contornar isso deverá ser aplicado um algoritimo de força bruta até encontrar uma chave valida, semelhante ao que é feito no VanityGen.
* Ainda é tudo apenas uma ideia, não tenho certeza absoluta se os address poderão realmente ser construidos desta maneira. A idéia precisa ser testada ainda.PROTOCOLO:
Modelo de Loteria (ficaria armazenado no site)
{
"name": "Loteria do Instituto de pesquisas contra o cancer",
"description": "hacktivism rulez",
"owner": "anonymous",
"site": "http://bitbit.org/loto123",
"coin": "Bitcoin",
"block_target": "311011",
"block_limit": "310991",
"estimated_arrival": "2014-07-19T19:07:14Z",
"database": [
{
"url": "http://site1.org/bitbit",
"type": "post basic 1.0"
},
{
"url": "http://freehost2.org/~user/bitbit",
"type": "post basic 1.0"
},
{
"url": "http://onionhiddensite1234567890.onion/bitbit",
"type": "post basic 1.0"
}
],
"quotas": {
"principal": {
"value": 0.0015,
"recipient_type": "random",
"method": "p1.0",
"method_params": [],
"bootstrap": ["....", "....", "...."]
},
"donation1": {
"value": 0.001,
"recipient_type" : "fixed",
"address": "1doejFmV84SvgSbnTkJyPrRD44hUCjQrX",
"site": "http://sitedainstituicao.org"
}
}
}
O campo "type" nos databases permitirá que sejam criados multiplos tipos de armazenamento, como P2P, mysql, memcache, etc.
A principio apenas um PHP aceitando POST será suficiente.
O "recipient_type fixed" permite que instituições ou projetos possam ser patrocinados pela loteria, de forma transparente e livre da asquerosa corrupção política.
Claro que esse address precisa ser abertamente reconhecido pela instituição receptora ou pelo menos ter alguma transparencia no processo que conduzirá os valores até a mesma.
O algoritimo não terá como ajudar muito quanto a isso, dependerá dos apostadores validarem isso.
O campo "quotas" teoricamente permitiria multiplas quotas de premiação, assim o total do premio poderia ser distribuido para N ganhadores distintos.
Essa possibilidade não foi estressada o suficiente para certificar seu funcionamento, precisará ser melhor analisada.
O campo "method" permite multiplos metodos de sorteio para permitir a criação de premios secundários, assim cada premio deverá ter um metodo diferente de sorteio, ou parametros diferentes para um mesmo metodo.
O campo "block_target" define o bloco cujo hash será utilizado para o sorteio, e o campo "block_limit" define o bloco maximo que os pagamentos devem ter confirmação para participarem do sorteio.
Pagamentos confirmados após esse bloco "block_limit" são silenciosamente rejeitados e o valor da aposta se perde pra sempre.
Embora seja possível que os participantes colaborem para o retorno desse valor de apostas tardias, o esforço não é justificável.
O campo "bootstrap" indica tres apostas iniciais (unique_id) que não participam do sorteio mas servem para formar as primeiras chaves de construção distribuida.
Essas tres apostas iniciais não tem como possuirem "chaves de construção distribuida" pois para essa construção são necessárias tres apostas previamente registradas.
APOSTA
Para cada aposta deverá ser enviado ao database um registro similar a esse:
{
"rsa_public_key": "........",
"quotas": [
"principal": {
"payment_transaction": ".......",
"payment_address": "........",
"address_construction": {
"method": "basic 1.0",
"members": ["... unique_id member A", "... unique_id member B", "... unique_id member C"]
},
"ecdsa_public_key": "........",
"unique_id": "......"
},
"donation1": {
"payment_transaction": ".......",
},
]
}
O campo "method" deve permitir a coexistência de multiplos algoritimos de construção de chaves distribuidas.
O valor de "method" "bootstrap" é reservado para as tres primeiras apostas de cada loteria e que não participam do sorteio.
O metodo basico deverá ser A+B+C+ecdsa_public_key, sendo que as ecdsa_public_key de ABC deverão ser obtidas dos registros equivalentes e com mesma "quota".
O unique_id é calculado fazendo sha256sum da rsa_public_key+ecdsa_public_key, o que deve produzir entropia suficiente para não ocorrerem colisões.
O uso da hash da transação como referencia do pagamento ainda é um ponto de discussão devido ao "bug transaction malleability" ainda afetar quase todas as altcoins.
PAGAMENTO AO VENCEDOR
Todos os apostadores devem registrar nos databases as chaves privadas parciais, assim o vencedor poderá coletar seu premio.
{
"rsa_public_key": "........",
"ecdsa_public_key": "........",
"quota": "principal",
"ecdsa_private_key_rsa_encrypted": "........",
"winner_rsa_public_key": "........"
}
Só é possível fazer esse registro quando os apostadores souberem quem foi o ganhador, pois assim poderão criptografar as chaves privadas ECDSA usando a chave RSA do ganhador.
A definição do ganhador se faz localmente com a aplicação de um algoritimo.
REDUNDANCIA DA CHAVE PRIVADA ECDSA PARCIAL (storage)
Para evitar que valores de apostas sejam perdidas e moedas sejam destruidas no caso de um apostador abandonar a loteria, eu pensei em fazer uma copia da chave privada ECDSA parcial, utilizando para isso um outro participante escolhido randomicamente.
Essa escolha não exige determinismo em algoritimos especiais, já que não compromete o sorteio e nem mesmo a segurança do valor apostado, apenas oferece uma redundancia em caso de abandono.
Cada apostador deveria escolher uma outra aposta e enviar um registro de redundancia.
{
"rsa_public_key": "........",
"ecdsa_public_key": "........",
"quota": "principal",
"ecdsa_private_key_rsa_encrypted": "........",
"store_rsa_public_key": "........"
}
O apostador que recebe esse registro (storage) deverá também informá-lo ao vencedor, em um registro normal de pagamento, como se fosse o pagador original.
*esta ideia não foi estressada suficientemente ainda, precisa ser submetida a analise.
CARTEIRA
Todas as operações de pagamentos e recebimentos podem ser automatizadas com a API do blockchain.info, portanto o usuario precisará apenas ter uma carteira nesse site que facilitará bastante para fazer apostas de um clique usando seu celular android.
Acredito que esse seja o melhor caminho para a implementação do software de loteria, mas existe também a possibilidade de interfacear um cliente RPC ou implementar um cliente leve.
COMENTARIO ADICIONAL
Este esboço de algoritimo foi construido no melhor animo de boa vontade, sem intenção de vantagem, portanto tenham paciência caso o esforço seja infrutífero ou não apresente o resultado desejado.
E espero que alguem com tempo e disposição escreva o software necessário para tornar isso realidade.
Eu vou acabar escrevendo esse software, mas agora não tenho como disponibilizar tempo pra isso pois o equilibrio entre receitas e despesas anda complicado.
Acredito que olhar para esse projeto como apenas uma loteria seria uma visão curta das possibilidades implicitas, pois este poderá servir de impulsionador para muitos projetos que carecem de investimentos e cuja participação como beneficiários de uma loteria poderia ser de muita ajuda.
Em um breve futuro poderiam haver milhares de loterias beneficiando uma infinidade de obras de interesse coletivo.
E sem precisar dar nenhum centavo a nenhum político sangue suga.
Vamos sonhar, pois por sonhar ainda não se paga imposto.
