Con Bitcoin è possibile realizzare script complessi con condizioni di spesa più articolate, dai multisig ad altre tipologie. Come funzionavano questi script prima dell’introduzione di P2SH ? Quali problemi affronta e risolve l’introduzione di P2SH ? In questo video andiamo ad esaminare questi temi da un profilo tecnico e con esempi.
COMMENTI DI GIACOMO ZUCCO E ULTERIORE APPROFONDIMENTO:
La maggior parte dei casi d’uso reali usano delle policy standard, dove i wallet sanno ricostruire lo script sulla base di pochi dati che l’utente deve ricordare (n chiavi, di cui m firme, segwit nativo oppure incapsulato oppure legacy). Per esempio in specter non devi neanche ricordare ORDINE delle chiavi, che é sempre lessicografico. Se peró usi una policy strana, cosa che si puó fare tipo importando un descriptor in Sparrow, allora la devi salvare.
Nota aggiuntiva: prima di taproot, lo script ha una dimensione massima (quella del blocco in pratica). Se tu conosci bene almeno le chiavi che compongono lo script e i tipi di opcode, in teoria puoi bruteforzare tutte le permutazioni, fino a che trovi l’hash giusto. Invece in taproot lo spazio teorico dell’intero tapscript é infinito (solo la branch che riveli deve rispettare limite). Quindi ancora piú facile perdere script.
Nella vita di Bitcoin si é passati da una fase iniziale in cui dovevi salvarti e tenerti per sempre un backup per OGNI ricezione (dentro il wallet.dat, con le chiavi non deterministiche), a una fase bip32 pura in cui basta la seed phrase e recuperi tutto, alla fase attuale in cui questo non é piú vero: p2sh, taproot (soprattutto), stati dei canali LN!
