deploy: f1fbec5

Author: adamjonas

categories/index.html

@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Categories on ₿itcoin Transcripts</title><link>https://btctranscripts.com/categories/</link><description>Recent content in Categories on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 21 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/categories/index.xml" rel="self" type="application/rss+xml"/><item><title>Entertainment</title><link>https://btctranscripts.com/categories/entertainment/</link><pubDate>Wed, 21 Jan 2026 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/entertainment/</guid><description/></item><item><title>podcast</title><link>https://btctranscripts.com/categories/podcast/</link><pubDate>Thu, 06 Nov 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/podcast/</guid><description/></item><item><title>Science &amp; Technology</title><link>https://btctranscripts.com/categories/science-technology/</link><pubDate>Fri, 31 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/science-technology/</guid><description/></item><item><title>Education</title><link>https://btctranscripts.com/categories/education/</link><pubDate>Fri, 20 Dec 2024 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/education/</guid><description/></item></channel></rss>
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Categories on ₿itcoin Transcripts</title><link>https://btctranscripts.com/categories/</link><description>Recent content in Categories on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 21 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/categories/index.xml" rel="self" type="application/rss+xml"/><item><title>Entertainment</title><link>https://btctranscripts.com/categories/entertainment/</link><pubDate>Wed, 21 Jan 2026 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/entertainment/</guid><description/></item><item><title>podcast</title><link>https://btctranscripts.com/categories/podcast/</link><pubDate>Thu, 06 Nov 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/podcast/</guid><description/></item><item><title>Science &amp; Technology</title><link>https://btctranscripts.com/categories/science-technology/</link><pubDate>Fri, 31 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/science-technology/</guid><description/></item><item><title>Scripts and Addresses</title><link>https://btctranscripts.com/categories/scripts-and-addresses/</link><pubDate>Thu, 30 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/scripts-and-addresses/</guid><description/></item><item><title>Security Enhancements</title><link>https://btctranscripts.com/categories/security-enhancements/</link><pubDate>Thu, 30 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/security-enhancements/</guid><description/></item><item><title>Soft Forks</title><link>https://btctranscripts.com/categories/soft-forks/</link><pubDate>Thu, 30 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/soft-forks/</guid><description/></item><item><title>Education</title><link>https://btctranscripts.com/categories/education/</link><pubDate>Fri, 20 Dec 2024 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/categories/education/</guid><description/></item></channel></rss>

categories/index.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Scripts and Addresses on ₿itcoin Transcripts</title><link>https://btctranscripts.com/categories/scripts-and-addresses/</link><description>Recent content in Scripts and Addresses on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 30 Oct 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/categories/scripts-and-addresses/index.xml" rel="self" type="application/rss+xml"/><item><title>Post Quantum CISA: Signature Aggregation for Bitcoin’s Future</title><link>https://btctranscripts.com/tabconf/2025/post-quantum-cisa-signature-aggregation-for-bitcoins-future/</link><pubDate>Thu, 30 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/tabconf/2025/post-quantum-cisa-signature-aggregation-for-bitcoins-future/</guid><description>&lt;p>This talk introduces a novel approach to cross-input signature aggregation (CISA) designed to work with post-quantum (hash-based) signature schemes, addressing one of Bitcoin&amp;rsquo;s most pressing scalability concerns in a post-quantum world.&lt;/p>
+&lt;p>The speaker begins by explaining elliptic curve CISA: in a Bitcoin transaction with multiple inputs from the same wallet, each input currently requires its own signature. CISA allows these to be combined into a single aggregate signature, saving block space. However, with EC signatures at ~64 bytes and the 75% witness discount, the savings are only ~8% in vbytes - modest enough that CISA hasn&amp;rsquo;t been prioritized for a soft fork.&lt;/p>
+&lt;p>Post-quantum signatures change the calculus dramatically. Schemes like SPhInXs Plus produce signatures of ~4 kilobytes - roughly 50x larger than EC signatures. If Bitcoin ever needs to migrate to post-quantum cryptography, transaction throughput could drop to around 2% of current capacity. In this context, aggregation becomes critical: two inputs aggregated would yield ~50% space savings, three inputs ~60% or more.&lt;/p>
+&lt;p>The fundamental challenge is that all existing EC aggregation techniques (MuSig2, FROST, half-aggregation, etc.) rely on elliptic curve math that simply does not apply to hash-based or lattice-based signatures.&lt;/p>
+&lt;p>The speaker proposes a new opcode (informally called OpCSIV) that sidesteps this problem entirely. Instead of cryptographically combining signatures, inputs can point to other inputs. One input provides a full signature (covering the entire transaction via SIGHASH_ALL), while other inputs include a hash-based pointer - the outpoint (TXID + index) of the signing input - baked into their taproot tree at address creation time. The opcode verifies that the referenced outpoint is being spent in the same transaction, effectively delegating signing authority without any new cryptographic primitives.&lt;/p>
+&lt;p>Key design details include: an input index field for O(n) rather than O(n²) lookup complexity; a random nonce for privacy blinding to prevent chain analysis of uncommitted taproot branches; and the constraint that the &amp;ldquo;lead&amp;rdquo; UTXO must exist before the &amp;ldquo;follower&amp;rdquo; address is generated. No cycles are possible since outpoints are unique, and there are no replay attack vectors.&lt;/p>
+&lt;p>Wallet integration requires careful design: wallets should embed pointers to currently owned UTXOs in new address taproot trees (limited to ~10 for recovery feasibility), while always retaining a primary signing path so no UTXO becomes unspendable. The approach works best with sequential address generation rather than bulk address pre-generation, and is particularly beneficial for exchanges performing frequent UTXO consolidations.&lt;/p>
+&lt;p>The speaker notes that this opcode would be pointless today given small EC signatures, but would be highly valuable if Bitcoin ever transitions to post-quantum signatures.&lt;/p></description></item></channel></rss>

