Your daily summary

Brandon Black focuses on refining the Partially Signed Bitcoin Transaction (PSBT) format to improve multi-party transaction coordination. He suggests the PSBT should be directly valid or easily made valid, advocating for a standardized descriptor file to facilitate transaction processes between devices.

Black's enhancement to the Bitcoin Improvement Proposal (BIP) 174 includes introducing two new global types: PSBT_GLOBAL_DESCRIPTOR and PSBT_GLOBAL_KEY_NAME. These are intended to standardize the inclusion of descriptors and key names, ensuring better compatibility and communication with signing devices without necessitating further protocol modifications.

The proposed updates are expected to allow for smoother interactions between coordinating and signing devices. Coordinating devices could add inputs using either PSBT version 2 or create an unsigned transaction with version 1, which can then be efficiently verified and signed by the signing devices, streamlining the overall transaction completion.

Filter by List

Active Discussions 🔥

2 replies

Authored by

SeedHammer Team

Involving

Brandon Black

  • SeedHammer is creating a compact descriptor for metal engraved backups using PSBT encoding.
  • The descriptor adheres to BIP standards, supports Miniscript, and includes metadata with restrictions.
  • Debate exists between using CBOR or PSBT encoding, with an invitation for community feedback.

lightning-dev

Mailing List Future

8 replies

Authored by

Matt Corallo

Involving

Bastien TEINTURIER, Olaoluwa Osuntokun+2 others

  • The meeting addressed the mailing list shutdown and reviewed alternatives like Google Groups and GitHub.
  • Options included a new mailman managed instance and a self-hosted or delvingbitcoin.com Discourse.
  • A deciding vote on the platform choice is scheduled for the next meeting in over a week.

4 replies

Authored by

Bastien TEINTURIER

Involving

Matt Morehouse, ZmnSCPxj

  • Liquidity ads pose pricing and attack risks during protocol design for sellers.
  • Solutions like CLTV and splicing introduce opportunities for exploitation and complexity.
  • Despite challenges, liquidity ads remain key to the lightning network's progress.

All Activity

12 replies

Posted December 5, 2023 03:04 UTC

Authored by

Matt Corallo

Involving

Bastien TEINTURIER, Olaoluwa Osuntokun+3 others

The email discussions at hand delve into the challenges and considerations of preserving digital discussions on platforms like delvingbitcoin.org, especially when compared to traditional mailing lists. The sender showcases a strong preference for maintaining information in a durable and accessible format, akin to the Linux kernel's use of lore.kernel.org, which allows access to emails dating back to 2001.


4 replies

Posted December 4, 2023 09:48 UTC

Authored by

Bastien TEINTURIER

Involving

Matt Morehouse, ZmnSCPxj

The correspondence delves into a sophisticated mechanism designed to manage the seller’s funds within a transactional channel, particularly focusing on the use of CheckLockTimeVerify (CLTV) leases. The proposed system involves three distinct counters for the seller's funds: `to_local` for non-leased funds, `to_local_leased` for leased funds, and `to_local_leased_owed`, which mirrors `to_local_leased` but excludes pending HTLCs sent by the seller.


2 replies

Posted November 30, 2023 23:12 UTC

Authored by

SeedHammer Team

Involving

Brandon Black

SeedHammer is in the process of creating a standardized output descriptor to facilitate self-contained metal engraved backups, which could be crucial for the preservation and recovery of cryptocurrency assets. Their proposed format incorporates the binary encoding from BIP174 PSBT, aiming to make it compatible with PSBTv1 and PSBTv2 by allowing a coordinating device to add inputs or an unsigned transaction without additional modifications.


1 reply

Posted November 27, 2023 14:56 UTC

Authored by

Michael Ford

The latest release candidate for Bitcoin Core, version v26.0rc3, is now available for download. Interested parties can obtain the binaries from the provided link to Bitcoin Core's official website.


4 replies

Posted November 22, 2023 17:13 UTC

Authored by

niftynei

Involving

Bastien TEINTURIER

