Yosh, questo è markstr, un POC per la risoluzione degli oracoli basata su Nostr per i mercati delle previsioni su Bitcoin, presentato su Mutinynet signet con CTV e CSFS attivati. Lo script di risoluzione dell'esito appare così: <outcome_message_hash> <oracle_pubkey> OP_CHECKSIGFROMSTACK L'oracolo deve firmare un particolare evento Nostr (con un contenuto del tipo: PredictionMarketId:SJ1IPWRX Esito:Sì - Bitcoin sopra $100k Timestamp:175284641) e la risoluzione dell'esito viene quindi verificata onchain utilizzando l'opcode CSFS. Il testimone per il percorso dello script taproot sarà quindi: firma (dell'esito hash / id evento Nostr), script (script di risoluzione mostrato sopra), control_block.

MODALITÀ GRINTA ATTIVATA. Adoro davvero il concetto di grinta, cattura perfettamente il mio stato d'animo attuale e la mentalità che voglio vedere di più in @StarkWareLtd e nell'ecosistema @Starknet. Grinta significa determinazione, risolutezza, tenacia. Ma queste traduzioni non catturano il fuoco completo di questo termine. È più come un'energia barbarica che scatena un potere pazzesco, la forza che ti fa continuare a giocare nonostante le incertezze, oltre i tuoi limiti. Ti trascende. Ho quella grinta ora, più che mai, perché voglio che la tecnologia della libertà vinca. Voglio che l'iperbitcoinizzazione colpisca il mondo nella mia generazione. Voglio un mondo con uno Standard Bitcoin per i miei figli. E voglio che libertà e sovranità siano la norma. Insieme a integrità computazionale e privacy. Chi attiva la modalità grinta con me? FGU. MODALITÀ GRINTA ATTIVA.

Stavo chiacchierando con il team di @getAlby riguardo al loro server Lightning MCP utilizzando Nostr Wallet Connect. L'ho forkato per integrare gli scambi atomici Lightning <> Starknet tramite il SDK di @atomiqlabs. Nella demo, ho avviato Claude Code e gli ho chiesto di gestire uno scambio end-to-end: "scambia 311 sats in STRK". Ha eseguito perfettamente, prelevando dal mio wallet @primal_app tramite la stringa di connessione NWC e eseguendo il . Completamente trustless (scambio sottomarino HTLC inverso). Tempi entusiasmanti per costruire app Bitcoin con l'AI. 🧡

Toolkit per il covenant di Bitcoin: Un'analisi approfondita di CTV e CSFS

Un saluto a tutti i massimalisti del bitcoin che hanno inondato la mia sezione commenti 2 anni fa dicendomi che ero un idiota per aver comprato affitti di famiglie singole e azioni con dividendi quando avrei potuto comprare Bitcoin. Voi siete i veri! 💯

Sì. @1440000bytes ha ragione, sono anche molto entusiasta dell'idea potenziale di verificare le firme degli eventi Nostr onchain su Bitcoin con CSFS. Potrebbe aprire molte interessanti possibilità d'uso. Ho aggiunto questa dimostrazione della verifica delle firme degli eventi Nostr nel repository Vault POC. <sig> = 8b3a1a5652e3bb18d0fcab1d8719008f8c837f1c0c815f36ff207ef0195bb9b2cf715f09418287804f85666a6a381c20241f82772536c98e48aa69f0f061d832 <nostr_eventid> = 4024c943979561551412b994453c1d119cc79ca7ea7bb9a5c407f665c464f7db <nostr_pubkey> = f7944cf4370f583ccf74af56d8e22bda77dc894e1165387d1607a1fe7dbae5a4 OP_CHECKSIGFROMSTACK

Costruito un proof of concept di Bitcoin vaults per mostrare CTV e CSFS su Mutinynet signet. Vault di base: Fondi bloccati su un output P2TR con uno script CTV a foglia singola che si impegna a un modello di transazione trigger. Il trigger si sposta su un P2TR condizionale: il ramo IF richiede un ritardo CSV + firma della chiave hot; ELSE è CTV a un indirizzo cold (immediato, senza firma). La chiave interna NUMS costringe le spese dello script. Il vault ibrido si estende a due foglie: Una per il percorso CTV (stesso del base). Seconda per CSFS: Verifica una firma Schnorr su un messaggio di delega (ad esempio, "EMERGENCY_DELEGATION:AMOUNT=...:RECIPIENT=...:EXPIRY=...:VAULT=...") dalla chiave del tesoriere, consentendo una spesa diretta al destinatario (via di fuga). Flusso demo 1: Recupero cold tramite CTV. Fondi vault P2TR. Trasmetti il trigger (soddisfa CTV dal vault). Poi trasmetti la transazione cold dal trigger (ramo ELSE, soddisfa CTV a cold). Nessun ritardo. Funziona come risposta di emergenza se viene rilevato il trigger (ad esempio, compromissione della chiave hot). Flusso demo 2: Delega tramite CSFS. Il tesoriere firma un messaggio che autorizza il team operativo a spendere X sats a Y entro il blocco Z (anche se l'importo e altri parametri di transazione dinamici non sono applicati nella demo, richiederebbero OP_AMOUNT, potrebbe essere possibile costringere il spenditore a fornire i dati della transazione nel testimone, controllare la firma dei dati della transazione con CSFS e poi ispezionare gli elementi della transazione che vogliamo come l'importo, ma non sono sicuro che il parsing/suddivisione degli elementi della transazione sarebbe pratico). Spendi direttamente il vault tramite la foglia CSFS: Il testimone include la firma, l'hash del messaggio, la chiave pubblica del tesoriere, lo script, il controllo. Salta CTV/ritardo temporale per emergenze autorizzate.

Starknet v0.14.0 è ora su testnet! ✅Decentralizzazione: più sequencer che eseguono il consenso ✅Veloce: pre-conferme in meno di un secondo Un passo importante verso una rete più decentralizzata e veloce. Leggi lo SNIP👇

Starknet / Cairo >>>>> EVM / Solidity Sistema di tipi: Cairo ha tipi forti, generici, tipi di dati algebrici, tratti. Solidity non ha generici e ha un pattern matching più debole. Proprietà / controllore di prestito al momento della compilazione: Cairo lo ha, semantiche di spostamento con proprietario singolo e regole di prestito che catturano l'uso dopo lo spostamento. La sicurezza della memoria di Solidity si basa sulla disciplina dello sviluppatore. Sicurezza aritmetica: Cairo utilizza matematiche verificate per impostazione predefinita. Solidity ora ha aritmetica verificata ma può essere disattivata. Cairo viene fornito con una rappresentazione intermedia (Sierra) che non può esprimere comportamenti indefiniti o un'asserzione che fallisce, ogni funzione è dimostrata per terminare al momento della compilazione. Modelli di aggiornamento: In Cairo si fa con syscall nativa per sostituire l'hash della classe mantenendo lo storage, imposto dalla prova, senza rischi di collisione nello storage proxy. In Solidity, i proxy sono realizzati a mano, le collisioni negli slot di storage e gli errori di delegatecall rappresentano un rischio. Cairo omette deliberatamente alcune funzionalità presenti in Solidity, come i modificatori, l'ereditarietà delle classi. Cairo favorisce la composabilità rispetto all'ereditarietà, il che aiuta a scrivere codice più pulito e modulare, rendendo più facile ragionare e controllare per difetti di sicurezza. Il design di Cairo elimina intere classi di bug prima che il codice venga compilato, mentre Solidity dipende da convenzioni come Checks Effects Interactions e linters esterni.