Bitcoin Optech Newsletter #128 Bitcoin Optech

This week’s newsletter describes two suggested improvements to LN static
backups and links to a proposal for a new version of PSBTs. Also
included are our regular sections with summaries of changes to services
and client software, popular questions and answers from the Bitcoin
StackExchange, new releases and release candidates, and notable changes
to popular Bitcoin infrastructure projects.

Action items

None this week.

News

  • Proposed improvements to static LN backups: anyone receiving money
    in a payment channel, including those currently used by LN, needs to
    keep track of the channel’s latest state—all the details that make
    it possible to close the channel and receive the correct share of the
    channel’s funds onchain. Unfortunately, computers have a bad habit of
    losing data and regular periodic backups don’t help much when a
    channel’s state could have changed just milliseconds before a disk drive
    fails.

    LN has always provided some robustness against this type of problem: if your node is offline, your channel counterparty will eventually close the channel so that they can start spending their funds again. This will send your funds to the onchain part of your LN wallet, which you hopefully backed up using a normal BIP32 seed. This should be reasonably safe: LN’s regular penalty mechanism encourages your counterparty to close the channel in its latest state—if they use an old state, they could lose all their money from the channel.

    The downside of the above approach is that you have to wait for your counterparty to decide that you’re not coming back. This wait can be eliminated if you back up some static information about your channel (e.g. the ID of your peer), reconnect to the peer after you lose data, and request that the peer immediately close the channel. This does seem to indicate that you’ve lost data and so your peer could close the channel in an old state—but, if they try that and you still have your old data, you can penalize them.

    This week, Lloyd Fournier started two threads on the Lightning-Dev mailing list about possible improvements to the above mechanisms:

    • Fast recovery without backups: the static per-channel backups
      that allow fast recovery of funds require you to create a new backup
      each time you open a new channel. If you fail to make a backup,
      your only option is to wait until your channel counterparty
      decides to close the channel on their own. Fournier instead
      proposed a deterministic key derivation method that would allow a
      node to search through the list of public LN nodes, combine
      information about its private keys derived from its HD wallet with
      information about each node’s main public key, and determine
      whether or not it had a channel with that node. This backup strategy would only
      work for channels opened with public nodes, which are expected
      to be the most common type of channel for typical users.

    • Covert request for mutual close: the existing mechanism for
      closing a channel requires that your counterparty broadcast their
      unilateral commitment transaction. It would be better to use a
      mutual close transaction—this uses less space onchain, requires
      paying less fees, is not identifiable onchain as having belonged
      to an LN channel, and allows both parties to spend their funds
      immediately. However, mutual close transactions don’t contain any
      penalty mechanism, so if you request a channel be closed and your
      counterparty gives you an inaccurate mutual close transaction,
      there’s no way for you to penalize them. In the normal protocol,
      this isn’t an issue—you’d just broadcast the latest state, but
      if you’ve lost your state, then you have no remedy.

      Fournier proposed a solution using a cryptographic primitive called oblivious transfer that allows your counterparty to send you the mutual close transaction encrypted in a way that allows you to either use it (closing the channel) or prove that you can’t decrypt it (allowing them to safely continue accepting payments in the channel). If you use this procedure every time you reconnect, you don’t reveal to them that you lost any data until after they’ve provided you all the information you need to recover.

  • New PSBT version proposed: Andrew Chow, author of the BIP174
    specification of Partially Signed Bitcoin Transactions
    (PSBTs), proposed a new version of PSBTs that will contain
    several backwards incompatible features, although it’ll be largely the
    same as the current version 0 PSBT.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin
wallets and services.

  • Bitcoin Wallet Tracker adds descriptor support:
    Bitcoin Wallet Tracker’s 0.2.0 release adds support for tracking
    output script descriptors and introduces libbwt,
    a library for allowing Electrum-backed wallets to easily support a Bitcoin
    Core full node.

  • JoinMarket now defaults to native segwit addresses:
    While JoinMarket supported segwit since 0.5.1, version 0.8.0
    now uses bech32 native segwit addresses by default for coinjoins.

  • Bisq adds segwit for trade transactions:
    Building on previous bech32 support for deposits and
    withdrawals, Bisq v1.5.0 adds segwit support within trade
    transactions as well as implementing fee optimizations.

  • PSBT Toolkit v0.1.2 released:
    PSBT Toolkit, software that “aims to give you a nice
    gui that gives you functionality for PSBT interactions”, released various
    improvements in its 0.1.2 version.

  • Sparrow adds Replace-By-Fee:
    Sparrow 0.9.8 adds Replace-By-Fee (RBF)
    functionality and support for HWI 1.2.1.

  • Ledger Live adds Bitcoin Core full node support:
    Ledger Live, using the open source Ledger SatStack
    application, can now connect to a Bitcoin full node for
    sending transactions and providing balances in a more private way, without
    using Ledger’s explorers.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.

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.

  • Bitcoin Core 0.21.0rc3 is a release candidate
    for the next major version of this full node implementation and its
    associated wallet and other software. Note, the macOS version of the
    signed binary will not run due to a problem with the
    code signing tool. The unsigned version (which can
    still be verified with PGP) should run if opened
    using the right-click (or control-click) context menu. Developers are
    working on fixing this problem for future release candidates and the
    final relase.

  • LND 0.12.0-beta.rc1 is the first release candidate
    for the next major version of this LN node. It makes anchor
    outputs
    the default for commitment
    transactions and adds support for them in its watchtower implementation, reducing costs and increasing safety, and
    adds generic support for creating and signing PSBTs.
    Also included are several bug fixes.

  • Bitcoin Core 0.20.2rc1 and 0.19.2rc1 are expected to be
    available sometime after the publication of
    this newsletter. They contain several bug fixes, such as an
    improvement described in Newsletter #110 that will
    prevent them from redownloading future taproot transactions that they
    don’t understand.

