Skip to content

Commit f31d4eb

Browse files
hardingbitschmidty
harding
authored and
bitschmidty
committed
Newsletters: add 61 (2019-08-28)
1 parent 04fe49c commit f31d4eb

File tree

4 files changed

+181
-1
lines changed

4 files changed

+181
-1
lines changed

‎_includes/references.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@
3131
[libsecp256k1 repo]: https://github.com/bitcoin-core/secp256k1
3232
[lnd repo]: https://github.com/lightningnetwork/lnd/
3333
{% comment %}<!-- TODO: switch miniscript link to some sort of overview page when available -->{% endcomment %}
34-
[miniscript]: http://bitcoin.sipa.be/miniscript/miniscript.html
34+
[miniscript]: http://bitcoin.sipa.be/miniscript/
3535
[musig]: https://eprint.iacr.org/2018/068
3636
{% assign _link_descriptors = 'https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md' %}
3737
[output script descriptor]: {{_link_descriptors}}

‎_includes/specials/bech32/24-conclusion.md

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
After six months and over 10,000 words published, this is our last
2+
bech32 sending support section. Our goal was to gently persuade as many
3+
developers as possible to add support for paying bech32 addresses in
4+
their applications. We hoped that would make it easier for segwit-ready
5+
wallets to switch from using P2SH-wrapped segwit addresses by default to
6+
more efficient native segwit bech32 addresses.
7+
8+
By our efforts and by the efforts of many other Bitcoiners, we think
9+
we're on the brink of success: 19 of the 23 popular
10+
wallets and services we've [evaluated][bech32 compat] are ready to pay
11+
bech32 addresses and 4 already
12+
generate bech32 receiving addresses by default.
13+
14+
Every week, it's looking more and more reasonable for wallets to switch
15+
to bech32 soon, and we expect to hear from an increasing number of
16+
developers that their next major release will default to bech32
17+
receiving addresses. This will lower the transaction fees for the users
18+
of that software and make more block space available to all Bitcoin
19+
users, helping to keep fees lower for everyone a little bit longer.
20+
21+
Even though this series has ended, we'll continue to update the segwit
22+
section of the [compatibility matrix][] and report on notable bech32
23+
developments in the other parts of the weekly newsletter. We thank all
24+
of you for reading this series and for helping to improve Bitcoin
25+
scalability one wallet and service at a time.
26+
27+
[bech32 compat]: /en/bech32-sending-support/#insights-from-segwit-compatibility-matrix

‎_posts/en/2019-03-19-bech32-sending-support.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -165,5 +165,11 @@ on bech32 sending support, from March 19th to August 28th, 2019.
165165

166166
{% include specials/bech32/23-compat.md %}
167167

