Transazioni

Le transazioni consentono agli utenti di spendere satoshi. Ogni transazione è composta da diverse parti che consentono sia pagamenti diretti semplici sia transazioni complesse. Questa sezione descriverà ogni parte e dimostrerà come usarli insieme per creare transazioni complete.

Per semplificare le cose, questa sezione fa finta che le transazioni coinbase non esistano. Le transazioni coinbase possono essere create solo dai minatori Bitcoin e rappresentano un'eccezione a molte delle regole elencate di seguito.

La figura sopra mostra le parti principali di una transazione Bitcoin. Ogni transazione ha almeno un input e un output. Ogni input spende il satoshi pagato a un output precedente. Ogni output attende quindi come output di transazione non speso (UTXO) fino a quando un input successivo lo spende. Quando il tuo portafoglio Bitcoin ti dice che hai un saldo di satoshi di 10.000, significa realmente che hai 10.000 satoshi in attesa in uno o più UTXO.

Ogni transazione è preceduta da un numero di versione della transazione a quattro byte che comunica ai peer e ai minatori di Bitcoin quale insieme di regole utilizzare per convalidarlo. Ciò consente agli sviluppatori di creare nuove regole per le transazioni future senza invalidare le transazioni precedenti.

Un output ha un numero di indice implicito in base alla sua posizione nella transazione: l'indice del primo output è zero. L'output ha inoltre una quantità in satoshi che paga ad uno script pubkey condizionale. Chiunque sia in grado di soddisfare le condizioni di quel pubkey script può spendere la quantità di satoshi pagati.

Un input utilizza un identificatore di transazione (txid) e un numero di indice di output (spesso chiamato "vout" per il vettore di output) per identificare un particolare output da spendere. Ha anche uno script di firma che gli consente di fornire parametri di dati che soddisfano i condizionali nello script pubkey. (Il numero di sequenza e il locktime sono correlati e saranno trattati insieme in una sottosezione successiva.)

Le figure seguenti illustrano come queste funzioni vengono utilizzate mostrando il flusso di lavoro utilizzato da Alice per inviare a Bob una transazione che in seguito viene spesa da Bob. Sia Alice che Bob utilizzeranno la forma più comune del tipo di transazione standard Pay-To-Public-Key-Hash (P2PKH). P2PKH consente ad Alice di passare satoshi a un tipico indirizzo Bitcoin, e quindi consente a Bob di spendere ulteriormente quei satoshi usando una semplice coppia di chiavi crittografiche.

Bob deve prima generare una coppia chiave pubblica/chiave privata prima che Alice possa creare la prima transazione. Bitcoin utilizza l'algoritmo Elliptic Curve Digital Signature (ECDSA) con la curva secp256k1; le chiavi private secp256k1 sono 256 bit di dati casuali. Una copia di tali dati viene trasformata deterministicamente in una chiave pubblica secp256k1.

La chiave pubblica (pubkey) viene quindi crittografata hashandola. Questo hash pubkey può anche essere ripetuto in modo affidabile in seguito, quindi non è necessario memorizzarlo. L'hash accorcia e offusca la chiave pubblica, semplificando la trascrizione manuale e fornendo sicurezza contro problemi imprevisti che potrebbero consentire la ricostruzione di chiavi private da dati di chiavi pubbliche in un momento successivo.

Bob fornisce il pubkey hash ad Alice. Gli hash di Pubkey vengono quasi sempre inviati codificati come indirizzi Bitcoin, che sono stringhe codificate in base58 che contengono un numero di versione dell'indirizzo, l'hash e un checksum di rilevamento degli errori per rilevare errori di battitura. L'indirizzo può essere trasmesso attraverso qualsiasi mezzo, compresi mezzi a senso unico che impediscono allo spender di comunicare con il ricevitore, e può essere ulteriormente codificato in un altro formato, come ad esempio un codice QR contenente un “bitcoin:” URI.

Una volta che Alice ha l'indirizzo e lo ritrasforma in un hash standard, può creare la prima transazione. Crea un output di transazione P2PKH standard contenente istruzioni che consentono a chiunque di spendere quell'output se riescono a dimostrare di controllare la chiave privata corrispondente al hash della chiave pubblica di Bob. Queste istruzioni sono chiamate lo script pubkey o scriptPubKey.

