---
title: IRC meeting summary for 2018-04-12
permalink: /en/meetings/2018/04/12/
name: 2018-04-12-meeting
type: meetings
layout: page
lang: en
version: 1
---
{% include toc.html %}
{% include references.md %}

- [Link to this week logs](https://botbot.me/freenode/bitcoin-core-dev/2018-04-12/?msg=98918663&page=4)
- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-12-19.01.html)

---

Topics discussed during this weekly meeting included what pull requests
members of the project would like reviewers to focus on during the
upcoming week, whether or not to break compatibility with an odd and
rarely used feature in the wallet (IsMine bare multisig), how to safely
improve multiwallet support, and how to deal with some unsupported
software when upgrading the build environment for Bitcoin Core's
reproducible binary releases.

## High priority for review

*Background:* each meeting, Bitcoin Core developers discuss which Pull
Requests (PRs) the meeting participants think most need review in the
upcoming week.  Some of these PRs are related to code that contributors
especially want to see in the next release; others are PRs that are
blocking further work or which require significant maintenance (rebasing)
to keep in a pending state.  Any capable reviewers are encouraged to
visit the project's list of [current high-priority
PRs](https://github.com/bitcoin/bitcoin/projects/8).

*Discussion:* The following PRs were suggested for attention this week:

1. **Build tx index in parallel with validation ([#11857][])** nominated
   by Jim Posen and Wladimir van der Laan.  This PR moves the optional
   transaction index that allows users to look up historical
   transactions by their txid into a separate database.  This will allow
   users to enable or disable the transaction index while a node is
   running instead of having to wait for up to several hours even on
   fast hardware.  The PR also lays the groundwork for adding additional
   separate indices to Bitcoin Core that can enable features such as
   improved-privacy block filtering for lightweight clients as described
   in BIPs [157][BIP157] and [158][BIP158].

    Prior to the meeting, the PR has already received some positive
    review but a few changes were requested and have now been made, so
    discussion in the meeting focused on getting those changes
    themselves reviewed.

2. **Upgrade path for non-HD wallets to HD ([#12560][])** nominated by
   Van der Laan. This PR adds a new `sethdseed` (set HD seed) RPC that
   allows users to set the seed value for a [BIP32][] Hierarchical
   Deterministic (HD) wallet.  This can be used to request Bitcoin Core
   generate a new seed on its own or to change the seed to a value
   obtained from outside the currently-running Bitcoin Core (such as
   from a backup).  In addition, the PR allows users of older non-HD
   Bitcoin Core wallets to upgrade to HD wallets using the
   `-upgradewallet` command line parameter.

    Discussion in the meeting indicated that the PR may have one
    unaddressed issue but that the PR primarily needs review from
    additional contributors.

3. **Move fee estimator into validationinterface/cscheduler thread
   ([#11775][])** nominated by Van der Laan.  This PR makes a backend
   change to some internal interfaces in Bitcoin Core's code and then
   changes Bitcoin Core's fee estimator to use one of those interfaces,
   giving it access to additional information useful for fee estimation.
   The PR also makes some minor improvements to the fee estimator in the
   way that it handles edge cases.

    Prior to the meeting, the author of the PR (Matt Corallo) had
    offered to split the PR into separate smaller PRs for the different
    parts of the change.  Discussion during the meeting indicated that
    reviewers are waiting for this to happen before reviewing further.

4. **Introduce `getblockstats` RPC to [provide data that can be used to]
   plot things ([#10757][])** nominated by Jorge Timón.  This PR adds a
   new RPC that returns various details and statistics about a specified
   block.

    Discussion in the meeting saw one contributor agreeing to review the
    PR.

A concern mentioned during the discussion was GitHub's recent problem of
pages failing to load for significant periods of time.  The problem has
become frequent enough that meeting participants mention the problem
by reference to the drawing GitHub displays on the error page, a
unicorn.

## What to do with IsMine on bare multisig

*Background:* Bare multsig refers to a payment to multiple public keys
without using a much more commonly used P2SH or segwit address.  Bitcoin
Core's wallet currently scans any bare multisig payments to see if every
public key used is part of the user's wallet and, if so, categorizes the
payment as *InMine* to indicate that it's spendable by the user.

*Discussion:* Pieter Wuille requested the topic.  He described the
current behavior as, "stupid, annoying, pointless, and hard to
maintain."  For *stupid* and *pointless,* the issue is probably that
multisig doesn't provide any additional security over single-sig when
all of the public keys belong to the same wallet, but using multisig
does cost more than single-sig.  For *annoying* and *hard to maintain,*
the issue is that this behavior requires extra code and is making it more
difficult for developers to work towards an [improved wallet
design](https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2)
previously described by Wuille.

Wuille then described his concern: "there may be existing outputs to it.
I don't know if this is the case or not, but it sounds scary to just
stop supporting it."  After some discussion, Wuille clarified that he
isn't proposing to remove the code that allows owners of those payments
to spend them; rather, it would be the case that Bitcoin Core would no
longer automatically see those payments.

Additional discussion between Matt Corallo and Wuille provided a vivid
description of the problem: to support this old behavior in the desired
new wallet model would require generating N<sup>3</sup> combinations,
where *N* is the number of private keys the user owns.  By default,
Bitcoin Core generates 2,000 private keys, so the wallet would need to
generate an unmanageable eight billion combinations.

Continued discussion surrounded Wuille's PR [#12874][] which disables
the current behavior and provides a workaround for users who need it.
Corallo mentioned that the existing RPC `importaddress` already provides
the important features necessary for the workaround.

*Conclusion:* although meeting participants were in favor of preserving
existing functionality if there was a reasonable way to do so,
discussion seemed to favor removing IsMine on bare multisig and
mentioning the workaround in the release notes.

## Dynamic wallet load/unload

*Background:* Old versions of Bitcoin Core could only use a single
instance of the built in wallet with a particular node. This was
extended to allow multiple wallet instances in [version
0.15.0](/en/releases/0.15.0/#multi-wallet-support), but older parts of
Bitcoin Core (such as command-line options read on startup) assume
the user only has one wallet instance and so they act on all loaded
wallets at once.  John Newbery's pull request [#10740][] provides a
workaround for this by allowing users to load, unload, and maybe even
create wallets at run time using new proposed RPCs.

*Discussion:* Joao Barbosa requested the topic, suggesting that
"...wallet management should be with shared pointers".  This would help
ensure that if a user requests to unload a wallet at run time, pending
requests involving that wallet can be handled before the wallet is
unloaded.  The alternative could be a wallet disappears unexpectedly in
the middle of an operation, which could cause unexpected and harmful
effects.  Barbosa has opened PR [#11402][] to make this proposed
change.

This proposal seemed uncontroversial and discussion moved to other
improvements and the sequence in which those improvements should be
implemented.  Jonas Schnelli suggested that Bitcoin Core first needed a
`createwallet` RPC so that wallets could be created at run time and the
command-line wallet options could be retired (or possibly restricted to
just single-wallet use).  Pieter Wuille noted that a runtime `createwallet`
would be strange without a runtime way to load a wallet, as you'd have to
restart Bitcoin Core in order to use the wallet you just created.

Luke Dashjr suggested the sequence "load -> create -> unload" as "unload
is the complex part," likely because of the potential problems dealing
with multiple processes working on a loaded wallet simultaneously.
Newbery concurred and responded favorably to Schnelli's suggestion
to "split unload away from the existing PR."

Wladimir van der Laan suggested that "unload should probably be in two
stages: after requesting it, RPC and the GUI lose access to it. Then it
waits for current operations to finish. Then the thing really gets
[unloaded]."

*Conclusion:* Newbery agreed that he'll modify his PR, saying on the PR
itself that he'll "reduce the scope of this PR to just a loadwallet RPC.
A createwallet RPC should come next, followed by unloadwallet.
(unloadwallet is where most of the difficulties are)."

## Gitian update

*Background:* Bitcoin Core uses a system called [Gitian][] to build its
release binaries in a way that is fully reproducible by anyone with a
computer and Internet connection, allowing anyone to verify that the
release binaries are the product of the peer-reviewed source code.  As
Bitcoin Core changes, the operating system targeted for building changes,
and the availability of other software changes, the Gitian build
environment needs to be updated to handle the changes.

*Discussion:* Luke Dashjr requested the topic, which seemed to be
related to the project's desire to switch the operating system used by
Gitian to the upcoming Ubuntu 18.04 LTS.  Dashjr's concern is that "we
need a replacement for vmbuilder or something, since Canonical hasn't
updated it to support anything recent."  Vmbuilder is a tool that allows
one to create and run a subsidiary operating system under your regular
operating system in order to build software in it.  A desirable feature
of vmbuilder is that it can create the sub-operating system in a virtual
machine to fully isolate it from your main operating system, helping to
prevent any problems in the code you're building from affecting your
actual operating system.

Wladimir van der Laan suggested using debbootstrap (Debian bootstrap), a
tool that predates vmbuilder and which uses a chroot instead of a
virtual machine, allowing it to trick normal software into thinking it's
being built in a separate operating system but which does nothing
significant to prevent malicious software from attacking the primary
operating system.  Although other developers such as Cory Fields were in
favor of moving to debootstrap, Dashjr remained concerned and said, "I
suppose fixing vmbuilder might be not too unreasonable [an] effort, maybe I
will try that."

Andrew Chow added that he was "considering adding Docker support to Gitian
so we would use a default Ubuntu docker image and then build from
there."  Docker can be more secure than a chroot but is usually less
secure than a virtual machine. Dashjr noted that Docker also restricted to
the x86_64 platform used by most desktops and servers, whereas some
project contributor believe it would be advantageous for some of the
reproducible builds to be created on other platforms that may not have
the problems found on x86_64 such as those related to the [Intel
Management Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine).

*Conclusion:* a switch to debootstrap in parallel with Dashjr
potentially working on getting vmbuilder working again.  Long term,
Fields is working to overhaul the system.

## Comic relief

{% highlight text %}
<wumpus>      #topic dynamic wallet load/unload (promag)
<instagibbs_> what's the controversy in this topic :)
<sipa>        it should happen, duh
<sipa>        how and when is another :)
{% endhighlight %}

## Participants


| IRC nick        | Name/Nym                  |
|-----------------|---------------------------|
| sipa            | [Pieter Wuille][]         |
| wumpus          | [Wladimir van der Laan][] |
| jonasschnelli   | [Jonas Schnelli][]        |
| luke-jr         | [Luke Dashjr][]           |
| BlueMatt        | [Matt Corallo][]          |
| promag          | [Joao Barbosa][]          |
| jnewbery        | [John Newbery][]          |
| jtimon          | [Jorge Timón][]           |
| jimpo           | [Jim Posen][]             |
| achow101        | [Andrew Chow][]           |
| randolf         | [Randolf Richardson][]    |
| instagibbs      | [Gregory Sanders][]       |
| cfields         | [Cory Fields][]           |
| sdaftuar        | [Suhas Daftuar][]         |
| meshcollider    | [Samuel Dobson][]         |
| jcorgan         | [Johnathan Corgan][]      |
| kanzure         | [Bryan Bishop][]          |

## Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.

[#11857]: https://github.com/bitcoin/bitcoin/issues/11857
[#12560]: https://github.com/bitcoin/bitcoin/issues/12560
[#11775]: https://github.com/bitcoin/bitcoin/issues/11775
[#10757]: https://github.com/bitcoin/bitcoin/issues/10757
[#12874]: https://github.com/bitcoin/bitcoin/issues/12874
[#10740]: https://github.com/bitcoin/bitcoin/issues/10740
[#11402]: https://github.com/bitcoin/bitcoin/issues/11402
[Gitian]: https://github.com/bitcoin-core/docs/blob/master/gitian-building.md
