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
https://bitcoinops.org/en/newsletters/2023/08/30/
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...
https://bitcoinops.org/en/newsletters/2023/08/30/#covenant-mashup-using-txhash-and-csfs
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?
https://bitcoinops.org/en/newsletters/2023/08/30/#selected-qa-from-bitcoin-stack-exchange
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!
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
https://bitcoinops.org/en/newsletters/2023/08/23/
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...
https://bitcoinops.org/en/newsletters/2023/08/23/#fraud-proofs-for-outdated-backup-state
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
https://bitcoinops.org/en/newsletters/2023/08/23/#changes-to-services-and-client-software
Peer storage is an optional service where a node accepts a small amount of frequently-updated encrypted data from its peers (especially channel counterparties)...
https://bitcoinops.org/en/topics/peer-storage/
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!
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 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
https://bitcoinops.org/en/newsletters/2023/08/16/
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...
https://bitcoinops.org/en/newsletters/2023/08/16/#serverless-payjoin
Field Report: Implementing MuSig2
Brandon Black from BitGo describes their perspectives on integrating MuSig2 in their wallet for scriptless multisignatures...
https://bitcoinops.org/en/newsletters/2023/08/16/#field-report-implementing-musig2
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!
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 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
https://bitcoinops.org/en/newsletters/2023/08/09/
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...
https://bitcoinops.org/en/newsletters/2023/08/09/#severe-libbitcoin-bitcoin-explorer-vulnerability
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...
https://bitcoinops.org/en/newsletters/2023/08/09/#denial-of-service-dos-protection-design-philosophy
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...
https://bitcoinops.org/en/newsletters/2023/08/09/#htlc-endorsement-testing-and-data-collection
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...
https://bitcoinops.org/en/newsletters/2023/08/09/#libbitcoin-bitcoin-explorer-security-disclosure
‘Silent Payments: Implement BIP352’ is a PR by josibake that takes the first step in adding silent payments to the Bitcoin Core wallet...
https://bitcoinops.org/en/newsletters/2023/08/09/#bitcoin-core-pr-review-club
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...
https://bitcoinops.org/en/topics/codex32/
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...
https://bitcoinops.org/en/topics/htlc-endorsement/
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!
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
https://bitcoinops.org/en/newsletters/2023/08/02/
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...
https://bitcoinops.org/en/newsletters/2023/08/02/#transcripts-of-periodic-ln-specification-meetings
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...
https://bitcoinops.org/en/newsletters/2023/08/02/#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!
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
https://bitcoinops.org/en/newsletters/2023/07/26/
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...
https://bitcoinops.org/en/newsletters/2023/07/26/#simplified-ln-closing-protocol
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...
https://bitcoinops.org/en/newsletters/2023/07/26/#ln-summit-notes
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?
https://bitcoinops.org/en/newsletters/2023/07/26/#selected-qa-from-bitcoin-stack-exchange
Channel announcements are advertisements that a channel is available to forward payments. The advertisements are relayed through the LN gossip network...
https://bitcoinops.org/en/topics/channel-announcements/
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...
https://bitcoinops.org/en/topics/cluster-mempool/
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...
https://bitcoinops.org/en/topics/redundant-overpayments/
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!
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
https://bitcoinops.org/en/newsletters/2023/07/19/
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...
https://bitcoinops.org/en/newsletters/2023/07/19/#waiting-for-confirmation-10-get-involved
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
https://bitcoinops.org/en/newsletters/2023/07/19/#changes-to-services-and-client-software
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!
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
https://bitcoinops.org/en/newsletters/2023/07/12/
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...
https://bitcoinops.org/en/newsletters/2023/07/12/#ln-specification-clean-up-proposed
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...
https://bitcoinops.org/en/newsletters/2023/07/12/#waiting-for-confirmation-9-policy-proposals
'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...
https://bitcoinops.org/en/newsletters/2023/07/12/#bitcoin-core-pr-review-club
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!
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
https://bitcoinops.org/en/newsletters/2023/07/05/
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...
https://bitcoinops.org/en/newsletters/2023/07/05/#waiting-for-confirmation-8-policy-as-an-interface
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!
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
https://bitcoinops.org/en/newsletters/2023/06/28/
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...
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...
https://bitcoinops.org/en/newsletters/2023/06/28/#speculatively-using-hoped-for-consensus-changes
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...
https://bitcoinops.org/en/newsletters/2023/06/28/#waiting-for-confirmation-7-network-resources
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?
https://bitcoinops.org/en/newsletters/2023/06/28/#selected-qa-from-bitcoin-stack-exchange
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!
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
https://bitcoinops.org/en/newsletters/2023/06/21/
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...
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...
https://bitcoinops.org/en/newsletters/2023/06/21/#waiting-for-confirmation-6-policy-consistency
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
https://bitcoinops.org/en/newsletters/2023/06/21/#changes-to-services-and-client-software
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...
https://bitcoinops.org/en/topics/submarine-swaps/
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...
https://bitcoinops.org/en/topics/jit-channels/
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!
Bitcoin Optech newsletter #255 is here:
- summarizes discussion about allowing relay of txs containing taproot annex data
- links to a silent payments draft BIP
- includes 'Waiting for confirmation #5: Policy for Protection of Node Resources' from our series about policies for transaction relay and mempool inclusion
- recaps the "Allow inbound whitebind connections to more aggressively evict peers when slots are full" PR Review Meeting
- #255 Recap on Twitter Spaces
https://bitcoinops.org/en/newsletters/2023/06/14/
Joost Jager posted to the Bitcoin-Dev mailing list a request for a change in the Bitcoin Core transaction relay and mining policy to allow storing arbitrary data in the taproot annex field...
https://bitcoinops.org/en/newsletters/2023/06/14/#discussion-about-the-taproot-annex
Josie Baker and Ruben Somsen posted to the Bitcoin-Dev mailing list a draft BIP for silent payments, a type of reusable payment code that will produce a unique onchain address each time it is used, preventing output linking...
https://bitcoinops.org/en/newsletters/2023/06/14/#draft-bip-for-silent-payments
Waiting for confirmation #5: Policy for Protection of Node Resources
A node that fully validates blocks and transactions requires resources including memory, computational resources, and network bandwidth. We must keep resource requirements low in order to make running a node accessible and to defend the node against exploitation...
Allow inbound whitebind connections to more aggressively evict peers when slots are full is a PR by Matthew Zipkin (pinheadmz) that improves a node operator’s ability in certain cases to configure desired peers for the node...
https://bitcoinops.org/en/newsletters/2023/06/14/#bitcoin-core-pr-review-club
Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Gloria Zhao, Joost Jager, Josie Baker, Ruben Somsen, and Matthew Zipkin on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions!
Join Optech on Twitter Spaces in 2 hours (1500 UTC) where we will chat MATT/OP_CTV/joinpools, mempools and transaction feerates, and more with Dave Harding, Gloria Zhao, Johan Torås Halseth and Salvatore Ingala
Waiting for confirmation #4: Feerate estimation
Last week, we explored techniques for minimizing the fees paid on a transaction given a feerate. But what should that feerate be? Ideally, as low as possible to save money, but high enough to secure a spot in a block suitable for the user’s time preference.
The goal of fee(rate) estimation is to translate a target timeframe for confirmation to a minimal feerate the transaction should pay...
https://bitcoinops.org/en/newsletters/2023/06/07/#waiting-for-confirmation-4-feerate-estimation
Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Dave Harding, Gloria Zhao, Johan Torås Halseth and Salvatore Ingala on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions!
Johan Torås Halseth posted to the Bitcoin-Dev mailing list about using the OP_CHECKOUTPUTCONTRACTVERIFY opcode (COCV) from the Merklize All The Things (MATT) proposal to replicate the functionality of the OP_CHECKTEMPLATEVERIFY proposal.
https://bitcoinops.org/en/newsletters/2023/06/07/#using-matt-to-replicate-ctv-and-manage-joinpools
Waiting for confirmation #4: Feerate estimation
Last week, we explored techniques for minimizing the fees paid on a transaction given a feerate. But what should that feerate be? Ideally, as low as possible to save money, but high enough to secure a spot in a block suitable for the user’s time preference.
The goal of fee(rate) estimation is to translate a target timeframe for confirmation to a minimal feerate the transaction should pay...
https://bitcoinops.org/en/newsletters/2023/06/07/#waiting-for-confirmation-4-feerate-estimation
Johan Torås Halseth posted to the Bitcoin-Dev mailing list about using the OP_CHECKOUTPUTCONTRACTVERIFY opcode (COCV) from the Merklize All The Things (MATT) proposal to replicate the functionality of the OP_CHECKTEMPLATEVERIFY proposal.
https://bitcoinops.org/en/newsletters/2023/06/07/#using-matt-to-replicate-ctv-and-manage-joinpools
Bitcoin Optech newsletter #254 is here:
- summarizes mailing list discussion about using the MATT proposal to manage joinpools and replicate functions of the OP_CHECKTEMPLATEVERIFY proposal
- includes 'Waiting for confirmation #4: Feerate estimation' from our series about policies for transaction relay and mempool inclusion
- Optech Newsletter #254 Recap on Twitter Spaces
Hello, nostr!