This week’s newsletter describes the new Minsc policy language and contains 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

  • ● New spending policy language: Nadav Ivgi announced a new language he’s developed named Minsc which makes it easier for developers to specify a set of conditions that must be fulfilled in order for a UTXO to be spent. The new language is based on the miniscript policy language but adds the ability to use variables and functions along with several other features. Minsc policies can be compiled to miniscript policies, which can be themselves be compiled into miniscript and used to produce regular Bitcoin Script. Compatibility with miniscript means that policies developed using Minsc will be solvable using any miniscript-aware wallet in the future, allowing wallets to contribute signatures, preimages, or other data needed to spend bitcoins without their developers having to manually specify how to handle each specific script template the wallet supports. This should allow faster upgrades to new language features and greatly simplify development of interoperable wallets for coinjoins, contract protocols, shared coin ownership, and other types of desirable collaborations.

    Ivgi has also created an outstanding website for the language. It includes both a plethora of examples and a live compiler that allows linking to its input so that developers can easily play with the language and share their Minsc policies with other developers. We recommend anyone interested in developing spending policies visit the website, but as an illustration of what Minsc can do, we offer the following example adapted from Ivgi’s own examples. Several years ago, before miniscript or Minsc, LN developers hand crafted the following HTLC script specified in BOLT3:

    # To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

    The same encumbrance can be specified using the following Minsc policy (setting the cltv_expiry to 3 hours):

    fn htlc_received($revocationpubkey, $local_htlcpubkey,
                 $remote_htlcpubkey, $payment_hash,
                 $cltv_expiry)
{
  // To local node via HTLC-success transaction
  $success = pk($local_htlcpubkey) && hash160($payment_hash);

  // To remote node after timeout
  $timeout = older($cltv_expiry);

  // To remote node with revocation key, or use success/timeout
  pk($revocationpubkey) || (pk($remote_htlcpubkey) && ($success || $timeout))
}

