Bitcoin Optech Newsletter #104

This week’s newsletter summarizes a discussion about mining incentives
related to HTLCs and links to an announcement about a proposed service to
store and relay presigned transactions. Also included are our regular
sections with recently transcribed talks and conversations, new releases
and release candidates, and notable changes to popular Bitcoin
infrastructure projects.

Action items

None this week.


  • Discussion of HTLC mining incentives: Itay Tsabary, Matan
    Yechieli, Ittay Eyal posted to the Bitcoin-Dev mailing
    list with a paper they’ve written. They claim that rational miners should
    want to run a modified Bitcoin node that allows a user to bribe it
    with a transaction that’s timelocked and can’t be confirmed until some
    point in the future. As a result of this bribe, the miner won’t
    confirm any transaction that could be mined immediately but which
    conflicts with the bribe (as long as the bribe pays a sufficiently
    higher feerate than any transactions it blocks).

    If this theory is accurate, it affects Hash TimeLock Contracts (HTLCs) which can be settled immediately by one party (Alice) using a preimage, or which can be settled later by a second party (Bob) after a timeout. According to the authors, if Bob sees Alice use the preimage to spend the HTLC, Bob should send his conflicting timeout settlement transaction to miners with a sufficiently higher feerate than Alice’s preimage settlement—even though miners can’t immediately include Bob’s transaction—bribing them to ignore Alice’s transaction in favor of waiting to confirm his alternative transaction. This allows Bob to steal the money Alice should receive. HTLCs are currently used in LN, atomic swaps, and several other contract protocols.

    The authors of the paper propose a solution they call Mutually Assured Destruction HTLCs (MAD-HTLCs). These require Bob to provide a hashlocked bond that makes him reveal his own preimage when sending his timeout settlement. If both Alice and Bob reveal their respective preimages, miners will be able to claim both the payment/refund amount and the bond collateral—destroying the incentive for Bob to attempt to steal by bribing miners.

    The downsides to this approach are that it requires Bob to use more collateral—raising the cost of using HTLCs—and it uses more block chain space when MAD-HTLCs are settled onchain compared to traditional HTLCs—also raising costs. It was also claimed in the mailing list discussion that MAD-HTLCs might have their own problems with theft when the bonded user’s counterparty is a miner (e.g. Alice is a miner).

    ZmnSCPxj noted that a mechanism already exists to allow Alice to discourage Bob from attempting his theft: Alice can enact a scorched earth policy where she spends all of her legitimate funds to fees in order to prevent Bob from receiving them. In theory, this should prevent Bob from even trying the theft. Another paper by Majid Khabbazian, Tejaswi Nadahalli, and Roger Wattenhofer was mentioned in the discussion, which showed (among other things) that nearly all miners would need to switch to the proposed bribe-accepting software before the attack would become particularly effective under normal conditions.

    In the short term, and probably the medium term, this attack does not appear to pose any significant danger to HTLCs whose receivers resolve their preimages well before their timelocks expire. In the long term, this is an incentive compatibility concern that protocol developers may want to keep in mind.

  • Proposed service for storing, relaying, and broadcasting presigned transactions:
    Jacob Swambo sent a request for comments to the Bitcoin-Dev
    mailing list about creating software and a protocol for allowing
    applications to store presigned transactions with third-party services
    for later broadcast. The software could also perhaps determine when to
    broadcast the transactions based on certain conditions being met. This
    could be useful for software such as vaults and
    watchtowers. Swambo asks anyone interested in
    the idea, especially those interested in using it with their protocol, to
    contact him.

Recently transcribed talks and conversations

