@Looarn ok tu m’a convaincus, reste a voir ce qu’en pense les autres dev 
1 Like
Ce qui poserait des contraintes pour faire des transactions contre-factuelles (une transaction ayant une periode de validité limité), rendant plus difficile l’implémentation de canaux de paiements (Lightning).
3 Likes
Je pense à ouvrir un PRC ^^ Il y a un format standardisé, ou je le fais à l’inspi ?
Les canaux sont (si on part sur une solution à la bitcoin) sur un Layer au dessus de la blockchain, ce qui signifie que pour que des coins arrivent effectivement sur Lightning, il faut une TX depuis la blockchain qui les inscrivent en dur sur le Layer 2. A partir de la le protocole propre à Lightning prend le relais.
Sauf si vous avez une autre approche déjà documentée ? Je veux bien jeter un oeil. 
De souvenir il y a déjà une fenêtre de 6 jours qui rend les transactions trop vieilles invalides, moi je propose 2 mois. ^^
Le layer 2 consiste à contre-signer des transactions qui à tout moment peuvent être publiées sur la blockchain, et que le sont que s’il y a un désacord entre les participants du canal. La grande majorité du temps elle ne le sont donc pas (on se base sur un fait sûr mais qui n’est pas publié => contrefactuel).
Si les transactions périment au bout de 2 mois, alors un canal doit forcement exister moins de 2 mois pour ne pas se retrouver avec une transaction contre-factuelle inutilisable.
Lightning Network : https://lightning.network/lightning-network-paper.pdf
Conterfactual states channels : https://l4.ventures/papers/statechannels.pdf
4 Likes
Du coup si je comprends bien la fenêtre de 6 jours sur les noeuds actuel est configurable, tout comme le serai celle de 2 mois ; mais n’est pas une règle protocolaire.
Si un noeud A souhaite élaguer plus que les autres, ça ne pose pas de souci à priori. Un noeud B qui lui acceptera la transaction dans sa piscine, la publiera dans un bloc, et à partir de là, le noeud A la verra comme valide, vu que c’est une règle piscine.
Et on n’empêche pas les TX sous forme de contrat notamment celle avec une limite dans le temps.
Si je dis bien c’est tout pareil que le fonctionnement actuel non ? 
Si actuellement c’est protocolaire . Si une transaction est écrite dans un block dont le temps est plus de txWindow secondes après le blockstamp que contient la transaction, alors le block est considéré invalide.
2 Likes
Je ne m’en souvenait même pas tient … Il faudra voir si cette règle ne pourra pas être relégué à une simple “bonne pratique” pour éviter de limiter par defaut ce qu’on peut faire avec.
2 Likes
Je pense que la règle BR_G103 peut être supprimé sans problème, mais peut être que quelque chose m’échappe quand a la raison de cette règle mise en place par @cgeek ?
1 Like
Le commentaire est un champ technique, destiné à permettre de porter une référence d’un système extérieur. Il permet de l’indexation, par exemple.
Mais son usage a rapidement été détourné pour y inscrire un commentaire humain. Je n’ai pas de problème avec cela, après tout pourquoi pas.
Oui c’est très efficace pour les comptes membres. J’utilise ce mécanisme pour la piscine de certifications : elle limite à 12 certifications par membre (ce qui est le max possible étant donné le délai de 5 jours inter-certifications et les 2 mois de péremption = 60 jours).
Mais ça ne fonctionne pas pour les non-membres, qui peuvent créer autant d’issuers qu’ils le souhaitent.
Le chaînage fait partie intégrante du protocole depuis le début, mais un bug faisait que celui-ci était inopérant pendant un temps (je dis cela de mémoire). Puis après correctif, un jour une remontée utilisateur m’a fait implémenter la règle de profondeur max et nous avions tranché au doigt mouillé pour une valeur de 5 avec @nanocryk visiblement.
Cette discussion est intéressante, on voit qu’elle recoupe celle que vous avez ici.
Ne modifions pas le protocole pour de mauvaises raisons @elois évoquait plus haut que pour la problématique de date, Cesium+ pouvait très bien s’en occuper, pourquoi cagette.net ne pourrait-elle pas faire de même ? En plus ce serait autrement plus précis, à la nanoseconde près si ça vous chantait.
Par contre pour le rejeu en cas de fork, oui, je comprends.
Je ne vois pas d’autre raison que le spam. A priori, oui, cette règle pourrait être supprimée. En plus elle est effectivement très gênante pour du Lightning ou même du Atomic Swap (change inter-blockchain) avec de longs délais.
3 Likes