Bitcoin Optech - Nostr Hypermedia

Bitcoin Optech

_@bitcoinops.org

npub1hkuk...432p

We provide weekly newsletters, workshops, case studies, and research for the #Bitcoin community.

Bitcoin Optech 2 years ago

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

Bitcoin Optech Newsletter #273

This week’s newsletter briefly mentions a recent security disclosure affecting LN users, describes a paper about making payments contingent on th...

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...

Bitcoin Optech Newsletter #273

This week’s newsletter briefly mentions a recent security disclosure affecting LN users, describes a paper about making payments contingent on th...

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...

Bitcoin Optech Newsletter #273

This week’s newsletter briefly mentions a recent security disclosure affecting LN users, describes a paper about making payments contingent on th...

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 Optech Newsletter #273

This week’s newsletter briefly mentions a recent security disclosure affecting LN users, describes a paper about making payments contingent on th...

Bitcoin Core 24.2rc2 and Bitcoin Core 25.1rc1 are release candidates for maintenance versions of Bitcoin Core.

Bitcoin Optech Newsletter #273

This week’s newsletter briefly mentions a recent security disclosure affecting LN users, describes a paper about making payments contingent on th...

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 2 years ago

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

Bitcoin Optech Newsletter #272

This week’s newsletter links to a specification for a proposed OP_TXHASH opcode and includes our regular sections summarizing a Bitcoin Core PR R...

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...

Bitcoin Optech Newsletter #272

This week’s newsletter links to a specification for a proposed OP_TXHASH opcode and includes our regular sections summarizing a Bitcoin Core PR R...

'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 Optech Newsletter #272

This week’s newsletter links to a specification for a proposed OP_TXHASH opcode and includes our regular sections summarizing a Bitcoin Core PR R...

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 Optech Newsletter #272

This week’s newsletter links to a specification for a proposed OP_TXHASH opcode and includes our regular sections summarizing a Bitcoin Core PR R...

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 Newsletter #272

This week’s newsletter links to a specification for a proposed OP_TXHASH opcode and includes our regular sections summarizing a Bitcoin Core PR R...

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 2 years ago

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

Bitcoin Optech Newsletter #271

This week’s newsletter summarizes a proposal for remotely controlling LN nodes using a hardware signing device, describes privacy-focused researc...

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)...

Bitcoin Optech Newsletter #271

This week’s newsletter summarizes a proposal for remotely controlling LN nodes using a hardware signing device, describes privacy-focused researc...

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)...

Bitcoin Optech Newsletter #271

This week’s newsletter summarizes a proposal for remotely controlling LN nodes using a hardware signing device, describes privacy-focused researc...

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 Newsletter #271

This week’s newsletter summarizes a proposal for remotely controlling LN nodes using a hardware signing device, describes privacy-focused researc...

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 2 years ago

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

Bitcoin Optech Newsletter #270

This week’s newsletter describes a proposal to use covenants to significantly improve LN’s scalability. Also included are our regular sections ...

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...

Bitcoin Optech Newsletter #270

This week’s newsletter describes a proposal to use covenants to significantly improve LN’s scalability. Also included are our regular sections ...

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 Newsletter #270

This week’s newsletter describes a proposal to use covenants to significantly improve LN’s scalability. Also included are our regular sections ...

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 2 years ago

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

Bitcoin Optech Newsletter #269

This week’s newsletter shares the announcement of an upcoming research event and includes our regular sections summarizing significant updates to...

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...

Bitcoin Optech Newsletter #269

This week’s newsletter shares the announcement of an upcoming research event and includes our regular sections summarizing significant updates to...

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 Newsletter #269

This week’s newsletter shares the announcement of an upcoming research event and includes our regular sections summarizing significant updates to...

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 2 years ago

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

Bitcoin Optech Newsletter #268

This week’s newsletter links to draft specifications related to taproot assets and describes a summary of several alternative message protocols f...

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...

Bitcoin Optech Newsletter #268

This week’s newsletter links to draft specifications related to taproot assets and describes a summary of several alternative message protocols f...

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...

