Skip to content

Commit fc90f77

Browse files
hardingharding
committed
Meetings: add 2018-06-14
1 parent 245ad61 commit fc90f77

File tree

2 files changed

+337
-1
lines changed

2 files changed

+337
-1
lines changed

‎_posts/en/meetings/2018-06-14-meeting.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -67,7 +67,7 @@ to spend---to simultaneously improve privacy, reduce transaction size,
6767
and reduce fees. The current selection protocol starts with a
6868
Branch-and-Bound (BnB) algorithm that tries to find a match between the
6969
inputs available and the amount being sent. If that doesn't work, a
70-
fallback algorithm is needed. A Single-Random Draw (SRD) algorithm
70+
fallback algorithm is needed. A Single-Random-Draw (SRD) algorithm
7171
randomly adds additional inputs to a partial transaction until the sum
7272
of the inputs is equal to or greater than the amount being spent
7373
(including fees).

‎_posts/en/meetings/2018-06-21-meeting.md

Lines changed: 336 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,336 @@
1+
---
2+
title: IRC meeting summary for 2018-06-21
3+
lang: en
4+
permalink: /en/meetings/2018/06/21/
5+
name: 2016-06-21-meeting
6+
layout: page
7+
type: meetings
8+
version: 1
9+
---
10+
{% include _toc.html %}
11+
{% include _references.md %}
12+
13+
- View this week's log on [BotBot.me][bbm log] or [MeetBot][mb log]
14+
- [Meeting minutes by MeetBot][mb minutes]
15+
16+
---
17+
18+
Topics discussed during this weekly meeting included what pull requests
19+
members of the project would like reviewers to focus on during the
20+
upcoming week, when to disclose known DoS vulnerabilities for versions
21+
of Bitcoin Core 0.12.0 and earlier related to the signed alerts system
22+
along with the mechanism to initiate the DoS attacks (Nakamoto's alert
23+
signing key), changes to hosting for the bitcoin-dev mailing list, how
24+
inputs are chosen to be included in new transactions by default, dealing
25+
with the loading of new wallets in multiwallet mode, improved private
26+
key backup and recovery, and continuing work towards creating a
27+
machine-writeable configuration file.
28+
29+
## Review blockers [high priority for review]
30+
31+
**Background:** each meeting, Bitcoin Core developers discuss which Pull
32+
Requests (PRs) the meeting participants think most need review in the
33+
upcoming week. Some of these PRs are related to code that contributors
34+
especially want to see in the next release; others are PRs that are
35+
blocking further work or which require significant maintenance (rebasing)
36+
to keep in a pending state. Any capable reviewers are encouraged to
37+
visit the project's list of [current high-priority
38+
PRs][].
39+
40+
**Discussion ([log][log hipri]):** Pieter Wuille listed the three PRs
41+
currently on the list ([#13062][], [#12196][], and [#13425][]) and asked
42+
if anyone wanted to nominate additional PRs. João Barbosa suggested
43+
[#13100][], which adds a menu entry to open a wallet, but it's not quite
44+
ready yet, so Wuille will wait until it is before adding it.
45+
46+
## Alert key [public disclosure]
47+
48+
**Background:** In 2010, someone created a protocol-valid block that
49+
[created over 184 billion bitcoins][value overflow incident]. Satoshi
50+
Nakamoto encouraged users to stop mining and soon published an updated
51+
version of Bitcoin that corrected the behavior in a retroactive soft
52+
fork, but he subsequently added a mechanism to the Bitcoin software that
53+
allowed him to sign "alert" messages that could directly notify node
54+
operators of problems and even, by default, shut down some node
55+
functions that might cause monetary loss. In Nakamoto's [last
56+
post][nakamoto last post] to the BitcoinTalk.org forum, he wrote,
57+
58+
> "safe mode" alerts was a temporary measure after the 0.3.9 overflow
59+
> bug. We can say all we want that users can just run with
60+
> "-disablesafemode", but it's better just not to have it for the sake
61+
> of appearances. It was never intended as a long term feature. Safe
62+
> mode can still be triggered by seeing a longer (greater total PoW)
63+
> invalid block chain.
64+
65+
Over time, subsequent Bitcoin Core developers steadily deprecated,
66+
disabled, and removed the alert feature, turning it [off by
67+
default][alerts off] in version 0.12.1, [removing it entirely][alerts
68+
removed] in version 0.13.0, hard coding a [final alert][final alert]
69+
into version 0.14.0, and (in November 2016) announcing the [pending
70+
public disclosure][alert key disclosure] of the alert-signing key
71+
created by Nakamoto. The disclosure was delayed indefinitely upon
72+
discovery of Denial-of-Service (DoS) vulnerabilities related to the alert
73+
mechanism in versions of Bitcoin Core below 0.12.1, as discussed in the
74+
[9 March 2017 weekly meeting][], that affected approximately 2,600 nodes
75+
at the time.
76+
77+
**Discussion ([log][log alert]):** Bryan Bishop requested and introduced
78+
the topic, "I'm thinking of releasing the private [alert signing] key.
79+
[It] would be nice to get that out there and remove that liability.
80+
I'm particularly interested in hearing from others who have good reason
81+
not to reveal the key. In the year-plus since [planned public
82+
disclosure] was announced, I don't think much has been raised."
83+
84+
Gregory Maxwell said, "All supported versions [of Bitcoin Core] have
85+
[the signed alert system] gone completely, so that sounds pretty good
86+
for a release now---unless pre-0.12 nodes are still popular, and I don't
87+
believe they are."
88+
89+
Luke Dashjr cited his [node scanning system][dashjr addr scanner] to say
90+
that 3% of nodes were running version 0.12 and "0.61% 'other' versions,
91+
which includes everything before 0.12." Pieter Wuille found similar
92+
statistics using the [Bitnodes scanning system][], which uses a
93+
different scanning method.
94+
95+
Regarding the vulnerabilities related to the signed alert messages in
96+
old versions of Bitcoin Core, Maxwell said, "I doubt we know all the
97+
vulnerabilities. I know of at least two, but I stopped looking."
98+
Andrew Chow said he knew of three.
99+
100+
The DoS vulnerabilities affect not just Bitcoin but also altcoins that have
101+
copied Bitcoin Core's code and are currently using old versions. When
102+
the vulnerabilities are disclosed, anyone with the alert-signing key for
103+
an altcoin will be able to execute those DoS attacks. In discussing
104+
this, Chow said, "[but] if the altcoins have better control of their
105+
alert key, publishing the Bitcoin one and the related vulnerabilities
106+
shouldn't be a problem."
107+
108+
**Conclusion:** no explicit conclusion. Bishop seems likely to continue
109+
to work towards responsibly disclosing the alert key and (probably)
110+
vulnerabilities related to it. No one objected to this, although Matt
111+
Corallo did say he thought there was "limited utility to releasing the
112+
alert key."
113+
114+
## Bitcoin-dev mailing list
115+
116+
**Background:** the bitcoin-dev (Bitcoin development) mailing list has
117+
been hosted at lists.linuxfoundation.org for the past several years.
118+
119+
**Discussion ([log][log dev ml]):** Bryan Bishop requested and
120+
introduced the topic: "Linux Foundation is migrating away from the email
121+
protocol and will no longer be hosting the bitcoin-dev mailing list.
122+
There is a migration plan, but it's under investigation still."
123+
124+
There was some brief discussion about current delivery problems with the
125+
list, an expression of hope that existing URLs to old posts remain
126+
valid, and other migration concerns.
127+
128+
**Conclusion:** Bishop will send an email to the mailing list, hopefully
129+
before migration to a new host domain, with additional details once he
130+
has them.
131+
132+
## Coin selection
133+
134+
**Background:** several developers have been working on improving
135+
Bitcoin Core's coin selection---how it chooses which bitcoins (inputs)
136+
to spend---to simultaneously improve privacy, reduce transaction size,
137+
and reduce fees. The current selection protocol starts with a
138+
Branch-and-Bound (BnB) algorithm that tries to find a match between the
139+
inputs available and the amount being sent. If that doesn't work, a
140+
fallback algorithm is needed. A Single-Random-Draw (SRD) algorithm
141+
randomly adds additional inputs to a partial transaction until the sum
142+
of the inputs is equal to or greater than the amount being spent
143+
(including fees).
144+
145+
This week's discussion is a continuation of [last week's discussion][srd
146+
2018-06-14] about the same topic.
147+
148+
**Discussion ([log][log coin selection]):** Andrew Chow requested and
149+
introduced the topic, "I did a bunch of simulations of the
150+
[single random draw] fallback stuff
151+
([link](https://gist.github.com/achow101/242470486265d3f21adab08f65b9102c)).
152+
There are two problems that I see with this strategy: change can be
153+
incredibly small and the mean number of UTXOs in the wallet is quite
154+
high. The question is whether we can accept these tradeoffs or whether
155+
we need to find a better algorithm."
156+
157+
Gregory Maxwell said, "[If I recall correctly], there is nothing
158+
fundamental about [single random draw] that makes it good for making
159+
[branch and bound] work better, but rater it was the first alternative
160+
\[Mark Erhardt] tried there."
161+
162+
Chow added, "well, and in [Erhardt]'s simulations, [single random
163+
draw] performed reasonably well and was extremely simple. Though I
164+
guess we may be seeing different results now."
165+
166+
Various additional strategies and their tradeoffs were discussed, but
167+
the topic was starting to become complicated for a short segment of a
168+
time-limited text-only meeting.
169+
170+
**Conclusion:** Chow suggested, "perhaps this coin selection discussion
171+
would be better done in person with whiteboards," ending the meeting
172+
discussion, although Maxwell noted, "that leaves out people who can't
173+
attend." Presumably discussion will continue on PR [#13307][] and
174+
perhaps elsewhere.
175+
176+
## Multiwallet session persistence
177+
178+
**Background:** the development branch ("master" branch) of Bitcoin Core
179+
includes code that allows users to dynamically load and unload
180+
individual wallets in multiwallet mode. For example, you can have a
181+
"personal" wallet and a "business" wallet that can each be opened or closed
182+
separately.
183+
184+
**Discussion ([log][log multiwallet persistence]):** Jonas Schnelli
185+
requested and introduced the topic, "I guess it's not ideal that loaded
186+
wallets need to be re-loaded after a Bitcoin Core restart---especially
187+
in pruning mode."
188+
189+
Several meeting participants suggested that this is what the
190+
writable Bitcoin config file (rwconf) is being developed for. See PR
191+
[#11082][] and weekly meeting notes for [24 May 2018][rwconf meeting
192+
2018-05-24] and [7 June 2018][rwconf meeting 2018-06-07] for background.
193+
194+
[rwconf meeting 2018-05-24]: /en/meetings/2018/05/24/#gui-prune-setting-and-writable-config-files
195+
[rwconf meeting 2018-06-07]: /en/meetings/2018/06/07/#command-line-argument-mapping
196+
197+
**Conclusion:** "Okay, guess rw/config solves this, so /topic," said
198+
Schnelli.
199+
200+
## Bech32x
201+
202+
**Background:** several Bitcoin Core contributors have been working to
203+
create a new serialization format for backing up and recovering Bitcoin
204+
private keys, HD-wallet seeds, and HD-wallet extended private keys. The
205+
primary goal is to replace the current popular standards of base58check
206+
and BIP39 with a new standard that not only detects errors but can also
207+
automatically correct several of those errors for the user. Current
208+
ideas for this proposed format reuse some of the work that was performed
209+
to create the [bech32][bip173] native segwit address format, so work is
210+
proceeding under the name "bech32x" (but this may later change).
211+
212+
**Discussion ([log][log bech32x]):** Jonas Schnelli requested and introduced
213+
the topic, "Bech32x currently has the distance 27 [BCH][wikipedia BCH] with
214+
correction to 7 characters, thanks to \[Pieter Wuille]. The idea is now
215+
to have three 'levels' of correction. [...] Seven characters is not
216+
much more than 5% correction for 512-bit key material [so more is wanted
217+
for that case, at least]."
218+
219+
Wuille offered to provide three codes that user could choose from.
220+
Gregory Maxwell said, "I think it is not good to make it generally user
221+
selectable. The user *generally* has no way to make a useful
222+
decision---but making the format support multiple codes seems okay to
223+
me, though it might lower the odds that fancy decoders get written
224+
because it'll be more work."
225+
226+
Wuille said, "we can make sure they use the same field and extension so
227+
that the majority of the recovery code can be shared." Wuille and
228+
Maxwell continued talking about details of choosing optimal BCH codes
229+
for this purpose.
230+
231+
**Conclusion:** the time for the meeting to end occurred during the
232+
discussion and Maxwell said, "will continue later."
233+
234+
## RWConf [writeable Bitcoin configuration file]
235+
236+
*This topic was requested during the meeting but not enough time was
237+
available. Still, some participants stayed late to discuss it
238+
immediately after the meeting.*
239+
240+
**Background:** as discussed in the [24 May 2018 meeting][rwconf meeting
241+
2018-05-24], several contributors are working towards creating a
242+
machine-writeable configuration file that will be shared between Bitcoin
243+
Core's daemon and GUI so that when users change a setting in one
244+
program, it'll be set the same way in the other program. A particular
245+
problem with creating the new configuration file was raised in the [7
246+
June 2018 meeting][rwconf meeting 2018-06-07] but the person most
247+
familiar with the subject was not present; he was present for this
248+
after-meeting discussion.
249+
250+
**Discussion ([log rwconf][]):** Luke Dashjr had requested the topic and
251+
introduced it post meeting by asking whether AJ Towns had any objection
252+
to Dashjr reverting one of Towns's commits that changed how command-line
253+
and configuration file parameters were handled when Bitcoin Core is
254+
started. This would resolve an issue Dashjr was having creating the
255+
writeable configuration file.
256+
257+
Pieter Wuille suggested an additional mechanism and Towns pointed out a
258+
potential problem with Dashjr's proposal related to network
259+
configuration. However, Towns said, "anyway, I don't object to changing
260+
around the map stuff, [it] was just the simplest way I could see of
261+
getting relatively sane behavior."
262+
263+
**Conclusion:** no explicit conclusion. Presumably Dashjr will continue
264+
working on creating a machine-writable configuration file.
265+
266+
## Comic relief
267+
268+
{% highlight text %}
269+
<gmaxwell> I doubt we know all the vulnerabilities.
270+
I know of at least two but I stopped looking.
271+
<achow101> gmaxwell: I believe I know of three
272+
<gmaxwell> Also depends on how you count. :)
273+
<achow101> that too
274+
<sipa> i tend to count using the ring of integers
275+
{% endhighlight %}
276+
277+
## Participants
278+
279+
| IRC nick | Name/Nym |
280+
|-----------------|---------------------------|
281+
| sipa | [Pieter Wuille][] |
282+
| gmaxwell | [Gregory Maxwell][] |
283+
| kanzure | [Bryan Bishop][] |
284+
| achow101 | [Andrew Chow][] |
285+
| luke-jr | [Luke Dashjr][] |
286+
| jonasschnelli | [Jonas Schnelli][] |
287+
| Murch | [Mark Erhardt][] |
288+
| BlueMatt | [Matt Corallo][] |
289+
| meshcollider | [Samuel Dobson][] |
290+
| promag | [Joao Barbosa][] |
291+
| aj | [Anthony Towns][] |
292+
| jnewbery | [John Newbery][] |
293+
| instagibbs | [Gregory Sanders][] |
294+
| jtimon | [Jorge Timón][] |
295+
296+
## Disclaimer
297+
298+
This summary was compiled without input from any of the participants in
299+
the discussion, so any errors are the fault of the summary author and
300+
not the discussion participants. In particular, quotes taken from the
301+
discussion had their capitalization, punctuation, and spelling modified
302+
to produce consistent sentences. Bracketed words and fragments, as well
303+
as background narratives and exposition, were added by the author of
304+
this summary and may have accidentally changed the meaning of some
305+
sentences. If you believe any quote was taken out of context, please
306+
[open an issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)
307+
and we will correct the mistake.
308+
309+
[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/101362379/
310+
[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.html
311+
[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8
312+
313+
314+
{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.log.html" %}
315+
[mb log]: {{log}}
316+
[log hipri]: {{log}}#l-14
317+
[log alert]: {{log}}#l-30
318+
[log dev ml]: {{log}}#l-120
319+
[log coin selection]: {{log}}#l-155
320+
[log multiwallet persistence]: {{log}}#l-219
321+
[log bech32x]: {{log}}#l-239
322+
[log rwconf]: https://botbot.me/freenode/bitcoin-core-dev/msg/101364609/
323+
324+
[dashjr addr scanner]: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
325+
[value overflow incident]: https://en.bitcoin.it/wiki/Value_overflow_incident
326+
[nakamoto last post]: https://bitcointalk.org/index.php?topic=2228.msg29479#msg29479
327+
[alerts off]: /en/releases/0.12.1/#miscellaneous
328+
[alerts removed]: /en/releases/0.13.0/#low-level-p2p-changes
329+
[final alert]: /en/releases/0.14.0/#final-alert
330+
[alert key disclosure]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement
331+
[9 march 2017 weekly meeting]: /en/meetings/2017/03/09/#alert-key-disclosure-timeline
332+
[bitnodes scanning system]: https://bitnodes.earn.com/
333+
[srd 2018-06-14]: /en/meetings/2018/06/14/#srd-single-random-draw-fallback-coin-selection
334+
[wikipedia bch]: https://en.wikipedia.org/wiki/BCH_code
335+
336+
{% include link-to-issues.md issues="13062,12196,13425,13100,13307,11082" %}

0 commit comments

Comments
 (0)