Bitcoin Optech

Bitcoin Optech's avatar
Bitcoin Optech
npub1hkuk...432p
We provide weekly newsletters, workshops, case studies, and research for the #Bitcoin community.
Bitcoin Optech newsletter #387 is here: - warns of a wallet migration bug in Bitcoin Core - summarizes a post about using the Ark protocol as an LN channel factory - links to a draft BIP for silent payment descriptors - Optech Newsletter #387 Podcast Bitcoin Core posted a notice of a bug in the legacy wallet migration feature in versions 30.0 and 30.1... René Pickhardt wrote on Delving Bitcoin about his discussions and ideas around whether Ark’s best use case might be as a flexible channel factory rather than as an end-user payment solution... Craig Raw posted to the Bitcoin-Dev mailing list a proposal for a draft BIP, which defines a new top-level descriptor script expression sp() for silent payments... Bitcoin Optech will host an audio recap discussion of this newsletter on Tuesday at 17:30 UTC. Join us to discuss or ask questions!
Anthony Towns and Mikhail Kudinov joined Optech to discuss Newsletter #386: - A notice about the wallet migration bug in Bitcoin Core - Building a vault using blinded co-signers - BIP for Peer feature negotiation - Year 2106 timestamp overflow - BIP54 timestamp restriction for a timestamp overflow soft fork - Mitigating a CTV footgun - CTV activation meeting - OP_CHECKCONSOLIDATION to enable cheaper consolidations - Hash-based signatures post-quantum Bitcoin - And more You can listen on our website: Fountain: Spotify: Apple Podcasts:
Bitcoin Optech newsletter #386 is here: - summarizes a vault-like scheme using blinded MuSig2 - describes a proposal for Bitcoin clients to announce and negotiate support for new P2P features - links to 2106 timestamp overflow discussion and considerations around BIP54 - notes a CTV activation meeting and CTV footgun discussion - summarizes the OP_CHECKCONSOLIDATION proposal - links to a report of hash-based post-quantum signature schemes - Optech Newsletter #386 Podcast Jonathan T. Halseth posted to Delving Bitcoin a prototype of a vault-like scheme using blinded co-signers. Unlike traditional setups using co-signers, this scheme uses a blinded version of MuSig2 to ensure the signers know as little as possible about the funds they are involved in signing... Anthony Towns posted to the Bitcoin-Dev mailing list about a proposal for a new BIP to define a P2P message that would allow peers to announce and negotiate support for new features... Asher Haim posted to the Bitcoin-Dev mailing list asking Bitcoin developers to act promptly to prepare for a migration from uint32 to uint64 block timestamps... Josh Doman posted to the Bitcoin-Dev mailing list and Delving Bitcoin asking whether it’s might be worthwhile to modify the consensus cleanup proposal to be more permissive to odd block timestamp behavior to allow a potential soft fork solution to the 2106 block timestamp overflow issue... Chris Stewart posted to Delving Bitcoin a discussion of a “footgun” with OP_CHECKTEMPLATEVERIFY (CTV)... Developer 1440000bytes hosted a CTV (BIP119) activation meeting... billymcbip proposed an opcode specifically optimized for consolidations. OP_CHECKCONSOLIDATION (CC) would evaluate to 1 if and only if it’s executed on an input with the same scriptPubKey as an earlier input in the same transaction... Mikhail Kudinov and Jonas Nick posted to the Bitcoin-Dev mailing list about their work on evaluating hash-based signatures for use in Bitcoin... Bitcoin Optech will host an audio recap discussion of this newsletter on Tuesday at 17:30 UTC. Join us to discuss or ask questions!
Bruno Garcia and Liam Eagen joined Optech to discuss Newsletter #369: News 24:56 Update on differential fuzzing of Bitcoin and LN implementations 0:58 Garbled locks for accountable computing contracts Selected Q&A from Bitcoin Stack Exchange 39:45 Is it possible to recover a private key from an aggregate public key under strong assumptions? 41:24 Are all taproot addresses vulnerable to quantum computing? 45:20 Why cant we set the chainstate obfuscation key? 52:09 Is it possible to revoke a spending branch after a block height? 53:45 Configure Bitcoin Core to use onion nodes in addition to IPv4 and IPv6 nodes? Releases and release candidates 54:22 Bitcoin Core 29.1rc2 56:45 Core Lightning v25.09rc4 Notable code and documentation changes 57:37 Bitcoin Core #31802 1:04:46 LDK #3979 1:06:19 LND #10102 1:07:04 Rust Bitcoin #4907 You can listen on our website: Fountain: Spotify: Apple Podcasts:
Bitcoin Optech newsletter #347 is here: - describes upfront and hold fees in LN based on burnable outputs - summarizes discussion about testnets 3 and 4 - announces a plan to relay certain transactions containing taproot annexes - summarizes popular Q&A from Stack Exchange - Bitcoin Core 29.0rc2 - Optech Newsletter #347 Recap John Law posted to Delving Bitcoin the summary of a paper he’s written about a protocol nodes can use to charge two additional types of fees for forwarding payments... Sjors Provoost posted to the Bitcoin-Dev mailing list to ask whether anyone was still using testnet3 now that testnet4 has been available for about six months... Peter Todd announced to the Bitcoin-Dev mailing list his plan to update his Bitcoin Core-based node, Libre Relay, to begin relaying transactions containing taproot annexes if they follow particular rules... Selected Q&A from Bitcoin Stack Exchange: - Why is the witness commitment optional? - Can all consensus valid 64 byte transactions be (third party) malleated to change their size? - How long does it take for a transaction to propagate through the network? - Utility of longterm fee estimation - Why are two anchor outputs are used in the LN? - Why are there no BIPs in the 2xx range? - Why doesn’t Bech32 use the character “b”? - Bech32 error detection and correction reference implementation - How to safely spend/burn dust? - How is the refund transaction in Asymmetric Revocable Commitments constructed? - Which applications use ZMQ with Bitcoin Core? Bitcoin Core 29.0rc2 is a release candidate for the next major version of the network’s predominate full node. Please see the version 29 testing guide. Bitcoin Optech will host an audio recap discussion of this newsletter on Riverside.fm Tuesday at 15:30 UTC. Join us to discuss or ask questions!
Bitcoin Optech newsletter #345 is here: - looks at an analysis of P2P traffic experienced by a typical full node - summarizes research into LN pathfinding - describes a new approach for creating probabilistic payments - recaps the "Stricter internal handling of invalid blocks " PR Review Meeting - Optech Newsletter #345 Recap on Riverside Developer Virtu posted to Delving Bitcoin an analysis of the network traffic generated and received by his node in four different modes: initial block download (IBD), non-listening (outbound connections only), non-archival (pruned) listening, and archival listening... Sindura Saraswathi posted to Delving Bitcoin about research she conducted with Christian Kümmerle about finding optimal paths between LN nodes for sending payments in a single part... Robin Linus replied to the Delving Bitcoin thread about probabilistic payments with a conceptually simple script that allows two parties to each commit to an arbitrary amount of entropy that can later be revealed and xored together, to produce a value that can be used to determine which one of them receives a payment... 'Stricter internal handling of invalid blocks' is a PR by mzumsande that improves the correctness of two non-consensus-critical and expensive-to-calculate validation fields by immediately updating them when a block is marked as invalid... Bitcoin Optech will host an audio recap discussion of this newsletter on Riverside.fm Tuesday at 15:30 UTC. Join us to discuss or ask questions!
Bitcoin Optech newsletter #344 is here: - announces the disclosure of a vulnerability affecting old versions of LND - summarizes a discussion about the Bitcoin Core Project’s priorities - Changing consensus covering: Bitcoin Forking Guide, BIP360 pay-to-quantum-resistant-hash (P2QRH) updates, and Private block template marketplace to prevent centralizing MEV - Optech Newsletter #344 Recap on Riverside Matt Morehouse posted to Delving Bitcoin to announce the responsible disclosure of a vulnerability that affected LND versions before 0.18... Several blog posts by Antoine Poinsot about the future of the Bitcoin Core project were linked in a thread on Delving Bitcoin... Anthony Towns announced to Delving Bitcoin a guide to how to build community consensus for changes to Bitcoin’s consensus rules... Developer Hunter Beast posted an update on his research into quantum resistance for BIP360 to the Bitcoin-Dev mailing list... Matt Corallo and developer 7d5x9 posted to Delving Bitcoin about allowing parties to bid in public markets for selected space within miner block templates... Bitcoin Optech will host an audio recap discussion of this newsletter on Riverside.fm Tuesday at 15:30 UTC. Join us to discuss or ask questions!