< 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
< 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/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 127.0.0.1?
< jonasschnelli>
Seems like whitelist=127.0.0.1 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=127.0.0.1:8333 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
< 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>
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
< 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
< 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
< 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.
< 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
< 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
< 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 ?