Ca me fait penser aux outputs conditions: elle sont quasiment optionnelles (SIG étant le minimum) et cela n’a dérangé personne.
L’important pour moi est de savoir ce qu’en penses @cgeek, pour Duniter ?
En deuxième lieu (car pas encore concernés par la production) @elois, pour DunitRust ? et @Junidev pour Juniter ?
@Moul, @inso, etc. pour les clients.
Est-ce que cette solution te conviendrait à toi aussi, @Looarn ?
D’un point de vue client, je vois pas bien comment le hash du bloc te permet d’avoir la date d’envoi du document en mempool. Selon moi la date du bloc est suffisante pour afficher l’historique des transactions, c’est imprécis, mais Silkaj fait avec. Ça correspond à la date d’entrée de la tx en chaîne, à la génération du bloc, pas quand elle a été émise sur le réseau. Comment fais-tu pour déterminer la date de réception/émission d’une tx à partir du hash de bloc ? Elle ne peut être que dans les logs du nœud qui a généré une ligne de log à la réception de la tx.
Y’a surement quelque chose que j’ai pas compris dans votre discussion, je veux bien des éclaircissements.
Je n’ai jamais parlé de la date de réception par le noeud. cf ce post :
Sans le blockHash dans la TX, cela devient :
Merci pour la précision. Je comprends mieux la discussion.
J’avais compris à tort que le hash servait à avoir la date d’émission de la tx. Or, c’est pas le sujet.
Je comprends pas encore très bien ton point.
Je ne vois pas ce qui pourrait poser problème dans l’enlèvement du hash de bloc dans la tx.
J’ai besoin d’y penser à tête reposée pour me forger un avis et/ou relire la discussion.
Ca pourrait etre le bon compromis.
De façon pragmatique si le hash est optionnel, ça me facilite la vie, et je n’ai plus a craindre des forks, donc oui ça marche. 
Mon coté “smallblockiste” considère que l’espace dans les blocs est précieux et qu’il ne faut pas le gacher, aussi ajouter un champ qui fait à mon sens doublon (BlockNumber = déclaratif de à partir de quand la TX est valide (de currentBlock - 6 jours à endOfTimes) et blockID = à partir de quand la tx est valide de currentBlock - 6 jours à currentBlock)
La complexité est déscendu sur les noeuds (rien d’insurmontable, mais ça induit un peu de complexité).
Finalement pour le marchand, la date qui fait fois et qui est importante est la date de réception du paiement et non sa date d’emission.
En tant que client, la date d’emission pourrait etre une donnée lié au compte utilisateur et non une donnée blockchain.
Mais possiblement je vais trop loin là.
Avec le dernier fork, je crois qu’il devient important de statuer sur l’avenir des TX multi-branches…
Concernant la suppression du hash du bloc dans le document TX, le point négatif important selon moi est l’écriture possible de TX dans le futur, avec le risque de s’accaparer les DU futurs (par exemple par braquage), car les numéros de blocs (sans le hash) sont prédictifs (à un delta près).
Une solution simple serait de consommer les DU en indiquant le blockstamp plutot que le numéro du bloc :
AMOUNT:BASE:D:PUBLIC_KEY:BLOCKSTAMP (BLOCKSTAMP au lieu BLOCK_ID)
On garderait ainsi tous les avantages de la suppression du blockHash au niveau global de la TX, sans le problème de consommation futur des DU.
Le risque de perte des TX (en cas de fork) serait toujours présent uniquement s’il l’on consomme tous les derniers DU des branches, ce qui me parait acceptable, et par ailleurs facile à gérer dans les clients (avertissement utilisateur, etc.)
Qu’en pensez vous ? Il faudrait un changement de protocole, mais la suppression du blockHash est équivalent de ce point de vu là.
Si je reformule ta proposition serait de :
Est ce que c’est bien ça ? Sinon, peut tu formuler précisement ta proposition de changement complète ? Merci 
En fait c’est déjà possible même avec le hash, puisque la piscine est hors protocole.
Personnellement je n’arrive pas à mettre la résolution de fork dans le protocole, de la même façon que WS2P. Je crois que c’est un problème d’espace logique (tiens, @Galuel aura peut-être un avis là-dessus).
Parce que si j’adopte le protocole DUBP, alors il m’est garanti le respect de ce même protocole par les autres utilisateurs à un instant donné. Tandis que ce n’est pas vrai de la résolution de fork dans la mesure où l’état distant des autres nœuds est ambigu (déjà définir instant et ensemble des nœuds est hyper ambigu). Je crois que c’est ce problème de définition d’espace-temps qui rend la résolution hors-scope du protocole.
Néanmoins je ne nie pas que celui qui veut participer à l’état de la Ğ1 a tout intérêt à suivre ces protocoles supplémentaires (WS2P, résolution de fork), de même que nous avons intérêt collectivement à ce que chacun les suivent. Mais pour moi ce sont bien des entités à part du protocole Duniter en ce qu’ils ne sont pas nécessaires à son exécution.
Exemple assez courant sur la Ğ1 : le réseau se remet d’accord parce que les utilisateurs forcent la synchronisation sur un nœud particulier, et à cette occasion n’utilisent ni la résolution de fork ni WS2P (bon, WS2P est utilisé oui, mais pas nécessaire : on peut synchroniser avec BMA ou avec un simple dossier).
Oui, et puis j’y ai aussi réfléchi depuis (je n’avais pas trop le temps pendant les fêtes de fin d’année).
En fait non il n’y a pas de problème (j’ai cru mais non). Deux cas possibles :
Aussi j’ai trouvé un argument en faveur de la suppression du hash dans les TX : cela concerne un vieil argument de @Galuel (s’il veut bien le reformuler je suis preneur) sur le fait qu’un point crucial de toute monnaie c’est la confiance dans sa stabilité/son existence. Autrement dit une monnaie où les transactions sont sujettes à l’opposition (par fork) n’inspire pas vraiment confiance à l’humain et affaiblissent celle-ci.
Bref après relecture de ce sujet, je n’ai pas vraiment d’argument qui aille contre la suppression de ce hash. La date de signature peut par ailleurs être indiquée dans le champ commentaire (pas besoin de mettre le hash entier) pour ceux pour qui cette info est importante.
De mon souvenir le hash était nécessaire sur les documents de WoT afin de protéger la communauté dans son ensemble, mais là concernant les TX je ne vois pas de problème particulier.
À ce stade je trouve effectivement que ce champ nous contraint plus qu’il nous aide.
Oui le fork est toujours ambigu, et n’a pas de rapport avec le protocole puisque les branches restent parfaitement logiques. Le fait de suivre une branche ou une autre peut avoir quantité de raisons, mais surtout n’a pas de rapport avec l’état de la monnaie, ça a plutôt un rapport avec des problématiques de connexions (quel espace de noeuds “voit” un noeud particulier ? Ce sera très souvent différent, selon le noeud, et la résolution de fork étant une affaire de consensus alors on ne peut pas trancher sur qui est majoritaire ou pas… Et le consensus peut mettre bien du temps à s’établir et le faire sur un jugement humain).
Eh oui ! Cf les accords de la Jamaïque
On ne peut pas dire que l’or soit resté “monnaie courante” depuis…
Mais aussi les problèmes liés à l’impossibilité ou la limitation des transfert, des blocages récurrents, des failles, sont autant de thèmes qui font chuter la confiance et donc l’existence même de la monnaie, cela pousse à chercher d’autres solutions.
si le Block hash et la précédence sont abandonnée pourquoi ne pas utiliser le median time comme reference ? c’est plus précis que le block number surtout par rapport au CSV/CLTV, c’est un entier unique et ordonnée dans la chaine (index) donc la complexité ne change pas. mais la précision de la transaction s’en retrouve amélioré.
de plus cela évite un lookup supplémentaire pour trouvé le timestamp d’expiration. => persformance
Même commentaire pour les documents de WOT. Ca simplifierais bien des choses !
Qu’est-ce que je rate dans mon raisonnement ?
Déjà merci de me faire remarquer qu’il faut bel et bien garder une référence temporelle dans la transaction pour que la condition CSV fonctionne encore.
Ce que tu rates : CSV(délai) + medianTime est strictement équivalent à CLTV(délai + medianTime). Or les cryptos existantes ont bien conservé ces deux fonctions distinctes, il y a donc sûrement un truc. Mais je ne sais pas lequel, à chaud
Quel est le détail des fonctions ?
En fait je l’utiliserais partout le medianTime, car c’est une dépendance forte sur un entier. je le remarque au niveau des certif, le blocknumber seul, c’est la merde techniquement. ça force une dépendance sur l’index pour un timestamp.
Outre la technique, lorsque je signe un chèque ou signe un document chez le notaire je le date, c’est la date qui induit la précédence.
Antidater un document officiel c’est pénalisable, en partit pour cette raison. sur le marché financé, on imagine bien le blé qu’on peu se faire simplement en falcifiant un timestamp.
c’est pour ça que la précedance me paraissait une nécessité jusqu’à lire ce thread mais je n’y ai pas réfléchis plus que çà
CLVT(TIMESTAMP)returns true if and only if the transaction including block’sMedianTime >= TIMESTAMP.
…
CLTV's parameter must be an integer with a length between1and10chars.
CSV(DELAY)returns true if and only if the transaction including block’sMedianTime - TxTime >= DELAY.
…
CSV's parameter must be an integer with a length between1and8chars.
Et quelle est la relation entre TIMESTAMP, TxTime et DELAY ?
Lapin. 
Lapin compris la question.
Ce sont des temps exprimés en secondes, TIMESTAMP indiquant un nombre de secondes écoulé depuis le 1er janvier 1970 à minuit UTC (indique un moment quelconque). Le reste est exprimé au-dessus.
Notamment, il n’existe aucune relation entre TIMESTAMP et DELAY, car ce sont des paramètres de deux fonctions différentes.
Quant à TxTime (exprimé en timestamp)… Le moment où je fais une transaction a-t-il une influence sur le délai de bloquage de la monnaie ? Il me semble que non, mais peut-être qu’une étude sociologique poussée aboutirait à des conclusions différentes. Je ne suis pas sûr si TxTime est la date de la transaction ou la date de son enregistrement en BC.
Et MedianTime est le temps Blockchain, exprimée en Timestamp.
S’il n’y a aucune relation entre TIMESTAMP, TxTime et DELAY, alors les deux inégalités (A) MedianTime >= TIMESTAMP et (B) MedianTime - TxTime >= DELAY ne peuvent pas être équivalentes.
En effet pour qu’elles soient équivalentes, il faut alors :
MedianTime >= TIMESTAMP <=> MedianTime >= TxTime + DELAY
Ce qui implique qu’il existe une relation simple qui est que si TIMESTAMP est inférieur ou égal à MedianTime, alors TxTime + DELAY doit l’être aussi, et inversement.
Ce qui signifie que TIMESTAMP et (TxTime + DELAY) doivent toujours être ensemble inférieurs ou supérieurs à TIMESTAMP, l’un ne pouvant l’être sans l’autre.
Ce qui constitue une relation entre ces trois paramètres et TIMESTAMP
Il semble qu’utiliser MedianTime revient a pointer précisément un bloc (et sa branche), comme actuellement avec le Number+Hash. Or le but recherché est de pouvoir générer des TX valables pour n’importe quelle branche.
A moins que ton idée ne soit d’autoriser n’importe quel MedianTime, y compris provenant de branche minoritaire ?
c’est ca, n’importe quel timestamp sauf si pour une raison X ou Y il faut le contraindre a l’émission d’un bloc ! ca permet de signer des transactions a minuit précise plutôt que minuit 2 minutes et 34 secondes, ca change rien mais ca devient une possibilité si on utilise le timestamp… l’utilité de ce truc est surtout technique… tu a dut t’en apercevoir avec l’expiration d’un certif… c’est chiant, c’est d’ailleur (probablement) la raison pour laquelle cesium spam les noeud sur la page de certifications, tu va verifier chaque blocks… pour obtenir leur expiration, ce qui est assez moche… une requette par certif c’est assez inefficace pour un simple timestamp .