Bitcoin Optech Newsletter #116 Bitcoin Optech

This week’s newsletter describes a proposed soft fork to enable a new
type of fee bumping and summarizes research into scripts that can never
be spent because they require satisfying both timelocks and heightlocks.
Also included are our regular sections with summaries of updates to
services and client software, a list of new releases and release
candidates, and changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

  • Transaction fee sponsorship: Jeremy Rubin posted a proposal to the Bitcoin-Dev mailing list for a soft fork to
    add a new fee bumping mechanism that could be less vulnerable to abuse
    than the current Replace-by-Fee (RBF) and
    Child-Pays-For-Parent (CPFP) methods. Transacting
    pinning
    and other abuses
    against the existing system can be used to attack contract
    protocols. These problems have led to partial solutions such as anchor
    outputs
    that work with specific protocols (e.g.
    two-party LN channels) but aren’t easy to generalize and so are
    somewhat unsatisfactory.

    At the consensus layer, Rubin proposes allowing transactions to optionally contain a special final output that commits to the txids of one or more other unconfirmed transactions. The transaction with the special output, called a sponsor transaction, may only be included in a valid block if every one of the transactions it sponsored is also included in that same block. This means a miner who wants the high feerate from a sponsor transaction will be incentivized to confirm low-feerate sponsored transactions. Beyond their special sponsorship output, sponsor transactions are normal Bitcoin transactions.

    For the rules that control mempool acceptance and transaction relay (the policy layer), Rubin suggests a set of simple changes that allow anyone to sponsor any transaction currently in a mempool or to replace an existing sponsor transaction with a higher feerate alternative that makes the same commitment. The goal is to ensure that, as long as a sponsor transaction follows the rules and pays a high enough feerate, it will propagate across the network without running afoul of pinning or other attacks.

    Rubin’s proposal comes with a reference implementation and discussion of design tradeoffs and forward compatibility. As of this writing, comments on the list have shown appreciation for Rubin’s work but also describe two significant complications:

    • Floating payments still pinnable: Antoine Riard notes that, even with a change to the proposal to allow sponsoring particular inputs,
      a malicious counterparty can pin a particular input signed with
      SIGHASH_SINGLE (e.g. HTLCs in the latest LN protocol or state
      transactions in eltoo) by including that input in a
      maximum size transaction.

    • Breaks reorg safety guarantee: Suhas Daftuar reminds readers of a founding principle of Bitcoin’s design. As
      Satoshi Nakamoto wrote, “In the event of a
      block chain reorg […], transactions need to be able to get into
      the chain in a later block.” This principle is broken by sponsor
      transactions which are only valid in the same block as the
      transactions they sponsor.

    The proposal was still being actively discussed just hours before publication of this newsletter. We’ll summarize any new notable discussion in future editions.

  • Research into conflicts between timelocks and heightlocks: A
    post to the Blockstream engineering blog describes
    an interaction between different types of Bitcoin time locks
    (timelocks) and block-height locks (heightlocks). All transactions
    since Bitcoin’s initial release have had an nLockTime field. A soft
    fork activating at block 31,000 (December 2009) began
    comparing this field against a block header’s
    explicit time field and its implicit height (number of blocks since
    the Genesis Block). A block is only valid if
    every one of its transactions follows these two
    rules:1

    • If a transaction’s nLockTime is below 500 million, it must also be
      below the block’s height.

    • If a transaction’s nLockTime is equal to or above 500 million, it
      must be below the block header’s time (in epoch time).

    This overloading of the single nLockTime field for two different purposes is efficient but has the obvious implication that a transaction can only use either a heightlock or timelock—not both.

    Years later, the BIP65 soft fork activated in December 2015 added the OP_CHECKLOCKTIMEVERIFY (CLTV) opcode that compares its argument against its spending transaction’s nLockTime field in the same way the nLockTime field is compared to the containing block’s height or time field. This allows scripts to prevent money received to them from being spent until after a certain future height or time. However, the Blockstream post explains that this also has the non-obvious implication that it’s possible to create a script that’s unspendable because it requires the simultaneous use of both heightlocks and timelocks. For example, a payment to the following script can never be spent:

     1 OP_CLTV OP_DROP 500000001 OP_CLTV
    

    The first condition allows the spending transaction to be included in block 1 or later, so any block after early January 2009, and the second condition allows it to be included in any block after early November 1985. Both conditions are true today—but they can’t both be satisfied using a transaction’s single nLockTime field. The post notes that the same problem can apply when a transaction has multiple inputs each with their own script. For example:

     Input 0: 1 OP_CLTV Input 1: 500000001 OP_CLTV
    

    The problem also applies to relative timelocks and relative heightlocks created using BIP68 sequence numbers and the BIP112 OP_CHECKSEQUENCEVERIFY opcode.

    The post notes that the Miniscript compiler has been updated to deal with the possible conflicts as best as possible. It will identify when one or more of the ways to satisfy a script contains conflicting locks and will return a warning. Because of the conflict, it’ll also not be able to provide a full analysis of the script. Additionally, the compiler for the policy language will now deliberately fail on policies that mix timelocks and heightlocks, e.g. thresh(3,after(1),after(500000001),pk(A)). Note: as of this writing, this change is only a pending PR to the Rust version of the miniscript library and has not yet propagated to the online live demos for miniscript or minsc.

