Newsletters: add 66 (2019-10-02)

_includes/articles/dong-btse-operation.md

@@ -0,0 +1,14 @@
+{:.post-meta}
+*by [Carl Dong](https://twitter.com/carl_dong)<br>Engineer at Optech*
+
+[BTSE](https://www.btse.com/en/home) uses segwit, BIP32 HD wallets, and multisig key management to reduce their operational burdens and improve fund safety. For this Optech field report, we interviewed BTSE staff to learn how their exchange operations have benefited from these Bitcoin technologies.
+
+BIP32 is a widely-implemented [standard][BIP32] that describes how to deterministically derive arbitrarily-many new public keys [from a single extended public key](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Unsecure_money_receiver_NmisubHsub0), even if the corresponding private key is kept offline. Without BIP32, the burden of securely storing private keys would incentivize reuse of public keys and addresses, leading to [problems](https://en.bitcoin.it/wiki/Address_reuse) that include exchange front-running and user loss of privacy. Speaking about the operational advantages of cold wallet deposits for users, BTSE's CEO Jonathan Leong notes that "if the hot wallet keys are compromised, addresses for all users would have to be re-generated, and inevitably some users would continue to send funds to their old addresses."
+
+Although exchanges using BIP32 can keep their private key offline, that private key is still a single point of failure. Happily, they can lessen the impact of compromise of any one single key by constructing a k-of-n multisig address with each of the n public keys derived from a different extended public key. What BTSE achieves with this combination is on-the-fly generation of arbitrarily-many addresses that all deposit straight into a multisig cold wallet without needing to touch the private keys.
+
+Aside from BIP32 and multisig, BTSE also uses [P2SH-P2WSH](https://bitcoincore.org/en/segwit_wallet_dev/#complex-script-support) (P2SH-wrapped segwit) for their deposit addresses. Segwit allows BTSE to reduce the fee of spending transactions by reducing their weight, such as for moving to hot wallets or UTXO consolidation. As an example, spending from a P2SH-P2WSH 2-of-3 multisig address [saves 44% when compared to spending from a legacy P2SH one](https://en.bitcoin.it/wiki/Techniques_to_reduce_transaction_fees#P2SH-wrapped_segwit). As adoption of sending to native segwit P2WSH addresses rises (tracked on Optech’s [compatibility matrix][]), businesses should also consider using these addresses for deposits to unlock 14% additional savings and increase security for their multisig scripts (256-bits rather than 160-bits). You can learn about adoption speed, address security, and much more in our [Bech32 Sending Support series][bech32 series].
+
+Segwit, BIP32, and multisig work together to ease the burden of operating a secure, usable, and low-fee exchange for BTSE. Optech encourages new exchanges to consider these technologies when designing their infrastructure. For existing exchanges, as noted in a previous field report, a good time to consider adopting these technologies and reducing your technical debt is when you're also consolidating UTXOs.
+
+{% include references.md %}

_includes/references.md

@@ -1,4 +1,5 @@
 {% comment %}<!-- internal site links, alphabetical order -->{% endcomment %}
+[bech32 series]: /en/bech32-sending-support/
 [compatibility matrix]: /en/compatibility/
 [optech email]: mailto:info@bitcoinops.org
 [rss feed]: /feed.xml

_posts/en/2019-10-02-btse-exchange-operation.md

@@ -0,0 +1,16 @@
+---
+title: 'Field Report: Exchange operation using Bitcoin technologies at BTSE'
+permalink: /en/btse-exchange-operation/
+name: 2019-10-02-btse-exchange-operation
+slug: 2019-10-02-btse-exchange-operation
+type: posts
+layout: post
+lang: en
+version: 1
+
+excerpt: >
+  A field report about how BTSE uses Bitcoin technologies to improve their
+  exchange operations.
+
+---
+{% include articles/dong-btse-operation.md hlevel='##' %}

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

@@ -53,8 +53,8 @@ infrastructure projects.
     regular Bitcoin transactions (state changes) to be easily reused
     within payment channels.
 
-- **Request for comments on limiting LN gossip updates to once per
-  day:** Rusty Russell [posted][less gossip] to the Lightning-Dev
+- **Request for comments on limiting LN gossip updates to once per day:**
+  Rusty Russell [posted][less gossip] to the Lightning-Dev
   mailing list his plan to limit the number of gossip updates
   C-Lightning will accept to one per day normally.  By his calculations
   based on the current network characteristics, this should limit the

_posts/en/newsletters/2019-10-02-newsletter.md

@@ -0,0 +1,141 @@
+---
+title: 'Bitcoin Optech Newsletter #66'
+permalink: /en/newsletters/2019/10/02/
+name: 2019-10-02-newsletter
+slug: 2019-10-02-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter notes a proposed BIP that would allow nodes to
+implement the Erlay transaction relay protocol, announces full
+disclosure of vulnerabilities that affected earlier versions of LN
+implementations, links to a transcript from a recent Optech schnorr
+and taproot workshop, and includes a field report about some of the
+technology Bitcoin exchange BTSE uses to conserve block chain
+space while ensuring the safety of user deposits.  We also
+describe several notable changes to popular Bitcoin infrastructure
+projects.
+
+{% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %}
+{% include references.md %}
+
+## Action items
+
+*None this week.*
+
+## News
+
+- **Draft BIP for enabling Erlay compatibility:** a draft [BIP for
+  transaction relay through set reconciliation][bip-reconcil] has been
+  [posted][reconcil post] to the Bitcoin-Dev mailing list by [Erlay][]
+  co-author Gleb Naumenko.  Currently, Bitcoin nodes send each of their
+  peers the txids for all newly-seen transactions, resulting in each
+  node receiving many duplicate txid announcements.  This can be quite
+  bandwidth inefficient for Bitcoin's tens of thousands of nodes and
+  several hundred thousand transactions a day.  Alternatively, as [described
+  previously][erlay paper], minisketch-based set reconciliation allows
+  nodes to send a *sketch* of a set of short txids that can be combined
+  with the short txids the receiving peer already knows about to allow the
+  receiver to recover the short txids it hasn't seen yet.  The size of the
+  sketch is roughly equal to the expected size of the short txids that need to
+  be recovered, reducing txid-announcement bandwidth.  Erlay is a
+  proposal that suggests how to use this mechanism to achieve the best
+  mix of bandwidth efficiency and network robustness.  This draft BIP
+  describes the proposed implementation of the minisketch-based set
+  reconciliation between nodes, laying the foundation for the
+  implementation of Erlay.  We encourage anyone with feedback to contact
+  the BIP authors either privately or on the mailing list.
+
+- **Full disclosure of fixed vulnerabilities affecting multiple LN
+  implementations:** several weeks ago, the developers of C-Lightning,
+  Eclair, and LND announced the previous discovery of an undisclosed
+  issue in each of their implementations, which they had each fixed in a
+  recent release.  At that time, they strongly encouraged their users to
+  upgrade (a message which Optech [relayed][optech ln warning]) and
+  promised a full disclosure in the future, which they have now done
+  with an [email][russell disclosure] by vulnerability discoverer and
+  C-Lightning developer Rusty Russell and a [blog post][lnd stay safe]
+  by LND developers Olaoluwa Osuntokun and Conner Fromknecht.
+
+    Briefly, the issue appears to have been that the implementations did not
+    confirm that channel open transactions paid the correct script,
+    amount, or both.  Because of this, the implementations would accept
+    payments within the channel which they would later be unable to get
+    confirmed onchain, allowing them to be defrauded.  As of this writing,
+    Optech is not aware of any reports that this issue was exploited
+    prior to the warning last month.  Now that the issue has
+    been disclosed, a [PR][BOLTS #676] has been opened to update the
+    specification to note that this check is needed.
+
+- **Optech taproot and schnorr workshop:** last week, Optech held workshops in
+  both San Francisco and New York City teaching developers about the
+  schnorr signature scheme and other parts of the proposed
+  [taproot][bip-taproot] soft fork.  We thank Bryan Bishop for typing an
+  excellent [transcript][workshop transcript] of the NYC workshop.  We
+  are preparing videos and other educational material for release via a
+  blog post in the near future.
+
+## Field report: exchange operation using Bitcoin technologies at BTSE
+
+{% include articles/dong-btse-operation.md %}
+
+## Notable code and documentation changes
+
+*Notable changes this week in [Bitcoin Core][bitcoin core repo],
+[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo],
+[libsecp256k1][libsecp256k1 repo], [Bitcoin Improvement Proposals
+(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].*
+
+- [Bitcoin Core #15558][] changes the number of DNS seeds Bitcoin Core
+  typically queries.  DNS seeds are servers hosted by well-known
+  contributors that return the IP addresses of listening peers (peers
+  that accept incoming connections).  Newly-started nodes query the DNS
+  seeds to find an initial set of peers; then those peers tell the node
+  about other possible peers, with the node saving this information to
+  disk for use later (including after restarts).  Ideally, nodes only
+  ever query DNS seeds once---when they're first started.  Practically,
+  though, they may also query on subsequent startups if none of the
+  saved peers they select responds quickly enough.
+
+    This merge causes Bitcoin Core to only query three DNS seeds at a
+    time rather than all of them.  Three seeds should be enough
+    diversity in sources to ensure the node connects to at least one
+    honest peer (a requirement for Bitcoin security), but it's few enough
+    that not every seed will learn about the querying node if it uses
+    direct DNS resolution.  Which seeds to query are selected randomly
+    from the list hardcoded into Bitcoin Core.
+
+- [LND #3523][] allows users to update the maximum millisat value of
+  HTLCs they'll accept in a particular open channel or across all of
+  their open channels.
+
+- [LND #3505][] limits invoices to 7,092 bytes, the maximum size that
+  will fit in a single QR code.  Larger invoices could cause large
+  amounts of memory to be allocated.  For example, a 1.7 MB invoice
+  tested by the patch author produced about 38.0 MB in allocations.
+
+- [Eclair #1097][] begins deriving channel keys from the funding pubkey,
+  preparing Eclair for using the data loss protection scheme described
+  in [Newsletter #31][dlp footnote].  This only applies to new channels
+  opened after updating to a version of the software implementing this
+  change; old channels are unaffected.
+
+- [C-Lightning #3057][] makes it possible to use postgres as
+  C-Lightning's database manager.
+
+- [C-Lightning #3064][] makes the changes described in [Newsletter
+  #63][ln daily updates] for reducing how often a C-Lightning node will
+  relay channel update announcements from other nodes.  This reduces the
+  amount of gossip bandwidth a node uses.
+
+{% include linkers/issues.md issues="15558,3523,3505,1097,3057,3064,676" %}
+[lnd stay safe]: https://blog.lightning.engineering/security/2019/09/27/cve-2019-12999.html
+[dlp footnote]: /en/newsletters/2019/01/29/#fn:fn-data-loss-protect
+[ln daily updates]: /en/newsletters/2019/09/11/#request-for-comments-on-limiting-ln-gossip-updates-to-once-per-day
+[bip-reconcil]: https://github.com/naumenkogs/bips/blob/bip-reconcil/bip-reconcil.mediawiki
+[reconcil post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017323.html
+[erlay paper]: /en/newsletters/2019/06/05/#erlay-proposed
+[optech ln warning]: /en/newsletters/2019/09/04/#upgrade-ln-implementations
+[workshop transcript]: http://diyhpl.us/wiki/transcripts/bitcoinops/schnorr-taproot-workshop-2019/notes/
+[russell disclosure]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002174.html