News153: edits to harding sections

Author: harding

_posts/en/newsletters/2021-06-16-newsletter.md

@@ -7,7 +7,7 @@ type: newsletter
 layout: newsletter
 lang: en
 ---
-This week's newsletter celebrates the lock in of the taproot soft fork,
+This week's newsletter celebrates the lock-in of the taproot soft fork,
 describes a draft BIP for improving transaction
 privacy by varying the fields used to implement anti fee sniping, and
 features an article about the challenges of combining transaction
@@ -23,7 +23,7 @@ software.
   [342][bip342] were locked in by signaling miners last weekend.
   Taproot will be safe to use after block 709,632, which is expected in
   early or mid November.  The delay gives time for users to upgrade
-  their nodes to a release (such as Bitcoin Core 0.21.1) that will
+  their nodes to a release (such as Bitcoin Core 0.21.1 or later) that will
   enforce taproot's rules, ensuring that funds received to taproot
   scripts after block 709,632 are safe even if there's a problem with
   miners.
@@ -33,8 +33,8 @@ software.
     be ready to take advantage of greater efficiency, privacy, and
     fungibility as soon as the activation is complete.
 
-    Readers celebrating the lock in of taproot may also wish to read a
-    [short history][wuille taproot] of taproot's origins and history by
+    Readers celebrating the lock-in of taproot may also wish to read a
+    [short thread][wuille taproot] about taproot's origins and history by
     developer Pieter Wuille.
 
 - **BIP proposed for wallets to set nSequence by default on taproot transactions:**
@@ -114,7 +114,7 @@ BOLTs][bolts repo].*
   in Bitcoin Core.  The most notable change is the use of the
   optimized modular inverse code described in Newsletters [#136][news136
   safegcd] and [#146][news146 safegcd].  Performance evaluations posted
-  to the PR found it to speed up old block verification by about 10%.
+  to the PR found it accelerated old block verification by about 10%.
 
 - [C-Lightning #4591][] adds support for parsing [bech32m][topic bech32]
   addresses. C-Lightning will now permit a peer that has negotiated the feature

_topics/en/fee-sniping.md

@@ -66,9 +66,10 @@ honestly mining is `x` percent of the [best feerate set of
 transactions][csb] in their mempool.
 
 Alternatively, a miner could dishonestly attempt to re-mine the
-immediately previous block plus a wholly new block to extend the
-chain.  That's fee sniping and their chance of succeeding at it if every
-other miner is honest is `(x/(1-x))^2`.  Even though fee sniping has a
+previous block plus a wholly new block to extend the
+chain.  This behavior is referred to as fee sniping, and the dishonest
+miner's chance of succeeding at it if every
+other miner is honest is `(x/(1-x))^2`.  Even though fee sniping has an
 overall lower probability of success than honest mining, attempting
 dishonest mining could be the more profitable choice if transactions in
 the previous block paid significantly higher feerates than the
@@ -77,7 +78,7 @@ can be worth more than a large chance at a small amount.
 
 The problem is actually worse than described above because every miner
 who chooses to mine dishonestly reduces the number of honest
-miners trying to extended the chain.  The smaller the share of hash
+miners trying to extend the chain.  The smaller the share of hash
 rate controlled by honest miners, the greater the probability that a
 dishonest miner will be successful, so a single large miner
 rationally choosing to mine dishonestly can set off a cascade of
@@ -86,10 +87,10 @@ If that persists for an extended period of time, confirmation scores
 cease to be a proxy for transaction finality and Bitcoin becomes
 unusable until the problem is resolved.  We expect the most likely
 resolution would be centralization of mining---a cartel representing
-a majority of hashrate agreeing to never reorg each others blocks
+a majority of hash rate agreeing to never reorg each others' blocks
 can restore stability to the system, but that comes with the
-increased risk that they'll later choose to (or be pressured into)
-censoring certain transactions.
+increased risk that they'll later
+censor certain transactions.
 
 ### Mitigations
 
@@ -99,7 +100,7 @@ censoring certain transactions.
   transactions they know about now and try to put them into the oldest block
   they're working to re-mine.  All other blocks would be empty, with
   miners only creating them to bury their re-mined block under as much
-  proof-of-work as possible.
+  proof of work as possible.
 
     {:.center}
     ![Illustration of fee sniping without block limits](/img/posts/2021-06-sniping-size-limit.png)
@@ -109,7 +110,7 @@ censoring certain transactions.
 
     1. It tends to prevent any new block at the tip of the chain from
        containing all pending transactions, leaving some transactions
-       for the next block.  If the amount of transaction fee available
+       for the next block.  If the amount of transaction fee expected
        from honestly mining the next block is close to the amount of
        transaction fee available from dishonestly re-mining the previous
        block, all rational miners will behave honestly.
@@ -119,7 +120,7 @@ censoring certain transactions.
        near the tip empty---those blocks will need to contain fee-paying
        transactions.  Other dishonest miners may attempt themselves to
        fee snipe those transactions, reducing the revenue of the initial
-       fee sniping miner and possible discouraging them from fee sniping
+       fee sniping miner and possibly discouraging them from fee sniping
        in the first place.
 
 - **Rearrangement protection (anti fee sniping):** even with a block size
@@ -149,20 +150,14 @@ censoring certain transactions.
 
      This rearrangement protection is commonly called **anti fee
      sniping.** Originally [implemented][bitcoin core #2340] in Bitcoin
-     Core, anti fee sniping is also used today by Electrum, Blockstream
-     Green, LND, and C-Lightning.
+     Core, anti fee sniping is now also used by several other wallets.
 
     All wallets that implement anti fee sniping today use nLockTime
     height locks to prevent a transaction from being included in the
     re-mined version of a previous block.  It's also [possible][belcher
     post] to implement the same protection using [BIP68][] nSequence
-    height locks.  This wouldn't be any more effective at preventing fee
-    sniping, but it would provide a good reason for regular wallets to
-    set their nSequence values to the same values that are required for
-    transactions in certain [multisignature][topic multisignature]-based
-    contract protocols, such as ideas for coinswaps and taproot-enabled
-    LN.  This helps make regular wallet transactions look like contract
-    protocol transactions and vice versa.
+    height locks, which could help make regular wallet transactions look
+    like contract protocol transactions and vice versa.
 
 We're unaware of any developers who think the above mechanisms are a
 complete solution to the fee sniping problem, but every other mitigation