Aller au contenu

Bitcoin et autres cryptomonnaies


Messages recommandés

C'est la tension entre le bid et le ask qui fait évoluer le prix et c'est principalement la nouvelle demande (en Bitcoin ou en fiat) qui la créé.

J'imagine que vous avez raison tous les deux mais je ne comprends pas pourquoi. De la même façon, ça n'est certainement pas l'or extrait et mis sur le marché qui joue sur le cours.

C'est largement moins que ça. Environ 150.000 BTC sur les plateformes en USD et 1.000.000 BTC sur les chinoises - depuis qu'ils ont éteint les robots.

https://www.cryptocompare.com/coins/btc/charts/USD

Je maintiens mes 3 millions. Pas le calcul sous la main cependant.

Lien vers le commentaire

Je maintiens mes 3 millions. Pas le calcul sous la main cependant.

 

Tout le monde sait que les volumes des deux chinois sont fake. Récement il y a eu des révélations assez concrètes sur le sujet, je ne retrouve plus la source mais de mémoire ils multiplient les volumes par 7 ou 8.

 

Wash Trading Definition

Lien vers le commentaire

Le souci avec Coq (et aux langages de la même famille, genre OCAML ou même Haskell en plus pur) c'est le nombre de programmeurs valables sur le marché (très faible).

 

Et d'autre part les personnes compétentes pour vérifier le code seront encore plus rares.

Lien vers le commentaire

Cela revient à une critique que je ferais à l'article en question ( critique qui survient aussi dans les commentaires ) : c'est une question d'outil mais aussi de compétences. (je ne pense pas de mal de la génération de script kiddie dont je fais partie parce que je pense que c'est un premier pas dans la programmation et donc une opportunité vers une programmation plus rigoureuse pour ceux qui veulent étudier cela ).

Il faut élever le niveau général en quelque sorte... en attendant ceux qui détectent des failles ont plus de pouvoir. Est-il possible que plus tard dans le domaine des smart contracts ceux qui seront plus smart auront toujours l'avantage ?

Lien vers le commentaire

De façon générale, si on veut avoir confiance dans les smartcontracts, il faudra qu'ils soient écrits d'une façon formelle humainement compréhensible dont on pourra dériver le code source de façon sûre et certaine. Ce qui impose d'une part la création d'un ML formel ad hoc pour ces smart-contracts. On en est encore trèèèès loin.

 

Une alternative serait que les personnes mandatées pour auditer le code soient responsabilisées financièrement. On peut aussi imaginer un système d'assurance.

Lien vers le commentaire

Et d'autre part les personnes compétentes pour vérifier le code seront encore plus rares.

mhmmhm dans l'idée, c'est le ML qui permet de vérifier (au sens mathématique) que le code est ok.
Lien vers le commentaire

Une alternative serait que les personnes mandatées pour auditer le code soient responsabilisées financièrement. On peut aussi imaginer un système d'assurance.

Non et non. Rien à voir. Il existe déjà des systèmes automatiques qui font ça, et c'est tout le point du post du gars. Il y a des domaines où on fait vérifier systématiquement les codes pondus par des outils automatiques, voire on écrit les specs sur ces outils qui pondent un résultat (en C, en ADA par exemple) qui est garanti (sur facture) correspondre aux specs.

Il y a par exemple des outils qui vérifient qu'un compilateur pond un code machine qui fera exactement ce qui est décrit dans le code source. Ce n'est pas un humain qui le fait (et qui pourrait de toute façon). Et ce n'est pas trivial, c'est essentiel pour certains systèmes (avionique, par exemple).

Lien vers le commentaire

J'imagine que vous avez raison tous les deux mais je ne comprends pas pourquoi. De la même façon, ça n'est certainement pas l'or extrait et mis sur le marché qui joue sur le cours.

L'ex head of energy trading de JPMorgan :

 

Commodities price on the rate of change of inventory, not on inventory.

 

http://www.coindesk.com/daniel-masters-440-bitcoin-price/

 

