transazione bitcoin

Tutti i dati utili per sapere tecnicamente come funziona una transazioneApprofondimento sulle Transazioni Bitcoin

Questo spiegone sulle transazioni Bitcoin riprende quanto scritto nella developer guide di Bitcoin, presente qui.

L’obiettivo è approfondire sulla struttura, gli obiettivi ed altre funzionalità delle transazioni Bitcoin per chiunque fosse interessato a comprendere a fondo il funzionamento del protocollo Bitcoin.

Gli obiettivi delle Transazioni Bitcoin

Le transazioni Bitcoin forniscono agli utenti la possibilità di spendere satoshi— una sotto unità di bitcoin, che può essere paragonata ai centesimi di Euro. Ogni transazione è composta da diversi elementi, che danno la possibilità di poter svolgere a parimenti transazioni semplici e più complesse, a seconda delle esigenze.

Ogni nodo nel network Bitcoin dovrebbe essere in grado di trasmettere le transazioni nel network e farle minare in un blocco.
Inoltre, ogni nodo dovrebbe essere in grado di controllare se:

(1) Il denaro speso nella transazione esiste realmente;

(2) Il denaro è già stato utilizzato (problema del double-spending);

(3) Chi spende il denaro ha effettivamente i diritti per poterlo fare;

L’idea generale delle transazioni nel network Bitcoin è quella di inviare degli Input che vanno a spendere degli Output. Ogni transazione ha quindi almeno un Input ed un Output. Ogni Input spende un Output precedente.

Ogni Output è quindi in una specie di sala d’attesa (e prende il nome di Output Non Speso- Unspent Output), finchè un successivo Input non lo “spende”.

Ogni transazione ha come prefisso il numero della versione, che ha lo scopo di indicare agli altri peers ed ai miners il corretto insieme di regole da usare per validarla. Questo da la possibilità agli sviluppatori di poter creare nuove regole senza invalidare le transazioni precedenti.

Ogni Output ha un numero di Indice (Output Index) basato sul suo posto nella transazione — il primo Output avrà quindi come Indice zero, il secondo uno e così via. Inoltre, nell’output è presente la quantità di satoshi, che viene pagata ad una chiave pubblica che conferma le condizioni di spesa specificate — PubKey Script.

D’altro canto, un Input utilizza un numero di identificazione della transazione (Transaction Identifier — TxId) ed un numero di Indice dell’Output, che serve ad identificare precisamente quale Output debba essere speso. Inoltre, nell’Input è presente un Signature Script (Script di Firma) all’interno del quale sono contenute informazioni e parametri che debbono soddisfare le condizioni di spesa indicate nel PubKey Script.

Fonte: Bitcoin developer guide

La figura qui sopra illustra come questi diversi elementi vengono utilizzati, mostrando il processo tramite il quale Alice invia una transazione a Bob,che successivamente la spende. Entrambi useranno il formato di transazione più comune, chiamato Pay-To-Public-Key-Hash (P2PKH).

Questo sistema utilizza una tecnica crittografica basata su un paio di chiavi, la chiave pubblica (public key) e la chiave privata (private key). La chiave pubblica è da intendere come un indirizzo e-mail e viene quindi condivisa per indicare l’indirizzo dove si vuole ricevere le transazioni, mentre la chiave privata è da intendere come una password e deve quindi rimanere segreta, pena la perdita dei fondi contenuti all’interno.

Per creare la prima transazione, Bob deve quindi generate un paio di chiavi pubblica/privata. Bitcoin utilizza l’algoritmo ECDSA (una firma digitale che risulta dalla selezione di specifici punti su una curva ellittica) con la curva secp256k1. Una copia di queste informazioni è quindi trasformata deterministicamente in una chiave pubblica secp256k1.

Tramite l’utilizzo di una tecnica crittografia chiamata hashingla chiave pubblica (PubKey) è quindi “offuscata” e trasformata in una stringaalfanumerica univoca. Il processo di hashing è unidirezionalenon è mai possibile eseuire l’operazione al contrario per derivare la chiave privata di Bob.

Esempio di hashing:

 

Bob invia quindi l’hash della sua chiave pubblica ad Alice, sotto forma di un indirizzo Bitcoin.

