Updates Jonas Nick's topic

_data/speakers.yml

@@ -27,12 +27,14 @@
   affiliation: Blockstream Research
   img: jnick.jpg
   bio:  Jonas Nick is a researcher in the field of Bitcoin, working as part of Blockstream's research team. He has made contributions to the Bitcoin community through his involvement in co-authoring various Bitcoin Improvement Proposals (BIPs), including the Taproot BIPs. Additionally, Jonas has collaborated on several scientific publications in cryptography, such as MuSig2 and Bulletproofs++ and contributes to the secp256k1 cryptographic library
-  topic: "No More Guesswork: Ready-to-Use Distributed Key Generation for FROST"
-  abstract: Threshold signature schemes such as FROST are gaining considerable attention in Bitcoin. Yet, Distributed Key Generation (DKG), with its heavy requirements on the underlying communication mechanisms such as secure channels and a secure broadcast mechanism, remains the Achilles heel of threshold signatures and holds back their deployment in the real world.
+  topic: "Shielded CSV: Private and Efficient Client-Side Validation"
+  abstract: The client-side validation approach removes transaction verification from the consensus rules. Instead, transaction data posted to the blockchain is only interpreted on each individual node ("client-side"). This approach allows building protocols with very low on-chain size and verification cost, while providing strong privacy.
             <br>
-            In this talk, we will first take a detailed look at the obstacles that implementers and practitioners face in practice. We will foster an understanding of potential pitfalls and attacks, in particular those that can arise from the (mis)use of reliable broadcast protocols. We will then provide recommendations and guidelines on how to avoid these pitfalls and implement broadcast securely in practice. A key technical ingredient in our recommendations is a simple extension of the Goldwasser-Bellare echo broadcast protocol, which we have not seen proposed in the context of DKG so far.
+            This session covers Shielded CSV, a novel client-side validation protocol that, in contrast to existing client-side validation protocols, only requires 64 bytes of on-chain space regardless of the size of the transaction and is fully private. The protocol's communication cost between transaction sender and receiver is independent of the transaction history. Furthermore, Shielded CSV can be instantiated with existing cryptographic zk-SNARK primitives.
             <br>
-            With these learnings in mind, we present ChillDKG, a DKG protocol that fully incorporates minimal but sufficient implementations of secure channels and reliable broadcast, and thereby hides this complexity from engineers entirely. The protocol addresses further practical problems by eliminating the need for fresh randomness per threshold setup and offering a practical solution for backups. To facilitate real-world adoption of ChillDKG, we have been working on a publicly available specification that aims to be comprehensive and easy to use
+            With a trust-minimized mechanism like BitVM2 to bridge between the blockchain and the client-side validation protocol, Shielded CSV adds strong privacy to Bitcoin and scales Bitcoin to 100 transactions per second. It has been described as "the most useful thing you can do with BitVM2".
+            <br>
+            Even without a bridge, Shielded CSV can be used to create a private cryptocurrency pegged to bitcoin (for example via the one-way peg) that offers substantial advantage over existing private cryptocurrencies. These currencies require users to validate all transactions, which contain relatively large and  computationally expensive Zero-Knowledge proofs. ShieldedCSV, however, only requires the recipient of a transaction to download the full transaction data, which results in significant reductions in computational and bandwidth costs. Furthermore, ShieldedCSV derives its resistance to double-spending from Bitcoin, eliminating the need for its own consensus mechanism.
 
 - name: Hannes Hartenstein
   id: hhartenstein