SatoshiDice like pour Duniter

R&D
1

Je ne sais pas si je poste ça au bon endroit. ^^

Voilà, j’ai enfin un peu de temps pour le projet de satoshidice like pour duniter dont j’avais parlé à certain d’entre vous.

Pour ceux qui ne savent pas ce qu’est satoshidice, c’est un paris sur la blockchain, en gros on faiit ça :
hash(TX + secretKey)
On extrait les 4 premiers digit, et on obtient un LuckNumber, qu’on compare au paris fait.
gagner ou perdu si plus petit.

L’idée est que ce soit vérifiable par tous car les infos (hash de la transaction) sont sur la blockchain. La secretKey est diffusé chaque jour suivant son utilisation sur le site par exemple, on pourrai aussi l’émettre sur la blockchain (en réflexion, mais je favorise une diffusion sur le site directement.)

Alors je pars sur une solution sans base de donnée, ma base de donnée sera la blockchain directement. ^^

Vous me direz aucun souci, avec l’aide des commentaires liés au TX il suffit de mettre dans chaque TX sortante le hash de la TX du paris en commentaire. (histoire de savoir si il a déjà été joué ou non)
Et bien je pars aussi sur la non-utilisation du champ commentaire qui est une aberration à mon sens. ^^

Alors avec cette problématique voici ce que j’ai :

Donc mon idée c’est d’utiliser le fait que l’UTXO soit ou non dépensé comme un statut pour le paris en cours, admettons que
Alice paris, elle envoie 10 June sur mon adresse.
Je vois cette entrée en piscine, je peux déjà simuler le résultat du paris (j’ai toute les infos) Affichées sur le site quasi instantanément. (statut en attente)
La TX est ajouté à un bloc, alors je peux procéder au paiement.
Si c’est perdu, je rapatrie les june sur mon adresse principale de sort à dépenser l’UTXO dans son intégralité.
Si c’est gagné, je fais alors 2 transactions, la premier comme le premier cas pour rapatrier les coins et une autre pour envoyer le gain au joueur.

Affichage des paris passé et en cours sur le site.
J’analyse la blockchain, si UTXO dépensé alors paris passé, je peux savoir si c’est gagné ou perdu via les UTXO (je pense à envoyer un lot de consolation, qui serai comme un marqueur pour savoir si c’est un paris perdu. ^^ )
Si en cours, via les informations disponible en piscine.

Coté vérification, je compte proposer aux joueurs un utilitaire, l’ID du paris sera le hash de la transaction associé. et le timeblock définira si c’est un paris au jour J ou au jour j+1.

La seule base de donnée que je maintiendrai sera donc la liste des secretKey associé au jour correspondant.

Je poste ça pour le soumettre à challenge, est ce que c’est suffisant ? Est ce que ça marche selon vous ? Une faille à laquelle je n’ai pas pensé ?

Merci pour votre attention. :slight_smile:

2

Salut Looarn :slight_smile:

Oui, c’est pas une mauvaise idée :slight_smile:

Sur le fond, ça devrait globalement fonctionner. Je dis globalement parce que les piscines sont pas toujours parfaitement synchronisées, donc potentiellement une transaction vers ta clé n’apparaitrait pas sur le site, et pourrait inquiéter des joueurs.

T’as regardé du côté des verrous XHX ? Ca a l’air de pas mal correspondre à ton besoin.

J’ai pas très bien compris le fonctionnement général (secret key, sa diffusion, etc), si tu peux le formaliser un peu plus ça serait cool :slight_smile:

1 Like
3

Merci @Inso pour le retour.

Oui j’ai mal expliqué ^^

En gros on paris sur le fait que le luckNumber sera plus petit que disons 100.
Pour ce faire j’ai fait un sha256(hashTX (c’est le hash de la transaction qui initie le paris) + secretKey (que je sale avec une clé secrète produite par le jeu (une unique clé par jour))).
Du hash résultant disons af4e01ba606feea919b849e4bf2dd67886ccb1fdf0a04786a9c240b4b7bbb91b Je prend les 4 premiers digits qui me donne un chiffre 44878 qui est le luckNumber.

