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 updatedpay
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
rather than using proof of work, 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.