< bitcoin-git> [bitcoin] fanquake reopened pull request #13503: Document FreeBSD quirk. Fix FreeBSD build: Cast to int to allow std::min to work under FreeBSD. (master...document-freebsd-quirk) https://github.com/bitcoin/bitcoin/pull/13503
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13512: [qa] mininode: Expose connection state through is_connected (master...Mf1806-qaMininodeState) https://github.com/bitcoin/bitcoin/pull/13512
< bitcoin-git> [bitcoin] fanquake opened pull request #13513: [wip] depends: native_protobuf 3.6.0 (master...depends-protobuf-36) https://github.com/bitcoin/bitcoin/pull/13513
< fanquake> sipa: Feeling a bit nostalgic today? 100'000 was quite a while ago
< bitcoin-git> [bitcoin] fanquake opened pull request #13514: depends: set LANG=C in Makefile (master...depends-ios-support) https://github.com/bitcoin/bitcoin/pull/13514
< skeees> pierre_rochard: looks like bitcoinacks might not update when labels get removed from a pr
< bitcoin-git> [bitcoin] ken2812221 opened pull request #13515: travis: Enable Qt build for Windows and 32-bit Linux (master...travis_qt) https://github.com/bitcoin/bitcoin/pull/13515
< wumpus> I won't be able to attend tonight's meeting, can someone else chair this time please?
< jonasschnelli> wumpus: I'm also not sure if I make it on time... so happy if sipa, MarcoFalke or someone else takes the chair
< Guest37145> bitcoin to rise $8230 2.35am EST tomorrow
< Guest37145> dgdsgd
< Guest37145> sgd
< Guest37145> sg
< Guest37145> dsg
< Guest37145> d
< Guest37145> g
< Guest37145> dsg
< Guest37145> dg
< Guest37145> dsg
< Guest37145> d
< Guest37145> g
< Guest37145> dg
< Guest37145> d
< Guest37145> gd
< Guest37145> g
< Guest37145> dsg
< Guest37145> gds
< pierre_rochard> skeees: ouch, I'll fix asap
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13517: qa: Remove need to handle the network thread in tests (master...Mf1806-qaAsyncIo) https://github.com/bitcoin/bitcoin/pull/13517
< bitcoin-git> [bitcoin] jonasschnelli pushed 9 new commits to master: https://github.com/bitcoin/bitcoin/compare/6579d80572d2...000abbb6b074
< bitcoin-git> bitcoin/master 537efe1 João Barbosa: rpc: Extract GetWalletNameFromJSONRPCRequest from GetWalletForJSONRPCRequest
< bitcoin-git> bitcoin/master 6608c36 João Barbosa: rpc: Add unloadwallet RPC
< bitcoin-git> bitcoin/master 4940a20 João Barbosa: test: Add functional tests for unloadwallet RPC
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #13111: Add unloadwallet RPC (master...2018-04-unload-wallet) https://github.com/bitcoin/bitcoin/pull/13111
< sipa> #startmeeting
< lightningbot> Meeting started Thu Jun 21 19:00:01 2018 UTC. The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< achow101> hi
< promag> hi
< meshcollider> Hi
< sipa> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
< kanzure> hi.
< sipa> topics?
< kanzure> alert key
< kanzure> not priority tho
< instagibbs> hi
< sipa> okay, let's start with high-priority reviews
< sipa> #topic review blocks
< kanzure> also, bitcoin-dev mailing list hosting provider is migrating away from the email protocol, so the underlying host is going to probably switch soon (more details forthcoming)
< jnewbery> hi
< sipa> we have 3 open review blockers: #13062 #12196 #13425
< gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
< achow101> the merged ones should be removed from the list
< sipa> good point, will od
< sipa> done
< sipa> any proposals for others to add?
< promag> I'll update #13100 in the next couple of days, but would be nice to have it on high priority
< gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
< promag> it's the missing piece in the dyn multi wallet story
< sipa> promag: ping me when ready, i'll add it then
< promag> will do ty
< sipa> #topic alert key
< sipa> kanzure: ^
< kanzure> alert key system deprecated, topic has absolutely no impact on bitcoind itself AFAIK
< achow101> besides vulnerable versions
< kanzure> i recognize the request to perhaps wait for v0.13 end-of-life, would like to hear more comments about that
< sipa> absent any other topic proposals, i'm sure we can talk about it
< kanzure> i believe those vulnerabilities might not be public but whatever, yes those
< achow101> 0.13 is the first version to have the alert system gone. the final alert stuff was added in 0.14.
< kanzure> for context: i'm thinking of releasing the private key, would be nice to get that out there and remove that liability
< achow101> so waiting for 0.14 to be the oldest version in any form of support is good
< gmaxwell> Though it was default off since what.. 0.10.something ?
< luke-jr> if 0.13 doesn't have alert system at all, why wait for it to be EOL?
< achow101> 0.12
< meshcollider> Yeah doesn't seem much point waiting for 13 EOL
< meshcollider> 0.12 is already gone
< gmaxwell> There are two levels, off by default, and gone completely. 0.12 has it off by default and 0.13 gone completely?
< achow101> yes
< kanzure> i'm particularly interested in hearing from others who have good reason not to reveal the key.. in the year+ since this was announced i don't think much has been raised.
< gmaxwell> and 0.12 is not supported at all, so all supported versions have it gone completely.
< kanzure> i sent out an email to the mailing list a few days ago and i have heard back from exactly one person regarding a request for a final alert message to some other altcoin
< kanzure> so i think this stuff is good and dead at this point
< achow101> yes
< achow101> also, if someone needs a final alert, they can pull it from the current source code
< gmaxwell> So that sounds pretty good for a release now, unless pre-0.12 nodes are still popular, and I don't believe they are.
< achow101> I would assume that someone who has changed the alert format would also change the alert key
< kanzure> anyway, if anyone would like to send me name suggestions for someone to go talk to in private, i'm open to that, although i don't expect to hear from anyone
< gmaxwell> unfortunately, final alerts don't have the protective properties we believed they had.
< luke-jr> there's ~3% of the network on 0.12
< achow101> luke-jr: what about earlier?
< kanzure> was non-protection disclosed somewhere?
< sipa> bitnodes says around 300 ish 0.12 and below nodes, out of 9945
< luke-jr> achow101: 0.61% "other" versions, which includes everything before 0.12
< achow101> ok.. and they all probably have the final alert anyways
< luke-jr> sipa: bitnodes only shows listening
< luke-jr> although that's the same 3%
< sipa> luke-jr: i'm aware; just offering an extra data point
< luke-jr> gmaxwell: what was missing re protective properties?
< kanzure> also how do folks feel about the unmentioned (spamming) vulnerabilities related to this?
< gmaxwell> luke-jr: back when we first started talking about publishing it I was under the mistaken belief that a final alert basically disabled the alert code ... e.g. no more alert message processing, only relaying of the final alert.
< gmaxwell> so that a final alert would effectively also limit the usefulness of any alert dos attacks
< gmaxwell> But that isn't the case.
< achow101> kanzure: I think all of the vulns should be disclosed at the same time as the key
< kanzure> this sounds like the same one
< luke-jr> gmaxwell: that was also my impression
< gmaxwell> I doubt we know all the vulnerabilities. I know of at least two but I stopped looking.
< achow101> gmaxwell: I believe I know of three
< gmaxwell> Also depends on how you count. :)
< achow101> that too
< sipa> i tend to count using the ring of integers
< gmaxwell> in any case, the alert code didn't stand up to careful review and is somewhat exposed to malicious alerts.
< gmaxwell> But then again any code still with it is also exposed in other ways.
< BlueMatt> there's also limited utility to releasing the alert key
< kanzure> sounds like some forkcoin projects might have to deal with this if they haven't already, not just rely on the fantasy of a final alert that shuts down the alert system
< BlueMatt> aside from "one less thing to worry about"
< gmaxwell> kanzure: well if anything still had it, it would have been easy enough to fix.
< gmaxwell> (by basically adding an "if I have had a final alert, drop all new alert messages" line.
< jnewbery> I think 'one less thing to worry about' is good enough reason (also 'one less thing to discuss for the rest of our lives')
< gmaxwell> )
< kanzure> i was surprised by the one person that did message- didn't think he would have had something with the alert system :-)
< kanzure> and if he could make that kind of mistake, i'd imagine many others are making worse mistakes
< gmaxwell> I was more concerned about it a year ago when in a short periord we had multiple people crop up and propose using that stupid key as some centeralized controlled whatever.
< meshcollider> And it has been a couple of years since the deprecation was announced, it's not like fair warning wasn't given in any case
< achow101> kanzure: if the altcoins have better control of their alert key, publishing the bitcoin one and the related vulns shouldn't be a problem
< kanzure> #action collect vulnerability knowledge from achow101
< kanzure> achow101: ah interesting point. i was only thinking about the projects that copied the public key actually.
< gmaxwell> I had thought there were ~none, but it turns out prior searches were somewhat ineffective.
< achow101> kanzure: AFAICT, there aren't any projects using the bitcoin one
< gmaxwell> The litecoin alertkey is copied all over heck and back.
< achow101> Google and github search for the key itself has turned up nothing
< gmaxwell> achow101: there was at least one we missed.
< kanzure> achow101: there is at least one actually, and someone contacted me about it i think :-)
< achow101> it could be that they removed the alert system but still have legacy nodes?
< kanzure> unfortunately this person was also misinformed about the effects of the final alert message... in fact, i should go fix that misunderstanding.
< gmaxwell> In any case, I think there has been plenty of warning from the prior discussion.
< gmaxwell> kanzure: also I think our prior discussion made it pretty clear that the final alert turned out to not be so final.
< BlueMatt> at some point if you're so incompetent that you leave the alert key around for a while you've probably broken things in 10 other ways, honestly
< gmaxwell> (or rather there were DOS vulnerabilties that persisted in spite of it)
< kanzure> BlueMatt: yeah but i also somewhat have a duty to not inadvertedly break other people's broken systems just because they are stupid broken systems
< BlueMatt> I dont think we need to worry about other random crap
< meshcollider> Agreed, I think just a full post with all info, vulns and key would be best now to resolve this
< gmaxwell> the alert system was kinda cool, except for the bugs... and unclear security model, lack of multisig, etc. :P
< BlueMatt> more like worry about our own crap and make sure to sufficiently disclose, which clearly happened
< luke-jr> DoS is not a big deal IMO
< kanzure> sure. okay. let's move on.
< luke-jr> maybe the denial of service will prompt the user to upgrade ;)
< kanzure> i do have one other topic about bitcoin-dev mailing list
< gmaxwell> luke-jr: yes, assuming thats the worst of it.
< sipa> ok, let's switch topics
< gmaxwell> (I don't have any reason to assume it's worse than dos other than the fact that there were a bunch of DOS vulns that were unknown until I checked before publishing the key)
< sipa> #topic bitcoin-dev mailinglist
< kanzure> linuxfoundation is migrating away from the email protocol and will no longer be hosting the bitcoin-dev mailing list
< kanzure> there is a migration plan but it's under investigating still
< kanzure> details are still forthcoming sorry i don't have anything specific at this time
< BlueMatt> what are the other 200 mailing lists on lists.linuxfoundation.org doing?
< kanzure> will post to mailing list when i have more details about actual plan
< BlueMatt> errr, oh, actually there arent many
< kanzure> i believe the current plan is "give lists.linuxfoundation.org to osuosl"
< achow101> what does "migrating away from the email protocol" mean? are they just not doing mailing lists anymore?
< luke-jr> achow101: right
< kanzure> achow101: linuxfoundation no longer believes in email apparently
< kanzure> i don't know, man.
< meshcollider> lol
< gmaxwell> Is that like not believing in santa clause?
< kanzure> it's similar but not in the abstract
< gmaxwell> claus*
< sipa> How can you believe in the universe, if you don't even know if email is real?
< kanzure> i'll post more details once i have some, i'd prefer to get an email out to the mailing list before the migration happens since this is weird and unusual
< luke-jr> I guess if you disbelieve in email, it ceases to be real for you?
< gmaxwell> in any case, I can't say that I was completely happy with LF regardless.
< kanzure> my primary concern is about linkrot
< kanzure> they seem open to including some rewrite rules on their http server to fix some of the linkrot problem
< sipa> ... for now
< luke-jr> kanzure: if they're letting OSUOSL use the domain, wouldn't OSUOSL just be able to maintain the links?
< kanzure> and also, if the mailing list was to move away from lists.linuxfoundation.org as the domain, and MX records, then potential email delivery problems for the current subscribers
< kanzure> luke-jr: sipa notes that the relationship there might change over time
< sipa> are there any other topics?
< achow101> I'm already experiencing mail delivery problems, so....
< luke-jr> kanzure: nothing we can do can prevent that AFAIK
< sipa> (we can let this discussion continue if nothing else, but perhaps there are more development related topics)
< kanzure> oh yeah, achow101 has reported mail delivery and receipt problems for lists.linuxfoundation.org that i haven't been able to investigate
< aj> was there configuration / bitcon-rw.conf / ...? stuff to discuss? i think some got deferred from previous meetings
< achow101> topic suggestion: coin selection
< achow101> (again)
< sipa> aj: i'm not up to date with that discussion
< sipa> #topic coin selection
< achow101> I did a bunch of simulations of the srd fallback stuff
< luke-jr> aj: yes, last time it was deferred cuz someone wasn't here
< achow101> there are two problems that I see with this strategy: change can be incredibly small and the mean number of utxos in the wallet is quite highg
< achow101> the question is whether we can accept these tradeoffs or whether we need to find a better algorithm
< sipa> it sounds concerning to me
< achow101> I agree, especially the small change
< achow101> we may have to keep MIN_CHANGE, but I don't really like having a fixed minimum change
< gmaxwell> is this code discarding sub fee change?
< sipa> yes
< sipa> you mean turning dust change into fee? yes
< gmaxwell> OKAY
< gmaxwell> So let me check my understanding of our understanding.
< gmaxwell> SRD is producing poor solutions in cases where the wallet has lots of small inputs? And also tends to produce small change itself?
< sipa> tends to produce
< achow101> however it does help BnB find more exact matches
< gmaxwell> Yes, but probably other strategies could do that.
< sipa> but clearly not enough to compensate (as the total number of UTXOs grows)
< luke-jr> aj: (do you have time to discuss rwconf stuff after the meeting if we run out of time during?)
< gmaxwell> e.g. current algo but with a min_change that is randomized more.
< jtimon> sorry I'm late, https://github.com/bitcoin/bitcoin/pull/13311 is kind of blocking to me for the block signed testnets thing (assuming there's still interest in that) </offtopic>
< gmaxwell> IIRC there is nothing fundimental about SRD that makes it good for making BNB work better, but rather it was the first alternative murch tried there.
< aj> luke-jr: (yes, it's the start of my day here)
< sipa> well and in murch's simulations, SRD performed reasoably well, and was extremely simple
< sipa> though i guess we may be seeing different results now
< gmaxwell> So for example, current solver plus add a couple extra inputs at random probably also makes BNB work better than current alone.
< sipa> i'm wondering if instead of SRD, we shouldn't use a BNB algorithm with a very large target range, larger than minimal change
< Murch> And then allow it to create change outputs?
< sipa> Murch: indeed
< sipa> Murch: basically run BNB in a mode where it assumes change will be created anyway
< sipa> and then minimize waste for that
< sipa> have you considered such a strategy?
< gmaxwell> stratigies that minimize change values are bad for building a collection of coins that help BNB.
< Murch> I have thought a bit about it, but figured that it is computationally intensive for no good reason
< sipa> gmaxwell: minimizing change != minimizing waste
< gmaxwell> sipa: what is 'waste'?
< jonasschnelli> hi
< Murch> Also, then you're just minimizing the input set since everything produces change and thus all with the same count of inputs have the same waste value
< Murch> at least at higher fees
< achow101> gmaxwell: line 36 of src/wallet/coinselection.cpp
< sipa> gmaxwell: in this case, it means minimziing fees
< Murch> Maybe one could just do smallest first selection at the lowest fee range to auto-consolidate?
< gmaxwell> Murch: smallest first is pathalogical for wallets with tons of tiny inputs, unfortunately.
< sipa> we probably shouldn't do algorithm design in this meeting, but ideas for things to try may be useful
< Murch> Alright, maybe oldest first on the ones that are smaller than the target. ;)
< gmaxwell> we can't have undefended pathological behavior, since we can't assume the usage will be supervised.
< Murch> but it would have some sort of limit on transaction size
< luke-jr> might be interesting to have coin selection pay attention to feerate estimates. use more inputs when feerates are low, for example. just a thought
< gmaxwell> We could still have that mode, it would just have to be guarded by something that cuts off the pathalogical behavior.
< Murch> gmaxwell: If smallest first is only used at < 4 sats/byte, why not auto-consolidate up to e.g. 250 unspents?
< achow101> luke-jr: preferably the algorithm would be self adjusting to the feerates
< sipa> luke-jr: it does
< sipa> BNB at least does
< Murch> ofc it would mean that a cpfp would be extremely expensive should it become necessary
< Murch> luke-jr: the new fee estimation is already fee sensitive
< luke-jr> i c
< sipa> Murch: you mean coin selections
< sipa> i would hope that fee estimation is fee sensitive :p
< Murch> äh, I do
< jonasschnelli> I have two topic proposal... but I guess I'm too late: a) Multiwallet session persistence b) Bech32X
< achow101> perhaps this coin selection discussion would be better done in person with whiteboards
< sipa> yeah
< sipa> #topic multiwallet session persistence
< Murch> I'm game
< jonasschnelli> Okay...
< luke-jr> ok, so I guess rwconf waits until after meeting :x
< gmaxwell> achow101: that leaves out people who can't attend.
< jonasschnelli> I guess it's not ideal that loaded wallets need to be re-loaded after a Bitcoin-Core restart...
< jonasschnelli> especially in pruning mode
< sipa> luke-jr, aj: i can make it a topic; it wasn't clear if you wanted it here
< gmaxwell> jonasschnelli: so put them in the conf file?
< luke-jr> sipa: almost out of time anyway
< sipa> jonasschnelli: that sounds like something to address with rwconf
< jonasschnelli> gmaxwell: that works for static enviromnents...
< gmaxwell> jonasschnelli: not with rwconf.
< luke-jr> gmaxwell: maybe not easy for GUI users (yet; rwconf to the rescue? :P)
< jonasschnelli> rwconf would be indeed a solution, yes.
< sipa> it seems like the exact same problem as the one rwconf is intended to solve
< luke-jr> unless you wanted multiple different sessions, maybe?
< luke-jr> but I'm not sure there's a use case for that
< gmaxwell> seems out of scope to me.
< jonasschnelli> Okay guess rw/config solves this... so /topic
< sipa> #topic bech32x
< jonasschnelli> Bech32X has currently the distance 27 BCH with correction to 7 chars (thanks to sipa)
< jonasschnelli> The idea is now..
< jonasschnelli> to have three "levels" or correction..
< sipa> i'll gladly create code for that
< jonasschnelli> I'd like to hear if this a) is "easy" possible (three generators) and b) if the use case makse sense (selective correction robusntess)?
< sipa> i don't have strong opinions about usage
< gmaxwell> I don't understand
< gmaxwell> 12:52:32 < jonasschnelli> to have three "levels" or correction..
< jonasschnelli> 7 chars is still not much more then 5% correction for 512bit key material
< luke-jr> maybe correction level should be somehow defined as a % of the whole?
< gmaxwell> Oh you want multiple codes so for long key data it uses a stronger code?
< jonasschnelli> gmaxwell: a flexible checksum, either 7 chars or 14chars or 28 chars of correction
< sipa> gmaxwell: or that the user can choose how much correction information they want
< jonasschnelli> gmaxwell: either the length or the HRP does hint what code to use
< sipa> (QR codes have this, for example)
< jonasschnelli> Yes.
< gmaxwell> It can't be 'flexible' without hurting performance, but we could just have more or less.
< gmaxwell> through multiple codes.
< sipa> yeah, i'm sure he just means have 3 codes to choose from
< jonasschnelli> yes
< gmaxwell> But I think it is not good to make it generally user selectable. The user _generally_ has no way to make a useful decision.
< jonasschnelli> gmaxwell: Yes. I also thought this...
< luke-jr> user in this case being the software I think
< gmaxwell> But making the format support multiple codes seems okay to me though it might lower the odds that powerful fancy decoders get written, because it'll be more work.
< jonasschnelli> On the other hand, maxing on 5% correction may also be not ideal
< sipa> gmaxwell: we can make sure they use the same field and extension, so that the majority of the recovery code can be shared
< gmaxwell> There are certian improved properties we can get if we know a code will only be used for shorter vs longer data.
< sipa> gmaxwell: not much as these levels of corrections (too large search space)
< gmaxwell> so if the goal really was just to have multiple codes to have a certian percentage of correction that could perhaps be used.
< gmaxwell> sipa: well we can still search for codes with improved performance over modest (e.g. 50 char) windows, giving better burst error handling.
< sipa> we can even make the generators multiples of each other, so that a valid code according to one is also valid according to the "weaker" versions
< gmaxwell> in any case, I assume sipa would come up with the codes.. fewer levels is better than more...
< sipa> (or with a different offset, guarantee that this exactly never happens)
< gmaxwell> sipa: if you're going to abandon beyond bch performance the difference codes could just be punctures of a single bigger one.
< sipa> gmaxwell: right, i believe that's actually saying the same thing
< sipa> gmaxwell: also, for distance 15 there is nothing we can grind, not even for short lengths
< sipa> #endmeeting
< lightningbot> Meeting ended Thu Jun 21 20:00:09 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa> #lunch
< gmaxwell> It seems odd and a bit sad to have so much design freedom and not use it however.
< luke-jr> sipa responds and runs :P
< gmaxwell> will continue later.
< luke-jr> =⃦topic rwconf (ping aj)
< gmaxwell> sipa: I wonder if we can at least choose the lower degree part of the code to have better performance.
< sipa> gmaxwell: that's a good point
< aj> luke-jr: yo
< sipa> gmaxwell: we could just extend the bech32 generator for example
< aj> luke-jr: yeah. the separate maps for cmdline and config were to preserve the flipped ordering behaviour
< luke-jr> aj: do you have any objections to reverting it back to a single-value map + multi-value map?
< luke-jr> (thereby resolving the ordering stuff at startup, rathre than runtime)
< sipa> i think AddArg should get a flag indicating whether the option is single-value or multi-value, so that repeated arguments can be dealt with at parsing time
< * sipa> afk
< luke-jr> sipa: IMO that makes sense, but best as a separate PR
< aj> luke-jr: i don't think that quite works with prioritising the network stuff; ie atm it's "cmdline, [regtest], plainconfig"; but if you populate a single map with override first, then see a plain config option, then see regtest.foo=bah, you can't decide whether to drop the old entry or preserve it
< luke-jr> hmm
< aj> luke-jr: long term i like (an approach like) meshcollider's arg rework stuff
< aj> luke-jr: //github.com/MeshCollider/bitcoin/commits/201712_argument_registration maybe
< aj> luke-jr: anyway, i don't object to changing around the map stuff, this was just the simplest way i could see of getting relatively sane behavior
< luke-jr> aj: maybe the single map will need a flag indicating where it came from for now
< aj> luke-jr: yeah, that's just equivalent to two maps :)
< luke-jr> well, now we're getting into 4 sources - "cmdline, rwconf, [regtest], plainconfig"
< aj> luke-jr: 3 sources if you count them as cmdline, rwconf, config[foo=/regtest.foo=/test.foo=/main.foo=]
< aj> luke-jr: but yeah
< * booyah> whispers "the Registry"