Bitcoin Optech Newsletter #268

This week’s newsletter links to draft specifications related to taproot assets and describes a summary of several alternative message protocols f...

'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...

Bitcoin Optech Newsletter #268

This week’s newsletter links to draft specifications related to taproot assets and describes a summary of several alternative message protocols f...

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...

Client-side validation

Client-side validation protocols allow a Bitcoin transaction to commit to some data whose validity is determined separate from the validity of the ...

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 2 years ago

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

Bitcoin Optech Newsletter #267

This week’s newsletter describes a new technique for compressing Bitcoin transactions and summarizes an idea for privacy-enhanced transaction cos...

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...

Bitcoin Optech Newsletter #267

This week’s newsletter describes a new technique for compressing Bitcoin transactions and summarizes an idea for privacy-enhanced transaction cos...

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 Newsletter #267

This week’s newsletter describes a new technique for compressing Bitcoin transactions and summarizes an idea for privacy-enhanced transaction cos...

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 2 years ago

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

Bitcoin Optech Newsletter #266

This week’s newsletter announces the responsible disclosure of a vulnerability affecting old LN implementations and summarizes a suggestion for a...

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...

Bitcoin Optech Newsletter #266

This week’s newsletter announces the responsible disclosure of a vulnerability affecting old LN implementations and summarizes a suggestion for a...

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...

Bitcoin Optech Newsletter #266

This week’s newsletter announces the responsible disclosure of a vulnerability affecting old LN implementations and summarizes a suggestion for a...

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 Newsletter #266

This week’s newsletter announces the responsible disclosure of a vulnerability affecting old LN implementations and summarizes a suggestion for a...

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 2 years ago

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

Bitcoin Optech Newsletter #265

This week’s newsletter describes fraud proofs for outdated backup state and includes our regular sections summarizing recent changes to services ...

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...

Bitcoin Optech Newsletter #265

This week’s newsletter describes fraud proofs for outdated backup state and includes our regular sections summarizing recent changes to services ...

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

Bitcoin Optech Newsletter #265

This week’s newsletter describes fraud proofs for outdated backup state and includes our regular sections summarizing recent changes to services ...

Peer storage is an optional service where a node accepts a small amount of frequently-updated encrypted data from its peers (especially channel counterparties)...