Alice trasmette la transazione e viene aggiunta alla catena di blocchi. La rete la classifica come un Unspent Transaction Output (UTXO) e il software di portafoglio di Bob lo mostra come un saldo spendibile.

Quando, qualche tempo dopo, Bob decide di spendere l'UTXO, deve creare un input che faccia riferimento alla transazione di Alice creata dal suo hash, chiamato Transaction Identifier (txid), e l'output specifico usato dal suo numero di indice (indice di output). Deve quindi creare uno script di firma, una raccolta di parametri di dati che soddisfano le condizioni inserite da Alice nello script pubkey dell'output precedente. Gli script di firma sono anche chiamati scriptSigs.

Gli script Pubkey e gli script di firma combinano i pubkeys e le firme secp256k1 con la logica condizionale, creando un meccanismo di autorizzazione programmabile.

Per un output in stile P2PKH, lo script di firma di Bob conterrà le seguenti due parti di dati:

La sua chiave pubblica completa (non modificata), così che lo script pubkey possa verificare che abbia hash allo stesso valore dell'hash di pubkey fornito da Alice.

Una firma secp256k1 realizzata utilizzando la formula crittografica ECDSA per combinare determinati dati di transazione (descritti di seguito) con la chiave privata di Bob. Ciò consente allo script pubkey di verificare che Bob possiede la chiave privata che ha creato la chiave pubblica.

La firma di Bob secp256k1 non dimostra solo che Bob controlla la sua chiave privata; inoltre rende le parti non-signature-script della sua transazione a prova di manomissione in modo che Bob possa trasmetterle in modo sicuro sulla rete peer-to-peer.

Come illustrato nella figura sopra, i dati di Bob includono l'indice txid e l’output della transazione precedente, lo script pubkey dell'output precedente, lo script pubkey che Bob crea e che consentirà al prossimo destinatario di utilizzare l'output di questa transazione e la quantità di satoshi da passare al prossimo destinatario. In sostanza, l'intera transazione è firmata tranne che per gli script di firma, che contengono le chiavi pubbliche complete e le firme secp256k1.

Dopo aver inserito la firma e la chiave pubblica nello script della firma, Bob trasmette la transazione ai minatori Bitcoin attraverso la rete peer-to-peer. Ogni peer e minatore convalida in modo indipendente la transazione prima di trasmetterla ulteriormente o tentando di includerla in un nuovo blocco di transazioni.

Convalida Script P2PKH

La procedura di validazione richiede la valutazione dello script della firma e dello script pubkey. In un output P2PKH, lo script pubkey è:

OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

Lo script della firma dello “spender” viene valutato e prefisso all'inizio dello script. In una transazione P2PKH, lo script della firma contiene una firma secp256k1 (sig) e una chiave pubblica completa (pubkey), creando la seguente concatenazione:

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

Il linguaggio di script è un linguaggio stack-based simile a Forth, progettato deliberatamente per essere apolidi e non completo di Turing. L'apolidia garantisce che, una volta aggiunta una transazione alla catena di blocchi, non vi sia alcuna condizione che la rende definitivamente non spendibile. Turing-incompleta (in particolare, mancanza di loop o goto) rende il linguaggio degli script meno flessibile e più prevedibile, semplificando notevolmente il modello di sicurezza.

Per verificare se la transazione è valida, lo script della firma e le operazioni di script pubkey vengono eseguite un elemento alla volta, a partire dallo script di firma di Bob e continuando fino alla fine dello script pubkey di Alice. La figura seguente mostra la valutazione di uno script pubkey standard P2PKH; sotto la figura è una descrizione del processo.

L

Dallo script pubkey di Alice, l'operazione OP_DUP viene eseguita. OP_DUP spinge nello stack una copia dei dati attualmente in cima ad essa, creando in questo caso una copia della chiave pubblica fornita da Bob.

L'operazione eseguita successivamente, OP_HASH160, spinge nello stack un hash dei dati attualmente su di esso, in questo caso, la chiave pubblica di Bob. Questo crea un hash della chiave pubblica di Bob.

Lo script pubkey di Alice poi spinge l'hash pubkey che Bob le ha dato per la prima transazione. A questo punto, ci dovrebbero essere due copie dell'hash pubkey di Bob in cima allo stack.

Ora diventa interessante: lo script pubkey di Alice esegue OP_EQUALVERIFY.

OP_EQUALVERIFY equivale all'esecuzione di OP_EQUAL seguito da OP_VERIFY (non mostrato).

OP_EQUAL (non mostrato) controlla i due valori nella parte superiore dello stack; in questo caso, controlla se l'hash pubkey generato dalla chiave pubblica completa fornita da Bob è uguale all'hash di pubkey fornito da Alice quando ha creato la transazione n. 1. OP_EQUAL apre (rimuove dalla cima dello stack) i due valori confrontati e li sostituisce con il risultato di tale confronto: zero (falso) o uno (vero).

OP_VERIFY (non mostrato) controlla il valore nella parte superiore dello stack. Se il valore è falso, termina immediatamente la valutazione e la convalida della transazione non riesce. Altrimenti espelle il vero valore dallo stack.

Infine, lo script pubkey di Alice esegue OP_CHECKSIG, che controlla la firma fornita da Bob contro la chiave pubblica ora autenticata che ha anche fornito. Se la firma corrisponde alla chiave pubblica ed è stata generata utilizzando tutti i dati richiesti per la firma, OP_CHECKSIG inserisce il valore true nella parte superiore dello stack.

Se “false” non è nella parte superiore dello stack dopo che lo script pubkey è stato valutato, la transazione è valida (a condizione che non ci siano altri problemi con esso).

Script P2SH

Gli script di Pubkey sono creati da spender che hanno poco interesse su quello che fa lo script. I destinatari si preoccupano delle condizioni dello script e, se lo desiderano, possono chiedere agli spender di utilizzare un particolare script pubkey. Sfortunatamente, gli script pubkey personalizzati sono meno convenienti dei brevi indirizzi Bitcoin e non esisteva un modo standard per comunicarli tra programmi prima dell'implementazione diffusa del protocollo di pagamento BIP70 discusso più avanti.

Per risolvere questi problemi, nel 2012 sono state create transazioni pay-to-script-hash (P2SH) per consentire a uno spender di creare uno script pubkey contenente un hash di un secondo script, lo script di riscatto.

Il flusso di lavoro di base P2SH, illustrato di seguito, sembra quasi identico al flusso di lavoro P2PKH. Bob crea uno script di riscatto con qualunque script desideri, blocca lo script di riscatto e fornisce l'hash dello script da riscattare ad Alice. Alice crea un output in stile P2SH contenente l'hash dello script di riscatto di Bob.

Quando Bob vuole spendere l'output, fornisce la sua firma insieme allo script di riscatto (serializzato) completo nello script della firma. La rete peer-to-peer assicura in modo completo l’hash dello script di riscatto allo stesso valore dell'hash dello script Alice nel suo output; quindi elabora lo script di riscatto esattamente come farebbe se fosse lo script pubkey principale, lasciando che Bob spenda l'output se lo script riscatto non restituisce lo stato “false”.

L'hash dello script di riscatto ha le stesse proprietà di un pubkey hash, quindi può essere trasformato nel formato di indirizzo Bitcoin standard con solo una piccola modifica per differenziarlo da un indirizzo standard. Questo rende la raccolta di un indirizzo in stile P2SH semplice come la raccolta di un indirizzo in stile P2PKH. L'hash inoltre nasconde tutte le chiavi pubbliche nello script di riscatto, quindi gli script P2SH sono sicuri quanto gli hash di pubkey P2PKH.

Transazioni standard

Dopo la scoperta di diversi bug pericolosi nelle prime versioni di Bitcoin, è stato aggiunto un test che accettava solo le transazioni dalla rete se i loro script pubkey e gli script di firma corrispondevano a un piccolo insieme di modelli ritenuti sicuri, e se il resto della transazione non ha violato un'altra piccola serie di regole che rafforzano il buon comportamento della rete. Questo è il test “IsStandard ()” e le transazioni che lo superano sono chiamate transazioni standard.

Le transazioni non standard, quelle che non superano il test, possono essere accettate dai nodi che non utilizzano le impostazioni predefinite di Bitcoin Core. Se sono inclusi in blocchi, eviteranno anche il test IsStandard e saranno elaborati.

Oltre a rendere più difficile per qualcuno l'attacco gratuito a Bitcoin trasmettendo transazioni dannose, il test standard delle transazioni aiuta anche a impedire agli utenti di creare transazioni oggi che renderebbero più difficile l'aggiunta di nuove funzionalità di transazione in futuro. Ad esempio, come descritto sopra, ogni transazione include un numero di versione, se gli utenti hanno iniziato a modificare arbitrariamente il numero di versione, sarebbe diventato inutile come strumento per l'introduzione di funzionalità incompatibili con le versioni precedenti.

A partire da Bitcoin Core 0.9, i tipi standard di script pubkey sono:

Pay To Public Key Hash (P2PKH)

P2PKH è la forma più comune di script pubkey utilizzata per inviare una transazione a uno o più indirizzi Bitcoin.

Pubkey Script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Signature script: <sig> <pubkey>

Pay To Script Hash (P2SH)

P2SH è usato per inviare una transazione a un script hash. Ciascuno degli script pubkey standard può essere utilizzato come script di riscatto P2SH, escludendo P2SH stesso. A partire da Bitcoin Core 0.9.2, le transazioni P2SH possono contenere qualsiasi redeemScript valido, rendendo lo standard P2SH molto più flessibile e consentendo la sperimentazione di molti nuovi e complessi tipi di transazioni. L'uso più comune di P2SH è lo script standard multisig pubkey, il secondo utilizzo più comune è l'Open Assets Protocol.

Un altro redeemScript comune usato per P2SH è memorizzare dati testuali sulla blockchain. La prima transazione bitcoin mai effettuata includeva del testo e P2SH è un metodo conveniente per memorizzarlo sulla blockchain in quanto è possibile memorizzare fino a 1,5 kb di dati di testo. Un esempio di memorizzazione del testo sulla blockchain usando P2SH può essere trovato in questo repository.

(https://github.com/petertodd/checklocktimeverify-demos/blob/master/lib/python-bitcoinlib/examples/publish-text.py)

Script Pubkey: OP_HASH160 <Hash160 (redeemScript)> OP_EQUAL

Signature script: <sig> [sig] [sig...] <redeemScript>

Questa combinazione di script sembra perfettamente adatta ai nodi precedenti, a condizione che l'hash dello script corrisponda allo script di riscatto. Tuttavia, dopo l'attivazione del soft fork, i nuovi nodi eseguiranno un'ulteriore verifica per lo script di riscatto. Estrae lo script di riscatto dallo script della firma, lo decodificano e lo eseguono con gli elementi dello stack rimanenti ( <sig> [sig] [sig..]part). Pertanto, per riscattare una transazione P2SH, lo spender deve fornire la firma o la risposta valida oltre allo script di riscatto corretto.

Questo ultimo passaggio è simile al passaggio di verifica negli script P2PKH o P2Multisig, in cui la parte iniziale dello script di firma (<sig> [sig] [sig ..]) funge da "script di firma" in P2PKH / P2Multisig e lo script di riscatto funge da "script pubkey".

Multisig

Sebbene il multisig P2SH sia ora generalmente utilizzato per le transazioni multisig, questo script di base può essere utilizzato per richiedere più firme prima che un UTXO possa essere speso.

Negli script pubkey multisig, chiamati m-of-n, m è il numero minimo di firme che deve corrispondere a una chiave pubblica; n è il numero di chiavi pubbliche fornite. Sia m che n devono essere opcodes da OP_1 a OP_16, corrispondenti al numero desiderato.

A causa di un errore "off-one" nell'implementazione originale di Bitcoin che deve essere preservata per compatibilità, OP_CHECKMULTISIG consuma un altro valore dallo stack rispetto quanto indicato da m, quindi l'elenco delle firme secp256k1 nello script della firma deve essere preceduto da un extra valore (OP_0) che verrà consumato ma non utilizzato.

Lo script della firma deve fornire le firme nello stesso ordine in cui le chiavi pubbliche corrispondenti appaiono nello script pubkey o riscattare lo script. Vedere la descrizione in OP_CHECKMULTISIG per i dettagli.

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

Signature script: OP_0 <A sig> [B sig] [C sig ...]

Sebbene non sia un tipo di transazione separato, questo è un multisig P2SH con 2-di-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 di Pubkey sono una forma semplificata dello script pubkey P2PKH, ma non sono sicuri quanto il P2PKH, quindi in genere non vengono più utilizzati nelle nuove transazioni.

Pubkey script: <pubkey> OP_CHECKSIG

Signature script: <sig>

Null Data

La transazione di tipo Null Data, rilasciata di default in Bitcoin Core 0.9.0 e successive versioni, aggiunge dati arbitrari ad uno script pubkey che i nodi completi non devono memorizzare nel loro database UTXO. È preferibile utilizzare transazioni Null Data piuttosto che transazioni che gonfiano il database UTXO perché non possono essere automaticamente eliminate; tuttavia, è sempre più preferibile memorizzare i dati al di fuori delle transazioni, se possibile.

Le regole di consenso consentono output di dati nulli fino alla dimensione massima consentita dello script pubkey di 10.000 byte purché seguano tutte le altre regole di consenso, come ad esempio non avere push di dati superiori a 520 byte.

Bitcoin Core da 0.9.x a 0.10.x, per impostazione predefinita, inoltra le transazioni Null Data con un massimo di 40 byte in un singolo push di dati e solo un output di Null Data che paga esattamente 0 satoshi:

Script Pubkey: OP_RETURN <da 0 a 40 byte di dati>

(Gli script Null Data non possono essere spesi, quindi non c'è uno script di firma.)

Bitcoin Core 0.11.x aumenta questo valore predefinito a 80 byte, con le altre regole che rimangono invariate.

Il valore predefinito di Bitcoin Core 0.12.0 è di inoltrare e estrarre output di Null Data con un massimo di 83 byte con un numero qualsiasi di push di dati, a condizione che il limite totale di byte non venga superato. Ci deve essere ancora un singolo output di Null Data e deve ancora pagare esattamente 0 satoshi.

L'opzione di configurazione -datacarriersize di Bitcoin Core consente di impostare il numero massimo di byte in output di Data Null che verranno inoltrati o miniati.

Transazioni non standard

Se si utilizza qualcosa di diverso rispetto ad uno script pubkey standard in un output, peer e minatori che utilizzano le impostazioni predefinite di Bitcoin Core non accetteranno, trasmetteranno o estrarranno la transazione. Quando si tenta di trasmettere la transazione a un peer che esegue le impostazioni predefinite, si riceverà un errore.

Se crei uno script redeem, ne ricavi l’hash e usi l'hash in un output P2SH, la rete vede solo l'hash, quindi accetta l'output come valido, indipendentemente da ciò che dice lo script di riscatto. Ciò consente il pagamento di script non standard e, a partire da Bitcoin Core 0.11, è possibile utilizzare quasi tutti gli script di riscatto validi. L'eccezione è rappresentata dagli script che utilizzano opcode NOP non assegnati; questi opcode sono riservati per future soft fork e possono essere inoltrati o estratti solo da nodi che non seguono la politica standard di mempool.

Nota: le transazioni standard sono progettate per proteggere e aiutare la rete, ma non ti impediscono di commettere errori. È facile creare transazioni standard che rendono i Satoshi inviati a loro non spendibili.

A partire da Bitcoin Core 0.9.3, le transazioni standard devono inoltre soddisfare le seguenti condizioni:

La transazione deve essere finalizzata: o il suo locktime deve essere nel passato (o inferiore o uguale all'altezza del blocco corrente), o tutti i suoi numeri di sequenza devono essere 0xffffffff.

La transazione deve essere inferiore a 100.000 byte. Quindi circa 200 volte più grande di una normale transazione P2PKH a singolo-input e singolo-output.

Ciascuno degli script di firma della transazione deve essere inferiore a 1.650 byte. È abbastanza grande da consentire le transazioni multisig 15-of-15 in P2SH utilizzando chiavi pubbliche compresse.

Le transazioni multisig “Bare” (non P2SH) che richiedono più di 3 chiavi pubbliche sono attualmente considerate non standard.

Lo script della firma della transazione deve solo inviare dati allo stack di valutazione dello script. Non può spingere nuovi opcode, ad eccezione degli opcode che spingono solo i dati nello stack.

La transazione non deve includere output che ricevano meno di 1/3 di satoshi quanti ne impiegherebbero per spenderli in un tipico input. Al momento sono 546 satoshi per un output P2PKH o P2SH su un nodo Bitcoin Core con il costo del relay predefinito. Eccezione: gli output di null data standard devono ricevere satoshis zero.

Tipi di hash di firma

OP_CHECKSIG estrae un argomento non stack da ogni firma che valuta, consentendo al firmatario di decidere quali parti della transazione firmare. Poiché la firma protegge le parti della transazione dalla modifica, ciò consente ai firmatari di scegliere in modo selettivo di consentire ad altre persone di modificare le loro transazioni.

Le varie opzioni per cosa firmare sono chiamate tipi di hash della firma. Ci sono tre tipi SIGHASH di base attualmente disponibili:

SIGHASH_ALL, il valore predefinito, firma tutti gli input e gli output, proteggendo tutto tranne gli script della firma da modifiche.

SIGHASH_NONE firma tutti gli input ma nessuno degli output, permettendo a chiunque di cambiare dove stanno andando i satoshi a meno che altre firme che usano altri flag hash di firma proteggano le uscite.

SIGHASH_SINGLE l'unico output firmato è quello corrispondente a questo input (l'output con lo stesso numero di indice di output di questo input), assicurando che nessuno possa modificare la tua parte della transazione ma consentendo ad altri firmatari di modificare la loro parte della transazione. L'output corrispondente deve esistere o il valore "1" verrà firmato, interrompendo lo schema di sicurezza. Questo input, così come altri input, sono inclusi nella firma. I numeri di sequenza di altri input non sono inclusi nella firma e possono essere aggiornati.

I tipi di base possono essere modificati con il flag SIGHASH_ANYONECANPAY (chiunque può pagare), creando tre nuovi tipi combinati:

SIGHASH_ALL | SIGHASH_ANYONECANPAY firma tutti gli output ma solo questo input e consente a chiunque di aggiungere o rimuovere altri input, in modo che chiunque possa contribuire con satoshi aggiuntivi ma non può modificare quanti satoshi vengono inviati né dove vanno.

SIGHASH_NONE | SIGHASH_ANYONECANPAY firma solo questo input e consente a chiunque di aggiungere o rimuovere altri input o output, in modo tale che chiunque possa ottenere una copia di questo input può spenderlo come preferisce.

SIGHASH_SINGLE | SIGHASH_ANYONECANPAY firma questo input e il suo output corrispondente. Consente a chiunque di aggiungere o rimuovere altri input.

Poiché ogni input è firmato, una transazione con più input può avere più tipi di hash di firma che firmano diverse parti della transazione. Ad esempio, una transazione con input singolo firmato con NONE potrebbe avere il suo output modificato dal minatore che lo aggiunge alla catena di blocchi. D'altra parte, se una transazione a due input ha un input firmato con NONE e un input firmato con ALL, il firmatario ALL può scegliere dove passare i satoshi senza consultare il firmatario di NONE, ma nessun altro può modificare la transazione.

Locktime e Sequence Number

Una cosa che firma tutti i tipi di hash delle firme è il locktime della transazione. (Chiamato nLockTime nel codice sorgente di Bitcoin Core.) Il locktime indica il primo momento in cui una transazione può essere aggiunta alla catena di blocchi.

Locktime consente ai firmatari di creare transazioni bloccate nel tempo che diventeranno valide solo in futuro, dando ai firmatari la possibilità di cambiare idea.

Se qualcuno dei firmatari cambia idea, può creare una nuova transazione non locktime. La nuova transazione utilizzerà, come uno dei suoi input, uno degli stessi output che è stato utilizzato come input per la transazione locktime. Ciò rende la transazione locktime non valida se la nuova transazione viene aggiunta alla catena di blocchi prima della scadenza del blocco temporale.

Si deve prestare attenzione vicino al tempo di scadenza di un “time lock”. La rete peer-to-peer consente al "tempo di blocco” di essere fino a due ore avanti in tempo reale, quindi una transazione locktime può essere aggiunta alla catena di blocchi fino a due ore prima che il suo time block scada ufficialmente. Inoltre, i blocchi non vengono creati a intervalli garantiti, pertanto qualsiasi tentativo di annullare una transazione valida dovrebbe essere effettuato poche ore prima della scadenza del blocco temporale.

Le versioni precedenti di Bitcoin Core fornivano una funzionalità che impediva ai firmatari delle transazioni di utilizzare il metodo descritto sopra per annullare una transazione bloccata a tempo, ma una parte necessaria di questa funzione era disabilitata per prevenire attacchi denial of service. Un retaggio di questo sistema sono numeri di sequenza a quattro byte in ogni input. I numeri di sequenza intendevano consentire a più firmatari di accettare di aggiornare una transazione; quando hanno terminato di aggiornare la transazione, potrebbero accettare di impostare il numero di sequenza di ogni input sul massimo senza segno a quattro byte (0xffffffff), consentendo di aggiungere la transazione a un blocco anche se il suo time lock non era scaduto.

Anche oggi, l'impostazione di tutti i numeri di sequenza su 0xffffffff (l'impostazione predefinita in Bitcoin Core) può ancora disattivare il blocco temporale, quindi se si desidera utilizzare l'intervallo, almeno un input deve avere un numero di sequenza inferiore al massimo. Poiché i numeri di sequenza non sono utilizzati dalla rete per nessun altro scopo, l'impostazione di un qualsiasi numero di sequenza su zero è sufficiente per abilitare il tempo di blocco.

Locktime stesso è un numero intero a 4 byte senza segno che può essere analizzato in due modi:

Se inferiore a 500 milioni, l'orario di blocco viene analizzato come altezza del blocco. La transazione può essere aggiunta a qualsiasi blocco che ha questa altezza o superiore.

Se maggiore o uguale a 500 milioni, l'orario di blocco viene analizzato utilizzando il formato dell'ora di epoca Unix (il numero di secondi trascorsi dal 1970-01-01T00: 00 UTC - attualmente oltre 1,395 miliardi). La transazione può essere aggiunta a qualsiasi blocco il cui tempo di blocco è maggiore del tempo di blocco.

Commissioni di transazione e Cambi

Le transazioni pagano le tasse in base alla dimensione totale dei byte della transazione firmata. Le tariffe per byte sono calcolate in base alla domanda corrente di spazio in blocchi estratti con commissioni in aumento all'aumentare della domanda. La commissione di transazione viene fornita al minatore Bitcoin, come spiegato nella sezione della catena di blocchi, quindi ciascun minatore deve scegliere la commissione minima di transazione che accetteranno.

C'è anche un concetto di cosiddette "transazioni ad alta priorità" che smuovono satoshi che non si sono spostati da molto tempo.

In passato, queste transazioni "prioritarie" erano spesso esentate dai normali requisiti tariffari. Prima di Bitcoin Core 0.12, 50 KB di ciascun blocco sarebbero riservati per queste transazioni ad alta priorità, tuttavia per impostazione predefinita ora è impostato su 0 KB. Dopo l'area di priorità, tutte le transazioni hanno la priorità in base alla tariffa per byte, mentre le transazioni che pagano commissioni più alte vengono aggiunte in sequenza fino a quando tutto lo spazio disponibile è stato riempito.

A partire da Bitcoin Core 0.9, è stata richiesta una commissione minima (attualmente 1.000 satoshi) per trasmettere una transazione attraverso la rete. Qualsiasi transazione che paghi solo la tariffa minima dovrebbe essere pronta ad aspettare molto tempo prima che ci sia abbastanza spazio libero in un blocco per includerla. Si prega di consultare la sezione “verifica dei pagamenti” in quanto argomento importante.

Poiché ogni transazione spende le uscite di transazione non spese (UTXO) e poiché un UTXO può essere speso una sola volta, il valore totale degli UTXO inclusi deve essere speso o dato a un minatore come una tassa di transazione. Poche persone avranno UTXO che corrispondono esattamente alla somma che vogliono pagare, quindi la maggior parte delle transazioni include un output di modifica (change output).

Gli output di modifica sono output regolari che spendono il surplus degli UTXO indietro allo spender (restituiscono il “resto” della transazione indietro al mittente). Possono riutilizzare lo stesso hash di pubkey P2PKH o hash di script P2SH utilizzato nell'UTXO, ma per le ragioni descritte nella sottosezione successiva, si consiglia vivamente di inviare gli output di cambiamento a un nuovo indirizzo P2PKH o P2SH.

Evitare il riutilizzo delle chiavi

In una transazione, lo spender e il ricevitore rivelano reciprocamente tutte le chiavi pubbliche o gli indirizzi utilizzati nella transazione. Ciò consente ad entrambe le persone di utilizzare la catena di blocchi pubblica per tenere traccia delle transazioni passate e future che coinvolgono le stesse chiavi o indirizzi pubblici dell'altro utente.

Se la stessa chiave pubblica viene riutilizzata spesso, come accade quando le persone usano gli indirizzi Bitcoin (hashed public key) come indirizzi di pagamento statici, altre persone possono facilmente rintracciare le abitudini di ricezione e spesa di quella persona, incluso il numero di satoshi che controllano negli indirizzi conosciuti.

Non deve essere così. Se ciascuna chiave pubblica viene utilizzata esattamente due volte - una volta per ricevere un pagamento e una volta per spendere quel pagamento - l'utente può ottenere una notevole quantità di riservatezza finanziaria.

Ancora meglio, l'utilizzo di nuove chiavi pubbliche o indirizzi univoci quando si accettano pagamenti o si creano output di cambiamento (change output) possono essere combinati con altre tecniche discusse in seguito, come CoinJoin o “merge avoidance”, per rendere estremamente difficile l'utilizzo della catena di blocchi da sola per tracciare in modo affidabile come gli utenti ricevono e spendono i loro satoshi.

Evitare il riutilizzo delle chiavi può anche fornire sicurezza contro gli attacchi che potrebbero consentire la ricostruzione di chiavi private da chiavi pubbliche (ipotizzate) o da confronti con le firme (possibili oggi in determinate circostanze descritte di seguito, con ipotesi più generali ipotizzate).

1.Gli indirizzi P2PKH e P2SH univoci (non riutilizzati) proteggono dal primo tipo di attacco mantenendo le chiavi pubbliche ECDSA nascoste (hash) fino a quando la prima volta che vengono inviati i satoshi a tali indirizzi vengono utilizzate, quindi gli attacchi sono effettivamente inutili a meno che non possano ricostruire le chiavi private in meno di un'ora o due per una transazione ben protetta dalla catena di blocchi.

2.Le chiavi private univoche (non riutilizzate) proteggono dal secondo tipo di attacco generando solo una firma per chiave privata, pertanto gli autori di attacchi non ottengono mai una firma successiva da utilizzare negli attacchi basati sui confronti. Gli attuali attacchi basati sul confronto sono pratici solo quando l'entropia è insufficiente per la firma o quando l'entropia utilizzata è esposta in qualche modo, come un attacco di canale laterale (side-channel attack).

Pertanto, sia per la privacy che per la sicurezza, ti invitiamo a creare le tue applicazioni per evitare il riutilizzo delle chiavi pubbliche e, quando possibile, scoraggiare gli utenti dal riutilizzare gli indirizzi. Se l'applicazione deve fornire un URI fisso a cui devono essere inviati i pagamenti, vedere la sezione bitcoin: URI di seguito.

Malleabilità di transazione

Nessuno dei tipi di hash delle firme di Bitcoin protegge lo script della firma, lasciando aperta la porta per un limitato attacco denial of service chiamato Transaction Malleability. Lo script della firma contiene la firma secp256k1, che non può firmare se stessa, consentendo agli autori di attacchi di apportare modifiche non funzionali a una transazione senza renderla non valida. Ad esempio, un utente malintenzionato può aggiungere alcuni dati allo script della firma che verrà eliminato prima che venga elaborato lo script pubkey precedente.

Sebbene le modifiche non siano funzionali, in questo modo non cambiano gli input utilizzati dalla transazione né gli output che paga, cambiano però l'hash della transazione calcolato. Poiché ogni transazione si collega a transazioni precedenti usando hash come identificativo di transazione (txid), una transazione modificata non avrà il txid che il suo creatore si aspetta.

Questo non è un problema per la maggior parte delle transazioni Bitcoin che sono progettate per essere aggiunte immediatamente alla catena di blocchi. Ma diventa un problema quando l'output di una transazione viene speso prima che la transazione venga aggiunta alla catena di blocchi.

Gli sviluppatori di Bitcoin hanno lavorato per ridurre la malleabilità delle transazioni tra i tipi di transazione standard, un risultato di tali sforzi è BIP 141: Segregated Witness, che è supportato da Bitcoin Core ed è stato attivato ad agosto 2017. Quando SegWit non viene utilizzato, le nuove transazioni non dovrebbero dipendere da transazioni precedenti che non sono state ancora aggiunte alla catena di blocchi, specialmente se sono in gioco grandi quantità di satoshi.

La malleabilità delle transazioni influisce anche sul tracciamento dei pagamenti. L'interfaccia RPC di Bitcoin Core ti consente di tracciare le transazioni tramite il loro txid, ma se quel txid cambia perché la transazione è stata modificata, può sembrare che la transazione sia scomparsa dalla rete.

Le best practice attuale per il tracciamento delle transazioni indica che una transazione deve essere tracciata dagli output delle transazioni (UTXO) che spende come input, in quanto non possono essere modificati senza invalidare la transazione.