News62: add snicker

Author: harding

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

@@ -8,8 +8,8 @@ layout: newsletter
 lang: en
 ---
 This week's newsletter relays a security announcement for LN
-implementations and notes a few changes in popular Bitcoin
-Infrastructure projects.
+implementations, describes a non-interactive coinjoin proposal, and
+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 %}
@@ -28,9 +28,78 @@ Infrastructure projects.
 
 ## News
 
-*None this week besides the above LN security announcement.  Instead,
-we extend our best wishes for safe travels and informative presentations
-at Scaling Bitcoin Tel Aviv next week.*
+- **SNICKER proposed:** Adam Gibson posted 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:
+
+  1. Coinjoin output to Alice
+
+  2. Coinjoin output to the owner of the selected UTXO (Bob).  Both
+     coinjoin outputs pay the same amount to make them indistinguishable
+     to third parties looking at the block chain
+
+  3. Change output to Alice returning any of her money in excess of the
+     coinjoin amount
+
+  Addresses that already have transaction history can't be reused or the
+  privacy benefits of coinjoin are lost, so Alice generates new unique
+  addresses for her two outputs.  However, Bob has no way in this
+  non-interactive protocol to tell Alice what addresses to use for his
+  output.  Instead, Alice can use Bob's public key and [Elliptic Curve
+  Diffie-Hellman][ECDH] (ECDH) to derive a shared secret that Bob will
+  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
+  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.
+  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
+  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
+  coinjoin.
+
+  The key advantage of this proposal is that no interaction is required
+  between Alice and Bob.  They each perform their steps independently
+  and aren't limited by having each other as potential partners.  Alice
+  can create as many proposals as she wants at no cost (except server
+  storage space) and Bob can receive multiple proposals from different
+  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
+  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]
+  soft fork is activated and becomes widely adopted.  In the meantime,
+  the SNICKER proposal suggests using 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.
 
 ## Notable code and documentation changes
 
@@ -58,3 +127,5 @@ at Scaling Bitcoin Tel Aviv next week.*
 [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
+[ecdh]: https://en.wikipedia.org/wiki/Elliptic_curve_Diffie-Hellman