Una volta ricevuto l’hash della chiave pubblica di Bob, Alice utilizza l’hash per creare la sua prima transazione. Viene quindi creato un Output P2PKH standard, indicando le istruzioni che danno la possibilità a chiunque di spendere l’output nel caso in cui controllino la chiave private corrispondente all’hash della chiave pubblica fornita da Bob.
Queste istruzioni sono contenute nel PubKey Script.

Alice trasmette quindi la transazione sulla blockchain; il network la categorizza come un Output Non Speso e il wallet di Bob come saldo spendibile.

Successivamente, nel caso in cui Bob decidesse di spendere l’Output Non Speso, egli dovrà creare un input che abbia come referenza l’hash della transazione precedentemente create da Alice — chiamato TxID — e l’Indice dell’Ouput, per poterlo identificare con precisione. Inoltre, Bob dovrà creare un Signature Script — una collezione di parametri che soddisfino le condizioni evidenziate da Alice nel precedente PubKey Script.
La combinazione di PubKey Script e Signature Script crea quindi dei meccanismi di autorizzazione programmabili, un vero e proprio smart contract.

Per un Output P2PKH, il Signature Script di Bob dovrà quindi contenere le seguenti informazioni:

1. La propria chiave pubblica (senza hash), in modo tale che lo Script PubKey possa controllare che, una volta calcolatone l’hash, abbia effettivamente lo stesso valore dell’hash fornito da Alice — PubKey hash.

1. La propria chiave pubblica (senza hash), in modo tale che lo Script PubKey possa controllare che, una volta calcolatone l’hash, abbia effettivamente lo stesso valore dell’hash fornito da Alice — PubKey hash.

2. Una firma secp256k1 creata utilizzando la formula crittografica ECDSA,che combina alcune informazioni della transazione con la chiave private di Bob.Questo permette allo Script PubKey di verificare che Bob è effettivamente il proprietario della chiave privata dalla quale è stata derivata la chiave pubblica usata.

Fonte: Bitcoin developer guide

Come illustrato nella figura qui sopra, le informazioni che vengono firmate da Bob includono:

1. Il TxId e l’Indice Output della transazione precedente;

2. Lo Script PubKey dell’Output precedente;

3. Un nuovo PubKey Script creato da Bob, che permetterà al prossimo utente al quale verrà inviata la transazione di poterla spendere;

4. Una quantità di satoshi da spendere;

Una volta inserita la propria Firma Digitale e la propria chiave pubblicanello scriptSig, Bob trasmetterà quindi la transazione ai miners Bitcoin, tramite il network peer-to-peer. Ogni peer e miner validerà indipendentemente la transazione, prima di includerla in un nuovo blocco di transazioni.

Il Linguaggio di Scripting Bitcoin

Il linguaggio di script utilizzato da Bitcoin è un linguaggio apolide simile a Forth, ed è stato specificamente sviluppato per non essere Turing-complete— questo rende il linguaggio meno flessibile e più prevedibile, semplificando di gran lunga il modello di sicurezza. Inoltre, è basato su un sistema di “stack”(da immaginare come una pila): due stack possono essere usati per manipolare le informazioni.

Il fatto che sia apolide garantisce che una volta che una transazione viene trasmessa sulla blockchain non ci sono condizioni che la possano rendere permanentemente non spendibile.

Nel linguaggio Bitcoin, sia gli Input che gli Output includono uno script (Signature Script negli Inputs, PubKey Script negli Outputs).

Validazione di uno Script P2PKH

La procedura di validazione richiede l’esecuzione del Signature Script e del PubKey Script. In un Output P2PKH lo Script PubKey è il seguente:

OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

Il Signature Script di colui che spende è inserito all’inizio dello script.

In una transazione P2PKH il Signature Script è il seguente:

<Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

Fonte: Bitcoin developer guide

L’immagina va letta da sinistra verso destra; gli elementi in alto vengono disposti sulla “pila” in ordine, eseguendo gli script e controllando le condizioni di spesa.

.Il primo elemento che viene aggiungo è Sig (il Signature Script di Bob). Anche la chiave pubblica di Bob viene inserita in cima alla pila.

.Dallo Script PubKey di Alice, l’operazione OP_DUP viene eseguita.
Questo comando duplica l’informazione correntemente in cima alla pila
 in questo caso creando una copia della chiave pubblica fornita da Bob.

.L’operazione che viene eseguita successivamente è OP_HASH160 che immette sulla pila l’hash dell’ultima informazione in cima — in questo caso la chiave pubblica di Bob, creandone un hash.

