Bloc résolution: Zéro bloc potentiel après bloc zéro

Folaht · 11 April 2018 12:21

J’ai créé le bloc zéro:

admin@Gildurklaus:/var/lib/duniter/.config/duniter/duniter_default$ sudo sqlite3 duniter.db
SQLite version 3.8.7.1 2014-10-29 13:59:56
Enter ".help" for usage hints.
sqlite> INSERT INTO block VALUES (0, "", "cf4c4fcad8be6f362ef5e307fd5894df022a00cb8fcb95a6bd7efd5812c24b72", "", "guilder-test", "4FE3bGwDNwsjLzAKF7f87NCEnwgKqTipH4tgK8HuXEwR", "0.000054218:86400:100:0:300000:604800:604800:0.9:35136000:3:20:960:10:0.6666666666666666:1489675722:1489675722:2629800",  NULL, NULL, 10, 1, 0, NULL, 1523173253, NULL, 0, 1523173253, 0, 0, 0, '[]', '[]', '[]', '[]', '[]', '[]', '[]', '[]', NULL, NULL, 0, 0, 0, 0);
sqlite>

Et lancé Duniter:

admin@Gildurklaus:/var/lib/duniter/.config/duniter/duniter_default$ sudo su -c "/bin/bash /usr/bin/duniter direct_start --home /var/lib/duniter/.config/duniter --mdb duniter_default" -s/bin/sh duniter
2018-04-11T04:51:16+02:00 - debug: Plugging file system...
2018-04-11T04:51:17+02:00 - debug: Loading conf...
2018-04-11T04:51:17+02:00 - debug: Configuration saved.
2018-04-11T04:51:17+02:00 - debug: Opening SQLite database "/var/lib/duniter/.config/duniter/duniter_default/duniter.db"...
2018-04-11T04:51:17+02:00 - debug: Upgrade database...
2018-04-11T04:51:17+02:00 - info: Block resolution: 0 potential blocks after current#0...
2018-04-11T04:51:17+02:00 - info: >> Server starting...
2018-04-11T04:51:17+02:00 - info: NodeJS version: v9.4.0
2018-04-11T04:51:17+02:00 - info: Node version: 1.6.22
2018-04-11T04:51:17+02:00 - info: Node pubkey: 4FE3bGwDNwsjLzAKF7f87NCEnwgKqTipH4tgK8HuXEwR
2018-04-11T04:51:18+02:00 - info: Duniter server listening on http://[2001:983:8610:1:8a:4ff:fec2:a55a]:10901
2018-04-11T04:51:18+02:00 - warn: Local node is not a member. Waiting to be a member before computing a block.
2018-04-11T04:51:18+02:00 - info: Sibling endpoints:
2018-04-11T04:51:18+02:00 - info: BMA access: 2001:983:8610:1:8a:4ff:fec2:a55a:10901
2018-04-11T04:51:18+02:00 - debug: Generating server's peering entry based on block#0...
2018-04-11T04:51:18+02:00 - error:  httpCode=400, ucode=2023, message=Peer document already known
2018-04-11T04:51:18+02:00 - info: Next peering signal in 31 min
2018-04-11T04:51:19+02:00 - info: >> Server ready!
2018-04-11T04:51:19+02:00 - info: Block resolution: 0 potential blocks after current#0...

Ai-je créé le bloc zéro correctement ?
Comment créer le bloc suivant ?

Moul · 11 April 2018 12:28

You need requirements to be a member at block n°0: certifications from other identities and a membership document.
Also, your node should contains your member’s credentials to generate next block.

1000i100 · 11 April 2018 15:11

Si tu arrive à lancer techniquement une nouvelle monnaie avec duniter, je serais très très intéressé que du document ce que tu as fait

Folaht · 19 April 2018 06:22

Avec l’information actuelle, je ne sais pas si cela sera possible.
Je ne sais même pas comment BLOCK_UID est généré.
Le document dit: BLOCK_ID-HASH, mais oui, hash de quoi ?

[mise-à-jour]

SHA1 Hash de référence temporelle, mais de quoi ?
Je me rapproche déjà.

nanocryk · 20 April 2018 07:11

C’est le hash des données du bloc.

Folaht · 20 April 2018 08:55

Comment cela est-il possible si le document de bloc contient le BLOCK_UID ?