Pas de bol, ton luckNumber est grand tu avais parié que ça serai plus petit que 100 tu as donc perdu.

A ce moment TX en piscine, j’affiche déjà le résultat de ton jeu.

Quand la TX arrive dans un bloc, je t’envoie le lot de consolation, et ça valide pour de bon ton jeu.

Le jour suivant, je délivre la secretKey, qui te permet de vérifier que les dés n’étaient pas pipés. :slight_smile:

Et je t’invite a rejouer bien sûr. :smiley:

4

Donc finalement, toute la question est : comment révéler la clé secrète de manière sécurisée ?

Tu peux inscrire une transaction qui verrouille la monnaie avec XHX(clé secrète), et déverouiller la transaction pour révéler la clé secrète par exemple :slight_smile:

1 Like
5

Intéressant, il y a de la doc sur XHX ?

6

Yes :

1 Like
7

Si je comprends bien le souci du lock c’est que la donnée est publié non ?

Il faut que ça reste secret.

Cela dit ça m’a donner une idée pour me dispenser de tenir à jour la liste des secretKey.
Si je créé un TX et que j’utilise son hash, et la TX en question je la publie le lendemain.

ça serai sur une adresse spécial depuis une adresse spécial avec un montant fixe. chaque jour par exemple après le bloc du DU. :slight_smile:

8

Tu verrouilles les outputs avec le hash, et tu déverouilles la transaction avec la valeur qui a été hashée.

Donc une première transaction publie le hash de ton secret key.
Une deuxieme transaction publie la secret key pour déverouiller les fonds.

9

Intéréssant, je viens de finir la lecture de la doc. ^^

Oui ça marcherai bien, ça permet de publier le hash en amont (preuve de bonne foi) puis ensuite de publier le password le lendemain en débloquant la TX.

Niveau usecase pour l’utilisateur, par contre ça complique l’histoire, il y a désormais 2 TX liées dont une contient l’info dans un champ peu connu.

Utiliser directement le hash d’une TX que j’aurai émise à rebours me semble plus simple.
Et si j’ai un patern bien précis, voilà que j’ai tout automatisé et sans utiliser de base de donnée. :slight_smile:

Désormais, je suis dépendant du fait que duniter marche globalement bien, un fork pourrai foutre le boxon, ou un DU non émis pourrai chambouler mon calendrier d’émission des secretKey. :thinking:

Merci @inso pour le brainstorming, ^^

2 Likes
10

Il suffit que ton application affiche tout ça correctement. L’utilisateur n’a pas besoin de connaitre le fonctionnement sous-jacent :slight_smile: Tu peux même envoyer un lien vers Cesium avec le bloc contenant la transaction pour prouver ta bonne foi :slight_smile:

Je ne comprends pas ça ?

11

à rebours dans le sens où je build ma TX sans l’émettre (il faut que le hashreste secret ^^), du coup je connais le hash de la TX. Puis je la délivre le lendemain.

12

Et comment font les utilisateurs pour savoir que ta TX a été générée avant leur pari et pas après ? :thinking:

13

Euh en fait le jeu utilise une seule secretKey pour tous les paris de la journée.

Ainsi tous les joueurs pourront vérifier le lendemain que les dés n’étaient pas pipés.

Pour la première partie du hash qui genere le luckNumber, c’est simplement le hash de la TX du joueur (TX de la partie si t’es mieux).

faisons un pile ou face :
J’ai deux adresses : pile123465 et face123456 si le joueur pari sur face, alors j’attends de recevoir les June sur l’adresse face123456, je fais le hash sha256(hashTX+secretKey)
Je prends les 4 premiers digits et je regarde si c’est plus petit que 00ff pour face et plus grand pour pile.
Ainsi je connais le résultat du paris dès que j’ai la transaction en piscine ^^

