A₿del fgu's avatar
A₿del fgu
abdel@snort.social
npub1hr6v...2e29
If you want to change the world, don't protest. Write code!
A₿del fgu's avatar
Abdel 5 months ago
Built a proof of concept of Bitcoin vaults to showcase CTV & CSFS on Mutinynet signet. Basic vault: Funds locked to a P2TR output with a single leaf CTV script committing to a trigger tx template. Trigger moves to a conditional P2TR: IF branch requires CSV delay + hot key sig; ELSE is CTV to cold address (immediate, no sig). NUMS internal key forces script spends. Hybrid vault extends to two leaves: One for CTV path (same as basic). Second for CSFS: Verifies a Schnorr sig over a delegation message (e.g., "EMERGENCY_DELEGATION:AMOUNT=...:RECIPIENT=...:EXPIRY=...:VAULT=...") from treasurer key, allowing direct spend to recipient (escape hatch). Demo flow 1: Cold clawback via CTV. Fund vault P2TR. Broadcast trigger (satisfies CTV from vault). Then broadcast cold tx from trigger (ELSE branch, satisfies CTV to cold). No delay. Works as emergency response if trigger detected (e.g., hot key compromise). Demo flow 2: Delegation via CSFS. Treasurer signs message authorizing ops team to spend X sats to Y by Z block (though the amount and other dynamic transaction params are not enforced in the demo, would require OP_AMOUNT, might be possible forcing the spender to provide the transaction data in the witness, check the signature of the tx data with CSFS, and then introspect the transaction elements we want like the amount, but not sure the parsing / splitting of the transaction elements would be practical). Spend vault directly via CSFS leaf: Witness includes sig, message hash, treasurer pubkey, script, control. Bypasses CTV/timelock for authorized emergencies.
A₿del fgu's avatar
Abdel 6 months ago
Running Bitcoin ZK Knots, baby! We've successfully run a POC verifying a STARK proof of Bitcoin's mainnet block #1 inside a modified Bitcoin Knots client. The proof validates critical consensus rules: - Timestamp - Chain difficulty - Block difficulty - Proof of Work Here’s the technical flow: - A Cairo program defines the block header consensus rules & generates the execution trace: - The STWO prover generates the STARK proof from the trace: - A modified ProcessNewBlockHeaders function in Bitcoin Knots performs the proof verification: The main purpose of this POC was to test the integration of our Rust-based proving stack into the C++ codebase. The ultimate vision? To improve Initial Block Download (IBD) dramatically by allowing the entire chain's validity to be verified with a single recursive proof. Once Raito is fully equipped with recursive proving and strong performance, we'll be back to implement a full, real-world IBD with ZK verification enabled. Stay tuned! Follow our StarkWare Bitcoin Github for updates:
A₿del fgu's avatar
Abdel 6 months ago
Decentralized mining on Bitcoin is an important area. We've developed a prototype within Stratum v2 that leverages STARK proofs to achieve a more trustless system and better preserve the strategies of individual miners. Our demo shows the individual miner (JD client) generating a STARK proof for the validity of the coinbase transaction and the total fees of the block template, all without disclosing the list of transactions. The JD server can then verify this STARK proof, confirming the block template's validity and the claimed sum of fees, without gaining any knowledge about the specific transactions. This also provides an advantage for mining pools from a regulatory perspective due to plausible deniability, which in turn improves the network's censorship resistance. While this is currently a proof of concept, our goal is to extend it to include full transaction validity in the future. We're keen to collaborate with teams working on decentralized mining and will also be exploring this with Datum. #Bitcoin #DecentralizedMining #StratumV2 #Datum #STARKs #ZeroKnowledgeProof
A₿del fgu's avatar
Abdel 6 months ago
Hey, any Bitcoiner in Prague tomorrow? I won’t be there but have few colleagues from StarkWare who will be there and would love to meet more Bitcoiners. If you wanna hang out with them and chat about Bitcoin in general and / or zero knowledge proofs let me know.
A₿del fgu's avatar
Abdel 6 months ago
Posting here for more visibility on Nostr. CTV + CSFS: a letter to the technical bitcoin community from 43 engineers Full text at ctv-csfs.com Let’s accelerate and improve Bitcoin as money and as a tool that people can use to take back their sovereignty. CTV and CSFS can improve significantly Lightning network and have many other benefits. Study them, discuss them, share your opinions, debate. Hyperbitcoinization intensifies. image
A₿del fgu's avatar
Abdel 7 months ago
Stateful computation on Bitcoin mainnet without Fraud Proofs has been achieved internally with ColliderVM . It's a toy implementation to demonstrate the concepts. We can already do covenants on Bitcoin, now we are simply negotiating the price 😘 What are the interesting properties that ColliderVM could bring on the table: - Capital efficient: no fraud proof windows - 1-of-n security model for safety and liveness - No protocol upgrades / soft fork required - Immediate settlement without challenges The problem: Bitcoin's scripting language is intentionally limited, making stateful computation challenging. In particular: - No native statefulness: Bitcoin Script lacks loops, has size restrictions, and can't persist data across transactions - Capital inefficiency: Existing solutions like BitVM2 require operators to lock capital during fraud proof windows - Trust assumptions: Current approaches often require trusted setups or weaker security models In short, what you need to achieve stateful computation on Bitcoin is really those 2 properties: - Logic persistence (the code of the program / computation must remain consistent across transactions) - Data persistence (otherwise you are vulnerable to the inconsistent input problem) ColliderVM is an attempt to overcome those challenges in a different manner than BitVM. But before going deeper, let's be clear on the current status of ColliderVM: ColliderVM is currently a research project and should not be used in production environments. The protocol is in active development and exploration phase. While the theoretical foundations are promising, it remains unclear whether ColliderVM will prove practical for meaningful real-world use cases. Significant research and development work is still required to determine its viability. Ok, now that this important disclaimer is done, let's explore more the context of this demo on mainnet. In short, ColliderVM combines presigned transactions with hash collision puzzles to enable stateful computation without fraud proofs. - Presigned flows: Create 2^L parallel transaction flows during offline setup phase, each corresponding to a unique flow identifier. - Hash Collision Puzzle: Operators find nonce r such that H(x,r)|_B matches a flow ID, ensuring input consistency across transactions. - Immediate Settlement: No fraud proof windows or capital lock-up. So, what did we do for this Mainnet demo ? Real Bitcoin transactions demonstrating a ColliderVM's two-step range check computation: verifying that 100 < x < 200 across separate onchain transactions. The range check computation was split in 2 functions (F1: x > 100, F2: x < 200). The onchain hash function used is blake3 (BitVM implementation). Here is the transaction flow of the demo: - Funding transaction: Initial funding transaction that provides the UTXO for the ColliderVM computation sequence.( - F1 transaction: validates that the input value (114) is greater than the lower bound (100) ( - F2 transaction: validates that the input value (114) is less than the upper bound (200). Larger due to hash collision verification. ( - Spending transaction: Final transaction that releases the funds after successful verification of the range check computation. ( ColliderVM parameters used for the demo (very low security): - L: 4 bits, set size of 16 possible flows - B: 16 bits, hash prefix length for collision puzzle - Security gap: 6 bits (B - L/2 = 16 - 2 = 14 vs honest 12 bits) Total transaction fees: 172,126 sats (~$179 at demo time). ~136 kB of total onchain data. ColliderVM toy code: ColliderVM paper: image
A₿del fgu's avatar
Abdel 7 months ago
Just run a node anon. And yeah you can choose whatever implementation you want. That’s good. Personally I prefer running Core and I don’t consider Knots being a production grade serious alternative on par with Core in terms of open source and software best practices (and there are obvious reasons for this to be the case, and it does not mean it could not change), but the choice is yours and it’s fine if you switch to Knots as a voice of protest. I think client diversity is a healthy debate to have at the end of the day, so maybe the filters drama was a good excuse to put it on the table I don’t know. I think there is a lot of bad faith arguments from some people pushing users to switch to Knots but that’s fine, Bitcoin is resilient and does not care about those drama. But yeah, just run a node, it really matters.
A₿del fgu's avatar
Abdel 7 months ago
Bitcoin decentralised mining: pools should trust the math, not the miner, and miners should gain privacy for their transaction selection which improves censorship resistance of the network. Stay tuned. Stratum V2 + STARK proofs 👀
A₿del fgu's avatar
Abdel 7 months ago
Gm to those running a well maintained software following best practices of open source development.
A₿del fgu's avatar
Abdel 7 months ago
Filters are cool but have you tried verifying a STARK proof with OP_CAT on a signet. Peak spam at its finest. image
A₿del fgu's avatar
Abdel 7 months ago
“To be truly radical is to make hope possible, rather than despair convincing.” - Raymond Williams Bitcoin is radical hope for the world, seriously. Let’s fight, TATAKAE! image
A₿del fgu's avatar
Abdel 8 months ago
be me: yesterday I found randomly a paper about 2 Circle STARK friendly hash functions working with Mersenne M31 (RPO-M31 and XHash-M31: Efficient Hash Functions for Circle STARKs by Tomer Ashur1 and Sundas Tariq) then i was: ohhh wow, looks interesting. then: write a rust implementation then start thinking: wait, maybe it could be a good candidate for a Circle STARK friendly AND Bitcoin Script friendly hash function then: start doing analysis and cost estimate then realise that they would NOT be practical to implement in Bitcoin Script... It's a pity for this but still it's very interesting hash functions, and the fact that they natively work with M31 is super promising. Maybe it's worth building a Cairo and Solidity implementation and benchmark the costs. They might be more interesting to use than Poseidon for Circle STARKs M31. Paper: https://eprint.iacr.org/2024/1635.pdf Rust repo: image
A₿del fgu's avatar
Abdel 9 months ago
Gm from Hong Kong Nostriches. image