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 .
1 Like
Le hash garantit l’integrité des données, le timestamp leur validité, je penses que ça a du sens !
Utiliser le timestamp permet de changer le code sans changer le model, si l’on souhaite contraindre le timestamp sur un bloc on peu le faire sans changer le model.
contrainte sur le number => peu précis dans le temps
contrainte sur le HASH => problème des fork
contrainte sur le medianTime => flexibilité du code! indépendance des données (moins de lookup a l’indexation), simplicité du code,… c’est un entier a peine plus gros bien que ça reste un index naturel avec une complexité similaire au number
Oui il y a un truc 
La fonction CSV (CheckSequenceVerify), a été créée pour les Lightning Network. Son but principal est de permettre de prémunir l’une des parties et cas de tentative de vol de l’autre partie :
Outsourceable enforcement: if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.
Cela implique que le délai de la fonction CSV court à partir de la date d’écriture en blockchain de la transaction, et non a partir de la date d’émission de la transaction.
Ainsi CSV(délai) + medianTime n’est pas équivalent à CLTV(délai + medianTime) car dans le 1er cas le medianTime n’est pas connue (on ne sait pas lors de l’émission du document transaction a quel moment il sera inscrit en blockchain, ni même s’il le sera un jours).
D’ailleurs la définition de la fonction CSV est explicite :
- CSV: (
OP_CheckSequenceVerify,OP_CSV) opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See relative locktime.
Pour aller plus loin : bips/bip-0068.mediawiki at master · bitcoin/bips · GitHub
Une explication en français et avec des schémas simples et clairs des Lightning Network : https://bitconseil.fr/bitcoin-lightning-network-histoire-fonctionnement/
D’ailleurs, si on veut que les Lightning Network soient utilisables sur la G1 il nous faudra supprimer la contrainte txWindow du protocole, mais je dérive, on vas ouvrir un autre thread la dessus 
Pour revenir au sujet, en effet on pourrait dater la transaction directement par un timestamp, je n’y vois pas d’inconvénient
Pour le coup, en l’état actuel de DUBP j’en vois un avec la fonction CSV car TxTime devient malléable (en levant la contrainte du blockstamp), du coup il est possible de mettre une date future et de dépenser sans attendre le délai inscrit dans CSV.
Sauf à modifier le protocole pour qu’une transaction doive avoir un timestamp < HEAD.medianTime bien entendu. Dans ce cas le champ timestamp libre devient tout indiqué (par contre la transaction ne peut pas rentrer tout de suite en blockchain si le client ne tient pas compte de l’heure blockchain qui est toujours en retard).
Le plus souvent c’est vrai, mais pas de façon absolue. Il existe des blocs au medianTime identique (notamment les tous premiers). Autrement dit le medianTime ne permet pas d’identifier un bloc.
1 Like
En effet cela signifie que si l’on veut se baser sur un timestamp libre pour la date d’émission il faut modifier en même temps la fonction CSV pour qu’elle se base sur les dates d’inscription en blockchain et pas les dates d’émission (ce qu’il faudra faire de toute façon de mon point de vue).
Ceci étant concernant le choix entre blockNumber ou timestamp pour dater l’émission du document transaction, ça m’est égal
4 Likes
Oui, oui, oui, bravo messieurs, c’est bien le temps blockchain qui importe.
Le temps relatif à l’emission de la TX, n’est qu’une vue client et n’a pas de sens en terme de protocole selon moi.
1 Like