categories/scripts-and-addresses/index.html

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Security Enhancements on ₿itcoin Transcripts</title><link>https://btctranscripts.com/categories/security-enhancements/</link><description>Recent content in Security Enhancements on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 30 Oct 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/categories/security-enhancements/index.xml" rel="self" type="application/rss+xml"/><item><title>Post Quantum CISA: Signature Aggregation for Bitcoin’s Future</title><link>https://btctranscripts.com/tabconf/2025/post-quantum-cisa-signature-aggregation-for-bitcoins-future/</link><pubDate>Thu, 30 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/tabconf/2025/post-quantum-cisa-signature-aggregation-for-bitcoins-future/</guid><description>&lt;p>This talk introduces a novel approach to cross-input signature aggregation (CISA) designed to work with post-quantum (hash-based) signature schemes, addressing one of Bitcoin&amp;rsquo;s most pressing scalability concerns in a post-quantum world.&lt;/p>
+&lt;p>The speaker begins by explaining elliptic curve CISA: in a Bitcoin transaction with multiple inputs from the same wallet, each input currently requires its own signature. CISA allows these to be combined into a single aggregate signature, saving block space. However, with EC signatures at ~64 bytes and the 75% witness discount, the savings are only ~8% in vbytes - modest enough that CISA hasn&amp;rsquo;t been prioritized for a soft fork.&lt;/p>
+&lt;p>Post-quantum signatures change the calculus dramatically. Schemes like SPhInXs Plus produce signatures of ~4 kilobytes - roughly 50x larger than EC signatures. If Bitcoin ever needs to migrate to post-quantum cryptography, transaction throughput could drop to around 2% of current capacity. In this context, aggregation becomes critical: two inputs aggregated would yield ~50% space savings, three inputs ~60% or more.&lt;/p>
+&lt;p>The fundamental challenge is that all existing EC aggregation techniques (MuSig2, FROST, half-aggregation, etc.) rely on elliptic curve math that simply does not apply to hash-based or lattice-based signatures.&lt;/p>
+&lt;p>The speaker proposes a new opcode (informally called OpCSIV) that sidesteps this problem entirely. Instead of cryptographically combining signatures, inputs can point to other inputs. One input provides a full signature (covering the entire transaction via SIGHASH_ALL), while other inputs include a hash-based pointer - the outpoint (TXID + index) of the signing input - baked into their taproot tree at address creation time. The opcode verifies that the referenced outpoint is being spent in the same transaction, effectively delegating signing authority without any new cryptographic primitives.&lt;/p>
+&lt;p>Key design details include: an input index field for O(n) rather than O(n²) lookup complexity; a random nonce for privacy blinding to prevent chain analysis of uncommitted taproot branches; and the constraint that the &amp;ldquo;lead&amp;rdquo; UTXO must exist before the &amp;ldquo;follower&amp;rdquo; address is generated. No cycles are possible since outpoints are unique, and there are no replay attack vectors.&lt;/p>
+&lt;p>Wallet integration requires careful design: wallets should embed pointers to currently owned UTXOs in new address taproot trees (limited to ~10 for recovery feasibility), while always retaining a primary signing path so no UTXO becomes unspendable. The approach works best with sequential address generation rather than bulk address pre-generation, and is particularly beneficial for exchanges performing frequent UTXO consolidations.&lt;/p>
+&lt;p>The speaker notes that this opcode would be pointless today given small EC signatures, but would be highly valuable if Bitcoin ever transitions to post-quantum signatures.&lt;/p></description></item></channel></rss>

