Bitcoin Optech's avatar
Bitcoin Optech
_@bitcoinops.org
npub1hkuk...432p
We provide weekly newsletters, workshops, case studies, and research for the #Bitcoin community.
Bitcoin Optech newsletter #281 is here: - summarizes a discussion about griefing liquidity advertisements - summarizes changes to services/client software - summarizes popular Q&A from Stack Exchange - Optech Newsletter #281 Recap on Twitter Spaces Bastien Teinturier posted to the Lightning-Dev mailing list about a potential problem with timelocks on dual-funded channels created from liquidity advertisements... Changes to services and client software: - Stratum v2 mining pool launches - Bitcoin network simulation tool warnet announced - Payjoin client for Bitcoin Core released - Call for community block arrival timestamps - Envoy 1.4 released - BBQr encoding scheme announced - Zeus v0.8.0 released Selected Q&A from Bitcoin Stack Exchange: - What are all the rules related to CPFP fee bumping? - How is the total number of RBF replaced transactions calculated? - What types of RBF exist and which one does Bitcoin Core support and use by default? - What is the Block 1,983,702 Problem? - What are hash functions used for in bitcoin? Bitcoin Optech will host an audio recap discussion of this newsletter with special guest Bastien Teinturier on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1YpJkwPgyBjJj
Bitcoin Optech newsletter #279 is here: - summarizes an update to the liquidity advertisements specification - summarizes popular Q&A from Stack Exchange - Bitcoin Core 26.0rc3 - Optech Newsletter #279 Recap on Twitter Spaces Lisa Neigut posted to the Lightning-Dev mailing list to announce an update to the specification for liquidity advertisements... Selected Q&A from Bitcoin Stack Exchange: - Is Schnorr a multisignature interactive scheme? - Is it advisable to operate a release candidate full node on mainnet? - What is the relation between nLockTime and nSequence? - What would happen if we provide to OP_CHECKMULTISIG more than threshold number (m) of signatures? - What is “(mempool) policy”? - What does Pay to Contract (P2C) mean? - Can a non-segwit transaction be serialized in the segwit format? Bitcoin Core 26.0rc3 is a release candidate for the next major version of the predominant full-node implementation. There’s a testing guide available. Bitcoin Optech will host an audio recap discussion of this newsletter with special guest Lisa Neigut on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1OwGWYZdqaWxQ
Bitcoin Optech newsletter #278 is here: - describes a proposal to allow retrieval of LN offers using specific DNS addresses similar to lightning addresses - summarizes changes to services/client software - Bitcoin Core 26.0rc2 release candidate - Optech Newsletter #278 Recap on Twitter Spaces Bastien Teinturier posted to the Lightning-Dev mailing list about creating email-style addresses for LN users in a way that takes advantage of the features of the offers protocol... Changes to services and client software: - BitMask Wallet 0.6.3 released - Opcode documentation website announced - Athena Bitcoin adds Lightning support - Blixt v0.6.9 released - Durabit whitepaper announced - BitStream whitepaper announced - BitVM proof of concepts - Bitkit adds taproot send support Bitcoin Core 26.0rc2 is a release candidate for the next major version of the predominant full-node implementation. There’s a testing guide available. Bitcoin Optech will host an audio recap discussion of this newsletter with special guests Dave Harding, Bastien Teinturier, and Robin Linus on Twitter Spaces today (Wednesday) at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1ypKdkaaXDvxW
Bitcoin Optech newsletter #277 is here: - describes an update to the proposal for ephemeral anchors - includes a contributed field report that outlines miniscript's ecosystem adoption - provides Bitcoin Core 26.0rc2 testing materials - Optech Newsletter #277 Recap on Twitter Spaces Gregory Sanders posted to the Delving Bitcoin forum about a tweak to the ephemeral anchors proposal. That proposal would allow transactions to include a zero-value output with an anyone-can-spend output script... Field Report: A Miniscript Journey Antoine Poinsot from Wizardsardine describes their perspectives on miniscript adoption Bitcoin Core 26.0rc2 is a release candidate for the next major version of the predominant full node implementation. There’s a testing guide and a scheduled meeting of the Bitcoin Core PR Review Club dedicated to testing on 15 November 2023. Bitcoin Optech will host an audio recap discussion of this newsletter with special guests Dave Harding, Gregory Sanders, Antoine Poinsot, and Max Edwards on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1RDGlljdDeOGL
Bitcoin Optech newsletter #276 is here: - announces an upcoming change to the Bitcoin-Dev mailing list - briefly summarizes a proposal to allow aggregating multiple HTLCs together - recaps the "Fee Estimator updates from Validation Interface/CScheduler thread" PR Review Meeting - Bitcoin Core 26.0rc2 release candidate - Optech Newsletter #276 Recap on Twitter Spaces Administrators for the Bitcoin-Dev mailing list announced that the organization hosting the list plans to cease hosting any mailing lists after the end of the year. The administrators sought feedback from the community about options... Johan Torås Halseth posted to the Lightning-Dev mailing list a suggestion for using a covenant to aggregate multiple HTLCs into a single output that could be spent all at once if a party knew all the preimages... 'Fee Estimator updates from Validation Interface/CScheduler thread' is a PR by Abubakar Sadiq Ismail (ismaelsadeeq) that modifies the way the transaction fee estimator data is updated. It moves fee estimator updates from occurring synchronously during mempool updates to instead occur asynchronously... Bitcoin Core 26.0rc2 is a release candidate for the next major version of the predominant full node implementation. There’s a scheduled meeting of the Bitcoin Core PR Review Club dedicated to testing on 15 November 2023. Bitcoin Optech will host an audio recap discussion of this newsletter with special guests Johan Torås Halseth and Abubakar Ismail on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1gqxvQwkqOgJB
Bitcoin Optech newsletter #275 is here: - follows up on several recent discussions about proposed changes to Bitcoin’s scripting language - LDK 0.0.118, Rust Bitcoin 0.31.1 releases There were several replies on the Bitcoin-Dev mailing list to proposed scripting change discussions we’ve previously covered. Anthony Towns compares Rusty Russell’s approach to other approaches specifically for covenant-based vaults and finds it unappealing. Several people replied to Ethan Heilman’s post announcing a proposed BIP for OP_CAT... Bitcoin Optech will host an audio recap discussion of this newsletter on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1PlKQDwepbqxE
Bitcoin Optech newsletter #274 is here: - describes the replacement cycling attack against HTLCs used in LN and other systems, examines the mitigations deployed, and summarizes proposals for additional mitigations - notes a bug affecting a Bitcoin Core RPC - describes research into covenants with minimal changes to Bitcoin Script - announces a proposed BIP for an OP_CAT opcode - summarizes popular Q&A from Stack Exchange - Optech Newsletter #274 Recap on Twitter Spaces As briefly mentioned in last week’s newsletter, Antoine Riard posted to the Bitcoin-Dev and Lightning-Dev mailing lists about a responsibly disclosed vulnerability affecting all LN implementations. It’s possible to use transaction replacement to remove one or more inputs of a multi-input transaction from node mempools... Several mitigations have been deployed by LN implementations for replacement cycling... There have been over 40 separate posts made to the Bitcoin-Dev and Lightning-Dev mailing lists in response to the disclosure of the replacement cycling attack. Suggested responses included proposed additional mitigations... Fabian Jahr posted to the Bitcoin-Dev mailing list to announce that a bug had been discovered in Bitcoin Core’s calculation of the hash of the current UTXO set... Rusty Russell posted to the Bitcoin-Dev mailing list a link to some research he has performed about using a few simple new opcodes to allow a script being executed in a transaction to inspect the output scripts being paid in that same transaction, a powerful form of introspection... Ethan Heilman posted to the Bitcoin-Dev mailing list a proposed BIP to add an OP_CAT opcode to tapscript... Selected Q&A from Bitcoin Stack Exchange: - How does the Branch and Bound coin selection algorithm work? - Why is each transaction broadcast twice in the Bitcoin network? - Why are OP_MUL and OP_DIV disabled in Bitcoin? - Why are hashSequence and hashPrevouts computed separately? - Why does Miniscript add an extra size check for hash preimage comparisons? - How can the next block fee be less than the mempool purging fee rate? Bitcoin Core 26.0rc1 is a release candidate for the next major version of the predominant full node implementation... Bitcoin Optech will host an audio recap discussion of this newsletter with special guests Fabian Jahr and Ethan Heilman on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1rmxPMZzbYQKN
Bitcoin Optech newsletter #273 is here: - mentions a recent security disclosure affecting LN users - describes a paper about making payments contingent on the result of running arbitrary programs - announces a proposed BIP to add fields to PSBTs for MuSig2 - summarizes changes to services/client software - Bitcoin Core 24.2rc2 and Bitcoin Core 25.1rc1 release candidates - Optech Newsletter #273 Recap on Twitter Spaces Antoine Riard posted to the Bitcoin-Dev and Lightning-Dev mailing lists the full disclosure of an issue he had previously responsibly disclosed to developers working on the Bitcoin protocol and various popular LN implementations... Robin Linus posted to the Bitcoin-Dev mailing list a paper he’s written about BitVM, a combination of methods that allows bitcoins to be paid to someone who successfully proves that an arbitrary program executed successfully. Notably, this is possible on Bitcoin today—no consensus change is required... Andrew Chow posted to the Bitcoin-Dev mailing list with a draft BIP, partly based on prior work by Sanket Kanjalkar, for adding several fields to all versions of PSBTs for the “keys, public nonces, and partial signatures produced with MuSig2.” Bitcoin Core 24.2rc2 and Bitcoin Core 25.1rc1 are release candidates for maintenance versions of Bitcoin Core. Bitcoin Optech will host an audio recap discussion of this newsletter with special guests Robin Linus and Antoine Poinsot on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1vAGRvZRgrvGl
Bitcoin Optech newsletter #272 is here: - links to a specification for a proposed OP_TXHASH opcode - recaps the "Type-safe transaction identifiers" PR Review Meeting - Bitcoin Core #27596 and the assumeutxo project - Bitcoin Core #28331 and the BIP324 version 2 encrypted P2P transport project - Optech Newsletter #272 Recap on Twitter Spaces Steven Roose posted to the Bitcoin-Dev mailing list a draft BIP for a new OP_TXHASH opcode. The idea behind this opcode has been discussed before but this is the first specification of the idea... 'Type-safe transaction identifiers' is a PR by Niklas Gögge (dergoegge) that improves type safety by introducing separate types for txid (the transaction identifier or hash that doesn’t include the segwit witness data) and wtxid... Bitcoin Core #27596 finishes the first phase of the assumeutxo project, containing all the remaining changes necessary to both use an assumedvalid snapshot chainstate and do a full validation sync in the background... Bitcoin Core #28331 adds support for version 2 encrypted P2P transport as specified in BIP324. The feature is currently disabled by default but can be enabled using the `-v2transport` option... Bitcoin Optech will host an audio recap discussion of this newsletter with special guests Steven Roose, Gloria Zhao, and James O'Beirne on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1nAKEamLYMgKL
Bitcoin Optech newsletter #271 is here: - summarizes a proposal for remotely controlling LN nodes using a hardware signing device
- describes privacy-focused research and code for allowing LN forwarding nodes to dynamically split LN payments
- looks at a proposal for improving LN liquidity by allowing groups of forwarding nodes to pool funds separately from their normal channels
- Optech Newsletter #271 Recap on Twitter Spaces Bastien Teinturier posted to the Lightning-Dev mailing list about a proposed BLIP that would specify how a user could send signed commands to their LN node from a hardware signing device (or any other wallet)... Gijs van Dam posted to the Lightning-Dev mailing list about a plugin he’s written for Core Lightning and some research he’s performed related to it. The plugin allows forwarding nodes to tell their peers that they support payment splitting and switching (PSS)... ZmnSCPxj posted to the Lightning-Dev mailing list a suggestion for what he calls sidepools. This would involve groups of forwarding nodes working together to deposit funds in a multiparty state contract—an offchain contract (that is anchored onchain similar to an LN channel) that would allow funds to be moved between the participants by updating the offchain contract state... Bitcoin Optech will host an audio recap discussion of this newsletter with special guest Gijs van Dam on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1OyKAWPldmNJb
Bitcoin Optech newsletter #270 is here: - describes a proposal to use covenants to significantly improve LN’s scalability - summarizes popular Q&A from Stack Exchange - Optech Newsletter #270 Recap on Twitter Spaces John Law posted to the Bitcoin-Dev and Lightning-Dev mailing lists the summary of a paper he’s written about creating very large channel factories using covenants and managing the resultant channels using adaptations of several previous protocols he’s described... Selected Q&A from Bitcoin Stack Exchange: - How did peer discovery work in Bitcoin v0.1? - Could reorgs cause Bitcoin to break because of the 2-hour block time restriction? - Is there a way to download blocks from scratch without downloading block headers first? - Where is the 21 million hard cap stated?
- Are blocks containing non-standard transactions relayed through the network? - When does Bitcoin Core allow you to “Abandon transaction”? Bitcoin Optech will host an audio recap discussion of this newsletter with special guest Anthony Towns on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1yNGaZaYOWbJj
Bitcoin Optech newsletter #269 is here: - shares the announcement of an upcoming research event - summarizes changes to services/client software - Optech Newsletter #269 Recap on Twitter Spaces Sergi Delgado Segura and Clara Shikhelman posted to the Bitcoin-Dev and Lightning-Dev mailing lists to announce a Bitcoin Research Day event to be held in New York City on October 27th... Changes to services and client software: - Bitcoin-like Script Symbolic Trace (B’SST) released - STARK header chain verifier demo - JoinMarket v0.9.10 released - BitBox adds miniscript - Machankura announces additive batching feature - SimLN Lightning simulation tool Bitcoin Optech will host an audio recap discussion of this newsletter with special guest Sergi Delgado Segura on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1OwGWYavZpkxQ?s=20
Bitcoin Optech newsletter #268 is here: - links to draft specifications related to taproot assets
- describes a summary of several alternative message protocols for LN that can help enable the use of PTLCs
- recaps the BIP324 "Transport abstraction" PR Review Meeting
- adds a Client-side validation topic
- Optech Newsletter #268 Recap on Twitter Spaces Olaoluwa Osuntokun posted separately to the Bitcoin-Dev and Lightning-Dev mailing lists about the Taproot Assets client-side validation protocol. To the Bitcoin-Dev mailing list, he announced seven draft BIPs... As the first LN implementation with experimental support for channels using P2TR and MuSig2 is expected to be released soon, Greg Sanders posted to the Lightning-Dev mailing list a summary of several different previously-discussed changes to LN messages to allow them to support sending payments with PTLCs instead of HTLCs... 'Transport abstraction' is a recently-merged PR by Pieter Wuille (sipa) that introduces a transport abstraction (interface class). This PR is part of the BIP324 Version 2 P2P Encrypted Transport Protocol project... Client-side validation protocols allow a Bitcoin transaction to commit to some data whose validity is determined separate from the validity of the transaction under Bitcoin’s consensus rules. The client-side validation can take advantage of consensus rules, such as only allowing an output to be spent once within a valid block chain, but it may also impose additional rules known only to those interested in the validation... Bitcoin Optech will host an audio recap discussion of this newsletter with special guests Olaoluwa Osuntokun, Greg Sanders, and Pieter Wuille on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1ypKddqdRLjKW
Bitcoin Optech newsletter #267 is here: - describes a new technique for compressing Bitcoin transactions - summarizes an idea for privacy-enhanced transaction cosigning - Optech Newsletter #267 Recap on Twitter Spaces Tom Briar posted to the Bitcoin-Dev mailing list a draft specification and proposed implementation of compressed Bitcoin transactions. Smaller transactions would be more practical to relay through bandwidth constrained mediums, such as by satellite or through steganography... Nick Farrow posts to the Bitcoin-Dev mailing list about how a scriptless threshold signature scheme like FROST could improve the privacy of people who use co-signing services... Bitcoin Optech will host an audio recap discussion of this newsletter with special guest Tom Briar on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1DXxyvWlwdRKM
Bitcoin Optech newsletter #266 is here: - announces the responsible disclosure of a vulnerability affecting old LN implementations - summarizes a suggestion for a mashup of proposed covenant opcodes - summarizes popular Q&A from Stack Exchange - Optech Newsletter #266 Recap on Twitter Spaces Matt Morehouse posted to the Lighting-Dev mailing list the summary of a vulnerability he had previously responsibly disclosed and which is now addressed in the latest versions of all popular LN implementations... Brandon Black posted to the Bitcoin-Dev mailing list a proposal for a version of OP_TXHASH (see Newsletter #185) combined with OP_CHECKSIGFROMSTACK that would provide most of the features of OP_CHECKTEMPLATEVERIFY (CTV) and SIGHASH_ANYPREVOUT (APO) without much additional onchain cost over those individual proposals... Selected Q&A from Bitcoin Stack Exchange: - Is there an economic incentive to switch from P2WPKH to P2TR? - What is the BIP324 encrypted packet structure? - What is the false positive rate for compact block filters? - What opcodes are part of the MATT proposal? - Is there a well defined last Bitcoin block? - Why are miners setting the locktime in coinbase transactions? - Why doesn’t Bitcoin Core use auxiliary randomness when performing Schnorr signatures? Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Matt Corallo and Brandon Black on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1BRJjZmnLbaJw
Bitcoin Optech newsletter #265 is here: - describes fraud proofs for outdated backup state - summarizes changes to services/client software - adds a Peer storage topic - Optech Newsletter #265 Recap on Twitter Spaces Thomas Voegtlin posted to the Lightning-Dev mailing list an idea for a service that could be penalized if it provided a user with any version of the user’s backup state besides the most recent version... Changes to services and client software: - Scaling Lightning call for feedback - Torq v1.0 released - Blixt Wallet v0.6.8 released - Sparrow 1.7.8 released - Open source ASIC miner bitaxeUltra prototype - FROST software Frostsnap announced - Libfloresta library announced - Wasabi Wallet 2.0.4 released Peer storage is an optional service where a node accepts a small amount of frequently-updated encrypted data from its peers (especially channel counterparties)... Bitcoin Optech will be hosting an audio recap discussion of this newsletter on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1OyKAVLllOwGb
Bitcoin Optech newsletter #264 is here: - summarizes a discussion about adding expiration dates to silent payment addresses - provides an overview of a draft BIP for serverless payjoin - includes a contributed field report that describes the implementation and deployment of a MuSig2-based wallet for scriptless multisignatures - Optech Newsletter #264 Recap on Twitter Spaces Peter Todd posted to the Bitcoin-Dev mailing list a recommendation to add a user-chosen expiration date to addresses for silent payments... Dan Gould posted to the Bitcoin-Dev mailing list a draft BIP for serverless payjoin... Field Report: Implementing MuSig2 Brandon Black from BitGo describes their perspectives on integrating MuSig2 in their wallet for scriptless multisignatures... Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Brandon Black and Dan Gould on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1LyGBqgdXVjKN
Bitcoin Optech newsletter #263 is here: - warns about a vulnerability in uses of Libbitcoin’s bx tool - summarizes discussion about the design of DoS protection - announces a plan to begin testing and collecting data about HTLC endorsement - describes two proposed changes to Bitcoin Core’s tx relay policy - recaps the "Silent Payments: Implement BIP352" PR Review Meeting - Adds Topics for: Codex32, HTLC endorsement - Optech Newsletter #263 Recap on Twitter Spaces Severe Libbitcoin Bitcoin Explorer vulnerability: if you used the bx seed command to create BIP32 seeds, BIP39 mnemonics, private keys, or any other secure material, consider immediately moving any funds to a different secure address... Anthony Towns posted to the Lightning-Dev mailing list in response to the channel jamming part of the notes for the recent LN developers meeting. Towns suggested an alternative to trying to price out attackers... Carla Kirk-Cohen and Clara Shikhelman posted to the Lightning-Dev mailing list to announce that developers associated with Eclair, Core Lightning, and LND were implementing parts of the HTLC endorsement protocol in order to begin collecting data related to it... Peter Todd started two threads on the Bitcoin-Dev mailing list related to pull requests he’s opened to change Bitcoin Core’s default relay policy... Several security researchers investigating a recent loss of bitcoins among users of Libbitcoin discovered that program’s Bitcoin Explorer (bx) tool’s seed command only generated about 4 billion different unique values... ‘Silent Payments: Implement BIP352’ is a PR by josibake that takes the first step in adding silent payments to the Bitcoin Core wallet... Codex32 is an encoding designed for BIP32 seeds that is convenient to store on paper. It supports relatively simple processes for creating a seed, encoding that seed, splitting the seed into parts, and verifying the integrity of partial or full seed backups... HTLC endorsement is a reputation system proposed for LN. When a node receives a payment (HTLC) from a channel counterparty for forwarding, that payment may be flagged as endorsed... Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Clara Shikhelman, Josie Baker, and Peter Todd on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1RDGlayOZDRJL