News180: add ToC and Conclusion

Author: harding

_posts/en/newsletters/2021-12-22-newsletter.md

@@ -19,7 +19,44 @@ summary], [2019][2019 summary], and [2020][2020 summary].
 
 * January
   * [Signet in Bitcoin Core](#signet)
-* FIXME:fill out table of contents
+  * [Bech32m addresses](#bech32m)
+  * [Onion messages and offers protocol](#offers)
+* February
+  * [Faster signature creation and verification](#safegcd)
+  * [Channel jamming attacks](#jamming)
+* March
+  * [Quantum computing risks](#quantum)
+* April
+  * [LN atomic multipath payments](#amp)
+* May
+  * [BIP125 opt-in replace-by-fee discrepancy](#bip125)
+  * [Dual funded channels](#dual-funding)
+* June
+  * [Candidate set based block construction](#csb)
+  * [Default transaction replacement by fee](#default-rbf)
+  * [Mempool package acceptance and package relay](#mpa)
+  * [LN fast forwards for speed and offline receiving](#ff)
+* July
+  * [LN liquidity advertisements](#liq-ads)
+  * [Output script descriptors](#descriptors)
+  * [Zero-conf channel opens](#zeroconfchan)
+  * [SIGHASH_ANYPREVOUT](#anyprevout)
+* August
+  * [Fidelity bonds](#fibonds)
+  * [LN pathfinding](#pathfinding)
+* September
+  * [OP_TAPLEAF_UPDATE_VERIFY](#tluv)
+* October
+  * [Transaction heritage identifiers](#txhids)
+  * [PTLCs and LN fast forwards](#ptlcsx)
+* November
+  * [LN developer summit](#lnsummit)
+* December
+  * [Advanced fee bumping](#bumping)
+* Featured summaries
+  * [Taproot](#taproot)
+  * [Major releases of popular infrastructure projects](#releases)
+  * [Bitcoin Optech](#optech)
 
 ## January
 
@@ -38,13 +75,15 @@ real money is at stake.  Also [discussed][signet reorgs] this year was
 adding deliberate block chain reorganizations to Bitcoin Core's default signet network to help
 developers test their software against that class of problems.
 
+{:#bech32m}
 A draft BIP for [bech32m][topic bech32] was also [announced][bech32 bip]
 in January.  Bech32m addresses are a slight modification of bech32
 addresses that make them safe for use with [taproot][topic taproot] and
 future protocol extensions.  Later in the year, a [Bitcoin Wiki
 page][bech32m page] was updated to track adoption of bech32m addresses
 by wallets and services.
 
+{:#offers}
 Another [first release][cl 0.9.3] of a new protocol was [onion
 messages][topic onion messages] and the [offers protocol][topic offers].
 Onion messages allow an LN node to send a message to another node in a
@@ -56,10 +95,9 @@ continue as draft specifications for the remainder of the year, but they
 would receive additional development, including a proposal to use them
 to [reduce the impact of stuck payments][offers stuck].
 
-<!-- TODO:EXTRA: /en/newsletters/2021/01/06/#trampoline-routing -->
-
 ## February
 
+{:#safegcd}
 Contributors to Bitcoin [advanced][safegcd blog] the state of research
 into an improved signature creation and verification algorithm, and then
 used their research to produce a variation with additional improvements.
@@ -72,6 +110,7 @@ sound and safe to use.  The change also provides a significant boost to
 the speed of securely creating signatures on low-powered hardware
 signing devices.
 
+{:#jamming}
 [Channel jamming attacks][topic channel jamming attacks], a known
 problem for LN since 2015, received continued discussion throughout the
 year, with a [variety][jam1] of [possible][jam2] solutions
@@ -81,10 +120,9 @@ and the problem remained unmitigated by year's end.
 {:.center}
 ![Illustration of jamming attacks](/img/posts/2020-12-ln-jamming-attacks.png)
 
-<!-- TODO:EXTRA /en/newsletters/2021/02/17/#anti-exfiltration -->
-
 ## March
 
+{:#quantum}
 Significant [discussion][quant] in March was devoted to analyzing the
 risk of quantum computer attacks on Bitcoin, particularly for the case
 where taproot activated and became widely used.  One of Bitcoin's
@@ -157,8 +195,6 @@ addresses.
   [compromise][bcc#21377] that allowed a Bitcoin Core [version][bcctap]
   to be released with an activation mechanism and parameters.
 
-<!-- TODO:EXTRA: BIPs drama? -->
-
 - **May<!--taproot-->** was when miners were [able][signal
   able] to [begin][signal began] signalling their readiness to enforce taproot and a website for
   tracking signaling progress became [popular][taproot.watch].
@@ -224,6 +260,7 @@ making use of its many features.
 
 ## April
 
+{:#amp}
 LND added [support][lnd#5709] in April for making Atomic Multipath
 Payments ([AMP][topic amp]), also called original AMPs due to being described earlier
 than the [Simplified Multipath Payments][topic multipath payments]
@@ -237,13 +274,15 @@ consideration the one significant downside of AMPs.
 
 ## May
 
+{:#bip125}
 A discrepancy between the specification of [BIP125][] transaction
 [replacement][topic rbf] and the implementation in Bitcoin Core was
 [disclosed][bip125 discrep] in May.  This didn't put any bitcoins at
 risk, as far as we know, but it did spawn several discussions about the
 risks to users of contract protocols (such as LN) from unexpected transaction relay
 behavior.
 
+{:#dual-funding}
 Also in May, the C-Lightning project [merged][cl#4489] a plugin for
 managing [dual-funded channels][topic dual funding]---channels where
 both parties can provide some amount of the initial funding.  In
@@ -322,13 +361,15 @@ use of LN is receiving payments instead of sending them.
 
 ## June
 
+{:#csb}
 A new [analysis][csb] discussed in June described an alternative way for
 miners to select which transactions they want to include in the blocks
 they create.  The new method is predicted to slightly increase miner
 revenue in the short term.  In the long-term, if the technique is
 adopted by miners, wallets aware of it will be able to collaborate when [CPFP fee bumping][topic cpfp]
 transactions, increasing the effectiveness of that technique.
 
+{:#default-rbf}
 Another attempt to make fee bumping more effective was a [proposal][rbf
 default] to allow any unconfirmed transaction to be [replaced by
 fee][topic rbf] (RBF) in Bitcoin Core---not just those that opt-in to
@@ -343,6 +384,7 @@ does need to use BIP68 to blend in with more common transactions.
 Neither proposal seemed to make much progress despite few significant
 objections.
 
+{:#mpa}
 June also saw the merge of the [first PR][bcc#20833] in a
 series implemeting [mempool package acceptance][mpa ml]
 in Bitcoin Core, the first step towards package relay.  [Package
@@ -360,6 +402,7 @@ makes [CPFP fee bumping][topic cpfp] unreliable for contract protocols
 using presigned transactions, such as LN.  Package relay hopes to solve
 this key safety issue.
 
+{:#ff}
 An idea originally proposed in 2019 for LN saw renewed life in June.  The
 original [fast forwards][ff orig] idea described how an LN wallet could receive
 or relay a payment with fewer network round-trips, reducing network
@@ -370,6 +413,7 @@ easier to keep that signing key secured.
 
 ## July
 
+{:#liq-ads}
 After years of discussion and development, the first implementation of a
 decentralized liquidity advertisements system was [merged][cl#4639] into
 an LN implementation.  The still-draft [liquidity ads][bolts #878]
@@ -386,8 +430,7 @@ the agreed upon lease period has concluded.  That means refusing to
 route payments would provide no advantages but would deny the
 advertising node the opportunity to earn routing fees.
 
-<!-- TODO:EXTRA:table comparing liquidity ads and Pool -->
-
+{:#descriptors}
 Three years after [first being proposed][descriptor gist] for Bitcoin
 Core, [draft BIPs][descriptor bips1] were [created][descriptor bips2] for
 [output script descriptors][topic descriptors].  Descriptors are strings
@@ -401,6 +444,7 @@ the wallet to determine which keys it controls in a multisig script.  By
 the end of the year, Bitcoin Core had made descriptor-based wallets its
 [default][descriptor default] for newly-created wallets.
 
+{:#zeroconfchan}
 A common way of opening LN channels that had never before been
 part of the LN protocol began to be [specified][0conf channels] in July.  Zero-conf
 channel opens, also called *turbo channels*, are new single-funded
@@ -420,6 +464,7 @@ who offer this service.
 {:.center}
 ![Zero-conf channel illustration](/img/posts/2021-07-zeroconf-channels.png)
 
+{:#anyprevout}
 Two related proposals for new signature hash (sighash) types were
 [combined][sighash combo] into [BIP118][].  `SIGHASH_NOINPUT`, proposed
 in 2017 and partly based on previous proposals going back a decade, was
@@ -431,15 +476,9 @@ storage requirements and complexity.  For multiparty protocols, the
 benefits may be even more significant by eliminating the number of
 different states that need to be generated in the first place.
 
-<!--
-TODO:EXTRA LN migration to real databases:
-  /en/newsletters/2021/07/14/#lnd-5447
-  /en/newsletters/2021/07/21/#eclair-1871
-  /en/newsletters/2021/10/06/#lnd-5366
--->
-
 ## August
 
+{:#fibonds}
 Fidelity bonds is an idea [described][wiki contract] at least as early as
 2010 for locking up bitcoins for a period of time in order to create a
 cost for misbehavior in third-party systems.  Because the bitcoins can't be used again until
@@ -450,6 +489,7 @@ the first large scale and decentralized use of fidelity bonds.  Within
 days of release, over 50 BTC had been timelocked (worth over $2 million
 USD at the time).
 
+{:#pathfinding}
 A new variation of pathfinding for LN was [discussed][0base] in August.
 Proponents of the technique thought that it would be most effective if
 routing nodes only charged a percentage of the amount routed without
@@ -473,6 +513,7 @@ _includes/specials/taproot/en/* -->
 
 ## September
 
+{:#tluv}
 One feature Bitcoin developers have long discussed is the ability to
 send bitcoins to a script which could limit which other scripts could
 later receive those bitcoins, a mechanism called [covenants][topic
@@ -492,6 +533,7 @@ ownership of a UTXO.
 
 ## October
 
+{:#txhids}
 In October, Bitcoin developers discussed a new way for a transaction to
 [identify][heritage identifiers] which set of bitcoins it wanted to
 spend.  Currently, bitcoins are identified by their location in the
@@ -504,6 +546,7 @@ advantages for designs such as [eltoo][topic eltoo], [channel
 factories][topic channel factories], and [watchtowers][topic
 watchtowers], all of which benefit contract protocols such as LN.
 
+{:#ptlcsx}
 Also in October, a combination of existing ideas for improving LN were
 bundled into a [single proposal][ptlcs extreme] that would bring some of
 the same benefits of eltoo but without requiring the
@@ -519,6 +562,7 @@ needed to be used by online computers.
 
 ## November
 
+{:#lnsummit}
 LN developers held the first general LN summit [since 2018][2018 ln
 summit] and [discussed][2021 ln summit] topics including using
 [taproot][topic taproot] in LN, including [PTLCs][topic ptlc],
@@ -532,6 +576,7 @@ payments].
 
 ## December
 
+{:#bumping}
 For single-sig onchain transactions, fee bumping a transaction's feerate
 to encourage miners to confirm it sooner is a relatively straightforward
 operation.  But for contract protocols such as LN and [vaults][topic
@@ -545,7 +590,31 @@ important long-term problem.
 
 ## Conclusion
 
-FIXME:write conclusion
+We tried something new in this year's summary---describing two dozen
+noteworthy developments in 2021 without mentioning even a single
+contributor's name.  We're indebted to all of those contributors and
+very much want to see them credited for their incredible work, but we
+also want to recognize all of the contributors who we wouldn't normally
+mention.
+
+They're the people spending hours on coding reviews, or who are writing
+tests for established behavior to ensure it doesn't unexpectedly change,
+or who put effort into debugging mysterious issues to fix problems
+before money is put at risk, or who are working on a hundred other tasks
+that would only make the news if they weren't being done.
+
+This final newsletter of 2021 is dedicated to them.  We don't have an
+easy way to make a list of the names of these underacknowledged
+contributors.  Instead we've omitted all names from this newsletter to
+make the point that developing Bitcoin is a team effort where some of
+the most important work is being done by people whose names have never
+appeared in any issue of this newsletter.
+
+We thank them and all contributors to Bitcoin in 2021.  We can't wait to
+see what exciting new developments they will deliver in 2022.
+
+*The Optech newsletter will return to its regular Wednesday publication
+schedule on January 5th.*
 
 <!-- FIXME add topic links, there's gonna be a lot!!! -->
 {% include references.md %}
@@ -667,3 +736,4 @@ FIXME:write conclusion
 [dec cs]: /en/newsletters/2021/12/15/#changes-to-services-and-client-software
 [mpa ml]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
 [ff orig]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
+[2020 conclusion]: /en/newsletters/2020/12/23/#conclusion