News62: edits for feedback (thanks everyone!)

Author: harding

_posts/en/newsletters/2019-09-04-newsletter.md

@@ -9,7 +9,7 @@ lang: en
 ---
 This week's newsletter relays a security announcement for LN
 implementations, describes a non-interactive coinjoin proposal, and
-notes a few changes in popular Bitcoin Infrastructure projects.
+notes a few changes in popular Bitcoin infrastructure projects.
 
 {% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %}
 {% include references.md %}
@@ -20,24 +20,24 @@ notes a few changes in popular Bitcoin Infrastructure projects.
   to be disclosed at the end of this month affect older LN
   implementations.  If you are using any of the following software
   versions, upgrading to a more recent version is [strongly
-  recommended:][cve ln]
+  recommended][cve ln]:
 
     - C-Lightning < 0.7.1
     - LND < 0.7
     - Eclair <= 0.3
 
 ## News
 
-- **SNICKER proposed:** Adam Gibson posted to the Bitcoin-Dev mailing
+- **SNICKER proposed:** Adam Gibson [posted][snicker email] to the Bitcoin-Dev mailing
   list with a [proposal][snicker] for *Simple Non-Interactive Coinjoin
-  with Keys for Encryption Reused* (SNICKER), a two-step method for
-  allowing wallets to create coinjoins non-interactively.  In the first
-  step---the *proposer* step--Alice's wallet uses the block chain to
-  create a map of addresses to public keys.  The wallet then checks the
-  UTXO set to determine whether any of those addresses have a current
-  balance smaller than the amount Alice controls.  If a satisfactory
-  UTXO is found, Alice creates a proposed coinjoin moving funds from
-  that address's UTXO and one or more of Alice's UTXOs to three outputs:
+  with Keys for Encryption Reused* (SNICKER), a method for
+  allowing wallets to create coinjoins non-interactively in two steps, a
+  *proposer step* and a *receiver step*.  In the proposer step,
+  Alice's wallet uses the block chain and UTXO set to find UTXOs for
+  which she knows (or can infer) the owner's public key.
+  She selects one of those UTXOs whose value is less than the amount
+  controlled by her wallet and creates a proposed coinjoin between that
+  UTXO and her wallet's UTXOs, producing three outputs:
 
   1. Coinjoin output to Alice
 
@@ -57,24 +57,18 @@ notes a few changes in popular Bitcoin Infrastructure projects.
   also be able to derive from Alice's public key.  With the shared
   secret and Bob's public key, Alice is able to create a new public key
   that only Bob can sign for.  That new public key is used to create the
-  new address for Bob's coinjoin output.  Nobody besides Alice and Bob
+  new address for Bob's coinjoin output.  No one besides Alice and Bob
   can tell the difference between the addresses, ensuring privacy for
   the coinjoin.
 
-  {% comment %}<!-- Note: the proposal as written assumes the PSBT will
-  be encrypted.  However, I (harding) chatted with Gibson and arubi on
-  IRC about making the PSBTs unencrypted as part of a mechanism to avoid
-  server spam, so the text says "perhaps encrypted" below to leave open
-  both possibilities.-->{% endcomment %}
-
   With information about the inputs and the outputs, Alice creates a
   [BIP174][] Partially-Signed Bitcoin Transaction (PSBT) containing the
   signatures for her UTXO or UTXOs.  She can then upload this PSBT to a
-  public server, perhaps encrypted so that only Bob can decrypt it.
+  public server (and she can encrypt it so that only Bob can decrypt it).
   This completes the proposer step in SNICKER.
 
-  If Bob participates in the scheme, his wallet can begin the second
-  step (*receiver* step) by periodically checking the server to see if
+  If Bob participates in the scheme, his wallet can begin the
+  receiver by periodically checking the server to see if
   anyone like Alice has sent him a proposed PSBT.  If so, Bob can
   evaluate the PSBT to ensure it's correct, add his signature for his
   UTXO to finalize it, and broadcast the transaction to complete the
@@ -88,18 +82,20 @@ notes a few changes in popular Bitcoin Infrastructure projects.
   people via a variety of servers, selecting whichever proposal he
   prefers (or none at all).  Either party can also spend their UTXO
   normally at any time, automatically invalidating any pending proposals
-  without any harm done.  The PSBTs can be exchanged using any medium,
-  such as a via a simple FTP server, making it easy for anyone to host a
+  without any harm done.  The PSBTs can be exchanged using any medium that doesn't require users identify themselves,
+  such as a via a simple FTP server over Tor, making it easy for anyone to host a
   SNICKER exchange server.
 
   The main downside of the proposal is that it requires the proposer
   (Alice) know the public key of the receiver (Bob).  Almost all
   transactions today pay an address that doesn't include a public key,
-  although that may to change if the proposed [taproot][bip-taproot]
+  although that may change if the proposed [taproot][bip-taproot]
   soft fork is activated and becomes widely adopted.  In the meantime,
-  the SNICKER proposal suggests using reused addresses where public keys
+  the SNICKER proposal suggests scanning for reused addresses where public keys
   have been revealed via the block chain, or by using a public key
-  from the input of a transaction that creates a UTXO.
+  from the input of a transaction that creates a UTXO.  For a more
+  detailed overview of the proposal, see [Gibson's blog post][snicker
+  blog].
 
 ## Notable code and documentation changes
 
@@ -114,7 +110,7 @@ notes a few changes in popular Bitcoin Infrastructure projects.
   as described in [last week's newsletter][bolts608].
 
 - [Eclair #899][] implements extended queries as proposed in [BOLTs
-  #557][], allowing an LN node to only request gossip updates that
+  #557][], allowing an LN node to request only gossip updates that
   arrived after a certain time or which have a different checksum than
   those the node has already seen.
 
@@ -127,5 +123,7 @@ notes a few changes in popular Bitcoin Infrastructure projects.
 [cve ln]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002130.html
 [bolts608]: /en/newsletters/2019/08/28/#bolts-608
 [bolts]: https://github.com/lightningnetwork/lightning-rfc/
-[snicker]: https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#storage-of-keys
+[snicker]: https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
 [ecdh]: https://en.wikipedia.org/wiki/Elliptic_curve_Diffie-Hellman
+[snicker email]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017283.html
+[snicker blog]: https://joinmarket.me/blog/blog/snicker/