Skip to content

Commit 32c1388

Browse files
hardingharding
committed
Meetings: add 2018-05-24 and 2018-05-31
1 parent bc0ce7c commit 32c1388

File tree

2 files changed

+456
-0
lines changed

2 files changed

+456
-0
lines changed

‎_posts/en/meetings/2018-05-24-meeting.md

Lines changed: 251 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,251 @@
1+
---
2+
title: IRC meeting summary for 2018-05-24
3+
permalink: /en/meetings/2018/05/24/
4+
name: 2018-05-24-meeting
5+
type: meetings
6+
layout: page
7+
lang: en
8+
version: 1
9+
---
10+
{% include _toc.html %}
11+
{% include _references.md %}
12+
13+
- View this week's log on [BotBot.me](https://botbot.me/freenode/bitcoin-core-dev/msg/100407600/) or [MeetBot][mb log]
14+
- [Meeting minutes by MeetBot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-24-19.00.html)
15+
16+
---
17+
18+
Topics discussed during this weekly meeting included what issues need to
19+
be resolved before generating the first release candidate for version
20+
0.16.1, whether transaction relay should be delayed a bit more in order
21+
to potentially increase spender privacy, how to store settings set
22+
internally by Bitcoin Core GUI and daemon so that both programs can
23+
access them, and whether Bitcoin Core should add a feature for scanning
24+
the UTXO set even though it might (hypothetically) not store the UTXO
25+
set in a scanable form in the future.
26+
27+
## [What needs to be done for] 0.16.1
28+
29+
**Background:** Bitcoin Core contributors are working towards releasing
30+
Bitcoin Core 0.16.1, a [maintenance release][] that will contain
31+
bug fixes and minor improvements.
32+
33+
**Discussion ([log][log 0.16.1 todo]):** Wladimir van der Laan proposed the topic and
34+
dove right into discussing what needed to be done, which appeared to be
35+
getting reviews on Pull Request (PR) [#13317][]. There was some
36+
discussion about whether PRs not related to 0.16.1 should be
37+
given high priority, which Van der Laan opposed "I think we should focus
38+
on 0.16.1 now; we'll get around to the other high priority stuff again
39+
next week."
40+
41+
Two PRs were proposed for backporting, [#12172][] and [#12431][], but
42+
both were argued against as either problematic or unnecessary.
43+
44+
**Conclusion:** reviewers are encouraged to view [#13317][].
45+
46+
## Random delays per network group to obfuscate transaction time
47+
48+
**Background:** many years ago, when Bitcoin software received a
49+
transaction, it shortly thereafter attempted to relay it to its other
50+
peers. This allowed transaction analysis organizations to connect to
51+
lots of nodes and assume that the first node they received a transaction
52+
announcement from was probably the node who created it (or, at least,
53+
was one of the first to relay it). In Bitcoin version 0.2.10, a feature
54+
was added that caused nodes to wait a different amount of time for
55+
different groups of peers before relaying them new transactions; this
56+
caused transactions to spread through the network less predictably to
57+
increase spender privacy. Subsequent releases have improved upon this
58+
basic feature.
59+
60+
PR [#13298][] describes a possible counter to the above method:
61+
transaction analysis organizations connect multiple times to each node,
62+
increasing the chance that they will hear about a transaction earlier
63+
rather than latter, and therefore increasing the chance that the first
64+
node they receive a transaction from is its original sender. That same
65+
PR also provides a method to make multiple connections more expensive
66+
for the analysis organization by causing the random delays to be based
67+
on network groups (large blocks of IP addresses) rather than individual
68+
nodes, so that analysis organizations need to get access to specific IP
69+
address ranges in order to obtain the same chance of being an early
70+
receiver
71+
72+
**Discussion ([log][log random relay delays]):** Pieter Wuille requested
73+
the topic and described what he'd like to see: "I want to bring up
74+
[#13298][] briefly [...] It's a possibly significant effect on P2P
75+
transaction relay and it needs review beyond 'does the code work.' But
76+
it's also just local policy and not something that warrants a BIP [in my
77+
honest opinion]. Maybe there's not much more to say about that, [I'm]
78+
just hoping to get people to think about it a bit."
79+
80+
The possibly significant effect on P2P transaction relay would
81+
lengthening the amount of time it takes a transaction (but not a block)
82+
to propagate from its originating peer to 90% or more of the other nodes.
83+
84+
**Conclusion:** there was no discussion, just a recommendation for
85+
reviewers to visit the PR, consider its effects, and provide comments
86+
with any recommendations.
87+
88+
## GUI prune setting and writable config files
89+
90+
**Background:** Bitcoin Core provides command line options and a
91+
user-editable configuration file (`bitcoin.conf`) but it also allows
92+
users to change some of the same settings in the Graphical User
93+
Interface (GUI). Currently these two sets of settings are stored in
94+
different places because the GUI can't change the configuration file
95+
(on some systems, it's read-only, and in all cases it may contain user
96+
comments and formatting that an automated configuration editor might
97+
break). However, this creates several problems, where a user changes a
98+
setting in one place and it either does or doesn't apply in the other
99+
place unexpectedly. The latest case of a shared setting is PR
100+
[#13043][] adding to a GUI the ability to control the pruning previously
101+
available from the command line and configuration file.
102+
103+
**Discussion ([log][log gui prune]):** Sjors Provoost requested the
104+
topic and suggested three solutions to the problem of where to store
105+
settings shared between different Bitcoin Core programs:
106+
107+
1. "Ignore the problem." Continue with the current system.
108+
109+
2. "Go the writable config file route." (Discussion goes into more
110+
detail later.)
111+
112+
3. "Interpret a lack of `prune=` setting differently." Give an option
113+
specified in a configuration file precedence over an option
114+
configured in the GUI.
115+
116+
Provoost added, "if we go for [option] 2, then I'd like to nominate
117+
[PR] [#11082][] for priority review." That PR adds a new
118+
`bitcoin_rw.conf` file for settings modified by the software. Unlike
119+
the Qt settings, the file can be shared between both Bitcoin Core's
120+
daemon and GUI, and the file would be explicitly marked as not intended
121+
to support comments, whitespace-based formatting, and other conveniences
122+
for human editing.
123+
124+
Jonas Schnelli complained, "do we want four(!) levels of configuration?
125+
Conf[iguration file] <-> startup [command line interface parameters] <->
126+
Qt Settings <-> level 4 [`bitcoin_rw.conf`]."
127+
128+
Provoost explained, "I'd also like to get rid of Qt settings completely
129+
[...] I wrote a migration away from QTSettings [in PR]&#32;[#12833][]."
130+
Schnelli was satisfied by this option and said, "thanks [Provoost] for
131+
working on that!"
132+
133+
Gregory Sanders suggested the "user could, by and large, be migrated
134+
over to the [`bitcoin_rw.conf`] unless they have a need for read-only."
135+
Wladimir van der Laan argued against this, "well, the `bitcoin.conf` is
136+
for human editing; the [`bitcoin_rw.conf`] is machine writable, all
137+
comments will be discarded, etc..."
138+
139+
**Conclusion:** no explicit conclusion; meeting participants seemed to
140+
be in favor of moving forward with creating a `bitcoin_rw.conf` to store
141+
settings modified by the software. There was some unresolved discussion
142+
about whether currently-open PRs that modify settings should wait for
143+
`bitcoin_rw.conf` to become available before being merged, or should use
144+
the existing sub-optimal Qt Settings mechanism.
145+
146+
## ScanTxOutSet RPC command
147+
148+
**Background:** The Bitcoin Core software maintains a [key-value
149+
database][] of every Unspent Transaction Output (UTXO)---that is, every
150+
spendable group of bitcoins and the conditions that need to be fulfilled
151+
in order to spend them. The database is not designed for access by more
152+
than one program at once and is not API stable, meaning other programs
153+
can't easily read from it, and so there's currently no convenient way
154+
for other programs to retrieve information from the UTXO set.
155+
156+
**Discussion ([log][log scantxoutset]):** Jonas Schnelli requested the
157+
topic and introduced it: "[Pieter Wuille] raised concerns about the
158+
`scantxoutset` command [proposed in PR #12196]. Before continuing on
159+
[PR]&#32;[#12196][], we may want to discuss if it makes sense[...]. The scan
160+
functionality allows UTXO sweeping (`rawsweeptransaction`) with no block
161+
scanning. You can pass in *n* pubkeys/addresses, or even [HD wallet
162+
extended public keys] with a lookup window, and it gives you back all
163+
unspent [outputs] (and even a rawsweeptransaction to a single address)."
164+
165+
Wuille described his concerns, "I just mentioned that we preferably
166+
don't commit to having functionality that's hard to maintain in the
167+
future. [For example, in a possible future with the]&#32;[UHF model][],
168+
implementing a scan of the UTXO set without indexes requires going
169+
through the block chain." *[Note: what's labeled in the discussion as
170+
"UHF" is elsewhere called "UHS"; see [link][UHF model].]*
171+
172+
Johnathan Corgan suggested, "If we want to encourage people to treat
173+
bitcoind as the 'ground truth', instead of baking up their own stuff,
174+
giving them easier access to the 'database' would help."
175+
176+
Wuille conceded that the issue was "less a concern [because it's easier
177+
to] add optional indexes now with [Jim Posen's] background index work.
178+
Before, new indexes always required ugly hacks all over the validation
179+
code."
180+
181+
**Conclusion:** "this is turning into a philosophical discussion,"
182+
remarked Wuille near the end of the discussion. There was no explicit
183+
conclusion, but it seemed that if a `scantxoutset` RPC or similar RPC is
184+
added, a warning might be added to the release notes that indicating
185+
that it might require enabling an optional index in the future.
186+
187+
## Comic relief
188+
189+
{% highlight text %}
190+
[...Things start to break...]
191+
<mquin> [Global Notice] [...] There are ongoing issues with
192+
services that are being looked into - please bear
193+
with us
194+
<sipa> fun.
195+
<instagibbs> err what
196+
<wumpus> services massacre
197+
<cfields> irc unicorns...
198+
let's move to slack!
199+
(/s)
200+
<wumpus> :-(
201+
{% endhighlight %}
202+
203+
204+
## Participants
205+
206+
| IRC nick | Name/Nym |
207+
|-----------------|---------------------------|
208+
| wumpus | [Wladimir van der Laan][] |
209+
| jonasschnelli | [Jonas Schnelli][] |
210+
| sipa | [Pieter Wuille][] |
211+
| provoostenator | [Sjors Provoost][] |
212+
| jcorgan | [Johnathan Corgan][] |
213+
| jimpo | [Jim Posen][] |
214+
| achow101 | [Andrew Chow][] |
215+
| MarcoFalke | [Marco Falke][] |
216+
| instagibbs | [Gregory Sanders][] |
217+
| cfields | [Cory Fields][] |
218+
| jamesob | [James O'Beirne][] |
219+
| jtimon | [Jorge Timón][] |
220+
| echeveria | Echeveria |
221+
| jnewbery | [John Newbery][] |
222+
| promag | [Joao Barbosa][] |
223+
| kanzure | [Bryan Bishop][] |
224+
| Murch | [Mark Erhardt][] |
225+
226+
## Disclaimer
227+
228+
This summary was compiled without input from any of the participants in
229+
the discussion, so any errors are the fault of the summary author and
230+
not the discussion participants. In particular, quotes taken from the
231+
discussion had their capitalization, punctuation, and spelling modified
232+
to produce consistent sentences. Bracketed words and fragments, as well
233+
as background narratives and exposition, were added by the author of
234+
this summary and may have accidentally changed the meaning of some
235+
sentences. If you believe any quote was taken out of context, please
236+
[open an issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new)
237+
and we will correct the mistake.
238+
239+
[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8
240+
[maintenance release]: /en/lifecycle/#maintenance-releases
241+
[key-value database]: https://en.wikipedia.org/wiki/Key-value_database
242+
[UHF model]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015967.html
243+
244+
{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-24-19.00.log.html" %}
245+
[mb log]: {{log}}
246+
[log 0.16.1 todo]: {{log}}#l-14
247+
[log random relay delays]: {{log}}#l-51
248+
[log gui prune]: {{log}}#l-66
249+
[log scantxoutset]: {{log}}#l-136
250+
251+
{% include link-to-issues.md issues="13317,12172,12431,13298,13043,11082,12833,12196" %}

0 commit comments

Comments
 (0)