< bitcoin-git> [bitcoin] lucash-dev closed pull request #13050: [tests] improvements to slow unit tests (master...slow-unit-tests-improvement) https://github.com/bitcoin/bitcoin/pull/13050
< promag> MarcoFalke: #13230 needs rebase tag?
< gribble> https://github.com/bitcoin/bitcoin/issues/13230 | Simplify include analysis by enforcing the developer guides include syntax by practicalswift · Pull Request #13230 · bitcoin/bitcoin · GitHub
< fanquake> promag it looks ok to me?
< fanquake> MarcoFalke is your bot on GH somewhere?
< promag> wumpus: #13394 done
< gribble> https://github.com/bitcoin/bitcoin/issues/13394 | cli: Ignore libevent warnings by theuni · Pull Request #13394 · bitcoin/bitcoin · GitHub
< wumpus> promag: thanks!
< promag> cfields: +1
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/e4082d59f53d...5779dc4f76ad
< bitcoin-git> bitcoin/master 0a4ea2f practicalswift: build: Add linter for checking accidental locale dependence
< bitcoin-git> bitcoin/master 698cfd0 practicalswift: docs: Mention lint-locale-dependence.sh in developer-notes.md
< bitcoin-git> bitcoin/master 5779dc4 Wladimir J. van der Laan: Merge #13041: build: Add linter checking for accidental introduction of locale dependence...
< bitcoin-git> [bitcoin] laanwj closed pull request #13041: build: Add linter checking for accidental introduction of locale dependence (master...lint-locale-dependence) https://github.com/bitcoin/bitcoin/pull/13041
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5779dc4f76ad...e1f8dce9939a
< bitcoin-git> bitcoin/master 0231ef6 Cory Fields: cli: Ignore libevent warnings
< bitcoin-git> bitcoin/master e1f8dce Wladimir J. van der Laan: Merge #13394: cli: Ignore libevent warnings...
< bitcoin-git> [bitcoin] laanwj closed pull request #13394: cli: Ignore libevent warnings (master...cli-event) https://github.com/bitcoin/bitcoin/pull/13394
< kallewoof> cfields: are you able to debug using lldb on mac? even with ./configure --enable-debug and make clean I get 'optimized', which is because it puts in -O2. Despite --enable-debug.
< wumpus> anyhow, going to tag rc2
< wumpus> * [new tag] v0.16.1rc2 -> v0.16.1rc2
< sipa> w00t
< fanquake> wumpus If you're still here, #13369 can go in
< gribble> https://github.com/bitcoin/bitcoin/issues/13369 | [docs] update transifex doc link by mess110 · Pull Request #13369 · bitcoin/bitcoin · GitHub
< wumpus> fanquake: ack
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1f8dce9939a...f8bcef38fb9b
< bitcoin-git> bitcoin/master 2b30ccc Cristian Mircea Messel: [docs] update transifex doc link
< bitcoin-git> bitcoin/master f8bcef3 Wladimir J. van der Laan: Merge #13369: [docs] update transifex doc link...
< bitcoin-git> [bitcoin] laanwj closed pull request #13369: [docs] update transifex doc link (master...fix_transifex_doc_link) https://github.com/bitcoin/bitcoin/pull/13369
< rafalcpp> no one ported the github-merge.py script to support gitlab?
< wumpus> not that I know
< wumpus> i'd guess that they have similar APIs, and it's just a matter of tweaking some things
< wumpus> huh, test_runner stopped printing progress dots here
< rafalcpp> API differs, and they do not want to write compatiblity layer. But probably allows same needed functions
< wumpus> oh it still prints ".", but it looks like it takes a lot longer to initially generate the cache
< wumpus> (ok, can't bisect it either, must be something that changed locally in the environment here)
< wumpus> rafalcpp: yes, I did not mean to imply it would be an exact mapping
< wumpus> rafalcpp: looking at it, it does only use one call from the gh api, the one to get PR information
< rafalcpp> wumpus: yeap, perhaps it will be written tomorrow
< wumpus> and from that, it only uses the title, body and branch base ref
< bitcoin-git> [bitcoin] marcoagner opened pull request #13410: Qt: removes html tags from tr calls (master...refactor_remove_tr_html_tags) https://github.com/bitcoin/bitcoin/pull/13410
< rafalcpp> wumpus: any idea how "refs/heads/pull/1/merge" is created, because it seems to not exist on github.com repo for PR 1, and yet the script wants it
< harding> rafalcpp: it's a special GitHub endpoint for PRs. I don't know how they generate it. You can see some instructions for one way to use it here that may be helpful (or not): https://gist.github.com/harding/1a99b0bad37f9498709f#opening-a-pr-for-a-pr
< ryanofsky> you may need a line like "fetch = +refs/pull/*/merge:refs/remotes/origin/pull/*/merge" in your .git/config file
< rafalcpp> hmm actually that /head etc might be created by script itself. checking
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f8bcef38fb9b...3d3d8ae3a0a9
< bitcoin-git> bitcoin/master ebebedc lucash.dev@gmail.com: speed up of tx_validationcache_tests by reusing of CTransaction....
< bitcoin-git> bitcoin/master 3d3d8ae MarcoFalke: Merge #13404: [tests] speed up of tx_validationcache_tests by reusing of CTransaction....
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13404: [tests] speed up of tx_validationcache_tests by reusing of CTransaction. (master...speedup-tx_validationcache_tests) https://github.com/bitcoin/bitcoin/pull/13404
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13412: Make ReceivedBlockTransactions return void (master...Mf1806-refactorReturnCodeValidation) https://github.com/bitcoin/bitcoin/pull/13412
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13384: qa: Remove polling loop from test_runner (master...Mf1806-qaTestRunnerConcurrentFuture) https://github.com/bitcoin/bitcoin/pull/13384
< bitcoin-git> [bitcoin] skeees opened pull request #13413: [net,mempool] Call AcceptToMemoryPool() asynchronously in p2p (master...mempool-async) https://github.com/bitcoin/bitcoin/pull/13413
< bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/3d3d8ae3a0a9...ea263e1eb030
< bitcoin-git> bitcoin/master 9b0ec1a Jim Posen: db: Remove obsolete methods from CBlockTreeDB.
< bitcoin-git> bitcoin/master e5af5fc Jim Posen: db: Make reusable base class for index databases.
< bitcoin-git> bitcoin/master 61a1226 Jim Posen: index: Extract logic from TxIndex into reusable base class.
< bitcoin-git> [bitcoin] laanwj closed pull request #13243: Make reusable base class for auxiliary indices (master...index-abstraction) https://github.com/bitcoin/bitcoin/pull/13243
< jamesob> nice change, congrats jimpo
< wumpus> I think we should invite jimpo / Jim Posen to the organizations, he's certainly a frequent contributor
< sipa> ack
< luke-jr> is there some reason we went from single-value args + multi-value args to override-args + config-args? the former seems a lot better..
< rafalcpp> wumpus: gitlab support is added probably. Though I see git submodules are not supported at all. Ok to add support for it? maybe just convert them to text of the sha1 commit?
< wumpus> rafalcpp: in bitcoin we use subtrees, not submodules, that's why there's no support for them
< sipa> support for submodules where?
< sipa> ah, in github-merge
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ea263e1eb030...97073f8837f3
< bitcoin-git> bitcoin/master 2acd1d6 Ben Woosley: Drop uint 256 not operator...
< bitcoin-git> bitcoin/master 97073f8 Wladimir J. van der Laan: Merge #13396: Drop unused arith_uint256 ! operator...
< bitcoin-git> [bitcoin] laanwj closed pull request #13388: util: Implement boolean conversion and !operator for uint* (master...uint_bool) https://github.com/bitcoin/bitcoin/pull/13388
< bitcoin-git> [bitcoin] laanwj closed pull request #13396: Drop unused arith_uint256 ! operator (master...drop-bool-not) https://github.com/bitcoin/bitcoin/pull/13396
< bitcoin-git> [bitcoin] rfree-d opened pull request #13414: Support gitlab API in github-merge.py (master...githubmerge_support_gitlab) https://github.com/bitcoin/bitcoin/pull/13414
< skeees> what would reaction / opinion be to defining a macro that allows a function to be static except in unit test builds
< skeees> something like #ifdef TEST "" #else static
< sipa> that would mean compiling the core objects separately for tests and for normal operation
< sipa> which may have performance advantages, but also downsides w.r.t. testability (you're not testing the exact same code as the one that goes in production)
< cfields> skeees: for what purpose?
< skeees> basically, theres a bunch of stuff (e.g. in net_processing) that could become static (and a lot of which is only called from one place so probably even inlined at compile time) except that its unit tested somewhere. might have some perf benefits, and would also help readability because you can immediately assess that something is translation unit local
< skeees> but i imagine the work to configure separate builds is substantial
< sipa> the perf benefits we can get longer term through lto as well
< cfields> skeees: sounds like you're looking for lto?
< skeees> mostly actually, i'm trying to separate net_processing a bit more from validation, and its been somewhat of a manual exercise, but finding lots of these - so i would say primarily readability / modularization actually
< skeees> probably better static analysis tools would accomplish the same
< cfields> ah, I see
< gmaxwell> If we just want a cosmetic note for arch reasons, there could be a STATICBUTFORTESTS that turns into STATIC for a specific test build (to verify that its used correctly) but otherwise isn't.
< skeees> hmmm yeah, that would do it
< wumpus> skeees: yes, pretty much an alternative to this: https://github.com/bitcoin/bitcoin/pull/13301#issuecomment-391712408
< wumpus> skeees: there's some good reasons to be against including cpp files, but it's also useful for testing static functions :)
< skeees> ahhh, well you could have that linter not run on anything in test/*
< gmaxwell> In other projects I've had okay success with including .c files for unit tests. I can get arguments against it though.
< wumpus> well it still has sipa's problem that "you're not testing the exact same code as the one that goes in production", it avoids the macro magic, but has including c/cpp files
< wumpus> choosing between evils...
< wumpus> the advantage of "my" method is that it also works for anonymous namespaces
< wumpus> a macro to replace static, would just work for static
< gmaxwell> Not testing the exact same code that goes into production is already pretty complicated. What the compiler is doing for inlinable functions already is inlining them where it can, potentially at every use in the file, and then the export is some other code. So the test may well already be testing code that is not used anywhere else.
< wumpus> gmaxwell: indeed
< gmaxwell> (obviously this doesn't matter if the code is all defined behavior and the compiler is bug free...)
< gmaxwell> I like to think of the "not testing the exact same code" as more of just a fundimental limitation of unit tests.
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13415: rpc: Add testblocktemplatevalidity (master...Mf1806-rpcTestblocktemplatevalidity) https://github.com/bitcoin/bitcoin/pull/13415
< jcorgan> meeting?
< wumpus> I mean it's a good point - internal/static functions are very likely inlined, so it's impossible to test exactly the same assembly code as used in production functions
< wumpus> the point of the unit test would be to test the functionality of the code, not the compiler
< wumpus> jcorgan: still 3 minutes to go according to my clock
< jcorgan> ah, need to fix ntpd on my irc bouncer :)
< gmaxwell> wumpus: yes, point of the unit test is testing functionality of the code not the compiler-- though if the code executes undefined behavior you can't fully decouple those things. In any case, my point is that static vs not static doesn't differ in the functionality of the code...
< sipa> *GONG*
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jun 7 19:00:08 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< achow101> hi
< sipa> hi
< wumpus> PSA: v0.16.1rc2 has been tagged, please start your gitian builders if you haven't yet, hopefully this can be a short rc, the only change is translations
< sipa> reasonable chance that rc2 will be final?
< sipa> (sorry, i haven't followed 0.16.1 much)
< achow101> yes
< wumpus> well at least I haven't seen any other reports to it, except the Russian translation issue
< promag> hi
< wumpus> so yes I hope this can be final very quickly
< jimpo_> hi
< wumpus> topic proposals?
< wumpus> #topic High priority for review
< wumpus> I don't understand why I added #13059 there last week, it's an issue, not a PR
< gribble> https://github.com/bitcoin/bitcoin/issues/13059 | Dynamic wallet load / create / unload · Issue #13059 · bitcoin/bitcoin · GitHub
< wumpus> at least we merged #13243
< gribble> https://github.com/bitcoin/bitcoin/issues/13243 | Make reusable base class for auxiliary indices by jimpo · Pull Request #13243 · bitcoin/bitcoin · GitHub
< sipa> yay
< promag> =)
< wumpus> so 6 PRs left, I'll remove the issue, surprised no one notified me about that
< promag> I saw that, didn't mind :P
< wumpus> I had an attempt at reviewing and testing #12196, but seems I found a bug
< gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
< wumpus> it also needs rebase
< wumpus> @jonasschnelli
< jonasschnelli> hi
< sipa> i was going to follow up with some ideas for writing sets of scripts/addresses
< jonasschnelli> yes. will take care. had some busy days but will work on it next week
< wumpus> ok, thanks for letting me know
< jonasschnelli> please do sipa
< sipa> yeah, it's on my todo list
< wumpus> #13062 I already reviewed a while ago, though it's been needed to rebase since
< gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
< sipa> i'll happily keep rebasing it :)
< wumpus> luke-jr: #11082 needs rebase too
< gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< luke-jr> is there some reason we went from single-value args + multi-value args to override-args + config-args? the former seems a lot better..
< luke-jr> (this is blocking me on 11082 rebasing)
< wumpus> I'll take that as a topic suggestion
< sipa> i'm not sure what you mean by that
< wumpus> (for later)
< wumpus> #12136 still has lots of active discussion
< gribble> https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
< wumpus> achow101: any idea what's needed to move forward there?
< gmaxwell> Is 13191 waiting on my review and testing?
< achow101> wumpus: more review
< wumpus> achow101: just review? ok
< achow101> wumpus: perhaps on the bip itself too
< sipa> i've also been discussion some ideas for splitting part of it up
< wumpus> gmaxwell: #13191 is already merged, but you're very welcome to test and review it anyhow
< gribble> https://github.com/bitcoin/bitcoin/issues/13191 | Specialized double-SHA256 with 64 byte inputs with SSE4.1 and AVX2 by sipa · Pull Request #13191 · bitcoin/bitcoin · GitHub
< wumpus> sipa: that's a good idea, I think, just to have progress
< wumpus> better to make sure as many as possible non-controversial things already merged
< gmaxwell> wumpus: lol. sorry, I had an old page up and on reload the post merge discussion caused me to miss that it was merged. :P
< gmaxwell> So I was confused as to why it wasn't merged yet.
< wumpus> gmaxwell: hehe
< sipa> there are a few more specialized-instructions-optimized-code PRs open
< sipa> we discovered yesterday that compiling the sse4 intrinsics code with -mavx gives a 30% speedup
< wumpus> #13111 should be pretty close, I guess it's just a boring thing to manually test because it unloads
< gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
< cfields> sipa: how much work do you think it would be to switch the sse41 to intrinsics?
< promag> reviews are welcome
< wumpus> promag: I will
< promag> i think it's almost there
< sipa> cfields: that would be neat
< sipa> cfields: i can try, but it's low priority for me
< wumpus> sipa: yes, that was really neat
< gmaxwell> I'll put money on it being a boatload slower. :P
< sipa> gmaxwell: define "boatload" please
< gmaxwell> (based on the mavx result suggests to me that the compiler is failing to achieve a good register allocation that doesn't kill performance)
< gmaxwell> 30%.
< sipa> (so i know whether to take the bet or not)
< sipa> nah, no way it's 30% slower with intrinsics :)
< wumpus> I supose it's only boatloads slower on my stupid AMD system :)
< cfields> sipa: ok, I'll look around for an impl on the net to copy from. I doubt I'd fare well myself, though :(
< sipa> cfields: the asm code we have is derived from nasm code that's more readable
< sipa> that may help
< wumpus> but anyhow if anyone needs benchmarking of anything on AMD, just let me know
< cfields> ok
< cfields> wumpus: I'd prefer to merge before getting the AMD numbers :p
< wumpus> cfields: I understand :p
< gmaxwell> wumpus: have you seen if the mavx compiled SSE4 code is slower on your system? I wouldn't expect it to be.
< wumpus> too bad I seem to collect them
< cfields> gmaxwell: iirc he benched those and it was ~the same.
< wumpus> gmaxwell: there was almost no difference with avx here
< wumpus> it was very slightly faster
< gmaxwell> odd.
< wumpus> looks like they go in to some emulation mode
< gmaxwell> (odd because my understanding was that the 30% speedup from getting better register space, not from using any AVX instructions...)
< sipa> gmaxwell: in AVX mode there literally is 2x more register space
< sipa> but maybe that's not the reason for the speedup, i haven't analysed
< sipa> still, i would be very surprised if equivalent code with intrinsics rather than asm is more than a few % slower
< gmaxwell> We can take this discussion offline, but I don't completely agree. :)
< sipa> ok!
< wumpus> intrinsics should do very well, with modern SIMD instruction sets
< wumpus> (they're pretty much designed to work well with them)
< wumpus> but yes, it's getting a bit off topic
< wumpus> #topic single-value args + multi-value args to override-args + config-args? (luke-jr)
< sipa> luke-jr: elaborate
< gmaxwell> I have cached skeptcisism mostly because compilers used to be VERY bad with register allocations for SIMD, resulting in a lot of code that is more complex than 'run this code 4x in parallel' not getting a speedup when hand asm hapily got a 3x speedup. I know they're much better now. So perhaps ignore me. :)
< luke-jr> we used to have a map of arg name -> single value and arg name -> multiple values
< luke-jr> it's been changed to arg name-> multiple values, but with two maps, one for config file, and one for command line options
< luke-jr> it seems better to have config/commandline share maps
< wumpus> gmaxwell: compilers seem to have become better with that, but I understand your skepticism
< wumpus> gmaxwell: there's also the *optimizing for a specific CPU type* versus *optimizing it to be, on average, fast, for many families of CPUs* thing
< luke-jr> this comes up because the change complicates how to implement rwconf
< achow101> luke-jr: I think that change may be for qt settings interactions
< wumpus> luke-jr: I'm not sure I know enough about this to understand the implications of this in practice
< jnewbery> luke-jr: it was changed in #11862
< gribble> https://github.com/bitcoin/bitcoin/issues/11862 | Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
< wumpus> whatever you do, please don't mess up the bitcoin-qt initialization order, the rest is fine with me :p
< sipa> i think it would also be useful to make the arg information know whether a particular argument is single-value or multi-value
< sipa> rather than have that information be at query time
< sipa> but i also don't understand the interactions well enough
< sipa> aj: you here?
< luke-jr> sipa: yes, I was thinking about that too
< wumpus> #13389 kind of scared me
< gribble> https://github.com/bitcoin/bitcoin/issues/13389 | Utils and libraries: Fix #13371 - move umask operation earlier in AppInit() by n2yen · Pull Request #13389 · bitcoin/bitcoin · GitHub
< luke-jr> the reason they're split one way or the other, is because the last command line option overrides the former ones, and the earlier config file overrides the later ones
< wumpus> we don't have good tests for half of this stuff
< luke-jr> so now when we do Get*Arg, the code is going for the end of the command line list, then the start of the config file list
< luke-jr> (the altnerative being, to just parse into a single value at startup, and just access that map at runtime)
< sipa> i feel like the right people aren't here to discuss that
< wumpus> yes
< luke-jr> maybe
< sipa> it sounds reasonable what you're saying, but i don't know enough to really comment
< wumpus> I agree
< jnewbery> There's a lot of discussion and review in both #12878 and #11862. AJ also added really good code coverage in those PRs, so it should be pretty straightforward to follow
< wumpus> other topics?
< gribble> https://github.com/bitcoin/bitcoin/issues/12878 | [refactor] Config handling refactoring in preparation for network-specific sections by ajtowns · Pull Request #12878 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11862 | Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
< promag> it also sounds reasonable to encapsulate the arg chaining in a map lookup lookalike
< wumpus> meh
< luke-jr> sounds like either way I should start with tests
< wumpus> personally I prefer method calls to just look like method calls, not operator overrides, in the common case
< wumpus> luke-jr: yes! tests are always good
< wumpus> other topics?
< promag> actually I have a question
< promag> #13374 and #13375
< gribble> https://github.com/bitcoin/bitcoin/issues/13374 | utils and libraries: checking for bitcoin address in translations by kaplanmaxe · Pull Request #13374 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13375 | utils and libraries: address check in update-translations.py by undercoverGod · Pull Request #13375 · bitcoin/bitcoin · GitHub
< wumpus> if you have a topic, just propose it, there's no need to tell that you have a question
< promag> they are the same, why isn't one closed?
< wumpus> because no one told me (or fanquake, or anyone) to?
< wumpus> I do not have the capacity to pay attention to all PRs in parallel
< promag> really? :P
< sipa> we need to have an AVX2 wumpus
< wumpus> sipa: +1
< sipa> +8
< sipa> end of meeting, i assume?
< wumpus> yes
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jun 7 19:45:28 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< BlueMatt> oh, quick comment: if you have had ideas about things you want to fork into the protocol in the future, *please* read https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki and make sure that your ideas can be added without protocol modifications so that miners dont need firmware updates
< BlueMatt> and pools wouldnt need to change
< BlueMatt> obviously basic things like additional commitments especially via the witness reserved value are clearly supported
< wumpus> promag: if people open "competing PRs" for the same issue that makes things more difficult
< wumpus> instead of just reviewing code, you suddenly need to be judge of what is the best approach
< promag> what are the odds to open competing PRs at the "same time"?
< promag> right
< wumpus> promag: it luckily doesn't happen too much!
< promag> imo one of the authors (the last?) should review the other
< promag> and close his own
< wumpus> I like your approach, get them to cooporate intead of compete
< * luke-jr> goes through the PR list, rewrites them, and opens new PRs to compete. jk
< promag> luke-jr: in this case they are very very similar
< wumpus> luke-jr: I know it, I shouldn't have given away this obvious DoS strategy
< promag> it's not a rewrite like you say
< luke-jr> wumpus: actually, if someone does try to DoS with it, it may end up improving our flow quickly
< wumpus> I'm... not going to say more about this, not giving people ideas :)
< promag> wumpus: then feel free to review my PR
< wumpus> promag: which one?
< promag> all
< promag> :|
< promag> unloadwallet
< promag> in travis its failing with -with-incompatible-bdb i think
< wumpus> lets' first see why travis is failing on it
< promag> I'll
< promag> .. to reproduce locally
< wumpus> multiwallet failing on x86_64 linux platforms
< promag> hm
< wumpus> I'll try locally too, on AMD :p
< promag> ty
< bitcoin-git> [bitcoin] wodry opened pull request #13416: More precise explanation of parameter onlynet (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13416
< wumpus> promag_: /home/orion/projects/bitcoin/bitcoin/src/qt/bitcoingui.cpp:122:5: warning: field 'spinnerFrame' will be initialized after field 'm_wallet_selector_label' [-Wreorder]
< wumpus> (I think that's due to your change, I haven't seen it before)
< wumpus> promag_: I don't get the same crash locally
< promag> regarding the warning, i'll fix
< promag> strange
< promag> mtt bug?
< wumpus> mtt?
< promag> multithread
< promag> crash aside, a code review + concept ack would be nice
< bitcoin-git> [bitcoin] skeees opened pull request #13417: [net] Tighten scope in net_processing (master...net_processing-disentangle) https://github.com/bitcoin/bitcoin/pull/13417
< bitcoin-git> [bitcoin] wodry closed pull request #13416: More precise explanation of parameter onlynet (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13416
< bitcoin-git> [bitcoin] wodry opened pull request #13418: More precise explanation of parameter onlynet (master...patch-2) https://github.com/bitcoin/bitcoin/pull/13418
< MarcoFalke> > <fanquake> MarcoFalke is your bot on GH somewhere?
< MarcoFalke> Not yet
< jimpo> Why in BIP 141 is the coinbase witness stack restricted to 1 item instead of making the reserved value the entire witness?
< sipa> jimpo: perhaps that was a mistake
< sipa> the reasoning was that you only need 1 reserved value in each level to 'chain' a new piece of data necessary for consensus
< jimpo> OK, thanks. Yeah, seems like it would just require more hash operations if it's linear in the number of levels/commitments.