categories/scripts-and-addresses/index.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Soft Forks on ₿itcoin Transcripts</title><link>https://btctranscripts.com/categories/soft-forks/</link><description>Recent content in Soft Forks on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 30 Oct 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/categories/soft-forks/index.xml" rel="self" type="application/rss+xml"/><item><title>Post Quantum CISA: Signature Aggregation for Bitcoin’s Future</title><link>https://btctranscripts.com/tabconf/2025/post-quantum-cisa-signature-aggregation-for-bitcoins-future/</link><pubDate>Thu, 30 Oct 2025 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/tabconf/2025/post-quantum-cisa-signature-aggregation-for-bitcoins-future/</guid><description>&lt;p>This talk introduces a novel approach to cross-input signature aggregation (CISA) designed to work with post-quantum (hash-based) signature schemes, addressing one of Bitcoin&amp;rsquo;s most pressing scalability concerns in a post-quantum world.&lt;/p>
+&lt;p>The speaker begins by explaining elliptic curve CISA: in a Bitcoin transaction with multiple inputs from the same wallet, each input currently requires its own signature. CISA allows these to be combined into a single aggregate signature, saving block space. However, with EC signatures at ~64 bytes and the 75% witness discount, the savings are only ~8% in vbytes - modest enough that CISA hasn&amp;rsquo;t been prioritized for a soft fork.&lt;/p>
+&lt;p>Post-quantum signatures change the calculus dramatically. Schemes like SPhInXs Plus produce signatures of ~4 kilobytes - roughly 50x larger than EC signatures. If Bitcoin ever needs to migrate to post-quantum cryptography, transaction throughput could drop to around 2% of current capacity. In this context, aggregation becomes critical: two inputs aggregated would yield ~50% space savings, three inputs ~60% or more.&lt;/p>
+&lt;p>The fundamental challenge is that all existing EC aggregation techniques (MuSig2, FROST, half-aggregation, etc.) rely on elliptic curve math that simply does not apply to hash-based or lattice-based signatures.&lt;/p>
+&lt;p>The speaker proposes a new opcode (informally called OpCSIV) that sidesteps this problem entirely. Instead of cryptographically combining signatures, inputs can point to other inputs. One input provides a full signature (covering the entire transaction via SIGHASH_ALL), while other inputs include a hash-based pointer - the outpoint (TXID + index) of the signing input - baked into their taproot tree at address creation time. The opcode verifies that the referenced outpoint is being spent in the same transaction, effectively delegating signing authority without any new cryptographic primitives.&lt;/p>
+&lt;p>Key design details include: an input index field for O(n) rather than O(n²) lookup complexity; a random nonce for privacy blinding to prevent chain analysis of uncommitted taproot branches; and the constraint that the &amp;ldquo;lead&amp;rdquo; UTXO must exist before the &amp;ldquo;follower&amp;rdquo; address is generated. No cycles are possible since outpoints are unique, and there are no replay attack vectors.&lt;/p>
+&lt;p>Wallet integration requires careful design: wallets should embed pointers to currently owned UTXOs in new address taproot trees (limited to ~10 for recovery feasibility), while always retaining a primary signing path so no UTXO becomes unspendable. The approach works best with sequential address generation rather than bulk address pre-generation, and is particularly beneficial for exchanges performing frequent UTXO consolidations.&lt;/p>
+&lt;p>The speaker notes that this opcode would be pointless today given small EC signatures, but would be highly valuable if Bitcoin ever transitions to post-quantum signatures.&lt;/p></description></item></channel></rss>