< gmurf> any good places to learn how to use Bitcoin api
< rusty> Latest master branch, bitcoind in regtest mode: bitcoind: validation.cpp:4203: void CheckBlockIndex(const Consensus::Params&): Assertion `(pindexFirstNeverProcessed != nullptr) == (pindex->nChainTx == 0)' failed.
< 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
< bitcoin-git> [bitcoin] laanwj closed pull request #11722: Switched sync.{cpp,h} to std threading primitives. (master...tjps_sync_antiboost) https://github.com/bitcoin/bitcoin/pull/11722
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/9754 | Change NULLFAIL => SIG_NULLFAIL. by richardkiss · Pull Request #9754 · bitcoin/bitcoin · GitHub
< raheel_> hii
< wumpus> fanquake: it seems it doesn't really bother anyone but him
< fanquake> I think I'm just going to close it again.
< bitcoin-git> [bitcoin] fanquake closed pull request #9754: Change NULLFAIL => SIG_NULLFAIL. (master...feature/unify_sig_nullfail) https://github.com/bitcoin/bitcoin/pull/9754
< fanquake> re ready to merge. Maybe #11647 if you wanted to verify the backports.
< gribble> https://github.com/bitcoin/bitcoin/issues/11647 | 0.15: Backports by MarcoFalke · Pull Request #11647 · bitcoin/bitcoin · GitHub
< wumpus> agree with closing, I see no way forward for that PR
< aj> wumpus, fanquake: maybe having a 'highfive' bot would be an interesting idea to pursue? (auto welcome new contributors, assign reviewers, complain about lacking tests, modifying unsafe code, etc) http://sarah.thesharps.us/2016/11/17/impact-of-bots-on-github-communities/
< wumpus> I think we should add cfields's #11457 to high priority for review, to make sure his net refactoring work can move forward
< gribble> https://github.com/bitcoin/bitcoin/issues/11457 | Introduce BanMan by theuni · Pull Request #11457 · bitcoin/bitcoin · GitHub
< 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 #11781: Add `-debuglogfile` option (master...2017_11_logfile) https://github.com/bitcoin/bitcoin/pull/11781
< 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
< bitcoin-git> [bitcoin] laanwj closed pull request #11287: DRY config header inclusion (master...refactor/dry-config) https://github.com/bitcoin/bitcoin/pull/11287
< promag> wumpus: I'm going to test #11783 rebased with #11781
< gribble> https://github.com/bitcoin/bitcoin/issues/11783 | Fix shutdown in case of errors during initialization by laanwj · Pull Request #11783 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11781 | Add `-debuglogfile` option by laanwj · Pull Request #11781 · bitcoin/bitcoin · GitHub
< wumpus> thanks!
< promag> wumpus: bitcoind -debuglogfile=/foo/bar/bar.log doesn't crash without 11783
< promag> > (currently this segfaults afterwards, but that is due to an unrelated problem introduced in #10286, see #11783)
< gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11783 | Fix shutdown in case of errors during initialization by laanwj · Pull Request #11783 · bitcoin/bitcoin · GitHub
< promag> doesn't segfault here
< wumpus> well that's good
< wumpus> still happens here
< wumpus> "src/bitcoind -debuglogfile=/dfdf" is enough to reproduce it immediately
< promag> wumpus: what I mean is that 11781 alone doesn't segfault, how could it segfault there?
< wumpus> I don't know, maybe a subtle configuration difference?
< gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
< wumpus> so it calls UnregisterValidationInterface(0) . I don't see how that could not segfault.
< promag> wumpus: sorry my bad, forget to git checkout . after git reset HEAD~1
< wumpus> hah!
< wumpus> what would be a good functional test to add the -debuglogfile= test in? can create a new one but it seems kind of overkill
< wumpus> none itseems, I'll just create a new one
< Provoostenator> In an RPC test, how would I go about debugging why sync_mempools times out, after a succesful sendrawtransaction?
< 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> "<category> can be: net, tor, mempool, http, bench, zmq, db, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb"
< instagibbs> oh sorry, so it's "net"
< 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...
< sipa> there is also -debug=all
< Provoostenator> Even -debug-all doesn't tell me anything useful. Here's the combined log: https://gist.github.com/Sjors/f887722422f49144fe9b97cee9fef836
< Provoostenator> Interestingly the same transaction (ca43...) is sent twice, even though only one test is run.
< luke-jr> Provoostenator: -debug=all is not -debug-all
< Provoostenator> luke-jr: that was a typo in IRC only.
< Provoostenator> The test framework shows a warning if you use an unsupported debug category.
< MarcoFalke> nanotube: Where is the gribble code hosted that runs in this channel?
< MarcoFalke> nanotube: https://github.com/nanotube/supybot-bitcoin-marketmonitor is only for the market, no?
< jonasschnelli> wumpus: Would it make sense to mention absolute paths are possibbe in #11781 (in the release notes or the init.cpp part)?
< gribble> https://github.com/bitcoin/bitcoin/issues/11781 | Add `-debuglogfile` option by laanwj · Pull Request #11781 · bitcoin/bitcoin · GitHub
< 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
< jonasschnelli> sipa: Oh. What storage?
< sipa> 128 GB microsd card, pruned
< jonasschnelli> sipa: okay. Happy to hear more... (sync speed, corruptions)
< sipa> i just started maybe 10 hours ago
< sipa> ask me again in a week :)
< jonasschnelli> I'd say in 3 days. :)
< 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)
< nanotube> MarcoFalke: that repo you linked contains a bunch of the plugins, but the core of the bot is https://github.com/nanotube/supybot_fixes
< MarcoFalke> nanotube: I was specifically looking for the code that does this: #1337
< gribble> https://github.com/bitcoin/bitcoin/issues/1337 | Quieter initial block download by rebroad · Pull Request #1337 · bitcoin/bitcoin · GitHub
< nanotube> MarcoFalke: ah, that's the MessageParser plugin :) the actual function to spit out issues is just config in the plugin
< cluelessperson> I'm sorry to annoy you, is there an ETA on Core segwit support in the QT wallet?
< sipa> cluelessperson: when it's done
< sipa> cluelessperson: we never have the ability to set ETAs on features, as they depend on review, which is done by people volunteering their time
< cluelessperson> sipa: how can I help? (I don't know C++)
< sipa> cluelessperson: you can help by testing it for sure
< cluelessperson> sipa: can you lead me through what I need to do?
< cluelessperson> maybe I can gain some experience and help more on my own in the future
< sipa> can you compile from sourcr?
< cluelessperson> yes
< sipa> well the hardest part of being a good testing is figuring out what are good scenarios to test
< sipa> identifying potential edge cases
< cluelessperson> I figure I could try to test everythign on testnet
< Chris_Stewart_5> *something something* #8469 *something something*
< gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
< 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.
< cfields> Chris_Stewart_5: have you tried with a very recent rapidcheck, as opposed to what's shipped by distros?
< MarcoFalke> lol, what disto ships that?
< MarcoFalke> Aren't we fetching the code from the git directly?
< Chris_Stewart_5> cfields: I did not see that and MarcoFalke yes. IIRC someone created a .mk file for it
< cfields> oh, i assumed distros packaged it so we could use a local copy. nm.
< MarcoFalke> I did ;)
< Chris_Stewart_5> hah I thought it was you.
< Chris_Stewart_5> cfields: I'll look at that later and see if I can just use that hack instead of having to do all this extra work
< Chris_Stewart_5> thanks!
< cfields> Chris_Stewart_5: well it's pretty old, so I assume it's not enough
< cfields> (I was thinking you were testing with a stale distro package)
< cfields> yea, your commit includes the hack
< meshcollider> promag: are you here?
< promag> y
< meshcollider> what would you suggest I put there instead?
< promag> I thought this was true: std::string GetArg(const std::string& strArg, const std::string& strDefault="") const;
< promag> Because your code is inside if (gArgs.IsArgSet("-walletdir") ...
< promag> So this would look better gArgs.GetArg("-walletdir")
< meshcollider> iirc GetArg didn't default to empty string?
< promag> right, it doesn't
< 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
< promag> just say:
< meshcollider> yep
< promag> * db.log: wallet database log file; replaced by wallets/ directory in 0.16.0 for fresh installs?
< promag> or something?