< rusty>
Pretty sure that was a .bitcoind dir from an older bitcoind.
< aj>
rusty: hey, i can duplicate that
< aj>
rusty: try https://pastebin.com/QfjsEHFK to reproduce -- bug seems to be in validation.cpp::RewindBlockIndex where pindexIter->nTx or nChainTx gets set to 0, but not real sure what the fix should be
< wangyuan>
test
< Varunram>
rusty: aj: had the bugs few days back, turned out to be exactly what rusty specified, there'd be another .bitcoin directory somewhere. Once I changed home directories, it went well
< Varunram>
bug*
< aj>
Varunram: yeah, i think it'd be triggered by an old regtest blockchain from before #11389 got merged
< gribble>
https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest (sipa, ajtowns, jnewbery) by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub
< Varunram>
aj: Thanks! I was looking for that commit, couldn't find it
< wumpus>
I'm completely lost with regard to PRs once again - anything ready for merge?
< jonasschnelli>
wumpus: I think a lot of "unfinished" PRs right now...
< wumpus>
yes...
< fanquake>
A few that could probably just be closed as well
< jonasschnelli>
fanquake: BTW. Thanks for your awesome work on closing / pinging on PRs!
< fanquake>
wumpus probably lost in that wormhole from earlier :p
< wumpus>
yes thanks fanquake :)
< fanquake>
jonasschnelli I try and keep on top of it. Have been wanting to ask you about your place for the coredev-tech site. Saw you put it up on GH?
< jonasschnelli>
fanquake: Yeah, The site is ugly (but simple). jnewbery will probably do some changes for the NY meeting.
< jonasschnelli>
(Which you are very welcome to join)
< fanquake>
jonasschnelli when is that, might see if I can come along? I'm waiting for a meetup down here heh
< jonasschnelli>
fanquake: Australia is on the list,.. :) I'm not sure about the NY one... you need to ask jnewbery. Not sure if the exact date stays.. Guess it's in March 18
< jonasschnelli>
Not announce yet
< fanquake>
jonasschnelli cool. Good chance to discuss any potential iOS development work as well.
< aj>
"next one in NYC the week of March 5th 2018"
< jonasschnelli>
aj: Thanks!
< jonasschnelli>
fanquake: Yeah. Though, I won't attend. Schedule-colision.
< wumpus>
this is what we should avoid: https://github.com/bitcoin/bitcoin/pull/11747 the person posts a straightforward two-line fix for an actual issue, when well-meaning but overly zealous review comments get them to refactor things in a questionable way resulting in much more discussion and doubt of correctness
< fanquake>
jonasschnelli no worries
< wumpus>
if something fixes a problem, please just utACK it, if you want to refactor it to your personal taste later then go ahead but that's not part of review
< wumpus>
now we have yet another PR that is stuck...
< jonasschnelli>
wumpus: indeed.
< bitcoin-git>
[bitcoin] fanquake closed pull request #9859: Make TestBlockValidity optional in CreateNewBlock (master...tbv-optional) https://github.com/bitcoin/bitcoin/pull/9859
< fanquake>
I've always wondered how best we could keep tracked of post merge nits/minor fixups. Maybe another tag that we can add to PRs post merge which have any todos remaining in the comments? Then occasionally someone can sweep through and "clean up" stuff.
< wumpus>
fanquake: I think MarcoFalke added the "up for grabs" tag for that
< fanquake>
If GitHub search was a bit better it mightn't be such as issue.
< aj>
commits that sweep through and clean up stuff are generally pretty painful though, aren't they?
< wumpus>
yes, they are
< fanquake>
wumpus I mean PRs that have been merged, but with outstanding todos. Rather than just abandoned. I guess they are somewhat the same.
< wumpus>
fanquake: if they have important TODOs that warrants an issue of its own, if not, better to forget about it sometimes
< wumpus>
if no one cares to remember it
< fanquake>
Is it more painful than not having obvious fixes easily merged
< raheel_>
?HELP
< fanquake>
wumpus fair enough. I guess they get picked up again eventually anyways.
< wumpus>
for criticial concerns with something that is merged always open an issue, that's what they're for
< raheel_>
I want to create wallet address in pphp
< wumpus>
raheel_: #bitcoin
< raheel_>
php
< raheel_>
any api ?
< wumpus>
raheel_, take this to #bitcoin
< jonasschnelli>
raheel_: this is the core dev channel, pleae use #bitcoin or #bitcoin-dev for your Q
< wumpus>
read the topic for a change
< fanquake>
Thoughts on #9754 ? This is the second or third time this PR has been opened, hasn't ever gotten any real discussion
< wumpus>
aj: don't know about others, but I'm not really a fan of bots personally, they generate a lot of extra notification. We had a "pull tester" bot once, you know.
< wumpus>
I like how travis integration doesn't generate a message, just shows the status inline
< aj>
wumpus: no, didn't know. how was the "pull tester" different to travis now?
< wumpus>
it posted a message if the tests failed/passed
< aj>
wumpus: ah, so same idea, just differnt github hook?
< wumpus>
I guess so, it was a project specific solution. travis is generic
< Provoostenator>
Coveralls can be configured to post the result like Travis does and not leave comments.
< Provoostenator>
Maybe the other bots can be too.
< wumpus>
if so I have no problem with them
< wumpus>
aj: anyhow that article seems interesting
< bitcoin-git>
[bitcoin] laanwj opened pull request #11783: Fix shutdown in case of errors during initialization (master...2017_11_notify_callbacks_shutdown_crash) https://github.com/bitcoin/bitcoin/pull/11783
< Provoostenator>
I don't think it's related to the minimum relay fee, as even a 0.1 BTC fee doesn't help.
< Provoostenator>
I probably broke something about the nodes in the test setup, but it would be nice if I can reveal some sort of P2P error message to get a clue what I broke.
< Provoostenator>
E.g. can I access log files of the test nodes?
< wumpus>
timeout problems are notoriously annoying to debug
< wumpus>
yes, you can, it prints the test directory at start
< wumpus>
inside that are the data directories for the nodes
< wumpus>
also pass --nocleanup to not clean up
< Provoostenator>
Ah yes, that's very useful.
< wumpus>
there's also test/functional/combine_logs.py to merge the test log with logs of multiple nodes
< wumpus>
(to show one timeline)
< Provoostenator>
I'm seeing an AddToWallet entry in the logs for the node that created the transaction, but no obvious error messages after that related to propagating it to the other peer.
< Provoostenator>
The other node has a "got inv: tx" entry for the same tx
< Provoostenator>
And no obvious error either.
< Provoostenator>
mempool.dat is empty for the other node though
< Provoostenator>
So I’m looking for debut messages that might explain why a node receives a transaction, but doesn’t add it to its mempool.
< instagibbs>
Provoostenator, you may have to set debug=p2p, if you haven't yet
< Provoostenator>
instagibbs: is that a flag to pass to the test node?
< Provoostenator>
--tracerpc is quite useful too, although in this case it just shows that the second node's mempool is indeed empty every time sync_mempools looks at it
< instagibbs>
Provoostenator, yes, `debug=X` is the general purpose logging argument
< Provoostenator>
Ok, that seems to add a bit more detail. So the node which doesn't update its mempool log says: "received: inv (37 bytes) peer=1", "got inv: tx b4e9...f354 new peer=1"
< Provoostenator>
I'll turn on some more debug options...
< jonasschnelli>
Only after reading the code I know it's possible (if (logfile.is_absolute()) {)
< jonasschnelli>
*knew
< jonasschnelli>
But maybe it's obvious
< blockchain>
hi I have installed bitcoin-core 15.01 and want to use the replace by fee. but the "increase transaction fee" option is grey, how can i activate it ?
< jonasschnelli>
blockchain: better use #bitcoin for this... off-topic here.
< blockchain>
ok didnt know where to ask
< jonasschnelli>
wumpus: every tried ODROID-XU4 with Core?
< sipa>
jonasschnelli: i'm syncing on an odroid-c2 currently
< Masterboy>
jonasschnelli, sync speed is really bad on my core i3 pentium 300mbit connection
< Masterboy>
it took me days to sync from the start
< jonasschnelli>
Masterboy: dbcache how large?
< Masterboy>
and the ping and speed to other clients was like 1/mbit
< Masterboy>
wait i will see
< Masterboy>
now it is crawling slow
< Masterboy>
client 0.15.1
< jonasschnelli>
Masterboy: network speed doesn't matter that much. What matters is CPU speed for signature verification, a.s.o. Disk speed is also important for the UTXO set read/writes.
< jonasschnelli>
Make sure you use a large dbcache which can make a significant improvement
< sipa>
jonasschnelli: running with dbcache=450 maxmempool=10
< sipa>
default settings made it OOM
< jonasschnelli>
sipa: but you have 2GB, right?
< jonasschnelli>
maybe the maxmempool->dbcache-during-IBD-change is a OOM-problem for such systems
< sipa>
the total RSS was totally within expected ranges
< sipa>
it's more a question of what else was using memory i guess
< sipa>
but i haven't investigated
< jonasschnelli>
running with X?
< Masterboy>
jonasschnelli, sorry it take some time to load btc-qt like 10 min now. i am loading it from a hdd 700gb
< sipa>
jonasschnelli: yes, with a 4k screen - maybe that causes a lot of video memory
< jonasschnelli>
sipa: go headless!
< sipa>
yes, i should
< Masterboy>
jonasschnelli, how can i find out the dbcache value?
< sipa>
Masterboy: #bitcoin
< jonasschnelli>
4k screen. ;-)
< Masterboy>
ok default is 450 i see in the manual
< sipa>
my tv was the only screen i had available with an HDMI port
< Masterboy>
jonasschnelli, so how can i make it faster? what should i set for a 300mbit connection?
< Masterboy>
jonasschnelli, cpu is 2.4ghz
< jonasschnelli>
Masterboy: please answer in the #bitcoin channel
< BlueMatt>
sipa: I highly recommend headless c2s, you can now build upstream kernels from released branches and upstream u-boot and things work :)
< BlueMatt>
no closed-source drivers needed
< BlueMatt>
(closed source tool needed to convert u-boot build to binary image, sadly, and it does have a close-source first boot loader stage)
< cfields>
Chris_Stewart_5: ugh, sorry. I promised you at Stanford that I'd take a look at that again, and never did.
< cfields>
adding it to my review queue.
< BlueMatt>
Chris_Stewart_5: I believe its still blocked on gcc 4.9, no?
< BlueMatt>
jnewbery: seemed to think so, at least
< BlueMatt>
(we currently only require 4.8)
< Chris_Stewart_5>
cfields: It's fine! I just like to make shameless plugs when I can.
< * BlueMatt>
still has it marked as "awaiting gcc bump"
< Chris_Stewart_5>
BlueMatt: I'm far from an expert on the build system, but can we make it only build if we have a >= 4.9 compiler?
< Chris_Stewart_5>
it was my understanding that 4.8 is going to be around for awhile
< BlueMatt>
4.8 is some debian thing, right?
< BlueMatt>
like oldstable?
< cfields>
that's what we just did for DEBUG_LOCKORDER, so that sounds like fair game to me
< BlueMatt>
true
< cfields>
Trusty is 4.8 too
< BlueMatt>
ah, an ubuntu thing
< BlueMatt>
oldstable appears to be 4.9
< sipa>
what feature in 4.9 is needed?
< BlueMatt>
heh, trusty doesn't die until 2019
< BlueMatt>
man I'm so glad ubuntu shortened their supported cycle
< Chris_Stewart_5>
sipa: See the pull request. The library I'm using uses lambda's heavily
< Chris_Stewart_5>
apparently there is an issue with parameter packs
< cfields>
variadic lambdas? I thought that was a c++14 (or higher?) thing
< cfields>
oh, maybe that's a variadic in the callback definition as opposed to unpacking inside the lambda
< MarcoFalke>
nanotube: Ah, so the config is not in the repo... Have you enabled the Scheduler plugin? If so, mind adding a repeat every seconds=7*24*60*60 with a message of 'Meeting in ~30min' (first time at around 18:30UTC next Thursday)?
< MarcoFalke>
cfields: yeah travis is on trusty.
< MarcoFalke>
And I'd prefer to have it run on travis. Or at least compile
< sipa>
Chris_Stewart_5: it looks like it's a c++11 feature that's just buggy in gcc 4.5-4.8
< sipa>
cfields: ^
< MarcoFalke>
Jup, it is a bug in gcc4.8 that was never fixed (or backported)
< cfields>
MarcoFalke: well we could always work around that. The issue is what we consider to be the minimum for building.
< BlueMatt>
cfields: werent you gonna get us a depends-built gcc by 0.15 :p
< MarcoFalke>
Jup, could use that as work-around and keep min-gcc at 4.8
< cfields>
BlueMatt: yea, I just started messing with it again. Still unclear, though, whether we should go the gcc or clang route :(
< BlueMatt>
i thought we were going the "trusting trust" route :p
< BlueMatt>
(ie: both)
< cfields>
BlueMatt: both available for use? or use them to compile each-other, then use 1 of the resulting ones?
< BlueMatt>
the second
< cfields>
yea, even if we use clang for everything, we'll still want to build it with gcc at least once.
< promag>
it could be overloaded: std::string GetArg(const std::string& strArg) const; and there it would assert(IsSet(strArg))
< meshcollider>
yeah true, probably out of scope for this PR though :)
< meshcollider>
Also re: same PR, I'm unsure about the change you suggested to files.md, because even nodes running 0.16.0 will use the old file location if its an upgrade not a new install
< meshcollider>
if I move it to a "Only used in pre-0.16.0" section, users may not realise that