Peer storage is an optional service where a node accepts a small amount of frequently-updated encrypted data from its peers (especially channel cou...

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 2 years ago

Earlier today Mark “Murch” Erhardt and Mike Schmidt spoke with Brandon Black and Dan Gould in a Bitcoin privacy-focused recap including: - Silent Payments - Payjoins - MuSig2 - Eclipse attacks - BIP324 Catchup here:

Bitcoin Optech Newsletter #264 Recap Podcast

Mark “Murch” Erhardt and Mike Schmidt are joined by Brandon Black and Dan Gould to discuss Newsletter #264.

Bitcoin Optech 2 years ago

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

Bitcoin Optech Newsletter #264

This week’s newsletter summarizes a discussion about adding expiration dates to silent payment addresses and provides an overview of a draft BIP ...

Peter Todd posted to the Bitcoin-Dev mailing list a recommendation to add a user-chosen expiration date to addresses for silent payments...

Bitcoin Optech Newsletter #264

This week’s newsletter summarizes a discussion about adding expiration dates to silent payment addresses and provides an overview of a draft BIP ...

Dan Gould posted to the Bitcoin-Dev mailing list a draft BIP for serverless payjoin...

Bitcoin Optech Newsletter #264

This week’s newsletter summarizes a discussion about adding expiration dates to silent payment addresses and provides an overview of a draft BIP ...

Field Report: Implementing MuSig2 Brandon Black from BitGo describes their perspectives on integrating MuSig2 in their wallet for scriptless multisignatures...

Bitcoin Optech Newsletter #264

This week’s newsletter summarizes a discussion about adding expiration dates to silent payment addresses and provides an overview of a draft BIP ...

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 2 years ago

Yesterday we were joined by Dave Harding and spoke about HTLC endorsement with Clara Shikhelman, proposed changes to Bitcoin Core default relay policy with Peter Todd, silent payments with Josie Baker and more Catchup here:

Bitcoin Optech Newsletter #263 Recap Podcast

Mark “Murch” Erhardt and Mike Schmidt are joined by Dave Harding, Clara Shikhelman, Peter Todd, Josie Baker, and Eduardo Quintana to discuss Ne...

Bitcoin Optech 2 years ago

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

Bitcoin Optech Newsletter #263

This week’s newsletter warns about a severe vulnerability in uses of Libbitcoin’s Bitcoin Explorer (bx) tool, summarizes a discussion about the...

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...

Bitcoin Optech Newsletter #263

This week’s newsletter warns about a severe vulnerability in uses of Libbitcoin’s Bitcoin Explorer (bx) tool, summarizes a discussion about the...

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...

Bitcoin Optech Newsletter #263

This week’s newsletter warns about a severe vulnerability in uses of Libbitcoin’s Bitcoin Explorer (bx) tool, summarizes a discussion about the...

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...

Bitcoin Optech Newsletter #263

This week’s newsletter warns about a severe vulnerability in uses of Libbitcoin’s Bitcoin Explorer (bx) tool, summarizes a discussion about the...

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...

Bitcoin Optech Newsletter #263

This week’s newsletter warns about a severe vulnerability in uses of Libbitcoin’s Bitcoin Explorer (bx) tool, summarizes a discussion about the...

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...

Bitcoin Optech Newsletter #263

This week’s newsletter warns about a severe vulnerability in uses of Libbitcoin’s Bitcoin Explorer (bx) tool, summarizes a discussion about the...

‘Silent Payments: Implement BIP352’ is a PR by josibake that takes the first step in adding silent payments to the Bitcoin Core wallet...

Bitcoin Optech Newsletter #263

This week’s newsletter warns about a severe vulnerability in uses of Libbitcoin’s Bitcoin Explorer (bx) tool, summarizes a discussion about the...

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...

Codex32 is an encoding designed for BIP32 seeds that is convenient to store on paper. It supports relatively simple processes for creating a seed, ...

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...

HTLC endorsement

HTLC endorsement is a reputation system proposed for LN. When a node receives a payment (HTLC) from a channel counterparty for forwarding, that pay...

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

Bitcoin Optech 2 years ago

Bitcoin Optech newsletter #262 is here: - links to transcripts of recent LN specification meetings - summarizes a thread about the safety of blind MuSig2 signing - Optech Newsletter #262 Recap on Twitter Spaces

Bitcoin Optech Newsletter #262

This week’s newsletter links to transcripts of recent LN specification meetings and summarizes a thread about the safety of blind MuSig2 signing....

Carla Kirk-Cohen posted to the Lightning-Dev mailing list to announce that the last several video conference meetings to discuss changes to the LN specification were transcribed...

Bitcoin Optech Newsletter #262

This week’s newsletter links to transcripts of recent LN specification meetings and summarizes a thread about the safety of blind MuSig2 signing....

Tom Trevethan posted to the Bitcoin-Dev mailing list to request a review of a cryptographic protocol planned as part of a statechains deployment. The goal was to deploy a service that would use its private key to create a MuSig2 partial signature without gaining any knowledge about what it was signing or how its partial signature was used...

Bitcoin Optech Newsletter #262

This week’s newsletter links to transcripts of recent LN specification meetings and summarizes a thread about the safety of blind MuSig2 signing....

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/1eaJbrgAlWqJX

Bitcoin Optech 2 years ago

Bitcoin Optech newsletter #261 is here: - describes a protocol for simplifying the communication related to mutual closing of LN channels - summarizes notes from a recent meeting of LN developers - summarizes popular Q&A from Stack Exchange - Adds Topics for: Channel announcements, Cluster mempool, Redundant overpayments - Optech Newsletter #261 Recap on Twitter Spaces

Bitcoin Optech Newsletter #261

This week’s newsletter describes a protocol for simplifying the communication related to mutual closing of LN channels and summarizes notes from ...

Rusty Russell posted to the Lightning-Dev mailing list a proposal that simplifies the process of two LN nodes mutually closing a channel they share...

Bitcoin Optech Newsletter #261

This week’s newsletter describes a protocol for simplifying the communication related to mutual closing of LN channels and summarizes notes from ...

Carla Kirk-Cohen posted to the Lightning-Dev mailing list a summary of several discussions from the recent meeting of LN developers in New York City...

Bitcoin Optech Newsletter #261

This week’s newsletter describes a protocol for simplifying the communication related to mutual closing of LN channels and summarizes notes from ...

Selected Q&A from Bitcoin Stack Exchange: - How can I manually (on paper) calculate a Bitcoin public key from a private key? - Why are there 17 native segwit versions? - Does 0 OP_CSV force the spending transaction to signal BIP125 replaceability? - How do route hints affect pathfinding? - What does it mean that the security of 256-bit ECDSA, and therefore Bitcoin keys, is 128 bits?

Bitcoin Optech Newsletter #261

This week’s newsletter describes a protocol for simplifying the communication related to mutual closing of LN channels and summarizes notes from ...

Channel announcements are advertisements that a channel is available to forward payments. The advertisements are relayed through the LN gossip network...

Channel announcements

Channel announcements are advertisements that a channel is available to forward payments. The advertisements are relayed through the LN gossip netw...

Cluster mempool is a proposal to associate each unconfirmed transaction in a mempool with related transactions, creating a cluster. Each cluster of transactions, whether it be a single transaction or several transactions, can be ordered from most desirable to mine to least desirable, allowing operations for adding or removing new clusters to complete fast enough to use them in P2P network code...

Cluster mempool

Cluster mempool is a proposal to associate each unconfirmed transaction in a mempool with related transactions, creating a cluster. Each cluster co...

Redundant overpayments are LN payments split into parts where the spender sends a greater amount and more parts than necessary to pay the receiver’s invoice. Even if some of the parts fail to arrive at the receiver’s node on the first try due to forwarding failures, enough of the other parts may arrive to allow the receiver to claim their invoiced amount...

Redundant overpayments

Redundant overpayments are LN payments split into parts where the spender sends a greater amount and more parts than necessary to pay the receiver�...

Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Greg Sanders and Bastien Teinturier on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1DXGyvjzgXNJM

Bitcoin Optech 2 years ago

Bitcoin Optech newsletter #260 is here: - includes 'Waiting for confirmation #10: Get Involved' from our series about policies for transaction relay and mempool inclusion - summarizes changes to services/client software - Optech Newsletter #260 Recap on Twitter Spaces

Bitcoin Optech Newsletter #260

This week’s newsletter includes the final entry in our limited weekly series about mempool policy, plus our regular sections describing notable c...

Waiting for confirmation #10: Get Involved We hope this series has given readers a better idea of what’s going on while they are waiting for confirmation. We started with a discussion about how some of the ideological values of Bitcoin translate to its structure and design goals. The distributed structure of the peer-to-peer network offers increased censorship resistance and privacy over a typical centralized model...

Bitcoin Optech Newsletter #260

This week’s newsletter includes the final entry in our limited weekly series about mempool policy, plus our regular sections describing notable c...

Changes to services and client software: - Wallet 10101 beta testing pooling funds between LN and DLCs - LDK Node announced - Payjoin SDK announced - Validating Lightning Signer (VLS) beta announced - BitGo adds MuSig2 support - Peach adds RBF support - Phoenix wallet adds splicing support - Mining Development Kit call for feedback - Binance adds Lightning support - Nunchuk adds CPFP support

Bitcoin Optech Newsletter #260

This week’s newsletter includes the final entry in our limited weekly series about mempool policy, plus our regular sections describing notable c...

Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guest Gloria Zhao on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1OdKrzzpmLkKX

Bitcoin Optech 2 years ago

Bitcoin Optech newsletter #259 is here: - describes a proposal to remove details from the LN specification that are no longer relevant to modern nodes - includes 'Waiting for confirmation #9: Policy Proposals' from our series about policies for transaction relay and mempool inclusion - recaps the "Stop relaying non-mempool txs" PR Review Meeting - Optech Newsletter #259 Recap on Twitter Spaces

Bitcoin Optech Newsletter #259

This week’s newsletter describes a proposal to remove details from the LN specification that are no longer relevant to modern nodes and includes ...

Rusty Russell posted to the Lightning-Dev mailing list a link to a PR where he proposes to remove some features that are no longer supported by modern LN implementations and to assume other features will always be supported...

Bitcoin Optech Newsletter #259

This week’s newsletter describes a proposal to remove details from the LN specification that are no longer relevant to modern nodes and includes ...

Waiting for confirmation #9: Policy Proposals Last week’s post described anchor outputs and CPFP carve out, ensuring either channel party can fee-bump their shared commitment transactions without requiring collaboration. This approach still contains a few drawbacks. This post explores current efforts to address these and other limitations...

Bitcoin Optech Newsletter #259

This week’s newsletter describes a proposal to remove details from the LN specification that are no longer relevant to modern nodes and includes ...

'Stop relaying non-mempool txs' is a PR by Marco Falke (MarcoFalke) that simplifies the Bitcoin Core client by removing an in-memory data structure, mapRelay, that may cause high memory consumption and is no longer needed...

Bitcoin Optech Newsletter #259

This week’s newsletter describes a proposal to remove details from the LN specification that are no longer relevant to modern nodes and includes ...

Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Gloria Zhao, Bastien Teinturier, and Martin Zumsande on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1YqxoAAYQEBGv

Bitcoin Optech 2 years ago

Bitcoin Optech newsletter #258 is here: - includes 'Waiting for confirmation #8: Policy as an Interface' from our series about policies for transaction relay and mempool inclusion - Core Lightning 23.05.2 - Optech Newsletter #258 Recap on Twitter Spaces

Bitcoin Optech Newsletter #258

This week’s newsletter includes another entry in our limited weekly series about mempool policy, plus our regular sections announcing new release...

Waiting for confirmation #8: Policy as an Interface Since transaction relay policy changes to Bitcoin Core can impact whether an application’s transactions relay, they require socialization with the wider Bitcoin community prior to consideration. Similarly, applications and second layer protocols that utilize transaction relay must be designed with policy rules in mind to avoid creating transactions that are rejected...

Bitcoin Optech Newsletter #258

This week’s newsletter includes another entry in our limited weekly series about mempool policy, plus our regular sections announcing new release...

Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guest Gloria Zhao on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1gqGvylbbrqKB

Bitcoin Optech 2 years ago

Bitcoin Optech newsletter #257 is here: - summarizes an idea for preventing the pinning of coinjoin transactions - describes a proposal for speculatively using hoped-for consensus changes - includes 'Waiting for confirmation #7: Network Resources' from our series about policies for transaction relay and mempool inclusion - summarizes popular Q&A from Stack Exchange - Optech Newsletter #257 Recap on Twitter Spaces

Bitcoin Optech Newsletter #257

This week’s newsletter summarizes an idea for preventing the pinning of coinjoin transactions and describes a proposal for speculatively using ho...

Greg Sanders posted to the Bitcoin-Dev mailing list a description for how the proposed v3 transaction relay rules could allow creating a coinjoin-style multiparty transaction that wouldn’t be vulnerable to transaction pinning...

Bitcoin Optech Newsletter #257

This week’s newsletter summarizes an idea for preventing the pinning of coinjoin transactions and describes a proposal for speculatively using ho...

Robin Linus posted to the Bitcoin-Dev mailing list an idea for spending money to a script fragment that can’t be executed for a long time (such as 20 years). If that script fragment is interpreted under current consensus rules, it will allow miners in 20 years to claim all the funds paid to it...

Bitcoin Optech Newsletter #257

This week’s newsletter summarizes an idea for preventing the pinning of coinjoin transactions and describes a proposal for speculatively using ho...

Waiting for confirmation #7: Network Resources A previous post discussed protecting node resources, which may be unique to each node and thus sometimes configurable. We also made our case for why it is best to converge on one policy, but what should be part of that policy? This post will discuss the concept of network-wide resources, critical to things like scalability, upgradeability and accessibility of bootstrapping and maintaining a full node...

Bitcoin Optech Newsletter #257

This week’s newsletter summarizes an idea for preventing the pinning of coinjoin transactions and describes a proposal for speculatively using ho...

Selected Q&A from Bitcoin Stack Exchange: - Why do Bitcoin nodes accept blocks that have so many excluded transactions? - Why does everyone say that soft forks restrict the existing ruleset? - Why is the default LN channel limit set to 16777215 sats? - Why does Bitcoin Core use ancestor score instead of just ancestor fee rate to select transactions? - How does Lightning multipart payments (MPP) protocol define the amounts per part?

Bitcoin Optech Newsletter #257

This week’s newsletter summarizes an idea for preventing the pinning of coinjoin transactions and describes a proposal for speculatively using ho...

Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Gloria Zhao, Greg Sanders, and Robin Linus on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1OdJrzVXdEwJX

Bitcoin Optech 2 years ago

Bitcoin Optech newsletter #256 is here: - summarizes a discussion about extending BOLT11 invoices to request two payments - includes 'Waiting for confirmation #6: Policy Consistency' from our series about policies for transaction relay and mempool inclusion - summarizes changes to services/client software - add Submarine swaps and Just-In-Time (JIT) channels topics - Optech Newsletter #256 Recap on Twitter Spaces

Bitcoin Optech Newsletter #256

This week’s newsletter summarizes a discussion about extending BOLT11 invoices to request two payments. Also included is another entry in our lim...

Thomas Voegtlin posted to the Lightning-Dev mailing list to suggest BOLT11 invoices be extended to optionally allow a receiver to request two separate payments from a spender, with each payment having a separate secret and amount...

Bitcoin Optech Newsletter #256

This week’s newsletter summarizes a discussion about extending BOLT11 invoices to request two payments. Also included is another entry in our lim...

Waiting for confirmation #6: Policy Consistency Last week’s introduced policy, a set of transaction validation rules applied in addition to consensus rules. These rules are not applied to transactions in blocks, so a node can still stay in consensus even if its policy differs from that of its peers. Just like a node operator may decide to not participate in transaction relay, they are also free to choose any policy, up to none at all...

Bitcoin Optech Newsletter #256

This week’s newsletter summarizes a discussion about extending BOLT11 invoices to request two payments. Also included is another entry in our lim...

Changes to services and client software: - Greenlight libraries open sourced - Tapscript debugger Tapsim - Bitcoin Keeper 1.0.4 announced - Lightning wallet EttaWallet announced - zkSNARK-based block header sync PoC announced - lnprototest v0.0.4 released

Bitcoin Optech Newsletter #256

This week’s newsletter summarizes a discussion about extending BOLT11 invoices to request two payments. Also included is another entry in our lim...

Submarine swaps are trust-minimized atomic swaps of offchain bitcoins for onchain bitcoins. A payment secured by an HTLC is routed over LN to a service provider who creates an onchain output paying the same HTLC...

Submarine swaps

Submarine swaps are trust-minimized atomic swaps of offchain bitcoins for onchain bitcoins. A payment secured by an HTLC is routed over LN to a ser...

JIT channels are virtual LN channels hosted by a service provider. When the first payment to the channel is received, the service provider creates a funding transaction and adds the payment to it, creating a normal channel...

Just-In-Time (JIT) channels

JIT channels are virtual LN channels hosted by a service provider. When the first payment to the channel is received, the service provider creates ...

Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guest Thomas Voegtlin on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions! https://twitter.com/i/spaces/1djxXloOldkxZ

Load More →

↑