News95: edits (thanks jonatack, ariad, bluematt, jnewbery!)

Author: harding

_posts/en/newsletters/2020-04-29-newsletter.md

@@ -8,9 +8,8 @@ layout: newsletter
 lang: en
 ---
 This week's newsletter summarizes the disclosure of an issue affecting
-the safety of routed LN payments, announces a new presigned vault
-proposal, and publishes a field report from Suredbits about building a
-high availability LN node.  Also included are our regular sections with
+the safety of routed LN payments and announces a new presigned vault
+proposal.  Also included are our regular sections with
 popular questions and answers from the Bitcoin StackExchange,
 announcements of releases and release candidates, and descriptions of
 notable code changes in popular Bitcoin infrastructure projects.
@@ -19,9 +18,7 @@ notable code changes in popular Bitcoin infrastructure projects.
 
 - **Review the disclosure of a potential LN issue:** as explained in the
   *news* section below, a public disclosure this week describes a new
-  method for stealing money from LN routing nodes (unaffected are
-  endpoint nodes that are only the initial spenders or final receivers
-  of payments).  The issue partly overlaps with a previous well-known
+  method for stealing money from LN nodes.  The issue partly overlaps with a previous well-known
   issue that has not been exploited (to our knowledge) because almost
   all onchain transactions relayed in the past two years confirmed
   relatively quickly even if they only paid the default minimum relay
@@ -35,7 +32,7 @@ notable code changes in popular Bitcoin infrastructure projects.
 - **New attack against LN payment atomicity:** Matt Corallo started a
   thread across both the [Lightning-Dev][corallo thread ld] and
   [Bitcoin-Dev][corallo thread bd] mailing lists disclosing an attack
-  discovered during [discussion][BOLTs #688] about allowing LN
+  discovered during a [discussion][BOLTs #688] about allowing LN
   commitment transactions to be [CPFP][topic cpfp] fee bumped via
   [anchor outputs][topic anchor outputs].  We'll describe the attack
   using an extended example: Alice uses an LN channel to send Bob a Hash
@@ -45,7 +42,7 @@ notable code changes in popular Bitcoin infrastructure projects.
      - If Bob discloses the preimage for `<hash>`, he can spend 1 BTC of
        Alice's money
 
-     - Otherwise, after 80 blocks, Alice can spend that 1 BTC back to
+     - Otherwise, after 80 blocks, Alice can refund that 1 BTC back to
        herself
 
     Alice also told Bob that the goal of her payment is to pay Mallory, so Bob
@@ -54,7 +51,7 @@ notable code changes in popular Bitcoin infrastructure projects.
      - If Mallory discloses the preimage for `<hash>`, she can spend 1
        BTC of Bob's money (we're ignoring routing fees in this example)
 
-     - Otherwise, after 40 blocks, Bob can spend his 1 BTC back to
+     - Otherwise, after 40 blocks, Bob can refund that 1 BTC back to
        himself
 
     Although the above HTLCs are usually created and settled offchain,
@@ -70,7 +67,7 @@ notable code changes in popular Bitcoin infrastructure projects.
     Alice (either onchain or offchain).  Or, if Bob doesn't see a
     preimage settlement transaction, Bob can create his own refund
     settlement transaction after 40 blocks that takes back his 1 BTC,
-    allowing him to also refund Alice her 1 BTC (again, either onchain
+    allowing him to also initiate the refund of Alice's 1 BTC (again, either onchain
     or offchain).  In either case, this leaves everyone in compliance
     with the intent of their contracts.
 
@@ -102,7 +99,7 @@ notable code changes in popular Bitcoin infrastructure projects.
     Alice-Bob HTLC once its 80 block timeout expires.  When Mallory's
     preimage settlement transaction does eventually confirm, Mallory
     gets the 1 BTC that Bob offered her in the Bob-Mallory HTLC.  This
-    leaves Bob 1 BTC poorer than he started.
+    leaves Bob 1 BTC poorer than when he started.
 
     Several solutions were considered in the thread, but all had
     problems or involved significant tradeoffs:
@@ -111,12 +108,12 @@ notable code changes in popular Bitcoin infrastructure projects.
       monitor the Bitcoin P2P relay network and learn about Mallory's
       settlement transaction.  Some LN nodes such as Eclair already do
       this and it seems like a [reasonable amount of extra
-      burden][osuntokun reasonable] since the problem only affects
-      routing nodes (like Bob).  Nodes that only send or receive
-      payments on behalf of themselves are unaffected, so everyday users
+      burden][osuntokun reasonable] since the problem only directly affects
+      routing nodes (like Bob).  Nodes that just send or receive
+      payments on behalf of themselves are only indirectly affected,[^non-routing-issues] so everyday users
       could still run lightweight LN clients on mobile devices.