The programming community is actively engaged in discussions and revisions to enhance network protocol functionalities, particularly focusing on transactional integrity and flexibility in liquidity management. One key change that has been implemented is the transition from CheckSequenceVerify (CSV) to CheckLockTimeVerify (CLTV) in locking leasor funds, a move motivated by the need to resolve complications associated with anchor outputs and updating commitment transactions.


22 replies

Posted November 22, 2023 11:27 UTC

Authored by

Casey Rodarmor

Involving

Andrew Poelstra, Léo Haf+11 others

The discussion on Bitcoin ordinals highlights their design to ensure on-chain data persistence, which leads to fuller blocks and raises concerns about space competition between regular transactions and data embedding. A proposed technical solution suggests hiding ordinals behind an R-value in the witness part of a transaction input, which would reduce their size and cost while maintaining cryptographic proof and allowing for uncensorable inclusion in different types of addresses. The role of Bitcoin Improvement Proposals (BIPs) is examined with the suggestion that they should focus on crucial protocol elements to preserve the integrity and functionality of Bitcoin.


13 replies

Posted November 21, 2023 10:57 UTC

Authored by

Bastien TEINTURIER

Involving

Tony Giorgio, Andy Schroder+1 others

The recent programming discussions have been concentrated on enhancing the user experience and scalability of Lightning node operations and DNS record management, while also focusing on security and efficiency. A key topic is the handling of DNS records for payment systems, debating whether clients should verify the expiration of offers against DNS record expirations and requesting new records proactively to avoid discrepancies.


2 replies

Posted November 21, 2023 02:39 UTC

Authored by

Johan Torås Halseth

Involving

Antoine Riard

The recent communication highlights the intricacies of enhancing the security and efficiency of the Lightning Network (LN) through HTLC output aggregation. The sender delves into the technical aspects of transaction recycling, a vulnerability that emerges from modifications to HTLC second-level transactions for anchor channel types.


2 replies

Posted November 21, 2023 02:39 UTC

Authored by

Johan Torås Halseth

Involving

Antoine Riard

Transaction recycling and slot jamming are critical issues that can arise in the context of Lightning Network's (LN) channel types, primarily due to the structure of Hash Time Locked Contracts (HTLCs). A notable change in HTLC second-level transactions for the anchor channel type has inadvertently enabled transaction recycling attacks.


13 replies

Posted November 20, 2023 19:47 UTC

Authored by

Anthony Towns

Involving

Aymeric Vitte, Rijndael+4 others

Blockchain standardization is a key topic, with suggestions to treat signature R-values as Taproot-based public keys for consistent protocol interpretation. Another approach proposes using commitments that can push any data and nest future commitments within previous ones, ensuring they remain off-chain by starting with OP_RETURN and expressing r-values as 256-bit numbers. Minimal on-chain presence for inscriptions involves hashing the actual data and committing it via sign-to-contract to reduce the blockchain footprint.


70 replies

Posted November 17, 2023 22:36 UTC

Authored by

Antoine Riard

Involving

Peter Todd, Matt Morehouse+9 others

The recent programmer discussions have centered on enhancing security within the Bitcoin and Lightning Network ecosystems, particularly addressing vulnerabilities related to Hash Time Locked Contracts (HTLCs). A significant vulnerability identified is the potential for replacement cycling attacks on HTLC-preimage transactions.


70 replies

Posted November 17, 2023 22:36 UTC

Authored by

Antoine Riard

Involving

Peter Todd, Matt Morehouse+9 others

The recent discussions among programmers have focused on addressing security threats to the Lightning Network (LN), particularly vulnerabilities in Hashed Time-Locked Contracts (HTLCs). The "flood & loot" attack, where attackers exploit network mempools by closing channels and hindering defensive transactions, has been highlighted as a significant threat.


17 replies

Posted November 15, 2023 19:59 UTC

Authored by

jlspc

Involving

Anthony Towns, Rusty Russell+4 others

