Prefix DisplayName Authors BitcoinAddress SpecificationUrl TxidRedirectUrl
0x005171C0
(C convention)
appears as 0xC0715100
Silico Signing Protocol Jérôme Hauss, Sébastien Madani, Michel Fages bitcoincash:qzlaquymmc65l74dee3ezm5rxslht8lync26n3q9sk https://silico.fr/blockchain/bch/silico_signing_protocol.html or https://silico.fr/blockchain/bch/silico_signing_protocol.md

We wish to thank Joannes Vermorel for his kind support and advices when designing this protocol.

Nous tenons à remercier Joannes Vermorel pour son aide et ses conseils lors de la conception de ce protocole.

(en) Silico Signing Protocol

Silico Signing Protocol proposes an easy format for storing lifelong hashes of documents (not documents themselves) in the Bitcoin Cash blockchain, thus creating a proof that a document existed at the time its signature was stored in a transaction in a block. The original (untouched) digital document has to be stored elsewhere so that the owner can perform the proof when required.

Silico Signing Protocol complies with the Lokad 4-byte prefix guideline for OP_RETURN on Bitcoin Cash specification. Protocol ID is 0x005171C0 (in C convention)

OP_RETURN operations will be formatted as 0x6a 0x04 [0x005171C0] {action}{arguments/payload} where 0x6a encodes for OP_RETURN, 0x04 stands for Lokad 4-byte prefix (also sends next 4 bytes onto the stack), 0x005171C0 is the Protocol ID. Remember the different parts of this data prefix are little endian encoded, so the bytes from the script will appear as {0x6a 0x04 0xC0 0x71 0x51 0x00}. The {action} is one of [OP_1, OP_2, OP_10, OP_16] codes.

The complete lengh of the OP_RETURN operation MUST NOT exceed the capacity defined in the blockchain specifications (as of today it is 223 bytes, so max length for "{action}{argument/payload}" is 217 bytes)

Given a Bitcoin Cash address, only OP_RETURN operations in transactions from this address are considered, relative to the Silico Signing Protocol: in each transaction there SHOULD be only one TxIn entry with an OutPoint from a unique UTXO with that address (UTXO: unspent transaction output). If there are multiple TxIn records, only the first one at index 0 is considered. Destination addresses that could exist in the TxOut transaction part are not meaningful.

 

List of actions, with arguments/payload :

  • OP_1 OP_PUSHDATA [hash] OP_PUSHDATA [size]
    ⇨ 0x51 0x20 [hash] 0x08 [size]
    e.g. c2253a40f550ad019b68d8e36c9f99e76d46072351095309e74f0e1f0e8397c5 or see hex (note the hash 00000000000000000123456789ABCDEF00112233445566778899AABBCCDDEEFF was pushed in little endian internal format, and hypothetical size was 54654812649 bytes=0x0000000cb9ae41e9)

    "Just a hash, and size of the source file" (added size, advised by Joannes Vermorel, see https://en.wikipedia.org/wiki/Zip_bomb and https://blog.vermorel.com/journal/2019/1/10/metadata-subtree-for-bitcoin.html )

    • hash: the SHA-256 of the document (considered as array of 32 bytes, internal format)
    • size: size of the document, hex encoded 8-byte unsigned integer in little endian format
  • OP_2 OP_PUSHDATA [index] OP_PUSHDATA [hash] OP_PUSHDATA [length]
    ⇨ 0x52 0x04 [index] 0x20 [hash] 0x08 [size]
    e.g. 35c1be8058c8cf03c261c3ad0303ab5c7ebd8d38f44c12b439c6c74b3542edb0 or see hex (same hash and size as previous example, index was 15=0x0000000f)

    "A hash with an index for ordering"

    • index: hex encoded 4-byte unsigned integer in little endian format This is for signing successive documents and ensuring the order can be rebuilt, in case some later transaction would land in a block before a preceding transaction. Indexes of signatures from a Bitcoin Cash address SHOULD form a sequence without holes. No special meaning is given to repeated indexes
    • hash: the SHA-256 of the document (considered as array of 32 bytes, internal format)
    • size: size of the document, hex encoded 8-byte unsigned integer in little endian format
  • OP_10 OP_PUSHDATA [owner]
    ⇨ 0x5a … rest is same as script conversion for OP_RETURN's OP_PUSHDATA, e.g. {size-push 0x01-0x4b}[string] if string size between 1 and 75 bytes, or {0x4c=OP_PUSHDATA1}[1-byte string size][string] if string is 76 bytes long or more1
    e.g. 965adc37665924847114960244208ed6bec7448c97b3ffb6861383038011fec1 or see hex

    "Here we claim who is the owner of hashes from the address"

    • owner: UTF-8 encoded string with public data (e.g. URL to a public pdf document signed with high level certs, that asserts some public piece of information about the owner of the public address used for signing, or the role he is allowed to play here)
  • OP_16 OP_PUSHDATA [any string]
    ⇨ 0x60 … rest is same as script conversion as for OP_RETURN's OP_PUSHDATA…
    e.g. 71538752d745b957352f262594572c1f3bb523544b7bde4833a24357e579a173 or see hex

    • any string: just raw data in case we need it, preferably UTF-8 string

(fr) Protocole de Signature Silico

Le Protocole de Signature Silico propose un format très simple pour stocker de façon pérenne des codes Hash de documents (pas les documents eux-mêmes) dans la blockchain Bitcoin Cash, créant de fait une preuve qu'un document donné existait à la date où sa signature a été stockée dans une transaction dans un bloc. Le document électronique original (non "touché") devra être conservé ailleurs, afin que son propriétaire puisse exécuter la preuve sur demande.

Le Protocole de Signature Silico suit la spécification Lokad 4-byte prefix guideline for OP_RETURN on Bitcoin Cash. L'identifiant du protocole est 0x005171C0 (notation en convention langage C).

Les opérations OP_RETURN seront formatées en {0x6a}{0x04}[0x005171C0]{action}{arguments/contenu} où 0x6a est le code de l'opération OP_RETURN, 0x04 signale la spécification "Lokad 4-byte" (et pousse les 4 octets suivants sur la pile), 0x005171C0 est l'identifiant du protocole. Rappelons que les différentes parties du préfixe sont encodées sous forme "little endian" ; les octets générés depuis le script apparaîtront sous forme {0x6a 0x04 0xC0 0x71 0x51 0x00}. L'{action} est l'un des codes [OP_1, OP_2, OP_10, OP_16]

La longueur totale de l'opération OP_RETURN ne DOIT PAS excéder la capacité définie dans la spécification de la blockchain (aujourd'hui c'est 223 octets, donc la longueur maximale pour la partie {action}{arguments/contenu} est de 217 octets).

Pour une adresse Bitcoin Cash, seules les opérations OP_RETURN des transactions à partir de cette adresse sont considérées, relativement au Protocole de Signature Silico : dans chaque transaction examinée, il DEVRAIT y avoir une seule occurrence TxIn avec un OutPoint (point de sortie) sur une UTXO pour cette adresse [UTXO: "unspent transaction output", transaction de sortie non dépensée]. S'il y a plusieurs entrées dans TxIn, seule la première occurrence, à l'index 0, sera prise en compte. Les adresses de destination qui pourraient exister en TxOut ne sont pas significatives.

 

Liste des actions, aver leurs arguments/contenu :

  • OP_1 OP_PUSHDATA [hash] OP_PUSHDATA [taille]
    ⇨ 0x51 0x20 [hash] 0x08 [taille]
    ex. c2253a40f550ad019b68d8e36c9f99e76d46072351095309e74f0e1f0e8397c5 ou voir hex (noter que le hash 00000000000000000123456789ABCDEF00112233445566778899AABBCCDDEEFF a été poussé en format interne "little endian", et la taille supposée du fichier était de 54654812649 octets=0x0000000cb9ae41e9)

    "Juste un hash, avec la taille du fichier source" (taille ajoutée, conseillée par Joannes Vermorel, voir https://en.wikipedia.org/wiki/Zip_bomb – et https://blog.vermorel.com/journal/2019/1/10/metadata-subtree-for-bitcoin.html -)

    • hash: hash SHA-256 du document (considéré comme un tableau de 32 octets, notation interne)
    • taille: taille du document, hexadécimal 8 octets non signé en format "little endian"
  • OP_2 OP_PUSHDATA [index] OP_PUSHDATA [hash] OP_PUSHDATA [taille]
    ⇨ 0x52 0x04 [index] 0x20 [hash] 0x08 [taille]
    ex. 35c1be8058c8cf03c261c3ad0303ab5c7ebd8d38f44c12b439c6c74b3542edb0 ou voir hex (mêmes hash et taille qu'au précédent exemple, l'index était 15=0x0000000f)

    "Un hash, avec un index pour ordonner les signatures"

    • index: entier 4 octets non signé encodé en hexadécimal, au format "little endian" Ceci est destiné à des signatures successives de documents pour pouvoir reconstruire l'ordre d'apparition, dans le cas où une transaction ultérieure serait incluse dans un bloc avant une transaction précédente. Les index des signatures doivent former une séquence sans trous. Aucune signification n'est attribuée à des index qui se répèteraient.
    • hash: hash SHA-256 du document (considéré comme un tableau de 32 octets, notation interne)
    • taille: taille du document, hexadécimal 8 octets non signé en format "little endian"
  • OP_10 OP_PUSHDATA [propriétaire]
    ⇨ 0x5a … le reste est constitué par la même conversion des OP_PUSHDATA d'une opération OP_RETURN brute, par exemple {taille-push 0x01-0x4b}[chaîne] si sa taille est comprise entre 1 et 75 octets, ou bien {0x4c=OP_PUSHDATA1}[1 octet, taille de la chaîne de caractères][chaîne] si sa longueur est supérieure ou égale à 76 octets2
    ex. 965adc37665924847114960244208ed6bec7448c97b3ffb6861383038011fec1 ou voir hex

    "Ici nous déclarons des informations quant au propriétaire de l'adresse Bitcoin Cash"

    • propriétaire: chaîne de caractères encodée en UTF-8 (par exemple une URL vers un document pdf signé avec un certificat de haut niveau, pour établir l'authenticité de certaines informations publiques concernant le propriétaire de l'adresse utilisée pour les signatures, ou le rôle pour lequel il est habilité à agir ici…)
  • OP_16 OP_PUSHDATA [info]
    ⇨ 0x60 … le reste est constitué par la même conversion des OP_PUSHDATA d'une opération OP_RETURN brute
    ex. 71538752d745b957352f262594572c1f3bb523544b7bde4833a24357e579a173 ou voir hex

    • info: des données brutes si besoin, de préférence une chaîne de caractères en UTF-8
1 This is a sum up, the algorithm has more cases
2 Ici c'est résumé, l'algorithme contient plus de cas

Passionnés par le code, développeurs d’applications dans l’âme, les deux fondateurs de SILICO réussissent une première expérience dans l’entrepreneuriat en créant une SSII Lyonnaise devenue une référence nationale dans son périmètre technologique.

Cette aventure, démarrée à trois (dans un garage) en 2010, se poursuivra jusqu’en janvier 2017, date à laquelle ils cèdent leur société (avec un effectif de 43 personnes) pour se lancer dans leur nouveau projet, SILICO.

Julien (directeur technique), entre au capital de la société en Novembre 2017 et apporte dans sa besace de nombreuses compétences, notamment la maîtrise des services Amazon (AWS) qui permettent à SILICO de proposer une nouvelle gamme de prestation (Architecte Cloud AMAZON AWS, DOCKER, IoT, Serverless, etc…).

Emilie, fraîchement embarquée dans la team, anime la force commerciale. Ses nombreuses qualités (bienveillance, disponibilité, empathie, sans oublier son efficacité) sont un atout certain pour SILICO.

En complément de ses services de développement et d’architecture, SILICO distribue et intègre une solution de GED, DOCUWARE, autour de laquelle elle est capable de développer des passerelles spécifiques pour archiver et indexer les documents en provenance d’applications tierces.

Portée par une croissance annuelle de 60%, SILICO compte aujourd’hui une vingtaine de collaborateurs, tous accros aux nouvelles technos !

Notre Histoire...

Passionnés par le code (on ne parle pas de pénal mais de bytes), développeurs d’applications dans l’âme, les deux fondateurs de SILICO, Michel et Sébastien, réussissent une première expérience dans l’entrepreneuriat en créant la SSII Lyonnaise INFOGONES.

Cette aventure, démarrée à trois (dans un garage) en 2010, se poursuivra jusqu’en janvier 2017, date à laquelle ils cèdent leur société (avec un effectif de 43 personnes) pour se lancer dans leur nouveau projet, SILICO.

Julien entre au capital de la société en Novembre 2017 et apporte dans sa besace de nombreuses compétences, notamment la maîtrise des services Amazon (AWS) qui permettent à SILICO de proposer une nouvelle gamme de prestation (Architecte Cloud AMAZON AWS, DOCKER, IoT, etc…).

Emilie, fraîchement embarquée dans la team, anime la force commerciale. Ses nombreuses qualités (bienveillance, disponibilité, empathie, sans oublier son efficacité) sont un atout certain pour SILICO.

En complément de ses services de développement et d’architecture, SILICO distribue et intègre une solution de GED, DOCUWARE, autour de laquelle elle est capable de développer des passerelles spécifiques pour archiver et indexer les documents en provenance d’applications tierces.

Portée par une croissance annuelle de 60%, SILICO compte aujourd’hui une vingtaine de collaborateurs, tous accros aux nouvelles technos !