Glossario / Indirizzi e chiavi
Derivazione BIP-86
- Che cos'è la derivazione BIP-86?
- La derivazione BIP-86 colloca i conti Taproot a chiave singola in m/86'/0'/0', poi modifica ogni chiave derivata con un hash di se stessa, così l'indirizzo fissa un percorso di script non spendibile.
Specificato nel BIP-86.
Il BIP-86 riguarda i wallet che detengono output Taproot per un solo firmatario, riutilizzando la struttura dei conti del BIP-44 con 86' al livello purpose. Anche il BIP-49 e il BIP-84 definiscono un secondo passaggio per l'indirizzo, ma solo il BIP-86 cambia la chiave stessa: il valore di 32 byte nel tuo indirizzo è la chiave che hai derivato, modificata con un hash di se stessa. Ripristina le tue parole in un software che scansiona solo il BIP-84 e il saldo dei tuoi bc1p risulterà zero.
Come funziona
La derivazione BIP-86 avviene in due passaggi, e solo il primo è il consueto percorso lungo un albero di chiavi.
Il primo passaggio è il percorso. Il modello è m / purpose' / coin_type' / account' / change / address_index, con 86' nello slot purpose e ogni livello sottostante usato senza modifiche, quindi un primo conto bitcoin si trova in m/86'/0'/0' e la sua prima chiave di ricezione in m/86'/0'/0'/0/0.
Il secondo passaggio è dove il BIP-86 si separa dai suoi predecessori. Anche il BIP-49 e il BIP-84 definiscono un secondo passaggio, ma il loro avvolge la chiave derivata in uno script e il witness rivela comunque la chiave prodotta dal percorso. Il BIP-86 sostituisce la chiave. Cita il BIP-341 sulla regola che deve rispettare: "If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path." Quindi la chiave derivata viene letta come chiave interna tramite lift_x, e ciò che arriva alla catena è quella chiave interna più int(HashTapTweak(bytes(internal_key)))G. Il risultato è un singolo push di 32 byte dietro OP_1, scritto 0x5120 seguito dalla chiave modificata, e spenderlo richiede solo una firma nel witness con uno scriptSig vuoto.
I vettori di test pubblicati mostrano la differenza. In m/86'/0'/0'/0/0 la chiave interna derivata dal seed è cc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115, mentre la chiave che la rete vede è a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c, codificata come bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr. Un'implementazione che salta il secondo passaggio pubblica invece il primo valore, così ti consegna indirizzi dall'aspetto plausibile che un wallet conforme, ripristinando lo stesso seed, non troverà mai.
Ava Chow ha scritto il documento, assegnato il 22 giugno 2021, che ora ha lo stato Deployed.
Dove lo vedi
La derivazione BIP-86 è dietro la maggior parte dei wallet a firma singola che ti consegnano un indirizzo bc1p senza chiederti quale formato vuoi. Bitcoin Core ha reso i wallet con descrittori l'impostazione predefinita nella versione 23.0, e le note di rilascio di quella versione dicono che un wallet con descrittori appena creato contiene un descrittore tr() generato automaticamente "which allows for creating single key Taproot receiving addresses".
L'hardware si è allineato a velocità molto diverse. La nostra recensione di KeepKey data il supporto degli output Taproot di quel dispositivo al firmware 7.10.0, a febbraio 2025, quindi un firmatario economico può conservare un seed di cui non ti mostrerà il ramo 86', mentre altro software che legge le stesse parole spende quei bitcoin normalmente.
La specifica è insolitamente franca sul perché un percorso fisso sia ancora necessario. La sua sezione sulla motivazione riconosce che "there are now solutions which obviate the need for fixed derivation paths for specific script types", intendendo i descrittori, poi spiega perché non risolvono la questione: molti wallet software e firmatari hardware eseguono ancora il backup del solo seed, senza alcuna registrazione del percorso o del tipo di script accanto. Un descrittore porta con sé quell'informazione; una lista di parole no, quindi al suo posto la porta il numero 86.
Derivazione BIP-86 vs P2TR
La derivazione BIP-86 è una ricetta per riempire un output P2TR, non la definizione di uno. P2TR è la witness version 1 e accetta qualsiasi chiave di output di 32 byte, compresa una chiave aggregata da più firmatari con MuSig2 e una chiave che fissa un albero di script davvero utilizzabili. Il BIP-86 copre il caso più ristretto di quello spazio: un firmatario, un seed e un percorso di script lasciato di proposito non spendibile, così nulla si nasconde dietro la chiave. Ogni indirizzo che il BIP-86 produce è un output P2TR, e la maggior parte di ciò che P2TR può esprimere è del tutto fuori dalla sua portata, quindi un wallet che dichiara il supporto a Taproot può comunque rifiutare un ramo multisig o con timelock che porta lo stesso formato di indirizzo.