Bitcoin Optech Newsletter #113 Bitcoin Optech

This week’s newsletter describes a proposed change to the way LN commitment
transactions are constructed, summarizes discussion of a default signet, and
links to a proposal for standardizing temporarily trusted LN channels. Also
included are our regular sections with recently transcribed talks and
conversations, releases and release candidates, and notable changes to popular
Bitcoin infrastructure projects.

Action items

None this week.

News

• ● Witness asymmetric payment channels: Lloyd Fournier posted to
  the Lightning-Dev mailing list this week with a request for feedback
  on a proposed change to the way LN commitment transactions are
  created. Currently, in-channel payments are made by constructing two
  transactions that conflict with each other, meaning Bitcoin’s
  consensus rules will only allow one of the transactions to be included
  in the block chain. Each of these transactions includes the same two
  outputs with the same two amounts—one paying Alice and one paying
  Bob—but with slightly different scripts.

  

  The script for Alice allows her to unilaterally close the channel, but
  it gives Bob a chance to spend her funds if he knows a revocation key that
  Alice previously created. Similarly, if Bob unilaterally closes the
  channel, Alice gets a chance to spend his funds using a revocation key he
  created. Giving your counterparty a private key that allows them to spend
  your money makes it possible to effectively revoke that old channel
  state so that you’re strongly incentivized to publish the latest
  unrevoked channel state onchain when it comes time to close the
  channel.

  What Fournier proposed this week was only creating a single commitment
  transaction that would be shared between
  Alice and Bob. When creating the transaction, Alice creates two
  private keys she’ll need to spend her output and gives Bob the
  corresponding public keys. Bob then gives Alice a signature
  adaptor for his half of the 2-of-2 multisig spend in the commitment
  transaction; the adaptor can only be transformed into Bob’s signature
  if that signature will reveal one of Alice’s private keys to Bob. The
  other private key Alice created is the revocation private key, which
  she’ll give to Bob if she wants to revoke this channel state in favor
  of a later state. Similarly, Bob generates his own keys and receives
  a signature adaptor from Alice.

  

  In this way, even though the commitment transaction is the same for
  both parties, there will be a difference in the signatures (called
  witnesses) each of them uses to unilaterally close the channel.
  The difference in the signatures will give the party who didn’t close
  the channel a chance to create and broadcast a penalty transaction if
  the channel was closed in an old state. Otherwise, if the channel was
  closed in its latest state, both parties get their money, just like in
  the current LN.

  The proposal also suggests using basically the same scheme to
  transition from Hash Time Lock Contracts (HTLCs) to Point Time Lock
  Contracts (PTLCs), which is a goal several LN contributors
  have voiced support for in the past.

  Advantages of this approach are that it might require less private
  data storage (though this is debated), it makes unilateral closes
  a bit smaller onchain, and it describes a path to using PTLCs that
  will provide LN users with additional privacy against routing
  node surveillance as well as bring the protocol a little closer to what it may
  look like when it can take advantage of the benefits of schnorr
  signatures.

• ● Default signet discussion: Michael Folkson posted to the
  Bitcoin-Dev mailing list a question about whether there should be a
  default signet similar to Bitcoin’s existing default testnet.
  Signets are test networks where valid blocks must be
  signed by one or more trusted keys; this allows them to be more
  predictable for testing than fully decentralized test networks that
  are often subject to vandalism. BIP325 describes the signet
  protocol, which anyone can use to create their own signet, but there
  is a desire to include a default signet into
  Bitcoin Core (and possibly other software) that
  users will be able to enable with a single configuration option.
  Folkson’s first question was whether anyone has any objection to this.

  If there is to be a default signet, Folkson posted several additional questions about how it should be administered. For example, who should control its signing keys? How many keys should there be? Under what circumstances should the default signet be reset? When should proposed consensus changes to mainnet Bitcoin be implemented by the trusted signet block signers?

  Anyone interested in helping answer these questions is encouraged to respond.

• ● Standardizing temporarily trusted LN channels: Roei Erez
  posted to the Lightning-Dev mailing list a proposal to standardize
  the way LN implementations deal with new channels when the
  participants are willing to trust an unconfirmed deposit transaction.
  For example, Alice pays Bob’s established business to fund a
  channel to her. In that case, Alice may be willing to trust Bob to not
  double spend his deposit transaction. Bob can also safely accept
  in-channel payments from Alice because he gets all his money back
  anyway if the deposit transaction doesn’t confirm.

  Erez noted that several LN implementations already allow users to opt in to trusting certain unconfirmed channels but that the different implementations vary in some aspects, such as what short_channel_id to use until the deposit transaction confirms (this value usually identifies the location of the deposit transaction in the block chain, which doesn’t apply to unconfirmed transactions).

  Participants in the mailing list discussion seemed supportive of the proposal.

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.