htlc_received(A, B, C, H, 3 hours)

    The Minsc policy is significantly easier for most developers to analyze and it’s able to take advantage of miniscript to transform the policy into a moderately smaller script than the original hand-crafted script.

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.

  • ● RaspiBlitz full node: Rootzoll and Openoms appeared on Potzblitz to present the RaspiBlitz, a Bitcoin and Lightning Network full node built on a Raspberry Pi (but also compatible with other hardware). Openoms explored some of the apps and services you can install on your RaspiBlitz such as ThunderHub and Balance of Satoshis. Rootzoll explained how the IP2TOR subscription service addresses the challenge of connecting a mobile wallet to a RaspiBlitz full node running on a home network. (transcript, video, slides)

  • ● Chicago meetup discussion: Anonymized participants discussed various Lightning Network attacks including flood and loot, fee blackmail, transaction pinning, preimage denial (see Newsletter #95) and time dilation (see Newsletter #101). In light of these various attacks of varying severities it was debated what current users should do to protect themselves on the Lightning Network and longer term what sufficient mitigations would be. Some solutions such as package relay, anchor outputs and rearchitecting the Bitcoin Core mempool are being worked on—but more work will be required at both the onchain layer and the Lightning layer in the coming months and years. (transcript)

  • ● Sapio: Jeremy Rubin presented Sapio at Reckless VR in virtual reality. Sapio is a new high level programming language designed for building stateful smart contracts with OP_CHECKTEMPLATEVERIFY. Rubin used the case study of the recent timelock issue with Blockstream’s Liquid sidechain to explain how Sapio and OP_CHECKTEMPLATEVERIFY could theoretically have been utilized to prevent funds unintentionally moving to the 2-of-3 multisig emergency backup. (transcript, video, slides)

  • ● Sydney meetup discussion: Anonymized participants discussed resolved bugs in the Bitcoin Core build system over the past months and the future challenges of building and distributing Bitcoin Core binaries on MacOS in light of notarization requirements and Apple transitioning from Intel to ARM processors. Other topics included updates to the SIGHASH_ANYPREVOUT proposal, generalized Bitcoin-compatible channels, and the latest thinking on taproot activation. (transcript)

  • ● BIP-Taproot: Pieter Wuille and Russell O’Connor participated in a joint event organized by London BitDevs and Bitcoin Munich exploring the history of how the original idea of MAST evolved into the final taproot proposal. Wuille talked about how his personal motivation switched from seeking to enable cross input signature aggregation to bolstering the privacy and efficiency of more complex transactions. O’Connor also gave an update on development of the Simplicity language (see Newsletter #96). He speculated how Simplicity could be implemented as a Tapleaf version in the coming years and used for delegation, covenants, and other functionality not currently available using Bitcoin Script. The PR for schnorr signatures in libsecp256k1 and the taproot PR in Bitcoin Core are seeking further review and O’Connor encouraged the community to consider what taproot might break in their own software well in advance of any possible deployment. (transcript, video)

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.

  • ● C-Lightning 0.9.0 is the newest major version of C-Lightning. It adds support for the updated pay command and new keysend RPC, both described in Newsletter #107. It also includes several other notable changes and multiple bug fixes.

  • ● Bitcoin Core 0.20.1 is a new maintenance release. In addition to bug fixes and some RPC behavior changes resulting from those fixes, the planned release provides compatibility with recent versions of HWI and its support for hardware wallet firmware released for the fee overpayment attack.

  • ● LND 0.11.0-beta.rc1 is the first release candidate for a new major release.

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 #19569 allows Bitcoin Core to fetch the parents of orphan transactions from peers that relay transactions using wtxid. An orphan transaction is an unconfirmed transaction that we receive from a peer where we don’t yet have the parent transactions, either as part of our best block chain, or in the mempool. More precisely, an orphan transaction has at least one transaction input whose associated output is not in the UTXO set or our mempool’s outpoint map.

    When we receive an orphan transaction, we place it in a temporary data structure called the orphan set. We then ask the peer that sent us the orphan to also send us the parent transactions that we don’t yet have. We can do that because the orphan transaction contains the txids of its parent transactions. We simply send a getdata message containing those txids to the peer to request the parent transactions.

    For wtxid relay peers, transactions are announced and requested using the wtxid of the transaction, not the txid. However, orphan transactions contain their parents’ txids, not wtxids, so it’s not possible to request the parent transaction using wtxid. PR #18044, which introduced wtxid relay peers and was merged last week, did not permit fetching parent transactions from wtxid peers. This follow-up PR allows us to fetch those parents using the txid.

    Fetching parent transactions using txid may eventually be replaced by a package relay mechanism, where we can ask a peer for all the unconfirmed ancestors of a transaction directly.

  • ● Eclair #1491 adds partial support for creating, using, and closing channels that use anchor outputs to both reduce onchain transaction fees in normal cases and increase fees when necessary for security. This implementation handles all the basics but does not yet support mutual channel closes or actual fee bumping; those will be added later. Additionally, interoperability testing with LND’s implementation revealed a case where the specification should be clarified.

  • ● LND #4488 updates the minimum CLTV expiry delta users may set to 18 blocks in line with an updated recommendation. The default remains at 40 blocks. When there are only this many blocks until an LN payment has to be settled, LND will unilaterally close the channel to ensure the latest state gets recorded onchain. However, the higher the expiry is, the more time a payment could become temporarily stuck in a channel (either by accident or deliberately). This has led some LN implementations to use route-finding algorithms that optimize for routes with low CLTV expiry deltas, which has in turn led some users to set their deltas to values that are especially unsafe. This new minimum should help prevent inexperienced users from naively setting an unsafe value.

  • ● BIPs #948 updates the BIP174 specification of PSBT input records to explicitly allow for providing both a non-witness UTXO (the full transaction) and a witness UTXO for a single input. This is in line with the current behavior in Bitcoin Core and was motivated by the possibility of a fee overpayment attack on multi-input segwit PSBTs which did not include the non-witness UTXOs as detailed in a previous newsletter.

  • ● BIPs #947 updates the BIP325 specification of signet to change the block signature verification method. Signets are test networks where valid blocks are signed by trusted signers, a change which eliminates some issues and makes certain types of testing easier.

    Previously, signet assumed the use of signatures compatible with legacy Bitcoin Script (e.g. DER-encoded ECDSA signatures). After this change, signet instead uses a pair of virtual transactions—transactions that aren’t valid on the block chain and aren’t included inside the block but which can easily be constructed by Bitcoin software (directly or using a PSBT). The first transaction commits to paying the network’s trusted signer script. A second virtual transaction then spends the output of the first virtual transaction. The signature or signatures from the second virtual transaction are included in the coinbase transaction of the block to prove the block is validly signed.

    The main advantage of this new approach is that it allows using segwit transactions. The opcodes available in current segwit v0 are almost all identical to legacy script, so this may seem irrelevant—but if segwit v1 (taproot) is made available on a signet, this will allow signing blocks with schnorr signatures. As future protocol changes will probably also use segwit, this will allow those features to be used as well. A secondary advantage is that any software or hardware that can sign PSBTs for arbitrary inputs will now be able to operate as a trusted signer for a signet.