--- Day changed Tue Aug 08 2017
00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:15 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
00:17 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 240 seconds]     
00:18 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
00:20 -!- miknotauro [~miknotaur@node-1w7jr9qg7ouwbwikqsvlf1ikz.ipv6.telus.net] has quit [Ping timeout: 255 seconds]     
00:45 < luke-jr> hm, it's a shame we're releasing 0.15 without bech32 sending :x
00:45 < gmaxwell> luke-jr: when does segwit activate?
00:46 < luke-jr> gmaxwell: Aug 21 it looks like
00:46 < gmaxwell> luke-jr: also it's just not that mature yet,... a serious problem was found in the test vectors of the spec and ref implementations just a week ago.
00:46 < luke-jr> :<     
00:47 < gmaxwell> luke-jr: dunno if you read the minutes from the last meeting (or was it the one before last) but we were talkign about a short cycle release with segwit wallet support right after 15 in any case.
00:47 < luke-jr> I didn't, but newbery did mention it to me. I agree a rapid 0.16 would be good.
00:47 < gmaxwell> https://github.com/sipa/bech32/pull/21 also re: bech32 support.
00:49 < luke-jr> is there a reason to have a C++ implementation at all? seems to me the proper route to go would be to make a C libbech32, which can be used by Core…?
00:51 < gmaxwell> a library for 50 lines of code... what are you, a nodejs developer? lpad() ftw? :P  But seriously, a native C++ interface is typesafe. Wrappign a C implementation to give it a C++ friendly interface would probably end up being the same size as the library itself.
00:51 < gmaxwell> FWIW it's much simpler to implement bech32 than base58.
00:52 < luke-jr> hmm     
01:23 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
01:25 < achow101> I suspect that #10982 is going to need to be locked soon due to brigading and trolling
01:25 < gribble> https://github.com/bitcoin/bitcoin/issues/10982 | Disconnect network service bits 6 and 8 until Aug 1, 2018 by TheBlueMatt · Pull Request #10982 · bitcoin/bitcoin · GitHub
01:25 < jonasschnelli> How do we deal with the service bits 6 and 8? Should NODE_NETWORK_LIMITED avoid bit6 because something else claimed it (although not via BIP process)?
01:27 < achow101> It was actually bits 5 and 7 that were claimed
01:30 < luke-jr> kidnapped*? :P
01:33 < jonasschnelli> achow101: Bip 7 is SW2x, right? Whats 5?
01:35 < luke-jr> jonasschnelli: BCash I assume
01:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
01:41 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
01:42 -!- Bartholome [~Bartholom@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
01:46 -!- Bartholome [~Bartholom@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
01:51 < luke-jr> achow101: sigh, would have been nice to get the commit message fixed before merging :/
01:54 < gmaxwell> unfortunately s2x people were spamming their slack with it and such the moment it went up.
01:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:55 < luke-jr> it would also be nice if we didn't merge things because of trolls :x
01:56 -!- corinrose_ [uid137375@gateway/web/irccloud.com/x-wiaihxrqbquofxiv] has quit [Quit: Connection closed for inactivity]     
02:03 < luke-jr> jonasschnelli: perhaps: uint16_t archival_data_flag = (servicebits & NODE_NETWORK_FLAG_MASK); if (servicebits & NODE_NETWORK) { … } else if (archival_data_flag == NODE_NETWORK_LIMITED_HIGH) { … } else if (archival_data_flag == NODE_NETWORK_LIMITED_LOW) { … } would fit nicely
02:08 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
02:18 < MarcoFalke> Reminder to call gpg --keyserver pgp.mit.edu --refresh-keys F4316B9B
02:21 < gmaxwell> achow101: depends on if you count the bits starting at 0 or 1
02:25 < luke-jr> gmaxwell: which has always been counted from 0..
02:26 < jnewbery> NODE_NONE must surely be zero?
02:26 < gmaxwell> depends on your language,  "first bit" is 1<<0. 
02:28 < jonasschnelli> From what I read you usually start a 0
02:28 < jonasschnelli> *at     
02:28 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/fa8a0639f7b0...627c3c0e495b
02:28 < bitcoin-git> bitcoin/master dac3782 Wladimir J. van der Laan: doc: Correct AmountFromValue/ValueFromAmount names
02:28 < bitcoin-git> bitcoin/master 46347ad Wladimir J. van der Laan: rpc: Move ValueFromAmount to core_write...
02:28 < bitcoin-git> bitcoin/master ec05c50 Wladimir J. van der Laan: rpc: Use ValueFromAmount instead of FormatMoney in TxToUniv...
02:28 < bitcoin-git> [bitcoin] laanwj closed pull request #10999: Fix amounts formatting in `decoderawtransaction` (master...2017_08_decoderawtx_amount) https://github.com/bitcoin/bitcoin/pull/10999
02:42 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/627c3c0e495b...4268426b4500
02:42 < bitcoin-git> bitcoin/master 055d95f John Newbery: [wallet] return correct error code from resendwallettransaction
02:42 < bitcoin-git> bitcoin/master 4268426 Wladimir J. van der Laan: Merge #11002: [wallet] return correct error code from resendwallettransaction...
02:42 < bitcoin-git> [bitcoin] laanwj closed pull request #11002: [wallet] return correct error code from resendwallettransaction (master...resendwallettransaction_error_code) https://github.com/bitcoin/bitcoin/pull/11002
02:58 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4268426b4500...2507fd55568b
02:58 < bitcoin-git> bitcoin/master 861f9a2 Matt Corallo: Skip remainder of init if upgrade is cancelled
02:58 < bitcoin-git> bitcoin/master 2507fd5 Wladimir J. van der Laan: Merge #10998: Fix upgrade cancel warnings...
02:59 < bitcoin-git> [bitcoin] laanwj closed pull request #10998: Fix upgrade cancel warnings (master...2017-08-fix-upgrade-cancel-warnings) https://github.com/bitcoin/bitcoin/pull/10998
03:00 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev     
03:10 -!- johnpark_pj [~quassel@211.46.62.22] has quit [Ping timeout: 268 seconds]     
03:11 -!- johnpark_pj [~quassel@211.46.62.22] has joined #bitcoin-core-dev     
03:17 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has quit [Ping timeout: 268 seconds]     
03:17 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has joined #bitcoin-core-dev     
03:18 -!- comboy_ [~quassel@tesuji.pl] has quit [Read error: Connection reset by peer]     
03:19 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:19 -!- comboy [~quassel@tesuji.pl] has joined #bitcoin-core-dev     
03:29 < wumpus> doing last checks on 10882, after which I'll merge it. After that I'm planning to tag 0.15.0rc1. Any objections?
03:30 < wumpus> (ah yes #10483 and #10607 too)
03:30 < gribble> https://github.com/bitcoin/bitcoin/issues/10483 | scripted-diff: Use the C++11 keyword nullptr to denote the pointer literal instead of the macro NULL by practicalswift · Pull Request #10483 · bitcoin/bitcoin · GitHub
03:30 < gribble> https://github.com/bitcoin/bitcoin/issues/10607 | scripted-diff: stop using the gArgs wrappers by benma · Pull Request #10607 · bitcoin/bitcoin · GitHub
03:31 < wumpus> then branching off 0.15, bumping version numbers, then tagging the release
03:32 < gmaxwell> I think 10882 is still in a state where if you run getnewaddress to the pont where it exhausts your keypool then recieve a transaction your node shuts off.
03:33 < wumpus> can you coment jnewbery?
03:33 < wumpus> if so, i'm going to bump it to 0.15.1 instead
03:34 < jnewbery> Yes, that's the case - I reverted to the commit that had ACKs
03:35 < wumpus> is it enough of an improvement to merge it like this?
03:35 < jnewbery> I think it's an improvement
03:35 < wumpus> (or does it make things worse? I don't know anymore)
03:36 < gmaxwell> It's a critical improvement, but I think the sequence of events I described should block a release, just like absense of this PR.  Keep in mind that most existing already encrypted wallets have less than 500 keys in their keypool already.
03:36 < wumpus> you want to block the release on this?
03:37 < gmaxwell> I think we need to turn HD off without this. We currently have non-trivial funds loss exposure without this.
03:37 < wumpus> is it a regression since 0.14?
03:37 < gmaxwell> It was introduced in 0.14 with hdwallet, though we only realized over time all the ways it could fail.
03:38 < wumpus> I'd really dislike blocking 0.15
03:38 < wumpus> anyone else think we should delay 0.15?
03:38 < wumpus> as I understand, the plan is to do a 0.15.1 fairly quick after it anyway
03:39 < gmaxwell> Agreed! but I don't think it's acceptable to keep shipping stuff we know will basically make people lose funds, and yet I don't think we can ship something that will just fall over on most encrypted wallets in use right now.
03:39 < wumpus> so every day we delay here delays that, too
03:39 < gmaxwell> I know.
03:39 < wumpus> and if it was already broken in 0.14, and still broken in 0.15, releaseing at least won't make things worse
03:39 < wumpus> delaying just means people will keep using 0.14.x in which it is broken too
03:40 < gmaxwell> whatever we do next might be fast but it's not going to be days.
03:40 < wumpus> anyhow, going back to other things then, we can postpone for another day at least
03:40 < gmaxwell> jnewbery: can you make a second PR with the remaining parts
03:41 < gmaxwell> I don't understand why that fix was removed.. it's really pretty broken without it.
03:41 < jnewbery> I plan to
03:41 < gmaxwell> OK.     
03:41 < jnewbery> because it and the other changes broke a test, and it was suggested I revert to a commit that already had lots of ACKs
03:41 < wumpus> jnewbery: agree that doing a new PR is better
03:42 < wumpus> let's just merge 10882 before the review there turns even more into a mess, if some state of a PR is sufficiently accepted and reviewed ideally no new things are added
03:42 < gmaxwell> (It's not that I don't think we can merge whats there, but I think we can't release with it because it will fail very quickly for basically anyone with a pre-existing encrypted wallet)
03:42 < wumpus> it will fail for anyone?
03:43 < wumpus> ok, then I'm not going to merge it, I already had half a hart attack with a 'corrupted' wallet yesterday :p
03:43 < gmaxwell> wumpus: right now with that PR if you get a transaction while your keypool has under 500 addresses in it, you'll shut down.
03:43 < jnewbery> yes, I realise now that the combination of 10882 and increasing the keypool defaults probably breaks this for pre-existing wallets
03:43 < gmaxwell> jnewbery: well this was going to need a look ahead greater than 50 regardless.
03:44 < wumpus> then why does everyone ack it if it creates a broken situation
03:44 < gmaxwell> jnewbery: sorry for my earlier comments on it not making it adequately clear that this applies to almost everyone, I just thought that pointing out that it would go down after a getnewaddress loop was enough. :)
03:46 < luke-jr> wumpus: my only possibly-not-ignored objection I think, is to breaking backward compatibility for RPC :/  (#10989)
03:46 < gribble> https://github.com/bitcoin/bitcoin/issues/10989 | RPC: Restore backward compatibility, in multiwallet mode by luke-jr · Pull Request #10989 · bitcoin/bitcoin · GitHub
03:47 < gmaxwell> luke-jr: I think that objection is acknoweldged and set aside. Making MW require the wallet was an intentional decision at least for now that basically everyone supported.
03:47 < jnewbery> wumpus - I think because it's been open for a long time and gone through many iterations, during which time the keypool defaults were increased. I've only just realised the implications from what gmaxwell said just now
03:48 < jnewbery> I can hopefully get a minimal PR on top of #10882 in the next hour that includes juse the getnewaddress fix. gmaxwell, will you be able to review today?
03:48 < gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
03:49 < luke-jr> so people will just be forced to switch to Knots to actually use MW I guess, whatever
03:50 < luke-jr> I suppose that's the same as with previous versions
03:50 < gmaxwell> luke-jr: come on dude, having to specify which wallet you want is not "having to use".  It's perhaps arguably less useful, but the feature is expiremental in this version.
03:51 < wumpus> multiwallet is experimental
03:51 < wumpus> even if it's completely useless in rc1, I'm not going to block the release on that
03:51 < wumpus> (and I know for sure it's not compltely useless)
03:51 < luke-jr> gmaxwell: no existing software uses the new API, and as you point out, the new API is experimental.. so there's basically no way to get the primary "just keep wallets in sync" benefit without using a new experimental API
03:52 < gmaxwell> luke-jr: bitcoin cli works, and many other things are easy to get working...
03:52 < luke-jr> anyway, I acknowledge that this isn't going to be fixed; I'm just not happy about it.
03:52 < gmaxwell> I agree it dimishes the wallet warming usecase.
03:54 < gmaxwell> luke-jr: the concern people have about accidentally interacting with the wrong wallet is a good one though. It's an obvious footgun and it's more conservative to avoid it for now.
03:54 < gmaxwell> luke-jr: also, perhaps that walletwarming usecase would better be met with a seperate state e.g. a scanwallet=file  where there is no risk of accidentally using it beyond getting some status about it.
03:55 < luke-jr> gmaxwell: yes, I agree that's a reasonable concern. I don't know a way to address it.
03:55 < luke-jr> hopefully MW will be more than warming by 0.16 anyway
03:55 < luke-jr> (I actually think it might have been better to release without *any* RPC MW support, than with what we have now)
03:56 < luke-jr> (that'd solve the footgun issue, while not breaking the warming use case)
03:56 < gmaxwell> luke-jr: fwiw, I think it would be more constructive on concerns like this if instead of just saying it's wrong, if you walked us through the specific case that you care about that it screws up.  It's a lot easier to sympatize with your concern if someone understands it, and they can't unless you explain it.  When you just state matter of factly that it's currently wrong or broken, it's random c
03:56 < gmaxwell> hance if any given person will understand why you think that.
03:56 < gmaxwell> luke-jr: For many people, updating to make the calls (e.g. cli users) is trivial.
03:57 < luke-jr> gmaxwell: my understanding was that it's basically the only real use case 0.15 will support MW for
03:57 < gmaxwell> and being able to actually use MW will be nice.
03:57 < gmaxwell> luke-jr: that wasn't my understanding. Actually, I didn't even really know people were thinking that much about "warming but not using" until I read the release note text re: GUI.  Which I assume you wrote.
03:58 < gmaxwell> Though I agree it's a useful thing to do, esp in a world with pruning.. (also rescan times are a seriously negative part of my life these days)
03:59 < luke-jr> (FWIW, Newbery wrote it)
03:59 < gmaxwell> I manage cold wallets for myself, for blockstream, for varrious projects... and it's not uncommon that I lose hours of waiting due to having to rescan something.
03:59 < gmaxwell> ah okay!
03:59 < jnewbery> yeah - I think for qt-only users warming is the only use in v0.15
03:59 < luke-jr> I suppose a reasonable compromise is to have a command-line option to set a default wallet, and only support it in that case. But probably too late to get it into 0.15
04:00 < jnewbery> but for RPC users, multiwallet is fully supported
04:00 < luke-jr> hmm. can a Qt user even access their wallet via debug console now?
04:01 < jnewbery> yes, just wallet 0
04:01 < jnewbery> #10870
04:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10870 | [Qt] Use wallet 0 in rpc console if running with multiple wallets by jonasschnelli · Pull Request #10870 · bitcoin/bitcoin · GitHub
04:03 < luke-jr> ah     
04:05 < jnewbery> gmaxwell - I don't think the getnewaddress changes you're asking for in 10882 address the encrypted-wallet-with-fewer-than-500-keys issue that you just raised
04:05 < jnewbery> basically every HD wallet now has fewer than 500 keys
04:06 < jnewbery> so on upgrade, everyone with an encrypted HD wallet will have their node shut down and be presented with the 'restart with bypasskeypoolcritical blah blah blah' error
04:07 < jnewbery> it's not a loss of funds risk, but it's a terrible first user impression of v0.15
04:08 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:08 < gmaxwell> the whole thing is a bit weird. When the wallet is current there is no need for the keypool to have lookahead.
04:10 < gmaxwell> But I didn't want to get into dictating major changes to it.
04:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
04:13 < wumpus> maybe it should only enlarge the keypool the first time the user unlocks the wallet
04:13 < wumpus> after upgrading
04:13 < Lauda> Does anyone know what the limiting factor for rescan speed is? I have been running a few imports on a fairly good machine, and I don't see everything being utilized whilst this is taking up a lot of time (single key 2+ hours). Disk I/O maybe? 
04:13 < Lauda> CPU <20% on average, 2 GB of RAM out of 32 (with dbcache 12GB).
04:14 -!- rjak [~rjak@gateway/vpn/privateinternetaccess/rjak] has joined #bitcoin-core-dev     
04:14 < wumpus> rescan could be a lot faster if you'd not care about transaction history, then it'd only have to scan over the utxo set instead of every single block
04:15 < Lauda> I don't, I just care about the final balance (in this case). Is there an option to ignore the TX history?
04:15 < Lauda> Seems like rescan speed will keep getting much worse with time, no?
04:16 < jnewbery> wumpus, the problem is that keypool_critical was changed to 500 during the iterations of this PR (when keypool was changed to 1000). We'd need a way for keypool_critical to be lowered to 50 on the first run after upgrading, or similar. I can't think of a good way to do that
04:20 < Lauda> I should also note that it is taking over 2 hours on a VPS with an SSD. I wonder how much of a difference it would make with an HDD (% duration increase).
04:25 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit []     
04:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:33 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:34 < gmaxwell> the rescan is slow presumably because it deseralizes each block and each transaction and hashes each trasnaction and does dozens of memory allocations for each transactions.
04:35 < gmaxwell> It could probably take your scriptpubkeys and txns as bytes and scan the raw block data without deseralizing things and be 500 times faster... but it would be a fair amount of work to implement that.
04:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
04:36 < gmaxwell> jnewbery: keypool_criticial being 50 is not really reasonable in any case. it would miss transactions in many of my existing wallets, for example, and I doubt my usage is that atypical.
04:36 < gmaxwell> jnewbery: I think the bigger point though is that when the wallet is current there is no reason to shut down.
04:37 < gmaxwell> It doesn't matter if there is look ahead if the wallet hasn't fallen behind.
04:37 < wumpus> yes, it will get slower with time, assuming you're donig a full rescan
04:37 < wumpus> if you rescan a more or less fixed number of blocks it should stay at the same speed
04:37 < wumpus> or at least not become much slower...
04:38 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
04:38 < wumpus> and yes, rescan as it is could certainly be optimized, though I doubt anyone sees it as that much of a priority
04:38 < jnewbery> "when the wallet is current there is no reason to shut down." - the getnewaddress change doesn't fix that
04:39 -!- berndj [~berndj@mail.azna.co.za] has quit [Ping timeout: 255 seconds]     
04:39 < Lauda> gmaxwell that sounds like a good optimization for the future. Thanks for the responses. 
04:39 < wumpus> you're welcome to give it a try of course
04:40 < gmaxwell> jnewbery: I realize this. When you suggested that I thought it would be simpler than another solution.
04:41 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
04:44 < jnewbery> I must have misunderstood you in the issue. I suggested the getnewaddress change because I thought you were talking about running getnewaddress 500 times. I didn't realise there was an upgrade issue until you mentioned it today
04:46 < gmaxwell> I was just trying to give an example where the keypool would be below the threshold. I don't really see them as different... end result is the same regardless of how you get there. Sorry.
04:47 < gmaxwell> e.g. imagine that the crit threshold were still 50, you'd still have existing wallets shut down immediately, or after the user executes a dozen getnewaddresses. :)
04:47 < gmaxwell> Just fewer of them.
04:47 < gmaxwell> but they'd mostly all die eventually except for users that unlock frequently before running out.
04:50 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
04:54 < jnewbery> ok, so how do we fix this?
04:55 < jnewbery> Offline keypool topup would be *really* useful
04:58 < gmaxwell> jnewbery: Can we distinguish the case where we are current vs rescanning? If so, then we just shouldn't perform the shutdown when we're current.
05:04 < gmaxwell> I think it would still be good to stop newaddresses short of the limit, so that we don't immediately go into shutdown on any attempt to rescan when the pool is empty.. but that is a less criticial improvement.
05:05 < jnewbery> We rescan from the wallet's best block on startup. So even with that change, we're going to barf on upgrade
05:06 < jnewbery> (unless you shutdown v0.14, upgrade, start v0.15 before a block has been produced)
05:07 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
05:07 < gmaxwell> hm. but we don't have those blocks at startup.
05:07 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds]     
05:07 < gmaxwell> when we start, the best block should be the same... though yea, IIRC we do a rescan in any case. I think just as a belt and suspenders check.
05:08 < jnewbery> oh, ok. Makes sense
05:08 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
05:09 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
05:11 < morcos> jnewbery: gmaxwell: i dont have all the code handy, but just brainstorming a quick fix for 0.15
05:11 < morcos> wouldn't it be possible to take advantage of the two different limits
05:12 < gmaxwell> I think that initial rescan can be disabled, but it's been so long since I've thought about it, there may be reasons that I am not remembering.
05:12 < morcos> if we set keypoolmin to 500 and keypoolcritical to 25, then don't we not miss anything since our best block has stopped advancing?
05:13 < gmaxwell> oh. that is an interesting point, but what about wallets with empty keypools
05:13 < gmaxwell> (below 25)
05:13 < morcos> then with the release notes we can recommend running walletpasphrase as soon as you startup  so your keypool will top up to the new bigger amounts
05:13 < morcos> oh wait, that doesnt work exactly...
05:13 < morcos> shoot
05:14 < morcos> also it would be potentially a problem for pruned nodes
05:14 < gmaxwell> need a third number, but then I think it does except for but what if there isn't even 25.. and pruned.
05:15 < morcos> i need to look at the code, but right now i actually think it is a broken state to set keypoolmin different from keypoolcritical
05:15 < gmaxwell> morcos: If instead we just make it so that the only time this applies is when the wallet has fallen behind the node tip (or is otherwise rescanned)-- then I think that would be fine. 
05:15 < gmaxwell> You'd still get forced into topping up anytime you imported keys, moved wallets between nodes, etc.. but normal operation wouldn't run into it.
05:17 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
05:17 < gmaxwell> I believe the reason we do rescanning at tip even when we're in sync (assuming we still do it) was a concern about reorgs and or the wallet not getting flushed consistently with blocks in an unclean shutdown or something like that.
05:17 < morcos> The scary thing to me is the way we turn off setting the best block, but then potentially turn it back on if we haven't rescanned (thereby missing scanning a bunch of blocks)
05:18 < morcos> i haven't looked at the most recent code, and maybe ryanofsky's suggestion fixed that i don't remember
05:18 < morcos> i'm going to stop giving out ideas until i look more closely at the code again
05:19 < morcos> but for the record wumpus, my view is it would be better to delay 0.15 (even by a week or two) to get this right
05:20 < morcos> i think we're getting pretty well into understanding all the issues now, so would be good to fix it while it's fresh, and it also seems like a big enough problem, that would be nice to fix before release
05:24 < sdaftuar> i think #10982 should be locked
05:24 < gribble> https://github.com/bitcoin/bitcoin/issues/10982 | Disconnect network service bits 6 and 8 until Aug 1, 2018 by TheBlueMatt · Pull Request #10982 · bitcoin/bitcoin · GitHub
05:27 < gmaxwell> :(     
05:30 -!- Aaronvan_ is now known as AaronvanW     
05:32 < jnewbery> morcos - I think ryanofsky's change is helpful. I tried including it but it broke tests, so I rolled back to a previous commit
05:34 < jnewbery> gmaxwell - ShutdownIfKeypoolCritical() is only called in CreateWalletFromFile() and AddToWalletIfInvolvingMe(). I think your change would be to remove it from CreateWalletFromFile(), and only call it from AddToWalletIfInvolvingMe() if that function was called by SyncTransaction() (and not by ScanForWalletTransactions())
05:34 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:35 < jnewbery> I think I know what I need to do - re-add the getnewaddress changes, re-add ryanofksy's changes about setting best block, and make the change above
05:36 -!- Aaronvan_ is now known as AaronvanW_     
05:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
05:40 -!- AaronvanW_ is now known as AaronvanW     
05:41 < sdaftuar> MarcoFalke: thank you
05:41 < wumpus> MarcoFalke: you just beat me to it :)
05:42 < MarcoFalke> Too much mail spam :(
05:43 < gmaxwell> :-( sorry that i even commented on it at all, it just made it worse
05:47 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
05:49 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
05:55 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
06:03 < jnewbery> ~.
06:03 < sipa> agree.
06:04  * sdaftuar wonders what sipa's reasoning is
06:07 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:09 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
06:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds]     
06:39 -!- Austindoggie [~austindog@2600:380:c06d:315e:58c1:a2c4:aada:fbe9] has joined #bitcoin-core-dev     
06:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
06:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
06:46 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
06:52 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
06:56 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
07:00 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
07:01 -!- timothy [tredaelli@redhat/timothy] has quit [Ping timeout: 240 seconds]     
07:01 -!- drizztbsd [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
07:19 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
07:23 -!- btcdrak [uid239175@gateway/web/irccloud.com/x-qgifodtoopaanbrn] has quit [Quit: Connection closed for inactivity]     
07:25 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
07:26 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
07:26 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
07:28 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
07:28 -!- Guyver2_ is now known as Guyver2     
07:32 -!- miknotauro [~miknotaur@node-1w7jr9qg7ouwbwikqsvlf1ikz.ipv6.telus.net] has joined #bitcoin-core-dev     
07:34 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
07:40 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
07:46 -!- miknotauro [~miknotaur@node-1w7jr9qg7ouwbwikqsvlf1ikz.ipv6.telus.net] has quit [Ping timeout: 258 seconds]     
07:48 < wumpus> jnewbery: maybe reverting the default mempool size increase for 0.15.0 will make this easier?
07:50 -!- miknotauro [~miknotaur@node-1w7jr9qg7ouwbwikqsvlf1ikz.ipv6.telus.net] has joined #bitcoin-core-dev     
07:50 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
08:02 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
08:03 -!- drizztbsd [tredaelli@redhat/timothy] has quit [Ping timeout: 276 seconds]     
08:03 < Chris_Stewart_5> How long do we support gcc versions? Curious for #8469
08:03 < gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
08:04 < wumpus> Chris_Stewart_5: there's no fixed policy on that - the preference is to support all compilers unless there's a good reason not to, such as lack of c++11 support
08:15 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 255 seconds]     
08:19 < jnewbery> wumpus: yes, that would resolve the upgrade issue, although I'm sure gmaxwell will argue against that
08:33 < wumpus> sure, I just mean maybe we can't have everything in a timeframe soon enough for 0.15.0 and we need to make choices
08:35 < luke-jr> Chris_Stewart_5: it would be pretty bad to not build on popular stable OSs
08:36 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
08:36 < luke-jr> so I'd check Fedora, Debian, RedHat/CentOS, Gentoo, Ubuntu at least
08:36 < luke-jr> IIRC typically the hold-back is CentOS
08:37 < wumpus> luke-jr: it doesn't even work on travis
08:37 < luke-jr> heh     
08:38 < wumpus> gcc 4.8 isn't *that* old and crappy yet, I doubt we should drop support just to be able to do tests in a certain way
08:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
08:38 < wumpus> and the tests working on travis is kind of important, so disabling them on gcc 4.8 isn't going to fly either
08:39 < luke-jr> right
08:39 < bitcoin-git> [bitcoin] practicalswift opened pull request #11007: [qt] Fix memory leak when loading a corrupted wallet file (master...wallet-corrupted-leak) https://github.com/bitcoin/bitcoin/pull/11007
08:39 < Chris_Stewart_5> Yes, 4.8.4 was released in Dec of 2014
08:40 < Chris_Stewart_5> ancient in terms of bitcoin! :P 
08:40 < sam_c> gentoo is about to mask 4.8
08:43 < wumpus> besides that, we already got lots of complaints that we're requiring a c++11 compiler, I"d prefer to keep the compiler requirement the same for the forseeable future  
08:46 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
08:46 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:46 < Chris_Stewart_5> wumpus: Do we have a 'rough' estimate on when 0.15.0 will be done? 
08:46 -!- Austindoggie_ [~austindog@2601:647:ca80:1f82:e440:6abf:b653:673c] has joined #bitcoin-core-dev     
08:50 -!- Austindoggie_ [~austindog@2601:647:ca80:1f82:e440:6abf:b653:673c] has quit [Client Quit]     
08:50 -!- Austindoggie [~austindog@2600:380:c06d:315e:58c1:a2c4:aada:fbe9] has quit [Ping timeout: 246 seconds]     
08:51 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
08:52 < wumpus> Chris_Stewart_5: yes, rc1 was planned for the 6th, we've slipped two days now
08:54 < wumpus> (which is perfectly normal)
08:54 -!- ekerstein [~ekerstein@rrcs-74-218-188-194.midsouth.biz.rr.com] has joined #bitcoin-core-dev     
08:56 -!- jamesob [~james@tempo-automation.static.monkeybrains.net] has joined #bitcoin-core-dev     
09:04 < luke-jr> sam_c: is it? why?
09:05 < luke-jr> actually, it looks like it's been masked since May, just because it's old O.o
09:08 < Chris_Stewart_5> cool, was just curious
09:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:30 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
09:31 -!- Aaronvan_ is now known as AaronvanW     
09:32 -!- miknotauro [~miknotaur@node-1w7jr9qg7ouwbwikqsvlf1ikz.ipv6.telus.net] has quit [Ping timeout: 276 seconds]     
09:43 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 258 seconds]     
09:49 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
09:55 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
09:56 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
09:57 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
09:58 -!- promag [~Adium@137.22.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
10:03 -!- JackH [~laptop@217.149.140.177] has joined #bitcoin-core-dev     
10:16 -!- corinrose_ [uid137375@gateway/web/irccloud.com/x-igvtzblxmlpolnwh] has joined #bitcoin-core-dev     
10:32 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 248 seconds]     
10:38 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
10:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
10:41 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 268 seconds]     
10:54 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:12 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
11:18 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:21 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
11:23 -!- wvr [~wvr@121.red-83-45-36.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
11:25 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:26 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 240 seconds]     
11:27 -!- Aaronvan_ is now known as AaronvanW     
11:32 -!- kexkey [~kexkey@184.75.212.28] has joined #bitcoin-core-dev     
11:33 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
11:33 -!- clarkmoody_ [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
11:37 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has quit [Ping timeout: 240 seconds]     
11:37 -!- kexkey [~kexkey@184.75.212.28] has quit [Client Quit]     
11:38 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 258 seconds]     
11:39 -!- kexkey [~kexkey@68.168.119.228] has joined #bitcoin-core-dev     
11:43 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:49 -!- kexkey [~kexkey@68.168.119.228] has quit [Quit: Leaving]     
11:51 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:53 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
11:56 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
11:56 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
11:58 < jcorgan> congrats
11:59 -!- ekerstein [~ekerstein@rrcs-74-218-188-194.midsouth.biz.rr.com] has quit [Ping timeout: 255 seconds]     
11:59 < AaronvanW> +1     
12:00 < arubi> when's "status" going to change to "locked-in" ?
12:00 < arubi> I mean, congrats!  :)  but also that
12:00 < gmaxwell> oh I guess, barring no reorgs segwit lockin is now guarenteed.
12:01 < gmaxwell> arubi: the thing happening now is that there aren't enough blocks left to prevent a lock in, but it won't lock in for another day or so IIRC.
12:01 < arubi> so I was just informed it happens at the end of the period
12:01 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
12:01 < gmaxwell> so even if all blocks for the next of the window don't signal segwit it will still lock in.
12:02 < jcorgan> something like 16-17 hours from now
12:02 < arubi> right, my confusion was re. the 'getblockchaininfo' "status" filed to changing after 95% rather than at the end of the period
12:02 < jcorgan> for end of period
12:03 < Chris_Stewart_5> Mmmm ok
12:04 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
12:16 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
12:19 < gmaxwell> 12:19:19 <@betawaffle> gmaxwell: can you congratulate everyone involved in segwit for us?
12:20 < sdaftuar> i guess we can cross "activate segwit" off the list of action items
12:21 < gmaxwell> \O/     
12:22 < jnewbery> gmaxwell morcos wumpus (and anyone else who's interested in wallet topup). I've pushed a branch which I think covers gmaxwell's requested logic:
12:22 < jnewbery> - don't shutdown the node on startup if keypool is < keypool_critical
12:22 < jnewbery>     - don't shutdown the node if wallet is current
12:22 < jnewbery>     - DO shutdown the node if rescanning and keypool drops below
12:22 < jnewbery>     keypool_critical
12:22 < jnewbery> #10882
12:22 < gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
12:22 < gmaxwell> When does the period end? exactly, it would kinda be nice if rc1 lands just after that, so that miners running BIP-91 code can safely try rc1. 
12:22 < jnewbery> getnewaddress should also be safe
12:23 < gmaxwell> sdaftuar: now we just need to get people to modulate their hashrate so that the activation coincides with the solar eclipse. It's pretty close.
12:23 < jnewbery> also includes ryanofsky's m_update_best_block 
12:23 < gmaxwell> (quick, someone make more spinoffs)
12:23 < luke-jr> lol     
12:24 < gmaxwell> jnewbery: where is the branch?
12:25 < jnewbery> #10882
12:25 < gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
12:26 < gmaxwell> jnewbery: oh great
12:27 < jnewbery> This should fix the upgrade issue. bitcoind v0.15 won't shutdown first time you run it with an old encrypted HD wallet
12:31 < jnewbery> but if you don't unlock and topup your keypool before you shutdown the node, then I expect it'll refuse to start the next time (since your node tip will advance but your wallet best block won't)
12:31 < gmaxwell> Right. We may need to do a bit of warning related to this pattern still:
12:31 < gmaxwell> wallet is below 500 because it's old and encrypted.
12:32 < gmaxwell> you start, life is good, but you are not updating the best block.
12:32 < gmaxwell> then you restart, and now the wallet is behind.
12:32 < gmaxwell> it rescans, and life becomes sad.
12:33 < jnewbery> yes, sad, but better than any alternative as far as I can see
12:34 < jnewbery> there is a warning that your keypool is below keypool_min and your best block isn't advancing
12:35 < jnewbery> 2017-08-08 19:19:20 Keypool has fallen below keypool_min (500). Wallet will no longer watch for new transactions and best block height will not be advanced.
12:35 < jnewbery> 2017-08-08 19:19:20 Unlock wallet, top up keypool and rescan to resume watching for new transactions.
12:35 < jnewbery> Perhaps that could be made more explicit "TOP UP KEYPOOL BEFORE NEXT RESTART!"
12:39 < luke-jr> Can we add a new checkpoint? (Minimally invasive way to lock Segwit in hard)
12:40 < gmaxwell> luke-jr: No.
12:40 < gmaxwell> Thats not a proper or interesting thing to do.
12:40 < luke-jr> just to eliminate the FUD around miners potentially reorging it out
12:41 < gmaxwell> luke-jr: you should do what we would eventually do, make a patch that removes the activation and just replaces it with a height comparison.
12:41 < luke-jr> Isn't it too late for that in 0.15?
12:42 < gmaxwell> probably, but we should still write the patch.
12:43 < luke-jr> to be clear: I meant the new checkpoint specifically for 0.15.0 only
12:43 < gmaxwell> luke-jr: but just pinning the consensus isn't a right thing to do, and especially violating the rules for setting the things.
12:43 < luke-jr> "violating the rules for setting the things."?
12:44 < gmaxwell> luke-jr: there is a spec for setting that requires them to be set at least 2016 blocks in the past.
12:44 < luke-jr> it will be by the time 0.15.0 is released
12:44 < gmaxwell> to avoid legislating the ledger state.
12:44 < gmaxwell> also neighter of these things will prevent the reorg around the activation and steal outputs along the way.
12:45 < gmaxwell> luke-jr: it's important to enforce these things by the time we'd issue SW addresses, less so before.
12:45 < luke-jr> hmm, true, I guess we'd need to be checkpointing the actual activation block for that. and there isn't 2016 blocks there.
12:46 < luke-jr> gmaxwell: Core is more than just a wallet, and wallets besides Core exist..
12:46 < sdaftuar> while on the subject of cleaning up technical debt associated with prior soft fork deployments: #10695 could use review
12:46 < gribble> https://github.com/bitcoin/bitcoin/issues/10695 | [qa] Rewrite BIP65/BIP66 functional tests by sdaftuar · Pull Request #10695 · bitcoin/bitcoin · GitHub
12:46 < sdaftuar> or merge
12:46 < sdaftuar> we should write the csv-height-activation patch first imo
12:46 < jnewbery> 10695 looks good to me
12:48 < sdaftuar> jnewbery: did we ever fix the ComparisonTestFramework for the bug i mentioned in the OP of that PR?
12:48 -!- Giszmo [~leo@ppp-88-217-124-37.dynamic.mnet-online.de] has joined #bitcoin-core-dev     
12:49 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
12:50 < jnewbery> I think we had buy-in for rewriting the ComparisonTestFramework scripts using the standard BitcoinTestFramework
12:50 < jnewbery> In fact I've already done that for some of them, but it depends on TestNode and will several months of rebasing
12:50 < jnewbery> *will need
12:50 < sdaftuar> re-reading my message there though i think there was an immediate bug that makes our comparisonTestFramework tests (perhaps including p2p-fullblocktest?) not test anything.  
12:50 < gmaxwell> jnewbery: I'm still feeling this solution is incomplete. For example, one of my wallets (though not hd) is a encrypted wallet I use for watching cold funds. I'm never going to unlock the darn thing, its keypool is empty right now.   Maybe what we should do for this release is merge the scan and mark as use and topup if possible but instead of shutting down, spam errors that the keypool ran out a
12:50 < gmaxwell> nd your wallet balance may be incorrect. 
12:51 < jnewbery> we don't shutdown for non-HD wallets
12:52 < gmaxwell> jnewbery: I know we don't, but my useage pattern wouldn't be any different if this wallet were HD.
12:53 < gmaxwell> I still don't think we have this handling cooked, in that we'll make 0.15 unusable for at least some people or very awkward.  I think we can do better even if I don't know how yet. But it's critical we do something, because without the mark use thing there are several ways to result in serious funds loss. (including giving customers addresses you already gave to other customers, then crediting t
12:53 < gmaxwell> he wrong accounts when people make payments..)
12:58 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has joined #bitcoin-core-dev     
12:58 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has left #bitcoin-core-dev []     
12:59 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
12:59 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
12:59 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
13:00 < sdaftuar> gmaxwell: in your watching cold funds example, would restarting with a -keypoolmin=0 be sufficient for the use case?
13:01 < sdaftuar> (perhaps i don't quite understand the PR though, so ignore me if my question doesn't make sense)
13:01 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
13:03 < gmaxwell> Yes. It is. I suppose we can just release note that. "If you want to run like this, set that." good point.
13:04 < jnewbery> thanks sdaftuar. I think that covers greg's use case
13:05 < jnewbery> gmaxwell can we try to evealuate whether this fixes the immediate problem (potential funds loss). We can fix up awkward behaviour post-branch
13:06 < gmaxwell> my concern there is that we also need to not introduce something that leaves lots (?) of people stuck. But sdaftuar answers how it doesn't.
13:13 < sdaftuar> has anyone given thought to how these keypool parameters work with multiwallet?
13:13 -!- somenick_29345 [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
13:14 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.9]     
13:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
13:15 < sdaftuar> eg if we advise people to use -keypoolmin=0 to solve one situation, and they load up two wallets, are they jeopardizing themselves?
13:17 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
13:17 < jnewbery> yes, if you use -keypoolmin=0 you can get into a state where your best block has advanced while your keypool is depleted
13:17 -!- clarkmoody_ [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has quit [Ping timeout: 268 seconds]     
13:18 < jnewbery> and so potentially miss transactions
13:18 < bitcoin-git> [bitcoin] gmaxwell opened pull request #11008: Enable disablesafemode by default. (master...no-safe-mode) https://github.com/bitcoin/bitcoin/pull/11008
13:19 < jnewbery> but keypoolmin is a hidden debug option. I don't think we're going to be advertising it widely
13:20 < bitcoin-git> [bitcoin] rawodb opened pull request #11009: Add information about the next state in getblockchaininfo rpc request (master...master) https://github.com/bitcoin/bitcoin/pull/11009
13:23 < jonasschnelli> sdaftuar, luke-jr: about NODE_NETWORK_LIMITED_*. If we would treat them independently, would this mean, a peer signalling NODE_NETWORK_LIMITED_HIGH will always singal NODE_NETWORK_LIMITED_LOW?
13:23 < jonasschnelli> And there would be no special case for a peer signaling both bits?
13:24 < jonasschnelli> I agree that would make most sense.
13:24 < sdaftuar> jonasschnelli: in my opinion, a peer should signal both if it offers both
13:24 < bitcoin-git> [bitcoin] rawodb closed pull request #11009: Add information about the next state in getblockchaininfo rpc request (master...master) https://github.com/bitcoin/bitcoin/pull/11009
13:24 < sdaftuar> that way if someone wants to write a bitcoin network client that only worries about one of those properties, they don't need to do any complicated reasoning
13:25 < jonasschnelli> We would just loose the third state for the two new bits for pure logical consistence reasons. But I guess this makes sense.
13:25 < sdaftuar> i would actually suggest that we rename the service bits too, if it's not too much bikeshedding...  NODE_NETWORK is a non-descriptive term for full node to begin with
13:25 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 255 seconds]     
13:25 < sdaftuar> and putting LIMITED in the name implies denial of "full" services, which i think isn't want we want
13:25 < jonasschnelli> We only have 24 useful service bits (~10 are gone)
13:26 < bitcoin-git> [bitcoin] rawodb opened pull request #11010: Add information about the next state in getblockchaininfo rpc request (master...pr/getblockchaininfo) https://github.com/bitcoin/bitcoin/pull/11010
13:26 < jonasschnelli> sdaftuar: Agree with renaming
13:26 < jonasschnelli> sdaftuar: any proposals?
13:26 < sdaftuar> i guess i haven't come up with good alternatives yet, but something which means "NODE_RECENT_BLOCKS" or "NODE_REALLY_RECENT_BLOCKS" is along the lines of what i'm thinking
13:27 < sdaftuar> (those are not actual proposals, just intuition)
13:28 < jonasschnelli> The question is also if NODE_NETWORK implies more then just historical block responses...
13:29 < sdaftuar> yeah that's a good question, it's not obvious to me
13:30 < sdaftuar> ie we have non-NODE_NETWORK nodes (pruning nodes) which do all the rest, already
13:31 < jonasschnelli> I guess there is no concrete definition what a peer must confirm to to allow signalling NODE_NETWORK (expect the reference implementation)
13:31 < sipa> yeah, node_network just means "all the things" :)
13:31 < jonasschnelli> also, SPV is also ~NODE_NETWORK (!= pruned)
13:31 < jonasschnelli> ~(== bit unset)
13:32 < sdaftuar> right, but SPV is certainly allowed to eg relay addresses... not sure if any do.
13:32 < jonasschnelli> Which results in that NODE_NETWORK_LIMITED somehow includes tx/block relay
13:35 < sipa> i guess it's reasonable to suggest that every node can participate in address murmuring, regardless of service flags
13:35 < sipa> it's an ootional thing regardless
13:36 < sipa> since compact blocks, it doesn't really make sense to have separate services for tx relay and block relay
13:36 < sipa> so the only question is whether we want to have a separate bit for relay vs historical fetch (even if it's just 144 blocks deep)
13:37 < sipa> any client right now will want both
13:38 < jonasschnelli> sipa: for a possible use case where a peer serves historical blocks but won't relay (pure block storage)?
13:38 < sdaftuar> if no clients currently offer one but not the other, i don't think it makes sense to split that now.  we can wait til someone wants to build that.
13:39 < jonasschnelli> Agree
13:40 -!- ula|2 [~kvirc@b2b-78-94-9-226.unitymedia.biz] has joined #bitcoin-core-dev     
13:41 < sipa> sdaftuar: right... the only downside is that it'd cost another bit later
13:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
13:42 < sdaftuar> sipa: we either take that 1 bit cost now or later, right?  unless there's a proposal for distinguishing now that saves a bit, which i missed?
13:43 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:46 < sipa> sdaftuar: if we now have 3 bits (relay_tx_and_blocks, blocks_144, blocks_1008), we're good. if we only have (relay_tx_and_blocks_up_to_144, blocks_1008), we may need 2 extra bits later (relay_tx_blocks, blocks_144) totalling 4 bits, where one just implies two other ones
13:47 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
13:48 < jonasschnelli> I think the current definition of NODE_NETWORK_LIMITED_LOW is:
13:49 < jonasschnelli> NODE_NETWORK_LIMITED_LOW means the same as NODE_NETWORK with the limitation of only serving the last 288 (2 day) blocks
13:49 < jonasschnelli> (coupled to the definition of NODE_NETWORK)
13:49 < jonasschnelli> Changing the block value is possible though the client/protocol version?
13:50 < jonasschnelli> If we want relay as an extra option (assume full block SPV may want to service historical blocks but not relay) another bit would be required
13:51 -!- ula|2 [~kvirc@b2b-78-94-9-226.unitymedia.biz] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]     
13:54 < sdaftuar> sipa: i think blocks_144 and blocks_1008 without relay_tx_and_blocks are sort of nonsensical; by definition you're always willing to provide the current tip, and you never have guarantees that transactions will be relayed to you eg due to policy differences, so i don't think of that as much of a promise.
13:54 < sdaftuar> but putting that aside:
13:54 < sdaftuar> i think we could downgrade those service bits in the future to "may or may not relay blocks and transactions"
13:54 < sdaftuar> if we wanted to save a bit
13:54 < sdaftuar> oh     
13:55 < sdaftuar> i guess i'm not sure what i'm comparing...
13:55 < sdaftuar> i'm taking jonas' proposal as relay_tx_and_blocks_up_to_144, relay_tx_and_blocks_up_to_1008
13:56 < sipa> sdaftuar: but there is a technical difference
13:56 < sdaftuar> and suggesting we could in the future add a single bit saying relay_tx_and_blocks
13:56 < sdaftuar> and at the point we add that, we say that there are no promises on the quality of service you get from older nodes that aren't setting the new bit
13:57 < sipa> sdaftuar: for example relay_blocks_tx could imply support for tx/inv(tx)/cmpctblock/blocktxn/getdata(tx), while the other implies support for getblock/getdata(block)/inv(block)
13:57 < sdaftuar> cmpctblock and blocktxn are already separately negotiated
13:57 < sipa> but not advertized
13:58 < sipa> (right?)
13:58 < sdaftuar> right
13:58 < sipa> they're implied by NODE_NETWORK + sufficient protocol version
13:58 < sdaftuar> well they're implied by NODE_SEGWIT, for all practical purposes
13:58 < sdaftuar> but interesting point
13:58 -!- Giszmo [~leo@ppp-88-217-124-37.dynamic.mnet-online.de] has quit [Quit: Leaving.]     
13:59 < sdaftuar> i'm not sure it's reasonable for service bits to keep up with p2p protocol improvements
13:59 < sipa> agree
14:00 < gmaxwell> I'm not enthused by all these flags because in general we should not be segmenting up the topology if we can avoid it.
14:01 < sdaftuar> i agree with that.  i also generally want to punt on features we are not sure anyone will implement.
14:02 < sipa> agree
14:02 < sipa> just pointing out that it may cost us an extra bit in the future - perhaps that's ok
14:03 -!- Giszmo [~leo@ppp-88-217-124-37.dynamic.mnet-online.de] has joined #bitcoin-core-dev     
14:06 -!- ula [~kvirc@b2b-78-94-9-226.unitymedia.biz] has joined #bitcoin-core-dev     
14:07 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/2507fd55568b...929fd7276c0f
14:07 < bitcoin-git> bitcoin/master d4f0d87 Suhas Daftuar: [qa] Rewrite BIP65 functional tests...
14:07 < bitcoin-git> bitcoin/master 4ccc12a Suhas Daftuar: [qa] Rewrite BIP66 functional tests...
14:07 < bitcoin-git> bitcoin/master 929fd72 MarcoFalke: Merge #10695: [qa] Rewrite BIP65/BIP66 functional tests...
14:07 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10695: [qa] Rewrite BIP65/BIP66 functional tests (master...2017-06-fix-bip65-test) https://github.com/bitcoin/bitcoin/pull/10695
14:11 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
14:27 < jonasschnelli> Should peers avoid serving blocks above the NODE_NETWORK_LIMITED_LOW|HIGH threshold to reduce finger printing opportunities?
14:28 < jonasschnelli> Assume you have pruned down to 10k blocks and signalling NODE_NETWORK_LIMITED_HIGH, one could fingerprint by checking how deep down you can serve blocks
14:30 < sipa> yes, i think so
14:30 -!- somenick_29345 [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has quit [Quit: Leaving]     
14:30 < jonasschnelli> Okay. Will update the BIP
14:31 < jonasschnelli> Or maybe just the implementation... need to check
14:31 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
14:36 < bitcoin-git> [bitcoin] rawodb closed pull request #11010: Add information about the next state in getblockchaininfo rpc request (master...pr/getblockchaininfo) https://github.com/bitcoin/bitcoin/pull/11010
15:02 -!- instagibbs [~instagibb@pool-72-83-36-237.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
15:07 -!- instagibbs [~instagibb@pool-72-83-36-237.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
15:23 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]     
15:25 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
15:26 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
15:27 < molz> Dear Core Devs, Thank you for all your hard work!  https://i.imgflip.com/1trxh9.jpg
15:29 < sipa> molz: yw!
15:32 < mryandao> could anyone from here answer this: https://bitcoin.stackexchange.com/questions/57416/since-bitcoin-core-0-14-0-how-does-a-node-with-default-settings-compute-the-dus
15:35 < Murch> sipa: Transaction overhead is 10 bytes for P2PKH transactions, since segwit adds flag and marker, which however go into the witness part am I correct to calculate the weight of the tx overhead as 42?
15:36 < Murch> For a transaction that spends at least one P2SHP2PWSH input
15:37 < sipa> Murch: looks right to me
15:37 < sipa> mryandao: yes, will do if i find the time
15:37 < Murch> thank you :)
15:37 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
15:53 < sipa> mryandao: achow101 beat me to it :)
15:53 < achow101> :)     
15:54 < bitcoin-git> [bitcoin] gmaxwell opened pull request #11011: [Trivial] Add a comment on the use of prevector in script. (master...201708-prevector-comment) https://github.com/bitcoin/bitcoin/pull/11011
16:11 -!- jouke [~worst@unaffiliated/komkommer] has quit [Ping timeout: 255 seconds]     
16:13 -!- jouke [~worst@2001:1c02:1600:9200:7119:18a0:a794:e3e1] has joined #bitcoin-core-dev     
16:13 -!- jouke [~worst@2001:1c02:1600:9200:7119:18a0:a794:e3e1] has quit [Changing host]     
16:13 -!- jouke [~worst@unaffiliated/komkommer] has joined #bitcoin-core-dev     
16:19 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
16:20 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Ping timeout: 246 seconds]     
16:21 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 255 seconds]     
16:24 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
16:30 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
16:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
16:37 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:40 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
16:43 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev     
16:47 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]     
16:52 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
16:53 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
16:59 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:04 -!- Giszmo [~leo@ppp-88-217-124-37.dynamic.mnet-online.de] has quit [Quit: Leaving.]     
17:10 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
17:14 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:33 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
17:33 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:38 < earlz> Has anyone tried porting the gitian build system to run on xenial instead of trusty since trusty is getting old and GCC 4.8's C++11 support is considered experimental? 
17:41 < sipa> 4.8 is enough
17:45 -!- elkalamar [~elkalamar@84.126.69.179.dyn.user.ono.com] has quit [Remote host closed the connection]     
17:46 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
17:51 < earlz> Even with the (still somewhat far away) 2019 EOL for Trusty? 
17:51 < sipa> we don't use any c++11 features that aren't in gcc 4.8
17:52 < gmaxwell> jnewbery: I really think we should split the PR and merge the mark-used and topup if possible stuff, and make the shutdown and don't update parts a seperate PR.  The first part is done, solves the issue for unlocked wallets. And even for locked wallets results in rescan instructions that we can give to succesfully rescan "(unlock the wallet with a long time, run rescan)"... and doesn't have an r
17:52 < gmaxwell> isk of making things worse for anyone.
17:53 < earlz> My concern isn't bitcoin itself, but rather it's dependencies will start using C++11 features, making for more and more patches being required for gitian compiles
17:53 < sipa> earlz: i'm confused
17:54 < sipa> gitian is a fully deterministic environment, we control all the dependencies
17:54 < sipa> and their exact version
17:54 < earlz> yes of course, but at some point there will be a discussion "no, we can't upgrade boost because it will require patching out their use of things gcc 4.8 doesn't support" 
17:54 < sipa> heh, then we'll just upgrade gcc...
17:55 < earlz> that seems... non-trivial without also upgrading from trusty to xenial or building our own compilers within gitian as another dependency
17:56 < sipa> which we should do anyway
17:58 < earlz> heh at that point might as well make a deterministic linux distro too ;) 
17:58 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Ping timeout: 276 seconds]     
17:58 -!- parazyd [~parazyd@unaffiliated/parazyd] has quit [Ping timeout: 276 seconds]     
17:58 < earlz> but seriously, I guess it's nothing to worry about for now, just concerning for the future, and if EOL affects gitian builds using trusty
17:58 -!- parazyd [~parazyd@chat.dyne.org] has joined #bitcoin-core-dev     
17:58 -!- parazyd [~parazyd@chat.dyne.org] has quit [Changing host]     
17:58 -!- parazyd [~parazyd@unaffiliated/parazyd] has joined #bitcoin-core-dev     
17:59 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 276 seconds]     
17:59 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]     
17:59 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
17:59 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
17:59 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Read error: Connection reset by peer]     
18:00 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
18:00 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Excess Flood]     
18:01 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
18:01 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
18:03 < gmaxwell> earlz: eventually our depends system will compile GCC. 
18:03 < gmaxwell> earlz: and wrt upgrading normally the barrier there is just that it often restricts our ability to produce binaries that will run on older systems.
18:04 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
18:05 < earlz> What is the official target for "older systems"? Like what distros and such? 
18:09 < eck> earlz: btw if you wanted to upgrade gcc on gitian you'd probably have to upgrade it on travis as well, which is non-trivial/challenging, as trusty is the latest release supported by travis (and they didn't even roll that out until relatively recently)
18:09 < eck> thre are some changes they made to the std::string ABI in GCC 5.1+ but I'm not sure how pertinent they are here
18:10 < earlz> wow really? That's ridiculous 
18:10 < eck> it's not ridiculous, c++11 changed the std::string spec
18:11 < eck> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
18:11 < earlz> No I mean about Travis just recently supporting a 4 year old distro
18:11 < earlz> regarding std::string ABI stuff, would that really matter that much? I know compiling Bitcoin outside of Gitian (ie with system deps) works fine in every version of GCC I've tried
18:13 < eck> libstdc++ now supports both ABIs but it would be an issue if you built an executable that used the new ABI and tried to run it on a system with an old copy of libstdc++
18:15 < earlz> ah, and I assume static linking of stdc++ isn't feasible? 
18:17 -!- btcdrak [uid239175@gateway/web/irccloud.com/x-ruisgxytstqgzsel] has joined #bitcoin-core-dev     
18:20 < eck> i would recommend against it, anyway it would presumably be less of an issue in a year when trusty is closer to EOL
18:21 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
18:22 < cfields_> we static link libstdc++
18:22 < cfields_> so the abi is not an issue
18:23 < Chris_Stewart_5> funny, wumpus and i had a convo about upgrading gcc earlier today
18:24 < cfields_> yes, it was on my list for 0.15 but i didn't make it :(
18:24 < cfields_> 0.16 will use a self-built toolchain
18:24 < Chris_Stewart_5> Is there consensus on what the oldest version of gcc will be that we support?
18:25 < cfields_> well that's independent of gitian and the release process
18:25 < Chris_Stewart_5> Just 4.9.x instead of 4.8?
18:26 < Chris_Stewart_5> What does gcc version have to do with a self built toolchain? Does your self built toolchain stuff require a bunch of fancy c++11 features?
18:26 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 268 seconds]     
18:28 < cfields_> no. maybe i'm the one who conflated things there. I'm not sure what you meant by "upgrading gcc". If you mean "bumping the minimum version required", i doubt that'll change soon
18:30 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
18:30 < Chris_Stewart_5> ah, yes that is what i meant. 
18:33 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
18:35 -!- corinrose_ [uid137375@gateway/web/irccloud.com/x-igvtzblxmlpolnwh] has quit [Quit: Connection closed for inactivity]     
18:43 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
18:47 -!- rasengan [~rasengan@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has left #bitcoin-core-dev []     
19:00 < bitcoin-git> [bitcoin] theuni opened pull request #11012: Make sure to clean up mapBlockSource if we've already seen the block (master...cleanup-blocksource) https://github.com/bitcoin/bitcoin/pull/11012
19:13 -!- corinrose_ [uid137375@gateway/web/irccloud.com/x-jzxibtfthmnygnef] has joined #bitcoin-core-dev     
19:21 < bitcoin-git> [bitcoin] eklitzke closed pull request #11005: Tests: Add a lint check for trailing whitespace (master...whitespace) https://github.com/bitcoin/bitcoin/pull/11005
19:33 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
19:36 < bitcoin-git> [bitcoin] eklitzke opened pull request #11013: Build: Fix Automake warnings when running autogen.sh (master...override_gzip_env) https://github.com/bitcoin/bitcoin/pull/11013
19:45 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
19:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
19:49 < bitcoin-git> [bitcoin] eklitzke closed pull request #10880: Update .gitignore to ignore more test files (master...gitignore) https://github.com/bitcoin/bitcoin/pull/10880
20:03 -!- jamesob [~james@tempo-automation.static.monkeybrains.net] has quit [Ping timeout: 240 seconds]     
20:06 -!- NorbertArmstrong [~NorbertEg@75.167.151.250] has joined #bitcoin-core-dev     
20:15 -!- NorbertArmstrong [~NorbertEg@75.167.151.250] has quit [Ping timeout: 258 seconds]     
20:18 < luke-jr> ‎[20:23:44] ‎<‎jonasschnelli‎>‎ sdaftuar, luke-jr: about NODE_NETWORK_LIMITED_*. If we would treat them independently, would this mean, a peer signalling NODE_NETWORK_LIMITED_HIGH will always singal NODE_NETWORK_LIMITED_LOW? <-- I disagree with this approach
20:30 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]     
20:33 < luke-jr> jonasschnelli: … but I didn't realise nodes would OR service bits themselves. Nevermind.
20:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
20:41 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
20:54 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
21:07 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Quit: leaving]     
21:14 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
21:23 -!- Squidicc [~squid@pool-173-48-113-37.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
21:26 -!- Squidicuz [~squid@pool-173-48-113-37.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
21:31 -!- TheV01D [thev01d@btc.mining.ga] has quit [Ping timeout: 258 seconds]     
21:31 -!- marcoagner [~user@187.113.131.76] has quit [Ping timeout: 240 seconds]     
21:44 -!- marcoagner [~user@179.177.245.14] has joined #bitcoin-core-dev     
22:02 -!- j_ybt [~j_ybt@192.161.48.22] has quit [Quit: ZNC 1.6.1+deb1 - http://znc.in]     
22:05 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
22:05 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
22:06 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
22:07 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]     
22:25 -!- corinrose_ [uid137375@gateway/web/irccloud.com/x-jzxibtfthmnygnef] has quit [Quit: Connection closed for inactivity]     
22:37 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
22:40 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 258 seconds]     
23:21 -!- promag [~Adium@2001:8a0:fe30:de01:2c4e:e3a6:fa26:2609] has joined #bitcoin-core-dev     
23:31 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
23:42 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
23:46 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 255 seconds]     
23:48 -!- JackH [~laptop@217.149.140.177] has quit [Ping timeout: 260 seconds]     
23:50 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:50 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
23:53 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Ping timeout: 240 seconds]