This week’s newsletter asks for comments on the miniscript
language, publishes our final bech32 sending support section, includes popular
Q&A from the Bitcoin StackExchange, and describes several notable changes to
popular Bitcoin infrastructure projects.
Evaluate miniscript: wallet developers are encouraged to evaluate
this proposed language that can allow wallets to
adapt to new script templates without requiring changes to the
underlying wallet code for each new template. See the news section
Miniscript request for comments: the developers of this language
have requested community feedback on their initial
design. Miniscript allows software to automatically analyze a
script, including determining what data is necessary to create a
witness that fulfills the script and allows any bitcoins protected by
the script to be spent. With miniscript telling the wallet what it
needs to do, wallet developers don’t need to write new code when they
switch from one script template to another.
For example, a wallet developer today who wants to switch from 2-of-3
multisig to 2-of-2 multisig with a 1-of-2 timelocked escape clause
might have to write and test a new function for the new case. With
miniscript, as long as the wallet knows how to produce signatures for
specified keys and how to resolve a timelock, miniscript can guide the
wallet through the various possible paths in an attempt to solve the
script. No new spending code would be required.
For scripts that need signatures or other data from multiple wallets,
miniscript can guide the wallet into creating all the witness data it
can so that the data can be bundled into a Partially Signed Bitcoin
Transaction (PSBT). Other wallets can create their own PSBTs, all of
which are given to a PSBT finalizer. If the finalizer is miniscript
aware, it can sort the witness data from all the provided PSBTs into a
single complete witness, making the spending transaction valid.
This automation for the large range of scripts supported by miniscript
allows wallets to be much more dynamic about the scripts they use,
possibly even allowing users to specify their own scripts. In support
of that dynamism, miniscripts can be created using an easily-written
policy language. Policies are composable, allowing any valid
sub-expression to be replaced by another valid sub-expression (within
certain limits imposed by the Bitcoin system). For example, imagine
Alice has a 2-of-3 policy that involves a hot wallet, a hardware
wallet, and a fallback cold wallet:
thresh(2, pk(A_hot), pk(A_hard), pk(A_cold))
Later Alice is asked to create a fidelity bond that timelocks some of
her bitcoins for a period of 26,000 blocks. The generic form of that
Alice can simply replace pk(KEY) with her particular policy:
The miniscript compiler can convert the policy into an efficient P2WSH
script and check that it doesn’t violate any of Bitcoin’s consensus
rules or Bitcoin Core’s transaction relay and mining policy. It can
also tell Alice the various sizes related to the script so she can
estimate her transaction fee expenses.
If script changes are added to the Bitcoin protocol, such as
taproot, a new version of miniscript will likely be
created that supports the protocol additions, making the upgrade easy
for both wallets and users even if they use complex scripts.
The last of 24 in a series about allowing the people
you pay to access all of segwit’s benefits.
After six months and over 10,000 words published, this is our last
bech32 sending support section. Our goal was to gently persuade as many
developers as possible to add support for paying bech32 addresses in
their applications. We hoped that would make it easier for segwit-ready
wallets to switch from using P2SH-wrapped segwit addresses by default to
more efficient native segwit bech32 addresses.
By our efforts and by the efforts of many other Bitcoiners, we think
we’re on the brink of success: 19 of the 23 popular
wallets and services we’ve evaluated are ready to pay
bech32 addresses and 4 already
generate bech32 receiving addresses by default.
Every week, it’s looking more and more reasonable for wallets to switch
to bech32 soon, and we expect to hear from an increasing number of
developers that their next major release will default to bech32
receiving addresses. This will lower the transaction fees for the users
of that software and make more block space available to all Bitcoin
users, helping to keep fees lower for everyone a little bit longer.
Even though this series has ended, we’ll continue to update the segwit
section of the compatibility matrix and report on notable bech32
developments in the other parts of the weekly newsletter. We thank all
of you for reading this series and for helping to improve Bitcoin
scalability one wallet and service at a time.
Selected Q&A from Bitcoin StackExchange
Bitcoin StackExchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments of time to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers made since our last update.
What are the key differences between regtest and the proposed
signet? Pieter Wuille and Andrew Chow explain that while
regtest is good for local automated integration tests, signet is more akin to
testnet in that it allows testing of things like peer finding, propagation,
and transaction selection. Signet allows for more control over block
production timing than testnet and more than one signet can exist for testing
Can hardware wallets actually display the amount of funds leaving your
control? Andrew Chow explains that since a hardware wallet is
not a full node, it needs to get its transaction amount information elsewhere.
In the case of non-segwit inputs, often the amount is provided to the hardware
signing device via the host computer or other wallet by sending the previous
transaction to the device. In the case of segwit inputs, the amount for the
input being signed must always be provided because it is a required part of
the data that is signed and verified.
Why is proof-of-work required in Bitcoin? Pieter Wuille
explains that PoW does not create trust, but instead creates incentive for
miners to cooperate with other miners by building on their blocks. PoW is also
used to regulate block times (and thus protect against denial of service)
since the difficulty adjustment makes it expensive to reliably produce blocks
more often than every 10 minutes on average.
LND #2203 adds a rejecthtlc configuration option that will
prevent the node from forwarding payments for other nodes but will
still allow it to accept incoming payments and send outgoing payments.
LND #3256 increases the number of inferences LND draws from
routing failures and uses that information to adjust subsequent
routes. For example, nodes are now penalized in the routing
preference database if they produce an error message that they
shouldn’t be generating given their particular role in a transaction
(e.g. intermediate node or final node).
BOLTs #608 provides a privacy update to BOLT4 that makes it
harder for a routing node to identify which node is ultimately
receiving a payment. Previously, the final node would send a
final_expiry_too_soon error if it received a payment due to expire
too soon in the future. Other non-final nodes would simply report
that they didn’t recognize the payment. This made it possible to
probe various channels to determine the recipient. The updated BOLT
now recommends final nodes send a generic
incorrect_or_unknown_payment_details message even when they know the
problem is a too-soon expiry. This is the same basic privacy leak and
solution described for the wrong-amount problem in last
We thank Pieter Wuille and Sanket Kanjalkar for reviewing drafts of this
newsletter and helping us understand the full range of miniscript’s
capabilities. Any remaining errors are the fault of the newsletter