|
| 1 | +--- |
| 2 | +title: "Bitcoin Optech Newsletter #18" |
| 3 | +permalink: /en/newsletters/2018/10/23/ |
| 4 | +name: 2018-10-23-newsletter |
| 5 | +type: newsletter |
| 6 | +layout: newsletter |
| 7 | +lang: en |
| 8 | +--- |
| 9 | +This week's newsletter contains a warning about communicating with |
| 10 | +Bitcoin nodes using RPC over unencrypted connections, links to two new papers |
| 11 | +about creating fast multiparty ECDSA keys and signatures that could reduce |
| 12 | +transaction fees for multisig users, and lists some notable merges from |
| 13 | +popular Bitcoin infrastructure projects. |
| 14 | + |
| 15 | +## Action items |
| 16 | + |
| 17 | +- **Close open RPC ports on nodes:** about 13% of Bitcoin |
| 18 | + nodes appear to have their RPC ports open on unencrypted public |
| 19 | + connections, putting users of those nodes at risk. See the full news |
| 20 | + item below for additional details about the risk and recommended |
| 21 | + solutions. |
| 22 | + |
| 23 | +## News |
| 24 | + |
| 25 | +- **Over 1,100 listening nodes have open RPC ports:** It was recently |
| 26 | + mentioned in the #bitcoin-core-dev IRC chatroom that many Bitcoin |
| 27 | + nodes on the network had their RPC port open. Optech |
| 28 | + [investigated][port scan summary] and found that about 1,100 of the |
| 29 | + 8,400 listening nodes with an IPv4 address did indeed have port 8332 |
| 30 | + open (13.2%). |
| 31 | + |
| 32 | + This may indicate that many node operators are unaware that RPC |
| 33 | + communication over the Internet is completely insecure by default |
| 34 | + and exposes your node to multiple attacks that could cost you money |
| 35 | + even if you've disabled the wallet on your node. RPC communication |
| 36 | + is not encrypted, so any eavesdropper observing even a single request |
| 37 | + to your server can steal your authentication credentials and use them |
| 38 | + to run commands that empty your wallet (if you have one), trick your |
| 39 | + node into using a fork of the block chain with almost no |
| 40 | + proof-of-work security, overwrite arbitrary files on your |
| 41 | + filesystem, or do other damage. Even if you never connect to your |
| 42 | + node over the Internet, having an open RPC port carries a risk that |
| 43 | + an attacker will guess your login credentials. |
| 44 | + |
| 45 | + By default, nodes do not accept connections to RPC from any other |
| 46 | + computer---you have to enable a configuration option to allow RPC |
| 47 | + connections. To determine whether you've enabled this feature, |
| 48 | + check your Bitcoin configuration file and startup parameters for the |
| 49 | + `rpcallowip` parameter. If this option is present, you should |
| 50 | + remove it and restart your node unless you have a good reason to |
| 51 | + believe all RPC connections to your node are encrypted or are |
| 52 | + exclusive to a trusted private network. If you want to test your |
| 53 | + node remotely for an open RPC port, you can run the following |
| 54 | + [nmap][] command after replacing *ADDRESS* with the IP address of |
| 55 | + your node: |
| 56 | + |
| 57 | + nmap -Pn -p 8332 ADDRESS |
| 58 | + |
| 59 | + If the result in the *state* field is "open", you should follow the |
| 60 | + instructions above to remove the `rpcallowip` parameter. If the |
| 61 | + result is either "closed" or "filtered", your node is safe unless |
| 62 | + you've set a custom RPC port or otherwise have enabled a customized |
| 63 | + configuration. |
| 64 | + |
| 65 | + A [PR][Bitcoin Core #14532] has been opened to Bitcoin Core to make |
| 66 | + it harder for users to configure their node this way and to print |
| 67 | + additional warnings about enabling such behavior. |
| 68 | + |
| 69 | +- **Two papers published on fast multiparty ECDSA:** in multiparty |
| 70 | + ECDSA, two or more parties can cooperatively (but trustlessly) create |
| 71 | + a single public key that requires the parties also cooperate to create |
| 72 | + a single valid signature for that pubkey. If the parties agree before |
| 73 | + creating the pubkey, they may also make it possible for fewer than all |
| 74 | + of them to sign, e.g. 2-of-3 of them must cooperate to sign. This can |
| 75 | + be much more efficient than Bitcoin's current multisig, which requires |
| 76 | + placing *m* signatures and *n* pubkeys into transactions for m-of-n |
| 77 | + security, whereas multiparty ECDSA would always require only one |
| 78 | + signature and one pubkey for any *m* or *n*. The techniques |
| 79 | + underlying multiparty ECDSA may also be used with scriptless scripts |
| 80 | + as described in [Newsletter #16][news16 mpecdsa]. |
| 81 | + |
| 82 | + Best of all, these advantages are available immediately to anyone |
| 83 | + who implements them because the Bitcoin protocol's current support |
| 84 | + for ECDSA means it also supports pure ECDSA multiparty schemes as |
| 85 | + well. No changes are required to the consensus rules, the P2P |
| 86 | + protocol, address formats, or any other shared resource. All you |
| 87 | + need are two wallets that both implement multiparty ECDSA key |
| 88 | + generation and signing. This can make the scheme appealing to |
| 89 | + existing services that gain from the additional security of Bitcoin |
| 90 | + multisig but lose from having to pay additional transaction fees for |
| 91 | + the extra pubkeys and signatures. |
| 92 | + |
| 93 | + It will likely take time for experts to review these papers, |
| 94 | + evaluate their security properties, and consider implementing |
| 95 | + them---and some experts are already busy working on implementing a |
| 96 | + consensus change proposal that would enable a Schnorr signature |
| 97 | + scheme that would also provide for multiparty pubkeys and signatures |
| 98 | + (and which also provides multiple other benefits). |
| 99 | + |
| 100 | + - [Fast Multiparty Threshold ECDSA with Fast Trustless Setup][mpecdsa goldfeder] by Rosario Gennaro and Steven Goldfeder |
| 101 | + |
| 102 | + - [Fast Secure Multiparty ECDSA with Practical Distributed Key Generation and Applications to Cryptocurrency Custody][mpecdsa lindell] by Yehuda Lindell, Ariel Nof, and Samuel Ranellucci |
| 103 | + |
| 104 | +[mpecdsa goldfeder]: http://stevengoldfeder.com/papers/GG18.pdf |
| 105 | +[mpecdsa lindell]: https://eprint.iacr.org/2018/987.pdf |
| 106 | + |
| 107 | +## Notable merges |
| 108 | + |
| 109 | +*Notable code changes this week in [Bitcoin Core][core commits], |
| 110 | +[LND][lnd commits], [C-lightning][cl commits], and [libsecp256k1][secp |
| 111 | +commits].* |
| 112 | + |
| 113 | +{% include linkers/github-log.md |
| 114 | + refname="core commits" |
| 115 | + repo="bitcoin/bitcoin" |
| 116 | + start="be992701b018f256db6d64786624be4cb60d8975" |
| 117 | + end="5c25409d6851182c5e351720cee36812c229b77a" |
| 118 | +%} |
| 119 | +{% include linkers/github-log.md |
| 120 | + refname="lnd commits" |
| 121 | + repo="lightningnetwork/lnd" |
| 122 | + start="e5b84cfadab56037ae3957e704b3e570c9368297" |
| 123 | + end="6b19df162a161079ab794162b45e8f4c7bb8beec" |
| 124 | +%} |
| 125 | +{% include linkers/github-log.md |
| 126 | + refname="cl commits" |
| 127 | + repo="ElementsProject/lightning" |
| 128 | + start="a44491fff0ccd7bde20661eecf88bf136db5f6e6" |
| 129 | + end="7eec2253e962e524f8fd92b74f411f0b99706ba9" |
| 130 | +%} |
| 131 | +{% include linkers/github-log.md |
| 132 | + refname="secp commits" |
| 133 | + repo="bitcoin-core/secp256k1" |
| 134 | + start="1e6f1f5ad5e7f1e3ef79313ec02023902bf8175c" |
| 135 | + end="1086fda4c1975d0cad8d3cad96794a64ec12dca4" |
| 136 | +%} |
| 137 | + |
| 138 | +- [Bitcoin Core #14291][]: For use with Bitcoin Core's multiwallet mode, |
| 139 | + a new `listwalletdir` RPC can list all available wallets in the wallet |
| 140 | + directory. |
| 141 | + |
| 142 | +- [Bitcoin Core #14424][]: Fixes a likely regression in 0.17.0 for |
| 143 | + watch-only wallets that require users to import their public keys for |
| 144 | + multisig scripts (rather than just importing the script) in order for |
| 145 | + Bitcoin Core to attempt spending the script using RPCs such as |
| 146 | + [fundrawtransaction][rpc fundrawtransaction] with the |
| 147 | + `includeWatching` flag. This PR has been tagged for backport to |
| 148 | + 0.17.1 whenever work on that should start. A workaround for 0.17.0 |
| 149 | + users is described in [Bitcoin Core #14415][]. |
| 150 | + |
| 151 | +- [LND #1978][], [#2062][LND #2062], [#2063][LND #2063]: new functions |
| 152 | + for creating sweep transactions have been added, replacing functions |
| 153 | + from the UTXO Nursery that is "dedicated to incubating time-locked |
| 154 | + outputs." These new functions accept a list of outputs, generate a |
| 155 | + transaction for them with an appropriate fee that pays back into the |
| 156 | + same wallet (not a reused address), and signs the transaction. The |
| 157 | + sweep transactions set nLockTime to the current block chain height, |
| 158 | + implementing the same anti-fee sniping technique adopted by other |
| 159 | + wallets such as Bitcoin Core and GreenAddress, helping to discourage |
| 160 | + chain reorgs and allowing LND's sweep transactions to blend in with |
| 161 | + those other wallets' transactions. |
| 162 | + |
| 163 | +- [LND #2051][]: ensures that an attacker who chooses to lock his funds |
| 164 | + for a very long period of time (up to about 10,000 years) can't cause |
| 165 | + your node to lock the same amount of your funds for the same length of |
| 166 | + time. With this patch, your node will reject requests from an |
| 167 | + attacker to lock his funds and your funds for a period of more than |
| 168 | + 5,000 blocks (about 5 weeks). |
| 169 | + |
| 170 | +- [C-Lightning #2033][]: provides a new `listforwards` RPC that lists |
| 171 | + forwarded payments (payments made in payment channels passing through |
| 172 | + your node), including providing information about the amount of fees |
| 173 | + you earned from being part of the forwarding path. Additionally, the |
| 174 | + `getstats` RPC now returns a new field, `msatoshis_fees_collected`, |
| 175 | + containing the total amount of fees you've earned. |
| 176 | + |
| 177 | +- [Libsecp256k1 #354][]: allows callers of the ECDH functions to use a |
| 178 | + custom hash function. The Bitcoin consensus protocol doesn't use |
| 179 | + ECDH, but it is used elsewhere with the same curve parameters as |
| 180 | + Bitcoin in schemes described in BIPs [47][BIP47], [75][BIP75], and |
| 181 | + [151][BIP151] (old draft); Lightning BOLTs [4][BOLT4] and [8][BOLT8]; |
| 182 | + and variously elsewhere such as [Bitmessage][], [ElementsProject][] |
| 183 | + side chains using confidential transactions and assets, and some |
| 184 | + Ethereum smart contracts. Some of these schemes can't use the default |
| 185 | + hash function libsecp256k1 uses, so this merged PR allows passing a |
| 186 | + pointer to a custom hash function that will be used instead of the |
| 187 | + default and which permits passing arbitrary data to that function. |
| 188 | + |
| 189 | +{% include references.md %} |
| 190 | +{% include linkers/issues.md issues="14291,14424,1978,2062,2063,2051,2033,354,14415,14531" %} |
| 191 | + |
| 192 | +[bitmessage]: https://bitmessage.org/wiki/Encryption |
| 193 | +[elementsproject]: https://elementsproject.org/ |
| 194 | +[port scan summary]: https://gist.github.com/harding/bf6115a567e80ba5e737242b91c97db2 |
| 195 | +[nmap]: https://nmap.org/download.html |
| 196 | +[news16 mpecdsa]: {{news16}}#multiparty-ecdsa-for-scriptless-lightning-network-payment-channels |
0 commit comments