From 2feedbf776740b840fe626c734c551c39217835c Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Mon, 22 Oct 2018 11:18:49 -0400 Subject: [PATCH 1/2] Newsletters: add #18 (2018-10-23) --- _includes/linkers/issues.md | 3 +- _includes/references.md | 8 +- .../en/newsletters/2018-10-23-newsletter.md | 196 ++++++++++++++++++ 3 files changed, 205 insertions(+), 2 deletions(-) create mode 100644 _posts/en/newsletters/2018-10-23-newsletter.md diff --git a/_includes/linkers/issues.md b/_includes/linkers/issues.md index 1f2b5fb212..8ad6983f00 100644 --- a/_includes/linkers/issues.md +++ b/_includes/linkers/issues.md @@ -1,7 +1,7 @@ {% capture /dev/null %} {% endcomment %} [BIP21]: https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki [BIP37]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki +[BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki [BIP61]: https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki [BIP70]: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki +[BIP75]: https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki [BIP118]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki [BIP125]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki [BIP133]: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki @@ -26,7 +28,9 @@ {% comment %}{% endcomment %} [BOLT2]: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md +[BOLT4]: https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md [BOLT7]: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md +[BOLT8]: https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md [BOLT11]: https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md {% comment %}{% endcomment %} @@ -56,12 +60,14 @@ [newsletter #11]: {{news11}} {% assign news12 = "/en/newsletters/2018/09/11/" %} [newsletter #12]: {{news12}} +{% assign news16 = "/en/newsletters/2018/10/09/" %} +[newsletter #16]: {{news16}} {% comment %} {% endcomment %} -{% assign rpc_prefix = "https://bitcoincore.org/en/doc/0.16.3/rpc" %} +{% assign rpc_prefix = "https://bitcoincore.org/en/doc/0.17.0/rpc" %} [rpc abandontransaction]: {{rpc_prefix}}/wallet/abandontransaction/ [rpc fundrawtransaction]: {{rpc_prefix}}/rawtransactions/fundrawtransaction/ [rpc getpeerinfo]: {{rpc_prefix}}/network/getpeerinfo/ diff --git a/_posts/en/newsletters/2018-10-23-newsletter.md b/_posts/en/newsletters/2018-10-23-newsletter.md new file mode 100644 index 0000000000..782c06eec8 --- /dev/null +++ b/_posts/en/newsletters/2018-10-23-newsletter.md @@ -0,0 +1,196 @@ +--- +title: "Bitcoin Optech Newsletter #18" +permalink: /en/newsletters/2018/10/23/ +name: 2018-10-23-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter contains a warning about communicating with +Bitcoin nodes using RPC over unencrypted connections, links to two new papers +about creating fast multiparty ECDSA keys and signatures that could reduce +transaction fees for multisig users, and lists some notable merges from +popular Bitcoin infrastructure projects. + +## Action items + +- **Close open RPC ports on nodes:** about 13% of Bitcoin + nodes appear to have their RPC ports open on unencrypted public + connections, putting users of those nodes at risk. See the full news + item below for additional details about the risk and recommended + solutions. + +## News + +- **Over 1,100 listening nodes have open RPC ports:** It was recently + mentioned in the #bitcoin-core-dev IRC chatroom that many Bitcoin + nodes on the network had their RPC port open. Optech + [investigated][port scan summary] and found that about 1,100 of the + 8,400 listening nodes with an IPv4 address did indeed have port 8332 + open (13.2%). + + This may indicate that many node operators are unaware that RPC + communication over the Internet is completely insecure by default + and exposes your node to multiple attacks that could cost you money + even if you've disabled the wallet on your node. RPC communication + is not encrypted, so any eavesdropper observing even a single request + to your server can steal your authentication credentials and use them + to run commands that empty your wallet (if you have one), trick your + node into using a fork of the block chain with almost no + proof-of-work security, overwrite arbitrary files on your + filesystem, or do other damage. Even if you never connect to your + node over the Internet, having an open RPC port carries a risk that + an attacker will guess your login credentials. + + By default, nodes do not accept connections to RPC from any other + computer---you have to enable a configuration option to allow RPC + connections. To determine whether you've enabled this feature, + check your Bitcoin configuration file and startup parameters for the + `rpcallowip` parameter. If this option is present, you should + remove it and restart your node unless you have a good reason to + believe all RPC connections to your node are encrypted or are + exclusive to a trusted private network. If you want to test your + node remotely for an open RPC port, you can run the following + [nmap][] command after replacing *ADDRESS* with the IP address of + your node: + + nmap -Pn -p 8332 ADDRESS + + If the result in the *state* field is "open", you should follow the + instructions above to remove the `rpcallowip` parameter. If the + result is either "closed" or "filtered", your node is safe unless + you've set a custom RPC port or otherwise have enabled a customized + configuration. + + A [PR][Bitcoin Core #14532] has been opened to Bitcoin Core to make + it harder for users to configure their node this way and to print + additional warnings about enabling such behavior. + +- **Two papers published on fast multiparty ECDSA:** in multiparty + ECDSA, two or more parties can cooperatively (but trustlessly) create + a single public key that requires the parties also cooperate to create + a single valid signature for that pubkey. If the parties agree before + creating the pubkey, they may also make it possible for fewer than all + of them to sign, e.g. 2-of-3 of them must cooperate to sign. This can + be much more efficient than Bitcoin's current multisig, which requires + placing *m* signatures and *n* pubkeys into transactions for m-of-n + security, whereas multiparty ECDSA would always require only one + signature and one pubkey for any *m* or *n*. The techniques + underlying multiparty ECDSA may also be used with scriptless scripts + as described in [Newsletter #16][news16 mpecdsa]. + + Best of all, these advantages are available immediately to anyone + who implements them because the Bitcoin protocol's current support + for ECDSA means it also supports pure ECDSA multiparty schemes as + well. No changes are required to the consensus rules, the P2P + protocol, address formats, or any other shared resource. All you + need are two wallets that both implement multiparty ECDSA key + generation and signing. This can make the scheme appealing to + existing services that gain from the additional security of Bitcoin + multisig but lose from having to pay additional transaction fees for + the extra pubkeys and signatures. + + It will likely take time for experts to review these papers, + evaluate their security properties, and consider implementing + them---and some experts are already busy working on implementing a + consensus change proposal that would enable a Schnorr signature + scheme that would also provide for multiparty pubkeys and signatures + (and which also provides multiple other benefits). + + - [Fast Multiparty Threshold ECDSA with Fast Trustless Setup][mpecdsa goldfeder] by Rosario Gennaro and Steven Goldfeder + + - [Fast Secure Multiparty ECDSA with Practical Distributed Key Generation and Applications to Cryptocurrency Custody][mpecdsa lindell] by Yehuda Lindell, Ariel Nof, and Samuel Ranellucci + +[mpecdsa goldfeder]: http://stevengoldfeder.com/papers/GG18.pdf +[mpecdsa lindell]: https://eprint.iacr.org/2018/987.pdf + +## Notable merges + +*Notable code changes this week in [Bitcoin Core][core commits], +[LND][lnd commits], [C-lightning][cl commits], and [libsecp256k1][secp +commits].* + +{% include linkers/github-log.md + refname="core commits" + repo="bitcoin/bitcoin" + start="be992701b018f256db6d64786624be4cb60d8975" + end="5c25409d6851182c5e351720cee36812c229b77a" +%} +{% include linkers/github-log.md + refname="lnd commits" + repo="lightningnetwork/lnd" + start="e5b84cfadab56037ae3957e704b3e570c9368297" + end="6b19df162a161079ab794162b45e8f4c7bb8beec" +%} +{% include linkers/github-log.md + refname="cl commits" + repo="ElementsProject/lightning" + start="a44491fff0ccd7bde20661eecf88bf136db5f6e6" + end="7eec2253e962e524f8fd92b74f411f0b99706ba9" +%} +{% include linkers/github-log.md + refname="secp commits" + repo="bitcoin-core/secp256k1" + start="1e6f1f5ad5e7f1e3ef79313ec02023902bf8175c" + end="1086fda4c1975d0cad8d3cad96794a64ec12dca4" +%} + +- [Bitcoin Core #14291][]: For use with Bitcoin Core's multiwallet mode, + a new `listwalletdir` RPC can list all available wallets in the wallet + directory. + +- [Bitcoin Core #14424][]: Fixes a likely regression in 0.17.0 for + watch-only wallets that require users to import their public keys for + multisig scripts (rather than just importing the script) in order for + Bitcoin Core to attempt spending the script using RPCs such as + [fundrawtransaction][rpc fundrawtransaction] with the + `includeWatching` flag. This PR has been tagged for backport to + 0.17.1 whenever work on that should start. A workaround for 0.17.0 + users is described in [Bitcoin Core #14415][]. + +- [LND #1978][], [#2062][LND #2062], [#2063][LND #2063]: new functions + for creating sweep transactions have been added, replacing functions + from the UTXO Nursery that is "dedicated to incubating time-locked + outputs." These new functions accept a list of outputs, generate a + transaction for them with an appropriate fee that pays back into the + same wallet (not a reused address), and signs the transaction. The + sweep transactions set nLockTime to the current block chain height, + implementing the same anti-fee sniping technique adopted by other + wallets such as Bitcoin Core and GreenAddress, helping to discourage + chain reorgs and allowing LND's sweep transactions to blend in with + those other wallets' transactions. + +- [LND #2051][]: ensures that an attacker who chooses to lock his funds + for a very long period of time (up to about 10,000 years) can't cause + your node to lock the same amount of your funds for the same length of + time. With this patch, your node will reject requests from an + attacker to lock his funds and your funds for a period of more than + 5,000 blocks (about 5 weeks). + +- [C-Lightning #2033][]: provides a new `listforwards` RPC that lists + forwarded payments (payments made in payment channels passing through + your node), including providing information about the amount of fees + you earned from being part of the forwarding path. Additionally, the + `getstats` RPC now returns a new field, `msatoshis_fees_collected`, + containing the total amount of fees you've earned. + +- [Libsecp256k1 #354][]: allows callers of the ECDH functions to use a + custom hash function. The Bitcoin consensus protocol doesn't use + ECDH, but it is used elsewhere with the same curve parameters as + Bitcoin in schemes described in BIPs [47][BIP47], [75][BIP75], and + [151][BIP151] (old draft); Lightning BOLTs [4][BOLT4] and [8][BOLT8]; + and variously elsewhere such as [Bitmessage][], [ElementsProject][] + side chains using confidential transactions and assets, and some + Ethereum smart contracts. Some of these schemes can't use the default + hash function libsecp256k1 uses, so this merged PR allows passing a + pointer to a custom hash function that will be used instead of the + default and which permits passing arbitrary data to that function. + +{% include references.md %} +{% include linkers/issues.md issues="14291,14424,1978,2062,2063,2051,2033,354,14415,14531" %} + +[bitmessage]: https://bitmessage.org/wiki/Encryption +[elementsproject]: https://elementsproject.org/ +[port scan summary]: https://gist.github.com/harding/bf6115a567e80ba5e737242b91c97db2 +[nmap]: https://nmap.org/download.html +[news16 mpecdsa]: {{news16}}#multiparty-ecdsa-for-scriptless-lightning-network-payment-channels From 0efd8592a0faffe0162aa85324d475e8f03806ab Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Mon, 22 Oct 2018 17:58:42 -0400 Subject: [PATCH 2/2] Newsletter #18 improvements --- _posts/en/newsletters/2018-10-23-newsletter.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_posts/en/newsletters/2018-10-23-newsletter.md b/_posts/en/newsletters/2018-10-23-newsletter.md index 782c06eec8..d15cd1602e 100644 --- a/_posts/en/newsletters/2018-10-23-newsletter.md +++ b/_posts/en/newsletters/2018-10-23-newsletter.md @@ -73,9 +73,9 @@ popular Bitcoin infrastructure projects. creating the pubkey, they may also make it possible for fewer than all of them to sign, e.g. 2-of-3 of them must cooperate to sign. This can be much more efficient than Bitcoin's current multisig, which requires - placing *m* signatures and *n* pubkeys into transactions for m-of-n + placing *k* signatures and *n* pubkeys into transactions for k-of-n security, whereas multiparty ECDSA would always require only one - signature and one pubkey for any *m* or *n*. The techniques + signature and one pubkey for any *k* or *n*. The techniques underlying multiparty ECDSA may also be used with scriptless scripts as described in [Newsletter #16][news16 mpecdsa]. @@ -84,7 +84,7 @@ popular Bitcoin infrastructure projects. for ECDSA means it also supports pure ECDSA multiparty schemes as well. No changes are required to the consensus rules, the P2P protocol, address formats, or any other shared resource. All you - need are two wallets that both implement multiparty ECDSA key + need are two or more wallets that implement multiparty ECDSA key generation and signing. This can make the scheme appealing to existing services that gain from the additional security of Bitcoin multisig but lose from having to pay additional transaction fees for @@ -93,9 +93,9 @@ popular Bitcoin infrastructure projects. It will likely take time for experts to review these papers, evaluate their security properties, and consider implementing them---and some experts are already busy working on implementing a - consensus change proposal that would enable a Schnorr signature - scheme that would also provide for multiparty pubkeys and signatures - (and which also provides multiple other benefits). + consensus change proposal to enable a Schnorr signature + scheme that can simplify generation of multiparty pubkeys and signatures + and also provide multiple other benefits. - [Fast Multiparty Threshold ECDSA with Fast Trustless Setup][mpecdsa goldfeder] by Rosario Gennaro and Steven Goldfeder