Bitcoin Transcripts is the home for transcripts of technical
Bitcoin presentations and discussions. In this monthly feature, we
highlight a selection of the transcripts from the previous month.

  • Magical Bitcoin: Alekos Filini presented at LA BitDevs on Magical
    , a set of tools and libraries under development for onchain
    wallet developers. He explained that coin selection logic and
    transaction signing logic currently have to be rewritten multiple times
    across multiple projects—a problem Magical Bitcoin aims to address
    with modular, extensible, and peer-reviewed components. A longer
    term ambition is to provide a platform for building native
    wallets and integrating them with existing projects. Filini demoed
    the current functionality, which includes a playground with a Policy
    to Miniscript compiler and some rudimentary
    visualizations. It is written in Rust and leverages the
    rust-miniscript library and the open source Esplora block explorer.
    (transcript, video)

  • Watchtowers and BOLT13: Sergi Delgado appeared on Potzblitz to
    discuss the latest state of watchtower
    development and a proposed watchtower protocol specification. He
    explored the various tradeoffs when designing a watchtower and the
    interplay between privacy requirements, accessibility, storage, and
    fees charged. Delgado is working on the watchtower implementation
    The Eye of Satoshi at Talaia Labs, which is aiming to be
    compliant with the proposed BOLT13 (see Newsletter #75). Delgado also highlighted how watchtowers are
    becoming increasingly critical in multiple settings such as Bitcoin
    vault designs, statechains, and atomic swaps in addition to LN.
    (transcript, video,

  • Coinswap: Aviv Milner presented on coinswap at the Wasabi Research
    Club. He explained the property of covertness and how Chris Belcher’s
    coinswap proposal (see Newsletter #100) provides
    covertness in a manner that other privacy schemes such as
    coinjoin fail to do. Milner also went through the
    motivation for routing coinswaps, namely to address the concern of
    unwittingly entering into a coinswap with an adversary such a chain
    surveillance company. (transcript, video)

  • Schnorr signatures and multisignatures: BIP340 co-authors Tim
    Ruffing, Pieter Wuille, and Jonas Nick held a discussion at London
    Bitcoin Devs on the specification of schnorr signatures. This covered earlier ideas for implementing
    schnorr signatures in Bitcoin and what the co-authors thought the
    community should be concerned about when considering a possible future
    soft fork deployment. Wuille noted that he is most concerned about how
    schnorr is adopted and what is built using it. The following day, Tim
    Ruffing presented on the challenges of multisignature and threshold
    signature schemes using schnorr signatures (see also Newsletter
    ). He’s been working with
    collaborators on a speculative MuSig signature scheme
    that only requires two rounds of interaction rather than three,
    without relying on zero knowledge proofs, which would greatly simplify
    some threshold and multisignature signing workflows. (Meeting transcript,
    meeting video, presentation transcript,
    presentation video, presentation slides)

  • Sydney meetup discussion: A number of Bitcoin and LN developers
    joined this Sydney meetup to discuss various topics. Ruben Somsen gave
    a short presentation on Succinct Atomic Swaps (SAS) (see Newsletter
    ) and how it compares to Chris Belcher’s coinswap
    proposal. Another topic was Bitcoin Core’s reliance on DNS seeds to
    find initial peers, whether it’s a potential attack vector against newly
    started nodes, and how work by Matt Corallo and Antoine Riard on
    allowing alternative transports could help
    mitigate some risks. Finally, Lloyd Fournier discussed how
    experimenting with his toy Rust implementation of secp256k1
    (secp256kfun) led to a small fix in the ECDSA
    signature code in the actual secp256k1 library. The transcript was
    anonymized to encourage open discussion. (transcript)

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.

  • Hardware Wallet Interface (HWI) 1.1.2: this release includes support
    for handling PSBTs with serialized previous segwit
    transactions, which is now required or suggested for several hardware
    wallets in response to the fee overpayment attack.

  • LND 0.10.2-beta.rc4: this release candidate for an
    LND maintenance release is now available for testing. It includes
    several bug fixes, including an important fix related to the creation
    of backups.

  • LND 0.10.3-beta.rc1: this release candidate,
    separate from the 0.10.2 RC, includes a package refactoring in
    addition to the bug fixes provided in 0.10.2. For details, see a
    mailing list post by LND developer Olaoluwa

Notable code and documentation changes

Notable changes this week in Bitcoin Core,
C-Lightning, Eclair, LND,
Rust-Lightning, libsecp256k1,
Hardware Wallet Interface, Bitcoin Improvement Proposals
, and Lightning BOLTs.

  • Bitcoin Core #19305 adds release notes for the upcoming codebase
    transition from the C++11 standard to C++17. The plan is to add C++17
    compatibility in the 0.21 release (expected end
    of 2020) and break C++11 compatibility later in 0.22 (expected mid-2021).
    Although this change won’t affect most users, those planning to build
    the 0.22 release on older systems may want to check their toolchain’s standard
    support against the C++ compiler support matrix.

  • Bitcoin Core #11413 updates the bumpfee, fundrawtransaction,
    sendmany, sendtoaddress, and walletcreatefundedpsbt RPCs to
    allow manually specifying the feerate to use in the newly created or
    updated transaction. By default, these commands still use either an
    automatic feerate computed by Bitcoin Core’s built-in transaction fee
    estimate or the fallback feerate if there’s not enough data for
    estimation. For details on how to use the updated RPCs, see the
    proposed release note. Despite not affecting any major
    system, this PR was open for almost three years—the second longest
    of any PR that has been merged into Bitcoin Core so far. We thank the
    author, Kalle Alm, and everyone else involved for their persistence.

  • Eclair #1466 decreases the length of time that an Eclair node will wait
    before closing a channel when a peer becomes unresponsive while an HTLC is
    pending. To prevent payments from becoming stuck forever, each HTLC includes
    a timelock. If the timelock expires, then the sending party can reclaim
    the funds in the HTLC. To prevent the sending party from pulling back
    funds that an intermediate party has already paid to the next hop, the
    intermediate party must settle the pending HTLC onchain if the sending
    party becomes unresponsive. This PR increases Eclair’s safety window—it
    will now broadcast the onchain transaction 24 blocks before the HTLC
    timeout, instead of 6 blocks before the timeout.

  • LND #4018 adds the ability to delay forwarding a payment (HTLC),
    giving an external process the ability to review it and decide whether
    to cancel it or continue forwarding it. This is similar to hold
    but it applies to payments being routed
    to a node’s peers rather than received by the node itself. Several
    use cases are described in the PR—for example, one idea is to hold an
    HTLC, detect that its next hop is offline (e.g. a mobile node), send a
    notification to that node which will restart it, and then continue
    relaying the HTLC.

  • LND #4106 adds a getrecoveryinfo RPC that returns information
    about the progress of restoring from a backup.

  • BIPs #933 adds the BIP339 specification for transaction
    relay announcement using Witness Transaction Identifiers (wtxids).
    Currently, nodes announce new unconfirmed transactions to their peers
    using the transaction’s txid, which is a hash over the legacy fields
    of the transaction. The new fields used in segwit transactions are
    not included in the txid, which was necessary to eliminate third-party
    and counterparty transaction malleability. However, during his June 2018 review
    of segwit, Peter Todd noticed that
    announcing transactions by their txid could allow nodes to modify the
    segwit fields before relaying a transaction. This couldn’t be used to
    steal money directly, but it did allow a relay node to mutate a valid
    transaction into an invalid or unacceptable transaction without
    changing its txid.

    Before Todd’s discovery, this was a problem: Bitcoin Core would track the txids of invalid transactions it had recently seen and refuse to download them again. That meant a malicious node could prevent any of its peers from downloading a valid segwit transaction from any of their other peers by sending them a mutated version of that transaction. Arbitrary transaction censorship, even just at the relay level, is bad by itself—but it has especially severe consequences for time-sensitive protocols such as LN.

    At the time of Todd’s analysis, segwit was nearing release, so a quick fix was implemented that prevents Bitcoin Core from caching the rejection status of segwit transactions that fail for the type of witness-related errors that malicious nodes can inject. This eliminated the issue, but it means that Bitcoin Core uses more bandwidth than necessary when it encounters segwit transactions that are invalid because of accidental mistakes. It may also complicate the development of new relay protocols such as package relay.

    The long-term solution to the problem is that transactions should be announced using a hash that commits to the entire transaction—both the legacy fields and the new segwit fields. That’s exactly what wtxids do, and they’re already needed in the protocol to construct the witness merkle root in each block’s coinbase transaction. This new BIP proposes updating the P2P protocol’s inv message that announces new transactions, and the getdata message that requests a transaction, to allow them both to use wtxids. That will allow nodes to skip re-downloading a transaction if it has the same wtxid as a transaction that was previously found to be invalid or unacceptable.

    The BIP339 proposal also adds the additional feature negotiation between newly started nodes described in Newsletter #87. See also the proposed implementation for Bitcoin Core.

  • BIPs #923 adds the BIP78 specification for the version of the
    payjoin protocol originally implemented in BTCPay
    (see Newsletter #94). Payjoin allows a spender
    and a receiver to both add UTXOs to a transaction. This decreases the
    reliability of the assumption made by third-party block chain
    surveillance companies that any set of UTXOs spent in the same
    transaction were all received by the same person. BIP78 is based on
    the BIP79 specification of the Bustapay payjoin variant (see
    Newsletter #13) but contains several notable
    differences, including different extensions to BIP21 bitcoin:
    URIs, usage of PSBTs, and some additional requirements designed to
    enhance privacy. Several programs already support this protocol and
    several more are currently working on adding support. The PR for this
    BIP received significant discussion and may provide useful reference
    material for anyone interested in the subject.

  • BIPs #550 revises the BIP8 alternative to BIP9
    versionbits-based soft fork deployment. BIP8 previously allowed a
    soft fork to be activated by miner signaling using the same parameters
    as would be used for BIP9, but it required that the soft fork activate
    at the end of the signaling period even if miners were still not
    signaling readiness to follow the new consensus rules. This could be
    used to override miners who were obstructing activation of a fork, but
    it could also lead to diverging block chains between nodes that
    enforced the fork’s new consensus rules and those that didn’t.

    The main change to BIP8 from its previous version is that it may now be used initially without requiring mandatory lock-in. Implementations may choose to commit to lock-in after their initial deployment of a BIP8-activated soft fork. BIP8 mandates signaling for a period after the mandatory lock-in height, which will trigger even deployments without mandatory lock-in to begin enforcing the new rules at the same time as the mandatory lock-in nodes; in the best case, this allows the entire economy to synchronously begin enforcing the new rules.

—Source link—

What do you think?

Making Maker: June 2020

Nervos CKB Development Update #37