C'est peut-être contre-intuitif mais c'est le même principe qui fait que 100 millions $ de fiat qui achètent des bitcoins ne vont pas augmenter la market cap de Bitcoin de 100m$ mais de beaucoup plus que cela. Le stock ne satisfait pas la nouvelle demande, ce qui satisfait la nouvelle demande est la fraction de l'offre qui n'appartient pas au stock .

  • Yea 1
Lien vers le commentaire

Cela revient à une critique que je ferais à l'article en question ( critique qui survient aussi dans les commentaires ) : c'est une question d'outil mais aussi de compétences. (je ne pense pas de mal de la génération de script kiddie dont je fais partie parce que je pense que c'est un premier pas dans la programmation et donc une opportunité vers une programmation plus rigoureuse pour ceux qui veulent étudier cela ).

Il faut élever le niveau général en quelque sorte... en attendant ceux qui détectent des failles ont plus de pouvoir. Est-il possible que plus tard dans le domaine des smart contracts ceux qui seront plus smart auront toujours l'avantage ?

L'article ne fait pas de critique des script kiddies, il dit à raison que ceux-ci ne sont pas armés pour la tâche qu'ils se sont fixés.

Un smart contract est par définition ancré dans le réel. Des specs "en anglais" (en langage humain) sont particulièrement lacunaires ou buguées si on veut (interprétables). L'écart au source pondu est difficile voire impossible à déterminer, le source pondu n'est pas vérifié formellement (au sens mathématique), et le langage choisi ajoute encore en plus des ambiguïtés.

Lien vers le commentaire

Non et non. Rien à voir. Il existe déjà des systèmes automatiques qui font ça, et c'est tout le point du post du gars. Il y a des domaines où on fait vérifier systématiquement les codes pondus par des outils automatiques, voire on écrit les specs sur ces outils qui pondent un résultat (en C, en ADA par exemple) qui est garanti (sur facture) correspondre aux specs.

 

Comment ça rien à voir ? un auditeur ou un groupe d'autiteurs humains qui fait le job sera davantage responsabilisé s'il s'engage financièrement. On peut aussi imaginer un système d'assurance.

Lien vers le commentaire

Comment ça rien à voir ? un auditeur ou un groupe d'autiteurs humains qui fait le job sera davantage responsabilisé s'il s'engage financièrement. On peut aussi imaginer un système d'assurance.

Tout le point est d'éviter l'intervention humaine qui laisse trainer des merdes. Le groupe d'auditeurs, même payé, face à une vérification formelle, ça fait pas le job.

Tu peux payer ce que tu veux, humain = bugs. On a même fait péter des Ariane avec ça. Pourtant, t'inquiète, y'avait de l'incitation et de l'engagement financier.

Lien vers le commentaire

Tout le point est d'éviter l'intervention humaine qui laisse trainer des merdes. Le groupe d'auditeurs, même payé, face à une vérification formelle, ça fait pas le job.

Tu peux payer ce que tu veux, humain = bugs. On a même fait péter des Ariane avec ça. Pourtant, t'inquiète, y'avait de l'incitation et de l'engagement financier.

 

Un moment il faudra bien vérifier formellement et humainement l'outil chargé de vérifier le code.

 

Sinon, message de TheAttacker : "I will set up a bounty for miners who oppose forks" :lol:

 

https://twitter.com/ActualAdviceBTC/status/744158525769691136

Lien vers le commentaire

 

Et ce sont les autres qui manquent de respect :rolleyes: Tu réagis comme un professionnel de la politique.

 

:fleur: En quoi t'ais-je manqué de respect, petite fleur fragile ? :fleur:

 

Je constate. Si tu comprenais de quoi on parle, tu ne dirais pas "Un moment il faudra bien vérifier formellement et humainement l'outil chargé de vérifier le code", c'est tout. Comme je l'ai écrit, en toutes lettres, de façon compréhensible, "Tout le point est d'éviter l'intervention humaine qui laisse trainer des merdes." (@15:22) ; le but du système proposé est d'autoriser une production de code source à partir d'une description fonctionnelle non ambigüe, sans bug et sans intervention humaine. Si tu rajoutes ensuite : oh bah oui mais il faudra qd même des humains pour vérifier, c'est que tu n'as rien lu ou rien compris.

