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

guilder-test

#1

traduit avec DeepL

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 ?


Duniter pour une nouvelle monnaie
#2

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.


#3

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 :wink:


#4

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à. :slight_smile:


#5

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


#6

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.


#7

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


#8

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


#9

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


#10

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.


#11

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.


#12

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


#13

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

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)


#14

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

#15

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.


#16

Je n’aurais pas mieux répondu. :slight_smile:

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.


#17

Little indian or big indian ?


#18

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.


#19

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.


#20

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