Pour simuler le temps, Bitcoin utilise son minage qui devient de plus en plus difficile, en tenant compte de la croissance de la puissance informatique. Il n’a pas besoin de se synchroniser à une horloge.
Mais dans le cas d’uCoin et j’imagine aussi pour OpenUDC, puisqu’il y a distribution régulière d’un DU, quelle est l’horloge utilisée pour décider le l’instant d’allocation ?
Autorisez vous une autorité de “time-stamping” ? Comment discriminer entre des noeuds du réseau qui ne donneraient pas la même date ?
uCoin définit 3 temps.
Le temps blockchain
Dont l’unité est le block, et dont chaque unité est imprédictible (sa valeur vaut le n° de block + son hash). Ex. : 3328-0837171AD6CE72B7DAD0409A230D43A9CCFFE0DC.
Le temps classique
Défini par les membres de la TdC, tour à tour, au moment où ils génèrent un block. Plus précisément, au moment de la génération du block, ceux-ci donnent l’heure qu’ils estiment être. Cette valeur, par ailleurs bornée, est ensuite utilisée pour définir le temps médian, qui le temps “officiel” de la blockchain.
De manière générale, ce temps est toujours “en retard” par rapport à l’heure courante. Retard dépendant des paramètres utilisés pour la monnaie.
Le temps Dividende Universel
Enfin une 3ème unité, le temps DU. Temps discret, utilisant les entiers naturels. Le DU est inscrit dans la blockchain en se basant sur le temps médian, et à chaque DU généré, on obtient une nouvelle unité de temps DU.
Ainsi, on démarre avec aucun temps DU (t = 0), puis 1 temps DU (t = 1, puis 2 (t = 2), etc.
Merci pour cette réponse, mais cela n’enlève pas mon inquiétude.
Pour le “temps blockcain”, c’est un hash de la chaine précédente…je ne pense qu’on puisse parler de temps, mais la question n’est pas la !
Pour le “temps classique”, la question est de savoir si l’estimation du temps est bonne ou bas. Sur quel critère et quelle référence (horloge) décider si cette estimation est acceptable ou pas ?
Ensuite, oui, le versement du DU est synchronisé au temps médian, mais c’est de temps médian qui peut être l’objet d’un désaccord entre nœuds du réseau. Quelles sont les règles pour prendre tel bloc en fonction du temps déclaré ?
Tant pis.
Non.
Vu tes réponses sur l’autre sujet (Conseil de lecture), c’est peine perdue de t’expliquer cela. Désolé, mais le concept de relativité t’échappe.
En tous les cas, tu peux obtenir toutes tes réponses dans le protocole. Plus précisément, tu peux lire la partie “Processing > Bloc” pour savoir comment est accepté un bloc.
Serais-tu vexé au sujet de mon conseil de lecture ?
Pour en revenir au problème d’horloge, ta description du protocole ne détaille pas le comportement quand un validateur donne une mauvaise date.
S’il donne une date dans le futur, quelle incidence sur les DU qui auraient du être versés entre temps ?
Ne peut-il pas accélérer le temps (en modifiant la date système de son nœud) pour que lui et ses copains actuels touchent plus de DU ? et si les autres veulent faire de même ?
Sur Bitcoin, c’est l’obligation de minage par des GPU toujours plus puissant qui ralentit la création de nouveaux coins, mais pour uCoin, si le minage est plus facile, c’est bien une horloge qui détermine l’instant de distribution d’un nouveau DU, non ?
Tu me diras que modifier le temps n’est qu’une entorse à la symétrie temporelle !
Libre ne signifiant pas gratuit, à la place de cgeek je proposerais un tarif en MetaBrouzoufs pour donner un cours d’horloge relativiste. Par exemple 12 DU mb me paraîtrait un bon prix. Après tout s’il y a de l’offre et de la demande il y aura bien un prix pour payer et ainsi équilibrer les choses…
Non, vraiment, trop de choses à expliquer. D’autres sont déjà capables d’expliquer à ma place, mais surtout il serait bien plus facile de renvoyer vers un wiki ou quelque chose s’en rapprochant que de faire du Question/Réponse systématique.
Edit : remarque, tu n’as pas tort @Galuel. Je ferais bien de demander une contrepartie monétaire !
…on pourrait se demander qui devraient payer à qui 
!
C’est vrai que c’est souvent difficile d’avoir une évaluation d’experts. Il semblerait que dans le domaine de l’économie, il soit normal de payer 100€ pour faire évaluer un papier par une revue de bon rang alors que dans le domaine de l’informatique/math, les publications restent toujours gratuites pour leurs auteurs…une des raisons du manque de retour sur le Partage Marchand.
Comprenez bien qu’avec mes questions “basiques”, je fais à peu près ce que je voudrais que l’on me fasse comme critique scientifique. J’ai donc du mal à comprendre que cela vous gène.
La réponse de Galuel n’est pas si anodine que cela. Elle montre qu’il y a bien une chose qui nous distingue; Pour Galuel, il semblerait qu’on peut tout, absolument tout vendre du moment qu’il y a un marché, conformément à une vision libertaire de l’économie. Moi, je pense qu’il doit persister une zone non-marchande, de biens public, dont la recherche scientifique fait parti. Si un forum technique devenait payant (pas certain qu’il marcherait), mais il remettrait en cause certains bon vieux principes. Alors, non désolé, ton forum est gratuit que tu le veuilles ou non.
Cette vision ultra-libertaire est parfaitement dans la logique de Bitcoin. La TRM apporte une certaine originalité au Bitcoin classique, mais cela reste bien de la même famille.
pelinquin, ou l’exemplification du péremptoire.
1 Like
Ah, tu vas m’y obliger ? Quel bon blagueur ce pelinquin ! 
Je propose de vérifier expérimentalement que cgeek peut vouloir faire payer 1 DU metabrouzouf avant de valider tout post de pelinquin sur le forum. Cette preuve pourrait invalider toute l’édifice théorique de pelinquin par une approche scientifiquement vérifiable.
1 Like
Quand cgeek fait référence à la doc c’est que ça y est.
PoWMin
Définitions
speed = dtDiffEval / (medianTime(incomingNumber) - medianTime(incomingNumber - dtDiffEval))
maxSpeed = 1/minGenTime
minSpeed = 1/maxGenTime
Rules
If incoming block’s Number is > 0 and a multiple of dtDiffEval, then:
If speed is greater or equal to maxSpeed, then PoWMin = PoWMin + 1
If speed is less or equal to minSpeed, then PoWMin = MAX(0, PoWMin - 1)
Else
If Number is > 0, PoWMin must be equal to previous block’s PoWMin
Dates
For any non-root block, MedianTime must be equal to the median value of Time field for the last medianTimeBlocks
blocks. If the number of available blocks is an even value, the median
is computed over the 2 centered values by an arithmetical median on
them, ceil rounded.
J’ai bien compris qu’on ajustait la difficulté de travail en fonction des blocs précédents, mais je ne vois pas à quel moment on demande l’heure système ?
Le bloc n’est accepté par le réseau que si il a été miné dans un intervalle de temps défini en fonction de la difficulté de l’auteur.
et si l’auteur change de machine et passe d’un coup d’un raspberryPi à un méga cluster de GPU ou inversement ?
et s’il y a désaccord sur la satisfaction de la contrainte pour accepter la validation d’un bloc, parce que les horloges des nœuds sont différentes ou-bien n’'évoluent pas à la même vitesse ?
Sa difficulté augmentera très vite (Calculs x4 à chaque bloc miné il me semble).
Pour le désaccord, tu ne peux pas faire marcher un réseau décentralisé sans synchronisation d’horloge. Pas pour rien que NTP existe. Si ça arrive c’est que les membres du réseau ne souhaitent pas faire fonctionner leur réseau. Comme bitcoin et l’histoire des 51% de noeuds corrompus, en sommes.
donc si plus de la moitié des nœuds décident de ne plus se synchroniser avec NTP, le réseau peut subir une accélération de distribution de DU ?
Si plus de la moitié des noeud sont corrompus, le réseau peut être considéré corrompu oui.
Sauf que c’est loin d’être binaire “corrompu/pas corrompu”. Pour quel écart de temps avec NTP, un nœud est-il considéré comme “corrompu” ? et comment distinguer une désynchro d’horloge volontaire ou involontaire ?
Comment distinguer une désynchro d’horloge volontaire ou involontaire ?
Il n’y a pas de distinction, les blocs seront rejetés dans chaque cas.
Pour quel écart de temps avec NTP, un nœud est-il considéré comme “corrompu” ?
Les écarts de temps ne sont pas par rapport à NTP. Les règles définissent l’acceptation d’un noeud “localement”. Ces règles sont appliquées par chaque noeud, individuellement. Pour que le réseau fonctionne, il est nécessaire que les noeuds aient une base de temps valide → utilisation de NTP pour ce faire.
Un bloc est accepté suivant plusieurs règles. Une des règles qui correspond à ta question est celle ci :
A block must have its Time field be between [MedianTime ; MedianTime + accelerationMax].
Root block’s Time & MedianTime must be equal.