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.

News

• ● 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
  Bitcoin, 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,
  slides)

• ● 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
  #68). 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
  #98) 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
  Osuntokun.

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
(BIPs), 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
  invoices 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—