John's paper analyzes the trade-offs between trust/safety and capital efficiency in Lightning network channel management, suggesting that casual users prepay cost-of-capital fees for the entire active lifetime of a channel to reduce risks. His scalability analysis considers how many timeout-tree leaves can be put on-chain given block capacity constraints, concluding that scaling to 100 million leaves is feasible without compromising safety or efficiency.


15 replies

Posted November 15, 2023 19:59 UTC

Authored by

jlspc

Involving

Anthony Towns, Rusty Russell+3 others

The recent discussions among programmers have centered on enhancing the Lightning Network's operation and scalability. John has analyzed trade-offs between trust/safety and capital efficiency, suggesting a prepayment system to balance channel lifetime risks and fund adjustments.


3 replies

Posted November 15, 2023 18:14 UTC

Authored by

Antoine Riard

The ongoing efforts to enhance the Lightning Network are centered around addressing significant challenges such as pinning, replacement cycling attacks, and mempool congestion. A collaborative approach is being taken by key researchers in the field, including Gleb Naumenko and the email's author, who have a history of working together on these complex issues since 2019/2020.


3 replies

Posted November 15, 2023 18:14 UTC

Authored by

Antoine Riard

The email outlines the considerations for creating a valid consensus-change based solution for Bitcoin L2, specifically regarding issues such as pinning and replacement cycling. The proposed solution should maintain non-interactive properties with off-chain counterparties, minimize fee-bumping reserves and UTXO locks, prevent malicious activities while allowing competition with ongoing fee rates, and ensure security for low-value lightning payments without relying on local knowledge of historical mempool states.


1 reply

Posted November 15, 2023 17:53 UTC

Authored by

Antoine Riard

In the realm of blockchain and cryptocurrency, specifically concerning the Lightning Network (LN), there are intricate details that can impact security and efficiency. One issue discussed is the problem of on-chain inclusion of "expired" off-chain output spends, such as HTLC-preimage, and the challenge posed by the use of revoked or updated states to obstruct the confirmation of a valid off-chain state.


27 replies

Posted November 15, 2023 17:50 UTC

Authored by

Peter Todd

Involving

David A. Harding, vjudeu at gazeta.pl+4 others

The recent technical discussions among programmers focus on enhancing the security and efficiency of the Lightning Network and Bitcoin transactions. Key issues addressed involve handling outdated or revoked states in multi-party off-chain agreements, fee management for commitment transactions, and preventing potential disruptions in consensus. One proposal suggests that each channel counterparty maintain individual fee-bumping reserves to avoid fee griefing strategies at the expense of capital efficiency.


25 replies

Posted November 14, 2023 19:50 UTC

Authored by

Peter Todd

Involving

David A. Harding, vjudeu at gazeta.pl+3 others

The discussion addresses technical challenges within the Lightning Network, such as managing outdated states and transaction fees. It is recognized that while security could be improved, keeping transaction fees to a minimum relative to the channel's total value is essential for economic viability. Miners benefit from the increase in feerate over discarded transactions when mining HTLC commitment transactions.


25 replies

Posted November 14, 2023 15:32 UTC

Authored by

Bryan Bishop

Involving

Andrew Chow, Ademan+17 others

Bitcoin developers are discussing alternatives to traditional mailing list infrastructure due to concerns about centralization, particularly with Google Groups. They value the decentralized nature of email for its archival capabilities and freedom from censorship.


14 replies

Posted November 10, 2023 12:54 UTC

Authored by

Thomas Voegtlin

Involving

Olaoluwa Osuntokun, Matt Corallo+4 others

Thomas Voegtlin has proposed a third strategy for Just-In-Time (JIT) liquidity in the Lightning Network by suggesting changes to BOLT-11 invoices to include bundled payments, designed to cater to non-custodial exchanges that require prepayment of fees. This approach would help protect service providers from denial-of-service attacks and on-chain fee incurrence.


1 reply

Posted November 8, 2023 06:47 UTC

Authored by

Luke Kenneth Casson Leighton

