Bitcoin Optech Newsletter #118 Bitcoin Optech

This week’s newsletter describes a revised proposal for a generic
message signing protocol. Also included are our
regular sections describing releases, release candidates, and notable
changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

• ● Alternative to BIP322 generic signmessage: the existing BIP322
  proposes a generic message signing protocol for Bitcoin that would allow signing messages for any
  Bitcoin address (script) even if it used multisig or advanced
  features. This includes the ability to sign for all types of bech32
  addresses, a feature that has not yet been standardized even several years
  after the introduction of that type of address and its subsequent
  widespread adoption (see Newsletter #54).

  This week, BIP322 author Karl-Johan Alm posted to the Bitcoin-Dev mailing list an alternative proposal for message signing that would use a technique called virtual transactions. The first virtual transaction would be deliberately invalid by attempting to spend from a non-existent previous transaction (one whose txid is all zeroes). This first transaction pays the address (script) the user wants to sign for and contains a hash commitment to the desired message. A second transaction spends the output of the first transaction—if the signatures and other data for that spend could be a valid transaction, then the message is considered signed (although the second virtual transaction still can’t be included onchain because it spends from an invalid previous transaction).

  The advantage of using virtual transactions, which were also adopted in the BIP325 specification for signet (see Newsletter #109), is that they may work with existing software that’s configured to sign arbitrary transactions, including those in PSBT format. The revised specification also allows one of the virtual transactions to contain inputs that reference specific UTXOs, allowing users to (arguably) prove control over those funds, similar to BIP127 proof of reserves.

  Alm is seeking feedback on the alternative proposal, including whether or not it should replace BIP322 or be opened as a separate BIP.

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 is the release for a new minor
  version. Its release notes summarize the changes as “a number of
  reliability improvements, some macaroon [authentication token]
  upgrades, and a change to make our version of anchor
  commitments spec compliant.”

• ● HWI 1.2.0-rc.1 is a release candidate that adds support
  for a new hardware device and contains multiple bug fixes.

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 #19898 changes the “unexpected version” warnings in the debug
  log to be printed only when the validation log category is set, rather than
  unconditionally. Originally designed to alarm users that miners and users
  might be coordinating a soft fork activation using BIP9 versionbits, these
  frequent warnings had become spurious and were both unactionable and a
  source of unnecessary confusion for users. See Newsletter #36 for more information.

• ● Bitcoin Core #15367 adds a -startupnotify configuration parameter that accepts
  a shell command to be executed after Bitcoin Core has finished its
  initialization and is ready to handle enabled interfaces (ZMQ,
  REST, JSON-RPC, etc). This can be used to directly start programs/daemons
  dependent on Bitcoin Core’s interfaces, or to notify init systems (e.g.
  systemd) that dependent programs/daemons can be safely started.

• ● Bitcoin Core #19723 changes the way unknown P2P protocol messages
  are handled. Previously the node penalized peers who sent unknown
  messages at any time; now the node ignores unknown messages during the
  brief window between when the remote peer establishes a new connection
  by sending a version message and when the remote node acknowledges
  receipt of the local peer’s version with a verack message. Peers
  who send unknown messages at any other time will still be penalized.

  By ignoring messages before verack, the local node makes it safe for a peer to send special messages identifying any features it supports. If the node recognizes any special messages, it can enable its support for the corresponding features; otherwise, it can just ignore the message. See Newsletter #111 for previous discussion about this proposed method for protocol feature negotiation.

• ● Bitcoin Core #19725 updates the getpeerinfo RPC. Its results
  now return a new connection_type field that indicates the
  reason the node either opened that connection to an outbound peer or
  accepted an inbound connection from the peer. The existing addnode
  field in the RPC output is deprecated (not returned by default);
  connections manually requested by the user now show up as
  connection_type: manual.

• ● Bitcoin Core #18309 allows each ZeroMQ configuration parameter to
  be specified multiple times. If the same parameter is specified more
  than once, each listed IP address and port will receive notifications.
  Previously, only the first provided address/port would receive a
  notification.

• ● Bitcoin Core #19501 updates the sendtoaddress and sendmany
  RPCs with a new optional verbose parameter that returns what
  mechanism was used to select the transaction’s feerate—such as
  whether the user manually selected the feerate, an appropriate feerate
  was automatically selected, or the configured fallback feerate was used.

• ● Bitcoin Core #20003 results in the program immediately exiting
  if the -proxy configuration parameter is specified without
  arguments. Previously, the program would start without a proxy, which
  could lead to the user thinking they were using a proxy (e.g. for
  privacy) when they really weren’t.

• ● Bitcoin Core #19991 makes it possible to track incoming
  connections to a local Tor onion service separately from other
  connections made by services or proxies run on the same computer.
  This is done by having Bitcoin Core listen on an additional port
  (8334), only on localhost, and associate any connections to that port
  with Tor. The Tor listening port may be changed using the existing
  -bind configuration parameter and its new =tor flag. This PR
  doesn’t do anything special with the ability to identify which
  connections came from Tor (or those that are now more likely to have
  come from a local service), leaving that to future PRs. Tor onion
  service operators who upgrade to this new code may want to update their
  settings as described in the updated documentation.

• ● Eclair #1528 allows plugins (see Newsletter #43) to register new features and message types. The
  features will be advertised to peers and potential peers, and any
  messages using registered message types will be routed to the appropriate
  plugin. Plugins may now also send messages with arbitrary message types.

• ● Eclair #1539 implements a simple measure to try to prevent channel
  jamming attacks. When a node has two or more open channels to the
  same peer and it receives a payment to that peer,
  it now routes the payment by whichever channel has the least
  amount of remaining bitcoin value. This means attackers will end up
  jamming low-value channels before high-value channels. This doesn’t
  eliminate the attack, but it does mean an attacker will need more
  open channels in order to jam some high-value channels. This PR
  shared discussion with LND #4646, which implements the
  same feature in LND.

• ● Eclair #1540 adds a configuration parameter for setting the name
  of the Bitcoin Core wallet to use. If not set, Eclair will use
  Bitcoin Core’s default wallet. The configuration documentation warns that the wallet must not be changed while there are
  open channels.

• ● LND #4389 adds a new psbt wallet subcommand that allows users to
  create and sign PSBTs. This extends LND’s previous
  PSBT support that was focused on allowing other wallets to fund a
  channel open (see Newsletter #92). For details
  about the new psbt subcommand and examples of it in use, see LND’s
  updated documentation.

—Source link—