Le réseau ğ1-test étant souvent sous-pourvu, serait-il possible d’imaginer un Remuniter qui donne des vrais ğ1 pour les personnes qui minent des blocs sur ğ1-test. Ce pourrait être une très faible somme (0.01 ğ1 par bloc, voire moins), mais cela pourrait motiver des personnes à faire tourner des nœuds. Il faudrait fournir à ce Remuniter l’adresse du compte à rémunérer en fonction de la clé publique ğ1-test, et je ne sais pas si c’est compliqué.
Ce serait aussi un moyen pour des personnes non membres de se faire quelques centi-ğ1. En tout cas, si cela se fait, je serais prêt à faire un don en ğ1 pour ça.
En fait, ce serait possible de rémunérer en Ğ1 une clef identique au compte membre sur ĞTest : la personne pourra accéder à ses Ğ1 sur le réseau principal, pour peu qu’elle y ait versé 1Ğ1 auparavant, (pour que les centimes ne soient pas effacés).
Après, sur la rémunération, vu le faible nombre de membres, 0.1 Ğ1 pour 10 blocs me paraîtrait correct.
Et il y a la critique que cgeek possède plusieurs comptes membres et peut calculer plus. Mais bon, on parle de très peu de Ğ1, là.
Je réveille le sujet pour @HugoTrentesaux qui ne le retrouvait pas, et pour moi aussi car l’idée me plaît.
La proposition de @matograine de créer des compte portefeuilles sur la Ğ1 avec les mêmes identifiants que les comptes membres de la Ğ1-test est assez simple, mais nécessite de recoder remuniter pour gérer deux noeuds, celui à surveiller et celui recevant les rémunérations.
On se garde ça dans un coin de la tête pour un hackathon remuniter ou autre atelier permettant à des développeurs de se faire la main sur les modules Duniter.
Après, Rémuniter est un système indépendant de la blockchain et centralisé. Rien n’empèche alors aux membres de G1 de signer leur clé g1test et de la donner à Rémuniter (messagerie Cesium ?). Ainsi Rémuniter peut observer g1test et rémunéré la clé associée G1. En plus, ça pourrait permettre de limiter un compte g1test calculant (rémunéré) par membre g1.
Centralisé oui, mais indépendant de la blockchain, pas vraiment. Remuniter est un module qui se greffe sur un noeud et observe et rémunère uniquement la blockchain de ce nœud me semble-t-il.
Contrairement à la proposition de faire des versements sur une clef publique Ğ1 identique à un compte membre Ğ1-test, ta proposition de signer une clef publique Ğ1-test par un compte membre Ğ1 signifie que je peux le faire sans avoir de compte Ğ1-test, juste en piquant un clef publique membre à un autre. C’est peu probable et pas très glorieux, mais bon. Pour éviter ça, il faudrait combiner deux signatures pour que remuniter soit sûr que la personne possède bien les deux comptes à relier. Ce qui est plus compliqué que la proposition faîte plus haut.
En effet il se greffe par dessus, de ce fait ce n’est pas un procésus intégré à la blockchain. C’est ce que je voulais dire par indépendant, mais le terme n’est pas forcement adapté.
Le compte g1 signe la clé g1test et la clé g1test signe la clé g1, chaqu’un étant envoyé sur Cesium à la clé g1/g1test du noeud (unique) Rémuniter. Un peu plus compliqué mais tout à fait faisable et compréhensible.
Admettons :
J’ai un compte Ǧ1test avec la clef publique suivante : 5fb23G7e
les mêmes codes me permettent d’accéder à ce compte sur la Ǧ1.
Remuniter peu donc :
avoir un compte Ǧ1 ou recevoir des dons.
observer Ǧ1test et envoyer des dons au comptes des auteurs de bloc… en Ǧ1 sur le même compte que si c’était en Ǧ1test.
La difficulté étant de modifier Rémuniter pour qu’il observe Ǧ1test et agisse sur Ǧ1.
Mais au pire, sans UI, un script qui remplie le rôle de remuniter en utilisant silkaj, et executé une fois par jour me semble peut-être plus simple à coder que de remanier Remuniter pour répondre à ce cas d’usage.
C’est vrai que même s’il pourrait techniquement y avoir vol (car les identifiants G1-test sont peu confidentiels), le risque reste faible et traçable, il suffit de vider le compte Ǧ1-équivalent-Ǧ1test régulièrement.