168+
## Conclusion
169+
170+
*Originally published in [Newsletter #61][].*
171+
172+
{% include specials/bech32/24-conclusion.md %}
173+
168174
## Footnotes
169175
{:.no_toc}

‎_posts/en/newsletters/2019-08-28-newsletter.md

Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #61'
3+
permalink: /en/newsletters/2019/08/28/
4+
name: 2019-08-28-newsletter
5+
slug: 2019-08-28-newsletter
6+
type: newsletter
7+
layout: newsletter
8+
lang: en
9+
---
10+
This week's newsletter asks for comments on the miniscript
11+
language, publishes our final bech32 sending support section, includes popular
12+
Q&A from the Bitcoin StackExchange, and describes several notable changes to
13+
popular Bitcoin infrastructure projects.
14+
15+
{% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %}
16+
{% include references.md %}
17+
18+
## Action items
19+
20+
- **Evaluate miniscript:** wallet developers are encouraged to evaluate
21+
this [proposed language][miniscript code] that can allow wallets to
22+
adapt to new script templates without requiring changes to the
23+
underlying wallet code for each new template. See the *news* section
24+
for details.
25+
26+
## News
27+
28+
- **Miniscript request for comments:** the developers of this language
29+
have [requested][miniscript email] community feedback on their initial
30+
design. [Miniscript][] allows software to automatically analyze a
31+
script, including determining what data is necessary to create a
32+
witness that fulfills the script and allows any bitcoins protected by
33+
the script to be spent. With miniscript telling the wallet what it
34+
needs to do, wallet developers don't need to write new code when they
35+
switch from one script template to another.
36+
37+
For example, a wallet developer today who wants to switch from 2-of-3
38+
multisig to 2-of-2 multisig with a 1-of-2 timelocked escape clause
39+
might have to write and test a new function for the new case. With
40+
miniscript, as long as the wallet knows how to produce signatures for
41+
specified keys and how to resolve a timelock, miniscript can guide the
42+
wallet through the various possible paths in an attempt to solve the
43+
script. No new spending code would be required.
44+
45+
For scripts that need signatures or other data from multiple wallets,
46+
miniscript can guide the wallet into creating all the witness data it
47+
can so that the data can be bundled into a Partially-Signed Bitcoin
48+
Transaction (PSBT). Other wallets can create their own PSBTs, all of
49+
which are given to a PSBT finalizer. If the finalizer is miniscript
50+
aware, it can sort the witness data from all the provided PSBTs into a
51+
single complete witness, making the spending transaction valid.
52+
53+
This automation for the large range of scripts supported by miniscript
54+
allows wallets to be much more dynamic about the scripts they use,
55+
possibly even allowing users to specify their own scripts. In support
56+
of that dynamism, miniscripts can be created using an easily-written
57+
policy language. Policies are composable, allowing any valid
58+
sub-expression to be replaced by another valid sub-expression (within
59+
certain limits imposed by the Bitcoin system). For example, imagine
60+
Alice has a 2-of-3 policy that involves a hot wallet, a hardware
61+
wallet, and a fallback cold wallet:
62+
63+
thresh(2, pk(A_hot), pk(A_hard), pk(A_cold))
64+
65+
Later Alice is asked to create a fidelity bond that timelocks some of
66+
her bitcoins for a period of 26,000 blocks. The generic form of that
67+
policy is:
68+
69+
and(pk(KEY), older(26000))
70+
71+
Alice can simply replace `pk(KEY)` with her particular policy:
72+
73+
and(thresh(2, pk(A_hot), pk(A_hard), pk(A_cold)), older(26000))
74+
75+
The miniscript compiler can convert the policy into an efficient P2WSH
76+
script and check that it doesn't violate any of Bitcoin's consensus
77+
rules or Bitcoin Core's transaction relay and mining policy. It can
78+
also tell Alice the various sizes related to the script so she can
79+
estimate her transaction fee expenses.
80+
81+
If script changes are added to the Bitcoin protocol, such as
82+
[taproot][bip-taproot], a new version of miniscript will likely be
83+
created that supports the protocol additions, making the upgrade easy
84+
for both wallets and users even if they use complex scripts.
85+
86+
For more information, see the [miniscript website][miniscript], [C++
87+
miniscript implementation][miniscript code], [Rust
88+
implementation][miniscript rust], code for a [Bitcoin Core
89+
integration][core miniscript], and Pieter Wuille's talk about an
90+
earlier version of miniscript ([video][miniscript vid],
91+
[transcript][miniscript xs], [Optech summary][miniscript summary]).
92+
93+
## Bech32 sending support
94+
95+
*The last of 24 in a [series][bech32 series] about allowing the people
96+
you pay to access all of segwit's benefits.*
97+
98+
{% include specials/bech32/24-conclusion.md %}
99+
100+
## Notable code and documentation changes
101+
102+
*Notable changes this week in [Bitcoin Core][bitcoin core repo],
103+
[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo],
104+
[libsecp256k1][libsecp256k1 repo], [Bitcoin Improvement Proposals
105+
(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].*
106+
107+
- [LND #2203][] adds a `rejecthtlc` configuration option that will
108+
prevent the node from forwarding payments for other nodes but will
109+
still allow it to accept incoming payments and send outgoing payments.
110+
111+
- [LND #3256][] increases the number of inferences LND draws from
112+
routing failures and uses that information to adjust subsequent
113+
routes. For example, nodes are now penalized in the routing
114+
preference database if they produce an error message that they
115+
shouldn't be generating given their particular role in a transaction
116+
(e.g. intermediate node or final node).
117+
118+
- [BOLTs #608][] provides a privacy update to [BOLT4][] that makes it
119+
harder for a routing node to identify which node is ultimately
120+
receiving a payment. Previously, the final node would send a
121+
`final_expiry_too_soon` error if it received a payment due to expire
122+
too soon in the future. Other non-final nodes would simply report
123+
that they didn't recognize the payment. This made it possible to
124+
probe various channels to determine the recipient. The updated BOLT
125+
now recommends final nodes send a generic
126+
`incorrect_or_unknown_payment_details` message even when they know the
127+
problem is a too-soon expiry. This is the same basic privacy leak and
128+
solution described for the wrong-amount problem in [last
129+
week's newsletter][lnd3391].
130+
131+
## Special thanks
132+
133+
We thank Pieter Wuille and Sanket Kanjalkar for reviewing drafts of this
134+
newsletter and helping us understand the full range of miniscript's
135+
capabilities. Any remaining errors are the fault of the newsletter
136+
author.
137+
138+
{% include linkers/issues.md issues="16647,3256,608,2203" %}
139+
[bech32 series]: /en/bech32-sending-support/
140+
[lnd3391]: /en/newsletters/2019/08/21#lnd-3391
141+
[miniscript code]: https://github.com/sipa/miniscript
142+
[miniscript email]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017270.html
143+
[core miniscript]: https://github.com/sipa/miniscript/tree/master/bitcoin/script
144+
[miniscript rust]: https://github.com/apoelstra/rust-miniscript
145+
[miniscript vid]: https://www.youtube.com/watch?v=XM1lzN4Zfks
146+
[miniscript xs]: http://diyhpl.us/wiki/transcripts/stanford-blockchain-conference/2019/miniscript/
147+
[miniscript summary]: /en/newsletters/2019/02/05#miniscript

0 commit comments

Comments
 (0)