--- Day changed Fri Dec 16 2016
00:08 < gmaxwell> I currently have a node running 8695, 8808, 9039, 9045, 9125, 9138, and 9199 ... surprisingly all applied without conflict.
00:08 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jucasrbtrbilyprl] has joined #bitcoin-core-dev     
00:15 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has joined #bitcoin-core-dev     
00:16 < NicolasDorier> When I do "fundrawtransaction" followed by a "getnewaddress" I noticed the generated address and the change of funrawtransaction are the same
00:16 < NicolasDorier> is it on purpose ?
00:17 < NicolasDorier> it is like funrawtransaction does not increment the index for generating the next address
00:17 < NicolasDorier> I can do a getnewaddress manually after FundRawTransaction, but first I would like if it is on purpose
00:19 < bitcoin-git> [bitcoin] kallewoof opened pull request #9361: Fix: OSX compile fix: defer to bswap_XX when defined. (master...macosx-qt-build-fix) https://github.com/bitcoin/bitcoin/pull/9361
00:22 < jonasschnelli> NicolasDorier: thats right. Fundrawtransaction does not keep the reserve key.
00:23 < NicolasDorier> what about adding a new parameter to fundrawtransaction for it to be the case ? I don't want same key used twice by mistake
00:23 < jonasschnelli> NicolasDorier: what you can and should do is call getrawchangeaddress and use this with fundrawtransaction (you can specify a change address there)
00:23 < NicolasDorier> ah     
00:23 < NicolasDorier> yes     
00:23 < NicolasDorier> will do that thanks
00:23 < jonasschnelli> NicolasDorier: yes. We should do that-.
00:23 < jonasschnelli> It feels llike a serious bug
00:23 < jonasschnelli> I'm opening an issue
00:23 < NicolasDorier> thanks
00:32 -!- amiller_ [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev     
00:33 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
00:34 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 250 seconds]     
00:42 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 250 seconds]     
00:43 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
00:44 -!- Alina-malina [~Alina-mal@37.157.216.188] has joined #bitcoin-core-dev     
01:15 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer]     
01:16 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
01:19 < bitcoin-git> [bitcoin] rebroad opened pull request #9363: Don't provide blocktxns for old blocks on a fork. (master...MinChainWorkBlocktxns) https://github.com/bitcoin/bitcoin/pull/9363
01:20 -!- rebroad [~rebroad@171.4.234.111] has joined #bitcoin-core-dev     
01:32 < gmaxwell> rebroad: you know you can run all the tests that travis runs locally?
01:36 < rebroad> gmaxwell, I assumed it was possible, although I have not yet worked out how to make it do so... I chose the --enable-extended-rpc-tests on the configure, but then couldn't work out what to do following that.
01:37 < rebroad> and anyway, "make check" is failing on my system... I raised an issue for it.
01:38 < rebroad> gmaxwell, what prompted you to mention the travis tests?
01:40 < rebroad> (well, 9 times out of 10 - re "make check")
01:40 < gmaxwell> rebroad: number of failing test on PR opens from you suggested to me that you weren't aware you could run them locally. (e.g. I follow the link when the bot mentions it in IRC and its failed already). 
01:41 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
01:41 < rebroad> gmaxwell, how do I run them locally please? (I am re-reading the docs now, but have not seen this info as yet)
01:42 < rebroad> my latest PR seems to have works all except for fundwartransaction.py (https://travis-ci.org/bitcoin/bitcoin/jobs/184479440)
01:42 < rebroad> and that failed only on 1 of the 6 platforms
01:43 < rebroad> I'm assuming if I run the tests locally it only tests my own platform
01:43 < gmaxwell> RE your latest PR, the same behavior exists for blocks it is pointless to be much more restrictive there for getblocktxn than blocks themselves. Also, we don't want to fail to reply to a getblocktxn we might have just offered by sending a compact block and then immediately having a reorg, as that will dos attack our peer.  For the code that avoids fingeringprinting with blocks search for "To pre
01:43 < gmaxwell> vent fingerprinting" in net_processing.cpp.
01:46 < rebroad> gmaxwell, "same behavior exists for blocks" - same behavior as what? For blocks it checks if it is more than 1 month old - quite different logic than is used for getblocktxns
01:46 < rebroad> it also checks if it is in the activechain - it doesn't do this for getblocktxns
01:46 < gmaxwell> rebroad: well you may not be able to test osx locally, though you could test windows if you wanted.  You can actually see exactly what travis runs by looking in the file .travis.yml   but the relevant command is qa/pull-tester/tpc-tests.py
01:46 < rebroad> for getblocktxns (from what I can tell) it checks if the height it within a certain height - a height comparison
01:47 < rebroad> gmaxwell, thanks (re rpc-tests.py) runnnig it now.. somewhat obscure command which I would not have tried unless told
01:47 < gmaxwell> rebroad: yes but there is no point for the purpose of avoiding fingerprinting in making the test there _more_ restrictive than the one for blocks.
01:48 < wumpus> rebroad: https://github.com/bitcoin/bitcoin/tree/master/qa on running qa tests locally
01:49 < wumpus> (this is all linked from the main README.md, you should have no problem finding this documentation if you bothered looking even casually)
01:53 < wumpus> I'm disappointed that you're constantly submitting issues and even pull request while you apparently don't even know how to run the tests
01:53 < rebroad> wumpus, I see the section now - yes, it is there - not sure how I missed it last time
01:56 < rebroad> I don't know when that info was added but it wasn't in there when I last read it - I'm not sure how often I am expected to re-read the README file
01:56 < jonasschnelli> Also, rebroad: you can setup travis for your own development branch
01:56 < jonasschnelli> (in case you open PRs to have them run though travis)
01:56 < wumpus> it was there for a long time, has been updated a few times
01:57 < rebroad> jonasschnelli, that would be very useful indeed. thanks
01:57 < jonasschnelli> Just head to http://travis-ci.org
01:57 < wumpus> and yes you're supposed to keep up to date with the (extrememly minimal) development documentation if you do development
01:57 < jonasschnelli> and enable you rebroad/bitcoin repo
02:01 < rebroad> jonasschnelli, it appears I enabled travis for my rebroad/bitcoin more than 9 months ago. I have just revisited it now, but so far am struggling to understand the interface
02:01 < jonasschnelli> understand travises interface?
02:01 < wumpus> travis, too, has documentation
02:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:03 < wumpus> it looks like the fundrawtransaction.py test is flaky at the moment
02:05 < rebroad> running the extended tests locally fundrawtransaction.py passed, but walletbackup.py failed!
02:05 < jonasschnelli> wumpus: what do you think about https://github.com/bitcoin/bitcoin/issues/9362, it surprises me that nobody has complained about address reuse so far.
02:05 < rebroad> my one line change doesn't touch things that either of those tests test
02:06 < wumpus> jonasschnelli: interesting - it's supposed to update the change address when it is actually used
02:07 < wumpus> jonasschnelli: apparently that logic doesn't work
02:07 < rebroad> gmaxwell, I am struggling to understand the context of what you are referring to. you mention a "more restrictive test" - but I am not sure which test you mean. The test was previously checking that the height was within 10 blocks from active-tip - it is still that test, but no longer assumes only one chain.
02:07 < rebroad> gmaxwell, by making that assumption it would respond to requests for any block of that height, whether on the active chain or not
02:07 < rebroad> (at least, this is my understanding from the code)
02:09 < rebroad> given the reason for the restriction was to avoid delving into old data and hard-disk read access, then the new check seems a better way, and doesn't apply any additional restrictions over the previous check (other than disallowing other chains where the work would have been much lower - therefore not a problem disabling this from what I can see)
02:10 < rebroad> if it is intentional to allow access to old blocks on alt chains, but not on the active chain, then I am at a loss why this would be intentional
02:11 < rebroad> my understanding is that as compact blocks relys on the memory pool, that old blocks on any chain are unnecessary
02:11 < wumpus> yes this is intentional, it avoids fingerprinting attacks
02:11 < rebroad> wumpus, it would allow fingerprint attacks, not avoid them
02:11 < wumpus> peers could fingerprint nodes based on what alt-chains they own - this is avoided now
02:12 < rebroad> wumpus, which PR are you referring to?
02:12 < rebroad> wumpus, my PR is a change that avoids fingerprinting. the current master allows it
02:12 < wumpus> I'm not refering to a PR, but to the reason that access is not allowed to old blocks on alt chains
02:13 < rebroad> wumpus, my PR stops access to old blocks on alt chains
02:13 < rebroad> in order to stop fingerprinting
02:13 -!- Alina-malina [~Alina-mal@37.157.216.188] has quit [Changing host]     
02:13 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
02:13 < wumpus> anyhow I can't reproduce the fundrawtransaction problem locally either
02:14 < rebroad> #9363
02:14 < gribble> https://github.com/bitcoin/bitcoin/issues/9363 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
02:14 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
02:15 < rebroad> in order for the fingerprinting to happen, a peer would need to be fed blocks on an alt chain until height within 10 from the current active tip 
02:16 < rebroad> then once that is done, a getblocktxn request would reveal the fingerprint
02:16 < rebroad> I have not tested this can be done, but from reading the code I believe it could
02:17 < rebroad> i would like to be able to write a test to show this - i need to become more familiar with the python tests to be able to do this. apologies if I am wrong about my assumption based on reading the code
02:18 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
02:19 < rebroad> and to be honest, I am not even sure what the big deal about fingerprinting is, but given it is coded to be protected against, I assumed this vector ought to be closed also
02:20 < wumpus> I don't understand why you write and submit a patch to do something that you don't even know it's a big deal?
02:20 < wumpus> why are you working on that at all, then?
02:20 < rebroad> I don't claim to know anything as Aristotle once said
02:20 < rebroad> I can go only on assumptions therefore
02:20 < wumpus> I just don't understand your motivation
02:21 < rebroad> wumpus, to help. what is your motivation?
02:21 < wumpus> either you believe fingerprint attacks are a serious attack vector and you try to improve mitigation of them, or you don't just leave the logic alone
02:21 < wumpus> for which change?
02:21 < rebroad> wumpus, for the project i mean
02:21 < wumpus> that's off topic here and certainly not something I want to get into
02:22 < rebroad> sorry, I answered assuming you were referring to the project, not the PR
02:22 < wumpus> the only thing relevant here is the motivation to make specific changes to the code, as you need that to convince other people to care about your change
02:23 < rebroad> wumpus, I assume that given anti-fingerprinting code is already in the code, then a sufficient number of core developers appreciate its importance. I didn't consider that I therefore needed to appreciate it also
02:23 < rebroad> I mean understand not appreciate
02:24 < rebroad> anyway, if I was wrong, and it's not important. I will close the PR
02:25 < rebroad> but it does make me question why it was important for blocks but not blocktxns
02:25 < wumpus> well your described angle is fine if you care about it: write a test that demonstrates it, then demonstrate that your code fixes that attack
02:25 < rebroad> wumpus, ok, I will get to work on that.. but before I do.. can anyone explain to me why fingerprinting attacks are bad?
02:25 < wumpus> if you don't, then don't waste your time
02:25 < rebroad> wumpus, because if they are not that bad, then it's a lot of effort for something trivial
02:26 < wumpus> if you don't think they are bad then donj't spend effort on it!
02:26 < rebroad> wumpus, lol.. ok
02:26 < wumpus> why do you need to be hand-held through every little thing
02:26 < rebroad> wumpus, it takes two to hold hands
02:27 < wumpus> fingerprinting has to do with privacy, especially over tor or other anonymity layers. Theoretically you should not be able to identify a peer connecting to you over tor, but with fingerprinting tricks you can.
02:27 < rebroad> wumpus, I mean that we both needed to understand each other to work out the way forward
02:27 < rebroad> wumpus, ah... thanks. i understand now in that context. thank you for explaining
02:28 < wumpus> if you can distinguish and thus identify peers sending you a transaction you gain information you shouldn't have
02:28 < wumpus> if you don't care about that, then well, don't
02:28 < rebroad> wumpus, based on that explanation, I shall work on creating that test you asked for
02:28 < wumpus> okay thanks
02:29 -!- JackH [~laptop@79-73-185-145.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
02:31 < wumpus> so fundrawtransaction.py test very regularly fails on travis with "Assertion failed: Mempool sync failed"
02:31 < wumpus> but I can't reproduce this locally
02:32 < luke-jr> timing maybe?
02:32 < wumpus> some recent change must have triggered it, it was not the case before
02:33 < jonasschnelli> wumpus: fundrawtx should not keep the CReserveKey, sendrawtx could, but what solutions do we offer for users broadcastign over different channels...
02:33 < jonasschnelli> Maybe we should add a call
02:33 < jonasschnelli> to reserve the used change key of a funded raw tx
02:33 < jonasschnelli> or to reserve a key by a specific address
02:33 < jonasschnelli> (and release)
02:33 < wumpus> jonasschnelli: well for broadcasting over separate channels we can't offer automatic change address functionality
02:34 < wumpus> jonasschnelli: unless there would be a way to tell the wallet of a transaction without broadcasting it
02:34 < jonasschnelli> ah,.. right.
02:35 < wumpus> right now the only way to tell the wallet is sendrawtransaction, which always broadcasts (walletbroadcast=0 setting won't help you there)
02:35 < jonasschnelli> I guess we should add detecting the change key in sendrawtx and make sure we reserve it from the keypool
02:35 -!- laurentmt [~Thunderbi@80.215.138.207] has joined #bitcoin-core-dev     
02:36 < wumpus> either that or indeed it should be an explicit step to reserve a change address, which should be returned if not used
02:36 < wumpus> this was overlooked in the fundrawtransaction design
02:38 < wumpus> fundrawtransaction doesn't even consistently fail in the same place (!)
02:38 < wumpus> I mean the test
02:38 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
02:39 < wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184431201 it's the sync_all on line 534 that fails
02:39 < wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184473580 it's the one on line 461
02:40 < wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184333528 it's line 449
02:40 < wumpus> the only commonality is that the fundrawtransaction.py test fails, and it happens while syncing mempools
02:41 -!- laurentmt [~Thunderbi@80.215.138.207] has quit [Quit: laurentmt]     
02:44 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
02:46 -!- rebroad_ [~rebroad@171.4.233.232] has joined #bitcoin-core-dev     
02:50 -!- rebroad [~rebroad@171.4.234.111] has quit [Ping timeout: 248 seconds]     
02:50 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
02:52 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
02:54 < bitcoin-git> [bitcoin] laanwj opened pull request #9365: [testing] Dummy commit for checking travis failure (master...2016_12_debug_travis_issue) https://github.com/bitcoin/bitcoin/pull/9365
02:54 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
02:55 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
02:57 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
02:58 -!- rebroad_ [~rebroad@171.4.233.232] has quit [Ping timeout: 268 seconds]     
02:59 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
02:59 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
03:00 < MarcoFalke> wumpus: The cause of test failure is most likely already known
03:00 < wumpus> MarcoFalke: what then?
03:01 < MarcoFalke> (see scrollback of yesterday evening)
03:01 < MarcoFalke> Might be some rounding in fee filter
03:01 < MarcoFalke> at the floor (i.e. minrelayfee)
03:02 < wumpus> can we work around this quicky to make travis pass again for unrelated pulls?
03:02 < MarcoFalke> Sure, I can try to settxfee in fundrawtx.py
03:03 < wumpus> reverting #9313 should help, then?
03:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
03:04 < wumpus> it started yesterday and the only pull merged yesterday affecting fees/feefilters is that one
03:04 < MarcoFalke> Yes, would help.
03:04 < MarcoFalke> But I'd like to get it in in another form then
03:05 < wumpus> well we need a temporary workaround to make travis sane agian, we can always merge it again once this issue is solved
03:05 < MarcoFalke> ok, fine w/ me
03:05 < wumpus> anyhow going to try in #9365
03:05 < gribble> https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
03:06 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
03:06 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
03:06 < wumpus> if travis will consistently pass with that reverted, I'm going to revert it on master too
03:07 < wumpus> in the mean time I've still managed to reproduce it locally 0 times - what makes this so special that it only happens on travis, I wonder
03:08 < wumpus> btw can anyone else get results from seed.bitcoin.sipa.be? it's been giving me nothing for something like two weeks now
03:08 < wumpus> but I've heard no one else compain about it
03:10 -!- rebroad_ [~rebroad@171.4.233.232] has joined #bitcoin-core-dev     
03:12 < jonasschnelli> wumpus: we have a bug in the seeder somewhere...
03:12 < jonasschnelli> I couldn't track it down.
03:12 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
03:13 < jonasschnelli> Seems to be introduced with the filtering option
03:13 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
03:13 < wumpus> jonasschnelli: okay - yes your testnet seed fails too
03:13 < jonasschnelli> Must be something with the cache... seeder is running but not results empty responses.
03:13 < jonasschnelli> (need to attach the debugger)
03:13 < jonasschnelli> But my long term plan is, to split the seeder in a crawler and a server
03:14 < jonasschnelli> As server, I'd like to use djbdns
03:14 < jonasschnelli> Shouldn't be that hard.
03:15 < wumpus> so it never returns results, or starts returning nothing after a while?
03:16 < wumpus> gah my dummy commit passed travis. Stupid heODODisenbug :)
03:16 < wumpus> heisenbug*
03:19 < btcdrak> wumpus: I also get no results from the seed, and I have complained about it on occasion
03:21 < MarcoFalke> wumpus: It should fail at most 25% of the time
03:24 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
03:25 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
03:27 < rebroad_> wumpus, my plan is to adapt the fingerprint test that (I presume) is already written to test that blocks cannot be fingerprinted - would you know which test file does that please? Is there a test already written to test fingerprint attacks at all?
03:28 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
03:28 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
03:29 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
03:41 < wumpus> btcdrak: okay, hadn't noticed then
03:41 < wumpus> MarcoFalke: that seems true on travis - but I'm running it locally in a loop, has run ~100 times or so, no failures
03:42 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
03:42 < wumpus> in any case #9365 seems to be consistently passing with #9313 reverted
03:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
03:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
03:43 < MarcoFalke> That is odd. I can no longer reproduce either. I surely saw it yesterday
03:44 < MarcoFalke> Nah, just failed
03:48 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
03:49 < MarcoFalke> rebroad_: qa/rpc-tests/p2p-compactblocks.py
03:52 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed]     
03:52 < rebroad_> MarcoFalke, I already checked that file - it seems to be a test for compact blocks - I was asking about the test that tests that old alt-chain full-blocks cannot be requested...  this would be the closest to the test I want to create
03:53 < rebroad_> MarcoFalke, thanks though
03:53 < rebroad_> these python tests are new territory for me.. so a bit of a learning curve..
03:54 < rebroad_> my goodness the pruning test seems to take a while to run...
04:02 -!- rebroad_ [~rebroad@171.4.233.232] has quit [Ping timeout: 258 seconds]     
04:10 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:23 < bitcoin-git> [bitcoin] kallewoof closed pull request #9361: [WIP] Fix: OSX QT compile fix: defer to bswap_XX when defined. (master...macosx-qt-build-fix) https://github.com/bitcoin/bitcoin/pull/9361
04:25 < bitcoin-git> [bitcoin] kallewoof opened pull request #9366: Fix: OSX QT compile: use built-in swap if available, or defer (master...macosx-qt-build-fix2) https://github.com/bitcoin/bitcoin/pull/9366
04:28 -!- e4xit [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Read error: Connection reset by peer]     
04:30 -!- e4xit [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
04:30 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
04:44 -!- Atomicat_ [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev     
04:45 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has quit [Ping timeout: 252 seconds]     
04:45 -!- Atomicat_ is now known as Atomicat     
04:50 -!- rebroad_ [~rebroad@180.183.200.133] has joined #bitcoin-core-dev     
05:11 < morcos> MarcoFalke: thanks... i just got a chance to sit down and look and i'd forgotten how fundrawtransaction sets exactly min_relay_tx_fee, but i think the way you fixed it makes the most sense.
05:17 -!- rebroad_ [~rebroad@180.183.200.133] has quit [Ping timeout: 265 seconds]     
05:23 < phantomcircuit> wumpus, can you tell me about commit e8ef3da7 ?
05:23 < phantomcircuit> it's from 2011 so im not expecting much
05:23 < phantomcircuit> commit message is just "update core to d0d80170a2ca73004e08fb85007fe055cbf4e411 (CWallet class)"
05:25 < phantomcircuit> nvm i see i should actually be asking sipa maybe?
05:26 < phantomcircuit> nvm i see i should be asking s_nakamoto
05:26 < phantomcircuit> :/     
05:45 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]     
05:49 -!- rebroad [~rebroad@2405:9800:b880:a1d0:70db:6875:af82:1a9c] has joined #bitcoin-core-dev     
05:50 < rebroad> gmaxwell, re this (https://botbot.me/freenode/bitcoin-core-dev/2016-12-15/?msg=78044110&page=4) - are you saying that one won't need a segwit wallet to spend a segwit tx?
05:50 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
05:54 < instagibbs> this is a bit #bitcoin but rebroad, you only need a segwit wallet to spend segwit outputs that you receive... but by definition you won't ask for them and receive legacy payments
05:54 -!- laurentmt [~Thunderbi@80.215.178.47] has joined #bitcoin-core-dev     
05:54 -!- laurentmt [~Thunderbi@80.215.178.47] has quit [Client Quit]     
05:56 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
05:57 < rebroad> instagibbs, ah. yes, makes sense. thanks.
06:02 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
06:03 < rebroad> gmaxwell, did zander change his article or did you misquote it? the sentence "So if a person doesn't upgrade they will eventually not be able to accept money from anyone." does not appear to be in the URL you posted on here
06:04 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
06:09 < bitcoin-git> [bitcoin] s-matthew-english opened pull request #9368: change to declarative sentences. simplify links (master...patch-13) https://github.com/bitcoin/bitcoin/pull/9368
06:18 < phantomcircuit> instagibbs, uh do you even need a segwit compatible wallet to spend segwit outputs?
06:18 < phantomcircuit> i didn't think you did
06:19 < phantomcircuit> i don't think you do actually 
06:20 < Chris_Stewart_5> phantomcircuit: Pretty sure you do, you won't be able to construct the tx in the proper structure without it
06:20 < phantomcircuit> the utxo entries aren't changes
06:20 < phantomcircuit> changed*
06:20 < phantomcircuit> you'd have to know that there is a transaction output in the utxo to begin with
06:20 < phantomcircuit> but if you have someone providing you transactions with the signatures stripped in normal format
06:20 < Chris_Stewart_5> segwit P2WPKH outputs require a empty script sig, and P2WSH requires a push only scriptSig of 32 bytes i think 
06:21 < phantomcircuit> ok?     
06:21 < phantomcircuit> so     
06:21 < phantomcircuit> you're talking about inputs not outputs
06:21 < phantomcircuit> which is what the person spending cares about
06:22 < phantomcircuit> i mean maybe it's not easy to do
06:22 < phantomcircuit> but you certainly should be able to
06:22 < Chris_Stewart_5> how doe thes person spending an output not care about the input? Isn't that by definition the inputs to the script program to make it evaluate to true?
06:23 < phantomcircuit> Chris_Stewart_5, why would they care about the inputs to a transaction they're spending the outputs of?
06:26 < Chris_Stewart_5> phantomcircuit: 'transactions stripped in normal format' -- so you mean someoen is just providing you a serialized tx to hash, then sign the hash?
06:33 < rebroad> phantomcircuit, if you have a non-segwit wallet, then you can spend any SegWit transaction... but it will never get mined :)
06:34 < rebroad> well, it could get mined by the 5% still on the non-segwit fork.. but would soon get orphaned
06:58 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Ping timeout: 258 seconds]     
06:58 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
07:06 -!- laurentmt [~Thunderbi@80.215.178.47] has joined #bitcoin-core-dev     
07:07 -!- laurentmt [~Thunderbi@80.215.178.47] has quit [Client Quit]     
07:10 < phantomcircuit> rebroad, why?
07:10 < phantomcircuit> the scriptPubKey is the same right?
07:10 < phantomcircuit> wait maybe it's not
07:10 < phantomcircuit> hmm     
07:11 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9369: Factor out CWallet::nTimeSmart computation into a method. (master...pr/atw-timesmart) https://github.com/bitcoin/bitcoin/pull/9369
07:16 -!- rebroad [~rebroad@2405:9800:b880:a1d0:70db:6875:af82:1a9c] has quit [Ping timeout: 240 seconds]     
07:17 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 240 seconds]     
07:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
07:20 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
07:32 -!- laurentmt [~Thunderbi@80.215.178.47] has joined #bitcoin-core-dev     
07:32 -!- laurentmt [~Thunderbi@80.215.178.47] has quit [Client Quit]     
07:39 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-xtfqkoxcqnmuakcm] has joined #bitcoin-core-dev     
07:43 < jonasschnelli> morcos: you once asked about a short description how the proposed spv-ish auxiliary block downloads works: https://github.com/bitcoin/bitcoin/pull/9171#issuecomment-267616678
07:44 -!- rebroad [~rebroad@223.206.10.89] has joined #bitcoin-core-dev     
07:50 < bitcoin-git> [bitcoin] laanwj closed pull request #9365: [testing] [donotmerge] Dummy commit for checking travis failure (master...2016_12_debug_travis_issue) https://github.com/bitcoin/bitcoin/pull/9365
07:52 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
08:08 < phantomcircuit> rebroad, yeah i still dont see why you wouldn't be able to spend outputs from a segwit transactions with a normal transaction
08:08 < phantomcircuit> the only thing being changed is the serialization of the script
08:10 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9e00591cd3f...8c7947e09ff8
08:10 < bitcoin-git> bitcoin/master fa16b8f MarcoFalke: If we don't allow free txs, always send a fee filter (take 2)
08:10 < bitcoin-git> bitcoin/master 8c7947e Wladimir J. van der Laan: Merge #9367: If we don't allow free txs, always send a fee filter (take 2)...
08:10 < bitcoin-git> [bitcoin] laanwj closed pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
08:18 < instagibbs> phantomcircuit, if your wallet doesn't understand segwit, it has no idea how to sign, if nothing else
08:18 < instagibbs> (sorry missed convo)
08:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
08:27 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 264 seconds]     
08:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
08:30 < rebroad> phantomcircuit, segwit as I understand is an extra bunch of rules that pre-segwit wallets have no knowledge of... pre-segwit wallets simply see segwit txs as txs that anyone can spend, so the only thing pre-segwit wallets can do is treat them as such, which segwit wallets and miners will reject as it ignores the segwit rules
08:33 < sipa> rebroad: no wallet does anything with outputs they do not understand
08:33 < sipa> *nodes* will treat those outputs as anyonecanspend, yes
08:33 < sipa> but wallets don't
08:34 < sipa> your wallet does not show you all anyonecanspend outputs on the network now, right?
08:34 < sipa> the only way you will receive a segwit output is if you give out a segwit address, which will only happen if your wallet supports it
08:35 < rebroad> sipa, well, nodes, and modified pre-segwit wallets ;)
08:36 < sipa> sure
08:36 < sipa> they can try
08:36 < sipa> but they won't confirm
08:36 < rebroad> sipa, if they did confirm, miners would build upon those blocks
08:37 < rebroad> at least, pre-segwit activation anyway
08:37 < rebroad> but people would have to be a little foolish to create such a tx pre-segwit
08:37 < sipa> pre-activation you shouldn't be creating segwit outputs
08:37 < sipa> that's very dangerois
08:41 -!- face_ [~face@mail.hmel.org] has joined #bitcoin-core-dev     
08:42 < Victorsueca> creating a segwit transaction without miners and nodes enforcing segwit yet can potentially lead to anyone-can-spend outputs
08:43 < sipa> not potentially
08:43 < sipa> by definition, they will be anyonecanspend outputs
08:43 -!- face_ is now known as face     
08:45 < rebroad> they need to be anyonecanspend outputs for segwit to be possible
08:49 < Victorsueca> just had a quick thought about this....
08:51 < Victorsueca> let's say the last block in a 2016 block period is the one that decides if segwit activates in that moment or it will in the next period (or even, hopefully not, never)...
08:52 < Victorsueca> and with that block it reaches 95% required to activate it
08:52 < sipa> that's not possible
08:52 < sipa> there is another 2016 block before it activates
08:52 < Victorsueca> ahh right
08:53 < sipa> the 95% makes it go to the LOCKEDIN state
08:53 < Victorsueca> welp, that solves it pretty much
08:54 < Victorsueca> my quick thoughts don't make sense most of the times.... but last time one of them made sense it was a disaster
09:01 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9370: Fix fundrawtransactions address-reuse problem (master...2016/12/fix_frt_cop) https://github.com/bitcoin/bitcoin/pull/9370
09:11 < jonasschnelli> I would say that #9370 (or one of the alternative solutions) is a candidate for a 0.13.2 backport.
09:11 < gribble> https://github.com/bitcoin/bitcoin/issues/9370 | Fix fundrawtransactions address-reuse problem by jonasschnelli · Pull Request #9370 · bitcoin/bitcoin · GitHub
09:18 < phantomcircuit> instagibbs, you're signing the new transaction not the old one
09:18 < phantomcircuit> rebroad, that's not saying that the wallet needs to understand segwit
09:18 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:18 < phantomcircuit> just that it needs to get the utxo entries from somewhere other than the transaction data
09:19 < phantomcircuit> wait no
09:19 < phantomcircuit> the SIGNATURE isn't needed by the person spending
09:19 < phantomcircuit> yeah im 99.99% sure you're wrong
09:20 < phantomcircuit> sipa, segwit doesn't change the outputs at all, just the inputs with the signature
09:20 < phantomcircuit> or does it and i am just very tired and hungry
09:22 < sdaftuar> phantomcircuit: see BIP 141.  segwit outputs are constructed differently than non-segwit outputs.
09:22 < phantomcircuit> hmm     
09:23  * phantomcircuit goes to find a thermometer
09:26 < gmaxwell> rebroad: he changed the text, many times. Last I checked the current text was still wrong as heck.
09:28 < phantomcircuit> 101...
09:28 < phantomcircuit> ok then
09:29 < phantomcircuit> oh right
09:29 < Victorsueca> 101ºC?
09:29 < Victorsueca> ;)     
09:30 < sipa> phantomcircuit: p2sh witness outputs are indistinguishable to the network from other p2sh outputs
09:30 < sipa> but they are distinguishable to the receiver... who either knows the redeemscript and how to spend it, or not
09:31 < phantomcircuit> sipa, it's the same as p2sh originally right
09:31 < phantomcircuit> and is because of the change to the signature hashing basically meaning it's a "new" script language
09:31 < Victorsueca> basically you can't know whether it is P2SH, P2WSH or P2WPKH until the outputs are redeemed
09:32 < sipa> phantomcircuit: new signature hashing, and it takes inputs from the witness rather than from the scriptSig directly
09:32 < Victorsueca> some extra privacy, that's always good
09:34 -!- laurentmt [~Thunderbi@80.215.178.47] has joined #bitcoin-core-dev     
09:34 -!- laurentmt [~Thunderbi@80.215.178.47] has quit [Client Quit]     
09:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
09:45 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-xtfqkoxcqnmuakcm] has quit [Quit: Connection closed for inactivity]     
09:47 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
09:54 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has joined #bitcoin-core-dev     
10:11 -!- rebroad [~rebroad@223.206.10.89] has quit [Ping timeout: 246 seconds]     
10:19 -!- profall [sid29922@gateway/web/irccloud.com/x-aazybhnwserjujnb] has joined #bitcoin-core-dev     
10:19 < profall> Hello, what is the default rpcworkqueue on 13.1 ?
10:20 < profall> I want to increase it but I have no idea what the starting value is
10:25 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 245 seconds]     
10:30 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
10:30 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
10:31 < sipa> 16     
10:31 < profall> Thank You
10:38 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
10:43 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
10:53 < gmaxwell> sipa: So the chainstate reindex without signature verification test with 300MB dbcache completed,  entry-per-txout is ~25% _faster_ than master! 
10:56 < sipa> gmaxwell: woah
10:56 < sipa> wasn't only 6% at some point during sync?
11:03 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 245 seconds]     
11:03 < gmaxwell> I was screwing up the comparison when I was giving you those figures.
11:05 < sipa> wasn't it around the same number for a 2000MB dbcache?
11:05 < sipa> anyway great... more work, now we need to investigate this idea further
11:07 -!- grubles is now known as grubles__     
11:08 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
11:09 -!- matrix01 [dsax@79.113.84.218] has joined #bitcoin-core-dev     
11:10 < matrix01> Who can help  to gave me a small amount of BTC or borow me some pm me thx!
11:14 < sipa> matrix01: for experimenting purpose, use a testnet faucet. otherwise: this is not a place for begging
11:22 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
11:27 < bitcoin-git> [bitcoin] morcos opened pull request #9371: Notify on removal (master...notifyOnRemoval) https://github.com/bitcoin/bitcoin/pull/9371
11:38 < gmaxwell> sipa: ~23% for 2000MB, so yes.
11:38 -!- sipa [~pw@2a02:348:86:3011::1] has quit [Changing host]     
11:38 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev     
11:42 -!- wvr [~wvr@157.red-88-8-243.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
11:47 < Lightsword> was the networking code being reworked to use libevent or something similar? or was that just the rpc server stuff?
11:48 < sipa> it's being reworked slowly
11:48 < sipa> but it's not yet using libevent
11:48 < sipa> but having the network code use libevent is indeed a goal
11:52 < Lightsword> is the network refactoring in preparation for that? how close is it to being able to use libevent?
11:52 < sipa> talk to cfields 
11:52 < sipa> i expect libevent to happen in 0.15
11:53 < cfields> Lightsword: quite close, up and running locally. Upstreaming in chunks.
11:54 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has quit [Ping timeout: 240 seconds]     
12:00 < matrix01> Who can help  to gave me a small amount of BTC or borow me some pm me thx!
12:00 < sipa> matrix01: stop begging. last warning
12:00 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ     
12:06 -!- matrix01 [dsax@79.113.84.218] has left #bitcoin-core-dev []     
12:07 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
12:12 -!- Atomicat_ [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev     
12:14 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has quit [Ping timeout: 264 seconds]     
12:14 -!- Atomicat_ is now known as Atomicat     
12:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
12:28 < instagibbs> sipa, he's been doing this under various names repeatedly on other channels someone banhammer him
12:32 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c7947e09ff8...b99a093afed8
12:32 < bitcoin-git> bitcoin/master ed58969 Pieter Wuille: Batch construct batches...
12:32 < bitcoin-git> bitcoin/master b99a093 Pieter Wuille: Merge #9346: Batch construct batches...
12:33 < bitcoin-git> [bitcoin] sipa closed pull request #9346: Batch construct batches (master...reusebatch) https://github.com/bitcoin/bitcoin/pull/9346
12:48 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has joined #bitcoin-core-dev     
12:56 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has quit [Ping timeout: 248 seconds]     
13:08 -!- wvr [~wvr@157.red-88-8-243.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]     
13:13 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
13:27 < gmaxwell> https://github.com/bitcoin/bitcoin/graphs/contributors?from=2015-12-16&to=2016-12-16&type=c  < anyone know why this doesn't list 2/3rds of the people who have contributed? 
13:28 < achow101> date range is wrong?
13:31 < gmaxwell> Hm? git log --no-merges shows commits from ~150 contributors (some name dupes) from 2015-12-16 to now.
13:33 -!- owowo [ovovo@gateway/vpn/mullvad/x-myxoyexrhwztqgca] has quit [Ping timeout: 264 seconds]     
13:33 < arubi> replacing 'type=c' with a mock 'type=none' lists 100 people
13:37 < achow101> maybe some of the authors don't have their emails registered with github so they aren't shown?
13:40 < achow101> they might also be counting committers and not authors
13:42 < gmaxwell> achow101: nope, far too many.
13:42 < gmaxwell> achow101: e.g. you're listed.
13:43 < btcdrak> sounds like we need to report this to github, their data processing appears to be bugged
13:43 < achow101> well I made commits. there are some commits that are like "X committed with Y" so they might be counting that commit as made by Y and not X
13:44 < gmaxwell> achow101: yea, no-- not that either. 
13:44 < gmaxwell> there are people not listed that made PRs and had them merged.
13:45 -!- owowo [ovovo@gateway/vpn/mullvad/x-ynwkixmzxszlgotw] has joined #bitcoin-core-dev     
13:46 < Chris_Stewart_5> gmaxwell: I've noticed this with other repos, such as bitcoin-dot-org -- here is a pull request I had merged https://github.com/bitcoin-dot-org/bitcoin.org/pull/1333
13:46 < Chris_Stewart_5> but I'm not on the contributors list :/ not sure why
13:49 < achow101> gmaxwell: are you sure? even though they opened PRs, some of them have the committer name as someone else or committed on GitHub
13:49 < gmaxwell> achow101: https://github.com/bitcoin/bitcoin/pull/6842 take that one for example.
13:50 < achow101> that commit is out of your time range
13:53 < gmaxwell> achow101: ah it's merge isn't. Lemme find another.
13:57 < gmaxwell> https://github.com/bitcoin/bitcoin/commit/8c1dbc5e9ddbafb77e60e8c4e6eb275a3a76ac12 < how about that?
13:58 < achow101> no registered email with github
14:00 < gmaxwell> okay, lemme try another!
14:01 < gmaxwell> yea, that might be it.
14:02 < achow101> gmaxwell: here's an example of a commit I was talking about: https://github.com/bitcoin/bitcoin/commit/203e2ddad8e544803491d1e9e9ca2b6e26a15f8e
14:02 < achow101> laudaa is not even in the contributors list at all
14:18 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
14:31 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
14:44 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has joined #bitcoin-core-dev     
15:01 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 256 seconds]     
15:06 <@sipa> morcos: any reason why ApplyTxInUndo can't use ModifyNewCoins?
15:07 -!- mode/#bitcoin-core-dev [-o sipa] by sipa     
15:11 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev     
15:11 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host]     
15:11 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
15:22 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds]     
15:29 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev     
15:33 < morcos> sipa: you mean for the case where it's the last spend (undo.nHeight != 0)?  I'm not sure I see how it would be any nicer..
15:36 < sipa> morcos: right, i was working on my per-txout branch... where it would apply for every spend
15:36 < sipa> i mean: would it be safe to use?
15:37 < morcos> heh, well then its a bit of a different question..
15:38 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 260 seconds]     
15:38 < morcos> i'd have to think about exactly how it works in a per-txout world..  but it seems like it should be.
15:39 < sipa> assuming your database is not corrupted, the undo data is trusted
15:39 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 265 seconds]     
15:39 < sipa> which means that you are certain that it (semantically speaking, from the chain point of view) is never overwriting anything
15:40 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
15:47 < morcos> yep, and at least after #9107 ModifyNewCoins asserts that that is the case
15:47 < gribble> https://github.com/bitcoin/bitcoin/issues/9107 | Safer modify new coins by morcos · Pull Request #9107 · bitcoin/bitcoin · GitHub
16:14 -!- chris200_ [~chris2000@p5082A9F7.dip0.t-ipconnect.de] has quit [Read error: No route to host]     
16:14 -!- chris2000 [~chris2000@p5082A9F7.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
16:41 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev     
16:41 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host]     
16:41 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:12 -!- rebroad [~rebroad@223.206.10.89] has joined #bitcoin-core-dev     
17:23 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
17:38 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev     
17:57 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:16 < jtimon> I apologize for opening #9271 as an excuse to close its ancestor without proper cleaning and tests first. I think now it's better...feedback welcomed...
18:16 < gribble> https://github.com/bitcoin/bitcoin/issues/9271 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ymwrmbtvguzhzstz] has quit [Quit: Connection closed for inactivity]     
18:33 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
18:51 -!- abpa [~abpa@2602:306:b837:dbf0:dd28:bfdd:5b2a:6fd8] has joined #bitcoin-core-dev     
18:55 -!- rebroad [~rebroad@223.206.10.89] has quit [Ping timeout: 258 seconds]     
18:55 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 256 seconds]     
19:10 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
19:15 -!- question [be09cb27@gateway/web/freenode/ip.190.9.203.39] has joined #bitcoin-core-dev     
19:16 < question> Hi, someone know how to mine on bitcoincore?
19:22 < question> ???     
19:22 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 258 seconds]     
19:23 < achow101> question: bitcoin core can no longer mine on the mainnet
19:23 < achow101> the internal miner was removed
19:23 < question> wow :(
19:23 < question> how did i could mine so with my PC
19:23 < question> ?     
19:24 < sipa> you can't
19:24 < question> did you know?
19:24 < achow101> it is pointless to attempt CPU or GPU mining. you will waste electrcity and earn nothing
19:24 -!- bitcoinocho_ [258b015c@gateway/web/freenode/ip.37.139.1.92] has joined #bitcoin-core-dev     
19:24 < bitcoinocho_> u can mine: https://bitcointalk.org/index.php?topic=1712184.msg17196641#msg17196641
19:24 < bitcoinocho_> core is past, ocho is future
19:24 < achow101> stop with the bitcoinocho spam
19:24 < question> ok     
19:24 < bitcoinocho_> mine  ocho get rich
19:24 < question> Thnks to all
19:25 < achow101> it is not bitcoin core and is off topic for this channel.
19:25 < bitcoinocho_> nobody has gpu miner even only cpu
19:25 < bitcoinocho_> achow101: u r not brocho
19:25 < achow101> banhammer him
19:25 < bitcoinocho_> MINE OCHO SELL OCHO GET RICH https://www.tradesatoshi.com/Exchange?market=OCHO_BTC
19:25 < bitcoinocho_> LET TRUTH BY KNOW NO CENSORSHIP
19:25 < bitcoinocho_> BITCOIN OCHO >> BITCOIN UNLIMITED, 8MB BLOCK, NO ASIC
19:26 < achow101> altcoins are off topic for this channel
19:26 < question> spammer
19:26 -!- bitcoinocho_ [258b015c@gateway/web/freenode/ip.37.139.1.92] has quit [Client Quit]     
19:26 < question> spammer bitcoinocho
19:27 -!- question [be09cb27@gateway/web/freenode/ip.190.9.203.39] has quit [Quit: Page closed]     
19:43 < bitcoin-git> [bitcoin] kallewoof opened pull request #9372: Fix: OSX QT compile: move bswap_XX into Bitcoin:: to avoid collision with existing definitions (master...rename-bswap_XX) https://github.com/bitcoin/bitcoin/pull/9372
19:59 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
20:06 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever]     
20:15 -!- rebroad [~rebroad@171.4.249.185] has joined #bitcoin-core-dev     
20:32 -!- chris200_ [~chris2000@p5082A30B.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
20:35 -!- chris2000 [~chris2000@p5082A9F7.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]     
20:41 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:25 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:e531:2902:9583:e521] has quit [Remote host closed the connection]     
21:26 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b0e6:1d46:f6bf:f830] has joined #bitcoin-core-dev     
21:36 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b0e6:1d46:f6bf:f830] has quit [Quit: .]     
21:37 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b0e6:1d46:f6bf:f830] has joined #bitcoin-core-dev     
21:44 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
22:05 -!- cjamthagen [d4555899@gateway/web/freenode/ip.212.85.88.153] has quit [Ping timeout: 260 seconds]     
22:22 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]     
22:26 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
23:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev