Et ça coupe l’herbe sous le pied de ceux qui voudraient faire disparaître la “monnaie papier” 
Il y aussi cette expérience avec le G1BILLET
Pour maintenir une meilleur appréhension de la “crypto”. Le système de clefs (et clefs dérivées) est basé sur la génération NaCl (salt pepper)
Par exemple la clef “MySwarm_${IPFSNODEID}” (service ~/_12345.sh) qui relaie les données du swarm connu par le node est liée au CPU de la machine.
SECRET1=$(cat /proc/cpuinfo | grep -Ev MHz | sha512sum | cut -d ' ' -f 1)
SECRET2=${IPFSNODEID}
Pour une clef PLAYER (salt / pepper / email)
Ses clef dérivée “G1Voeu” (qui cible les données actionnées lors de la synchronisation entre “clefs étoilés” de 20h12) se fabrique comme cela
SECRET1=$pepper
SECRET2=$(echo "$TITRE" | sed -r 's/\<./\U&/g' | sed 's/ //g') #CapitalGluedTddlerTittle
Pour les “G1BILLETS suiveurs” je pense introduire une clef associée à un Message inscrit sur IPFS qui se construise comme ça par exemple
SECRET1=TitreMessage $email_dest1 ($email_dest2 ...)
SECRET2=$email
Le programme “ASTROBOT” se déclencherait à la présence de ce type de clef pour envoyer un G1PASS “sans contact” (sans demande de PIN) vers $email_dest qui l’imprime et en scan le QRCODE voit le message (“Envoyez moi à celui ou celle qui cultive des oignons”) et peut indiquer un email_dest2 à qui renvoyer le message. Dans ce cas, le G1BILLET1 est vidé dans la nouvelle clef dérivée (et le message copié dans la clef IPNS)… Ainsi de suite…
Pour “contrôler la chaîne”. Si il se passe plus de 7 jours par exemple (compte non vidé = message non relayé) alors le G1BILLET2 est annulé (message mis à jour, portefeuille vidé vers le précédent).
Le but n’est pas de garantir la sécurité, ni une confidentialité des individus relais, mais s’occupe de garantir la traçabilité d’un “portefeuille qui se propage quand on l’ouvre”
Voila le concept derrière Les “Empanadas de Manu” (mode courrier de Milgram)
Les cagnottes sont ouvertes tous le mois de mai…
Box Ğ1Station.