Changes to services and client software

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

  • Swan supports sending to bech32 addresses:
    Swan, through their custodian Prime Trust, now supports withdrawals
    to bech32 addresses.

  • Ledger Live adds manual coin selection support:
    Moving from a first-in, first-out UTXO selection model, Ledger Live now also
    supports manual coin selection for either privacy
    or fee-minimization benefits.

  • Sparrow wallet announced:
    Sparrow wallet is a new desktop wallet supporting
    single or multisignature addresses, PSBT, hardware wallets, and coin
    selection
    .

  • JoinMarket 0.7.0 adds BIP78, PSBT:
    JoinMarket 0.7.0 includes support for BIP78 payjoin
    for payments. PSBT support was also added in order to facilitate the implementation.

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.

  • LND 0.11.1-beta.rc4 is the release candidate for a
    minor version. Its release notes summarize its changes as, “a number
    of reliability improvements, some macaroon [authentication token]
    upgrades, and a change to make our version of anchor commitments spec compliant.”

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 #16378 adds a new send RPC to the wallet. This new
    RPC is designed for maximum flexibility and includes options such as
    multiple outputs (allowing payment batching), coin selection, manual or automatic feerates, and PSBT format. It is
    intended to unify the functionality of the sendtoaddress and sendmany RPCs,
    which may be deprecated in a future release. For the full list of
    options, see the RPC help text.

  • Bitcoin Core #19643 adds a new -netinfo option to the bitcoin-cli
    command to display a peer connection dashboard. This dashboard offers
    node operators a bird’s-eye view of peer connection details such as
    directionality, relay type, network family, and uptime. An optional
    argument from 0 to 4 may be passed to display various levels of
    detail.

     $ watch -n 0.1 ./src/bitcoin-cli -netinfo 3 Bitcoin Core v0.20.99.0-bf1f913c44 - 70016/Satoshi:0.20.99/ Peer connections sorted by direction and min ping <-> relay net mping ping send recv txn blk uptime asmap id version in full onion 1 1 0 10206 70015/Satoshi:0.20.1/ in full ipv6 246 246 1 9 0 1 16509 10202 70015/Satoshi:0.19.1/ in block onion 37686 425955 42 42 25 10143 70015/Satoshi:0.20.1/ [...] out full ipv4 94 198 3 1 0 229 956 12998 7809 70015/Satoshi:0.19.0.1/ out block ipv6 107 269 64 64 949 5577 7835 70015/Satoshi:0.16.0/ out full onion 440 1180 4 4 0 257 9574 70015/Satoshi:0.18.1/ ms ms sec sec min min min ipv4 ipv6 onion total block-relay in 0 17 8 25 2 out 8 2 8 18 2 total 8 19 16 43 4 Local addresses [redacted] port 8333 score 6401 [redacted].onion port 8333 score 1085
    
  • Bitcoin Core #15454 no longer creates a new wallet when the
    program is started for the first time. Instead, the user is prompted
    to either load an existing wallet or create a new named wallet.
    Wallets created by default in earlier versions of the software will
    still be loaded by default, and newly created wallets can still be
    added to the load-on-start list (see Newsletter #111). By removing the default wallet creation, users
    gain more exposure to the options for customizing their wallet
    options, such as enabling wallet encryption, creating a watch-only
    wallet, or creating a wallet that’s ready to import output script
    descriptors
    (e.g. for multisig).

  • Bitcoin Core #19940 updates the testmempoolaccept RPC with
    additional result fields for the transaction’s vsize and total transaction fee if the
    transaction can be added to the mempool. In particular, the fee is
    information that some users need, which is guaranteed to be available
    for a mempool transaction, and which cannot be trustlessly obtained
    before broadcasting a non-wallet transaction unless several other RPCs
    are run in sequence (e.g. using decoderawtransaction and
    getrawtransaction).

  • LND #4440 records the number of times the local node sees a peer
    going offline and then coming back online, known as flapping. The
    node will limit the number of event records it’ll store about peers
    who frequently flap to avoid filling its database with too much noise.
    The listchannels RPC is also updated to display each peer’s flap
    rate.

  • LND #4567 adds a new --maxchansize configuration parameter that
    allows setting the maximum amount of money that can be contained in a
    new channel. Now that LND supports large channels (see Newsletter #107), this setting
    allows users to set a limit on the maximum amount of money they could potentially
    lose in a single channel if something goes wrong.

  • LND #4606 and #4592 improves LND’s effectiveness at
    fee bumping anchor outputs. The first PR
    calculates the feerate needed to confirm both the child anchor
    transaction and its parent commitment transaction. The second PR
    enables automatic fee bumping when a commitment transaction needs to
    be confirmed within the next several blocks.

Footnotes

  1. Timelocks and heightlocks based on a transaction’s nLockTime are a
    bit more complicated than described here due to an interaction
    with a transaction’s one or more nSequence fields. If all nSequence
    fields are set to their maximum value (0xffffffff), then the
    transaction can be included in any block. For details about the
    possible motivation for the interaction between nLockTime and
    nSequence (and signature hash flags), see an email with quotes attributed to Satoshi Nakamoto.

    Additionally, the BIP113 soft fork activated in July 2016 means
    nodes now compare timelock values to a block’s computed Median Time
    Past
    (MTP) rather than its explicit header time. 

—Source link—

What do you think?

How to open an unsecured loan with Teller Bankless

Set Protocol Automates UNI Yield Farming with USDAPY Set DeFi Rate