Wiki di ZooBC
Integrazioni

Messaggi firmati e cifrati

Non tutte le firme richiedono una transazione. Un messaggio firmato dimostra che possiedi una chiave senza spostare denaro e senza pagare una commissione; un messaggio cifrato può essere letto solo dal suo destinatario. Questa pagina tratta entrambi, e due firme collegate che l'API del nodo accetta.

Dimostrare di controllare un indirizzo

Un sito web che vuole sapere se controlli un indirizzo ZooBC ti invia una sfida casuale. Tu la firmi con zbc-cli sign-message, o con la stessa funzione in qualsiasi versione degli strumenti da riga di comando pubblici, e il sito verifica la firma rispetto al tuo indirizzo. Per un indirizzo nativo ZBC_ l'indirizzo è la chiave pubblica stessa, quindi non serve altro. Anche inviare un pagamento dimostrerebbe il controllo, ma si tratta di una transazione e costa una commissione. Non dare mai a nessuno, in alternativa, la tua chiave privata.

Lo schema si chiama ZBC-MSG-v2. Firma, con Ed25519:

SHA3-256("ZBC-MSG-v2" ‖ genesis hash ‖ message)

Due parti di quel digest contano:

  • Il tag. Le transazioni sono firmate con un tag diverso, «ZBC-TX». La firma di un messaggio non può quindi mai valere come transazione, e la firma di una transazione mai come messaggio.
  • L'hash genesi. Lega la firma a una sola rete: un messaggio firmato per devnet non risulta mai valido su testnet o mainnet (firme legate alla catena).

Per un periodo di transizione, il comando verify-message degli strumenti accetta anche la forma più vecchia senza catena, ZBC-MSG-v1 (lo SHA3-256 di «ZBC-MSG» e del messaggio). Il periodo termina a un momento limite fissato negli strumenti; dopo, si verifica solo la forma ZBC-MSG-v2.

Il tag ZBC-MSG-v2, l'hash genesi e il messaggio vengono sottoposti a hash con SHA3-256 e firmati con Ed25519, poi verificati rispetto all'indirizzo ZBC_; i tag ZBC-TX e ZBC-MSG-v2 non sono mai intercambiabili
Il tag ZBC-MSG-v2, l'hash genesi e il messaggio vengono sottoposti a hash con SHA3-256 e firmati con Ed25519, poi verificati rispetto all'indirizzo ZBC_; i tag ZBC-TX e ZBC-MSG-v2 non sono mai intercambiabili

La firma dei messaggi è una convenzione degli strumenti pubblici e dei servizi che la adottano, non una funzione della catena. Nulla viene memorizzato sulla catena, e i nodi non hanno alcun endpoint per essa.

Messaggi cifrati

Ogni transazione può contenere un messaggio (involucro della transazione). Un messaggio in chiaro è di al massimo 256 byte. Uno cifrato inizia con il marcatore «ZBE1», seguito da una sealed box di libsodium indirizzata alla chiave del destinatario, che solo la chiave privata del destinatario può aprire. Un messaggio cifrato può essere di fino a 320 byte, il che lascia spazio per al massimo 268 byte di testo.

Solo il messaggio è cifrato. Il resto della transazione, come mittente, destinatario e importo, resta pubblico come qualsiasi altra.

Richieste firmate all'API

La maggior parte dell'API del nodo consiste in letture aperte, e una transazione non ha bisogno di una chiave API perché porta con sé la propria firma. Dove è la richiesta stessa a dover essere firmata, la firma è Ed25519 sul testo METHOD:PATH:TIMESTAMP:BODY, valida per 300 secondi. Un client che fallisce 20 autenticazioni firmate in 5 minuti viene bloccato per 300 secondi.

Annullare una transazione in sospeso

Una transazione in attesa nel pool di un nodo può essere ritirata da quel nodo con DELETE /api/v1/transactions/pending/ seguito dal suo hash. La richiesta contiene una firma su:

SHA3-256("ZBC-CANCEL" ‖ genesis hash ‖ transaction hash)

Rimuove la copia solo dal pool di quel nodo. Altri nodi che detengono già la transazione possono comunque includerla in un blocco, quindi un annullamento è una richiesta, non una garanzia.

Vedi anche