OP_CHECKSIGFROMSTACKVERIFY, OP_CHECKSIGFROMSTACK, OP_CSFS o più semplicemente CSFS, è un un opcode che consente di verificare un messaggio arbitrario rispetto a una firma. Può essere utilizzato per implementare una varietà di nuove funzionalità in Bitcoin, come ad esempio:

• Pagamento delle firme
• Delega
• Oracoli
• Vincoli di protezione da doppia spesa
• Introspezione delle transazioni

OP_CSFS ha il vantaggio di essere generico e flessibile, ma può anche aumentare la dimensione delle transazioni. Spesso viene proposto insieme a OP_CAT, che consente di concatenare due elementi insieme.

È un opcode su sidechain basate su ElementsProject.org che viene talvolta proposto per l'implementazione su Bitcoin. Questo opcode consente di verificare se una firma abbia firmato un messaggio arbitrario. L'opcode richiede tre parametri: una firma, un messaggio e una chiave pubblica.

Gli opcode esistenti di verifica delle firme di Bitcoin, come OP_CHECKSIG, non consentono di specificare un messaggio arbitrario. Il messaggio che utilizzano è derivato dalla transazione che esegue l'opcode di verifica della firma. Ciò consente di verificare che la firma corrisponda a una determinata chiave pubblica e che la chiave privata utilizzata per generare entrambi gli oggetti sia stata utilizzata per autorizzare la spesa. Questo meccanismo è abbastanza potente per garantire la sicurezza degli UTXO di Bitcoin, ma impedisce di utilizzare firme digitali per autenticare altri tipi di dati nel sistema Bitcoin. La capacità di utilizzare OP_CSFS per verificare un messaggio arbitrario può consentire diverse nuove funzionalità per gli utenti di Bitcoin:

• Pagamento delle firme: se Alice controlla una chiave privata che può firmare una transazione di pagamento a Bob, Bob può utilizzare OP_CSFS per offrire in modo affidabile di pagare Alice per la firma di cui ha bisogno.
  Recentemente, i protocolli che coinvolgono il pagamento delle firme assumono tipicamente l'uso di firme adattabili che sono più private e utilizzano meno spazio di blocco.

• Delega: Alice potrebbe voler delegare l'autorità di spendere le sue monete a Bob senza creare esplicitamente una transazione onchain che trasferisce le monete a un multisig 1-su-2 tra lei e Bob. Se Alice progetta i suoi script con questo tipo di delega in mente, può inserire la chiave pubblica di Bob in un messaggio e utilizzare OP_CSFS per dimostrare che ha delegato l'autorità di spesa a quella chiave.
  Un approccio alternativo più privato, più flessibile ed efficiente in termini di spazio di blocco è graftroot, anche se ciò richiede un soft fork che finora è stato solo appena discusso.

• Oracoli: un oracolo può accettare di firmare un messaggio che indica l'esito di un evento, ad esempio il nome della squadra nazionale che vince un evento sportivo. Due o più utenti possono quindi depositare denaro in uno script utilizzando OP_CSFS che pagherà una persona diversa a seconda della squadra che l'oracolo indica come vincitrice.
  L'attenzione più recente sui contratti moderati dagli oracoli coinvolge l'uso di contratti a log discreto (DLC), che possono essere più privati ed efficienti in termini di spazio di blocco.

• Bond di protezione contro la doppia spesa: un servizio può promettere di non cercare mai di spendere due volte i suoi UTXO al fine di incoraggiare i beneficiari ad accettare le sue transazioni non confermate come pagamenti affidabili. Per dimostrare la sua buona fede, il servizio può utilizzare OP_CSFS per offrire il pagamento di un bond a qualsiasi utente che riesca a dimostrare che la stessa chiave è stata utilizzata per creare due firme diverse per transazioni che spendono lo stesso UTXO. Questo utilizzo di OP_CSFS può essere paragonato a firme a singolo utilizzo che consentono a chiunque veda due firme dalla stessa chiave di derivare la chiave privata utilizzata per crearle, consentendo loro di spendere altri fondi protetti da quella chiave.

• Introspezione della transazione: se la stessa coppia di chiave pubblica e firma è valida sia con OP_CSFS che con OP_CHECKSIG, allora il contenuto del messaggio arbitrario passato a OP_CSFS è identico alla transazione di spesa serializzata (e altri dati) implicitamente utilizzata con OP_CHECKSIG. Questo rende possibile inserire una copia convalidata della transazione di spesa nello stack di valutazione dello script, dove altri opcode possono eseguire test su di essa al fine di imporre restrizioni sulla transazione di spesa.
  Ad esempio, se OP_CSFS fosse stato disponibile nel 2015 e nel 2016, sarebbe stato possibile implementare le funzionalità di BIP65 OP_CHECKLOCKTIMEVERIFY CLTV e BIP112 OP_CHECKSEQUENCEVERIFY CSV senza alcuna modifica del consenso semplicemente scrivendo uno script di verifica.
  Guardando avanti, OP_CSFS potrebbe anche consentire agli script di implementare le funzionalità dell'hash di firma proposto SIGHASH_ANYPREVOUT, così come altre proposte di opcode come OP_CHECKTEMPLATEVERIFY. Inoltre, OP_CSFS consentirebbe la creazione di vincoli che limitano il modo in cui un insieme di bitcoin può essere speso, ad esempio, una cassaforte potrebbe limitare la transazione di spesa a un piccolo insieme di scriptPubKeys accettabili per limitare il rischio di furto.
  Il punto di forza di OP_CSFS è che fornisce una piena introspezione della transazione di firma in modo completamente generico. Il suo punto debole è che richiede essenzialmente l'aggiunta di una copia completa della transazione di firma allo stack, il che potrebbe aumentare significativamente le dimensioni delle transazioni che desiderano utilizzare OP_CSFS per l'introspezione. In confronto, gli opcode di introspezione a scopo specifico come CLTV e CSV richiedono un overhead minimo, ma l'aggiunta di ciascun nuovo opcode di introspezione speciale richiede una modifica del consenso e potrebbe non essere possibile disabilitarne l'uso (anche se diventano impopolari) senza correre il rischio che qualcuno perda denaro.