• ● btcd 0.21.0-beta is now released. This is the first major release for
  btcd since 0.20.0-beta in October 2019, and contains numerous improvements
  and bug fixes.

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.

• ● nix-bitcoin: nixbitcoindev appeared on the Stephan Livera Podcast to
  discuss nix-bitcoin. nix-bitcoin is an experimental project
  that aims to improve the security of installing Bitcoin and Lightning nodes. It
  uses the NixOS functional Linux distribution, where upgrading is equivalent to
  installing from scratch due to atomicity. Through minimalism, reproducibility,
  and compartmentalization, nix-bitcoin aims to reduce the attack
  surface of a Bitcoin and Lightning software stack—ensuring programs are unaware of
  other running processes unless they need to be. (transcript, audio)

• ● Taproot activation: Eric Lombrozo, Luke Dashjr, and Aaron van Wirdum
  discussed the various taproot activation proposals (see
  Newsletter #107) and gave their opinions
  on what lessons, if any, could be derived from activating the
  segwit soft fork. Lombrozo and Dashjr both believe that the taproot activation
  process should not be drawn out and that all opposition, criticism, or review of
  the proposed code changes should be completed prior to starting an
  activation process. As a result, they support a single-phase BIP8 activation
  method with parameters still to be determined. Community feedback on activation
  proposals continues to be collected. (transcript,
  video)

• ● Signet: Kalle Alm and AJ Towns participated in a discussion on
  signet. The design decisions of signet were explored as well
  as the mechanics of how testnet and regtest work. For more details, see the
  Default signet discussion news item.
  (transcript, video)

• ● Bitcoin Core GUI meeting: Anonymized participants, including designers and
  developers, met to discuss the Bitcoin Core graphical user interface, its
  current state, how it could be improved, and the constraints that
  a revamp would be subject to. For example, one change that has been
  discussed in the past is moving from Qt Widgets to the Qt QML framework, which
  is more flexible and easily customized. (transcript).

• ● Sydney meetup discussion: Ruben Somsen and Rusty Russell participated in a
  discussion on statechains, upgrading LN channels, and lnprototest. Somsen
  outlined how statechains (see Newsletter #91) could
  potentially be used to swap out your Lightning channel counterparty or, in the
  case of DLCs (see Newsletter #81), swap out a portion of your
  position without closing the channel. With various proposed Lightning channel
  upgrades on the horizon, participants speculated about which upgrades could use dynamic commitments
  (see Newsletter #108) and which would require
  splicing. Finally, Russell explained how the Lightning
  protocol test suite lnprototest could be used to find bugs in existing
  implementations and assist with ensuring interoperability across
  implementations when building out new features. (transcript).

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 #19797 strays from Satoshi’s original vision™ by
  removing an obsolete validity check for IPv6 addresses constructed by
  Bitcoin (Core) 0.2.8 and earlier. Those early nodes had a bug that
  would produce malformed addresses.
  This change should have no impact on the current P2P network, as
  affected versions are unable to communicate with current software due
  to the introduction of checksums for P2P messages in Bitcoin
  (Core) 0.2.9, which were later made mandatory.

• ● Bitcoin Core #19731 extends the getpeerinfo RPC output with two new
  fields: last_block and last_transaction. last_block is the time that
  the peer sent the local node a block which the node had not seen
  before and which passed preliminary validity checks. last_transaction is the
  last time that the peer sent the local node a transaction that the node
  accepted to its mempool. Both of these metrics are used when choosing peers
  to disconnect, so it’s useful for node operators to be able to access
  the values.

• ● LND #4527 adds a new default-remote-max-htlcs configuration
  option that allows the user to specify the default maximum number of
  unresolved HTLCs (payments) allowed in a channel. This can minimize
  the amount of onchain fees the user will have to pay if they need to
  unilaterally close their channel, such as because of a fee ransom attack
  (see Newsletter #103).

• ● BIPs #982 adds changes to BIP340 schnorr signatures (which
  also affect BIP341 taproot). BIP340 was previously
  changed to use two different tiebreakers for
  conveying the Y coordinate of points: squaredness for the R point
  inside signatures and evenness for the public keys. As described on
  the mailing list (see Newsletter
  #111), this update
  changes the R point to use evenness, since the performance gains of using
  squaredness were not observed in practice, and having consistent
  tiebreakers reduces complexity. Other changes included small fixups,
  clarifications, and typo corrections.

  Similar to previous revisions, the tag for the
  tagged hashes in BIP340 was changed, ensuring that any code written for
  the earlier drafts will generate signatures that fail validation under
  the proposed revisions.

—Source link—