The significance of accommodating various contributors' access and connectivity limitations in software development projects is highlighted by a programmer's personal experience with reliance on a mobile LTE/WIFI dongle. This setup is not only pay-as-you-go but also subject to service disruptions due to weather conditions, emphasizing the impracticality of assuming universal access to high-speed internet for all contributors.


1 reply

Posted November 8, 2023 06:08 UTC

Authored by

Anthony Towns

There is news that the Linux Foundation will soon stop hosting mailing lists, which has prompted discussions on alternative platforms for community engagement and development discourse. A forum named "Delving Bitcoin" has been established to serve as a potential venue for such discussions, particularly focusing on lightning-related research and development topics.


3 replies

Posted November 8, 2023 02:00 UTC

Authored by

Luke Kenneth Casson Leighton

Involving

James Blacklock

The discussion opens with a recognition of the importance of email lists as a means to stay abreast of technical dialogues within a particular community. It's suggested that email lists are a preferred method for knowledge sharing, and there is an active search for alternatives to the current system, indicating some limitations or the need for better features.


1 reply

Posted November 7, 2023 23:22 UTC

Authored by

Robin Linus

In a recent development within the BitVM ecosystem, the integration of a hash function to verify Merkle inclusion proofs has been successfully implemented. This advancement allows for an effectively unlimited memory capacity within the Bitcoin Script without necessitating expensive bit commitments.


2 replies

Posted November 7, 2023 17:31 UTC

Authored by

Joe

Involving

symphonicbtc

The discourse centers around a novel mnemonic generation method proposed by Joe, which aims to simplify and personalize the process of obtaining mnemonic phrases for cryptocurrency wallets. Joe's approach allows users to create their own easy-to-remember sentences in any language and then uses the SHA256 algorithm to transform these sentences into entropy.


8 replies

Posted November 7, 2023 12:24 UTC

Authored by

Erik Aronesty

Involving

JK, alicexbt+2 others

The email discussion opens with a critical examination of Bitcoin's economic model, particularly the challenges stemming from its programmed halvings and inflation rate. It points out that the system's initial expansion, which helped stakeholders weather high inflation phases, is nearing saturation, and the lack of control over the transition from high to low inflation rates is causing favoritism and conflicts of interest among different user groups.


2 replies

Posted November 7, 2023 11:34 UTC

Authored by

Andrew Chow

Involving

Salvatore Ingala

The correspondence from Salvatore underscores a critical evaluation of the proposed Bitcoin Improvement Proposal (BIP) draft for MuSig2 descriptors, a new addition to Bitcoin Core intended to streamline the process for multiple signers to jointly create a single signature. The BIP draft, found on GitHub, introduces descriptors that offer an abstraction layer for defining sets of addresses and scripts within Bitcoin software.


10 replies

Posted November 5, 2023 00:18 UTC

Authored by

Antoine Riard

Involving

Bernard Parah, Matt Corallo+1 others

Antoine Riard has communicated his decision to not attend the African Bitcoin conferences in December due to logistical challenges. Despite this, he remains committed to organizing a Lightning Network (LN) Summit in June 2024 but is now considering alternative locations such as London, Paris, or South France, as operations there would be more straightforward.


1 reply

Posted November 4, 2023 16:16 UTC

Authored by

AdamISZ

In this email, the sender discusses their recent thoughts on "PathCoin," a concept related to transferring coins. The sender acknowledges that their earlier conceptions were too specific and that there is a wide range of possibilities for transferring coins in this manner.


25 replies

Posted November 4, 2023 09:58 UTC

Authored by

Ali Sherief

Involving

Michael Folkson, Erik Aronesty+10 others

Bitcoin developers are engaged in discussions to find solutions for the current high fee environment, prevent spam transactions, and ensure the long-term sustainability and decentralization of the network. Proposed solutions include fixing layered protocols, introducing new opcodes like OP_ZKP, reallocating block space, and penalizing non-economic transactions.


3 replies

Posted November 3, 2023 19:57 UTC

Authored by

John Carvalho

Involving

Peter Todd, Antoine Riard

