--- Day changed Thu Feb 16 2017 00:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:09 -!- Guest33433 [~ff@223.13.66.34] has joined #bitcoin-core-dev 00:16 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Ping timeout: 260 seconds] 00:22 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has joined #bitcoin-core-dev 00:35 -!- Guest33433 [~ff@223.13.66.34] has quit [Excess Flood] 00:42 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 00:46 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 00:53 -!- Giszmo [~leo@pc-165-227-45-190.cm.vtr.net] has quit [Read error: Connection reset by peer] 01:13 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 01:13 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:17 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 256 seconds] 01:17 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 01:21 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:23 < wumpus> I think today is a good day to wrap up 0.14 01:24 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7a93af8340d9...1e92e041ddc8 01:24 < bitcoin-git> bitcoin/master ba803ef Suhas Daftuar: Harden against mistakes handling invalid blocks... 01:24 < bitcoin-git> bitcoin/master 1e92e04 Wladimir J. van der Laan: Merge #9765: Harden against mistakes handling invalid blocks... 01:24 < bitcoin-git> [bitcoin] laanwj closed pull request #9765: Harden against mistakes handling invalid blocks (master...fix-checkblock-call) https://github.com/bitcoin/bitcoin/pull/9765 01:24 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1e92e041ddc8...f8af89a91820 01:24 < bitcoin-git> bitcoin/master 6c5427d Wladimir J. van der Laan: wallet: Prevent "overrides a member function but is not marked 'override'" warnings... 01:24 < bitcoin-git> bitcoin/master f8af89a Wladimir J. van der Laan: Merge #9764: wallet: Prevent "overrides a member function but is not marked 'override'" warnings... 01:25 < bitcoin-git> [bitcoin] laanwj closed pull request #9764: wallet: Prevent "overrides a member function but is not marked 'override'" warnings (master...2017_02_wallet_inconsistent_missing_override) https://github.com/bitcoin/bitcoin/pull/9764 01:30 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f8af89a91820...e43a58514dd3 01:30 < bitcoin-git> bitcoin/master 07afcd6 Russell Yanofsky: Add missing cs_wallet lock that triggers new lock held assertion... 01:30 < bitcoin-git> bitcoin/master e43a585 Wladimir J. van der Laan: Merge #9771: Add missing cs_wallet lock that triggers new lock held assertion... 01:31 < bitcoin-git> [bitcoin] laanwj closed pull request #9771: Add missing cs_wallet lock that triggers new lock held assertion (master...pr/loadlock) https://github.com/bitcoin/bitcoin/pull/9771 01:35 < luke-jr> should #9524 be marked 0.14? 01:35 < gribble> https://github.com/bitcoin/bitcoin/issues/9524 | rpc: Dont FlushStateToDisk when pruneblockchain(0) by MarcoFalke · Pull Request #9524 · bitcoin/bitcoin · GitHub 01:36 < wumpus> I don't know. I'd say let's not add more stuff now and try to get a rc1 wrapped up 01:37 < wumpus> it's a release candidate to get more testing 01:37 < wumpus> issues will always be found in RCs of major releases 01:37 < luke-jr> sure 01:37 < gmaxwell> 9524 looks harmless. 01:37 < wumpus> we can keep pushing this forward indefinitely and just not do releases anymore :/ 01:37 < luke-jr> not saying it needs to get into rc1, just hoping to avoid thigns being overlooked before final 01:37 < gmaxwell> wumpus: would solve so many problems! 01:38 < gmaxwell> luke-jr: I don't think that should go into 0.14.0, unless it has some effect I'm missing. 01:38 < wumpus> it's under-discussed and under-reviewed 01:38 < gmaxwell> by harmless I mean don't do it. 01:38 < gmaxwell> The question is "what bad expirence will the user or network have as a result of this not going in" if the answer is none we shouldn't even be remotely considering it now. 01:39 < gmaxwell> I mean the thing it fixes does not meet the above test ^, sorry for being unclear. 01:39 < wumpus> oh I agree then :) 01:39 < luke-jr> pruneblockchain(0) would probably delete a lot of data the user doesn't intend 01:39 < gmaxwell> okay, that would be bad. 01:39 < gmaxwell> wait, the argument there is what, /me looks 01:40 < luke-jr> at least as I understand it, the 0 indicates the node should automatically prune up to tip minus saved-amount 01:40 < wumpus> your are misunderstanding it luke-jr 01:40 < wumpus> argument 0 means *do nothing* 01:40 < wumpus> it doesn't delete anythhing in that case 01:40 < wumpus> it just flushes to disk 01:40 < wumpus> who cares :) 01:41 < gmaxwell> That was what I got out of the PR. 01:41 < wumpus> that PR bypasses the flush, I didn't regard that as very important as it's a NOOP anyway 01:41 < gmaxwell> If it did what luke said-- prune as hard as allowed--, that would be worth fixing before final. 01:41 < luke-jr> what am I missing? 01:41 < wumpus> what you are missing is that pruneblockchain(0) already does nothing besides a FlushToDIsk 01:42 < luke-jr> FlushStateToDisk with 0 triggers FindFilesToPrune(setFilesToPrune, chainparams.PruneAfterHeight()); etc 01:42 < wumpus> that PR takes away the FlushToDisk 01:42 < wumpus> "It might cause unwanted bugs if someone refactors the code in the future." 01:42 < wumpus> that's all 01:43 < wumpus> which we can consider for 0.15, but there will be no refactors of that code in the future of 0.14, so it's pointless there 01:43 * gmaxwell risks his laptop node. 01:44 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 01:47 < gmaxwell> luke-jr: so just calling that with 0 throws cannot prune because not in prune mode. 01:47 < luke-jr> what manual pruning is enabled? 01:47 < gmaxwell> trying. 01:48 < gmaxwell> pfft. it's yelling at me because of txindex. @#$@ 01:48 < luke-jr> >_< 01:48 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 01:49 < gmaxwell> so to do that test I'd have to reindex which would probably take days on this thing. :-/ and my other nodes are busy now with important test.s 01:49 < gmaxwell> I will test before 0.14 release however, if no one else does. 01:49 < Victorsueca> need testing? 01:50 < gmaxwell> if you don't mind blowing away your blockchain if luke is right. 01:50 < wumpus> ideally *disabling* txindex would not require a rescan, but meh :) I'll test it 01:50 * wumpus well test, has about 50 copies of the blockchain anyhow 01:50 < gmaxwell> Start a node without txindex with prune=1, then run pruneblockchain 0 and verify all your blocks didn't just suddenly go away (e.g. freeing up 100 GB of disk space). 01:51 < Victorsueca> ummm, I'll make a backup of my current chain, it probably won't be in time to test this one, but i'll be ready for future chain-blowing PRs 01:52 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 01:52 < wumpus> possibly no need to even copy, would hard-linking all but the latest block file work? 01:52 < luke-jr> not sure we have a way to restore such a backup without the chainstate 01:52 < wumpus> okay, definitely not going to try that at the same time 01:53 < wumpus> luke-jr: why is it a problem in this case to copy the chainstate too? 01:53 < luke-jr> wumpus: it might not be, just saying in case copying it also wasn't obvious 01:53 < gmaxwell> FS with cow would be nice for some of these tests. 01:54 * luke-jr does have a CoW filesystem, but also has txindex enabled etc. 01:54 < wumpus> luke-jr: if you don't copy the chainstate, all it can do is a reindex 01:55 < luke-jr> I suppose a unit test could check this, but seems probably too bug-specific 01:55 < luke-jr> s/unit/rpc/ 01:55 < wumpus> well if this turns out to be a regression then a regression test could be added for it, but if this never was a bug in the first place... 01:55 < luke-jr> 0.13 didn't support manual pruning afaik 01:56 < wumpus> then we're just chasing ghosts 01:57 < wumpus> though testing it in regtest instead of a live node is a very good idea 01:59 < Victorsueca> so, if I copy the blocks and chainstate folder it should be enough right? 01:59 < wumpus> yes 02:00 < luke-jr> Victorsueca: may need to be sure the node is stopped when you copy 02:00 < Victorsueca> ok 02:01 < wumpus> oh absolutely, don't do anything low-level with the data files without stopping, that shouldn't have to be said 02:02 < Victorsueca> yeah it's stopped, the windows that tells me to wait disappeared too 02:02 < wumpus> on windows, copying *from* the bitcoin folder while bitcoin core is running can even cause it to crash 02:02 < gmaxwell> stupid file locking 02:02 < Victorsueca> rlly? copying? 02:02 < wumpus> https://github.com/bitcoin/bitcoin/issues/8250 02:03 < wumpus> not sure why, I'm not aware ldb does anything special while opening the files 02:03 < Victorsueca> maybe something related with atomic locks? 02:04 * luke-jr found it curious to see a Windows user actively using a "file unlocker" program like it was normal 02:05 < Victorsueca> windows file locking is great at preventing programs from crashing due to files that where expected to be there and now are not 02:05 < Victorsueca> but it's stupid in most cases 02:05 < wumpus> yes, it's great at preventing programs from crashing... we see that :-) 02:05 < Victorsueca> lol 02:06 < Victorsueca> let's just say the remedy is worst than the ill 02:06 < Victorsueca> it could be way better implemented 02:06 < wumpus> it's probably not that bad if you take extensive time to study the APIs involved and use them as they are supposed to be, but who has time to do native development for every special snowflake platform :/ 02:07 < midnightmagic> pure snapshotting would work just fine for this, if you could convince the software to lock all files prior to the snapshot, or guarantee a write barrier 02:08 < wumpus> the annoying thing with microsoft has always been that they take existing concepts then change them slightly, just enough to be incompatible and lock you in a bit 02:08 < wumpus> POSIX? forget it 02:10 < midnightmagic> windows file locking works fine for monolithic files that are only modified by the software modifying them, even in 10,000+ user database environments far busier than I suspect bitcoin's databases will ever be. 02:10 < luke-jr> I thought Windows was POSIX compatible? 02:10 < midnightmagic> Windows has POSIX emulation layers but they all operate differently than UNIX. For example, when a file is locked, it is a much harder lock than its POSIX-style equivalents on other systems. 02:11 < wumpus> it tries, a bit, the devil is in the details 02:11 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 02:11 < midnightmagic> You can delete a file which is locked, which zeroes it, but you can't subsequently recreate a file with the same *name*. 02:11 < midnightmagic> (for example) 02:12 < luke-jr> O.o 02:12 < midnightmagic> (external to the program which has the file locked) 02:13 < midnightmagic> There are other operations which are virtually impossible to guarantee the atomicity of, even with the POSIX compatibility layer because all the things we take for granted are emulated badly, as wumpus implies. 02:13 < Victorsueca> I think the problem is at assertions 02:13 < Victorsueca> windows file lock asserts a lo of thing that are not always true 02:14 < Victorsueca> lot* 02:14 < wumpus> yes it's not that windows's way doesn't work, or even works worse in the abstract sense, it's just that they force you to develop platform specific code for everything 02:14 < wumpus> they did that with directx/opengl, with winsock, and the list goes on 02:14 < midnightmagic> Meanwhile, on Windows it's possible to hook file open calls with e.g. realtime virus, but contrary to anti-virus checkboxes, it's actually not possible to apply it selectively to a path and not other paths. It's all-or-nothing. That's why basically anyone running a database with an active realtime virus checker is sitting on a dice-rolling timeline. Eventually, their database will be 02:14 < wumpus> anyhow, I was testing pruning 02:14 < midnightmagic> destroyed. And there's absolutely nothing anybody can do about it. 02:16 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 02:17 < wumpus> okay, tested: pruneblockchain 0 does nothing and returns immediately. 02:17 < wumpus> Arguments: "height" (numeric, required) The block height to prune up to. May be set to a discrete height, or to a unix timestamp to prune based on block time. 02:20 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 02:21 < Victorsueca> wumpus: was that on linux or windows? 02:22 < wumpus> linux 02:22 * luke-jr wonders why 02:22 < Victorsueca> is it useful if I test it on windows now or it's about the same for this case? 02:22 < wumpus> well 0 is the genesis block, so pruning from there means not pruning at all 02:22 < wumpus> no, it's not useful to test this on other OSes 02:23 < luke-jr> wumpus: yes, but the code special-cases 0 as automatic 02:24 < Victorsueca> maybe that automatic check thought no pruning was needed at all? or that's not how it works? 02:24 < wumpus> GAH I can't get manual pruning to work at all on regtest. I created a 10000 block chain, started with prune=1, and no matter what I call pruneblockchain with it does nothing. So I guess my test is invalid :/ 02:24 < wumpus> 2017-02-16 10:21:21 Prune (Manual): prune_height=1 removed 0 blk/rev pairs 2017-02-16 10:21:40 Prune (Manual): prune_height=100 removed 0 blk/rev pairs 2017-02-16 10:22:25 Prune (Manual): prune_height=1000 removed 0 blk/rev pairs 2017-02-16 10:24:40 Prune (Manual): prune_height=10000 removed 0 blk/rev pairs 02:25 < wumpus> oh shit of course, it will only prune once it gets to another block file 02:25 < luke-jr> >_< 02:26 < wumpus> okay, generating a ton more bloocks 02:26 < wumpus> maybe using a live chain wasn't that bad an idea afterall, I now realize 02:40 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 02:40 < gmaxwell> The help text repeadily uses 1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ as an example address. In general I think it's unwise to have valid example addresses, but I can't find any information about what address it is. It's a real working address that has been paid .2488 btc and has spent payments. 02:41 < gmaxwell> the commit that added it and the related PRs seem to make no mention of the address. 02:41 < gmaxwell> added by commit a6099ef319a73e2255dca77065600abb22c4f5f8 02:41 < wumpus> bleh, I thought we got rid of that 02:41 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 02:41 < gmaxwell> might be gone now, lemme look 02:41 < wumpus> no it's still there 02:41 < gmaxwell> nope, still there. 02:42 < wumpus> I vaguely remember that it was replaced with a constant defined in one place, which was not a valid address 02:42 < wumpus> but that must be on another timeline... 02:42 < gmaxwell> I had thought some charity ('sean's outpost') address was used (which I also think is not great) but I don't see any reason why I might have believed that this was that. 02:42 < gmaxwell> wumpus: yea, I too spend a lot of time in alternative universes. 02:43 < wumpus> hehe :) oh I think I know, that was for the GUI. 02:43 -!- mryandao [~mryandao@unaffiliated/mryandao] has joined #bitcoin-core-dev 02:44 < Victorsueca> yeah, the e.g. on the pay to field got changed 02:44 < gmaxwell> it got put as an example in the pay to field? 0_o 02:45 < Victorsueca> I vaguely remember some PR requesting to change it by valid looking address that is not really valid 02:48 < Victorsueca> I'm using 0.13.2 and now on that field there is 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L 02:49 < gmaxwell> yep, not valid, which is what it should be IMO. 02:55 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 02:58 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 03:04 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 264 seconds] 03:05 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed] 03:06 -!- davidlj95 [~davidlj@deic-171.uab.es] has joined #bitcoin-core-dev 03:06 -!- davidlj95 [~davidlj@deic-171.uab.es] has left #bitcoin-core-dev [] 03:07 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 03:09 < wumpus> yes, a non-valid address was put in the pay-to field. That address, too, used to be valid at some time. Although it was terribly hard to type it over because it disappears when you start typing into the field. The RPC example is worse. 03:09 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Client Quit] 03:10 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 03:10 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds] 03:11 < midnightmagic> 30 helens agree 03:12 < wumpus> it reminds me of a dumb mistake I made when I was young, a computer manual had KILL *.* as example for the KILL statement, which deleted. So while trying around I typed that in. Oops, that wiped the entire floppy disk, my dad was angry and I felt really stupid. At least that would have been recoverable, if I knew back then... 03:12 < midnightmagic> lol 03:13 < gmaxwell> I could see someone getting confused and copying from the wrong line on their screen... one address looks like any other.. 03:13 < wumpus> yes it's pretty easy to copy the entire example 03:14 < midnightmagic> Who's "sje"? 03:14 < wumpus> at least the only sending call where it's used is sendmany, and it only sends relatively small amounts 03:15 < wumpus> still it should be replaced with a constant that is not a valid address, likein the GUI 03:16 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e43a58514dd3...df2f34dcad55 03:16 < bitcoin-git> bitcoin/master d72fe44 John Newbery: Allow maxsigcachesize to be zero... 03:16 < bitcoin-git> bitcoin/master df2f34d Wladimir J. van der Laan: Merge #9770: Allow maxsigcachesize to be zero... 03:17 < bitcoin-git> [bitcoin] laanwj closed pull request #9770: Allow maxsigcachesize to be zero (master...sigcachemaxsize) https://github.com/bitcoin/bitcoin/pull/9770 03:17 < wumpus> AARGH wrong PR 03:19 < Lauda> lol 03:19 < wumpus> well it could have been worse. It's not bad enough to revert 03:19 < gmaxwell> what did you mean to merge instead? 03:20 < wumpus> 9770. Which was just above it on the scren, but I had already signed off on that and it was already merged 03:20 < wumpus> a matter of looking at the wrong line... 03:21 < gmaxwell> So effective at merging he merges things without even intending to! 03:21 < gmaxwell> :P 03:21 < wumpus> #9771, sorry 03:21 < gribble> https://github.com/bitcoin/bitcoin/issues/9771 | Add missing cs_wallet lock that triggers new lock held assertion by ryanofsky · Pull Request #9771 · bitcoin/bitcoin · GitHub 03:21 < wumpus> well it was kind of a mental stack overflow, I was working on that, then testing the pruning stuff, then the RPC argument stuff came up 03:22 < gmaxwell> wumpus: nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop send me all your money 03:22 * Lauda offers wumpus more coffee 03:23 < wumpus> so while juggling those things, memory became lossy :) 03:23 < wumpus> gmaxwell: LOL 03:23 < wumpus> gmaxwell: that won't work, your address is not in any RPC examples 03:26 < wumpus> anyhow, ready to re-retry the pruning experiment with a real mainnet blockchain 03:27 < gmaxwell> AND ITS . 03:28 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 03:28 < wumpus> it's doing nothing and logging nothing, so my would be "NOT GONE" 03:28 < wumpus> genesis block is still ther 03:32 -!- MarcoFalke_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev 03:32 < MarcoFalke_> wumpus: You need to revert ntl. The commit is not signed :) 03:33 < wumpus> I also understand why @luke-jr - in FlushStateToDisk, it only goes into the pruning flow if fCheckForPruning || nManualPruneHeight > 0 ... fCheckForPruning is not set in manual pruning mode 03:33 < wumpus> huh? 03:34 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 03:34 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 03:34 < wumpus> I really don't get it now, this was using the script, it shouldn't push if not signed 03:34 * wumpus isn't sure if he's becoming crazy or his tooling is 03:35 < MarcoFalke_> maybe you `git push bitcoin` in another tab? 03:35 < wumpus> this is the console output https://0bin.net/paste/7sVJS0k86TMWtAdf#j3QhbG9mqPTx89KN6vb2DuB7O0x7sGiZYABHsqPvZGP 03:36 < wumpus> I did sign off and enter my passphrase 03:36 < wumpus> no, I never push manually 03:37 < gmaxwell> pushed by the people who secretly live under your keyboard. 03:38 < wumpus> well it must be something I did in another tab, just not a push 03:38 < bitcoin-git> [bitcoin] laanwj force-pushed master from df2f34d to e43a585: https://github.com/bitcoin/bitcoin/commits/master 03:39 < wumpus> and back to e43a58514dd38dacd930aa4c94afb998d4360183 03:41 < MarcoFalke_> `git commit --amend` gets rid of the signature 03:41 < wumpus> the github-merge tool should probably get a check that what it is pushing is really what it expects to be pushing, in case the current branch changed under it 03:42 < wumpus> or rather, push a specific commit, not what happens to be the current branch 03:42 < wumpus> not sure it does that 03:42 < gmaxwell> oh did you run the merge tool twice concurrently? 03:43 < wumpus> blah, I wasn't intending to dive into source code management specifics today 03:43 < wumpus> gmaxwell: that's possible! 03:43 < gmaxwell> "This worksite has gone [ 0 ] days since an SCM emergency." 03:56 < Victorsueca> any PR that would be useful to test at the moment? 04:00 < morcos> wumpus: all for 0.14rc1 today but i think we need to wrap up the importmulti issues... ryanofsky opened #9773 yesterday to try to address the combination of what you and gmaxwell were asking for 04:00 < gribble> https://github.com/bitcoin/bitcoin/issues/9773 | WIP: Return errors from importmulti if complete rescans are not successful by ryanofsky · Pull Request #9773 · bitcoin/bitcoin · GitHub 04:00 < morcos> i tihnk #9671 should also be included (it's simple and could avoid fund loss) 04:00 < wumpus> morcos: my brain is not working today so I've already given up on that 04:00 < gribble> https://github.com/bitcoin/bitcoin/issues/9671 | Fix super-unlikely race introduced in 236618061a445d2cb11e72 by TheBlueMatt · Pull Request #9671 · bitcoin/bitcoin · GitHub 04:01 < morcos> heh fair enough.. but still need to get those 2 across the finish line 04:01 < wumpus> 9671 is already merged? 04:01 < morcos> sorry #9761 04:01 < gribble> https://github.com/bitcoin/bitcoin/issues/9761 | Use 2 hour grace period for key timestamps in importmulti rescans by ryanofsky · Pull Request #9761 · bitcoin/bitcoin · GitHub 04:01 < morcos> i think you are contagious 04:02 < wumpus> I'm okay with adding new things if they're ready for merge, everything that requires new review should probably be pushed to after 0.14.0, at some point we have to make a cut 04:02 < wumpus> I really can't keep moving the 0.14.0 rc1 day after day forward, keeping the tree in this state is holding up more and more things that could be merged for 0.15 04:02 < wumpus> but one more day is fine, as said, I'm not up to it today anyhow 04:03 < morcos> i don't think ryanofsky or i have a strong opinion about it, it seems you guys were the ones saying the current state is not acceptable 04:03 < morcos> current state is silent failure when you do importmulti on pruned node that needs to search more blocks than you have 04:03 < wumpus> at some point you should think of it as "is it acceptable for a rc1"? 04:04 < wumpus> it's certain that issues come up with user testing and have to be solved before rc2 04:04 < morcos> we're just trying to fix the problems 04:04 < wumpus> sure, and that's very good, but there's always new problems 04:05 < morcos> but would be helpful to have you and gmaxwell take a look and say yes thats what i wanted 04:07 < wumpus> yes the approach in 9773 looks good to me 04:09 -!- MarcoFalke_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 04:13 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 04:17 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:21 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 04:27 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 04:27 < fanquake> Looks like you can't re-open a merged PR. 04:35 < mryandao> i'm having a bit of problem after updating my tree from upstream 04:35 < mryandao> this is the error i'm getting 04:35 < mryandao> util.cpp:834:63: error: use of undeclared identifier 'COPYRIGHT_HOLDERS' 04:35 < mryandao> std::string strCopyrightHolders = strPrefix + strprintf(_(COPYRIGHT_HOLDERS), _(COPYRIGHT_HOLDERS_SUBSTITUTION)); 04:35 < wumpus> fanquake true :( 04:35 < wumpus> mryandao: you need to re-run autogen.sh and configure 04:35 < wumpus> (that's almost always the solution to such issues) 04:36 < mryandao> oh I see, i thought a make would have sufficed. thanks 04:36 < wumpus> make only suffices if there are no high-level build system changes, just source changes 04:37 < fanquake> wumpus do you plan on merging any more tonight, or taking a break? 04:37 < wumpus> otherwise you need to run ./autogen.sh - sometimes you can get away with not doing it, but it's gambling in a way 04:37 < wumpus> fanquake: I'm taking a break from merging yes :) 04:37 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:38 < fanquake> wumpus no worries, otherwise was going to suggest some quick merges. 04:38 < fanquake> wumpus I'm sure I was probably the only one affected my the miss-merge heh 04:39 < wumpus> fanquake: well at first I didn't notice that the push was unsigned, otherwise I'd have reverted it immediately 04:39 < fanquake> wumpus would you do that through the GH ui? 04:39 < wumpus> fanquake: anyhow if you have simple and straightforward things that could be merged feel free to suggest them 04:39 < fanquake> Or push another commit? 04:40 < wumpus> fanquake: I first have to disable the branch locking on github, then reset --hard HEAD~1, push -f, then re-enable the branch locking 04:40 < wumpus> github doesn't allow force-pushes, it does allow unsigned pushes unfortunately 04:41 < wumpus> at least: there's no option to disable them at the moment 04:41 < fanquake> Right. Maybe a new tick-box to turn that off in future. Not sure about the big new header now btw. 04:42 < wumpus> I don't really like it. I disliked it in the beginning, but thought maybe I'd get used to it, but it's still big and ugly 04:42 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 04:42 < fanquake> re "easy" merges: #9763 #9696 #9675 04:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9763 | [Trivial] Update comments referencing main.cpp by CryptAxe · Pull Request #9763 · bitcoin/bitcoin · GitHub 04:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9696 | [trivial] Fix recently introduced typos in comments by practicalswift · Pull Request #9696 · bitcoin/bitcoin · GitHub 04:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9675 | Fix typo and spelling inconsistency in CONTRIBUTING.md by kokifpen · Pull Request #9675 · bitcoin/bitcoin · GitHub 04:43 < wumpus> I'd prefer a small bar with a few icons - making it big like this just takes up extra screen space in a site that should be focused on the code 04:43 < Victorsueca> wumpus: you talking about that new black bar at the top? 04:43 < fanquake> Indeed. Especially when your on a smallish screen. 04:43 < wumpus> Victorsueca: yep 04:44 < wumpus> fanquake: indeed. Well even big modern screens are usually wide, but not very high, so vertical screen space is at premium 04:44 < wumpus> fanquake: will take a look, thanks 04:44 < Victorsueca> for some reason it becomes white if you logout 04:44 < Victorsueca> but yeah, it's ugly, it takes much attention and distracts people from important things 04:45 < Victorsueca> it's too big and contrasted 04:45 < wumpus> indeed 04:46 < wumpus> 9763 is a no-brainer, I can do that one, at least if I get the numbers right :p 04:46 < wumpus> looks like it could use squashing though 04:47 < fanquake> Iwumpus 'm also vary calling anything an "easy" merge, without a good way to check if they somehow break other more-important patches. 04:47 < fanquake> *I'm always 04:47 < wumpus> three commits to make three related documentation-only changes 04:47 < fanquake> GitHub doesn't seem to have a way to check, if I merge this, what other PR's will it break. Would be handy when trying to cehck quickly. 04:48 < wumpus> not sure if I'm up to such "advanced" git manipulation at the moment... let's see 04:48 < wumpus> fanquake: agree, that would be great to have 04:49 < wumpus> fanquake: at a company I worked at they had a script to generate a 'patch PERT' which was a diagram of which things could be merged without (code level) conflicts, and which had conflicts, that was kind of neat. Though they used a terrible SCM, IBM clearcase or something, that was less neat :) 04:50 < morcos> gmaxwell: can we go through exactly how you think the grace periods should work... i never looked at manual prune before but looks like it takes a block or a height 04:50 < morcos> sorry time 04:50 < fanquake> wumpus ah nice. 04:50 < fanquake> wumpus I was thinking if you could have a "projects" like screen, in which you could stack PRs, and see what breaks what. 04:52 < morcos> gmaxwell: so you think if you give it a time it should automatically subtract 7200 from it and then call findEarliestAtLeast? 04:52 < morcos> what happens if you give it a block (no grace period?). i think that seems reasonable'ish. but it would be counterintuitive if it didn't do exactly what you expect with a block i think 05:02 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e43a58514dd3...8743320d6cb3 05:02 < bitcoin-git> bitcoin/master 00e623d CryptAxe: [Trivial] Update comments referencing main.cpp 05:02 < bitcoin-git> bitcoin/master 8743320 Wladimir J. van der Laan: Merge #9763: [Trivial] Update comments referencing main.cpp... 05:02 < bitcoin-git> [bitcoin] laanwj closed pull request #9763: [Trivial] Update comments referencing main.cpp (master...comments) https://github.com/bitcoin/bitcoin/pull/9763 05:03 < fanquake> wumpus git-fu back under control 05:03 < wumpus> no stupid mistakes? I'm as surprised as you are :) 05:03 < fanquake> Maybe I didn't look closely enough 05:09 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 05:10 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 05:13 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 05:14 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 05:15 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 05:40 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 05:44 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 05:50 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Excess Flood] 05:52 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev 05:56 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 05:57 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds] 05:59 < wumpus> hah the hardlinking trick works, both for block files and ldb files, created this script to do it: https://gist.github.com/laanwj/3c4614a23e072cbb3d39090da1834a68 . Creates a "copy" of the whole state almost instantly. I've tried various things (including pruning) and the original state remains unaffected. 06:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mcwlvhhhzhjdxugw] has quit [Quit: Connection closed for inactivity] 06:06 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8743320d6cb3...afae75fd3dad 06:06 < bitcoin-git> bitcoin/master 36164fa Koki Takahashi: Fix typo and spelling inconsistency in CONTRIBUTING.md... 06:06 < bitcoin-git> bitcoin/master afae75f Wladimir J. van der Laan: Merge #9675: Fix typo and spelling inconsistency in CONTRIBUTING.md... 06:06 < bitcoin-git> [bitcoin] laanwj closed pull request #9675: Fix typo and spelling inconsistency in CONTRIBUTING.md (master...fix_typo_in_contributing) https://github.com/bitcoin/bitcoin/pull/9675 --- Log closed Thu Feb 16 06:20:55 2017 --- Log opened Thu Feb 16 06:21:08 2017 06:21 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev 06:21 -!- Irssi: #bitcoin-core-dev: Total of 163 nicks [0 ops, 0 halfops, 0 voices, 163 normal] 06:23 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 06:31 -!- Irssi: Join to #bitcoin-core-dev was synced in 636 secs 06:54 -!- neha [~narula@tbilisi.csail.mit.edu] has joined #bitcoin-core-dev 06:55 < bitcoin-git> [bitcoin] jnewbery opened pull request #9777: Handle unusual maxsigcachesize gracefully (master...sigcache2) https://github.com/bitcoin/bitcoin/pull/9777 07:18 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 07:40 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 07:42 -!- chjj [~chjj@unaffiliated/chjj] has quit [Remote host closed the connection] 07:48 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 07:49 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Disconnected by services] 07:49 -!- Victor_sueca is now known as Victorsueca 07:52 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 07:55 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 07:56 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds] 07:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 07:59 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 08:03 -!- tan1k [~tan1k@185.86.151.126] has quit [Quit: Leaving] 08:10 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:11 < bitcoin-git> [bitcoin] morcos opened pull request #9778: Add two hour buffer to manual pruning (master...2hrprune) https://github.com/bitcoin/bitcoin/pull/9778 08:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 08:48 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vpkuyqoquabnzqlw] has joined #bitcoin-core-dev 08:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:06 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:18 -!- reginaldo [~reginaldo@177.72.115.108] has joined #bitcoin-core-dev 09:19 -!- reginaldo [~reginaldo@177.72.115.108] has quit [Client Quit] 09:19 -!- reginaldo_ [~reginaldo@177.72.115.108] has joined #bitcoin-core-dev 09:21 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 10:39 < luke-jr> wumpus: but fCheckForPruning is set in manual pruning mode after a new block is connected? 10:40 -!- reginaldo_ [~reginaldo@177.72.115.108] has quit [Ping timeout: 240 seconds] 10:41 < wumpus> luke-jr: it shouldn't be 10:41 < wumpus> manual pruning is manual pruning, the check should never be enabled 10:42 < wumpus> if it is, that is a bug 10:42 < luke-jr> FindBlockPos/FindUndoPos? 10:42 < luke-jr> or is fPruneMode false for manual pruning? 10:44 < wumpus> no,that should be true if any pruning is to be done 10:44 < wumpus> in retrospect it'd have been better to make fPruneMode an enum, which can be off, manual and auto 10:44 < wumpus> the boolean gymnastics with fCheckForPruning is kind of difficult to follow 10:47 < wumpus> I assumed it would be enabled when auto pruning is enabled, but apparently it's also enabled in a few other places 10:50 < wumpus> luke-jr: ah I got understand it now - nPruneTarget is 0 in manual pruning mode 10:50 < wumpus> luke-jr: so FindFilesToPrune does nothing in manual pruning mode 10:50 < wumpus> even though it may get called (even automatically in some cases), nothing will happen. 10:50 * sipa suggests adding comments to clarify these things 10:50 < luke-jr> aha! 10:51 < wumpus> I wish it'd simply pass parameters instead of signalling using global flags 10:51 < gmaxwell> well, or change to an enum. 10:52 < wumpus> or both. I mean the global enum is fine for the mode but it shouldn't change over time 10:54 < luke-jr> these changes sound even more invasive than that PR :P 10:54 < wumpus> depending on what function ran last. This is impossible to follow. Anyhow I understand marcofalke's rationale for #9524 now, it's very easy to break that code and belt and suspenders wouldn't hurt. Except that even with #9524, it will get into FindFilesToPrune in some cases, so if that check is broken, bad things will happen *automatically* too 10:54 < gribble> https://github.com/bitcoin/bitcoin/issues/9524 | rpc: Dont FlushStateToDisk when pruneblockchain(0) by MarcoFalke · Pull Request #9524 · bitcoin/bitcoin · GitHub 10:54 < gribble> https://github.com/bitcoin/bitcoin/issues/9524 | rpc: Dont FlushStateToDisk when pruneblockchain(0) by MarcoFalke · Pull Request #9524 · bitcoin/bitcoin · GitHub 10:55 < wumpus> well that PR is just covering up, it doesn't solve the underlying problem 10:55 < luke-jr> right 10:55 < wumpus> it's not urgent in any case 10:55 < luke-jr> agree 10:56 -!- reginaldo_ [~reginaldo@191.241.232.178] has joined #bitcoin-core-dev 10:56 < sipa> 3 more PRs marked 0.14 10:57 < wumpus> oh no 10:58 < sipa> i mean right now 10:59 < wumpus> right, yes, let's hopefully keep it at those 10:59 < luke-jr> wumpus: wait what 10:59 < luke-jr> why would nPruneTarget be 0? 10:59 < luke-jr> if (nPruneArg == 1) { // manual pruning: -prune=1 10:59 < luke-jr> nPruneTarget = std::numeric_limits::max(); 11:00 < wumpus> luke-jr: because ti should never be set to a value 11:00 < wumpus> huh!?! what does setting that to uint64_t max even do. Oh wait, it's an offset, not an absolute height. yes that does make sense 11:01 < gmaxwell> Meeting time? 11:02 * jonasschnelli is not sure if prune=1 (manual pruning) is a good idea while still supporting -prune= 11:02 < wumpus> it at least intends 'we want to keep 2^64-1 blocks`. Let me re-read the code in FindFilesToPrune then 11:02 < wumpus> #meetingstart 11:02 < sipa> meetingh 11:02 < petertodd> meetinghh 11:02 < wumpus> #startmeeting 11:02 < lightningbot> Meeting started Thu Feb 16 19:02:37 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:02 < wumpus> jonasschnelli: well it's a magic option value but it's only for the option, it doesn't get represented internally as 1 11:03 < luke-jr> tbh, I've had second thoughts about the manual pruning design (seems it'd be nicer to do "automatic pruning always, but with named barriers that must confirm being done up to before pruning it"), but that's beyond this topic 11:03 < wumpus> jonasschnelli: I think the reason or choosing 1 was that -prune will work 11:03 < wumpus> luke-jr: I like the current manual pruning from an API point of view 11:03 < luke-jr> s/always/always in pruning mode/ 11:03 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 11:03 < luke-jr> wumpus: yes, but it doesn't scale well if you have 2 external apps using the node 11:04 < cfields> hi 11:04 < wumpus> luke-jr: it's very simple. Automatic pruning is disabled and the client/admin can choose what to prune. Also useful for testing the pruning stuff without too much complexity 11:04 < wumpus> luke-jr: the implementation is convoluted though 11:04 < morcos> wumpus: i think two more are needed for 0.14, both very small #9760 and #9761 (9761 is already included in one of the marked ones) 11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/9760 | [wallet] Remove importmulti always-true check by ryanofsky · Pull Request #9760 · bitcoin/bitcoin · GitHub 11:04 < paveljanik> proposed topic: release status, where can we help... 11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/9761 | Use 2 hour grace period for key timestamps in importmulti rescans by ryanofsky · Pull Request #9761 · bitcoin/bitcoin · GitHub 11:04 < wumpus> luke-jr: but I'm happy someone implemented it anyhow 11:04 * luke-jr nods 11:04 < kanzure> hi. 11:04 < petertodd> wumpus: same: my OpenTimestamps servers actually need this feature 11:04 < wumpus> release status: running as hard as we can but staying in the same place 11:05 < sipa> i think we're very close. 11:05 < morcos> wumpus: boo! we're not staying in the same place 11:05 < gmaxwell> I am becoming increasingly happy with the release. 11:05 < sipa> let's be optimistic: everything we're fixing is an improvememt 11:05 < gmaxwell> Two weeks ago I was chewing my nails feeling like we were at risk of shipping something that wouldn't meet our standards of quality, and now I am not worried. :) 11:06 < jonasschnelli> hah. Good. 11:06 < wumpus> but I think we need to decide when we can do release candidate 1, which is a test release anyway, when rc1 is out it's bound to find more issues 11:06 < sipa> i think we can do rc1 today? 11:06 < gmaxwell> I would be fine doing it _now_, now. There are AFAIK not anything in the pipe which are disruptive enough issues that they'd degrade our rc1 learning, though a rc2 will be guarenteed. 11:06 < paveljanik> rc1 for the weekend is fine! 11:06 < sipa> or at least branch off today 11:06 < luke-jr> I don't think we have any critical problems blocking a rc1 11:07 < jtimon> sipa: why branch of if we can't rc1 ? 11:07 < wumpus> I don't think so either 11:07 < cfields> no more blockers from me either 11:07 < luke-jr> jtimon: to begin merging for 0.15? 11:07 < wumpus> right, because more and more pulls for 0.15 are waiting 11:07 * jtimon nods 11:07 < jonasschnelli> IMO the two import multi fixes are not critical and can go in after rc1 (or even in 0.15 in the worst case). 11:08 < gmaxwell> all you naughty people not banging away at getting 0.14 ready to go. 11:08 < morcos> jonasschnelli: well lets decide that 11:08 < gmaxwell> jonasschnelli: I think 0.15 would be really unfortunate since they're interface changes that users may have to accomidate in their software. (and also are covering corner cases that could result in funds losses) 11:08 < wumpus> I think the fixes are all important, and should get either into 0.14.0 or backported to the 0.14 branch if they don't, but not everything should be regarded as yet another thing to hold up rc1 11:08 < morcos> yesterday people were saying it was bad to release with something that coudl silently not find funds 11:09 < gmaxwell> but no reason to hold rc1 for them. They're well understood. 11:09 < jonasschnelli> Yes. I think the should be in 0.14. Just worst case if we spun of rc1 and chaincode-labs colabses. :) 11:09 < wumpus> anyhow tomorrow sounds good to me, let's try to get in what we can get in 11:09 < gmaxwell> it's not like someone is going to encounter one of them running rc1 and leave us going "shit was that the know issue or something else?" 11:09 < luke-jr> #9619 is a fix, but not really critical since anyone affected needs a workaround in 0.13 anyway (just pushed an amend-with-no-changes because the Travis error seems impossible) 11:09 < gribble> https://github.com/bitcoin/bitcoin/issues/9619 | Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates by luke-jr · Pull Request #9619 · bitcoin/bitcoin · GitHub 11:09 < achow101> what's the point of making an rc1 if we're going to need rc2 anyways? 11:09 < sipa> achow101: exposure 11:09 < gmaxwell> achow101: to start getting people using it. 11:09 < wumpus> achow101: get the code actually tested? 11:09 < gmaxwell> more* 11:09 < wumpus> what is the point of doing rc1 at all if not? 11:09 < kanzure> and seeking bug reports 11:09 < jonasschnelli> I think we should plan enough time to fix stuff that gets report after rc1... 11:10 < sipa> jonasschnelli: the release schedule already has 2 weeks left 11:10 < wumpus> achow101: I don't think it ever happened that a major release didn'tneed a rc2 11:10 < luke-jr> 2 weeks can go fast 11:10 < jonasschnelli> Other can work on fixes reported in rc1. 11:10 < gmaxwell> achow101: what we generally don't want to do is to ship an RC1 with issues bad enough that it will harm the testers seriously, or which will fail in mysterious ways that we can't learn from. E.g. if we had a known crash fix, we would hold rc1, so that we wouldn't worry that every user crash report might have been an unknown issue. 11:10 < jonasschnelli> *Others 11:11 < morcos> my only concern is that if we do rc1 everyone will be distracted with that and not this last few remaining PR's.. but i guess i don't really care either way 11:11 < cfields> wumpus: just forget the bump to v0.14 again and thereby guarantee an rc2 :p 11:11 < wumpus> cfields: lol exactly 11:11 < morcos> seems like if someone would just review those PR's we might be able to get them merged today 11:11 < gmaxwell> well I think an RC2 is already guarenteed if we do an rc1 ASAP. But thats fine. Much better than not doing the rc1. 11:11 < achow101> ok 11:12 < wumpus> a RC2 is guaranteed in any case, not just if we do rc1 asap 11:12 < wumpus> that's my point, we don't know of all the issues yet 11:12 < morcos> almost all the complication is in new tests.. reviewing the code changes is pretty simple 11:13 < wumpus> the only one I doubt about is #9773, at it is still WIP 11:13 < gribble> https://github.com/bitcoin/bitcoin/issues/9773 | WIP: Return errors from importmulti if complete rescans are not successful (on top of #9761) by ryanofsky · Pull Request #9773 · bitcoin/bitcoin · GitHub 11:13 < luke-jr> it's a new feature, so we could just say "don't use this without being aware of the risks" 11:13 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 11:14 < paveljanik> mark it as experimental then? 11:14 < sipa> paveljanik: meh, i think we're close enough to not do that 11:15 < luke-jr> I mean in rc1 only 11:15 < wumpus> well even with that change it can be marked as experimental 11:15 < wumpus> it is new code afterall 11:15 < gmaxwell> I'm not too worried about it in rc1. 11:16 < wumpus> there are probably still problems with it that we haven't found, which will be found by people testing it 11:16 < paveljanik> we can mark it as experimental in the release notes only... 11:16 < wumpus> so yes, experimental makes sense. Though a new major release should be considered experimental entirely 11:16 < gmaxwell> people running rcs are the least likely to lose funds due to a rescan limitation, and there won't be many of them. 11:17 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 11:17 < morcos> i think it is a mistake to call it experimental 11:17 < morcos> we don't want to devalue the meaning of that word 11:18 < wumpus> ok... 11:18 < morcos> sometimes we may want to have things that are actually experimental and we don't want people to think we just always say that 11:18 < wumpus> "this feature is experimental level 4" 11:18 < sipa> haha 11:18 < kanzure> nasa technical readiness levels 11:18 < CodeShark> The whole thing is experimental :p 11:18 < morcos> this is known to the state of CA to be experimental 11:18 < petertodd> morcos: "dangerously experimental" 11:19 < petertodd> morcos: lol 11:19 < gmaxwell> Yea, thats why I was not supporting expiremental. 11:19 < instagibbs> morcos, accounts... deprecated! 11:20 < morcos> what.. is that an announcement? a question? 11:20 < morcos> i hate accounts 11:20 < gmaxwell> For rc1 we can simply say that there are in-flight improvements to that feature link to the PRs. if we really want to... in a reply to the announcement. 11:20 < sipa> let's just review the outstanding patches, they are tiny 11:20 < instagibbs> morcos, we use "deprecated" in things that are lasting forever in practice, bad joke 11:20 < jtimon> mhm, why 9619 doesn't go in for 0.14? 11:20 < morcos> oh.. yeah 11:20 -!- reginaldo_ [~reginaldo@191.241.232.178] has quit [Quit: Leaving] 11:20 < sipa> with some luck we can get everything merged 11:21 < sipa> branch and rc1 tomorrow 11:21 < wumpus> gmaxwell: yes, that there is still work in progress, that's better and more clear than the word experimental 11:21 < sipa> with whatever is in 11:21 < morcos> ok, so can we just pick a time. wumpus is going to call rc1 tomorrow morning.. it tonight we can convince people to merge a few of these other things... that'll leave less for rc2 11:22 < morcos> that was "if tonight" , if not , then ok 11:22 < sipa> wumpus: is that fine by you? 11:22 < wumpus> yes, that's fine with me 11:22 < wumpus> I'm okay with another day, let's just not let it slip another week, that next thursday we're again wondering when to do the rc1 :) 11:23 < sipa> next thursday we should be talking about doing rc2 11:23 < wumpus> yes, ideally 11:23 < gmaxwell> We're at a point where beyond the couple in flight PRs little to no more improvement is happening, which is when we need more input. 11:23 < achow101> so rc1 tomorrow regardless of whether those three prs get merged? 11:24 < sipa> achow101: that's what i suggest, yes 11:24 < paveljanik> +1 11:24 < achow101> ^ 11:26 < sipa> are we ok with talking about things beyond 0.14? 11:26 < wumpus> sure! 11:26 < luke-jr> new #topic? 11:26 < sipa> i'd briefly like to talk about randomness 11:26 < wumpus> #topic randomness 11:26 < luke-jr> that's random. 11:27 < sipa> we currently have 3 "levels" of randomnesz 11:27 < sipa> fastrandomcontext, getrandbytes, getsecurerandbytes 11:27 < sipa> i'd like to have only 2 11:27 < wumpus> we need a random number of levels of randomness 11:27 < wumpus> yes. 11:27 < wumpus> why are there three? 11:27 < instagibbs> can you explain "getsecurerandbytes" 11:27 < instagibbs> im going through code now but.. 11:27 < wumpus> I mean we need one for wallet keys, I understand that 11:28 < sipa> the last one is used for privaye keys 11:28 < jtimon> why 9619 doesn't go in for 0.14? 11:28 < jonasschnelli> jtimon: wrong topic 11:28 < sipa> it's as secure as getrandbytes if all goes well, but it's more paranoid 11:28 < sipa> so, i've been playing with a chacha2p based rng instead of fastrandomcontext 11:28 < jtimon> jonasschnelli: suggested topic then 11:28 < wumpus> I think I'm fine with an extra paranoid level for wallet keys 11:28 < sipa> *chacha20 11:29 < sipa> which takes around 10ns for a 32-bit rand 11:29 < wumpus> it's much more important to have good randomness there then in almost any other place in computing currently 11:29 < instagibbs> "GetStrongRandBytes" <--- this it? 11:29 < rabidus> return 4 11:29 < sipa> the current fastrandomcontext takes 1.5ns, but with extra optimizations it can be made comparablr 11:30 < sipa> and if we have that, i think we can use strong randomnes for everything 11:30 < wumpus> for non wallet keys we can probably do with one level 11:30 < wumpus> is that your plan sipa? 11:30 < sipa> basically i suggest making all RNGs cryptographic 11:30 < sipa> but the fast one is not thread-safe, doesn't reseed, doesn't protect against VM reloads 11:30 < wumpus> so merge the fastrandomcontext and somewhatmoresecure level, and keeping that and the ultra-paranoid one for wallet keys 11:31 < sipa> i realize the "only two randomness levels" is a bit of an abstract goal 11:31 < wumpus> yes the fastrandomcontext is supposed to only eb used from one thread at a time 11:31 < morcos> are there any inner loops that use random numbers? 11:31 < petertodd> wumpus: the ultra paranoid one can also use the chacha code 11:31 < wumpus> because it's for inner loops 11:32 < sipa> yes, the wallet coin selection 11:32 < sipa> i benchmarked it, making it chacha20 doesn't affect its performance 11:32 < wumpus> any locking for synchronization there would be pretty bad 11:32 < wumpus> there's also an inner random loop in the address selection code IIRC 11:32 < jonasschnelli> Do we need cPRNG for coin selection? 11:32 < sipa> yup 11:33 < wumpus> sipa: yes chacha20 is fast, but the problem is the thread safety 11:33 < sipa> jonasschnelli: no, we don't 11:33 < gmaxwell> sipa wants to reduce the codebase complexity. 11:33 < sipa> but chacha20 is so fast i don't care 11:33 < wumpus> if you want to be able to share a random context between threads, you end up with lots of synchronization overhead 11:33 < jonasschnelli> Yes. This would be good. 11:33 < wumpus> that's why the inner loops use a non-threadsafe random context, =which doesn't matter as it's only used by one thread 11:34 < bitcoin-git> [bitcoin] gmaxwell opened pull request #9779: Update nMinimumChainWork and defaultAssumeValid. (master...update_chainparams) https://github.com/bitcoin/bitcoin/pull/9779 11:34 < sipa> having clearer expectations about the rngs may simplify getting rid of openssl later 11:34 < wumpus> the thread sync overhead is where the overhead would be 11:34 < sipa> though that's not something to discuss now, i think 11:34 < wumpus> so how would you cope with that sipa? or would it all be non-shared context? 11:34 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] 11:35 < sipa> so 1) replace fastrandomcontext with a bit more featureful chacha20 based one 11:35 < wumpus> yes, depending on openssl for just randomness is fine, there's no urgent reason to get rid of that, and it seems controversial for some people 11:35 < sipa> 2) see where the current non-strong-getrandbytes can be replaced with fastrandcontexts, and replace everything with getstrongranbytes 11:35 < wumpus> that makes sense 11:36 < gmaxwell> one of the harder points (beyond threading) is that we need to manage which RNGs are robust against a VM image being snapshotted and restored. Coinselection using the same randomness again after a VM restore would be harmless. Choosing a crypto nonce would be much less harmless. If a RNG needs to be outputing data intially after restore there is unfortunately a runtime cost (esp on ARM). 11:36 < wumpus> also I think we need an abstraction for 'kernel randomness', this came up recently in context of OpenBSD, which doesn't have /dev/random/urandom available in all contexts 11:37 < gmaxwell> Pieter and I have been debating this a little bit the past could days. 11:37 < wumpus> the modern way,sandbox-proof way seems to be to use a specific system call fo that, but it differs per OS unfortunately 11:37 < sipa> wumpus: yup, that would go into the (singular) getstrongrandbytes implementation 11:37 < cfields> isn't there an old PR for exactly that abstraction? 11:37 < gmaxwell> wumpus: we do have a function for OS randomness, it should be smarter of course... but it was only fairly recently introduced. 11:37 < Victorsueca> maybe you could get rid of getrandbytes? so we keep the fast one for simple operations and the secure and paranoid one for important stuff and you can focus on implementing more features on those two 11:37 < gmaxwell> GetOSRand() 11:38 < wumpus> (linux also has a "getrandom" system call that can be used instead of /dev/urandom, in sandboxes) 11:38 < sipa> Victorsueca: read the above discussion, that is exactly what i am proposing 11:38 < wumpus> gmaxwell: ok 11:38 < gmaxwell> wumpus: yes, in newer systems. We do mention using that in the PR that implemented GetOSRand I think. (getentropy) 11:38 < wumpus> gmaxwell: in any case, that is the lowerst level, it shouldn't be regarded as 'a level of randomness' 11:38 < gmaxwell> so I think we know what we need to go there. 11:39 < wumpus> indeed, getentropy is bsd, getrandom is linux 11:39 < Victorsueca> sipa: ohh, I somehow misread that you where proposing to merge the fast and the middle one to make it simpler 11:39 < sipa> FWIW linux 4.8 also switched to chacha20 for /dev/urandom 11:39 < wumpus> yes 11:40 < gmaxwell> The framework I think about this is that we have several randomized algorithims where there are basically no cryptographic guarentees needed... coin selection, addr man buckets, and tests being some examples. These need to be fast but can all use just a local context, need no resistance against reversal (somsone steals your ram and recovers older randomness) or prediction (vm saves repeat rando 11:40 < petertodd> gmaxwell: re: VM image being snapshotted and restored, that's basically a case where reusing a secret is by itself harmful - is there an example in Bitcoin where that's the case, now that we do deterministic signing? 11:40 < gmaxwell> mness). 11:40 < gmaxwell> So thats one set of uses. 11:40 < sipa> Victorsueca: i'm proposing to make the fast one stronger (but not much slower), and then things using the middle one need to be judged on a case by case basis whether they can use the new fast one, or the strong one 11:40 < sipa> Victorsueca: after that, the middle one goes away 11:40 < gmaxwell> Then we have other uses where we have randomized behavior which does have stronger security requirements, like ping nonces which need to be strongly unforgable to prevent peers hiding their latency. 11:41 < Victorsueca> sipa: makes sense 11:41 < gmaxwell> But even if they're broken it just turns into DOS attacks. 11:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 11:41 < wumpus> it's strong, but far from as strong a requirement as wallet keys 11:41 < gmaxwell> Then we have things like long term keys which we do infrequently and basically no cost is too high. And they have to meet basically every security characteristic we can imagine. 11:41 < wumpus> indeed 11:42 < cfields> suggested similar next topic: clocks 11:42 < gmaxwell> the second class often has to be moderately fast too. 11:42 < gmaxwell> Pieter would like to collapse this class hierarchy some by making the first class use the second while making the second fast enough that it's fine to do so. 11:43 < Victorsueca> cfields: clocks as in CPU clock or as in timestamp? 11:43 < wumpus> Victorsueca: please wait until the topic is actaully started 11:43 < Victorsueca> ohh, sorry 11:43 < wumpus> though I think we've wrapped up randomness 11:43 < sipa> agree 11:43 < wumpus> #topic clocks 11:43 < gmaxwell> I have a little doubt that this is possible, because I think the second may need to deal with reversal resistace and prediction resistance, which cannot be done for free. (e.g. you must mix in TSC and/or RDRAND at every use.) 11:43 < instagibbs> he has to gavel before we can switch 11:44 < gmaxwell> okay! 11:44 < wumpus> gmaxwell: oh, didn't know you were still typing, sorry 11:44 < cfields> I have some local changes that implement the concept of different clocks/time_points/durations. The objective is for them to be incompatible with each-other. 11:44 < gmaxwell> thats fine! just some things to think about. 11:44 < wumpus> cfields: yes, that seems the way to go about it 11:44 < sipa> cfields: f i may interject... i was thinking about creating a generic int class wrapper that supports no implicit conversioms 11:44 < gmaxwell> cfields: pieter and I were talking about type safty recently, and pieter suggested a scheme for introducing more integer types which will never implicitly be converted. 11:45 < wumpus> most importantly we should start using monotonic timestamps in the network code where possible 11:45 < cfields> that sounds fine, but i'm not sure that they're entirely related here. The (my) objective is to stop storing time as an int, and instead as a time_value 11:46 < sipa> cfields: or are timestamps in a c++11 world not something that fit in integers? 11:46 < cfields> that way it can be represented in sec/msec/whatever whenever it's needed 11:46 < cfields> sipa: exactly 11:46 < cfields> it also enforces timestamps that can't be used on the wrong clock 11:46 < sipa> i'm confused 11:46 < gmaxwell> I have suggested in the past that we consider constructing a monotonic local clock, but wumpus seemed to not like the idea. which I think is orthorgonal to the type safty thing, but it would perhaps make time more sane in the codebase. 11:46 < wumpus> cfields: in general that sounds good, though in some structures such as the block index we want to use as compact types as possible 11:47 < gmaxwell> saftey* 11:47 < gmaxwell> doh 11:47 < cfields> wumpus: sure, you can always get an int out of it if you want 11:47 < wumpus> gmaxwell: huh I'm all for using monotonic clocks were possible, they're just not good for everything 11:47 < gmaxwell> safety** 11:47 < sipa> cfields: my point was to have a template class non_convertible_int 11:47 < cfields> also, i believe the class is actually not bigger than an int. It's just not convertable to int 11:48 < wumpus> cfields: well if it represents micro/nanosecond it needs to be at least uint64 :) 11:48 < sipa> and then have typedef non_comvertible_int systemtime_type 11:48 < sipa> and systemtype_type is what is used 11:48 < gmaxwell> you would get_int() on the object to get an int. You would just get a conversion by surprise. 11:48 < sipa> *systemtime_type 11:48 < gmaxwell> I would _hope_ we can construct something that at runtime is _exactly_ equal to using an integer. 11:49 < sipa> cfields: you're being inconsistent 11:49 < cfields> sipa: http://en.cppreference.com/w/cpp/chrono/time_point 11:49 < gmaxwell> I think we should do this far more broadly than just timestamps however. 11:49 < sipa> we can't use that in blocks, etc 11:50 < wumpus> indeed - block times /consensus are a special case 11:50 < cfields> sipa: we don't use timeval in blocks either though, we convert from the clock 11:50 < sipa> but perhaps we should use those types in network state, measuring speed, ... 11:50 < cfields> sipa: i'll demonstrate with code, probably easier that way 11:50 < wumpus> right 11:51 < sipa> cfields: what i want to address is the fact that an int or int64 can now mean microseconds, milliseconds, or seconds, and either system time, or monotonous time, or network-adjusted timr 11:51 < sipa> it's fine that those are int-like, but they shouldn't be convertible from one into another 11:51 < cfields> sipa: and that's exactly what i've addressed. Each of those gets its own type, and they're not convertable to eachother. But you can do a duration_cast(foo) and get an int64_t seconds value out 11:52 < sipa> anyway, for everything but consensus data structures, perhaps there are more c++ish ways 11:52 < sipa> cfields: let's discuss this outside of theeeting 11:52 < gmaxwell> This problem exists far beyond timestamps however. Use a node ID as a tx count? no problem. Use a vin index as a block number? no problem. Use a bytes sent as a relay bool? no problem. 11:53 < gmaxwell> We have multiple times had potentially serious bugs from the general issue of implicit conversions. 11:53 < cfields> gmaxwell: yes, agreed that the tag would be very useful 11:53 < gmaxwell> (or in the case of sighash single, an actual consensus behavior flaw) 11:53 < cfields> sipa: np 11:53 < sipa> jtimon had a topic as well 11:53 < wumpus> using enumerations instead of booleans would also go a long way 11:54 < jtimon> well, just a question really 11:54 < jonasschnelli> I also have a little proposal 11:54 < gmaxwell> all the data is there in the compile to prevent these mistakes, we're just not exposing it right. :) 11:54 < jtimon> I guess it can wait after the meeting 11:54 < wumpus> especially for functions that have tons of boolean arguments in succession, that's just crazy 11:54 < sipa> wumpus: yeah, generally useful 11:54 < gmaxwell> wumpus: yea, using bools, also using structs to get named parameters... lots of things we can do. 11:54 < cfields> wumpus: for sure 11:54 < jtimon> or answered fast enough that it doesn't need its own topic: "why 9619 doesn't go in for 0.14?" 11:54 < gmaxwell> true false true true false die die die. ... I hate counting aruments when changing things. 11:54 < morcos> jtimon: i think because there was an error reported and no explanation that it was fixed or wasn't really a problem. that's at least why i haven't looked at the PR. 11:54 < wumpus> (well with some IDEs you can see what gets assigned to what parameter because it parses the interface, but that's not something you can realy on that everyone has available) 11:55 < wumpus> gmaxwell: exactly 11:55 < wumpus> jtimon: what was your topic? 11:55 < instagibbs> gmaxwell, the fun really starts when you drop an arg with a default value at the end 11:55 < cfields> (or three) 11:55 < jtimon> morcos: that explains why is not merged, not why it's not labeled 0.14, but ok I guess 11:55 < wumpus> jtimon: let's reverse the question: why would it need to be added for 0.14? 11:55 < jtimon> wumpus: including 9619 in 0.14 11:56 < jtimon> it's a bugfix and is simple enough, why not? 11:56 < sipa> i think it can go in, it's trivial and very small in scope 11:56 < gmaxwell> basically without it a plausable downstream gbt user that changes the transaction set could construct an overlarge block, is that the concern there? 11:56 < wumpus> I'm fine with merging it before 0.14, if its sufficiently reviewed and teste 11:56 < wumpus> it will however not hold up rc1 11:57 < gmaxwell> it looks trivial and small in scope, and if my understanding is correct it should go in.. but sure, nothing should hold up rc1. 11:57 < gmaxwell> at least nothing that we know of now. 11:57 < sipa> fair 11:57 < jonasschnelli> Not sure if this makes sense, But I propose to rename the ./qa dir to ./test (or something that sorts after ./src). I think it would be better to have the RPC tests further down in the PRs diff. 11:57 < jtimon> sure, was simply surprised it didn't had the 0.14 label since it's not really that new 11:57 < Victorsueca> I see lots of utACKs but not any ACK, so trivial it doesn't need testing I assume? 11:57 < gmaxwell> short of some kind of crash eat money doom bug showing up before we manage to get it out (and even that shouldn't delay _constructing_ RC1; if doom shows up we can abort launch) 11:58 < wumpus> gmaxwell: sure, there are always serious enough problems possible that should postpone the release 11:58 < gmaxwell> jonasschnelli: On that I'd like to get into a state where make check is running those tests. They are most of our tests now, and the most valuable.. and really people building with compilers we've never seen before _REALLY_ ought to be running them. 11:59 < wumpus> jonasschnelli: don't really have an opinion on that, does it matter much how things are sorted? 11:59 < gmaxwell> Why would the sorting matter? 11:59 < jonasschnelli> As long as review is a bottleneck I think it matters 11:59 < jonasschnelli> But maybe I'm alone with that opinion. 12:00 < gmaxwell> OH so they show up lower on github. 12:00 < sipa> /zzztest 12:00 < wumpus> my biggest pet peeve is that they're called RPC tests, not 'functional tests' or such, they're testing much more than RPC these days :) 12:00 < jonasschnelli> ./test_functional 12:00 < gmaxwell> It is sometimes a bit confusing that the tests show up first... otoh it can be informative to read the test before the change in the cases where the test is especially good. :) 12:00 < wumpus> but not serious enough to actually go on renamind directories 12:00 < sipa> also, pull-tester should be merged in rpc-tests 12:00 < gmaxwell> wumpus: they are "system tests" rpc is incidental. 12:01 < sipa> we don't have pulltester anymore, and it's annoying to always change directory :) 12:01 < wumpus> gmaxwell: yes, it doesn't matter what interface they use, whether it's RPC or P2P or ZMQ or REST or command line arguments etc 12:01 < instagibbs> we're over time 12:01 < instagibbs> btw 12:01 < jonasschnelli> Okay. I'll do a cleanup PR once we branch off. 12:01 < wumpus> instagibbs: ah yes 12:01 < wumpus> #endmeeting 12:01 < lightningbot> Meeting ended Thu Feb 16 20:01:55 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:01 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-16-19.02.html 12:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-16-19.02.txt 12:01 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-16-19.02.log.html 12:02 < jnewbery> wumpus: Agree, and can we name it something other than pull-tester? 12:02 < Chris_Stewart_5> sipa: gmaxwell So if I understand you guys, you want to create custom types for all time related structures inside of core? 12:02 < gmaxwell> petertodd: nice ACK on 9779. 12:02 < Chris_Stewart_5> even further, integer related structures? 12:02 < sipa> Chris_Stewart_5: well it seems c++11 has things like that already, and they're more featureful than just integers 12:02 < cfields> Chris_Stewart_5: i'm suggesting that we switch to std::chrono::duration and std::chrono::time_point 12:02 < wumpus> jnewbery: yes, pulltester is a weird name now, it's simply a launch framework for the tests 12:03 < Victorsueca> midnightmagic: "and really people building with compilers we've never seen before _REALLY_ ought to be running them." <--- I tried it once on windows but it looks like they're broken and only work on linux 12:03 < sipa> Chris_Stewart_5: but yes, making ints not convertible into other int-like-types can fix bugs 12:03 < jnewbery> test-launcher.py or test-runner.py seem fine 12:03 < gmaxwell> wumpus: re 9779, assuming that gets ACKs feel free to merge that along with the version bump. (the assumevalid was 6119 blocks behind.) 12:03 < wumpus> Victorsueca: that's simply not true! they work on at least openbsd, freebsd, linux, and windows (in wine at least) 12:03 < Chris_Stewart_5> sipa: Sure, no arguments with that. Just wasn't sure if that was _exactly_ what you guys were saying in the meeting. 12:03 < wumpus> Victorsueca: oh and OSX 12:04 < Victorsueca> wumpus: hmmm should try it again 12:04 < Chris_Stewart_5> sipa: But conversions will still be able to be done right? Just with explicit function calls instead of casting correct? 12:04 < wumpus> Victorsueca: our tests are very well maintained on many platforms 12:04 < sipa> Chris_Stewart_5: of course 12:04 < sipa> otherwise it's useless 12:04 < cfields> Chris_Stewart_5: only to a degree. You shouldn't be able to compare a system_clock time_point to a steady_clock one. Because that makes no sense. 12:04 < gmaxwell> They tests have extra dependencies so its quite plausable that on some systems that compile the code the tests fail. 12:05 < wumpus> cfields: or a duration to a absolute time value! 12:05 < cfields> wumpus: right 12:05 < Victorsueca> wumpus: which one should I be running to run all tests? 12:05 < Victorsueca> ahh I think I found it 12:05 < wumpus> gmaxwell: it should disable the tests in question in that case, e.g. if there's no zmq if doesn't run that test 12:06 < jonasschnelli> Victorsueca: ./qa/pull-tester/rpc-tests.py 12:06 < jtimon> wumpus: right, functions with many bools could use thier own flags or something perhaps (sorry, was catching up on the previous discussion) 12:06 < jonasschnelli> Victorsueca: mind the -win parameter 12:06 < wumpus> jtimon: yes, either bitfield or individual enums, everything is better than bool,bool,bool,bool 12:06 < cfields> so instead, we get the concept of a clock, which gives you time_point's with some meaning. a time_point, which is an absolute time (but not necessarily wall-time) on some clock, and a duration, which is the difference between 2 time_points 12:07 < sipa> wumpus: for cases where it's excessive you can emulate named arguments using a struct 12:07 < jnewbery> jonasschnelli: My preference would be to also move the bitcoin-util-test.py and bctest.py (and data for those tests) from src/test to whatever you rename qa to. Those tests seem much more like the integration tests in qa than the unit tests in src/test 12:07 < jtimon> and I really hate we have so many bools with default values 12:07 < sipa> wumpus: for example a struct ATMPArgs that takes in its constructor all 'required' fields for ATMP, and has methods to change optionals 12:07 < Chris_Stewart_5> cfields: Wouldn't that comparison have to be enforced through code review and not a compile time failure? Sorry not super familar with the data structures.. 12:07 < jonasschnelli> jnewbery: Indeed. I'll try to move them. 12:07 < gmaxwell> I believe a struct for inputs can be nearly zero runtime overhead for functions with many arguments. 12:08 < sipa> Chris_Stewart_5: it will result in compile time failure; a timepoint for a steady clock would be a different data type 12:08 < wumpus> sipa: c99 designated struct initializers were always nice to use for emulating named arguments in C, too bad that never made it to C++ 12:08 < cfields> Chris_Stewart_5: no, it's enforced by the compiler. A time_point knows what clock it belongs to 12:08 < sipa> So you'd call AcceptToMemoryPool(ATMPArgs{std::move(tx)}.max_fee(fee)) 12:08 < gmaxwell> Chris_Stewart_5: enforcing things through code review that could be enforced by the machine is a losing strategy. Code review is essential but it should be focused on the bugs the machine cannot prevent. 12:08 < petertodd> gmaxwell: heh, yeah, I wanted to make a point of what the trust model was, particularly since -assumevalid was (partly) my idea! :) 12:09 < Victorsueca> jonasschnelli: wumpus: File "rpc-tests.py", line 283 print('.', end='', flush=True) SyntaxError: invalid syntax 12:09 < Victorsueca> uhmm shit hit the fan? 12:09 < wumpus> sipa: in any case, we also shouldn't go over the top with this, trying to emulate something in c++ that it is not :) 12:09 < jonasschnelli> Victorsueca: python3? 12:09 < Chris_Stewart_5> gmaxwell: No doubt. I'm all for type safety. Compilers are our friends :-) 12:09 < jonasschnelli> (requires p3) 12:09 < sipa> Victorsueca: looks like you're trying to run with python2 12:09 < Victorsueca> ahh forgot python stands for 2 and py stands for 3-2 hub 12:10 < sipa> Victorsueca: no, the first line of the file states the interpreter to use, but i guess that only works in unix-like systems 12:10 < wumpus> you should run all the bitcoin core scripts with python 3 12:10 < jtimon> gmaxwell: ack on adding the rpc tests on make check 12:11 < Victorsueca> here on windows if I run py it auto-detects whether 2 or 3 should be used 12:11 < Victorsueca> it's just i'm used to write python 12:11 < gmaxwell> wumpus: MISRA C (standard for safety critical C code targeting embedded systems) requires that no generic types be used, and certantly no sizeless generic types. And that is in C where you still get the implicit conversion and can't really avoid it, but the standard argues that static analysis tools can still catch your errors so long as you've exposed the type information. Libsecp256k1 is pre 12:11 < gmaxwell> tty close to this now. 12:12 < wumpus> well if the first line contains python3 it should be run with python 3, lacking that there is no general way to detect whether code is python2 or python3. But believe me, the bitcoin core python scripts need to be run with python 3. 12:13 < wumpus> gmaxwell: the most significant non-MISRA thing about secp256k1 is probably that it allocates a context on the heap? 12:15 < bitcoin-git> [bitcoin] jnewbery opened pull request #9780: Suppress noisy output from qa tests in Travis (master...travislogging) https://github.com/bitcoin/bitcoin/pull/9780 12:16 < gmaxwell> wumpus: Well MISRA doesn't actually forbid anything but requires that for every violation you write an exception document. So the context is one where the exception document is very easy to right: this allocation is pure initilization, not runtime. 12:17 < gmaxwell> What I've found harder to deal with is that it requires no function have multiple returns. As there are some cases where we do where fixing it feels like it would objectively worsen the code. But their argument is also pretty compelling 12:18 < wumpus> yes, there's something to be said for that, especially with regard to cleanup and such 12:18 < gmaxwell> It would also be very easy for us to make it possible to make libsecp256k1 mallocless with ifdefs, it's specifically structured to enable that. 12:18 < wumpus> though in some cases it can lead to terribly verbose code when combined with error handling 12:19 < wumpus> e.g. either deeply nested if() or some status flag that is checked every other statement 12:19 < cfields> wumpus: but those easily fixed with a goto ;) 12:19 < gmaxwell> (My goal though not a priority is to make libsecp256k1 MISRA conformant eventually) 12:19 < gmaxwell> cfields: forbidden by MISRA C. (though like anything else you can make exceptions) 12:19 < jtimon> jonasschnelli: regarding your rename, if rpc-tests/ and pull-tester/ in qa (as I think sipa suggests ), it may make sense to take the opportunity to rename qa as well 12:19 < wumpus> cfields: hah! I didn't expect those to be allowed if multiple returns are not 12:20 < cfields> gmaxwell: was just joking about trading one thing for another 12:20 < gmaxwell> Gotos that go backwards also forbidden by an extra rule, so at least error handling doesn't hit those. 12:20 < wumpus> cfields: I always tend to use goto's in C code for cleanups, kernel style 12:21 < gmaxwell> cfields: well I wasn't goto is actually an excellent way to handle error handling in C in some cases. It's very similar to multiple returns in its downsides, and yet few people care about peppering functions with 15 returns. 12:21 < cfields> wumpus: yes, they seem pretty necessary after using raii for long enough 12:22 < gmaxwell> The MISRA document is a really good read FWIW. It's pretty thoughtful in its recommendations. 12:22 < gmaxwell> though not so applicable to C++. :) 12:22 < cfields> gmaxwell: sure, agreed. I just used it as an example because it's often multiple-returns and gotos blindly spouted as "thou-shalt-not"s in c-code 12:24 < wumpus> I can't come up with a good reason to use backwards gotos though 12:24 < cfields> gmaxwell: well, no-multiple-returns carries some weight in c++ too as they inhibit rvo. Which can be very useful for structures that you assume move freely/cheaply 12:25 < Victorsueca> ok... now this is a mess.... I use WSL to cross-compile windows binaries, now all the tests have UNIX-like paths and can't run them on windows 12:27 < isle2983> gmaxwell: do you try any clang/LLVM plugins for checking MISRA? I am just wondering if it is worthwhile exploring 12:27 < wumpus> gcc computed goto is even more evil: arrays of labels, though it's used in e.g. the python bytecode dispatch loop for the last bits of speed optimization 12:27 < gmaxwell> isle2983: not clang/llvm ones, but I've used other static analysis tools that can check it, in particular pc-lint... They're of some value. 12:28 < wumpus> Victorsueca: strange - python code doesn't get compiled as such, it must be one of the generated py files that has a path in it. You could try explicitly setting the environment variable BITCOIND to the path of bitcoind, that will override the built-in guess 12:29 < gmaxwell> wumpus: some kinds of valid but complex flow control is just not expressable in C without a loss of efficiency. So you could imagine some kind of hyper optimized inner loop that uses backwards goto. I don't recall any case where I've been forced into that, though I have run into cases where performance required do{}while() and non-trivial code inside for expressions, and forwards goto out of a 12:29 < gmaxwell> loop that also had breaks and continues. 12:30 < wumpus> gmaxwell: yes, forwards goto out of a loop makes a lot of sense, if you want to break out of multiple levels 12:30 < gmaxwell> I wish C(++) had named continue/break. 12:31 < wumpus> gmaxwell: and these things matter, I mean if efficiency is not important you wouldn't be using c in the first place 12:31 < gmaxwell> (Rust has named breaks) 12:31 < gmaxwell> (also more important because it lacks the other options C has for that) 12:31 < wumpus> yes I remember quite some languages had them ,though I can't think of any right now 12:32 < wumpus> didn't know that rust did 12:33 < sipa> in c++ it's more complicated because you can't jump over variable initializations 12:34 < cfields> gmaxwell: i suspect that architects assumed throw/catch would be used for breaking out of multiple loops. But that's seen as poisonous to most, i think 12:34 < wumpus> ah, java has them apparently 12:34 < gmaxwell> cfields: youch. :P 12:34 < cfields> gmaxwell: my thought exactly :) 12:34 < wumpus> cfields: exceptions as a control flow statement? speak about shooting a fly with a thermonuclear missile :p 12:35 < gmaxwell> beyond the other issues with exception, they're slow... sooo. 12:35 < wumpus> right, they're slow exactly because they don't know where they're going to be catched, so they're a bad fit if you know exactly where you wantcontrol flow to go 12:36 < wumpus> the code for exceptions and stack unrolling is extremely complex, I looked at it some time there's even some cute VM involved that interprets DWARF debug info 12:37 < cfields> wumpus: heh, i once worked on some code that used it to parse some data, construct the right handler, and throw it. Then the catch was an abstract parent, and it would continue on with the newly-constructed handler 12:37 < wumpus> cfields: hahaha 12:37 < cfields> it was ugly, but surprisingly effective :) 12:37 < wumpus> cfields: anti-reverse-engineering? 12:38 < cfields> wumpus: heh, it would seem. no idea what the historical reasoning was 12:38 < gmaxwell> later you find out the guy that wrote it didn't know that function pointers or virtual methods were possible. :P 12:39 < wumpus> like anytiing so evil it sounds like a hell to debug 12:39 < cfields> gmaxwell: entirely possible :) 12:40 < wumpus> it reminds me of that saying that you should always expect that the person maintaining the code after you is a crazy axe murderer that knows where you live, this certainly classifies as inhuman cruelty to your successors 12:41 < jeremyrubin> sorry for misisng meeting! I was off by an hour :p 12:41 < jeremyrubin> I think w.r.t. entropy levels we should keep 3 12:41 < jeremyrubin> Deterministic, non-deterministic, secure 12:41 < cfields> std::chrono::off_by_one_clock 12:42 < jeremyrubin> deterministic is really useful for writing tests/benchmarks IMO 12:42 < wumpus> it's only useful for the tests and benchmarks, and could be in test_util.cpp 12:42 < jeremyrubin> That's fine to me! 12:42 < cfields> jeremyrubin: we have siphasher, which we use for deterministic randomness, and i don't think it really needs to care about the source of its seed? 12:43 < wumpus> but I agree it's useful to have fast deterministic random for some things, I manually rolled a LFSR in one place in the tests to quickly generate deterministic "random" numbers 12:44 < jeremyrubin> cfields: fine too -- just having something convenient to use for this purpose is all I care for! 12:45 < jeremyrubin> The cuckoocache tests test hit rate against deterministic data, so if the entropy changes then it *could* (unlikely) fail. 12:45 < jeremyrubin> but it depends on the variance of the hit rate... so it would be annoying if it fails say 1/100 times due to unlucky entropy 12:46 < wumpus> yes, that should ideally never happen 12:47 < wumpus> tests that randomly fail are extremely discouraging 12:48 < jeremyrubin> Indeed 12:48 < jeremyrubin> travis-gate was really a sad week for bitcoin ;) 12:52 < cfields> heh 12:59 < jeremyrubin> Speaking of tests -- any chance for putting #9495 (bugfix) and #9497 (tests) in 0.14? The CheckQueue is a pretty big piece of consensus code with almost no test coverage on it... Then again, there's no reason these tests can't wait for 0.15 either :) 12:59 < gribble> https://github.com/bitcoin/bitcoin/issues/9495 | Fix CCheckQueue IsIdle (potential) race condition by JeremyRubin · Pull Request #9495 · bitcoin/bitcoin · GitHub 12:59 < gribble> https://github.com/bitcoin/bitcoin/issues/9497 | CCheckQueue Unit Tests by JeremyRubin · Pull Request #9497 · bitcoin/bitcoin · GitHub 13:15 < jnewbery> jonasschnelli: I've got several PRs that are very disruptive to the qa directory: #9577 #9657 #9768 and the completion of #9707 (which I haven't yet PR'ed). Can you hold off your reorganzation of the qa directory until those are merged? Perhaps open an issue now for discussion but hold off on PR'ing. 13:15 < gribble> https://github.com/bitcoin/bitcoin/issues/9577 | Fix docstrings in qa tests by jnewbery · Pull Request #9577 · bitcoin/bitcoin · GitHub 13:15 < gribble> https://github.com/bitcoin/bitcoin/issues/9657 | Improve rpc-tests.py by jnewbery · Pull Request #9657 · bitcoin/bitcoin · GitHub 13:16 < gribble> https://github.com/bitcoin/bitcoin/issues/9768 | [qa] [WIP] Add logging to test_framework.py by jnewbery · Pull Request #9768 · bitcoin/bitcoin · GitHub 13:16 < gribble> https://github.com/bitcoin/bitcoin/issues/9707 | Fix RPC failure testing by jnewbery · Pull Request #9707 · bitcoin/bitcoin · GitHub 13:31 < jeremyrubin> jnewbery: git can handle renames fine iirc? 13:32 < jnewbery> jeremyrubin: I think you're right. If jonas is only going to rename files then there shouldn't be any conflicts. 13:33 < jeremyrubin> jonasschnelli: ^^^ 13:33 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 13:50 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 13:59 -!- aj_ is now known as aj 14:10 -!- wvr [~wvr@35.red-79-152-21.dynamicip.rima-tde.net] has quit [Ping timeout: 245 seconds] 14:11 -!- wvr [~wvr@35.red-79-152-21.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 14:13 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 14:22 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 15:09 -!- face [~face@mail.hmel.org] has quit [Ping timeout: 258 seconds] 15:12 -!- face [~face@mail.hmel.org] has joined #bitcoin-core-dev 15:15 -!- paracyst_ is now known as paracyst 15:18 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Excess Flood] 15:18 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 15:24 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 15:26 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 15:36 -!- chjj [~chjj@unaffiliated/chjj] has quit [Remote host closed the connection] 15:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 15:50 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 240 seconds] 15:56 -!- Giszmo [~leo@ip-31-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 16:07 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 240 seconds] 16:24 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 16:32 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 16:33 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 16:33 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 16:37 -!- molz_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 16:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 16:38 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] 16:42 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 16:49 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 255 seconds] 16:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 16:56 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 16:57 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:09 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 17:10 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 17:10 -!- chjj [~chjj@unaffiliated/chjj] has quit [Client Quit] 17:16 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 17:17 -!- fanquake [~fanquake@unaffiliated/fanquake] has left #bitcoin-core-dev [] 17:21 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 17:22 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds] 17:40 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vpkuyqoquabnzqlw] has quit [Quit: Connection closed for inactivity] 17:59 -!- Kexkey [~kexkey@23.227.207.22] has quit [Ping timeout: 240 seconds] 18:21 -!- Giszmo1 [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 18:24 -!- Giszmo [~leo@ip-31-233.219.201.nextelmovil.cl] has quit [Ping timeout: 240 seconds] 18:25 < achow101> is the zmq_test failing for anyone else? 18:25 < achow101> (in rpc tests) 18:29 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 18:33 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds] 18:36 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 18:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 18:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:00 -!- dermoth [~thomas@dsl-216-221-51-3.mtl.aei.ca] has quit [Read error: Connection reset by peer] 19:00 -!- dermoth [~thomas@dsl-216-221-51-3.mtl.aei.ca] has joined #bitcoin-core-dev 19:06 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds] 19:24 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 19:33 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev 19:33 -!- Giszmo1 [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 19:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 19:36 -!- deepbook5broo [~gk.1wm.su@2a03:4a80:2:2d4:2d4:e830:6db2:a7d4] has joined #bitcoin-core-dev 19:36 -!- deepbook5broo [~gk.1wm.su@2a03:4a80:2:2d4:2d4:e830:6db2:a7d4] has left #bitcoin-core-dev [] 19:40 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 19:44 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 20:12 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 20:16 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 20:33 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 20:34 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 20:37 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 21:05 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 21:09 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 21:12 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 21:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:37 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 21:41 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 22:04 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] 22:07 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 22:08 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 22:12 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 22:20 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Remote host closed the connection] 22:20 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 22:21 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Remote host closed the connection] 22:21 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 22:21 -!- city22 [~textual@210.13.244.130] has joined #bitcoin-core-dev 22:28 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 22:30 -!- mrkent [~textual@unaffiliated/mrkent] has quit [] 22:31 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 22:32 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Client Quit] 22:32 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 22:32 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Max SendQ exceeded] 22:33 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 22:34 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Client Quit] 22:34 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 22:34 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Client Quit] 22:35 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 22:35 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Client Quit] 22:38 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 22:40 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 22:43 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds] 22:44 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 23:11 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 23:15 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 23:16 < jonasschnelli> jnewbery: jeremyrubin: I can hold back the PR. There is no hurry. Lets firs aim on the one you have listed above 23:20 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 23:21 < gmaxwell> jonasschnelli: I happened to see the list recently, and I think you shouldn't waste your time arguing with people who are philosophically opposed to supporting encryption. These people are acting in a way which is harmful to human rights and wellfare. I do not know if they are confused or if they are working for state actors which are opposed to personal freedom, or what. But it's a waste of ti 23:21 < gmaxwell> me. Support for encryption and authication is completely optional and if other people want to use it it simply isn't any of their busienss. 23:22 < jonasschnelli> gmaxwell: Yes. That had cost me a lot of time and nerves... :) 23:23 < jonasschnelli> Thanks! 23:24 < jonasschnelli> gmaxwell: What I really dislikes is that those guys tried to enflame others and it partially worked... that's why I was commenting on some of the concerns 23:28 < luke-jr> gmaxwell: or possibly scared of what State actors opposing encryption might do to them/Bitcoin 23:29 < gmaxwell> luke-jr: if so, then they're arguing dishonestly... and I can't see a reason to do that. 23:30 < luke-jr> hm 23:32 < gmaxwell> If someone argued that adding encryption to Bitcoin would make some state actors hate bitcoin, I think that could be pretty easily refuted. 23:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-khwwrgxnmwawglkj] has joined #bitcoin-core-dev 23:38 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:42 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 23:46 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 23:59 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev