BIP
acronimo di: Bitcoin Improvement Proposal
BIP
acronimo di: Bitcoin Improvement Proposal
Difficoltà: avanzato
Argomento: tecnologia
DEFINIZIONE
Per far evolvere il protocollo Bitcoin, la comunità deve predisporre proposte sotto forma di documenti tecnici, noti come Bitcoin Improvement Proposals (BIP), e presentarli alla valutazione, discussione e approvazione della comunità Bitcoin. Questo processo di miglioramento del protocollo Bitcoin è essenziale per assicurare che il sistema rimanga al passo con i cambiamenti del mercato e le esigenze degli utenti.
Le proposte di miglioramento del protocollo sono numerate progressivamente per consentire una facile identificazione e tracciabilità, e l'adozione di queste migliorie può avere un impatto significativo sul funzionamento del protocollo stesso. In alcuni casi, per poter essere adottate, queste proposte richiedono un forte consenso nella comunità Bitcoin.
Il processo di approvazione di una proposta BIP è generalmente composto da un'analisi tecnica e un periodo di discussione tra i membri della comunità. Se la proposta viene accettata, viene integrata nel codice sorgente del protocollo Bitcoin e diventa parte della versione successiva del software Bitcoin.
Il protocollo Bitcoin è un sistema decentralizzato, quindi l'evoluzione del protocollo deve essere gestita in modo collaborativo, coinvolgendo la comunità di sviluppatori, miner e utenti di Bitcoin. In questo modo, gli aggiornamenti del protocollo diventano una responsabilità collettiva per la comunità, garantendo una maggiore sicurezza e affidabilità del sistema Bitcoin.
Chiunque può proporre un BIP.
L'autore del BIP è responsabile della costruzione del consenso all'interno della comunità e della documentazione delle opinioni dissenzienti.
Esiste anche un apposito BIP che definisce e documenta tale processo, il BIP-2.
Inizialmente il processo era definito dal BIP 1, scritta da Amir Taaki. Si basava quasi interamente sul modello delle PEP (Python Enhancement Proposals) di Python. Lo scopo era introdurre per la prima volta l'idea che Bitcoin non dovesse essere modificato "a braccio" nel codice, ma attraverso documenti formali discussi pubblicamente, ma era un po' generico.
La BIP 2, scritta da Luke Dashjr, è quella attualmente in vigore. Non ha "cancellato" la 1, ma l'ha sostituita e raffinata per adattarla a un ecosistema che era diventato molto più complesso e prezioso.
Nel definire una BIP ci sono alcune informazioni, o metadati, che indicano le caratteristiche del BIP.
Tra queste è presente il campo Layer, un metadato fondamentale introdotto per categorizzare l'ambito di applicazione della proposta.
I Valori del campo Layer
Il campo "Layer" indica a quale livello dello "stack" tecnologico di Bitcoin si riferisce la modifica proposta. I valori standard sono:
- Consensus (soft fork): Proposte che modificano le regole di validazione in modo restrittivo. Sono compatibili con le versioni precedenti (i vecchi nodi accettano i blocchi dei nuovi). Esempio: SegWit (BIP-141).
- Consensus (hard fork): Proposte che modificano le regole di validazione in modo non compatibile. Richiedono che tutti gli utenti aggiornino il software per rimanere sulla stessa catena.
- Peer Services: Modifiche al protocollo di rete (P2P), ovvero come i nodi comunicano tra loro, si scambiano blocchi o annunciano transazioni senza toccare le regole di consenso.
- API/RPC: Miglioramenti alle interfacce di programmazione (come le chiamate JSON-RPC di Bitcoin Core) o alle interfacce utilizzate dalle applicazioni esterne per interagire con il nodo.
- Applications: Proposte riguardanti standard che vivono "sopra" Bitcoin ma che richiedono coordinazione, come i formati degli indirizzi, gli schemi di portafoglio (HD Wallets) o protocolli di secondo livello.
Perché è importante?
Questo campo aiuta gli sviluppatori e la comunità a capire immediatamente l'impatto e il processo di approvazione necessario: una BIP di tipo Applications (come il formato mnemonico delle 12 parole) può essere adottata dai singoli wallet, mentre una di tipo Consensus richiede un coordinamento globale e un attivazione specifica da parte dei miner e dei nodi.
Ciclo di vita di una BIP
Il passaggio di una proposta da una semplice idea a uno standard ufficiale è un percorso a ostacoli fatto di revisioni tecniche e consenso della comunità. La BIP 2 definisce un workflow preciso (una "macchina a stati") che ogni documento deve seguire.
Ecco le tappe fondamentali del ciclo di vita di una BIP:
1. Fase Preliminare (L'Idea)
Prima di scrivere una riga di BIP, l'autore propone l'idea sulla Bitcoin-dev mailing list. Se la comunità non la "smonta" subito per difetti tecnici evidenti, si passa alla fase successiva.
2. Lo stato: Draft (Bozza)
L'autore scrive il documento seguendo il formato richiesto (inclusi i metadati come il campo Layer).
-
Viene assegnato un numero di BIP dall'editor (storicamente Luke Dashjr).
-
La BIP viene pubblicata nel repository GitHub ufficiale (
bitcoin/bips). -
In questa fase, il documento può subire modifiche continue in base ai feedback.
3. Lo stato: Proposed (Proposta)
Si passa a "Proposed" quando il design è considerato stabile e completo.
- Per le BIP di tipo Standard Track (specialmente quelle di Consensus), questo stato indica che esiste un'implementazione funzionante (codice) e che è pronta per essere testata seriamente o distribuita per il voto dei miner/nodi.
4. Lo stato: Final (Finale)
Questo è il traguardo. Una BIP diventa "Final" quando soddisfa criteri diversi in base al suo Layer:
-
Consensus: Deve essere attivata sulla rete principale (Mainnet) e accettata dalla maggioranza dei nodi.
-
Peer Services / API: Deve essere implementata in modo diffuso in almeno due client indipendenti (es. Bitcoin Core e Knots).
-
Applications: Deve essere adottata largamente dall'ecosistema (es. diversi wallet che usano lo stesso standard di indirizzi).
Altri stati possibili (Le "vie d'uscita")
Non tutte le proposte ce la fanno. La BIP 2 prevede anche:
-
Deferred: La proposta è valida ma messa "in pausa" perché non prioritaria.
-
Withdrawn: L'autore decide di ritirare la proposta.
-
Rejected: La proposta viene respinta dalla comunità o si dimostra tecnicamente fallace.
-
Active: Simile a Final, ma usato per BIP di tipo "Process" (regole interne) che non vengono mai "completate" ma restano in vigore.
Bitcoin Italia Podcast
In Italia BIP è anche la sigla di Bitcoin Italia Podcast, il podcast settimanale condotto da Rikki e Guybrush che dal 2019 vi portano alla scoperta dell'incredibile mondo del Bitcoin, una tecnologia rivoluzionaria spiegata con parole semplici.
- Vedi anche
- BIP 112 CSV (Check Sequence Verify)
- BIP 113 Median time-past
- BIP 118 (ANYPREVOUT)
- BIP 119 (CTV) (Check Template Verify)
- BIP 125 (RBF) (Replace-by-Fee)
- BIP 141 (Segregated Witness)
- BIP 158 (Block Filters for Light Clients)
- BIP 16 (P2SH) (Pay-to-Script-Hash)
- BIP 174 (PSBT) (Partially Signed Bitcoin Transaction Format) Formato di transazione Bitcoin parzialmente firmato
- BIP 179 (Name for payment recipient identifiers) Nome per gli identificatori del destinatario del pagamento
- BIP 21 (URI scheme)
- BIP 32 (HD Wallet)
- BIP 322 Generic Signed Message Format
- BIP 34 (Block Height in Coinbase)
- BIP 340 (Schnorr Signatures)
- BIP 341 (Taproot)
- BIP 342 (Tapscript)
- BIP 38 (Passphrase-protected private key)
- BIP 39 (Mnemonic Phrases)
- BIP 44 (Derivation Paths for P2PKH)
- BIP 49 (Derivation Paths for Wrapped Segwit)
- BIP 68 nSequence
- BIP 69 (Lexicographical Indexing of Transaction Inputs and Outputs)
- BIP 8 (SFA) (Soft Fork Activation)
- BIP 84 (Derivation Paths for Native Segwit)
- BIP 9 (SFA) (Soft Fork Activation)
- BIP352 silent payments
- bLIP (Bitcoin Lightning Improvement Proposal)
aggiornato il 2023-03-30