Je soupçonne que je dois crypter “0”, “Time : 0\n”, “MedianTime : 0\n” avec SHA1.
Peut-être découvrira-t-il assez vite en essayant les données VALID_ROOT et
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
…
Eh? Ça fait 64 caractères.
Le blochash dans le document d’identité en a 40, SHA1, mais joiners et identities dans VALID_ROOT utilisent SHA256.
Je m’embrouille.

nanocryk · 20 April 2018 11:27

Le document de block ne contient pas son propre BLOCK_UID, mais contient par contre celui de son prédécesseur.

Folaht · 23 April 2018 09:05

Le document de bloc zéro n’a pas de prédécesseur.

Inso · 23 April 2018 09:21

Il faut inscrire le hash d’une chaine vide comme prédédecesseur

Galuel · 23 April 2018 11:13

Ce qui signifie bien qu’il existe un prédécesseur au zéro, c’est bien le vide ! Il faut revoir tout le fondement des nombres entiers.

cgeek · 23 April 2018 11:27

Bien tenté, mais il semble que non : https://g1.duniter.org/blockchain/block/0

Par contre les documents (identité, certification, adhésion) ont bien l’empreinte dont tu parles. Elle est par ailleurs indiquée dans le protocole.

1000i100 · 23 April 2018 23:26

https://g1.duniter.org/blockchain/block/0

sujet	base	donnée
issuer	b58	“2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ”
signature	b64	“49OD/8pj0bU0Lg6HB4p+5TOcRbgtj8Ubxmhen4IbOXM+g33V/I56GfF+QbD9U138Ek04E9o0lSjaDIVI/BrkCw==”
hash	b16	“000003D02B95D3296A4F06DBAC51775C4336A4DC09D0E958DC40033BE7E20F3D”

Pourquoi tant de haine ? 3 lignes, 3 bases différentes

elois · 24 April 2018 00:02

C’est écris dans le protocole, on s’y habitue vite, c’est toujours la meme base pour chaque type de données

Les hashs sont toujours en base 16, les clés publiques toujours en base58 et les signatures toujours en base 64 ^^

Quand aux choix , on pourrait effectivement passer aussi les hashs en base 64, pour les clés en base58 c’est une base qui a été étudiée pour que ce soit saisisable par un humain, donc qui exclue les caractères qui se ressembles trop (0 et O, I et l, etc)

1000i100 · 24 April 2018 03:13

Je conçois qu’on s’y habitue… mais ça ne change pas mon sentiment…

Maintenant que j’ai compris l’intérêt de la base58, j’aurais tendance à mettre tout en b58, voir en b55, mais pas b16/hex !

const b58Alphabet =         '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz';
const disambiguishAlphabet = '23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz'; // retiré 1 i o -> b55

nanocryk · 24 April 2018 07:43

Il est utile de mettre en base58/55 uniquement les informations qui sont manipulés directements par les utilisateurs, soit les clés publiques. Les hashs ou les signatures ne sont jamais manipulés. Vu que les documents sont au format texte, utiliser la base58 au lieu de la base64 prend plus de place. Quand aux hashs en base16, les caractères sont directements utilisés pour la preuve de travail.

Enfin, vu que les documents sont signés dans ce format texte, il n’est pas pas possible de changer les formats des documents, les signatures n’étant alors plus valides.

cgeek · 24 April 2018 10:19

Je n’aurais pas mieux répondu.

En tous les cas, il n’y aura plus d’encodage quand les documents passeront au format binaire, sauf pour de l’affichage qui sera laissé à l’appréciation des clients.

gerard94 · 24 April 2018 11:01

Little indian or big indian ?

gerard94 · 24 April 2018 11:07

Bon, je chipote. Mais il y a toujours un encodage. 32, 64, 128 bits, etc… Il y a des standards pour éviter de s’emmêler les pinceaux, mais ils sont arbitraires.

cgeek · 24 April 2018 11:13

A priori big-endian, pour des raisons de simplicité.

J’aimerais notamment suivre les conseils de @nanocryk a propos du padding qui me semble intéressant et pas trop cher à gérer. Et si vous avez d’autres conseils je suis preneur.

nanocryk · 24 April 2018 11:31

En faisait attention à ce que les différents logiciels soit compatibles entre eux Si chaque logiciel à sa façon de formater une clé publique sans gérer celle des autres, ça pose des problèmes.