EDIT pas 00ff :stuck_out_tongue: 7FFF ^^

14

Oui mais tu ne peux pas garantir aux joueurs que tu n’as pas pipé la secret key pour faire gagner celui qui t’arrange dans ce modèle ?

15

J’affiche les luckNumber. ^^
Qui seront donc retrouvable.

16

Petit up,

Coté blockchain, j’ai finalement 2 process, coté client, le site explore la blockchain pour savoir quels sont les x derniers paris réalisé (i.e déjà joué). Et voir si il y a des paris en piscine à afficher. ça se complique sur l’affichage du lucknumber, je suis obliger de faire ça coté serveur, j’hésite à passer seulement le hash de la TX au serveur qui me retourne le lucknumber. Ou bien laisser le serveur fournir la totalité des infos sur les transactions en piscine.

coté serveur, c’est toute la partie paiement.

Ils sont cependant une logique commune qui est de savoir quel secretKey il faut utiliser, celle d’hier ou celle d’aujourd’hui ou celle d’il y a 2 semaines.

Là dessus, j’aimerai tout avoir en blockchain, j’ai pensé à ceci :
J’utilise un secretKey entre chaque émission du DU, l’émission du DU sera un marqueur.
toutes les TX ajouté dans un block compris entre DU et DU+1 utiliseront le secretKey+1. (une fois le bloc du DU passé, je peux émettre la TX qui gardait le secretKey secret. et recommencer.

17

Désolé pour le coté brouillon, à me relire, c’est une réflexion à haute voix. :smiley:

18

Alors finalement, j’ai du découper :

Coté client :
l’affichage des TX passées (déjà joué) se fait directement sur la blockchain.
Le contrôle (au cas par cas) se fait aussi directement sur la blockchain.
Par contre l’affichage des TX en attente, sera géré coté serveur. Car je contrôle dans la foulé si c’est un pari gagné ou perdu, laisser ouverte une API REST qui permet de savoir si avec tel ou tel paramètre, c’est gagné ou perdu, permettrai à des personnes mal intentionnées de vider la caisse du casino. :smiley: (je simule mon pari, si c’est gagné, je publie la TX en blockchain :stuck_out_tongue: )

Donc coté serveur, on ajoute le listing des paris en attente, que le client viendra chercher.

Pas le choix ici, j’aurai aimé que le client soit 100% indépendant, mais bon, je vais pas risquer de me faire dévaliser pour si peu. :smiley:

Sinon pour temporaliser facilement quelle secretkey est valable pour quel bloc intégrant un TX de pari. j’abandonne le système basé sur le DU (relativement complexe en post gestion pour les clients (trouver les blocs de DU n’est pas chose facile), je vais utiliser des multiples plutôt, je pars sur une secretKey pour un intervalle de 500 blocs (soit moins de 48h) Il sera alors très simple pour le client d’aller chercher les bons secretKey en fonction du numéro du blocs (on s’épargne l’étape de recherche du bloc de DU ^^).

ça avance bien le coté client est quasi fini.
Le coté serveur, la partie rouler les dés est faite, j’ai pas attaqué la partie exploration de la blockchain (qui est déjà là coté client. ^^)

J’annonce pas de date de sortie, mais j’ai bon espoir qu’il soit prêt pour les beta testeurs d’ici fin de semaine. ^^

1 Like
19

Oublie pas de tester sur le réseau de test d’abord :slight_smile:

1 Like
20

J’ai pas de compte de test, j’avoue que j’étais parti pour tester directement sur le mainnet :stuck_out_tongue:

Possible de m’envoyer de GT ici : 2LyLcCf3vQDDggPkECGeVrFMMvQdJACLNZet9HUxeY73

On fera le beta testing sur G1-Test ^^