--- Day changed Fri Mar 18 2016
00:16 < GitHub18> [bitcoin] jonasschnelli closed pull request #6641: De-neuter NODE_BLOOM (master...bloom-disable) https://github.com/bitcoin/bitcoin/pull/6641
00:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xnglynntcmzixhff] has joined #bitcoin-core-dev
00:22 -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has quit [Read error: Connection reset by peer]
00:27 -!- Guest57413 [greg@mf4-xiph.osuosl.org] has quit [Changing host]
00:27 -!- Guest57413 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev
00:27 -!- Guest57413 is now known as gmaxwell
00:33 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
00:51 < GitHub197> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/f034bced269c...73b7eb501e64
00:51 < GitHub197> bitcoin/master 6851107 Pieter Wuille: BIP9 Implementation...
00:51 < GitHub197> bitcoin/master 732e774 Pieter Wuille: Versionbits tests
00:51 < GitHub197> bitcoin/master d23f6c6 Pieter Wuille: Softfork status report in RPC
00:51 < GitHub90> [bitcoin] laanwj closed pull request #7575: Minimal BIP9 implementation (master...bip9) https://github.com/bitcoin/bitcoin/pull/7575
00:59 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
01:00 -!- B4ckJ4ck007 [~ipalyi@213.4.200.211] has joined #bitcoin-core-dev
01:08 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
01:08 < btcdrak> \o/
01:14 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
01:24 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:28 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
01:35 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
01:50 -!- devplop [2edac112@gateway/web/freenode/ip.46.218.193.18] has joined #bitcoin-core-dev
01:54 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 244 seconds]
01:54 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
01:57 < devplop> Hi, do I have to download the entire blockchain if I want to use bitcoind on my server? thanks 
01:58 < jonasschnelli> devplop: yes. But you can use -prune to remove "old blocks".
01:58 < jonasschnelli> devplop but you should discuss that in #bitcoin (this is the development channel)
02:00 < devplop> thanks jonasschnelli
02:00 < devplop> But it would be on a website for user to be able to create wallet etc. this is development right?
02:01 < jonasschnelli> devplop: hmm.. not sure what you mean with that
02:01 < devplop> approximately, what percentage it remove?
02:02 < jonasschnelli> you mean -prune? It's flexible.
02:02 < devplop> I'm developping a website wich use bitcoind, this is not development? or here we only talk about developement of bitcoin itself
02:02 < devplop> ok thanks, do you know a place I can find a documentation about this?
02:03 < jonasschnelli> This channel is for bitcoin-core development only. You can use #bitcoin-dev
02:03 < jonasschnelli> devplop: theres is a dev. documentation on bitcoin.org
02:04 < devplop> thanks again, I can't go to bitcoin-dev, where do I have to register?
02:04 < jonasschnelli> Just join the channel #bitcoin-dev ?
02:05 < devplop> #bitcoin-dev Cannot join channel (+r) - you need to be identified with services
02:06 < jonasschnelli> There are plenty user in this channel,.. you might face a local IRC issue.
02:06 < devplop> ok thanks
02:16 -!- murch [~murch@p4FE3AF6C.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:16 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
02:17 < btcdrak> devplop: you have to use /nickserv help
02:18 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 252 seconds]
02:18 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
02:34 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:03 -!- devplop [2edac112@gateway/web/freenode/ip.46.218.193.18] has quit [Ping timeout: 252 seconds]
03:04 < wumpus> paveljanik: don't forget to create an issue for the Qt 5.8 support (what changed in qt 5.8, what error you now get, etc)
03:09 < GitHub57> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/73b7eb501e64...efde86b4aae6
03:09 < GitHub57> bitcoin/master e38781d Suhas Daftuar: Tests: fix missing import in mempool_packages
03:09 < GitHub57> bitcoin/master efde86b Wladimir J. van der Laan: Merge #7709: Tests: fix missing import in mempool_packages...
03:09 < GitHub113> [bitcoin] laanwj closed pull request #7709: Tests: fix missing import in mempool_packages (master...fix-mempool-packages-2) https://github.com/bitcoin/bitcoin/pull/7709
03:10 < paveljanik> wumpus, I thought you do not want to see "reminder"  issues ;-)
03:10 < paveljanik> ok, ok, will do.
03:10 < paveljanik> :-)
03:10 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
03:10 < wumpus> paveljanik: but right now I'm confused about what the problem is
03:10 < wumpus> a build failure with a new version of a dependency seems a good reason to open an issue, anyhow
03:11 < wumpus> so is this on every platform or just say, OS X?
03:11 < paveljanik> I'll collect everything and create an issue, in ~1 hour.
03:11 < wumpus> thanks!
03:12 < paveljanik> lunch now :-)
03:19 < GitHub11> [bitcoin] petertodd opened pull request #7713: Fixes for verify-commits script (master...2016-03-fix-verify-commits) https://github.com/bitcoin/bitcoin/pull/7713
03:34 -!- AaronvanW [~ewout@D979E961.cm-3-2d.dynamic.ziggo.nl] has joined #bitcoin-core-dev
03:34 -!- AaronvanW [~ewout@D979E961.cm-3-2d.dynamic.ziggo.nl] has quit [Changing host]
03:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:35 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 244 seconds]
03:35 < paveljanik> #7714: Build with Qt 5.6 not supported
03:36 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
03:37 < wumpus> paveljanik: ah, so this seems OS X-focused
03:37 < wumpus> upstream issue explicitly mentions "frameworks"
03:38 < paveljanik> maybe. But the similar problem was reported by kwin people. So I think it is generic.
03:38 < paveljanik> will download other OS binary to see.
03:38 < jonasschnelli> missing .pc file will probably break all platforms?!
03:39 < wumpus> well the .pc files were broken on MacOSX in some cases, maybe they've removed them because of that
03:39 < paveljanik> maybe they are missing on OS X only. Do not know. I'm checking Linux now.
03:39 < wumpus> I would be really surpised (and disappointed) if they removed them on unix/linux
03:39 < wumpus> there's not really a replacement for pkgconfig on linux
03:40 < paveljanik> they probably expect projects to use cmake and their files.
03:40 < wumpus> (well ok, manually specifying all the directories)
03:40 < wumpus> cmake uses pkgconfig too IIRCI
03:40 < wumpus> cmake is just an autoconf replacement, it doesn't replace pkg-config
03:41 < paveljanik> OMG 661MB...
03:41 < wumpus> pkg-config is not part of any specific make system, it is just linux's way of locating development headers and libraries, OS X has this 'framework' system instead
03:43 < wumpus> paveljanik: make sure you download qtbase not the full thing, it's crazy - it's said it contains three copies of webkit, and many other ballast: https://twitter.com/whitequark/status/700583315254829057
03:43 < paveljanik> nevermind, already downloaded 8)
03:44 < paveljanik> hmm: qt-opensource-linux-x64-5.6.0.run: ELF ;-)
03:44 < paveljanik> so it has to be run in the VM
03:44 < paveljanik> it will take longer
03:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
03:50 < paveljanik> it needs X to install or Linux build env which I do not have readily available from here now :-(
03:54 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has quit [Ping timeout: 276 seconds]
03:58 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:01 < paveljanik> later
04:02 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
04:03 < wumpus> paveljanik: someone else can do it
04:04 < wumpus> paveljanik: btw, are you able to build if you manually specify all the library and header paths using the appropriate configure settings?
04:04 < paveljanik> bash command line too long I guess ;-)
04:05 < paveljanik> The change in qt is:
04:05 < paveljanik> https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=commitdiff;h=6c5d227da1709eb81968823f38a133747c0e95b0
04:05 < paveljanik> so I guess that on "unix"/mingw, it will be OK.
04:05 < paveljanik> have to leave now, sorry. Will be back later today.
04:06 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has quit [Ping timeout: 246 seconds]
04:16 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:24 < GitHub16> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/efde86b4aae6...29e1131c4642
04:24 < GitHub16> bitcoin/master fa4a522 MarcoFalke: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock
04:24 < GitHub16> bitcoin/master 29e1131 Wladimir J. van der Laan: Merge #7702: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock...
04:24 < GitHub162> [bitcoin] laanwj closed pull request #7702: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock (master...Mf1603-qaCleanup2) https://github.com/bitcoin/bitcoin/pull/7702
04:41 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
04:50 -!- qwebirc646325 [31b181f2@gateway/web/freenode/ip.49.177.129.242] has joined #bitcoin-core-dev
04:51 -!- wangchun_ [~wangchun@li414-193.members.linode.com] has quit [Quit: leaving]
04:52 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
04:52 < qwebirc646325>  does anyone know if its possible to fork bitcoin to createe a new coin with support for sending 1 satoshi
04:57 -!- fengling [~fengling@111.198.29.53] has quit [Quit: WeeChat 1.4]
05:01 -!- Guest73422 [~socrates1@li175-104.members.linode.com] has quit [Changing host]
05:01 -!- Guest73422 [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev
05:01 -!- Guest73422 is now known as amiller
05:03 < qwebirc646325> or if a fork could elimnate transaction fees
05:04 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
05:04 -!- tubro [~tubro@ipb2189d84.dynamic.kabel-deutschland.de] has quit [Client Quit]
05:09 < wumpus> qwebirc646325: altcoins can make whatever change they want
05:10 < wumpus> although both examples you meantion aren't even consensus rules. Any miner could accept transactions of one satoshi, or accept transactions without fee (some even do).
05:10 < qwebirc646325> great
05:11 < qwebirc646325> how much needs to be changed in the source to create an altcoin
05:11 < wumpus> this is not the place for altcoin questions
05:12 < btcdrak> ##altcoin-dev
05:19 < JackH> come on guys, the altcoin might become the biggest thing ever!
05:19 < JackH> you dont know what you are missing out on
05:20 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
05:25 < wumpus> hah
05:27 < JackH> nice on BIP9 btw :)
05:48 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
06:00 < morcos> gmaxwell: wumpus: sipa: sorry for being a pest, but I would like some direction on this getbalance mess.  does one of you want to talk it through with me?
06:02 < wumpus> morcos: at least ignore the accounts stuff
06:02 < wumpus> yes, balances can be off with accounts, we know that
06:03 < sipa> morcos: i've been thinking about it
06:03 < sipa> and i wonder how it was really ever intended to work
06:03 < morcos> wumpus: well.  that would lead to us not actually solving the problem that Cocodude first brought to us
06:03 < sipa> wumpus: it's not that simple
06:03 < morcos> also i'm most concerned by the fact that the account balances are what is used for sendfrom and sendmany
06:04 < sipa> morcos: ??
06:04 < sipa> wumpus: the account balance calculation is very strongly related to the computation of transaction 'effects' (which is what listtransactions lists)
06:04 < morcos> those functions get the available balance by calling GetAccountBalance
06:04 < sipa> what?
06:04 < wumpus> I don't think so, the send functions allow balances to go negative
06:04 < wumpus> (account balances)
06:05 < sipa> morcos: ... you're right, i thought that was changed in... 0.3.x
06:05 < morcos> my proposal was to just special case check if the given account is "" and then not use GetAccountBalance
06:05 < wumpus> people are finally looking at the wallet code in detail, that's good to hear :)
06:06 < morcos> but this is getting to be an invasive change for a point release
06:06 < wumpus> yes, try to solve it for master at least
06:06 < sipa> any correct solution is going to result in the account balances being correct anyway
06:06 < morcos> sipa: or removing accounts?
06:06 < sipa> if you can't get account balances right, listtransactions will also be wrong
06:06 < sipa> because they use the same code
06:06 < wumpus> maybe it's just too much of a change for a point release, that's a fair conclusion
06:07 < morcos> what do you mean by listtransactions being wrong? 
06:07 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
06:07 < morcos> wumpus: well the problem is we probably ought to do something.  there is a problem in the released code now.  its a matter of deciding what we should do for 0.12.1.  then there is a second question of what we should do for master.
06:07 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
06:08 < morcos> are we at the point where we can remove accounts?  if so, that is what we should do for master, b/c anything else is just a recipe for further problems down the road
06:08 < wumpus> yes, we should definitely remove account balances
06:08 < morcos> to be honest, i'm not really interested in taking the time to understand the accounting system well enough to try to make it work properly.  (since i don't believe its something we want to long term support)
06:09 < wumpus> people use other account functionality (e.g. they use them as labels)
06:09 < wumpus> but the balance logic is incorrect and dangerous
06:10 < morcos> wumpus: so my suggestion is if you don't really intend to be using account balances but you just are b/c thats the only way to get the total sum balance, then we should instead make you not use account balances
06:10 < sipa> morcos: there are two ways to look at the wallet; 1) as a set of utxos 2) as a sequence of balance updates
06:10 < morcos> this exists in at least 3 places now
06:11 < morcos> 1) getbalance (where you want to specify a confirm requirement you have to fill in an account argument), sendfrom, sendmany
06:11 < morcos> sorry, that was all 3
06:11 < sipa> morcos: effectively, you either iterate over the transactions to find which of its outputs are available
06:12 < sipa> morcos: or you iterate over transactions to see which utxos they add/remove
06:12 < sipa> the first is used by listunspent and getbalance "*"
06:12 < sipa> the second is used by listtransactions and getbalance acc
06:12 < morcos> sipa: yes, but i think thinking of it as a sequence of balance updates is fairly complicated when sometimes you want things to count for reducing your balance but not for adding to it. (in the case of unconfirmed txs)
06:13 < morcos> sipa: actually getbalance "*" is more similar (but a separate code path) to getbalance acc i think
06:14 < sipa> morcos: my point is that if you can't compute balance updates correctly, listtransactions will be wrong
06:14 < sipa> because listtransactions does not list transactions, but balance updates caused by transactioms
06:15 < sturles> At least some people use accounts.  If you remove accounts in the segwit release, it may impact the upgrade speed negatively.  E.g. I will have to code an entirely new solution for my system before I can use a version without accounts.
06:15 < morcos> sipa: i'm not sure i understand still.  i think it'll list all the balance updates as you say.  what it won't do is provide you an intelligent way to add them up to arrive at something meaningful
06:15 -!- jajc [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has joined #bitcoin-core-dev
06:16 < morcos> but i think each individual one would make some kind of sense depending on how you look at it
06:16 < morcos> the question comes when you are trying to decide whether you want to count the balance update in your total or not, but with listtransactions, you don't have to make that choice
06:16 < wumpus> sturles: I'm talking about removing account balances, not remove all the account related RPCs
06:17 < sipa> sturles: those are independent; if we make any meaningful changes to the account system, it will be in a major release and not backported
06:17 < morcos> sturles: yes we wouldn't remove accounts for segwit release, that would be for a major version
06:17 < sipa> sturles: consensus changes like segwit are always backported
06:17 < wumpus> account balances are unreliable, the other parts are not.
06:18 < morcos> sipa: did that make sense what i just said?  i'm not sure what you think will be "wrong" about listtransactions
06:18 < sipa> morcos: both use CWallet::GetAmounts
06:19 < morcos> yes, but i think the problem is in the filtering of whats returned from GetAmounts and listtransactions doens't filter it
06:19 < sipa> hmm
06:19 < sipa> ok
06:19 < sipa> but we have so many different states a transaction can be in
06:19 < sturles> Much of my system relies on account balances beeing correct. :-/
06:20 < sturles> Account balances have always been reliable for me.
06:20 < wumpus> that's very dangerous
06:20 < sipa> wumpus: i think account balances are perfectly well defined
06:20 < morcos> sturles: i think it had some broken behavior in 0.11 and it has some other broken behavior in 0.12
06:20 < wumpus> sipa: I've heard otherwise
06:20 < sturles> Oh?
06:20 < wumpus> sipa: I certainly wouldn't recommend anyone to rely on them
06:20 < sipa> they have unexpected behaviour wrt unconfirmed transactions
06:20 < sturles> Is there a bug report I can read?
06:21 < wumpus> the thing is, no one really understands it, it's just too messy
06:21 < midnightmagic> Before I retired it, I had a wallet where almost all the accounts had negative balances.
06:21 < morcos> wumpus: +1
06:21 < wumpus> did you read the convo between morcos and sipa above?
06:21 < wumpus> those are two long-term developers, who have worked on the code for a long time, and they're surprised about how some of the account things work - doesn't that say enough?
06:22 < sipa> i think we should go over the possible states a transaction can be in, and think about what their effect on listtransactions, listunspent, and getbalance should be (independent from accounts)
06:22 < wumpus> the problem is also that whatever broken behavior accounts have, people may be relying on it, even if it's unknown to us
06:23 < sipa> 1) confirmed 2) unconfirmed but in mempool 3) unconfirmed not in mempool 4) unconfirmed not in mempool, abandoned 5) unconfirmed not in mempool, known to conflict
06:23 < morcos> sipa: ok.  are you narrowing the discussion to differences in behavior between 0.11 and 0.12?
06:23 < sturles> I can't say I understand how the code works, but I do understand how accoutns work.  Negative balances are not a problem.  I use negative balances as well, in my accounting.
06:23 < wumpus> sturles: see also https://github.com/bitcoin/bitcoin/issues/3816
06:24 < sipa> morcos: no, i first want to know what we think the ideal behaviour should be
06:24 < morcos> sipa: and when you say getbalance, you have to refer to what arguments you are using.   btw, there is also getunconfirmedbalance
06:24 < wumpus> and I'm sure there is previous discussion
06:24 < sipa> morcos: ok, so we should treat those separately
06:24 < sipa> also, there is immature
06:24 < morcos> sipa: well i'm just trying to avoid the rabbit hole of trying to fix accounts perfectly.  i htink a better goal is to avoid regressions, and work towards removing accounts
06:24 < sipa> and non-final
06:24 < wumpus> morcos: +1
06:24 < sipa> morcos: i'm not trying to fix accounts
06:24 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:25 < midnightmagic> sturles: The wallet in my case had a total balance adding the accounts up, to a value different than the listunspent returned.
06:25 < sturles> wumpus: Yes, malleability issues messed with my accounting as well back in 2014, but I didn't have the problem during the last malleability attack where someone changed lots of transactions.
06:25 < sipa> morcos: i want to know what we think the correct behaviour should be for those different types of transactions, on listunspent, getbalance, getunconfirmedbalance, listtransactions
06:25 < sturles> midnightmagic: OK, I can't explain that.
06:25 < sipa> no account-related calls in that list
06:25 < wumpus> midnightmagic: yes that was quite common at a certain point
06:25 < morcos> ok, so if you don't want to worry about calling  getbalance("", n) or getbalance("*", n) or what gets used in sendfrom, sendmany, then i don't think its that hard
06:25 < sturles> midnightmagic: Some transaction cleaned out (abandoned) perhaps?
06:26 < wumpus> the account system has pretty much been unmaintained from 2011-2012 or so
06:26 < morcos> the thing we discovered yesterday, was that tx type 5 in your list above is not necessarily distinguishable from tx type 3
06:27 < midnightmagic> gmax tried to help me debug it, but at some point I abandoned the code and that wallet and rebuilt everything and respent it. Still not more than 95% sure I swept it all up.
06:28 < sipa> morcos: yes, i know
06:28 < morcos> this is a crap ton of stuff to write up.  i think i can do that reasonably well for 0.11, 0.12 and proposed fix
06:28 < sipa> morcos: so presumably we want to treat 3 and 5 the same, apart from reporting
06:28 < morcos> great. agreed with that
06:28 < wumpus> yes
06:28 < sipa> ... which means that the introduction of 5 was maybe overkill
06:29 < sipa> though i guess it can be useful for example for the gui to be able to suggest abandoning
06:29 < morcos> oh wait, sorry
06:29 < morcos> i don't actually agree we treat them the same
06:29 < wumpus> sipa: in some cases you may also want to treat transactions that you sent yourself differently from received ones
06:29 < morcos> exactly
06:30 < morcos> if you are considering whether your inputs are spent.  3) considers them spent, 5) doesn't
06:30 < wumpus> (I miss that in the list, but maybe that's a cartesian product)
06:30 < morcos> sorry whether your available coins are spent
06:30 < morcos> if you are considering whether you have new available coins to spend 3) and 5) should both be no you don't
06:31 < wumpus> e.g. the wallet could create a transaction, but you have wallet broadcasting disabled
06:31 < wumpus> you'd still want it to subtract from your balance and hold the inputs, at least until abandoned
06:31 < morcos> yes
06:32 < morcos> let me write all that up in detail, i can do that.  what i want to know is a proposed solution for getbalance("", n), sendfrom, sendmany ?  in particular the problem reported to us was a result of getbalance("",0)
06:33 < wumpus> in any case, making all of this consistent is too much for a point release, this would be something for a major release (+mention in release notes)
06:34 < sipa> sturles, midnightmagic: since you guys use/used the account system, were you relying on sendfrom/sendmany failing when you send from an account with a too low balance?
06:34 < morcos> wumpus: actually the code changes are going to be small.  probably just the first commit on 7706, plus potentially this question of skipping account accounting and using global balances when the account is "" in those 3 rpc calls
06:35 < sturles> sipa: I did at some point, but not now.
06:36 < sipa> that's the one thing that surprises me today, finding out that they do a balance check
06:36 < sipa> because there are several other ways in which account balances can ge negative without any protection
06:37 < sturles> Yep, especially the "" account.
06:37 < morcos> sipa: oh, that hadn't occurred to me, that it wasn't important
06:37 < sturles> Otherwise it is mostly due to fees.
06:38 < sipa> morcos: well, maybe it is, and i just don't know!
06:38 < morcos> well that makes things a lot easier, then i would suggest we don't change anything other than the first commit in 7706 and we can tell people that if they want total unconfirmed balance they should call getbalance() + getunconfirmedbalance() and not use getbalance("", 0)
06:39 < morcos> that would make me happy.  minimal changes.   
06:40 < sipa> morcos: it was an intentional change at some point very long ago (i believe in the 0.3.2x days), to not protect against account balances going negative, because it wasn't even possible
06:40 < morcos> its only through my stupidity in not knowing how getbalance("", 0) works that we even realized there is a problem in the wallet.cpp getunconfirmed balance code.
06:40 < midnightmagic> sipa: I've been using only the rawtx interface for too long to remember my use of accounts. gmax told me early on to stop using it. i was lazy and never cared if the send* failed or not for whatever reason. post-accounting aggregation has never been a concern for me. :-( Sorry man.
06:41 < sipa> morcos: for example, the move RPC has a 'minconf' argument that is ignored
06:41 < morcos> yeah i didn't even realize that RPC existed until yesterday
06:41 < sipa> morcos: it used to check whether there was enough balance in the account being moved from, at the given confirmation level
06:42 < midnightmagic> sturles: my accounts went into the thousands negative
06:43 < sipa> morcos: so if there is any change we make to this, i'd say we remove that check entirely...
06:43 < morcos> so i do think there was a regression in 0.12 in how bad account balances are as a result of this business with unconfirmed txs...   but maybe we should just let that be, other than communicating it
06:43 < morcos> sipa: my concern was when you weren't trying to use it for accounts!  isn't the only way to sendmany to do sendmany with the "" account
06:44 < sipa> right
06:44 < sturles> You cam make the numbers negative with move as well, of course.  In the millions negative.
06:44 < sipa> sturles: yeah, that's exactly what i was saying above, move and sendtoaddress don't check balance
06:45 < sipa> so why would sendfrom/sendmany?
06:45 < sturles> I have used that trick a few times, to make enough funds available in the account I was sending from. :-)
06:46 < morcos> sipa: ah ok.  now i see.  i was worried that sendmany with a "" account would create transaction that spent too many funds.  but it won't.  CreateTransaction will stop it.
06:46 < sturles> I see no reason why sendmany or sendfrom should check the balance of an account, but make sure to make a strong note of it in the release notes..
06:47 < morcos> thats why i was concerned about it.  
06:47 < sturles> Alternatively make it an option to check the balance.
06:48 < sipa> sturles: which is called getbalance :)
06:48 < morcos> I think we should just make minimal changes and announce a removal timeline for accounts.  Seems a lot for 0.13, maybe 0.14
06:49 < morcos> I'll put it in a fresh PR, so its cleaner
06:49 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
06:58 < GitHub7> [bitcoin] morcos opened pull request #7715: Fix calculation of balances and available coins. (master...fixconflicts_take2) https://github.com/bitcoin/bitcoin/pull/7715
06:59 < GitHub85> [bitcoin] morcos closed pull request #7706: [WIP] Fix calculation of balances and available coins. (master...fixconflicts2) https://github.com/bitcoin/bitcoin/pull/7706
07:23 -!- jannes [~jannes@178.132.211.90] has quit [Read error: Connection reset by peer]
07:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:25 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
07:32 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:36 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
07:39 < morcos> sipa: wumpus: ok checkout #7715, i _think_ that chart is right.
07:39 < wumpus> nice work!
07:40 < morcos> probably needs someone to make sure its right though
07:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:48 < btcdrak> morcos: <3 that chart
07:55 < sipa> morcos: awesome!
07:55 < sipa> (i had no idea github had so many icons...)
07:59 < morcos> I perhaps did not make it clear enough that the red triangle can't lead to bad things.  In other words you won't reduce your balance for coins spent if those were coins that weren't included in your balance.
07:59 < morcos> The fearful face can I think lead to bad things though.
08:00 < sipa> morcos: use :arrow_down: instead of the red triangle?
08:00 < sipa> and :warning: for the unhappy face?
08:01 < morcos> ah, good arrow down is better, but i like the fearful face.  you should be fearful!
08:01 < sipa> ok!
08:09 -!- zooko [~user@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:17 < wumpus> sipa: it has a crazy number of them, see http://www.emoji-cheat-sheet.com/ :)
08:17 < wumpus> (I think they originally took them from campfire, which is owned by the same company, but I may be confused)
08:19 < wumpus> the idea of them actually being useful is new and surprising to me, though, nice idea morcos
08:19 -!- zooko [~user@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
08:31 < wumpus> yes, the fearful faces are scary, why would you ever want to 'trust' unconfirmed transactions received but not those sent by yourself
08:31 < wumpus> well ok 'trust' is overstated, it only affect the *unconfirmed* balance
08:32 < wumpus> but still it seems inconsistent, if it has any effect for receiving it should also for spending
08:32 < wumpus> (or neither)
08:33 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 248 seconds]
08:33 < morcos> wumpus: sure, or you could just send yourself txs over and over again and increase your balance wily-nily (i think)
08:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
08:34 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-core-dev
08:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:36 < wumpus> morcos: oh no, you found a bitcoin cheat code :D
08:37 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
08:38 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
08:38 -!- B4ckJ4ck007 [~ipalyi@213.4.200.211] has quit [Quit: B4ckJ4ck007]
08:38 < GitHub85> [bitcoin] morcos opened pull request #7716: [0.12] Backport BIP9 and softfork for BIP's 68,112,113 (0.11...backportBIP9SoftFork) https://github.com/bitcoin/bitcoin/pull/7716
08:39 < morcos> oops, that was for 0.11
08:39 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
08:40 < wumpus> morcos: btw, non-final received transactions will never reach the wallet
08:40 < morcos> wumpus: well, almost, they could in a reorg
08:40 < wumpus> I mean they're rejected by the mempool code
08:41 < wumpus> hm right
08:45 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection]
09:01 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
09:49 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
10:16 -!- qwebirc646325 [31b181f2@gateway/web/freenode/ip.49.177.129.242] has quit [Quit: Page closed]
10:33 < GitHub157> [bitcoin] btcdrak closed pull request #7693: [0.11] Backport BIP112 CHECKSEQUENCEVERIFY mempool-only (0.11...bip112-backport-0.11) https://github.com/bitcoin/bitcoin/pull/7693
10:40 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
10:42 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
10:49 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
10:50 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
11:02 < jtimon> now that I have a good computer...can't the rpc tests be parallelized?
11:02 < jtimon> at least for people with zmq installed or something
11:03 < jtimon> just thinking out loud, don't take this too seriously yet
11:05 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
11:06 < sipa> i don't see how zmq is relevant for that
11:06 < sipa> you could run multiple tests in parallel though, just running different bitcoind's in different directories side by side
11:07 < jtimon> yeah, forget about that, just that I like to use zmq for concurrency in python, sorry for bringing that up
11:09 < jtimon> to your second comment, yes, that's what I was thinking, but with -j56 instead of having to think about it, it was just a wish in the open
11:10 < jtimon> to be perfectly clear, the goal is running ```python ./qa/pull-tester/rpc-tests.py -extended -j4``` or something like that
11:10 < jtimon> but as said is just a random thought
11:11 < sipa> that sounds totally reasonable and doable
11:11 < jtimon> zmq is just the way I would support that, so totally forget about if you don't like zmq/nanomsg
11:13 < jtimon> for me, messaging is the simplest way to levereage both threads and processes transparently
11:13 < sipa> there is nothing to communicate even
11:13 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
11:14 < sipa> just run multiple tests at the same time, and make sure they use separate directories/ports
11:18 -!- JackH_ [~Jack@host-2-102-203-221.as13285.net] has joined #bitcoin-core-dev
11:18 < jtimon> yeah, if anybody has a script that does that, please share. If I ever write it myself (which would still be prefarable to me than your "this can be done relatively easily manually"), I would do it using python and zmq, but as said that's just an irrelevant side-note
11:19 < jtimon> in the meantime python ./qa/pull-tester/rpc-tests.py -extended is not all that bad
11:19 -!- JackH_ [~Jack@host-2-102-203-221.as13285.net] has quit [Remote host closed the connection]
11:19 -!- JackH [~Jack@host-2-103-125-30.as13285.net] has quit [Ping timeout: 246 seconds]
11:20 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
11:21 < jtimon> anyway, just wishful comments while I learn more about our wonderful testing setup
11:21 < jtimon> rpc python testing newbie here
11:21 < jtimon> still
11:22 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
11:23 < jtimon> but that is good, that means unittests alone captured most of my stupid thoughts previously
11:25 < jtimon> and I have a good computer to start testing other people's things more deeply, sorry for the distraction, shouldn't think out loud here
11:27 < sipa> jtimon: i really don't understand where zmq comes in
11:27 < sipa> i'd be in favor of implememting multithreaded testing in rpc-tests.py
11:28 < sipa> using a -j flag like you suggest
11:28 < jtimon> just for concurrency, seriously, just forget about that whole part, I shouldn't have mentioned it, there's 3000 other ways to do concurrency in python
11:28 < sipa> ok :)
11:28 < jtimon> yeah, the -j option is the whole point
11:29 < sipa> but zmq is for communicating between processes, what do you expect to communicate?
11:29 < sipa> anyway, nvm :)
11:29 < sipa> if you feel like implementing it, and feel like zmq is useful for that, please do :)
11:30 < jtimon> zmq hs many use cases than you think, I think, but I'm happy that we have decoupled the topics
11:30 < jtimon> s/many/more
11:30 < jtimon> but yeah, nvm
11:34 < jtimon> I mean, if I implement it (which will depend on how often I run ./qa/pull-tester/rpc-tests.py -extended from now on) I will use that, and if anybody else does before me, the script can be written in php for all I care
11:37 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
11:42 < jtimon> TLDR; catching up on testing, I can't remember last time I gave a full ACK instead of just an utACK for something that wasn't obviously correct to me, oh, wait...that should never have happened, I'm virgo that way :p
11:43 < sipa> haha
11:46 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
11:57 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
12:04 < GitHub17> [bitcoin] morcos closed pull request #7695: [0.11] Backport BIP 68 mempool only (0.11...68backport) https://github.com/bitcoin/bitcoin/pull/7695
12:19 < btcdrak> wumpus: 7716 should be tagged consensus
12:20 < btcdrak> morcos: BIP is merged, you can send that email
12:21 < btcdrak> wumpus: 7543 also needs to be tagged consensus now
12:38 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 248 seconds]
12:38 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
12:39 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Ping timeout: 244 seconds]
12:48 < morcos> btcdrak: email sent
13:03 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 248 seconds]
13:04 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-core-dev
13:06 < wumpus> hm this is interesting, ubuntu 16.04 doesn't install python 2 by default anymore
13:06 < wumpus> no /usr/bin/python nor /usr/bin/python2
13:06 < wumpus> this breaks 'make check'
13:07 < wumpus> it is possible to install python 2.7 using 'apt-get install python2.7` but this will only give you a /usr/bin/python2.7, no /usr/bin/python nor /usr/bin/python2...
13:08 < wumpus> this is fucking annoying as it effectively makes it possible to refer to it as interpreter at the top of scripts
13:08 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
13:10 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
13:10 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
13:11 < wumpus> impossible*
13:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Disconnected by services]
13:11 -!- Guyver2_ is now known as Guyver2
13:20 < btcdrak> RIP python 2
13:22 < wumpus> yea
13:30 < btcdrak> wumpus: wait, do you have a time machine? It's only 16.03 last time I looked... 
13:31 < wumpus> yes, I inherited satoshi's delorean
13:32 < wumpus> (you can find beta images for ubuntu 16.04)
13:32 < sipa> damn
13:32 < sipa> ubuntu 16
13:33 < sipa> what happens to the past decade?
13:33 < sipa> i think i started using ubuntu in 2006
13:33 < wumpus> heh, me too, around 2005-2006, where goes the time
13:33 < wumpus> before that I used gentoo and before that slackware
13:35 < sipa> debian, gentoo, ubuntu here
13:40 < paveljanik> slackware, red hat, suse, os x
13:49 < Luke-Jr> kinda our fault for still using Python2..
13:51 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
13:53 < cfields> wumpus: yea, that's really annoying. Is there no convention for a python2/python3 shebang, at least?
13:54 -!- ka [779da513@gateway/web/cgi-irc/kiwiirc.com/ip.119.157.165.19] has joined #bitcoin-core-dev
13:54 < ka> http://oortr.com/ZjllYz
13:54 -!- ka [779da513@gateway/web/cgi-irc/kiwiirc.com/ip.119.157.165.19] has quit [Client Quit]
13:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
13:54 -!- Guyver2_ is now known as Guyver2
14:03 < btcdrak> cfields: I think you can use #!/usr/bin/env python
14:04 < sipa> btcdrak: that requires a binary named python, no?
14:04 < cfields> btcdrak: yea, looks like the convention is to use env python2/env python3. but that breaks according to wumpus's findings above
14:06 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
14:10 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:23 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
14:23 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
14:25 -!- Amnez777 [~Amnez777@37.157.216.147] has quit [Ping timeout: 276 seconds]
14:25 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 276 seconds]
14:25 -!- OxADADA [~OxADADA@alumni-linux.ccs.neu.edu] has quit [Ping timeout: 276 seconds]
14:26 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 276 seconds]
14:26 -!- Amnez777 [~Amnez777@37.157.216.147] has joined #bitcoin-core-dev
14:26 -!- OxADADA [~OxADADA@alumni-linux.ccs.neu.edu] has joined #bitcoin-core-dev
14:28 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev
14:28 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev
14:30 < paveljanik> ok, I have hacked Qt5.6 build on OS X.
14:34 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
14:35 < sipa> hey ebfull
14:36 < ebfull> how's it going sipa
14:36 < ebfull> grats on the versionbits work
14:37 < ebfull> sipa: btw look at the dates: https://github.com/bitcoin/bitcoin/pull/5220  https://github.com/bitcoin/bitcoin/pull/6954
14:38 < ebfull> told ya :D
14:39 < instagibbs> now I feel smart for writing my python tests compatible for both python2 and 3 :)
14:41 -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has joined #bitcoin-core-dev
14:44 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
14:44 < cfields> paveljanik: nice. what'd it take?
14:45 < paveljanik> I'm now entering a few hacks into the issue, mmnt.
14:45 < paveljanik> almost done
14:45 < paveljanik> cfields, you can probably help to clean it up ;-)
14:48 < paveljanik> cfields, comment added #7714
14:49 < paveljanik> remember #5728...
14:51 < cfields> paveljanik: ah, so it's just the osx frameworks that don't ship the .pc's ?
14:51 < paveljanik> I do not have a chance to test Linux downloads or source code distro.
14:51 < sipa> ebfull: remember remember the fifth of november
14:56 < cfields> paveljanik: hmm
14:57 < paveljanik> but we can home that brew/macports will fix both parts again... Or teach Qt to do that correctly.
14:58 < sipa> ebfull: it's not the commit date nor the merge date, though; just the date the PR was submitted
15:01 < cfields> paveljanik: it's annoying that they disable the .pc that helps us find the bins...
15:02 < cfields> i wonder if they could be talked out of that part
15:04 < cfields> paveljanik: mind pasting the contents of Qt5UiTools.pc ?
15:09 < cfields> paveljanik: heh: https://github.com/Homebrew/homebrew/commit/620baaf10c957875d9d2b958343456f0d35d15fc
15:45 -!- murch [~murch@p4FE3AF6C.dip0.t-ipconnect.de] has left #bitcoin-core-dev []
15:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:59 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
16:00 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 248 seconds]
16:08 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 248 seconds]
16:12 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
16:18 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 244 seconds]
16:31 -!- gevs [~greg@ip-62-235-153-39.dsl.scarlet.be] has joined #bitcoin-core-dev
16:31 -!- gevs [~greg@ip-62-235-153-39.dsl.scarlet.be] has quit [Changing host]
16:31 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
16:36 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds]
16:42 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
17:50 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Quit: Leaving]
18:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xnglynntcmzixhff] has quit [Quit: Connection closed for inactivity]
18:12 -!- ryan-c [~ryan@srv1.turboslow.net] has quit [Quit: ZNC - http://znc.sourceforge.net]
18:17 -!- ryan-c [~ryan@srv1.turboslow.net] has joined #bitcoin-core-dev
19:05 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
19:25 -!- fengling [~fengling@114.111.166.213] has joined #bitcoin-core-dev
20:31 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
20:31 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit []
21:01 -!- go1111111 [~go1111111@104.232.116.217] has quit [Quit: Leaving]
21:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:16 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
21:18 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Client Quit]
21:24 -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-core-dev
21:30 -!- jon_ [459c68a4@gateway/web/freenode/ip.69.156.104.164] has joined #bitcoin-core-dev
21:31 < jon_> Having a problem with bitcoin core can anyone help?
21:32 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
21:47 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds]
21:47 -!- jon_ [459c68a4@gateway/web/freenode/ip.69.156.104.164] has quit [Quit: Page closed]
22:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
22:43 -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has quit [Read error: Connection reset by peer]
22:50 -!- fengling [~fengling@114.111.166.213] has quit [Ping timeout: 240 seconds]
23:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
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
23:19 -!- fengling [~fengling@114.111.166.213] has joined #bitcoin-core-dev
23:45 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
23:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:54 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]