.Successivamente, dallo Script PubKey di Alice, viene inserito l’hash della chiave pubblica di Bob che egli aveva fornito per la prima transazione.
A questo punto vi dovrebbero essere due copie dell’hash della chiave pubblica di Bob in cima alla pila;

.L’operazione OP_EQUALVERIFYviene quindi eseguita, con un duplice scopo. #1: controlla se i due valori in cima alla pila siano uguali, ritornando “true” or “false”  vero o falso. #2: verifica il valore in cima alla pila, nel caso in cui sia vero, rimuove i valori dalla pila.

.Infine, lo Script PubKey di Alice eseguirà l’operazione OP_CHECKSIG, che controlla se la firma fornita da Bob equivale alla chiave pubblica da egli fornita. Nel caso in cui si equivalgano, ritornerà il valore “True”.

Nel caso in cui “False” non sia in cima alla pila, la transazione verrà effettivamente considerata valida.



Gli Script P2SH

Gli Script PubKey sono creati da chi spende la transazione, avendo quindi poco interesse nel funzionamento dello script. D’altro canto, chi riceve ha molto interesse nel corretto funzionamento dello script e potrebbero richiedere l’utilizzo di particolari Script PubKey. Tuttavia, l’utilizzo di script personalizzati è molto sconveniente su Bitcoin.

Per risolvere questo problema, nel 2012 è stato implementato un diversotipo di transazioni, chiamate Pay-To-Script-Hash (P2SH), dando la possibilità a chi spende di creare uno Script PubKey contenente l’hash di un secondo script, chiamato Redeem Script — una condizione aggiuntiva per poter spendere.

Il funzionamento di questo tipo di transazioni è quasi identico a quello delle transazioni P2PKH.

Bob crea uno script di redeem, contenente qualsiasi script egli voglia, ne fa l’hash e lo invia ad Alice. Alice crea quindi un output P2SH, contenente l’hash del redeem scrip che le è stato inviato da Bob.

Fonte: Bitcoin developer guide

L’hash dello Script di Redeem ha le stesse proprietà dell’hash della Chiave Pubblica e può quindi essere facilmente trasformato nel formato standard degli indirizzi Bitcoin. Inoltre, l’operazione di hashing offusca la chiave privata nel redeem script, pertanto gli script P2SH sono da considerare tanto sicuri quanto i più comuni P2PKH.

Transazioni Standard

Successivamente alla scoperta di numerosi bug nelle versioni iniziali di Bitcoin, è stato inserito un test che accetta transazioni solamente nel caso in cui i loro PubKey script e Sig Script siano conformi ad un insieme di template che ne dovrebbero attestare la sicurezza. Questo test è chiamato IsStandard() e le transazioni in grado di passarlo vengono quindi definite come transazioni standard.

Le transazioni non-standard — quelle che falliscono il test — possono comunque essere accettate da nodi che non usano la versione di default di Bitcoin Core.

Oltre a proteggere il network dalla possibilità di trasmettere transazioni pericolose, le transazioni standard aumentano la sicurezza del network in quanto non permettono agli utenti di creare transazioni che potrebbero rendere il futuro aggiornamento delle stesse più complicato. Questo è anche il motivo per cui ogni transazione include un numero di versione.

I tipi standard di script PubKey sono:

  1. P2PKH: la forma più comune, usato per inviare una transazione ad uno o più indirizzi Bitcoin
Pubkey script: 
OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Signature script: 
<sig> <pubkey>

2. P2SH: questo tipo di script è usato per inviare la transazione all’hash di uno script. Qualunque dei tradizionali script PubKey più essere usato come redeem script. Tuttavia, in pratica, lo script consigliato è il Multisig PubKey.

Pubkey script: 
OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Signature script: 
<sig> [sig] [sig...] <redeemScript>

MULTISIG: in uno script Multisig — comunemente definito m-di-n — m è il numero minimo di firme digitali a guardia di una chiave pubblica; n è invece il numero di firme fornite. Entrambi m ed n dovrebbero essere opcodes definiti tra OP_1 e OP_16, corrispondenti al numero desiderato.

A conseguenza di un errore nell’implementazione originale di BitcoinOP_CHECKMULTISIG consuma un valore di troppo dalla pila, rispetto a quanto indicato da m. Pertanto, la lista di firme secp256k1 dovrà contenere un valore extra (OP_0), che verrà consumato senza avere alcun effetto.

Lo scriptSig dovrà contenere le firme digitali nello stesso ordine in cui le corrispondenti chiavi pubbliche appaiono nello script PubKey o nello script Redeem.

Pubkey script: 
<m> <A pubkey> [B pubkey] [C pubkey...] <n> OP_CHECKMULTISIG
Signature script: 
OP_0 <A sig> [B sig] [C sig...]

Questo è un esempio di una transazione P2SH multisig, 2-su-3:

Pubkey script: 
OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Redeem script: 
<OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> OP_CHECKMULTISIG
Signature script: OP_0 <A sig> <C sig> <redeemScript>

PUBKEY: gli output PubKey sono una forma semplificata dello script PubKey utilizzato in transazioni P2PKH con la differenza che essi non sono in grado di fornire lo stesso livello di sicurezza — motivo per il quale non vengono più utilizzati.

Pubkey script: 
<pubkey> OP_CHECKSIG
Signature script: 
<sig>

NULL DATA: questo tipo di transazioni viene utilizzato per aggiungere delle informazioni arbitrarie ad uno script PubKey che non può essere speso e che non deve essere incluso nel set di UTXO. E’ preferibile utilizzare transazioni contenenti “null data” piuttosto che transazioni che impattino il database UTXO perché le prime non sono soggette a pruning;tuttavia, è bene menzionare che la soluzione migliore sarebbe quella di conservare le informazioni al di fuori delle transazioni, quando possibile.

Le correnti regole di consenso consentono output contenenti null data fino alla massima dimensione di 10,000 bytes (per gli script PubKey), a patto che essi seguano anche tutte le altre regole di consenso.

Le version Bitcoin Core 0.9.x e 0.10.x trasmetteranno e mineranno le transazioni contenenti null data di default — fino a 40 bytes e — in un singolo push di data e saranno incluse in un unico Output, che paga esattamente 0 satoshis:



Pubkey Script: 
OP_RETURN <0 to 40 bytes of data>
(Null data scripts cannot be spent, so there's no signature script.)

Bitcoin Core 0.11.x ha successivamente aumentato la dimensione massima a 80 bytes, che è poi diventata 83 dalla versione 0.12.0. All’interno del software di Bitcoin core l’opzione -datacarriersize fornisce la possibilità di poter decidere arbitrariamente il massimo numero di bytes che permette di minare e trasmettere una transazione contenente null data.

Transazioni Non-Standard

Nel caso in cui venisse usata una chiave diversa dal formato standard PubKey script all’interno di un output, i nodi e miners che utilizzano i setting di default di Bitcoin Core non accetteranno, trasmetteranno, né mineranno la transazione. 

D’altro canto, nella creazione di uno script di redeem, hashato e utilizzato in un output P2SH, il network visualizza solamente l’hash e quindi accetterà l’output come valido — senza analizzarne il contenuto.

Questo permette i pagamenti a script non-standard. L’eccezione è per quelli script che utilizzano opcodes NOP che non sono assegnati: questo tipo di opcodes sono riservati per eventuali soft fork future e possono essere minati e trasmessi solamente da nodi che non seguono la normale politica di mempool.

Nota: le transazioni standard sono sviluppate per proteggere ed aiutare il network, non per prevenire errori da parte degli utenti. E’ facile sbagliarsi e creare transazioni standard che rendono i satoshis inviati non spendibili per sempre.

A partire dalla versione Bitcoin Core 0.9.3, le transazioni standard devono rispettare le seguenti condizioni:

· La transazione deve essere finalizzata: il suo timelock deve essere nel passato (minore o uguale all’altezza del blocco corrente), o il proprio numero di seguenza deve essere 0xffffffff.

· La transazione deve essere più piccola di 100,000 bytes. Questo è circa 200 volte più grande in una tipica transazione P2PKH con un singolo input ed output.

· Tutti gli script sig nella transazione devono essere più piccoli di 1,650 bytes. Questa grandezza è sufficiente per consentire la creazione di transazioni multisig 15-di-15 , mediante l’uso di chiavi pubbliche compresse. Transazioni multisig non-p2sh che richiedono più di 3 chiavi pubbliche sono considerate non-standard.

· Lo script sig della transazione deve inviare solamente informazioni sullo stack dello script di valutazione. Non può inviare nuovi opcodes con l’eccezione di opcodes che hanno il solo scopo di inviare informazioni sullo stack.

· La transazione non deve includere nessun output che riceve meno di 1/3 dei satoshi che spenderebbe in un tipico input. Questo si attesta in media a 546 satoshi per una transazione P2PKH o P2SH su un nodo Bitcoin Core con delle fee standard. Eccezione: null data outputs devono ricevere zero satoshis.

Tipi di Firme Hash

OP_CHECKSIG estrae un argomento non-stack da ogni firma che verifica, dando la possible a chi firma di decidere quale parte della transazione firmare. Dato che la firma protegge quelle parti della transazione da modifiche, questo da la possibilità a chi firma di poter decider di lasciare ad altri utenti la possibilità di modificare le loro transazioni

Le diverse opzioni su quale parte della transazione firmare sono chiamate SIGHASH. Al momento ci sono tre diversi tipi di firme:

SIGHASH_ALL, lo standardfirma tutti gli inputs e gli outputs, proteggendo da eventuali modifiche tutto il contenuto tranne il sig script.

· SIGHASH_NONE firma tutti gli inputs ma nessun outputs, dando la possibilità a chiunque di cambiare l’indirizzo al quale sono diretti I satoshis, a meno che non ci siano altri SIGHASH a protezione degli output.

· SIGHASH_SINGLE l’unico output firmato è quello corrispondente all’input (l’output con lo stesso numero di indice dell’input), assicurando che nessuno possa cambiare la parte della transazione in questione, ma dando la possibilità ad altri firmatari di poter cambiare la loro parte di transazione. L’ouput corrispondente dovrà esistere, altrimenti il valore “1” verrà inserito, rendendo vano lo schema di sicurezza. L’input in questione, insieme agli altri input, sono inclusi nella firma. Il numero di sequenza degli altri input non è incluso nella firma e può quindi essere aggiornato.

SIGHASH di base possono essere modificati con il SIGHASH_ANYONECANPAY
(chiunque può spendere), creando tre nuove combinazioni:

· SIGHASH_ALL|SIGHASH_ANYONECANPAY firma tutti gli output ma solamente questo l’input in questione, dà anche la possibilità a chiunque di aggiungere o rimuovere altri inputs, in modo tale da permettere a chiunque di poter contribuire satoshis addizionali – non è tuttavia possible cambiare quanti satoshi vengono inviati, nè l’indirizzo di destinazione.

· SIGHASH_NONE|SIGHASH_ANYONECANPAY firma solamente l’input in questione e dà la possibilità di poter aggiungere o rimuovere altri inputs o outputs, chiunque può quindi ottenere una copia dell’input da spendere a propria discrezione.

· SIGHASH_SINGLE|SIGHASH_ANYONECANPAY firma l’input in questione e l’ouput corrispondente. Dà la possibilità a chiunque di aggiungere o rimuovere altri inputs.

Dato che ogni input viene firmato, una transazione con molteplici inputs deve avere diversi tipi di SIGHASH che firmano diverse parti della transazione. Ad esempio, una transazione con un singolo input firmato con NONE può avere il proprio output cambiato dal miner che la include nella blockchain.

D’altra parte, nel caso in cui una transazione con due input abbia un input firmato con NONE ed un altro con ALL, il firmatario ALL potrà scegliere dove spendere i satoshi, senza consultare il firmatario NONE – è comunque bene specificare che nessun altro può modificare la transazione.



Locktime e Numero di Sequenza

Un elemento che è sempre firmato dalle SIGHASH è il locktime della transazione (chiamato nLockTime nel codice di Bitcoin Core).

Questo elemento indica il periodo dove una transazione può essere aggiunta nella blockchain.

Il locktime dà la possibilità ai firmatario di poter creare transazioni che diventeranno valide solamente in futuro, dando quindi a chi firma la possibilità di cambiare idea prima del tempo.

Nel caso in cui questo avvenisse, la parte in questione potrà creare un’altra transazione non soggetta a timelock. Questa nuova transazione utilizzerà come input uno degli stessi output precedentemente usato come input nella transazione con timelock. Questo rende la transazione con timelock invalida, nel caso in cui la nuova transazione verrebbe trasmessa prima della scadenza del timelock.

E’ necessario prestare particolare attenzione una volta vicini alla scadenza del timelock. Infatti, la blockchain Bitcoin consente di aggiungere transazioni con timelock solamente fino a due ore prima della loro scadenza.
Inoltre, dato che gli intervalli di creazione di nuovi blocchi sono variabili, ogni tentativo di cancellare una transazione deve essere fatto alcune ore prima della scadenza.

Le versioni precedenti di Bitcoin Core avevano un feature che preveniva i firmatari delle transazioni dall’uso del metodo appena descritto per cancellare una transazione con timelock, successivamente disabilitato per prevenire attacchi DDOS. L’unica cosa che rimane da questo feature è un numero di sequenza di 4-bytes, presente in ogni input.

I numeri di sequenza danno la possibilità a multipli firmatari di essere d’accordo sull’aggiornamento di una transazione; una volta finito l’aggiornamento, essi devono essere d’accordo sul numero di sequenza di ogni input, che dev’essere impostato al massimo (0xffffffff), dando la possibilità alla transazione di essere aggiunta in un blocco anche nel caso in cui il timelock non sia ancora scaduto.

Anche al giorno d’oggi, impostare tutti i numeri di sequenza a 0xffffffff (il default in Bitcoin Core) può ancora disabilitare il timelock. Pertanto, nel caso in cui un utente volesse utilizzare il locktime, egli dovrebbe impostare almeno un input con un numero di sequenza più basso del massimo.Dato che questo è l’unico utilizzo dei numeri di sequenza, l’impostazione di qualsiasi numero a zero è sufficiente per abilitare il timelock.

Il locktime è un unsigned integer di 4-bytes, che può essere analizzato in due modi:

· Se meno di 500 milioni il locktime va interpretato come l’altezza del blocco. La transazione può essere aggiunda a qualsiasi blocco che abbia quell’altezza o un numero maggiore.

· Se uguale o maggiore a 500 milioni, il locktime è da interpretare utilizzando il formato Unix epoch time (il numero di secondi a partire dal 01–01–1970 alle ore 00:00 UTC). La transazione potrà quindi essere aggiunta a qualsiasi blocco il cui tempo sia maggiore del locktime.

Spese di Commissione

Le transazioni pagano delle commissioniin base alla grandezza totale della transazione firmata, espressa in bytes.

Le commissioni per bytes sono calcolate in base alla domanda per aver spazio all’interno dei blocchi minati — più alta la domanda, maggiori le commissioni.

Le commissioni sono date al miner che ha inserito le transazioni nel blocco — le commissioni minime sono quindi a discrezione dei singoli miners.

Esiste anche il concetto di “transazioni ad alta priorità” che spendono satoshi che non sono stati mossi per un lungo periodo. In passato, queste transazioni erano spesso esenti dalle commissioni normali. Prima della versione 0.12 di Bitcoin Core, 50kb di ogni blocco erano dedicati a questo tipo di transazioni, attualmente questo è impostato a 0 kb. Le transazioni possono essere comunque prioritizzate in base alla commissione indicata per byte.

Le transazioni con fees più alte verranno quindi inserite nel blocco in sequenza, fino a che ci sia spazio disponibile.

A partire dalla versione di Bitcoin Core 0.9 una commissione minima (1000 satoshi) è richiesta per l’invio di una transazione nel network. Tuttavia, la transazione che pagherà la commissione minima dovrà probabilmente aspettare molto tempo, prima di poter essere inclusa in un blocco.

Dato che ogni transazione spende Output Non-Spesi (UTXO) e siccome le UTXO possono essere spesi solamente una volta sola, l’intero valore delle UTXO incluse deve essere speso o dato ad un miner come commissione.Solamente alcune persone avranno UTXO che matcheranno perfettamente con quanto dovranno pagare, pertanto molte di queste transazioni includerà un output di resto.

Un output di resto non è altro che un output regolare che spende i satoshi in eccesso dalla UTXO e li invia a chi li ha mandati inizialmente. Questo tipo di output può riutilizzare lo stesso hash della pubKey in una transazione P2PKH o l’hash dello script in un P2SH — tuttavia, per ragioni descritte nel prossimo paragrafo è altamente raccomandabile che questo output vengano inviati ad un nuovo indirizzo.

Evitare il Riutilizzo delle Chiavi

In una transazione sia chi spende che chi riceve rivela all’altro la propria chiave pubblica o il proprio indirizzo. Questo dà la possibilità ad entrambi di poter utilizzare la blockchain pubblica per tener traccia di transazioni passate e future che coinvolgano l’indirizzo o la chiava pubblica dell’altra persona. Nel caso in cui la stessa chiave pubblica venisse riutilizzata più volte (come avviene nel caso di indirizzi Bitcoin utilizzati come indirizzi di pagamento statici), è possibile per chiunque tener traccia dei movimenti di quella persona, inclusa la quantità di satoshi in controllo.

Invece, nel caso in cui ogni chiave pubblica venisse utilizzata solamente per due volte — una per ricevere ed una per inviare — l’utente in questione ne guadagnerebbe in privacy. Ancora meglio, utilizzando nuove chiavi pubbliche o indirizzi univoci per ricevere pagamenti o creare output di resto può essere combinato con altre tecniche per preservare la privacy, che verranno discusse in seguito. In particolare, merge avoidance e CoinJoin rendono particolarmente difficile l’utilizzo della blockchain per tracciare le abitudini di spesa di precisi utenti. Evitare il riutilizzo della propria chiave fornisce inoltre garanzie contro attacchi che potrebbero rendere possibile la ricostruzione di chiavi private da chiavi pubbliche o paragonando diverse firme digitali.

1. L’utilizzo di indirizzi univoci P2PKH e P2SH protegge contro questo primo tipo di attacchi, tenendo le chiavi pubbliche ECDSA nascoste (hashed) fino alla prima volta che i satoshi inviati a questi indirizzi vengono spesi; pertanto gli attacchi a riguardo sono effettivamente inutili, a meno che gli attaccatori non siano in grado di ricostruire le chiavi private in questione in meno tempo della conferma della transazione in blockchain — 6 blocchi, un’ora o due.

2. L’utilizzo di chiavi private univoche protegge contro il secondo tipo di attacchi, generando solamente una singola firma digitale per chiave privata. In questo modo chi attacca non può ottenere una firma ulteriore da usare come paragone.

Il takeaway maggiore di questo paragrafo è che sia per la preservazione della privacy che per questioni di sicurezza gli utenti Bitcoin sono sempre invitati ad evitare il riutilizzo della chiave pubblica e — quando possible — dei propri indirizzi.



Malleabilità delle Transazioni

La malleabilità delle transazioni è un tipo di attacco a cui è — era — soggetto il network Bitcoin. Nessuno degli hash di firma è infatti in grado di proteggere lo scriptSig, lasciando la porta aperta per un possibile attacco “denial of service” (DDos), chiamato malleabilità delle transazioni.

Lo scriptSig include infatti una firma in formato secp256k1, che non può firmare se stessa, dando quindi la possibilità ad un attaccatore di fare modifiche non funzionali, senza rendere la transazione invalida.

Un esempio potrebbe essere l’aggiunta di informazioni nello scriptSig che verrebbero droppate prima che il pubKey script precedente venga eseguito.

Nonostante le modifiche in questione non siano funzionali — non cambiano gli input o gli output della transazione — esse cambiano l’hash della transazione e quindi il txid della stessa. Questo non è un problema per molte transazioni che sono create per essere aggiunte immediatamente in un blocco. Tuttavia, lo è quando l’output viene speso prima che la transazione sia nella blockchain. La comunità Bitcoin ha lavorato duramente per risolvere questo problema, eventualmente sviluppando la BIP 141: Segregated Witness, implementata ad Agosto 2017. 
Il problema della malleabilità ha anche un impatto sulla tracciabilità delle transazioni e dei pagamenti, in quanto essi vengono riportati in base al loro txid. La best practice per tracciare le transazioni sarebbe quella di tracciare gli output non spesi (UTXO), utilizzati come inputs, in quanto essi non sono modificabili senza invalidare la transazione.

Inoltre, un’ulteriore pratica nel caso di scomparsa di una transazione dal network è quella di rifarla in maniera tale da invalidare la transazione precedente. Un metodo funzionante è quello di assicurarsi che la nuova transazione spenda gli stessi outputs usati precedentemente come inputs.

Questo è tutto per quanto riguarda le transazioni Bitcoin, spero che questo approfondimento sia stato interessante e in grado di apportare valore, in termini di conoscenze o curiosità.

Leave a Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*