In the email exchange between Antoine and John, the discussion revolves around the safety issues related to lightning and other time-sensitive layers being affected when blocks are full. Antoine mentions that this issue has been described in a paper under the "forced expiration spam" problems arising within a high block space demand environment.


1 reply

Posted November 3, 2023 17:21 UTC

Authored by

Michael Ford

Bitcoin Core version v26.0rc2 binaries are now available for download from the official Bitcoin Core website (https://bitcoincore.org/bin/bitcoin-core-26.0/test.rc2/). The source code can be accessed on GitHub under the signed tag (https://github.com/bitcoin/bitcoin/tree/v26.0rc2).


5 replies

Posted October 31, 2023 22:12 UTC

Authored by

ZmnSCPxj

Involving

Antoine Riard, AdamISZ

The email discusses various aspects related to off-chain mechanisms in blockchain technology, specifically focusing on the Bitcoin blockchain. The sender introduces the concept of an actuary role, similar to miners in the blockchain, who are responsible for deciding transaction ordering without having custody of funds.


7 replies

Posted October 31, 2023 13:05 UTC

Authored by

Rusty Russell

Involving

Brandon Black, Anthony Towns+1 others

Rusty explores the feasibility of validating Taproot outputs in Bitcoin Script to enable useful vaults. He suggests including opcodes such as OP_TXHASH/OP_TX, OP_MULTISHA256 (or OP_CAT), OP_KEYADDTWEAK, and OP_LESS (or OP_CONDSWAP) to achieve this functionality.


8 replies

Posted October 31, 2023 13:05 UTC

Authored by

Rusty Russell

Involving

Brandon Black, Anthony Towns+1 others

The email exchange discusses the exploration of different ways to implement vaults and improve the functionality of Bitcoin Script. The sender's goal is to create a usable vault that offers both security and flexibility.


20 replies

Posted October 27, 2023 18:32 UTC

Authored by

Ethan Heilman

Involving

alicexbt, Andrew Poelstra+8 others

The email discusses the availability of patches for the inquisition project on GitHub, along with the need to update and add tests for these patches. The sender suggests comparing these patches with similar commits from APO/CTV PRs.


20 replies

Posted October 27, 2023 18:32 UTC

Authored by

Ethan Heilman

Involving

alicexbt, Andrew Poelstra+8 others

The email introduces a draft BIP proposing the activation of the OP_CAT opcode in Bitcoin tapscript. The proposed opcode allows for the concatenation of two values on the stack, providing a general-purpose way to combine objects in tapscript.


16 replies

Posted October 27, 2023 17:05 UTC

Authored by

Casey Rodarmor

Involving

Andrew Poelstra, Léo Haf+8 others

The email discusses the need for a comprehensive evaluation process for Bitcoin Improvement Proposals (BIPs) in order to address challenges related to governance and decision-making within the Bitcoin community. It suggests that there should be a clear distinction between BIPs that are fundamental to the core protocol and those that are optional or experimental.


11 replies

Posted October 24, 2023 09:12 UTC

Authored by

Bastien TEINTURIER

Involving

Tony Giorgio, SomberNight+3 others

The email discusses the possibility of introducing a 0-channel reserve option into the protocol for non-custodial wallets. The sender suggests adding this feature through a Blip and mentions the usefulness of including information on how to prove possible cheating attacks in the spec/blip.


11 replies

Posted October 24, 2023 09:12 UTC

Authored by

Bastien TEINTURIER

Involving

Tony Giorgio, SomberNight+3 others

The email discusses the review of an implementation called lnd and mentions that it currently checks that the reserve is at least the dust limit, which the sender finds reasonable. However, with the proposed protocol update, this requirement will need to be modified.


20 replies

Posted October 24, 2023 08:09 UTC

Authored by

Bastien TEINTURIER

Involving

ZmnSCPxj, Greg Sanders+2 others

The email discusses the challenges involved in designing a protocol for lightning withdrawals from exchanges. The current method of enabling withdrawals shifts the burden of on-chain transactions to the user's wallet provider, resulting in multiple splice transactions if multiple users withdraw funds.


20 replies

Posted October 24, 2023 08:09 UTC

Authored by

Bastien TEINTURIER

Involving

ZmnSCPxj, Greg Sanders+2 others

The email discusses Antoine's concerns about the robustness of secure fee-bumping in multi-party transactions and covenant-enable constructions. Antoine acknowledges Bastien's proposed protocol for batched splices but raises a concern about the feasibility of interactive re-generation of a bumped Replace-By-Fee (RBF) transaction in a hypothetical scenario with mempool spikes.


3 replies

Posted October 20, 2023 22:01 UTC

Authored by

Fabian

Involving

Peter Todd

In the email exchange, Fabian addresses a potential malleability issue in the UTXO set dump files used by assumeutxo. He mentions that the sha256 hash of the snapshot file itself could be considered as the canonical hash to eliminate any malleability issues.


3 replies

Posted October 20, 2023 22:01 UTC

Authored by

Fabian

Involving

Peter Todd

A recent email discussion raised the question of using the SHA256 hash in a snapshot file. James suggested that instead of hashing the snapshot file separately, it would be more efficient to use the hash of the file itself as the canonical hash.


6 replies

Posted October 17, 2023 18:00 UTC

Authored by

Robin Linus

Involving

Lloyd Fournier, symphonicbtc+3 others

The email conversation discusses the potential use of Simplicity's core language to generate circuits for the BitVM. The sender shares their success in compiling Simplicity expressions to polynomial constraints, suggesting that logic gates can be generated in a similar manner.


6 replies

Posted October 17, 2023 18:00 UTC

Authored by

Robin Linus

Involving

Lloyd Fournier, symphonicbtc+3 others

The email from Adam Gibson discusses the concept of "scriptless script" and explores its potential applications in Bitcoin. Scriptless script refers to a technique that allows for the execution of complex smart contracts on Bitcoin without revealing the details of the contract on the blockchain.


7 replies

Posted October 12, 2023 09:31 UTC

Authored by

Antoine Riard

Involving

ZmnSCPxj, Johan Torås Halseth

In the email, Johan discusses the concept of using a merkle root to track participants' keys and balances in a cryptocurrency system. He provides a demo script that shows how pubkeys and balances can be committed, how data can be traversed and modified, and how signatures can be validated for exiting users.


5 replies

Posted October 12, 2023 07:43 UTC

Authored by

Andrew Chow

Involving

Anthony Towns, Jonas Nick

In the email conversation, various topics related to BIP 327 ("MuSig2") and adaptor signatures are discussed. The context starts by mentioning that BIP 327 does not include adaptor signatures, and the decision was made due to the complexity of the BIP and the higher demand for single-signer adaptor signatures at the time.


5 replies

Posted October 12, 2023 07:43 UTC

Authored by

Andrew Chow

Involving

Anthony Towns, Jonas Nick

The email thread discusses the absence of adaptor signatures in BIP 327 ("MuSig2") and the rationale behind this decision. The author mentions that the BIP is already long and complicated enough without including adaptor signatures.


22 replies

Posted October 11, 2023 20:52 UTC

Authored by

Dhruv M

Involving

Pieter Wuille, Vasil Dimov+6 others

The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows.


2 replies

Posted October 3, 2023 07:53 UTC

Authored by

Anthony Towns

Involving

Johan Torås Halseth

In the email, Johan acknowledges a typo pointed out by aj and confirms that "O(log n)" is the correct notation instead of "O(n log n)". Johan clarifies that the variable P, representing the size of the program, does not matter in this context because the program is never put entirely on-chain.


3 replies

Posted October 3, 2023 07:53 UTC

Authored by

Johan Torås Halseth

Involving

Anthony Towns

The email discusses the complexity notation of "O(n log n)" and suggests that it may be incorrect. The sender proposes that it should be denoted as "O(P + log(N))" where P represents the size of the program and N represents the number of steps (rounded up to a power of 2). However, the recipient disagrees with this suggestion and explains that it is necessary to directly know the values of h(sub_node1) and h(sub_node2) in order to compare them to the results obtained from running the computation.