< provoostenator> TL&DR: 3:00 hours on t2.2xlarge, c5.2xlarge, 3:50 hours on m5.2xlarge. I ran out of ideas to make it run faster, see logs in #blockchain-sync.
< bitcoin-git> [bitcoin] glaksmono opened pull request #13183: [WIP][bitcoin-11004] New Travis job for CHECK_DOCS steps (master...bitcoin-11004) https://github.com/bitcoin/bitcoin/pull/13183
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66cc47be982a...a174702bad1c
< bitcoin-git> bitcoin/master fad63eb John Newbery: [logging] Don't incorrectly log that REJECT messages are unknown....
< bitcoin-git> bitcoin/master a174702 Wladimir J. van der Laan: Merge #13162: [net] Don't incorrectly log that REJECT messages are unknown....
< bitcoin-git> [bitcoin] laanwj closed pull request #13162: [net] Don't incorrectly log that REJECT messages are unknown. (master...fix_reject_logging) https://github.com/bitcoin/bitcoin/pull/13162
< jtimon> sorry, I forgot to fix BlueMatt's latest nits on https://github.com/bitcoin/bitcoin/pull/10757 fixed now
< jtimon> btw, I'm confused about what "matt was here" means in this context. I thought it was mostly for refactors and meant something like "I don't see the value of this refactor but it doesn't break things and I don't care, so I won't nack", but this is adding new functionality
< jtimon> can someone clarify what's that supposed to mean, perhaps we can put that on the documentation like we have ACK, utACK, etc ?
< luke-jr> jtimon: the impression I got (but I never asked him) was that it was a kind of "I looked at this, but I didn't review it sufficiently to ACK"
< jtimon> luke-jr: I was under the impression he had reviewed it enough, but perhaps that's it
< luke-jr> well, sounds like BlueMatt should clarify ;)
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a174702bad1c...6a01a50f4906
< bitcoin-git> bitcoin/master 43f3dec donaloconnor: Remove enum specifier (to avoid re-declare scoped enum as unscoped)
< bitcoin-git> bitcoin/master 6a01a50 Jonas Schnelli: Merge #13180: Fix re-declared scoped enum as unscoped (Causes issues with some compilers)...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #13180: Fix re-declared scoped enum as unscoped (Causes issues with some compilers) (master...06052018_unscoped_enum) https://github.com/bitcoin/bitcoin/pull/13180
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/6a01a50f4906...bd83704ec6fa
< bitcoin-git> bitcoin/master 29c9bdc practicalswift: Handle unsuccessful fseek(...):s
< bitcoin-git> bitcoin/master 20ce5af practicalswift: Print a log message if we fail to shrink the debug log file
< bitcoin-git> bitcoin/master bd83704 Wladimir J. van der Laan: Merge #13149: Handle unsuccessful fseek(...):s...
< bitcoin-git> [bitcoin] laanwj closed pull request #13149: Handle unsuccessful fseek(...):s (master...fseek) https://github.com/bitcoin/bitcoin/pull/13149
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bd83704ec6fa...57aae632e288
< bitcoin-git> bitcoin/master ddebde7 Chun Kuan Lee: Add Windows shutdown handler
< bitcoin-git> bitcoin/master 57aae63 Wladimir J. van der Laan: Merge #13131: Add Windows shutdown handler...
< bitcoin-git> [bitcoin] laanwj closed pull request #13131: Add Windows shutdown handler (master...win-quit) https://github.com/bitcoin/bitcoin/pull/13131
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/57aae632e288...5778d44aa857
< bitcoin-git> bitcoin/master 16be133 Ben Woosley: Fix rescanblockchain rpc to property report progress...
< bitcoin-git> bitcoin/master 5778d44 Jonas Schnelli: Merge #13079: Fix rescanblockchain rpc to properly report progress...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #13079: Fix rescanblockchain rpc to properly report progress (master...scan-for-wallet-stopblock-progress) https://github.com/bitcoin/bitcoin/pull/13079
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5778d44aa857...bf9b03ddcc65
< bitcoin-git> bitcoin/master ab3f4dd Chun Kuan Lee: tests: Add test for 64-bit PE, modify 32-bit test results...
< bitcoin-git> bitcoin/master bf9b03d Wladimir J. van der Laan: Merge #13094: tests: Add test for 64-bit Windows PE, modify 32-bit test results...
< bitcoin-git> [bitcoin] laanwj closed pull request #13094: tests: Add test for 64-bit Windows PE, modify 32-bit test results (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13094
<@wumpus> #10267 gives me an unicorn
< gribble> https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
<@wumpus> I'll complain to github
< aj> wumpus: tried clearing your cookies?
<@wumpus> yeah I can try that again...
< jonasschnelli> Also getting a unicorn
<@wumpus> though I have a hard time believing my browser's handling of cookies is at fault here
<@wumpus> contacted github anyhow
< Oldnewbie> Quit
< promag> unicorn too
<@wumpus> jonasschnelli: btw - what is the process for importing a new libbtc into bitcoincore-indexd? I need MSG_WITNESS_BLOCK
<@wumpus> is it a subtree?
< jonasschnelli> wumpus: I think I have added it as subtree
< jonasschnelli> wumpus: BTW: I'm currently running a script that runs 10 times block fetching from 490000 till 500000 and measures times
< jonasschnelli> Currently running on master... will compare than against your PR and report.
< jonasschnelli> Since this is on SSD, may result may be even more promissing then yours
<@wumpus> I hope so :)
<@wumpus> though 10% gain is already somewhat neat
< jonasschnelli> wumpus: Yes! 10% is already great!
< BlueMatt> jtimon: in this case it means what you thought - "I dont care about this feature, so I'm not gonna ack it, but it seems like some folks want it, so certainly wont oppose. Aside from the comments left, I see no other bugs, and so am fine with it advancing, but do not wish to in any way imply a concept ack"
< BlueMatt> luke-jr: plz2rebase #12208? Trying to whip 0.16.1 :p
< gribble> https://github.com/bitcoin/bitcoin/issues/12208 | GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default by luke-jr · Pull Request #12208 · bitcoin/bitcoin · GitHub
< jtimon> BlueMatt: thanks for claryfing
< bitcoin-git> [bitcoin] harding opened pull request #13184: RPC Docs: gettxout*: clarify bestblock and unspent counts (master...2018-05-rpc-help-bestblock) https://github.com/bitcoin/bitcoin/pull/13184
< jonasschnelli> How do I only allow connection from
< glaksmono> hi guys, i'm trying to find a reviewer for this: https://github.com/bitcoin/bitcoin/pull/13183
< glaksmono> can someone help?
< jonasschnelli> Seems like whitelist= and connect=0 won't work
< jonasschnelli> glaksmono: have some patience
< glaksmono> alright @jonasschnelli
< glaksmono> i'm a newbie contributor :)
< jonasschnelli> glaksmono: also, maybe write some pull request description (not only refere to the issue)
< jonasschnelli> NM: whitebind= fixed my issue
<@wumpus> jonasschnelli: subtree merge from libbtc/libbtc gives me tons of conflicts
< jonasschnelli> wumpus: try rm -rf src/libbtc and then a fresh git subtree add?
< jonasschnelli> I'm pretty sure I haven't done local changes
<@wumpus> or I'll resolve the conflicts to 'theirs'
< jonasschnelli> yeah
<@wumpus> let's see if it still builds at all
< jonasschnelli> I don't know why I had to manually add a LDADD+=-lpthread in the bitcoincore-indexd project... seems that lpthread will not auto-added via Makefile.leveldb.am
< jonasschnelli> hmm... master is quicker then PR 13151?! let me double check...
<@wumpus> jonasschnelli: eh whoops libbbtc serialize.h has two LIBBTC_END_DECL
< jonasschnelli> wumpus: hmm.. that was a recent change by promag...
< jonasschnelli> should this not have been detected by travis..
<@wumpus> jonasschnelli: if that header is used in one of the tests, which I assume, yes :)
<@wumpus> jonasschnelli: I think I know why travis passed with it: in C, the macros are defined as nothing
<@wumpus> this problem is only apparent when the lib is used from C++
< jonasschnelli> ah.. right!
< jonasschnelli> wumpus: any reason why your PR 13151 preforms ~6% slower then master?
< jonasschnelli> I just reverted back to 598db389c33e5e90783ef1223df2eeab095ed622 from 13151 head to make sure im comparing the right things
<@wumpus> jonasschnelli: you do request MSG_WITNESS_BLOCK at all?
< jonasschnelli> let me dbl check
<@wumpus> if so, I'm confused, I don't see how this can be *slower*
<@wumpus> maybe add back the LogPrintf to make sure it's hitting the new fast path at all
< jonasschnelli> wumpus: ser_u32(inv_msg_cstr, 2 | (1 << 30));
< jonasschnelli> seems correct
<@wumpus> yes
<@wumpus> yes the ""debug: Serving raw block directly from disk"
<@wumpus> although remove it when performance benchmarking, as all the log messages will again make it slower...
< jonasschnelli> Yes. Sure
< jonasschnelli> jup.. its firing...
< jonasschnelli> I do now disable the logprintf and test again...
< promag> wumpus: regarding block.resize(blk_size);
< promag> filein.read((char*)block.data(), blk_size) will overwrite those zeros.. so I really don't get it
<@wumpus> what if it somehow fails
<@wumpus> my point is defense in depth here
< promag> you mean read fails?
<@wumpus> yes
< promag> then it shouldn't serve, it should fail?
<@wumpus> it should, but a bug might prevent that
<@wumpus> either a kernel bug or something else
< promag> ok, I wounder if it has performance impact regarding jonas bench
<@wumpus> only if you can measure a significant improvement of not zeroing I'm willing to argue about this further
<@wumpus> otherwise it seems pointless shed painting...
< jamesob> hm. If I'm gonna implement a threadsafe ring buffer for use with the async logging stuff, better to do that as a general module (a util sort of thing) or within a logging-specific module?
<@wumpus> jamesob: depends on how much work it is to make it general instead of specific, and how much extra code that brings. If not much, making it general is preferable of course.
< jamesob> wumpus: good advice, thanks
< sipa> wumpus, promag: is there even a way to resize a vector _without_ initializing the chars to 0?
<@wumpus> jonasschnelli: seems you merged https://github.com/jonasschnelli/bitcoincore-indexd/pull/1, I think we had to update it to include https://github.com/libbtc/libbtc/pull/127
<@wumpus> sipa: no :/
<@wumpus> so indeed, I don't know what the c++11 "nice" way to do that is, could use a unique_ptr to a new [] array instead of a vector, or something else, but nothing seems really elegant
< sipa> std::array :)
< sipa> which does not seem to require initializing the elements
<@wumpus> does that work for variable lengths?
< sipa> no
< spudowiar> How is someone actually supposed to say they know C++ when you might blink and we'll suddenly be on C++18428 and it'll look like some dialect of Python
< spudowiar> That looks perfectly safe and not at all a terrible hack
< cfields> sipa: I believe a std::vector with a custom allocator can
<@wumpus> spudowiar: yeah... language evolution is not a bad thing, and c++11 brings a lot of useful things, but c++ is alread such a crazy complex language, it's increasingly impossible to say you really know it.
< sipa> spudowiar: "folly" i would say
<@wumpus> yes it scares me, let's just zero the vector ok
< sipa> wumpus: ack
< jonasschnelli> wumpus: meh. yes. Let me push a subtree update then.
< promag> jonasschnelli: wumpus: should libbtc have a c++ job in travis?
< jonasschnelli> promag: yes. a little c++ test would be great.
<@wumpus> promag: I think for most intents and purposes it doesn't matter, for a C library, except the specific thing (`extern "C" {` in headers) you were changing
< promag> BlueMatt: I can rebase #13063 on master and leave walletmanager out for now
< gribble> https://github.com/bitcoin/bitcoin/issues/13063 | Use shared pointer to retain wallet instance by promag · Pull Request #13063 · bitcoin/bitcoin · GitHub
< BlueMatt> I mean I presume given the annoyance of moving forward with the loadwallet stuff we should do a minimal fix to get that through, and then we can clean it up as all that stuff matures
< promag> so you suggest to reopen #12647?
< gribble> https://github.com/bitcoin/bitcoin/issues/12647 | wallet: Fix possible memory leak in CreateWalletFromFile. by jimpo · Pull Request #12647 · bitcoin/bitcoin · GitHub
< promag> BlueMatt: annoyance? :)
< bitcoin-git> [bitcoin] sipa opened pull request #13185: Bugfix: the end of a reorged chain is invalid when connect fails (master...201805_bugfix_invalidchain_end) https://github.com/bitcoin/bitcoin/pull/13185
< bitcoin-git> [bitcoin] skeees opened pull request #13186: Use a semaphore to trigger shutdown procedures (master...shutdown-cv) https://github.com/bitcoin/bitcoin/pull/13186
< DrDraake> hey guys
< DrDraake> Don't know if this is the right channel. If someone has a offline bitcoin core wallet showing a balance and you can do not see the corresponding wallet on chain. If they send you a core to core transaction offline and you bring your core wallet online can that transaction confirm and previously they have sent the same amount of BTC to someone else who gets the BTC? Will it show in my wallet and when I go to spend it wil
< BlueMatt> DrDraake: you probably want #bitcoin, but, if a transaction is not mine-able and your node is synced, it will be displayed as "conflicted"
< BlueMatt> (probably)
< DrDraake> I'm trying to figure out how can this wallet send me BTC if I can not verify they have the coin to begin with....
< BlueMatt> you probably want #bitcoin, way more people there to help you out if you clarify what you want to do
< DrDraake> Thanks
< jnewbery> I think we should consider putting #10973 on high priority for review. So far it has full review from jamesob and me, and partial review from jeremyrubin.
< gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
< jnewbery> It's a large changeset (+1526,-670), so it's quite an involved review. I don't know if it makes sense to chop it up into smaller PRs (although logically, the intermediate commits don't really make sense unless we take the whole lot)
< jnewbery> Perhaps something to discuss at the next meeting
< promag> BlueMatt: could you take a look at #13063? ty
< gribble> https://github.com/bitcoin/bitcoin/issues/13063 | Use shared pointer to retain wallet instance by promag · Pull Request #13063 · bitcoin/bitcoin · GitHub
< promag> jnewbery: I was planning to see that one too
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bf9b03ddcc65...6b824c090f53
< bitcoin-git> bitcoin/master f30e9be David A. Harding: RPC Docs: gettxout*: clarify bestblock and unspent counts
< bitcoin-git> bitcoin/master 6b824c0 MarcoFalke: Merge #13184: RPC Docs: gettxout*: clarify bestblock and unspent counts...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13184: RPC Docs: gettxout*: clarify bestblock and unspent counts (master...2018-05-rpc-help-bestblock) https://github.com/bitcoin/bitcoin/pull/13184
< jamesob> when writing a class that mimics a vector, should our naming conventions take precedence over interface imitation? e.g. PushBack vs. push_back
< skeees> if you're just adding something that exists in a future std (e.g. c++17) then preference is to maintain api compatibility
< jimpo> Friendly reminder: #12254 is still ready for review
< gribble> https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
< luke-jr> BlueMatt: what timeframe do you need it in? been meaning to rebase/address stuff for a week or so now..
< satwo> Hi all, wasn't able to get a clear answer in #bitcoin, so thought I'd ask here: Why is nSequence an input-level field while nLockTime is transaction-level, and what happens when there are multiple inputs with different nSequence values?
< luke-jr> satwo: originally, or today?
< satwo> luke-jr Today, though if evolution of the protocol would shed light on it I'd be interested in that too.
< fanquake> eklitzke Any chance you can rebase #12744 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/12744 | WIP: eliminate dependency on boost::program_options by eklitzke · Pull Request #12744 · bitcoin/bitcoin · GitHub