News180: edits for feedback (thanks all!)

Author: harding

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

@@ -27,22 +27,22 @@ summary], [2019][2019 summary], and [2020][2020 summary].
 After years of discussion, January saw the first [release][bcc21] of a
 Bitcoin Core version supporting [signets][topic signet], following prior
 [support][cl#2816] by C-Lightning and followed by [support][lnd#5025] in
-LND.  Signets are test networks that can be used to simulate Bitcoin's
-main network (mainnet) either as it exists today or how it might exist
+LND.  Signets are test networks anyone can used to simulate Bitcoin's
+main network (mainnet), either as it exists today or how it might exist
 with certain changes (such as the activation of a soft fork consensus
 change).  Most software implementing signets also supports a default
 signet that provides a particularly convenient environment for software
 developed by different teams to be tested in a safe environment that
-come as close as possible to the environment they'll experience when
+comes as close as possible to the environment they'll experience when
 real money is at stake.  Also [discussed][signet reorgs] this year was
-adding deliberate block chain reorganizations to signet to help
+adding deliberate block chain reorganizations to Bitcoin Core's default signet network to help
 developers test their software against that class of problems.
 
 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, [Bitcoin Wiki
-page][bech32m page] was created to track adoption of bech32m addresses
+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.
 
 Another [first release][cl 0.9.3] of a new protocol was [onion
@@ -76,7 +76,7 @@ signing devices.
 problem for LN since 2015, received continued discussion throughout the
 year, with a [variety][jam1] of [possible][jam2] solutions
 [discussed][jam3].  Unfortunately no widely accepted solution was found
-and the problem remained unmitigated by years end.
+and the problem remained unmitigated by year's end.
 
 {:.center}
 ![Illustration of jamming attacks](/img/posts/2020-12-ln-jamming-attacks.png)
@@ -88,7 +88,7 @@ and the problem remained unmitigated by years end.
 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
-original features, likely added to make Bitcoin addresses shorter, has
+original features, public key hashing---likely added to make Bitcoin addresses shorter---has
 also likely made it harder to steal funds from a limited number of users
 if there's a sudden major advance in quantum computing.  [Taproot][topic
 taproot] doesn't provide this feature and at least one developer was
@@ -123,19 +123,19 @@ addresses.
 
 - **March<!--taproot-->** began with many discussion participants tentatively agreeing
   to [try][speedy trial] a particular activation approach named *speedy
-  trial*, which was design to gather rapid feedback from miners but also
+  trial*, which was designed to gather rapid feedback from miners but also
   still give users sufficient time to upgrade their software for taproot
-  enforcement.  Speedy trial would go to become the actual
+  enforcement.  Speedy trial would go on to become the actual
   [mechanism][topic soft fork activation] used to activate taproot.
 
-    While activation discussion were underway, there was a final
+    While activation discussions were underway, there was a final
     [discussion][quant] about one of its design decisions, using bare
-    public keys, which it was argued might put user funds at increased
+    public keys, which was argued might put user funds at increased
     risk of being stolen by future quantum computers.  Many developers
     argued that the concerns were unwarranted or, at least, overblown.
 
     Also in March, Bitcoin Core merged support for [BIP350][], allowing
-    it to pay [bech32m][topic bech32] addresses.  This slight variation
+    it to pay to [bech32m][topic bech32] addresses.  This slight variation
     on the bech32 addresses that are used for payments to original
     segwit version addresses fixes a bug which could've caused taproot
     users to lose money in some very rare cases.  (Original segwit
@@ -155,12 +155,12 @@ addresses.
   of the speedy trial activation mechanism.  However, the authors of
   different implementations of the two different versions came to a
   [compromise][bcc#21377] that allowed a Bitcoin Core [version][bcctap]
-  to be released with activation parameters.
+  to be released with an activation mechanism and parameters.
 
 <!-- TODO:EXTRA: BIPs drama? -->
 
-- **May<!--taproot-->** was when miners [began][signal began] to be [able][signal
-  able] to signal their willingness to enforce taproot and a website for
+- **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].
 
 - **June<!--taproot-->** saw miners [lock-in taproot][lockin], committing to enforcing
@@ -183,7 +183,7 @@ addresses.
   proposals][bip118 update] were updated to use taproot or [lessons
   learned][bip119 update] from its activation.
 
-- **August<!--taproot-->** was quiet for development, although some
+- **August<!--taproot-->** was quiet for taproot development, although some
   [documentation][reuse risks] related to taproot was written.
 
 - **September<!--taproot-->** saw Bitcoin's most popular open source merchant software
@@ -203,8 +203,8 @@ addresses.
   subsequent blocks didn't include any taproot-spending transactions.
   However, thanks to the work of several developers and mining pool
   administrators, most blocks mined in subsequent days were ready to
-  contain taproot-spending transactions.  Development and [testing][cbf
-  verification] of taproot-ready software [continued][rb#691].
+  contain taproot-spending transactions.  [Development][nov cs] and [testing][cbf
+  verification] of [taproot-ready][dec cs] software [continued][rb#691].
 
 - **December<!--taproot-->** saw Bitcoin Core merge a PR that would
   allow [descriptor wallets][topic descriptors] to create
@@ -215,7 +215,7 @@ addresses.
 Despite complications choosing an activation mechanism for taproot and
 some minor confusion immediately after its activation, the final steps
 of adding support for the taproot soft fork to Bitcoin overall seemed to
-go well.  This is hardly the end the of the story for taproot.  Optech
+go well.  This is hardly the end of the story for taproot.  Optech
 expects to continue to spend a significant amount of time writing about
 it in the coming years as wallet and infrastructure developers begin
 making use of its many features.
@@ -225,7 +225,7 @@ making use of its many features.
 ## April
 
 LND added [support][lnd#5709] in April for making Atomic Multipath
-Payments (AMP), also called original AMPs due to being described earlier
+Payments ([AMP][topic amp]), also called original AMPs due to being described earlier
 than the [Simplified Multipath Payments][topic multipath payments]
 (SMPs) all major LN implementations currently support.  AMPs have a
 privacy advantage over SMPs and also ensure that the receiver has
@@ -241,7 +241,7 @@ 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 contract protocols such as LN from unexpected transaction relay
+risks to users of contract protocols (such as LN) from unexpected transaction relay
 behavior.
 
 Also in May, the C-Lightning project [merged][cl#4489] a plugin for
@@ -250,7 +250,7 @@ both parties can provide some amount of the initial funding.  In
 addition to prior dual-funding work [merged][cl#4410] this year, this
 allows the party initiating the channel open to not only spend funds
 through the channel but also receive them in the channel's initial
-state.  Dual-funding is particularly useful for merchants whose primary
+state.  That initial ability to receive funds makes dual-funding particularly useful for merchants whose primary
 use of LN is receiving payments instead of sending them.
 
 <div markdown="1" class="callout" id="releases">
@@ -297,7 +297,7 @@ use of LN is receiving payments instead of sending them.
   outputs][topic anchor outputs] the default commitment transaction
   format, added support for using a pruned Bitcoin full node, allowed
   receiving and sending payments using Atomic MultiPath ([AMP][topic
-  multipath payments]), and increased LND's [PSBT][topic psbt]
+  amp]), and increased LND's [PSBT][topic psbt]
   capabilities
 
 - [Bitcoin Core 22.0][] included support for [I2P][topic anonymity
@@ -325,13 +325,14 @@ use of LN is receiving payments instead of sending them.
 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, wallets aware of the new
-method will be able to collaborate when [CPFP fee bumping][topic cpfp]
+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.
 
 Another attempt to make fee bumping more effective was a [proposal][rbf
-default] to make [transaction replacement by fee][topic rbf] (RBF) the
-default behavior in Bitcoin Core.  This could help resolve some issues
+default] to allow any unconfirmed transaction to be [replaced by
+fee][topic rbf] (RBF) in Bitcoin Core---not just those that opt-in to
+allowing replacement using [BIP125][].  This could help resolve some issues
 with fee bumping in multiparty protocols and also improve privacy by
 allowing more transactions to use uniform settings.  Related to privacy,
 a separate [proposal][nseq default] suggested that wallets creating
@@ -342,12 +343,12 @@ does need to use BIP68 to blend in with more common transactions.
 Neither proposal seemed to make much progress despite few significant
 objections.
 
-June also saw the merge of [first PR][bcc#20833] in a
-[series][bcc#22642] attempting to implement mempool package acceptance
+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
 relay][topic package relay] will allow relay nodes and miners to treat
 packages of related transactions as if they were a single transaction
-for fee purposes.  A package might contain a parent transaction with a
+for feerate purposes.  A package might contain a parent transaction with a
 low feerate and a child transaction with a high feerate; the
 profitability of mining the parent transaction would incentivize miners
 to also mine the parent transaction.  Although package mining has been
@@ -359,7 +360,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.
 
-An idea original proposed in 2019 for LN saw renewed life in June.  The
+An idea originally proposed in 2019 for LN saw renewed life in June.  The
 original *fast forwards* idea described how an LN wallet could receive
 or relay a payment with fewer network round-trips, reducing network
 bandwidth and payment latency.  The idea was [expanded][ff expanded]
@@ -374,9 +375,9 @@ decentralized liquidity advertisements system was [merged][cl#4639] into
 an LN implementation.  The still-draft [liquidity ads][bolts #878]
 proposal allows a node to use the LN gossip protocol to advertise its
 willingness to lease out its funds for a period of time, giving other
-nodes the ability to buy incoming capacity that allows them to receive
+nodes the ability to buy inbound capacity that allows them to receive
 instant payments. A node that sees the advertisement can simultaneously
-pay for and receive the incoming capacity using a [dual funded][topic
+pay for and receive the inbound capacity using a [dual funded][topic
 dual funding] channel open. Although there’s no way to enforce that the
 advertising node actually routes payments, the proposal does incorporate
 an earlier proposal also [later used][lnd#5709] in Lightning Pool that
@@ -393,15 +394,15 @@ Core, [draft BIPs][descriptor bips1] were [created][descriptor bips2] for
 that contain all the information necessary to allow a wallet or other
 program to track payments made to or spent from a particular script or
 set of related scripts (i.e. an address or a set of related addresses
-such as in an HD wallet).  Descriptors combine well with [miniscript][topic miniscript] in
+such as in an [HD wallet][topic bip32]).  Descriptors combine well with [miniscript][topic miniscript] in
 allowing a wallet to handle tracking and signing for a larger variety of
 scripts.  They also combine well with [PSBTs][topic psbt] in allowing
 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.
 
-A common way of opening LN channels that had never before been official
-supported began to be [specified][0conf channels] in July.  Zero-conf
+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
 channels where the funder gives some or all of their initial funds to
 the acceptor. Those funds are not secure until the channel open
@@ -422,10 +423,10 @@ who offer this service.
 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
-superseded by [`SIGHASH_ANYPREVOUT`][topic sighash_anyprevout] first
+superseded by [`SIGHASH_ANYPREVOUT` and `SIGHASH_ANYPREVOUTANYSCRIPT`][topic sighash_anyprevout] first
 [proposed][anyprevout proposed] in 2019.  The new sighash types will
 allow offchain protocols such as LN and [vaults][topic vaults] to reduce
-the amount of intermediate states they need to retain, greatly reducing
+the number of intermediate states they need to retain, greatly reducing
 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.
@@ -439,11 +440,11 @@ TODO:EXTRA LN migration to real databases:
 
 ## August
 
-Fidelity bonds is an idea [proposed][wiki contract] at least as early as
+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.  Because the bitcoins can't be used again until
-their time lock expires, anyone banned or otherwise penalized during the
-locking period is prevented from using the same bitcoins to create a new
+cost for misbehavior in third-party systems.  Because the bitcoins can't be used again until
+their time lock expires, users in the other system who are banned or otherwise penalized during the
+locking period are prevented from using the same bitcoins to create a new
 virtual identity.  In August, JoinMarket put into [production][fi bonds]
 the first large scale and decentralized use of fidelity bonds.  Within
 days of release, over 50 BTC had been timelocked (worth over $2 million
@@ -476,14 +477,14 @@ 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
 covenants].  For example, Alice receives bitcoins to a script that can
-be spent by her hot wallet---but only by sending it to second script
+be spent by her hot wallet---but only by sending it to a second script
 that time delays any further spend by her hot wallet.  During the time
 delay, her cold wallet can claim the funds.  If it doesn't, and the time
 delay passes, Alice's hot wallet can spend the funds freely.  In
 September, a new `OP_TAPLEAF_UPDATE_VERIFY` opcode was
 [proposed][op_tluv] for creating these sort of covenants in a way that
 takes particular advantage of taproot's ability to spend funds either
-using just a signature (keypath spending) or a MAST-like tree of scripts
+using just a signature (keypath spending) or a [MAST-like][topic mast] tree of scripts
 (scriptpath spending).  The new opcode would be especially useful for
 creating [joinpools][topic joinpools] that could significantly increase
 privacy by allowing multiple users to easily and trustlessly share
@@ -617,7 +618,6 @@ FIXME:write conclusion
 [rbf default]: /en/newsletters/2021/06/23/#allowing-transaction-replacement-by-default
 [nseq default]: /en/newsletters/2021/06/16/#bip-proposed-for-wallets-to-set-nsequence-by-default-on-taproot-transactions
 [bcc#20833]: /en/newsletters/2021/06/02/#bitcoin-core-20833
-[bcc#22642]: /en/newsletters/2021/08/18/#bitcoin-core-22642
 [ff expanded]: /en/newsletters/2021/06/09/#receiving-ln-payments-with-a-mostly-offline-private-key
 [cl#4639]: /en/newsletters/2021/07/28/#c-lightning-4639
 [descriptor bips1]: /en/newsletters/2021/07/07/#bips-for-output-script-descriptors
@@ -663,3 +663,6 @@ FIXME:write conclusion
 [wiki contract]: https://en.bitcoin.it/wiki/Contract#Example_1:_Providing_a_deposit
 [cl#4771]: /en/newsletters/2021/10/27/#c-lightning-4771
 [fee bump research]: /en/newsletters/2021/12/08/#fee-bumping-research
+[nov cs]: /en/newsletters/2021/11/17/#changes-to-services-and-client-software
+[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