-      Unfortunately, not all full nodes receive the same transactions
-      even when everything is working perfectly and there are techniques
+      Unfortunately, not all full nodes receive the same transactions as other nodes
+      even when everything is working perfectly.  Worse, there are techniques
       attackers like Mallory can use to [send different conflicting
       transactions][corallo mempool not guaranteed] to different peers
       (for example, sending the pinned preimage settlement transaction
@@ -142,11 +139,11 @@ notable code changes in popular Bitcoin infrastructure projects.
       This would require those transactions to be larger (increasing
       onchain fees) and presigned (reducing flexibility).  This would
       only directly affect channels which are unilaterally closed while payments
-      are pending, which is already a situation that that can
+      are pending, which is already a situation that can
       significantly increase onchain costs and so is something users try
       to avoid.  However, raising the cost of onchain enforcement also
-      raises the minimum value of payments that can be sent trustlessly
-      through LN with economical enforcement.  Depsite these challenges,
+      raises the minimum practical value of payments that can be sent trustlessly
+      through LN.  Despite these challenges,
       as of this writing, this appears to be the most preferred
       solution.
 
@@ -163,9 +160,7 @@ notable code changes in popular Bitcoin infrastructure projects.
     to reclaim her funds from Bob, again creating the opportunity for
     Bob to end up both paying Mallory and giving a refund to Alice.
     (This existing issue is what developers were working on fixing when
-    the new issue was discovered.  Its ultimate solution also depends on
-    full nodes being able to perform [package relay][Bitcoin Core
-    #14895].)
+    the new issue was discovered.[^package-relay])
 
     So far we're unaware of any real-world losses due to onchain fee
     management problems in LN, possibly in part because the past two
@@ -180,8 +175,8 @@ notable code changes in popular Bitcoin infrastructure projects.
     Current defaults in popular LN nodes are [14][cl ced] for
     C-Lightning, [40][lnd ced] for LND, [72][rl ced] for Rust-Lightning,
     and [144][eclair ced] for Eclair.  Note that increasing the value
-    will make your channels less desirable to spenders who are choosing
-    routes for their payments as higher values increase the worst case
+    will make your channels less desirable to spenders,
+    as higher values increases the normal worst case
     amount of time a payment could be stuck waiting to be settled.
 
 - **Multiparty vault architecture:** Antoine "Darosior" Poinsot
@@ -230,8 +225,6 @@ endcomment %}
 
 ## Releases and release candidates
 
-FIXME:harding update to latest versions Tuesday afternoon
-
 *New releases and release candidates for popular Bitcoin infrastructure
 projects.  Please consider upgrading to new releases or helping to test
 release candidates.*
@@ -270,10 +263,32 @@ version 0.20.*
 
 ## Special thanks
 
-We thank Antoine Riard and ZmnSCPxj for reviewing drafts of this
+We thank Antoine Riard, ZmnSCPxj, and Matt Corallo for reviewing drafts of this
 newsletter and helping us understand the details of the LN atomicity
 issue.  Any remaining errors are the fault of the newsletter author.
 
+## Footnotes
+[^package-relay]:
+    The ultimate solution to deal with arbitrary feerates in LN also
+    depends on Bitcoin full nodes being able to perform [package
+    relay][Bitcoin Core #14895], a feature that's long been discussed
+    but never satisfactorily implemented.  For now, LN commitment
+    transactions can usually just [pay slightly higher][corallo slightly
+    higher] feerates than strictly necessary to avoid the need for
+    package relay.
+
+[^non-routing-issues]:
+    Although the only known way to use this attack to steal money
+    directly is by abusing a routing node (such as Bob in
+    Alice→Bob→Mallory), when the same attack of delaying the preimage
+    settlement and blocking the refund settlement is executed against a
+    spender (such as Alice in Alice→Mallory), it may produce a "payment
+    failed" error that causes the user to initiate a second payment
+    without realizing the first payment hasn't been revoked.  This
+    [indirect attack][corallo send twice] can perhaps be dealt with by warning the user that
+    the payment is stuck---not failed---and that sending additional
+    payments could result in losses.
+
 {% include references.md %}
 {% include linkers/issues.md issues="688,15761,17509,14895" %}
 [bitcoin core 0.20.0]: https://bitcoincore.org/bin/bitcoin-core-0.20.0
@@ -299,3 +314,5 @@ issue.  Any remaining errors are the fault of the newsletter author.
 [rl ced]: https://github.com/rust-bitcoin/rust-lightning/blob/12e2a81e1daf635578e1cfdd7de55324ed04bd48/lightning/src/ln/channelmanager.rs#L430
 [simplicity]: https://blockstream.com/simplicity.pdf
 [bitcoin core default ancestor limit]: https://github.com/bitcoin/bitcoin/blob/9fac600ababd8edefbe053a7edcd0e178f069f84/src/validation.h#L56
+[corallo slightly higher]: https://github.com/bitcoinops/bitcoinops.github.io/pull/394#discussion_r416014263
+[corallo send twice]: https://github.com/bitcoinops/bitcoinops.github.io/pull/394#discussion_r416099907