Notable code and documentation changes

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

  • Bitcoin Core #20564 makes two changes to the way that Bitcoin Core
    signals support for addrv2 messages (BIP155):

    • Protocol version: Bitcoin Core will only negotiate support for addrv2 messages with peers that signal
      they are using P2P version 70016 or higher. This restriction isn’t required by BIP155,
      but release testing has revealed that some other implementations will disconnect
      from Bitcoin Core if they receive any unknown message, including
      sendaddrv2. This change may be reverted in future versions of Bitcoin Core,
      so other implementations are advised to tolerate unknown P2P messages at any time in the connection.

    • Updated BIP: The sendaddrv2 message will now be sent between the version and
      verack message, as required by the latest version of BIP155. See BIPs
      #1043
      below for more information about that change to the BIP.

      This PR was backported to the latest V0.21 release candidate in Bitcoin Core #20612.

  • Bitcoin Core #19776 updates the getpeerinfo RPC with two new
    fields. bip152_hb_to indicates that we asked the peer to relay new
    blocks to us by sending a BIP152 compact block without waiting to
    ask if we need that specific block, called High-Bandwidth (HB) mode.
    bip152_hb_from indicates that the peer asked us to be one of their
    high-bandwidth peers. By default, each node selects up to 3 high-bandwidth compact block peers. (Despite the name,
    high-bandwidth mode doesn’t use much bandwidth compared to legacy block
    relay; its optimizations for fast relay of new blocks just uses more
    bandwidth than BIP152’s low-bandwidth mode.)

  • Bitcoin Core #19858 adds a new method for finding high-quality peers with
    the goal of making eclipse attacks more difficult.
    It opens an outbound connection every five minutes on average to a new peer
    and syncs headers with it. If the peer tells the node about new blocks, the
    node disconnects an existing block-relay-only peer and gives that connection
    slot to the new peer; otherwise, the new peer is dropped. Provided the node
    knows the IP address of at least one other honest node, this peer rotation should raise the cost of
    sustaining a partitioning attack against it, as the node should always
    eventually find the valid chain with the most work. The increased rotation and
    security will slightly reduce the number of open
    listening sockets on the network, but it is expected to help bridge the network
    as a whole via more frequent connections, add edges to the network
    graph, and provide more security against partitioning attacks in general.

  • Bitcoin Core #18766 disables the ability to get fee estimates when
    using the blocksonly configuration option. This bandwidth-saving
    option stops Bitcoin Core from requesting and relaying unconfirmed
    transactions. However, Bitcoin Core’s fee estimates are also
    dependent on tracking how long it takes transactions to become
    confirmed. Previously, when blocksonly was enabled, Bitcoin Core
    stopped updating its estimates but continued to return the
    estimates it had already generated, producing increasingly out of date
    estimates. After this change, it won’t return any estimates at all
    when blocksonly mode is enabled.

  • C-Lightning #4255 is the first of a series of pull requests for an
    initial version of offers—the ability to request and receive invoices
    over the LN. A common use of this feature would be that a
    merchant generates a QR code, the customer scans
    the QR code, the customer’s LN node sends some of the details from the
    QR code (such as an order ID number) to the merchant’s node over LN,
    the merchant’s node returns an invoice (also over LN), the invoice is
    displayed to the user (who agrees to pay), and the payment is sent.
    Although this use case is already addressed today using BOLT11
    invoices, the ability for the spending and receiving nodes to
    communicate directly before attempting payment provides much more flexibility. It
    also enables features that aren’t possible with BOLT11’s one-time-use
    hashlocks, such as recurring payments for subscriptions and donations.
    See the BOLT12 draft for more information.

  • Eclair #1566 abstracts out all connection-handling logic into a front
    node, which can be distributed across multiple hosts to achieve
    high availability for production deployments. These front nodes also handle
    CPU/bandwidth-intensive BOLT7 messages, such as routing table related
    gossip and syncing requests, in a distributed manner, improving scalability
    for larger node deployments like ACINQ’s. For readers looking to deploy this
    change, an AWS Beanstalk bundle is available, and the author recommends using
    the AWS Secrets Manager to store the node’s private key, a topic previously
    covered in the SuredBits field report.

  • Eclair #1610 allows overriding the default relay fees when
    opening a new channel using the new feeBaseMsat and
    feeProportionalMillionths options.

  • LND #4779 allows the node to claim payments (HTLCs) that weren’t
    yet settled at the time a channel using anchor outputs was closed.

  • BIPs #1043 changes the way that support for BIP155 is negotiated between
    peers. Previously, the BIP specified that a node should send a sendaddrv2 message
    to signal support for BIP155 after receiving a verack message from its peer.
    The BIP now specifies that the node must send the sendaddrv2 message
    earlier in connection establishment, between sending its version and verack
    messages. This is consistent with how BIP339 negotiates wtxid relay support
    and also with a generic method for negotiating features
    proposed to the mailing list earlier this year.

    John Newbery posted a summary of all the changes to BIP155 since it was proposed in February 2019 to the Bitcoin-dev mailing list.

  • BOLTs #803 updates BOLT5 with recommendations for preventing
    a transaction pinning attack. The recent
    anchor outputs update to the LN specification
    allows multiple payments (HTLCs) that were pending at the time a
    channel was unilaterally closed to all be settled in the same
    transaction. A potential problem is that some of those outputs may
    pay your channel counterparty, giving them the ability to pin the
    transaction and prevent the other HTLCs in the batch from confirming
    until after their timelocks expire. The recommendation is to allow
    batching the HTLCs for maximum efficiency when there’s plenty of time
    left but to split each HTLC into a separate transaction when the
    timelock expiration is approaching so that pinning isn’t a problem.

Correction

Newsletter #87 incorrectly claimed that “previous versions of Bitcoin
Core would terminate a new connection if certain messages didn’t appear
in a particular order”. We were alluding to a belief that the version
message needed to be immediately followed by the verack message
introduced in Bitcoin 0.2.9 (May 2010). Subsequent code review and
testing of old versions of Bitcoin Core by Optech contributors did not
substantiate this statement and we’ve added a correction to the original
text. We apologize for the error.

Holiday publication schedule

Happy holidays! This issue is our final regular newsletter for the
year. Next week we’ll publish our annual special year-in-review issue.
We’ll return to regular publication on Wednesday, January 6th.

—Source link—

What do you think?

Aave (AAVE), Bancor (BNT) and Synthetix (SNX) are now available on Coinbase The Coinbase Blog – Medium

Bitwise Lists Crypto Index Fund DeFi Rate