|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #9' |
| 3 | +permalink: /en/newsletters/2018/08/21/ |
| 4 | +name: 2018-08-21-newsletter |
| 5 | +type: newsletter |
| 6 | +layout: newsletter |
| 7 | +lang: en |
| 8 | +--- |
| 9 | +This week's newsletter includes the usual dashboard and action items, |
| 10 | +short descriptions of projects Bitcoin Core contributors are working on, |
| 11 | +and a list of notable merges during the past week. |
| 12 | + |
| 13 | +## Action items |
| 14 | + |
| 15 | +- **Allocate time to test Bitcoin Core 0.17 release candidates:** |
| 16 | + in the coming days, Bitcoin Core will begin releasing Release |
| 17 | + Candidates (RCs) for version 0.17.0. Organizations and individual |
| 18 | + users planning to use 0.17 are encouraged to test the RCs to ensure |
| 19 | + that they contain all the features you need and don't have any bugs |
| 20 | + that would affect your operation. There are often multiple RCs for a |
| 21 | + major release such as this, but each RC can theoretically be the last |
| 22 | + RC, so we encourage you to test as early as possible. |
| 23 | + |
| 24 | +## Dashboard items |
| 25 | + |
| 26 | +<!-- TODO: @moneyball --> |
| 27 | + |
| 28 | +## News |
| 29 | + |
| 30 | +No significant news was posted to the bitcoin-dev or lightning-dev |
| 31 | +mailing list last week, so this week's news focuses on some projects |
| 32 | +discussed during the Bitcoin Core weekly meeting. |
| 33 | + |
| 34 | +The Bitcoin Core project, like most free and open source software |
| 35 | +projects, is organized bottom-up with each contributor working on the |
| 36 | +things they think are important rather than top-down with project |
| 37 | +leaders directing the work, so occasionally---as happened last |
| 38 | +week---developers briefly summarize to each other what they're working |
| 39 | +on for the future. It's possible some of these initiatives may fail, |
| 40 | +but it's also possible that some will become future parts of Bitcoin |
| 41 | +Core. Here's a summary of the projects discussed: |
| 42 | + |
| 43 | +- **P2P protocol encryption** being worked on by Jonas Schnelli with |
| 44 | + a short-term focus on unauthenticated encryption in the [BIP151][] |
| 45 | + style (but perhaps using a different mechanism than described in that |
| 46 | + BIP). Peer authentication (e.g. [BIP150][]) is probably further off |
| 47 | + as a criticism against it is that the simplest way of implementing it |
| 48 | + makes it easy to fingerprint particular peers and reduce privacy---so |
| 49 | + a more advanced mechanism is desired for the cases that need it. |
| 50 | + |
| 51 | +- **Output script descriptors enhancements** being worked on by |
| 52 | + Pieter Wuille. The basic idea for this was described in |
| 53 | + [Newsletter #5][news5 news] but Wuille is investigating adding |
| 54 | + support for the ability to "import `and(xpub/...,or(xpub/...,xpub/...))` |
| 55 | + into your wallet as watch-only chain for example and get |
| 56 | + [PSBT][BIP174] to sign for it." This would make adding hardware |
| 57 | + wallet support to Bitcoin Core easier. The support would also be |
| 58 | + compatible with timelocks and hashlocks for use with LN-compatible |
| 59 | + wallets (hardware or software). |
| 60 | + |
| 61 | +- **RISC-V support** being worked on by Wladimir van der Laan. This |
| 62 | + is a CPU architecture rapidly increasing in popularity as a |
| 63 | + potential competitor with ARM-based chipsets, especially among |
| 64 | + hobbyists as the CPU design is open source. A project of |
| 65 | + several developers including Van der Laan's is ultimately |
| 66 | + providing deterministically-generated hashes of Bitcoin Core |
| 67 | + binaries produced using RISC-V cross-compiling to ensure known |
| 68 | + problems and backdoors in the prevalent x86_64 chipsets aren't |
| 69 | + being used to compromise Bitcoin Core binary builds. Van der Laan |
| 70 | + had several recent successes and started "probably the first |
| 71 | + RISC-V bitcoin node in the world" which has already synced part of |
| 72 | + the chain. |
| 73 | + |
| 74 | +- **Bandwidth-efficient set reconciliation protocol for transactions** |
| 75 | + being worked on by Gregory Maxwell, Gleb Naumenko, and Pieter Wuille. |
| 76 | + This may allow a node that has new transactions in its mempool to tell |
| 77 | + a peer about those transactions by communicating an amount of data |
| 78 | + "equal to the expected size of the differences themselves". This is |
| 79 | + in comparison to the current protocol where nodes communicate the |
| 80 | + existence of a transaction by sending a 32 byte hash of it to their |
| 81 | + peers. Well-connected nodes can receive or send more than hundred of |
| 82 | + these notifications for each 224-byte median-sized transaction they |
| 83 | + process, resulting in significant amount of long-lived nodes' |
| 84 | + bandwidth being wasted (about 90% [according][nmnkgl relay] to |
| 85 | + measurements by Naumenko). Maxwell is also working on making it |
| 86 | + possible for a newly-started (or long-disconnected) node to |
| 87 | + efficiently sync its mempool with its peers using this same basic |
| 88 | + mechanism, reducing the requirement for small independent miners to |
| 89 | + maintain expensive high-uptime and well-connected infrastructure. |
| 90 | + |
| 91 | +- **Dandelion protocol DoS-resistant stem routing** being worked on |
| 92 | + by Suhas Daftuar. The [Dandelion protocol][] is expected to make |
| 93 | + it extremely difficult for an adversary to determine the IP |
| 94 | + address of any program that creates a Bitcoin transaction (even if |
| 95 | + they don't use Tor), but the new method of handling unconfirmed |
| 96 | + transactions privately for a time during the "stem" phase has to |
| 97 | + be secured against attacks that could waste node bandwidth and |
| 98 | + memory. |
| 99 | + |
| 100 | +For additional details, please see the [conversation log][2018-08-16 |
| 101 | +meeting log]. |
| 102 | + |
| 103 | +## Notable commits |
| 104 | + |
| 105 | +*Notable commits this week in [Bitcoin Core][core commits], [LND][lnd |
| 106 | +commits], and [C-lightning][cl commits].* |
| 107 | + |
| 108 | +{% comment %}<!-- IMO, c-lightning only had 6 commits this week, mostly |
| 109 | +minor doc updates, so no news for them. I'm still leaving them |
| 110 | +mentioned above for easy copy/paste next week. -harding -->{% endcomment %} |
| 111 | + |
| 112 | +{% include linkers/github-log.md |
| 113 | + refname="core commits" |
| 114 | + repo="bitcoin/bitcoin" |
| 115 | + start="1b04b55f2d22078ca79cd38fc1078e15fa9cbe94" |
| 116 | + end="df660aa7717a6f4784e90535a13a95d82244565a" |
| 117 | +%} |
| 118 | +{% include linkers/github-log.md |
| 119 | + refname="lnd commits" |
| 120 | + repo="lightningnetwork/lnd" |
| 121 | + start="6989316b11c51922b4c6ae3507ac06680ec530b9" |
| 122 | + end="3f5ec993300e38369110706ac83301b8875500d6" |
| 123 | +%} |
| 124 | +{% include linkers/github-log.md |
| 125 | + refname="cl commits" |
| 126 | + repo="ElementsProject/lightning" |
| 127 | + start="a97955845ff43d4780b33a7301695db33823c57c" |
| 128 | + end="80a875a9a54e26c2ea4c90aee8fe606ddcc27c55" |
| 129 | +%} |
| 130 | + |
| 131 | +- Bitcoin Core 0.17 branched: this allows developers to focus on |
| 132 | + ensuring stability, translation completeness, and other release |
| 133 | + features on that branch while development of new features continues on |
| 134 | + the master branch. This Notable Commits section only focuses on the |
| 135 | + master development branch of each project, so commits mentioned from |
| 136 | + this point forward are much less likely to be included in the 0.17 |
| 137 | + version of Bitcoin Core and should not be expected before the 0.18 |
| 138 | + version. |
| 139 | + |
| 140 | +- [Bitcoin Core #13917][] and [Bitcoin Core #13960][] improve the |
| 141 | + [BIP174][] Partially-Signed Bitcoin Transaction (PBST) handling in |
| 142 | + ambiguous situations. |
| 143 | + |
| 144 | +- [Bitcoin Core #11526][] makes it much easier to build Bitcoin Core |
| 145 | + with Microsoft Visual Studio 2017, including being able to use the Visual |
| 146 | + Studio debugger. |
| 147 | + |
| 148 | +- [Bitcoin Core #13918][] provides the 10th, 25th, 50th, 75th, and 90th |
| 149 | + percentile feerates for a historic block with the `getblockstats` RPC |
| 150 | + introduced to the master development branch a couple months ago. |
| 151 | + |
| 152 | +- [LND #1693][] allows LND's autopilot funding mechanism to optionally |
| 153 | + use unconfirmed outputs for funding transactions. This can be a bit |
| 154 | + riskier for the user if you're spending money from a third party that |
| 155 | + you haven't finished receiving yet, but it can completely safely |
| 156 | + remove a common delay when transferring money from one wallet you |
| 157 | + control to a LN-compatible wallet you want to use. |
| 158 | + |
| 159 | + Note: this was only the most notable of several minor (but useful) |
| 160 | + improvements to the autopilot feature merged this week. |
| 161 | + |
| 162 | +- [LND #1460][] the payinvoice and sendpayment commands now require |
| 163 | + extra confirmation, although this can be bypassed with the `--force` |
| 164 | + or `-f` parameter. |
| 165 | + |
| 166 | +{% include references.md %} |
| 167 | +{% include linkers/issues.md issues="13917,11526,13918,1693,1460,13960" %} |
| 168 | + |
| 169 | +[news5 news]: {{news5}}#news |
| 170 | +[dandelion protocol]: https://arxiv.org/abs/1701.04439 |
| 171 | +[2018-08-16 meeting log]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-16-19.03.log.html |
| 172 | +[nmnkgl relay]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015863.html |
0 commit comments