Lien vers le commentaire

le but du système proposé est d'autoriser une production de code source

 

Et comment tu vas garantir que ton "système" fonctionne correctement, gros malin ?

Un auditeur ça fait pas le job, humain = bugs. On a même fait péter des Ariane avec ça. :lol:

Lien vers le commentaire

Et comment tu vas garantir que ton "système" fonctionne correctement, gros malin ?

Tu ne comprends pas de quoi il s'agit. Ce que tu viens d'écrire le montre clairement. Il n'y a pas d'humain. C'est tout le but. Ça marche. Ça existe déjà. Renseigne-toi.

Allez : https://fr.wikipedia.org/wiki/Notation_Z , https://fr.wikipedia.org/wiki/Méthode_formelle_(informatique)

C'est vraiment la base, mais fais un effort.

Lien vers le commentaire

Tu ne comprends pas de quoi il s'agit. Ce que tu viens d'écrire le montre clairement. Il n'y a pas d'humain.

 

Je t'explique qu'il faudra bien que des humains développent ce language car ce n'est pas une machine qui va s'en occuper. Tu alimentes la discussion en me reprochant de ne rien comprendre, donc ne t'étonnes pas si ça devient conflictuel car tu as tendance à rabaisser tes interlocuteurs un peu trop facilement.

 

Un autre exemple, dans un précédent message je soulignais l'intérêt d'un système de bug bounties qui permettrait d'atteindre l'objectif recherché en nettoyant le code des smart contract en profondeur, ce système ayant fait ses preuves. Ta réponse ? "Non et non. Rien à voir. Il existe déjà des systèmes automatiques qui font ça". Champion du monde :lol:

Lien vers le commentaire

Je t'explique qu'il faudra bien que des humains développent ce language car ce n'est pas une machine qui va s'en occuper.

Ceci est une ânerie.

 

Tu alimentes la discussion en me reprochant de ne rien comprendre, donc ne t'étonnes pas si ça devient conflictuel car tu as tendance à rabaisser tes interlocuteurs un peu trop facilement.

Je ne te rabaisse pas, mais le fait que tu le prennes comme ça indique clairement le problème : tu ne veux pas apprendre. Tu considères avoir compris, et tu considères que l'information que je te donne n'est pas utile. Tu ne cherches pas à comprendre cette information, et tu estimes que celle que tu donnes est pertinente (alors qu'elle est juste pile à côté de la plaque).

 

Un autre exemple, dans un précédent message je soulignais l'intérêt d'un système de bug bounties qui permettrait d'atteindre l'objectif recherché en nettoyant le code des smart contract en profondeur, ce système ayant fait ses preuves. Ta réponse ? "Non et non. Rien à voir. Il existe déjà des systèmes automatiques qui font ça". Champion du monde :lol:

Ceci est une autre ânerie (pas parce que ça ne marche pas - ça ne marche pas, ou pas assez bien comparé à ce que j'évoque), mais parce que c'est encore à côté de la plaque. En substance, tu t'obstines à parler validation, alors qu'on est sur la partie vérification. Et comme tu ne sais pas qu'il y a une différence (fondamentale) entre ces deux concepts, tu t'enferres.

Maintenant, tu peux continuer à me balancer du "champion du monde" et autres petites amabilités, ou essayer de voir ce que j'ai voulu dire. A moins bien sûr que tu considères que je suis un imbécile, ce qui expliquerait assez bien ta démarche.

Lien vers le commentaire

Ceci est une ânerie.

 

C'est peut-être une ânerie mais je constate qu'il t'as fallu trois messages de ma part pour que tu interpretes correctement l'idée, et en attendant c'est moi qui comprennais rien :rolleyes:

  1. Un moment il faudra bien vérifier formellement et humainement l'outil chargé de vérifier le code.
  2. Et comment tu vas garantir que ton "système" fonctionne correctement ?
  3. Je t'explique qu'il faudra bien que des humains développent ce language car ce n'est pas une machine qui va s'en occuper.

 

Donc avant de descendre ton interlocuteur en lui disant à plusieurs reprises qu'il ne comprend rien il faut déjà t'assurer, toi, que tu as compris ce qu'il voulait dire.

 

Tu ne cherches pas à comprendre cette information, et tu estimes que celle que tu donnes est pertinente (alors qu'elle est juste pile à côté de la plaque).

 

J'ai lu une partie des liens que tu as posté avec intérêt et j'ai bien cerné l'idée derrière les techniques de méthodes formelles, le problème n'est pas là puisque je suis moi même convaincu de leur intérêt.

 

et tu estimes que celle que tu donnes est pertinente (alors qu'elle est juste pile à côté de la plaque).

 

Tu ne l'avais pas comprise, cette information. Nuance.

 

Ceci est une autre ânerie [...] parce que c'est encore à côté de la plaque.

 

Non. Ma remarque sur le bug bounty est parfaitement en rapport avec le sujet, car elle était en réponse à ton message que tu commencais par "De façon générale, si on veut avoir confiance dans les smartcontracts". Dire que ça n'a rien à voir est juste grotesque.

 

 

En substance, tu t'obstines à parler validation, alors qu'on est sur la partie vérification. Et comme tu ne sais pas qu'il y a une différence (fondamentale) entre ces deux concepts, tu t'enferres.

 

Foutaise. La discussion portait sur ni l'un ni l'autre. Tu as avancé une idée interessante de méthode formelle mais la discussion ne se limitait pas à ça. La preuve, tu commençais ton message par "De façon générale".

 

 

A moins bien sûr que tu considères que je suis un imbécile

 

T'es gentil h16 mais là c'est toi qui me prends pour un idiot.

Lien vers le commentaire

Foutaise. La discussion portait sur ni l'un ni l'autre. Tu as avancé une idée interessante de méthode formelle mais la discussion ne se limitait pas à ça.

 

vérifier (au sens mathématique)

 

des outils qui vérifient

 

le source pondu n'est pas vérifié formellement (au sens mathématique),

 

face à une vérification formelle,

 

Non seulement, j'ai toujours été clair que la discussion portait sur la vérification formelle (et donc pas sur la validation, pas évoquée du tout), mais je l'ai fait à 4 reprises, sans ambiguïté. Du reste, la validation ne correspond pas non plus à ce que tu présentes.

 

La mauvaise foi, ça va deux minutes.

Lien vers le commentaire

Non. Ma remarque sur le bug bounty est parfaitement en rapport avec le sujet,

Non toujours pas. Tu peux obtenir des résultats corrects avec cette méthode, ils seront toujours inférieurs à la vérification formelle (par essence) et comme il s'agit d'enlever l'humain le plus possible, le bug bounty en ajoute une trouzaine. Pour la validation, tu ne peux pas utiliser ce procédé non plus puisqu'on n'est pas au même niveau.

Mais tout ceci est sans importance, parce que ni toi ni moi ne déciderons de la façon dont ça va se terminer.

L'idée est de pointer qu'il existe des systèmes efficaces pour résoudre le problème qui se pose à Ethereum. Ce sont malheureusement des systèmes complexes et pas à la portée du premier venu, et apparemment pas encore dispo pour Ethereum, et donc coûteux. Manifestement, ce ne sera pas ce genre de système qui sera choisi comme solution, et Eth. continuera donc à trainer plus ou moins ce problème.

Maintenant, on peut espérer qu'en ajoutant de nouvelles couches d'humains sur des problèmes gérés par des humains pourra venir à bout des soucis. Ca ne s'est jamais produit une seule fois en 60 année d'ingénierie logiciel, mais cette fois, c'est peut-être différent.

Lien vers le commentaire

Arrêtez de vous chamailler !

H16 quand tu parles de "dériver" le code source d'un langage formel, tu parles bien d'une équivalence entre les deux formes ? Pourquoi on en est encore très loin (ce sont des sujets de recherches actifs) ?

(PS : Langage, pas language en anglais où il y a confusion entre langue et langage)

Lien vers le commentaire

Arrêtez de vous chamailler !

H16 quand tu parles de "dériver" le code source d'un langage formel, tu parles bien d'une équivalence entre les deux formes ? Pourquoi on en est encore très loin (ce sont des sujets de recherches actifs) ?

(PS : Langage, pas language en anglais où il y a confusion entre langue et langage)

(je ne suis pas sûr qu'il puisse exister une équivalence : on peut aller de l'un à l'autre mais pas de l'autre à l'un a priori - par analogie, un décompilateur peut produire un source à partir du code machine, mais la sémantique des variables est perdue, par exemple)

On en est loin mais pas pour tout. Et Eth est justement l'occasion de mettre en pratique, ou au moins d'apporter un peu de formalisme, d'essayer. Pour le moment, ce n'est pas le cas, et ça n'en prend pas le chemin.

Lien vers le commentaire

Oui enfin les langages formels c'est bien pour des projets critiques qui ont des cycles de développement étalés sur des années, mais pour de la R&D sur Blockchain c'est pas franchement adapté. Rien que le coût est prohibitif, et ne parlons même pas des compétences disponibles sur le marché...

 

Mais bon, si au lieu de réinventer la roue pour Ethereum ils utilisaient un langage statiquement compilé et des techniques d'ingénierie logicielle prouvées, ça serait "good enough": on ne parle pas d'écrire un autopilote d'avion de ligne, c'est juste des programmes dans une blockchain.

Lien vers le commentaire

j'ai toujours été clair que la discussion portait sur la vérification formelle

 

Je répondais à un message que tu commencais par "De façon générale, si on veut avoir confiance dans les smartcontracts". Le sujet était ouvert donc c'était inutile de flinguer. Un peu de retenue.

 

 

la validation ne correspond pas non plus à ce que tu présentes.

 

A aucun moment je n'ai parlé de validation ni écris ce mot une seule fois. Facile de créer une erreur de toute pièce et de la faire porter par un autre.

 

 

La mauvaise foi, ça va deux minutes.

 

Quel toupet.

 

 

Non toujours pas. Tu peux obtenir des résultats corrects avec cette méthode, ils seront toujours inférieurs à la vérification formelle

 

Là encore tu fais une mauvaise lecture car mon propos n'était pas de dire que les bug bouties programs sont meilleurs que la vérification formelle. Le sujet portait sur les façons de mieux sécuriser les smart contract et le bug bounty, même s'il n'est pas parfait, en fait parti. Mon message était donc pertinent et il n'était pas en opposition avec le tien. Inutile de mettre systématiquement les idées en compétition les unes avec les autres lorsque c'est pas nécessaire.

 

 

Lien vers le commentaire

Oui enfin les langages formels c'est bien pour des projets critiques qui ont des cycles de développement étalés sur des années, mais pour de la R&D sur Blockchain c'est pas franchement adapté. Rien que le coût est prohibitif, et ne parlons même pas des compétences disponibles sur le marché...

Oui, c'est bien sûr le principal obstacle. Cependant, si les blockchains sont amenées à gérer des montants de plus en plus gros, et laissent aux acteurs la possibilité d'exécuter du code, le rapport coût/bénéfice sera rapidement en faveur de la montée en puissance de ces solutions.

Mais bon, si au lieu de réinventer la roue pour Ethereum ils utilisaient un langage statiquement compilé et des techniques d'ingénierie logicielle prouvées, ça serait "good enough": on ne parle pas d'écrire un autopilote d'avion de ligne, c'est juste des programmes dans une blockchain.

Ben c'est comme tout : tant qu'on parle en millions de dollars, ça passe encore et effectivement, les techniques prouvées seront "good enough". Si, un jour, les blockchains gèrent l'argent d'un peu tout le monde (ce que je souhaite et ce qui me semble réaliste), on parlera en trillions, et rapidement, la criticité du système sera supérieure ou égale à celle d'un autopilote d'avion de ligne.
Lien vers le commentaire

Quel toupet.

Je ne t'ai pas pris en traitre. 4 fois j'ai clairement expliqué de quoi je parlais. Et le toupet, c'est de ne même pas admettre ça, alors que j'ai tout cité pour qu'il n'y ait pas de doute.
Lien vers le commentaire

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...