--- Day changed Thu Oct 20 2016
00:00 < wumpus> I hope that will be separated in the future
00:02 < wumpus> and maybe add a libbitcoin_policy for the other things :-)
00:04 < GitHub91> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c5875773561c...f2d705629b51
00:04 < GitHub91> bitcoin/master cb08fdb Pedro Branco: Add importmulti rpc call
00:04 < GitHub91> bitcoin/master 215caba Pedro Branco: Add consistency check to RPC call importmulti
00:05 < GitHub91> bitcoin/master f2d7056 Wladimir J. van der Laan: Merge #7551: Add importmulti RPC call...
00:05 < GitHub161> [bitcoin] laanwj closed pull request #7551: Add importmulti RPC call (master...feature/rpc-import-multi) https://github.com/bitcoin/bitcoin/pull/7551
00:07 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
00:20 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:27 < GitHub117> [bitcoin] jonasschnelli opened pull request #8977: [Wallet] Refactor wallet/init interaction (Reaccept wtx, flush thread) (master...2016/10/fix_wallet_init) https://github.com/bitcoin/bitcoin/pull/8977
00:36 -!- laurentmt [~Thunderbi@80.215.178.194] has joined #bitcoin-core-dev     
00:36 -!- laurentmt [~Thunderbi@80.215.178.194] has quit [Client Quit]     
00:36 -!- laurentmt [~Thunderbi@80.215.178.194] has joined #bitcoin-core-dev     
00:38 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
00:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
00:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
00:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
00:52 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
00:52 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
00:57 -!- Eliel [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has quit [Quit: leaving]     
00:58 -!- laurentmt [~Thunderbi@80.215.178.194] has quit [Quit: laurentmt]     
00:59 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
01:02 < GitHub145> [bitcoin] jonasschnelli closed pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723
01:03 < GitHub86> [bitcoin] jonasschnelli reopened pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723
01:03 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
01:06 -!- Eliel [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has joined #bitcoin-core-dev     
01:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 265 seconds]     
01:17 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
01:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
01:18 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
01:21 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
01:31 < jonasschnelli> Anyone interested to test the mempool statistics collector? This would be a basic step for GUI mempool stats: https://github.com/bitcoin/bitcoin/pull/8501
01:32 < wumpus> jonasschnelli: maybe release binaries
01:32 -!- rebroad [~rebroad@node-17ka.pool-118-173.dynamic.totbb.net] has quit [Ping timeout: 260 seconds]     
01:32 < wumpus> usually that's more effective to get GUI stuff tested
01:33 < jonasschnelli> wumpus: 8501 is non GUI RPC only... the GUI diff is large because of the flexible core stats collector.
01:33 < wumpus> ohh     
01:33 < jonasschnelli> I don't want to scarify the flexible design to keep the GUI diff low. :)
01:33 < wumpus> bah I'll retest #8959
01:33 < jonasschnelli> Parts of the statics collector could probably be reused for sipas idea of evicting misbehave score
01:34 < jonasschnelli> 8959 is strange...
01:34 < jonasschnelli> Maybe a Qt bug
01:34 < wumpus> seems to work for me
01:34 < jonasschnelli> Could be a QT-OSX bug
01:39 < jonasschnelli> i'll test again
01:39 -!- laurentmt [~Thunderbi@80.215.178.194] has joined #bitcoin-core-dev     
01:40 < wumpus> either that or macosx's triangles are y-axis-reversed :-)
01:41 -!- laurentmt [~Thunderbi@80.215.178.194] has quit [Client Quit]     
01:42 < jonasschnelli> wumpus: looks like. :) I guess is a Qt bug
01:42 < jonasschnelli> *it's
01:43 < wumpus> turning the pyramid upside down
01:43 < jonasschnelli> we could add something in platformstyles... *duck*
01:43 < wumpus> do we have sorting triangles anywhere else?
01:43 < jonasschnelli> yes. TX table
01:43 < wumpus> are they reversed too?
01:43 < jonasschnelli> let me check
01:43 < jonasschnelli> Correct there for me
01:44 < jonasschnelli> wumpus: can you check on Ubuntu?
01:44 < wumpus> yes     
01:44 < jonasschnelli> Hmm... so its a bug in our codebase
01:45 < wumpus> huh. The tx one on ubuntu is: up-pointing pyramid is descending, down-pointing pyramid is ascending
01:45  * wumpus confused
01:46  * paveljanik was always confused...
01:46 < jonasschnelli> So at least the "bug" behavior is identical. 
01:46 < wumpus> tried with balance. same for date. up=most recent date first, down=oldest date first
01:47 < jonasschnelli> IMO its an upstream Qt bug
01:47 < wumpus> I don't know anymore, I've lost perspective how it is supposed to be. Should try some other qt app maybe
01:48 < wumpus> reverted my ACK
01:48 < jonasschnelli> If its the opposite direction on OSX its certainly an upstream issue. I don't think platforms have a different sort-pyramid-direction... :)
01:48 < wumpus> in principle the validity of #8959 is based on one thing: does order == Qt::DescendingOrder really sort descending?
01:49 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has joined #bitcoin-core-dev     
01:49 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Changing host]     
01:49 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:49 < wumpus> we should inspect the sorted list insome other way
01:49 < wumpus> along with the input to the operator
01:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mpgnomwudklnmxtk] has joined #bitcoin-core-dev     
02:06 < wumpus> jonasschnelli: ok, so the original code was correct
02:07 < wumpus> the arrow behavior is strange, but should not be corrected by changing the sorting code
02:07 < jonasschnelli> wumpus: look like, but with the original code, i get a strange initial state
02:07 < jonasschnelli> First click results in only changing the arrow. :)
02:08 < wumpus> it looks like initially the thing is not sorted at all
02:08 < jonasschnelli> dam those little GUI glitches
02:08 < wumpus> it only ends up in that sorting function *after* clicking the column the first time
02:08 < jonasschnelli> Ah. That could be.. so it takes the default arrow direction which could be different
02:08 -!- laurentmt [~Thunderbi@80.215.178.194] has joined #bitcoin-core-dev     
02:11 < michagogo> I wonder if my attempt to make a gitian-building vbox appliance will work, or crash and burn.
02:14 -!- jujumax [~jujumax@host101.200-45-126.telecom.net.ar] has joined #bitcoin-core-dev     
02:14 -!- laurentmt [~Thunderbi@80.215.178.194] has quit [Quit: laurentmt]     
02:18 < jonasschnelli> michagogo: isn't the idea that everyone should setup it's own VM (security)? 
02:19 -!- DigiByteDev [~JT2@202.83.241.113] has joined #bitcoin-core-dev     
02:19 < wumpus> well if everyone would start using michagogo's image that would be a problem
02:21 < michagogo> jonasschnelli: yeah, but I had someone ask me for it... and that way I'd also find out if it's actually possible to set up
02:21 < jonasschnelli> michagogo: Yes. I think its generally a good idea and it might lead to better docs as well.. :)
02:21 < michagogo> Since so many people seem to have trouble with it, while I have a working setup...
02:22 < jonasschnelli> though, wumpus did create an awesome gitian doc
02:22 < michagogo> People say it doesn't work :-(
02:22 < michagogo> I've wondered a couple times if it's just hard to do/understand, or if something changed and it's actually impossible to set up from scratch these days
02:22 < jonasschnelli> Yes. Maybe we should provide a non LXC version
02:23 < michagogo> i.e. if the only reason it works for me is that I already have the environment set up
02:23 < michagogo> Maybe I'll turn on VBox's video recording feature
02:23 < jonasschnelli> heh... I guess same here. :)
02:24 < jonasschnelli> michagogo: you could turn your working system into an appliance (including your bitcoin private keys)
02:24 < michagogo> jonasschnelli: actually, someone asked for that first
02:24 < michagogo> But yeah, not gonna do that
02:25 < jonasschnelli> yes. better not
02:25 < michagogo> No Bitcoin private keys in there, but gpg, probably ssh, and also token for github, chrome, etc.
02:26 < michagogo> (I use the VM whenever I want to do/try something in Linux, not just for gitian)
02:27 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]     
02:27 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:27 -!- drizztbsd is now known as timothy     
02:33 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]     
02:33 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:33 -!- drizztbsd is now known as timothy     
02:35 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]     
02:35 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:35 -!- drizztbsd is now known as timothy     
02:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
02:41 -!- jujumax [~jujumax@host101.200-45-126.telecom.net.ar] has quit [Ping timeout: 248 seconds]     
02:41 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
02:48 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]     
02:48 < wumpus> < jonasschnelli> Yes. Maybe we should provide a non LXC version <- I think there should be only one guide, LXC or not, it's hard enough to keep one up to date
02:48 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:48 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Quit: Gone frying asparagus or my Windows had a BSOD (how not)]     
02:48 -!- drizztbsd is now known as timothy     
02:48 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
02:50 < Victorsueca> morning
02:50 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]     
02:50 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:51 -!- drizztbsd is now known as timothy     
02:52 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]     
02:52 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:52 -!- drizztbsd is now known as timothy     
02:54 -!- DigiByteDev [~JT2@202.83.241.113] has quit [Ping timeout: 260 seconds]     
02:58 < wumpus> morning
02:59 < btcdrak> wumpus: achow101 script work great with --kvm
02:59 < wumpus> the problem has always been that kvm doesn't work in some VMs, due to nesting, but I have no idea whether this is still the case
02:59 < wumpus> if not a relevant problem anymore we could just switch the guide to KVM
02:59 < Victorsueca> windows update force-restarted my computer last night while I was sleeping :/
03:01 < rabidus_> new spyware installed
03:01 < luke-jr> wee, master no longer builds
03:02 < luke-jr> guess importmulti wasn't ready :<
03:02 < luke-jr> wallet/rpcdump.cpp:811:54: error: no match for ‘operator!=’ (operand types are ‘CTxDestination {aka boost::variant<CNoDestination, CKeyID, CScriptID>}’ and ‘CTxDestination {aka boost::variant<CNoDestination, CKeyID, CScriptID>}’)
03:02 < michagogo> wumpus: I assume it's still an issue... nested virtualization is hard
03:03 < michagogo> But I do think anyone who's able should use KVM... AFAIK it tends to work much, much better
03:03 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
03:04 -!- cdecker [~quassel@2a02:aa16:1105:4a80:183c:ad5:f656:aa73] has joined #bitcoin-core-dev     
03:05 < michagogo> Hm, should I try making this with the Ubuntu Server ISO?
03:05 < luke-jr> does this actually compile for anyone? it looks like boost::variant *intentionally* omits operator!=
03:07 < wumpus> does what actually compile for anyone?
03:08 < luke-jr> wumpus: importmulti or master
03:09 < wumpus> yes - it passes travis and builds here locally
03:09 < luke-jr> :/     
03:09 < luke-jr> how is CTxDestination.Get() != CTxDestination.Get() working?
03:12 < Victorsueca> Will try compiling master here
03:13 < wumpus> the intention would be to compare whether the two destinations are the same
03:16 < wumpus> I think the importmulti code could be cleaned up quite a bit
03:17 < luke-jr> hm, looks like boost added it in some newer version
03:18 < wumpus> looks like the variant comparison is mostly used for "consistency checks"
03:19 < GitHub145> [bitcoin] luke-jr opened pull request #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (master...compat_importmulti_oldboost) https://github.com/bitcoin/bitcoin/pull/8980
03:19 < luke-jr> !(a==b) works
03:19 < gribble> Error: "(a==b)" is not a valid command.
03:19 < wumpus> that's crazy
03:20 < sipa> gribble disagrees
03:20 < luke-jr> heh     
03:20 < Victorsueca> lol     
03:20 < wumpus> hahahah
03:21 < luke-jr> why does C++ make it possible to have a==b && a!=b ? :p
03:22 < wumpus> I think most/all languages with overloaded operators allow that
03:23 < luke-jr> I knew Perl did, but I figured that was because it was Perl ;x
03:24 < wumpus> same with > versus <=  and < versus >=. I think there's even legitimate cases for that, e.g. NaNs
03:28 < GitHub49> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/5f6b312e51dadaf40ea68c0f85bbb4e51fa987f1
03:28 < GitHub49> bitcoin/0.13 5f6b312 Wladimir J. van der Laan: doc: Add missing credit to release notes...
03:31 < sipa> wumpus: from 0.13 release notes: "This is a new majir versiob release"
03:31 < sipa> *major
03:35 < luke-jr> there's a lot of stuff in there that could use work, but I assume we're merging from the blog post before it's final anyway?
03:35 < GitHub87> [bitcoin] paveljanik opened pull request #8981: Wshadow: Do not shadow argument with a local variable (master...20161020_Wshadow_rpcdump) https://github.com/bitcoin/bitcoin/pull/8981
03:35 < wumpus> yes, the 0.13 release notes definitely need some updating still
03:38 < wumpus> "This is a minor release, bringing various improvements and fixes, as well as activation parameters for the SegWit and NULLDUMMY soft-forks." <- I think michagogo wrote this, would be better I think?
03:39 < Victorsueca> NULLDUMMY?
03:39 < Victorsueca> wut     
03:40 < sipa> Victorsueca: bip147
03:40 < GitHub48> [bitcoin] s-matthew-english opened pull request #8982: Eliminating Inconsistencies in Textual Output (master...patch-6) https://github.com/bitcoin/bitcoin/pull/8982
03:40 < michagogo> Hm, actually
03:40 < sipa> i wonder if release notes shouldn't be written and tracked in a separate repository
03:40 < michagogo> Do we call it two soft-forks?
03:40 < michagogo> Maybe it's more accurate to drop the s
03:40 < wumpus> michagogo: no, it should be called one, I think mentioning only segwit would be fine
03:40 < michagogo> since it's one softfork, with two components
03:41 < Victorsueca> maybe it would be better if we named bip147 something other than nulldummy
03:41 < wumpus> sipa: could be, though the release notes are pretty much on the same release cycle as bitcoin core so it'd not make much of a difference
03:42 < wumpus> e.g. the release notes need to be final at the same time the release is final
03:42 < wumpus> otherwise they can't be included with the release, they can't be uploaded to bitcoin.org and other places, etc
03:42 < wumpus> posted to the mailing lists
03:43 < wumpus> could do the editing of the release notes in another repo then include it before final, sure...
03:43 < wumpus> or heck ,even google docs
03:44 < wumpus> that's easier for collaborative editing I guess
03:45 < sipa> well it could remove the issue of retroactive changes
03:45 < sipa> and the ambiguity of whether to edit doc/release-notes in 0.13 vs doc/release-notes-0.13 in master
03:45 < wumpus> retroacive changes are always a problem
03:46 < wumpus> that's not an ambiguity: before final, it can be edited in 0.13 branch, after the release it is copied to master and can only be edited there
03:46 < wumpus> and is cleaned out on the 0.13 branch for the next release from there
03:47 < wumpus> but I really think retroactive changes should be avoided if possible - at final release the notes will be copied to tons of different places, editing on master is not very effective
03:47 < sipa> fair enough, it is less ambiguous than i thought
03:47 < sipa> but it's still confusing
03:48 < wumpus> I'm not against moving the release notes to another repository, but it leaves the same problem if we want to include them with the release
03:49 < wumpus> at some point it needs to be checked in as doc/release-notes.md
03:49 < wumpus> in principle only the state at the final tag matters, the filecould be non-existent before and after that
03:49 < Victorsueca> what about this: do the docs on a separate repo, when it's release time then clone to bitcoin
03:49 < wumpus> I don't think that's any less confusing though
03:50 < wumpus> maybe the current way of working should just be documented better
03:50 < wumpus> sometimes the answer to something that is confusing is to describe/document it better, not always to immediately change it, may well make it more confusing to other people, esp those used to how things were done
03:51 < wumpus> and to be honest I've never found anyone confused by this. Current 0.13 release notes? are on the 0.13 branch
03:51 < wumpus> current 0.14 release notes are on the master branch
03:51 -!- laurentmt [~Thunderbi@80.215.178.194] has joined #bitcoin-core-dev     
03:51 < wumpus> those are for the next release on either branch
03:53 < wumpus> the advantage of doing it this way is that pulls can update the release notes atomically with the thing they introduce
03:53 < wumpus> not that anyone bothers
03:57 < wumpus> what we could do is rename the generic release-notes.md to release-notes-0.13.0.md on the 0.13 branch and release-notes-0.14.0.md on master, and update as appropriate. This will remove confusion for which version they are, at least...
03:58 < wumpus> should make sure that the file still gets included in the tarballs though
03:58 < wumpus> (and all the other distributions)
04:04 < GitHub133> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/c9a5baddeef3d8721a7c71acf070f92a3d8d43a3
04:04 < GitHub133> bitcoin/0.13 c9a5bad Wladimir J. van der Laan: doc: Update blurb in release notes...
04:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mpgnomwudklnmxtk] has quit [Quit: Connection closed for inactivity]     
04:07 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
04:24 < luke-jr> ☺ deterministic git assembly of Knots' branch in 30 seconds :P
04:26 < Victorsueca> i'm currently testing if master can be built successfully
04:26 < luke-jr> Victorsueca: it will likely depend on your boost version
04:32 < Victorsueca> lastest probably, I installed it 2 days ago
04:34 < sipa> installed how?
04:34 < Victorsueca> with apt-get
04:35 < sipa> that way you get the version from your distro's repository
04:35 < sipa> that's very very unlikely to be the latest
04:35 < Victorsueca> it's ubuntu
04:35 < sipa> likely not even the latest at the time the distribution was released
04:35 -!- laurentmt [~Thunderbi@80.215.178.194] has quit [Quit: laurentmt]     
04:35 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
04:37 < Victorsueca> do unit tests mess with the default data directory or they create some temp dir to do the tests?
04:38 < wumpus> they create temp directories
04:38 < wumpus> if they touch the data directory that would be a bug
04:39 < Victorsueca> so it's _safe_ to run the scripts in the qa folder
04:42 < wumpus> those are not the unit tests, but functional tests, but the same holds
04:43 < Victorsueca> wumpus: would be helpful if I run any of those and paste the outputs?
04:44 < wumpus> only if they fail, I guess
04:45 < wumpus> you can run all of them with qa/pull-tester/rpc-tests.py
04:47 < Victorsueca> wumpus: is it currently more needed to test master or 0.13.1rc2?
04:47 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 245 seconds]     
04:53 < sipa> unless you have an unusual setup, running rpc or unit tests won't teach us anything new
04:53 < sipa> using bitcoind/-qt in your own ways may, however (though always be cautious about things that could lose you money)
04:54 < Victorsueca> AFAIK there are few devs using windows
04:54 < sipa> ah, yes
04:54 < Victorsueca> I use Windows x64
04:54 < sipa> i thought you were on ubuntylu
04:54 < sipa> *ubuntu
04:54 < Victorsueca> I use ubuntu to cross-compile the builds
04:54 < sipa> do the rpc tests even work on windows?
04:55 < Victorsueca> not sure, worth trying I guess
04:57 -!- rebroad [~rebroad@node-11cu.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev     
04:58 < luke-jr> I kinda doubt they would
05:03 -!- jujumax [~jujumax@host101.200-45-126.telecom.net.ar] has joined #bitcoin-core-dev     
05:04 -!- fengling [~fengling@223.223.187.136] has quit [Quit: WeeChat 1.4]     
05:04 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
05:09 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
05:14 < Victorsueca> looks like my boost version was right, master built successfully
05:17 < Victorsueca> error at rpc-tests.py https://softnet.homenet.org/zerobin/?a149e1289bc5714f#2PzAq4zVrcQJl9WrUgIBfA7hpiVEIA44Ml8QRANe2HE=
05:19 < luke-jr> wrong Python version
05:20 < Victorsueca> need python 3?
05:20 < luke-jr> yes     
05:22 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:25 < michagogo> I might have successfully set up a machine for Gitian building
05:26 < michagogo> It was pretty much just as easy as I thought it might be
05:26 < michagogo> I even migrated over my apt-cacher-ng cache from my other machine
05:27 < achow101> michagogo: but does it actually build the binaries properly?
05:27 < michagogo> achow101: That's my next test
05:28 < michagogo> I made the base VM and that seems to work as far as sanity-checking
05:28 < michagogo> Snapshotting it now, and then I'll test an actual build
05:28 < michagogo> Gitian is actually broken atm (make-base-vm tries to copy a file that doesn't exist)
05:29 < michagogo> But there's already a PR that fixes it, so I just cherry-picked that in
05:29 < achow101> yeah, i noticed that.
05:30 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
05:30 < michagogo> And I turned on VBox's video capture option, so I have a video of everything I did
05:43 < Victorsueca> Error again https://softnet.homenet.org/zerobin/?586fe4c0934c7d9c#fMLN5XtScV/cdqkwjN6dTkLU17hjkL0iiNGW81x7aNw=
05:45 < michagogo> Hm. Depends was downloading clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz from llvm.org, and it failed
05:45 < michagogo> then it tried to fall back to bitcoincore.org and got a 4040
05:45 < michagogo> -0     
05:45 < michagogo> Oversight?
05:51 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit []     
05:53 < timothy> hi, can you please consider adding man pages to linux tar too?
05:53 < timothy> instead of git repository only
05:53 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
05:56 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
05:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:00 < Victorsueca> running it on a ubuntu enviroment brings a similar error https://softnet.homenet.org/zerobin/?e1589c342242901a#RUf6mKsZzrb+JBznhaaAraDxb57s0DayDGRm1JgU5Bo=
06:00 < Victorsueca> so it's not windows fault
06:05 < Victorsueca> any ideas?
06:05 < michagogo> achow101: Seems to be working so far
06:05 < michagogo> Running an actual gitian build, it's built linux depends up until native_protobuf
06:05 < michagogo> Working on boost atm
06:07 < michagogo> OpenSSL...
06:09 < michagogo> Okay, if anyone's interested in taking a look, it should go up soon at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
06:10 < michagogo> It's being compressed atm, once it's done it'll start uploading
06:23 < GitHub167> [bitcoin] rebroad opened pull request #8983: Show block height and size when received (master...ShowBlockHeightAndSizeWhenReceived) https://github.com/bitcoin/bitcoin/pull/8983
06:30 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
06:30 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Client Quit]     
06:32 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
06:33 < achow101_> michagogo: how did you get lxc to work? Did you have to change anything in gitian's scripts?
06:35 < BlueMatt> why do i see so many nodes failing version handshake?
06:35 < BlueMatt> on 13.1
06:41 < Lightsword> BlueMatt, only on 0.13.1 and not 0.13.0?
06:44 < BlueMatt> dunno, didnt try 13
06:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]     
06:44 < BlueMatt> still, ProcessMessage FAILED on version messages is new to me
06:44 < BlueMatt> did xt/classic/unlimited break something?
06:46 < Victorsueca> BlueMatt: not getting those errors here
06:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:47 < Lightsword> BlueMatt, got an example of one it fails against?
06:48 -!- harrymm [~wayne@104.222.140.113] has quit [Remote host closed the connection]     
06:48 < sipa> BlueMatt: nExpectedServices could cause this
06:48 < BlueMatt> no, because it otherwise prints the peer's ip messages after version processing works
06:48 < BlueMatt> :/     
06:49 < sipa> when a node does not have the services in its version message listed that we expected it to have, we disconnect
06:49 < BlueMatt> sipa: no, ProcessMessages(version, 102 bytes) FAILED peer=10
06:49 < BlueMatt> oh, yea, that might be it
06:49 < sipa> yes, ProcessMessages returns false in that case
06:49 < BlueMatt> since it returns false
06:49 < BlueMatt> huh, funny, I've seen a bunch of those on fresh nodes
06:50 < Victorsueca> BlueMatt: maybe it's gmaxwell's aggressive witness peer search disconnection non-witness nodes to free connection slots
06:50 < Victorsueca> disconnecting*
06:50 < BlueMatt> no, it is almost surely the nServicesExpected & ~nServices check
06:50 < sipa> Victorsueca: no, that's for chossing which peers to connect to
06:50 < sipa> BlueMatt: to be fair, we probably had no idea about what services were circulating
06:51 < sipa> maybe some reachable nodes became pruned
06:51 < sipa> but their ips kept circulati g
06:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
06:51 -!- harrymm [~wayne@104.222.140.70] has joined #bitcoin-core-dev     
06:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:54 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
06:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jnshpgiqmjkysqxz] has joined #bitcoin-core-dev     
06:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
07:01 < tulip> BlueMatt: I was seeing that a lot too.
07:03 < tulip> I didn't think to take a packet capture until after it calmed down sadly. 
07:04 < BlueMatt> tulip: naa, see comments above, its pretty clear what it is
07:04 -!- laurentmt [~Thunderbi@80.215.178.194] has joined #bitcoin-core-dev     
07:05 -!- laurentmt [~Thunderbi@80.215.178.194] has quit [Client Quit]     
07:05 < tulip> BlueMatt: ok, needs more sensible error messages. there's a couple of those hanging around with peer connection. 
07:06 < tulip> if you use a proxy the errors it prints are basically noise, but that's solvable by just switching to another tmux window :) 
07:07 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
07:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]     
07:10 < Victor_sueca> damn, power outage
07:10 -!- Victor_sueca is now known as Victorsueca     
07:13 < Victorsueca> and router has +30 second ping :D
07:16 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
07:20 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 250 seconds]     
07:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
07:22 -!- jujumax [~jujumax@host101.200-45-126.telecom.net.ar] has quit [Ping timeout: 248 seconds]     
07:22 < BlueMatt> tulip: -debug=net will show it
07:22 < BlueMatt> that error message should probably not need debug=net
07:24 -!- Expanse is now known as nOgAnOo     
07:24 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
07:24 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-owqiljyghzvqjcqm] has quit [Changing host]     
07:24 -!- nOgAnOo [sid146237@unaffiliated/noganoo] has joined #bitcoin-core-dev     
07:24 -!- nOgAnOo [sid146237@unaffiliated/noganoo] has quit [Changing host]     
07:24 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-owqiljyghzvqjcqm] has joined #bitcoin-core-dev     
07:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
07:28 -!- jujumax [~jujumax@host55.190-31-39.telecom.net.ar] has joined #bitcoin-core-dev     
07:35 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Remote host closed the connection]     
07:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:46 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds]     
07:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
07:52 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
07:53 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Client Quit]     
07:55 < achow101> michagogo: did you upload it yet? All I see is a .webm file which I can't play
07:57 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
07:57 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Excess Flood]     
07:58 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
07:58 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Excess Flood]     
07:58 -!- Guest12765 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
07:58 -!- Guest12765 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Excess Flood]     
07:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:59 -!- Guest12765 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
08:04 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
08:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
08:24 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
08:25 < NicolasDorier> wumpus: I think we can sort of having a compromise where allowing to validate policy rules with libconsensus without using undoc flag with the following way:
08:25 < NicolasDorier> void* libconsensus_createValidationContext();
08:25 < NicolasDorier> void libconsensus_setConsensusFlags(void* context, int flags);
08:25 < NicolasDorier> void libconsensus_setPolicyValidation(void* context, bool value);
08:25 < NicolasDorier> bool libconsensus_verify(void* context, har *scriptPubKey, unsigned int scriptPubKeyLen, CAmount amount, unsigned char *txTo, unsigned int txToLen, unsigned int nIn, bitcoinconsensus_error* err);
08:25 < NicolasDorier> It would make things easier to extend in the future and prevent to rely on undoc flags for script policy validation
08:26 < NicolasDorier> so the whole undoc flags would be wrapped into the "PolicyValidation" boolean
08:27 < sipa> NicolasDorier: but libconsensus' purpose is not to test policy
08:27 < sipa> the same risks don't apply, you can use any implementation for that
08:27 < sipa> and exposing that functionality means we need to maintain it, which makes it impossible in the future to split off policy validation elsewhere
08:29 < NicolasDorier> sipa: mmhh that's unfortunate, for the script evaluator as a user of libconsensus, I'd like to delegate those rules to the dll if possible :(
08:29 < NicolasDorier> but well, I understand the point that you don't want the burden of maintaining it
08:29 < sipa> well maybe you can create a libbitcoinscript
08:29 < sipa> that does everything scripting, but isn't consensus
08:30 < sipa> imho it's a mistake that in our own code the policy script evaluator is mixed with consensus logic
08:30 < sipa> but that's a controversial opinion, i'm aware
08:31 < NicolasDorier> yeah, well, not so controversial I think there are way to remove from the script evaluator all code belonging to policy evaluation. I think the main barrier would be to carefully review such solution :p
08:31 < sipa> it would imply we have two separate script interpreter implementations
08:32 < sipa> one just for consensus, one for everything
08:32 < sipa> the first one would only need to be touched for consensus changes
08:33 < NicolasDorier> sipa: It can be possible to inject into EvalScript an abstract class "PolicyEvaluator" whose implementation check every policy rule. And put the implementation outside of consensus
08:33 < wumpus> I agree with sipa, I'm not against a libbitcoin_policy or such, but mixiing it with consensus is a bad idea
08:33 < sipa> NicolasDorier: i don't want "abstract" anything in consensus code, to the extent possible
08:34 < sipa> NicolasDorier: that makes it much harder to reason about all code interactions
08:35 < NicolasDorier> I don't think it such case it would be hard to reason: If you want to execute only Consensus rule, you would inject a NullPolicyEvaluator implementation with empty method implementation. 
08:35 < NicolasDorier> I mean it would be the easiest way I see to separate consensus code from policy code
08:35 < NicolasDorier> in script evaluator
08:36 < wumpus> as long as the injection is only used to inject e.g. debugging or policy where the outcome is no longer important for consensus that'd be fairly true, it starts to be a nightmare once you inject consensus rules that way
08:37 < NicolasDorier> wumpus: yes, only for injecting things that are only part of policy
08:37 < sipa> NicolasDorier: but how complicated would such an injector need to be to implement something like lows, or nullfail, or csv?
08:37 < wumpus> (e.g. as long as injection points are a no-op when validating for consensus)
08:37 < sipa> NicolasDorier: if for every new policy you need to add new injection places, it's no better than what you started with
08:38 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 260 seconds]     
08:39 < wumpus> in any case I'm still not sure how to handle the tests in https://github.com/bitcoin/bitcoin/pull/8976 - should I skip tests that use flag combinations that are not in the API?
08:39 < NicolasDorier> mh good point. I would say at least for consensus it is easy to see that a broken policy rule can't break the execution of the script with consensus flags, as the implementation of such class in "consensus mode" would just be empty
08:39 < wumpus> (when testing libconsensus)
08:39 < sipa> wumpus: i'd say so
08:39 < wumpus> ok!     
08:39 < sipa> define a value that is the or of all flags that are in consensus
08:40 < sipa> if any others are set, skip the test
08:40 < wumpus> yes, I added a bitcoinconsensus_SCRIPT_FLAGS_VERIFY_ALL that is all the flags in libconsensus ORed
08:41 < wumpus> let's see if that leaves enough tests :)
08:41 < NicolasDorier> for info, the checks in https://github.com/bitcoin/bitcoin/pull/8976 are meant for 0.13.1 ? just to know if I update NBitcoin to deal with it now or later :D
08:41 < sipa> NicolasDorier: there are good uses for a very powerful script interoreter that does more than consensus too... for example a debugger or execution inspector, or something that supports signing some general class of signatures, maybe not specific to bitcoin transactions, ...
08:41 < wumpus> I don't think it's urgent enough for a last-minute change to 0.13.1
08:42 < sipa> NicolasDorier: there woukd be a burden to maintain changes in two places (when they affect consensus) but imho that is less than the work in review we save due to "this code does not ever need to be touched, unless consensus changes"
08:42 < wumpus> agree, there are good uses for an extended script interpreter, e.g. it's a common request to have something that visually shows script execution
08:43 < wumpus> and it's easier (esp. organization and review-wise) to do such things if they *don't* need to touch consensus code
08:44 < NicolasDorier> ah so what you would say  is making a new "EvalScript" which is copied from the current one. And remove from the current EvalScript everything policy related ?
08:44 < wumpus> yes, I'd like that
08:44 < NicolasDorier> indeed would be cool
08:45 < NicolasDorier> doing such a thing would be easy to review as well.
08:46 < wumpus> the only thing it makes slightly more difficult is assuring that a policy matches a consensus change, when putting something in policy that becomes a softfork later
08:46 < sipa> NicolasDorier: not just EvalScript. Everything in script/*
08:47 < sipa> (most of it would go away in the consensus version, of course)
08:48 < NicolasDorier> mh interesting indeed.
08:48 < sipa> I once tried to simplify CScript::operator<< because it is very inconvenient to use
08:48 < sipa> turns out, changing it would have been a hard fork
08:49 < sipa> which was so scary that i really didn't want to touch consensus' CScript anymore
08:50 < wumpus> yes dodged a bullet there
08:50 < NicolasDorier> in C++ is there a way to split the implementation of a class in several file ? 
08:50 < sipa> yes     
08:50 < sipa> but you shouldn't :)
08:50 -!- rebroad [~rebroad@node-11cu.pool-118-173.dynamic.totbb.net] has quit [Ping timeout: 256 seconds]     
08:50 < wumpus> the implementation can be split into multiple files, the definition must be in one place, generally
08:50 < NicolasDorier> well, we could split CScript what belongs to consensus and what not
08:51 < sipa> see core_io.h with core_write.cpp and core_read.cpp for exmample
08:51 < sipa> NicolasDorier: die
08:51 < NicolasDorier> ahah is this so contentious :D
08:51 < sipa> NicolasDorier: now the users of your class' dependencies depend on _how_ they use the class
08:52 < wumpus> the way to achieve things like that is to define a bare data structure and have function act on it, like in the old days
08:52 < wumpus> you can put the functions everywhere
08:52 < sipa> indeed
08:52 < sipa> leveldb uses a struct with a {char* ptr; size_t size} in many places
08:53 < sipa> allowing processing routines to be independent from storage
08:53 < wumpus> we need a slice abstraction too
08:53 < sipa> slice, that's it
08:53 < wumpus> golang has that pretty much as central data representation :)
08:54 < NicolasDorier> well, you can represent a script with a char* and then just have two type PolicyScript and CScript would be better than bare, mainframe time code :p
08:54 < wumpus> nearly every time an array is passed, a slice is really passed, the slices keep a reference to the underlying array so it can't go away
08:54 < sipa> there wouldn't even be a CScriot
08:54 < NicolasDorier> you could wrap your char* by one of those
08:54 < sipa> just an EvalScript
08:55 < sipa> there could be a CScriptBuilder with the << operators etc for convenience
08:55 < wumpus> right - script generation isn't part of consensus
08:55 < sipa> exactly
08:55 < sipa> it would just be utikity
08:55 < NicolasDorier> wumpus: by "Slice" abstraction, you mean a structure  {*array, index, count} ?
08:55 < wumpus> NicolasDorier: yes
08:55 < wumpus> I think in golang it's a kind of shared pointer. Not sure though how they do memory internally
08:56 < wumpus> in leveldb it's just a *
08:56 < wumpus> so they don't 'hold' the memory, they just reference it, which is slightly more error prone but maybe lower overhead
08:57 < wumpus> in any case for one-off methods like consensus calls the distinction doesn't matter
08:57 < wumpus> consensus has no state and will never hold on to your slices
08:58 < wumpus> OK OK the statelessness not true if you include the caches
08:58 < wumpus> *current* libconsensus has no state
08:59 < michagogo> achow101: I don't think I did more than what gitian's README says
08:59 < NicolasDorier> in any case, I'm sold for the script evaluator code duplication which is specific to consensus. Not yet for char* everywhere though :D
09:00 < michagogo> (not as a "this is a list of steps to follow blindly", but as a way to understand how the system works and how to set it up)
09:00 < wumpus> not sure what you mean there, script is just a char*,size effectively. It has no internal structure
09:00 < michagogo> And yeah, the ova isn't fully uploaded yet
09:01 < michagogo> OneDrive says it's uploaded 1.2 out of 3.6 GB
09:01 < NicolasDorier> wumpus: I know, just for the use of code like GetSigOpsCount(char* script) insead  of script->GetSigOpsCount() But I may be spoiled kid with my C# :D
09:01 < michagogo> Unfortunately it looks like it doesn't show a speed or time estimate, unlike Dropbox...
09:01 < wumpus> on the C# size you could re-add all the syntactic sugar that you want, esp if you use it for non-consensus
09:02 < NicolasDorier> yeah with extension method :))
09:02 < wumpus> (e.g. if you *want* GetSigOpsCount implies you're doing policy)
09:02 < NicolasDorier> ah GetSigOpsCount I though it was part of consensus my bad
09:03 < michagogo> The Linux gitian build worked on the new appliance:  https://www.irccloud.com/pastebin/RpH8KGPY/
09:04 < wumpus> hm you're right I think, though if possible that would be used internally by libconsensus and not exposed
09:04 < achow101> michagogo: great! I guess gitian doesn't hate you. I followed the gitian readme almost to the word (I used vmware instead of vbox, but I don't think that makes a difference) and it still didn't work for me
09:05 < michagogo> achow101: Hm, odd
09:05 < michagogo> You said you weren't able to play the webm?
09:05 < michagogo> VLC seems to be playing it without a problem...
09:06 < michagogo> Looks like Chrome is doing just fine as well
09:06 < achow101> it didn't work in whatever default video player ubuntu uses. I'll try vlc
09:06 < michagogo> It's about an hour long
09:07 < achow101> yeah, it works in vlc
09:07 < michagogo> Shows the entire process, from the moment I booted the fresh VM from the 14.04.5 ISO until the moment I shut it down to export
09:07 -!- jujumax [~jujumax@host55.190-31-39.telecom.net.ar] has quit [Ping timeout: 248 seconds]     
09:07 < michagogo> Trial, error, and all
09:08 < michagogo> (also with some pauses while I looked stuff up outside the VM...)
09:11 < achow101> why do you need apt-cacher-ng
09:13 < michagogo> achow101: because when you're installing the same packages every time you gbuild, it's easier not to have to download them every single time
09:14 < michagogo> And once you're already setting up and using it for gitian, may as well point apt at it and have it go through there
09:14 < michagogo> (so that when you e.g. upgrade a system package, the same package is available to the gitian container when it needs to upgrade)
09:14 < achow101> ok     
09:19 < michagogo> Lauda: You may be interested in this too
09:19 < michagogo> In the meantime it's up to 1.3 GB...
09:20 < michagogo> Actually, just realized I can check Resource Monitor
09:21 -!- jujumax [~jujumax@186.158.136.209] has joined #bitcoin-core-dev     
09:24 < michagogo> Looks like OneDrive is currently uploading at about 250-300KB/s
09:25 -!- cdecker [~quassel@2a02:aa16:1105:4a80:183c:ad5:f656:aa73] has quit [Ping timeout: 260 seconds]     
09:26 -!- jujumax [~jujumax@186.158.136.209] has quit [Ping timeout: 248 seconds]     
09:26 < michagogo> achow101: Looks like it should show up in 2-3 hours
09:26 < michagogo> (assuming a steady rate)
09:27 -!- rebroad [~rebroad@node-11cu.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev     
09:32 < Lauda> thanks michagogo
09:34 < wumpus> luke-jr, Victorsueca: the RPC tests work on windows, but are currently disabled there in travis because of timeout issues
09:35 < wumpus> see https://github.com/bitcoin/bitcoin/pull/8227
09:37 < jonasschnelli> sipa, available?
09:38 < sipa> jonasschnelli: yes
09:39 < cfields_> BlueMatt: ping. #8969 ready for review/testing?
09:39 < jonasschnelli> When notifying about the header tip, can we not just use pIndexBestHeader instead of retrieving from setBlockIndexCandidates? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3010
09:39 < Victorsueca> wumpus: I tried it and there's some error with subprocess.py https://softnet.homenet.org/zerobin/?586fe4c0934c7d9c#fMLN5XtScV/cdqkwjN6dTkLU17hjkL0iiNGW81x7aNw=
09:39 < jonasschnelli> sipa: NotifyHeaderTip is only used by the gui and IMO it should just reflect whats inside pindexBestHeader... not?
09:40 < Victorsueca> wumpus: a similar error occurs even on a ubuntu env https://softnet.homenet.org/zerobin/?6b8aa1b1b6e5aca7#MhP7eiv7h8L7mHC9LMAIk6ytlzsmY2Hv+3t7I7WnUtQ=
09:41 < sipa> jonasschnelli:  remember thinking about that, and that we should indeed just switch to using pindexBestHeader
09:41 < jonasschnelli> sipa: Okay. Let me try a PR. I'd like to fix https://github.com/bitcoin/bitcoin/issues/8984 with it as well
09:42 < BlueMatt> cfields_: sure! go for it
09:43 < BlueMatt> cfields_: though maybe first do 8968 first, and review those separately
09:43 < BlueMatt> cfields_: 8969 should be pretty simple without 8968
09:43 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
09:43 < cfields_> BlueMatt: got it, thanks
09:44 < BlueMatt> sipa: got a chance to rebase 8515? I got sucked into making fibre support variable bw depending on the remote node
09:44 < BlueMatt> :/     
09:44 < cfields_> BlueMatt: ok. getting ready to update my stale PRs and catch up with your work, sorry for the delay. Mining is a rabbit-hole.
09:44 < BlueMatt> and fighting with hosts about their shitty routing
09:44 < BlueMatt> cfields_: no rush, so is debugging the shitty, shitty world of chinese internet
09:44 < cfields_> heh     
09:44 < sipa> BlueMatt: will do
09:46 < cfields_> BlueMatt: ah, if it weren't so last minute, i think i'd be in favor of backporting 8968 to 13.1. holding cs_main there is really scary, considering how far down that can go
09:47 < BlueMatt> cfields_: yea, we talked about this in milan...decided against it because it was late even then
09:47 < cfields_> BlueMatt: have you done any traces to see the worst-case effects of holding it in 0.13? maybe there are small tweaks we can do for 0.13 if there are known possible deadlocks?
09:48 < BlueMatt> cfields_: it should never cause deadlock since cs_main should always be the first lock, I believe
09:48 < BlueMatt> maybe sipa want to comment since he was the one claiming so in milan
09:48 < cfields_> BlueMatt: specifically, it's holding it while grabbing cs_vSend/cs_vRecvMsg that worry me
09:49 < cfields_> agh, brb.
09:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
10:04 < GitHub157> [bitcoin] jonasschnelli opened pull request #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (master...2016/10/fix_gui_overlay) https://github.com/bitcoin/bitcoin/pull/8985
10:19 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
10:33 < wumpus> cfields_: do you really think it's worth delaying 0.13.1 release for? or do you mean 'it should be included if we need to do rc3 anyway'?
10:34 < cfields_> wumpus: no, i don't think it's worth delaying. Unless something nasty manifests. It's just in the category of "feels icky and scary".
10:34 < wumpus> I agree
10:36 < Victorsueca> wumpus: is my error related to what you said or it's a different thing?
10:38 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
10:39 < wumpus> Victorsueca: I don't really know
10:40 < wumpus> what does "El sistema no puede encontrar el archivo especificado" mean?
10:40 < Victorsueca> The system couldn't find the specified file
10:41 < wumpus> ohh, no that's a different problem. You could try setting the environment variable BITCOIND to the location where bitcoind is
10:41 < wumpus> looks like it's simply notable to find the daemon
10:42 < sipa> s/notable/unable/ ?
10:42 < Victorsueca> thanks, will try
10:43 < Victorsueca> should I set it to the directory where bitcoind is or directly to the bitcoind.exe file?
10:43 < wumpus> the file
10:44 -!- laurentmt [~Thunderbi@80.215.178.214] has joined #bitcoin-core-dev     
10:44 -!- laurentmt [~Thunderbi@80.215.178.214] has quit [Client Quit]     
10:47 < Victorsueca> wumpus: done, exactly the same error
10:48 < Victorsueca> ohh wait, didn't restart the terminal...
10:48 < sipa> wallet/rpcdump.cpp:1020:13: warning: ‘nLowestTimestamp’ may be used uninitialized in this function [-Wmaybe-uninitialized] int64_t nLowestTimestamp;
10:50 < wumpus> Victorsueca: I don't get it then, you'll need to do more debugging what process it is trying to execute in the first place
10:52 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Read error: Connection reset by peer]     
10:53 < Victorsueca> well, the bash is on C:\UNIX\bitcoinalpha
10:53 < Victorsueca> which is where I cloned the master branch of the git repository
10:53 < sipa> Victorsueca: i don't think this channel is right for helping you debug these things
10:54 < Victorsueca> sipa: well, maybe something is wrong with the rpc tests in which case it should be fixed
10:55 < Victorsueca> first i'm trying to figure out if I did something wrong or the python script has some bug
10:55 < wumpus> "maybe". But you should first try to debug it locally, before making allegations like that
10:55 < wumpus> the QA tests are run by many people on many platforms
10:55 < achow101> Victorsueca: what's the problem again? I'll see if I can replicate
10:56 < Victorsueca> achow101: I posted the link above
10:56 < Victorsueca> wumpus: few on windows AFAIK
10:56 < wumpus> no, really ,they are being run on windows
10:56 < Victorsueca> hmmm ok
10:56 < Victorsueca> any instructions on how to dump extra debug info?
10:57 < wumpus> I think you need general python debugging tools
10:57 < wumpus> there's nothing bitcoin specific about not being able to execute the right executable
10:59 < Victorsueca> well, don't know if this is relevant but trying rpc-tests.py on a ubuntu enviroment brings out the same error
11:00 < Victorsueca> I guess that would discard being something windows-specific
11:00 < michagogo> achow101: .6 GB to go
11:01 < sipa> Victorsueca: rpc-tests.py is succesfully run for every pull request on travis... if it doesn't work for you, you likely have something missing in your setup
11:01 < wumpus> it's interesting how everyone on windows seems to have a problm debugging. The only people I've seen succesfully debug on windows are people reverse engineering or looking for exploits :p
11:01 < Victorsueca> sipa: yep, likely
11:02 < wumpus> even a backtrace seems to be problematic
11:02 < Victorsueca> wumpus: that's because windows is made to fail, M$ doesn't care because you already paid for the license :P
11:03 < wumpus> Victorsueca: well in the case of linux much likely no one paid for anything, it seems to be something with transparency of APIs
11:04 < Victorsueca> wumpus: exactly, if linux was such a huge crap as windows nobody would use or even care about contributing into it so it would be dead
11:04 < Victorsueca> in M$ they already have the money so they can use to to make even more crap software
11:07 < sipa> referring to microsoft M$ isn't particularly meaningful - every company tries to make money
11:07 < michagogo> Hm, just saw this morning's (last night's, really) wallops
11:07 < michagogo> I wonder if we're in scope
11:09 < sipa> michagogo: link?
11:09 < michagogo> http://freenode.net/news/community
11:09 < michagogo> (the full message was: 00:04:00 <nhandler> We would like to introduce you to the freenode Community Team (http://freenode.net/news/community). Please join us in #freenode-community and let us know how we can make freenode a more useful place for your group.)
11:09 < wumpus> sipa: looks like it may be a false positive, nLowestTimestamp is supposed to be only set and used in the case of fRescan
11:11 < achow101> Victorsueca: wumpus: replicated the problem, found the issue (I think)
11:12 < wumpus> it's true that everyone wants money for everything on the windows platform; no one is going to support a free debugger for windows, if you want proper debugging you probably have to buy some expensive development package
11:13 < achow101> It seems the the RPC_TESTS_DIR returns the path with unix style e.g /mnt/c/... and it isn't liking that
11:13 < wumpus> it's a valid way to do things, but that means targetting open source to windows is hard, ideally we should sell bitcoin core on windows instead of offer a free download :-)
11:15 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev     
11:15 < Victorsueca> achow101: maybe adding shell=True would solve it?
11:15 < wumpus> achow101: but he tried to override BITCOIND already
11:15 < wumpus> no, don't add shell=True please, that's a security disaster
11:15 < Victorsueca> lol yeah
11:16 < sipa> BlueMatt: remabsed 8515
11:16 < sipa> *rebased
11:16 < sipa> sometimes i fail to understand my own fingers.
11:17 < achow101> Victorsueca: it's because both of us built using WSL
11:17 < achow101> the problem is with the SRCDIR variable. If you go to qa/tests_config.py you'll see why
11:18 < Victorsueca> achow101: no such file
11:18 < achow101> sorry, qa/pull-tester/test_config.py
11:20 < Victorsueca> ahh lol
11:20 < Victorsueca> variables are in unix-like paths
11:21 < achow101> but fixing there's another error after fixing that
11:25 -!- rebroad [~rebroad@node-11cu.pool-118-173.dynamic.totbb.net] has quit [Ping timeout: 260 seconds]     
11:26 < Victorsueca> achow101: which one?
11:26 < achow101> %1 is not a valid Win32 application
11:27 < achow101> that happens when I run it again
11:27 < Victorsueca> i'm still getting the same error tho
11:28 < GitHub0> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f2d705629b51...0e228557f239
11:28 < GitHub0> bitcoin/master 7942d31 Luke Dashjr: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions
11:28 < GitHub0> bitcoin/master 0e22855 Wladimir J. van der Laan: Merge #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions...
11:28 < achow101> check your path and make sure it is correct. Use forward slashes instead of backslashes
11:28 < GitHub21> [bitcoin] laanwj closed pull request #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (master...compat_importmulti_oldboost) https://github.com/bitcoin/bitcoin/pull/8980
11:28 < BlueMatt> sipa: thanks
11:30 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has quit [Quit: ZNC 1.6.3 - http://znc.in]     
11:31 < gmaxwell> bleh why are we using boost::variant?
11:33 < wumpus> don't know, ask satoshi? that has been used for the base58 stuff as long as I remember at least
11:33 < sipa> nope, i introduced it.
11:33 < sipa> jonasschnelli: how do you unhide the catching up overlay?
11:33 < wumpus> I guess it's a convenient way to do that
11:34 < sipa> gmaxwell: well because it's exactly what we need for CTxDestination... a tagged union
11:34 < wumpus> I absolutely doubt it's the hardest thing to replace if we really were to want toget rid of hoost
11:34 < sipa> wumpus: absolutely
11:34 < wumpus> why is it such an issue for you gmaxwell ?
11:34 < sipa> though it's not trivial either
11:35 < sipa> as using a C union with non-trivial types in it is asking for problems
11:35 < achow101> Victorsueca: the second I error I ran into is because python.exe isn't being called where normally it will with linux
11:35 < achow101> tl;dr don't run the rpc tests on windows because windows does stupid things
11:36 < wumpus> yes i can't just be replaced with a C union, agreed, but thinking of some other construct to replce it doesn't seem ahrd
11:36 < Victorsueca> achow101: thanks, will put that on a bitcoin block so everybody knows ;)
11:37 < sipa> jonasschnelli: ah, clocking on the warning icon. that took me a while - isn't there a way to make it more obvious, like adding another top bar with "You're currently out of sync with the network. Click here for more information' ?
11:37 < wumpus> the usualy way in C++ would be something with subclasses
11:38 < sipa> yuck. that means the child classes need to know that they're part of a union
11:38 < wumpus> sipa: sure, feel free to make it more obvious
11:38 < sipa> wumpus: i don't know Qt :)
11:39 < wumpus> sipa: well evertying is a compromise, I'm sure some other solution could be thought up without that drawback
11:39 < wumpus> without having to go into boost template hell
11:39 < sipa> i guess my poreferred solution would be to reimplement boost::variant :)
11:40 < sipa> c++ really lacks a tagged union
11:40 < wumpus> bleh
11:40 < wumpus> the point of moving from boost is not to reimplement it, if that's what needs to happen we should just stuck with boost
11:40  * sipa is maybe biased by Haskell, where tagged union is pretty much the only way to construct new types
11:41 < cfields_> sipa: iirc c++14 adds std::variant and/or std::any
11:41 < wumpus> the only valid reason to change it if there is a more c++11 way of doing things, if not, let's just keep it as it is
11:41 < wumpus> we *don't * want to support half of bost as part of bitcoin core
11:41 < sipa> cfields_: aha!
11:42 < cfields_> sipa: bah, both c++17 :(
11:42 < wumpus> are we at c++17 yet?
11:43 < sipa> cfields_: oh, so we only need to wait until 2022 until we can use it in Bitcoin Core?
11:43 < wumpus> yes     
11:43 < cfields_> heh     
11:43 < cfields_> sipa: i think that's not quite fair, though. 14/17 are quite different from 11. afaik, gcc/clang are both ahead of the spec, rather than years behind as with c++11
11:44 < wumpus> knowing that it is supported in a future c++XX standard also removes all motivation to look for an alternative way to do it :)
11:44 < sipa> afaik c++14/17 change much less than what c++11 changed wrt to c++03
11:44 < wumpus> we only need time, and that elapses automatically
11:44 < cfields_> wumpus: yep, see std::filesystem :)
11:44 < gmaxwell> wumpus: because there is no analog in C++ afaik, and I recall the implementation being really ugly and slow-- though perhaps I'm wrong, and another boost dependency.
11:45 < cfields_> sipa: yes, true
11:45 < sipa> how many headers does testnet have?
11:45 < gmaxwell> wumpus: but it wuld be inaccurate to say it's such an issue.. it's now, I was just asking.
11:45 < wumpus> gmaxwell: sure, I'dcompletely believe that, though it's not used in any performance critical inner loops IIRC, so I don't think the performance is so important here
11:46 < wumpus> it's apparently just hard to support something like that in c++
11:46 < gmaxwell> wumpus: from a general principle of programming, using runtime determined types often undermines type safty. (often irrelevant on a case by case basis, but if I'm speaking in generalities...)
11:46 < wumpus> gmaxwell: well you're welcome to implement it in a better way! :)
11:47 < sipa> it's preferctly applicable in cases where you can say "an X is either a Y or a Z"
11:47 < cfields_> gmaxwell: yes, the more c++ish way of doing it almost certainly implies try/catch+dynamic_cast, which i find pretty nasty
11:47 < wumpus> yes, I don't think we use it in a type safety undermining way, we have visitors and such to handle all the cases
11:47 < sipa> cfields_: puke
11:47 < gmaxwell> (and yes, I also believe polymorphism is generally ill-advised based on the same argument)
11:48 < wumpus> cfields_: or as I said above, subclasses and the visitor pattern. NOt that that would really be any improvement in type safety
11:48 < sipa> found the C programmer.
11:48 < wumpus> sigh, let's not get into that discussino
11:49 < cfields_> wumpus: yes, that'd be much cleaner
11:49 < sipa> (though i would agree with saying that such constructions are often used in places where they're unnecessary and harmful)_
11:49 < wumpus> cfields_: sipa didn't like it because the subclasses have to know they're part of an union
11:49 < cfields_> wumpus: yes, that'd be the "tag" part :p
11:49 < cfields_> oh, i see what you mean
11:50 < wumpus> sure, polymorphism is certainly overused in some cases, espeically in the beginnign when it was new and everything had to be an object
11:50 < sipa> *switch topic* what is testnet's height?
11:50 < gmaxwell> sipa: yea, I don't mean that in a dogmatic sense. And I think in bitcoin core things are usually sensible. But I've had too much exposure to codebases where novices overuse these really exotic tools. 
11:50 < cfields_> sipa:  UpdateTip: new best=00000000000025c20dd75c51046acae15bdaa04151db3fc50d8d9cc673e6899e height=1009187 version=0x20000000 log2_work=68.584926 tx=11687999 date='2016-10-20 18:45:26' progress=1.000000 cache=6.6MiB(15650tx)
11:50 < wumpus> gmaxwell: yes - it's even worse in java code generally :)
11:50 < gmaxwell> sipa: on segwit nodes 1009190
11:50 < cfields_> as of a min or two ago
11:50 < sipa> cfields_: thanks. trying to sync headers over a really slow connection
11:53 -!- K-ballo [~Thunderbi@181.228.43.137] has joined #bitcoin-core-dev     
11:54  * wumpus should start running a dedicated testnet node again
11:55 < jonasschnelli> <*highlight>	[20:37:05] <sipa:#bitcoin-core-dev> jonasschnelli: ah, clocking on the warning icon. that took me a while - isn't there a way to make it more obvious, like adding another top bar with "You're currently out of sync with the network. Click here for more information' ?
11:55 < wumpus> btw: I've had, out of many 'no' responses, only two people admitting they're still running bitcoin core on windows 32-bit. Both expect to stop doing so in the next 6 months.
11:56 -!- instagibbs_ [640f7203@gateway/web/freenode/ip.100.15.114.3] has joined #bitcoin-core-dev     
11:56 < sipa> thinking a bit more about it, std/boost::variant isn't exactly a generic tagged union, it's a union where the type is the implicit tag
11:56 < jonasschnelli> Yes. It's a bit hidden. What about clicking on the progress bar in the status bar?
11:56 < sipa> and a real tagged union would be much more useful
11:56 < wumpus> sipa: good point
11:57 < sipa> jonasschnelli: that'd be useful too
11:57 < sipa> (it was the first thing i tried)
11:57 < wumpus> so I think stopping support for windows 32-bit in 0.15 would make sense
11:58 -!- jujumax [~jujumax@200.117.99.162] has quit [Ping timeout: 248 seconds]     
11:58 -!- rebroad [~rebroad@node-11cu.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev     
11:58 < achow101> meeting?
11:58 < wumpus> in two minutes!
11:58 < sipa> one and a half
11:58 < achow101> aw man, my clock's fast
11:59 < Victorsueca> what meeting?
11:59 < jl2012> the last windows with 32-bit is windows 7?
11:59 < achow101> Victorsueca: dev meeting
11:59 -!- harrymm [~wayne@104.222.140.70] has quit [Ping timeout: 252 seconds]     
11:59 < achow101> jl2012: windows10 has a 32 bit version
11:59 < Victorsueca> ^     
11:59 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
12:00 < Victorsueca> achow101: is it going to be broadcasted?
12:00 < achow101> it happens right here on irc
12:00 < CodeShark> it's here
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Oct 20 19:00:15 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < wumpus> proposed topics?
12:00 < sipa> proposed cheer: yay for 0.13.1rc
12:00 < CodeShark> ^ :DDD
12:00 < jonasschnelli> heh     
12:00 < wumpus> yay for 0.13.1rc, haven't heard of any real problems yet
12:01 < achow101> hmm. where's gmaxwell-ping-bot
12:01 < wumpus> not that it says much given how short it's been out, but ok, it's somewhat promising :)
12:01 < CodeShark> if only execution paths with problems tended to occur first :p
12:02 < wumpus> #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
12:02 < jtimon> proposed topic: libconsensus: do we want to expose a verifyBlock function or a processblock one? do we want to expose verifyHeader and verifyTx ?
12:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
12:02 < btcdrak> here
12:02 < wumpus> ah yes I have another topic about the libconsensus interface: what to do with undocumented flags
12:02 < instagibbs_> present
12:02 < btcdrak> ping jl2012
12:03  * paveljanik here
12:03 < jl2012> yes     
12:03 < wumpus> jl2012 was already here
12:03 < jtimon> wumpus: like bip113 ? or more like bip30 ?
12:03 < wumpus> jtimon: https://github.com/bitcoin/bitcoin/pull/8976
12:03 < wumpus> #topic libconsensus
12:04 < wumpus> currently it's possible to pass non-consensus flags into libconsensus
12:04 < wumpus> e.g. policy only flags
12:04 < CodeShark> yes, that should be pulled out
12:04 < sipa> i believe we should not expose policy functions in libconsensus
12:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:04 < sipa> as that would make it impossible to later split off policy code into a separate codebase
12:04 < BlueMatt> sipa: ack
12:05 < sipa> and consensus code should end up being isolated
12:05 < wumpus> ok so that means you agree with #8976
12:05 < instagibbs_> was there thought otherwise? (I'm outsider to this work)
12:05 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8976
12:05 < CodeShark> yeah, doesn't seem very controversial
12:05 < jtimon> I agree, currently it is not possible (at least using bitcoinconsensus_verifyScript)
12:05 < instagibbs_> ah I see what you mean
12:05 < wumpus> no, I don't think so. But people may be relying on this. I don't know anyone that does though.
12:05 < wumpus> and NicolasDorier is okay with it
12:05 < BlueMatt> wumpus: dont have a strong opinion, but I'm fine with that
12:06 < wumpus> if there is to be a policy script library it'll need to be separate imo
12:06 < jtimon> btw, currently the flags in script/bitcoinconsensus.h and in script/interpreter.h need to match, that shouldn't be the case
12:06 < wumpus> this is lib*consensus*
12:06 < sipa> jonasschnelli: agree
12:06 < sipa> eh, jtimon: agree
12:06 < wumpus> jtimon: no, they don't need to match, that's just an artifact
12:06 < sipa> wumpus: is there are translation layer?
12:07 < wumpus> although it's no longer possible to change the flags now 
12:07 < wumpus> ABI for libconsensus is fixed
12:07 < jtimon> wumpus: I mean, if I change  bitcoinconsensus_SCRIPT_FLAGS_VERIFY_WITNESS             = (1U << 11) to some other number different from 11, things won't work
12:07 < wumpus> sipa: no, that was never added
12:07 < sipa> we should add one
12:07 < sipa> and keep the flags for the existing bits
12:07 < jtimon> agreed
12:07 < sipa> as passthrough
12:07 < wumpus> yes, there should be a translation layer, though the current bits can no longer be changed
12:07 < wumpus> agreed
12:07 < sipa> but new ones can fill up the holes
12:08 < jtimon> btw, related branch: https://github.com/jtimon/bitcoin/commits/0.13-consensus-flags
12:08 < wumpus> at the lesat we should add the error when invalid flags are passed
12:08 < CodeShark> is anyone using these flags as ints rather than just as an enum?
12:08 < wumpus> this will discourage people from doing what they're doing now, e.g. treating it as a pass-through
12:09 < wumpus> they're using it as an unsigned int because that's the type passed in, remember it's a C interface, enums don't support bit field combos
12:09 < sipa> CodeShark: we're already abusing enum here. it's a bit field, not an enum
12:09 < sipa> the enum is just an easy way to give the constants name
12:09 < jtimon> CodeShark: AFAIK there used always like if (flags & MY_FLAG)
12:09 < sipa> for almost all operations we do with these enums, they decay into integers
12:09 < wumpus> yes     
12:09 < CodeShark> right - I meant, does it matter if we shuffle the bits as long as the integer values are not used anywhere outside the definitions?
12:10 < sipa> CodeShark: that breaks the ABI
12:10 < wumpus> you can't shuffle the bits because it would break the *binary* interface
12:10 < CodeShark> oh...
12:10 < sipa> you can't link with an older version of the library in that case
12:10 < CodeShark> ok     
12:10 < CodeShark> gotcha
12:10 < wumpus> the idea is that you can jsut drop in the 0.13.1 consensus library in place of the 0.13.0 one and it will work
12:11 < sipa> without recompiling your client
12:11 < wumpus> arguably the SEGWIT bit can be moved until 0.13.1 is finalized, but meh
12:11 < sipa> indeed, meh.
12:12 < jtimon> these are the consensus flags I end with in that branch: https://github.com/jtimon/bitcoin/blob/0.13-consensus-flags/src/consensus/flags.h
12:12 < CodeShark> sipa: so you're saying we can reuse the bits that get vacated when we remove the policy flags
12:12 < sipa> CodeShark: yes
12:12 < sipa> as those were never part of the abi
12:12 < wumpus> CodeShark: the policy flags were never really allowed by the interface, it's a bug that it posibble to specify them at all
12:12 < sipa> *api
12:12 < wumpus> this is what #8976 fixes by adding input checking on the flags
12:13 < jtimon> and my preference would be to expose a GetConsensusFlags call in libconsensus too
12:13 -!- Guest12765 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit []     
12:13 < wumpus> what would that do?
12:13 < jtimon> to hide the bip9 and previous developments stuff
12:14 < jtimon> you call it, now you know which flags to use verifyScript, verifyTx or verifyBlock (or verifyBlock could call it internally)
12:14 < sipa> and you pass in all block headers?
12:14 < jtimon> https://github.com/jtimon/bitcoin/blob/0.13-consensus-flags/src/versionbits.cpp#L153
12:15 -!- harrymm [~wayne@104.222.140.40] has joined #bitcoin-core-dev     
12:15 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
12:15 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Excess Flood]     
12:15 < jtimon> no, the same CBlockIndex interface used for verifyHeader
12:15 < sipa> i really don't like turning our internal representation for headers into an index
12:15 < jtimon> similar to https://github.com/bitcoin/bitcoin/pull/8493
12:16 < sipa> *into an interface
12:16 < CodeShark> sipa: agreed
12:16 < CodeShark> it could be done better
12:16 < jtimon> other ideas to interface with storage ?
12:16 < CodeShark> without exposing all that crap
12:16 < jtimon> CodeShark: how?
12:16 < sipa> just have an API where you can create a blockindexstore, and you give it headers 
12:17 < sipa> which are copied into the blockindexstore
12:17 < CodeShark> yes     
12:17 < jtimon> so libconsensus remains coupled with our storage?
12:17 < sipa> that's my personal preference
12:17 < CodeShark> well...hmmm
12:17 < jtimon> I wasn't planning on taking any headers from callers
12:17 < kanzure> i don't mean to go all pointy hair or anything, but what is current expectation around libconsensus separation milestone timelines
12:17 < sipa> kanzure: nobody even agrees what libconsensus means.
12:17 < kanzure> perfect
12:18 < CodeShark> the header storage engine is quite trivial, actually
12:18 < CodeShark> not sure it needs an abstract DB interface...but on the other hand...
12:18 < wumpus> I think the previous conslusion was that libconsensus should remain coupled with the current caching layer, but not with leveldb
12:18 < jtimon> ok, so you guys want the libconsensus++ luke-jr wanted (ie storage included), I would be fine with having both one with storage included and one without it
12:18 < BlueMatt> we already discussed this in milan
12:19 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
12:19 < wumpus> so the *memory* storage is part of libconsensus
12:19 -!- Cory [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Excess Flood]     
12:19 < wumpus> the disk storage is not
12:19 < BlueMatt> that
12:19 < CodeShark> ok     
12:19 < jtimon> BlueMatt: yeah, you and me discussed it a little, with no conclusion
12:19 < wumpus> right,we discussed that in Milan
12:19 < sipa> jtimon: my fear is that it's very hard to create a stable API for storage of headers... things like BIP9 cache and the skiplist for example are things that would break the API, but such changes may be needed in the future
12:19 < kanzure> meaning of "storage" has to be carefully defined
12:19 < sipa> they're perfectly compatible with a store into which you can load headers, though
12:20 < jtimon> sipa: so let's break the API, users of libconsensus++ may have a more stable API, but less flexibility and control too
12:20 < jonasschnelli> We are speaking of a in-memory only store, right?
12:20 < BlueMatt> i think the first target is this, and then, if at some point we decide we want to support no-headers-in-memory, we can add an api for storage
12:20 < wumpus> jonasschnelli: yes. as currently used for the headers
12:20 < BlueMatt> but i think that is further out on the horizon
12:20 < wumpus> BlueMatt: agreed, that's no issue right now
12:20 < BlueMatt> also because refactoring every use of CBlockIndex into an api right now would be a ton of work/review/diff
12:21 < sipa> the criterion would be that we ourself want to use it
12:21 < wumpus> later on it may make sense to not support storing all headers in memory, but let's let's not try to do everything atonce
12:21 < wumpus> s/not support/support not/
12:21 < sipa> if the API somehow needs to miss features, e.g. because adding some cache is hard, that goal is already broken
12:21 < CodeShark> no need for premature optimization here
12:21 < CodeShark> header storage is not a bottleneck ;)
12:21 < sipa> CodeShark: it's not premature optimized. it's breaking existing optimization
12:21 < kanzure> CBlockIndex usage is not necessarily libconsensus-only, right?
12:21 < jtimon> I was speaking both memory and disk storage, for all I know, some callers may have the headers on disk and maybe others have the whole utxo in memory
12:21 < sipa> storage isn't, but block index traversal needs to be past
12:22 < sipa> *fast
12:22 < kanzure> i mean that's only because nobody wants to maintain a CBlockIndex and also libconsensus, ya?
12:22 < sipa> kanzure: i have no clue what you're talking about
12:22 < Victorsueca> kanzure: maybe we could define "storage" as the port where you request/send data that needs to be stored but is not immediately required
12:22 < sipa> storage... port?
12:22 < sipa> wth?
12:22 < wumpus> I think a good goal should be that we could use libconsensus ourselves, at least it will have one client then :)
12:22 < kanzure> (i was responding to "refactoring every use of CBlockIndex into an api".)
12:23 < CodeShark> let's not get sidetracked
12:23 < wumpus> please, let's not split hairs over definitions
12:23 < Victorsueca> sipa: not a network port obv
12:23 < wumpus> any other topics?
12:23 < cfields_> wumpus: +1. As a side-effect, that also forces devs to become familiar with it.
12:23 < gmaxwell> sorry, went to sleep during API discussions. I agree that the library should be used by bitcoin core if it is to exist. :)
12:24 < gmaxwell> (I also support it existing, to be clear!)
12:24 < wumpus> cfields_: right, so it's possible to fork bitcoin core but still use the same libconsensus, for example
12:24 < jtimon> BlueMatt: an interface for CBlockIndex wouldn't requiore a ton of review, just some review. Remember you can use wrappers for the old stuff and only libconsensus needs to use the interface (uppper layers can remain using CBlockIndex directly), please see https://github.com/bitcoin/bitcoin/pull/8493
12:25 < wumpus> gmaxwell: if some topic isn't interesting to you, you don't need to be loud about that
12:25 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
12:25 < jonasschnelli> Would it hurt if the libb*'s blockstorage be completly decoupled from the CBlockIndex, new structures, etc. as a first step?
12:25 < sipa> jonasschnelli: we're not even talking about block storage
12:25 < jonasschnelli> sorry, heards
12:25 < CodeShark> we're still on headers :p
12:25 < jonasschnelli> headers
12:25 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-core-dev []     
12:26 < jtimon> conclusion, nobody seems to want the libconsensus I've been trying to move towards to, and as an external caller I wouldn't want a libconsensus++ (coupled to bitcoin core's storage and concurrency)
12:26 < kanzure> external caller == other wallet?
12:26 < jtimon> you guys want a processBlock function, not a verifyBlock one
12:26 < sipa> jtimon: i think exposing verification functions at different levels is useful
12:26 < jtimon> kanzure: yep, a wallet, an alternative implementation, whatever
12:26 < sipa> exposing headers, individual block, total block, ...
12:27 < sipa> jtimon: but the question is about whether or not to abstract out the state needed for that
12:27 < jtimon> sipa: cool, BlueMatt seem to think it's not
12:27 < sipa> those are independent questions
12:27 < jtimon> in any case, you don't want a verifyHeader independent of storage
12:27 < kanzure> jtimon: yes to me it sounds like you need to pass to libconsensus a reference to something that implements storage.  but iirc there are some concerns about consensus-coupled storage backend details.
12:28 < sipa> i think it would hurt our own usage of it, as it means fewer opportunities to improve memory usage
12:28 < jtimon> sipa: I think "is it needed" it's not the question, nothing is needed, the wuestion is what we want to do
12:28 < sipa> what i want to do is have the consensus code abstracted out
12:28 < wumpus> it is needed if it is used by us
12:28 < sipa> modularized
12:28 < jtimon> kanzure: I highly doubt libbitcoin will ever use a libconsensus that's coupled to bitcoin's storage and concurrency, for example
12:28 < BlueMatt> jtimon: I have no problem exposing a verifyblock function that makes no external state lookups, but I dont think its so useful
12:28 < sipa> that doesn't mean we need to abstract out every data structure it uses
12:29 < BlueMatt> jtimon: I dont see much use for a verifyblock function that makes external state calls when you could just do processnewblock
12:29 < kanzure> jtimon: well the complicating detail here is that folks probably just want to use core's current storage implementation details (etc) to cut down on work, i think.
12:29 < CodeShark> breaking out the storage engine can be done independently
12:29 < wumpus> BlueMatt: yes, I remember we discussed that before, too :)
12:29 < kanzure> what is the concurrency coupling that jtimon mentions in particular
12:30 < sipa> CodeShark: we're not really talking about (disk) storage here, just in-memory representation of data structures
12:30 < BlueMatt> wumpus: yes, this is exactly the discussion we had in milan
12:30 < jtimon> BlueMatt: right, I believe some callers don't want the library to do the processnewblock because they want to do certain things themselves (for example, libbitcoin AFAIK)
12:30 < BlueMatt> jtimon: have you spoken much to these folks? (I dont know, just asking, would love to see their responses)
12:31 < jtimon> kanzure: if it's to cut down on work we can have both, that was my conclusion from a previous discussion with luke
12:31 < wumpus> can we worry about that later? I think a good first goal would be to make the libarary useful for us, I agree with sipa that tha doesn't need abstracting every data structure
12:31 < sipa> yes, abstracting the data structures can still happen later
12:31 < wumpus> I think this is typical bitcoin scope creep
12:31 < CodeShark> yes - modularization is what's most important, then we can further optimize each unit
12:31 < kanzure> sounds like an emphasis on code movement first
12:31 < jtimon> BlueMatt: mostly only to erik from libbitcoin, but yeah, probably we should ask around before trying to guess what they want
12:31 < wumpus> nothing will ever get done this way and we keep repeating the same discussions
12:32 < wumpus> +tons of huge code changes that will take ages to review
12:32 < jtimon> I want libwally to use verifyHeader, its main author has seen #8493 but I don't know what he would think about a version with "storage included"
12:33 < sipa> jtimon: one reason for me is that for some things, performance is in fact consensus critical, and requiring the user of the library to implement their own optimized data structures is essentially requiring them to implement some portion of consensus-critical code
12:33 < wumpus> I just think it'd make sense to aim for a near-term goal of exposing something, instead of trying to refactor the whole code base first
12:33 < CodeShark> the focus for now should be on separation of units and removing dependencies
12:33 < jtimon> well, all I want is to have a common and clear idea of what libconsensus should be
12:34 < sipa> while we already have optimized data structures, and not abstracting them out leaves more opportunities for future such optimizations
12:34 < wumpus> it should be a libarary that we ourselves can use for consensus validation
12:34 -!- rebroad [~rebroad@node-11cu.pool-118-173.dynamic.totbb.net] has quit [Read error: Connection timed out]     
12:34 < wumpus> sipa: exactly! *not* exposing something as part of the API leaves flexibility to improve things later
12:34 < wumpus> sipa: putting it in the API/ABI effectively sets it in stone
12:34 < jtimon> CodeShark: but then people won't "see the point" of taking consensus code out of main...
12:34 < CodeShark> ?     
12:35 < CodeShark> there
12:35 < morcos> I think it would be nice if we proceeded down _a_ path right now but left ourselves open to revisiting some of these decisions as we get further along.
12:35 < morcos> For instance I disagree a bit with the flexibility when it comes to cache optimization for pcoinstip.
12:35 < CodeShark> there's a very simple justification for it - moving the code out of main.cpp means far simpler merging of code changes
12:35 < jtimon> CodeShark: ie #8337 #8329 
12:35 < morcos> But we don't have to answer all those questions right now
12:36 < sipa> jtimon: i think everyone agrees that modularizing consensus code is a good idea, independent of whether it's exposed as a library, or has refactorings for data structures or not
12:36 < sipa> morcos: agree
12:36 < kanzure> jtimon: you are referring to friction with code separation changes? i think some of that friction can be ameliorated by having it a prioritized shared goal (like segwit was).
12:36 < CodeShark> kanzure: indeed
12:37 < jtimon> sipa: the thing is some dependencies remain "hidden" or hard to see until you separate stuff or try to move the "consensus files" to the consensus module to expose something
12:37 < sipa> jtimon: well things may not be easy
12:37 < jtimon> kanzure: I would love that
12:37 < CodeShark> let's not get hung up on how the lib API will be exposed and start working on moving code into separate units
12:38 < Chris_Stewart_5> ^     
12:38 < BlueMatt> ^     
12:38 < jeremyrubin> ^     
12:38 < sipa> v     
12:38 < jtimon> CodeShark: I'm happy with that
12:38 < jtimon> I tried that too
12:38 < Chris_Stewart_5> always one sipa..
12:38 < jtimon> but some people asked for the final API...
12:38 < sipa> i'd really just want to see a proposal of a directory structure
12:39 < kanzure> jtimon: iirc you in the past have had problems with some pull requests because others would complain about additional merge/rebase work for their unrelated changes.
12:39 < sipa> which explains code responsible for what belongs where
12:39 < jtimon> sipa: I gave you one: all consensus fles except those in crypto to the consensus dir
12:39 < sipa> jtimon: that's not an answer
12:39 < jtimon> it is one you don't like
12:39 < sipa> there is code shared between consensus and non-consensus
12:39 < sipa> what happens to script? is it split up again?
12:39 < sipa> where does the signing code go?
12:40 < jtimon> but I really don't see how can we make a subrepository or subtree out of libconsensus otherwise
12:40 < kanzure> sipa did you read jtimon's libconsensus doc by any chance
12:40 < sipa> do we duplicate consensu logic?
12:40 < jtimon> sipa: signing code is not consensus
12:40 < sipa> sigh
12:40 < sipa> i know that
12:40 < jtimon> it remains in the common package
12:40 < jtimon> and the script dir
12:40 < sipa> ok, i'll shut up about it
12:41 < wumpus> I think this is monipolizing the meeting. ANy othe topics to be discussed?
12:41 < sipa> i can't seem to get my point across
12:41 < jtimon> no, you brought this point more times
12:41 < CodeShark> can we set as a goal to prioritize some moveonly PRs?
12:41 < sipa> yes, and i have never seen you give an answer to my question
12:41 < CodeShark> sipa, jtimon, let's save that for after the meeting
12:42 < CodeShark> can we agree for the time being to define a directory structure and prioritize moveonly PRs?
12:42 < jtimon> sure I really want to understand his concerns better. It seems related to the discussion we had around luke's script "debugger"
12:42 < wumpus> I can't prioritize moveonly PRs. There's just too much happening
12:42 < CodeShark> wumpus: the idea is that they should be super simple to review
12:43 < sipa> CodeShark: you underestimate it
12:43 < michagogo> achow101: looks like it finished uploading, if you want to try it
12:43 < sipa> moving the code is easy. deciding where things belong is not.
12:43 < wumpus> but if people prioritize reviewing them, sure
12:43 < kanzure> oh is review the bottleneck? i keep thinking it's "lots of other rebase work" for other pulls.
12:43 < jtimon> wumpus: I think it being a priority for reviewers is more important
12:43 < wumpus> kanzure: that's also an issue
12:43 < sipa> kanzure: imho the bottleneck is no agreement about what should be done
12:43 < michagogo> Wait, it's Thursday... sorry, didn't realize meeting was happening
12:43  * michagogo scrolls up
12:43 < jtimon> kanzure: I strongly feel review is the bottleneck
12:44 < instagibbs_> proposed topic: rc2 issues, etc?
12:44 < wumpus> kanzure: though not always a strong one, usually it's fairly easy to rebase over pure moves. As long as people agree that they should be done.
12:44 < kanzure> oh. alright.
12:44 < jtimon> CodeShark: also I think you understimate the potential for disagreements
12:44 < Chris_Stewart_5> How do we keep this from being discussed for the next 3 meetings is my question. What can actually be done persuade people one way or the other? 
12:44 < CodeShark> can we at least agree to start discussing a directory structure? ;)
12:45 < CodeShark> (after this meeting, of course)
12:45 < jtimon> CodeShark: ACK
12:45 < wumpus> Chris_Stewart_5: you tell me
12:45 < morcos> Someone should schedule a small in-person retreat for people who really want to work on libconsensus, to make some headway
12:45 < kanzure> Chris_Stewart_5: perhaps sipa could make a proposal if we ask nicely.
12:46 < jtimon> I already buried my hopes of libconsensus becoming eventually C
12:46 < wumpus> Chris_Stewart_5: preventing the topic from being discussed is quite easy, but I think that would be seen as censorship :)
12:46 < Chris_Stewart_5> This is ALL libbconsensus right? Is tehre any concrete proposals? 
12:46 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
12:46 < instagibbs_> 14 minutes in case anyone wants to discuss anything else
12:46 < jtimon> Chris_Stewart_5: afaik the most concrete proposal right now is #8493
12:46 < wumpus> instagibbs_: I asked in the beginning, don't think there's any issues with rc2 yet
12:46 < kanzure> Chris_Stewart_5: jtimon has made a number of proposals, such as https://github.com/jtimon/consensus-doc/blob/generated/libconsensus.pdf https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013204.html
12:47 < Chris_Stewart_5> Thanks, i'll take a look at it. 
12:47 < kanzure> ah 8493 is expose verifyheader. ok.
12:47 < instagibbs_> wumpus: ok great
12:48 < CodeShark> so any other topics?
12:48 < Chris_Stewart_5> rc2 issues? 
12:48 < wumpus> which rc2 issues?
12:48 -!- ___tau___ [user@gateway/vpn/mullvad/x-bnfqqxndhqddvcxc] has joined #bitcoin-core-dev     
12:48 < BlueMatt> the lack of rc2 issues =D
12:48 < Chris_Stewart_5> *crickets*
12:48 < wumpus> 19:46 < wumpus> instagibbs_: I asked in the beginning, don't think there's any issues with rc2 yet
12:48 < kanzure> i think he was asking to hear for any
12:49 < wumpus> if there are, feel free to say so
12:49 < achow101> what about killing off windows 32 bit builds?
12:49 < jonasschnelli> I guess in 0.15
12:49 < wumpus> that's not an urgent topic really
12:49 < wumpus> yes, 0.15 I'd say too
12:49 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev     
12:50 < wumpus> I asked around and from 50 or so 'no' responses, there were two actual users admitting they were still using bitcoin core on windows 32-bit
12:50 < sipa> are there likely some who don't know?
12:50 < wumpus> they both expected this to stilll last only 6 months or so no longer
12:50 < wumpus> old hw
12:50 < gmaxwell> I haven't encountered any issues in RC2 yet, though its a bit new. The PR of mine that was merged appears to be working.
12:50 < jonasschnelli> If we have no other topic, we can discuss if we want to adjust the GUI default confirmation target down to the RPC interfaces value of 2 blocks
12:50 < wumpus> so that would time with 0.15, which is fine with me, no hurry
12:51 < Victorsueca> gmaxwell: the lastest travis build seems to have failed for master
12:51 < instagibbs_> jonasschnelli: yeah i suggested this a bit ago
12:51 < jonasschnelli> 25 blocks as "normal" confirmation speed sounds ridiculous
12:51 < achow101> jonasschnelli: I think it's a good idea
12:51 < instagibbs_> i dont understand why having different command line and GUI behavior like that is "good"
12:51 < morcos> jonasschnelli: to be honest, i actually agree we should make the target less than 25, but I think 2 is too low, and i think we're going to bikeshed where it should be
12:52 < jonasschnelli> Yes. I fear that as well. :)
12:52 < sipa> it seems reasonable that the default in gui and rpc is the same
12:52 < instagibbs_> morcos: "match between command-line and GUI" is a starting point :)
12:52 < BlueMatt> jonasschnelli: I'm for 25
12:52 < BlueMatt> 25 is good
12:52 < morcos> the issue is that when there is a break between blocks or network congestion, to be really sure you get confirmed very quickly, say in a couple of blocks
12:52 < jonasschnelli> And the slider should probably not touch nTxConfirmTarget!
12:52 < jonasschnelli> global!
12:52 < morcos> then you might have to pay areally high fee
12:52 < MarcoFalke> jonasschnelli: This should be uncontroversial. And actually it is a bug in the current code, as the default already says 25, but the slider is "mirrored", so it ends up on the wrong side.
12:52 < morcos> which is priobably not what you want
12:53 < MarcoFalke> I never fixed it because I wanted to clean it up "in a go" with all the other nasty things the gui does with the "fee"-globals
12:53 < morcos> more intelligent fee estimation would maybe gauge the current conditions against historical conditions or something.
12:53 < gmaxwell> Is anyone working on improving the estimator generally, right now?
12:53 < jonasschnelli> I think there are some users fooled by the fact that RPCs sendto* uses different fee estimations then the "default" GUI send method.
12:53 < gmaxwell> It could use improvement, though I think bumping is more important.
12:53 < jonasschnelli> I mean only different confirmations targets
12:53 < morcos> MarcoFalke: i dont think it was a bug.  i noticed it when it went in and i thought it was on purpose, i think we discussed it at a time
12:54 < MarcoFalke> ok     
12:54 < jonasschnelli> Someone should review the new bumpfee PR.
12:54 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8456
12:54 < morcos> gmaxwell: i mentioned on that issue that i had worked on it..  6-9 months ago..  but abandoned it.  i have some custom code that does a lot more
12:54 < morcos> but nothing that really got polished
12:54 < wumpus> yes, we *must* have a bumpfee for 0.14
12:54 < kanzure> morcos: had you looked at bramc's work on fee estimation?
12:55 < morcos> kanzure: i've been shying away from algorithms which require replacement.  i think its a great idea, but not how most users expect their default transactions to work.  I think most users want them to get confirmed relatively quickly on the first try.
12:55 < morcos> But an algorithm for bumping when you guess too low makes sense.
12:56 < gmaxwell> in any case, in my expirence the core estimator usually produces fees which are generally too high (compared to what gets confirmed in the next block, also compared e.g. to 21inc's estimator), having a higher confirmed target helps reduce the impact.
12:56 < morcos> so to be clear, if someone else has an idea of how it should be improved, please go ahead.  and i'm happy to help.  but its just one of those things that there is no "right" answer for so it can get frustrating
12:57 < gmaxwell> I was just wondering if there was anything ongoing at the moment.
12:57 < gmaxwell> (since the subject came up)
12:57 < jonasschnelli> What about changing the default confirmation target to 6 for RPC interface and the GUI once we have the bumpfee cmd?
12:57 < Victorsueca> as example, most of my transactions where I set the fee slider to 25 it confirmed on the next 2 blocks
12:57 < morcos> gmaxwell: yes, exactly and thats by design.  i interprested the question of what does it take to be confirmed in X blocks as meaning you really want to be very sure it'll be confirmed wihtin the target
12:57 < jonasschnelli> Victorsueca: users made different experiences with that
12:57 < gmaxwell> morcos: And that is what it must do, esp when there is no bump. :)
12:57 < morcos> thats why i hesitate to set the default to 2
12:58 < jtimon> 2 mins
12:58 < morcos> jonasschnelli: i like 6, and i'd be fine with that.... 
12:58 < instagibbs_> overpaying is fine until we have bump, heh
12:58 < gmaxwell> I would be too.
12:58 < Victorsueca> jonasschnelli: yeah, I seen too lots of people blaming slow transactions even with recommended fee, but not my case for some reason
12:58 < CodeShark> wouldn't overpaying tend to raise fees up?
12:59 < CodeShark> for everyone
12:59 < wumpus> only if everyone is going to do that
12:59 < morcos> CodeShark: ah, that is one of bramc's concerns.  i think the existing algo is pretty resistant to that
12:59 < jtimon> CodeShark: I could think of some kind of overpaying race
12:59 < jonasschnelli> Most important is probably review of mrbandrews's bumpfee (https://github.com/bitcoin/bitcoin/pull/8456)
12:59 < morcos> yes unless literally everyone does it
12:59 < MarcoFalke> We should just set it to a random value *ducks*
12:59 < instagibbs_> Assuming everyone is transacting at the same exact time, sure. But there's time preferences in real life, week/weekend patterns
12:59 < instagibbs_> etc     
12:59 < wumpus> instagibbs_: +1
12:59 < instagibbs_> bitcoin businesses will do settlement on sunday evening to avoid fees
13:00 < sipa> TINGELINGELING
13:00 < wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Oct 20 20:00:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-20-19.00.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-20-19.00.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-20-19.00.log.html
13:00 < instagibbs_> I mean they *do* today, not just hypoethical. 
13:00 < kanzure> am interested to see resolution to jtimon/sipa concerns at some point
13:00 < jonasschnelli> I think we want resolution on the long term plan since 2 years or more. :)
13:01 < jtimon> so sipa I believe I have answered your question in previous times, just maybe you didn't like it or maybe I didn't make things clear that I considered implicit or obvious or something
13:01 < sipa> jtimon: i'll write my question done in a more detailed and clear way, then
13:01 < kanzure> jtimon, perhaps illustrate with an old pull request that shows a code move that matches what you are trying to explain
13:01 < wumpus> at the least having a bumpfee feature would make it possible to correct for too low fee, that'd already help a lot, no matter how good the estimation it's going to be wrong some of the time
13:01 < instagibbs_> urgh, my 0.13.1 rc1 node has *0* segwit connections
13:01 < sipa> kanzure: NO
13:01 < sipa> kanzure: i don't want to see code
13:01 < gmaxwell> morcos: one interesting question I've pondered is that -- is that fact that the estimators are blind to the market price mean that price increases are a pressure to increase fees (in real value) for everyone? I think they are.
13:01 < morcos> wumpus: yes agree entirely
13:02 < gmaxwell> instagibbs_: yea, apply rc2 directly to forehead.
13:02 < sipa> kanzure: the code to move things is huge, but trivial
13:02 < jtimon> I believe some code duplication is unavoidable once bitcoin core only talks to libconsensus' C API, for example, the primitives
13:02 < kanzure> there was an argument proposed where instead of only making libconsensus, someone (sipa?) said libconsensus + also some other library, and bitcoin core and also libconsensus consume from the other library.
13:03 < instagibbs_> gmaxwell: yeah, a little surprising to me how unaggressive behavior was
13:03 < kanzure> (or i misunsterood a comment from a few minutes ago)
13:03 < sipa> kanzure: hmm, at this point i do not suggest creating another library
13:03 < Victorsueca> I think the fees thing would cause what I call a "cocktail effect": people are at a party and everybody has cocktails on their hand, they speak between them and that causes background noise which difficults listening to your counterparty, he speaks louder so you can listen properly, but so does everyone else making the background noise louder which forces your friend to speak even louder
13:03 < instagibbs_> Speaking of which what is the intention of having outgoing connections that can't serve you data you want at all?
13:03 < jtimon> for generic signing and script-level policy, my preference would be to expose something like luke's "debugger" since the other option seems to duplicate the code for the interpreter
13:04 < morcos> gmaxwell: hmmm...  i think what SHOULD happen is that if some people are a bit more price sensitive (in real value) that when they start paying a bit less as the price goes up, then the fee estimates ought to start edging down...
13:04 < sipa> jtimon: i'll write some things down... now lunchtime
13:04 < jtimon> sure, np
13:04 < wumpus> Victorsueca: but if many people are trying to use the system at once the fees are supposed to rise, that's fine as long as it's not an infinite feedback loop
13:05 < gmaxwell> morcos: yes. Though that control loop may be rather slow.
13:06 < Victorsueca> wumpus: that's the problem, if people offsets the fees a bit higher to be sure it confirms quickly it would cause a infinite feedback
13:06 < instagibbs_> wumpus: and I don't think that's likely as long as there exists different time preferences alone
13:06 < instagibbs_> which clearly exist
13:06 < wumpus> Victorsueca: some people would find the fee unacceptable and choose a longer confirmation period
13:07 < wumpus> not everyone cares for transactions to confirm very quickly, and wants to pay a premium for that
13:07 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 256 seconds]     
13:07 < Victorsueca> wumpus: right, I guess that force would balance the whole thing
13:07 < jtimon> kanzure: yeah a lot of this code can be easy after the discussions: not only trying different movement posibilities one by one is painful but also seems to burn reviewers really fast, maybe you take the effort to verify a moveonly commit but then someone doesn't like something about it and you're back to square one
13:08 < wumpus> jtimon: we have a problem with review everywhere, unfortunately
13:08 < CodeShark> as sipa said, deciding where the code should go is the hard part - moving it is easy
13:08 < wumpus> jtimon: after all the time we've not really managed to find morepeople that will review code changes
13:08 < jtimon> kanzure: by libconsensus++ I mean another library that calls the basic libconsensus, but it also handles storage and processes blocks
13:08 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
13:09 < wumpus> jtimon: sometimes I despair a bit
13:09 < CodeShark> the review that's needed is on the directory structure and unit definitions - the moveonly PRs are easy
13:09 < Victorsueca> CodeShark: move it all to /dev/null lol that would be easy
13:09 < jtimon> CodeShark: well, after the easy moveonlies
13:09 < Victorsueca> unfortunately the real thing is not that easy
13:10 < wumpus> jtimon: I mean there's 119 pulls open, by far most are blocked on review and testing, and sometimes about finding anyone else that cares about the change at all
13:10 < jtimon> there's little parts that you want to take, mostly from ConnectBlock
13:10 < kanzure> wumpus: so the reason why i thought the bottleneck was rebasing was because, there's this effect where lots of moves pile up and make for more rebase work, and then anyone with an open pull has an incentive to propose delaying moves until their PRs are in, hehe
13:11 < wumpus> jtimon: I have honestly no idea how to better organize this, or to find people that will help
13:11 -!- rebroad [~rebroad@node-zyj.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev     
13:11 < jtimon> wumpus: I understand, we have a big bottleneck in review in general
13:11 < CodeShark> the majority of the work that's needed here is not in writing code, though
13:11 < CodeShark> nor reviewing code
13:11 < CodeShark> it's more conceptual
13:12 < kanzure> i suppose my last message is more re: large refactors, more than it is about moves.
13:12 < wumpus> kanzure: that's certainly a dynamic that happens, large changes were delayed until after segwit to avoid giving segwit devs extra work
13:12 < CodeShark> how should we pull out different units? what are their interdependencies? how should our directory structure look?
13:12 < kanzure> wumpus: sure. yes.
13:13 < jtimon> my intuition is that we simply need more developers. at first they may be more review demanding, but later they review too
13:13 < CodeShark> we're talking design decisions here, though - not so much code
13:13 < wumpus> jtimon: we have plenty of people writing pulls, though much fewer thtat do useful review
13:13 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
13:13 < CodeShark> once we agree on the design decisions, writing and reviewing code will go much more smoothly
13:13 < wumpus> maybe we should add a rule that for every pull you submit youshould thoroughly review another one :p
13:14 < morcos> wumpus: 5
13:14 < instagibbs_> heh :) review without writing is hard though
13:14 < kanzure> wumpus: unfortunately that degrades into a quid pro quo situation
13:14 < CodeShark> but if we keep bikeshedding on design decisions while reviewing PRs it will never happen
13:14 < kanzure> or a quid pro quo review scheme or something
13:14 < jtimon> CodeShark: my thinking is this: if eventually we want libconsensus to become an independent project ala libsecp, then we need a dir for it
13:14 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
13:14 < jtimon> it can have subdirs, sure, but I'm not convinced it will need them
13:15 < CodeShark> the directory structure needn't be cast in stone - it just needs to be something that works well enough for now
13:15 < CodeShark> anything is better than stuffing everything into main.cpp :p
13:15 < Victorsueca> do you still have any of those bitcoins that where collected years ago for ad campaigns? maybe you could use them to somehow bring people into contributing
13:16 < jtimon> sorry for showing code, but this is what I would do first "for cheap": https://github.com/bitcoin/bitcoin/pull/8328
13:16 < CodeShark> once we start working on how to break out a library and expose an API perhaps we have better ideas on file system structure
13:16 < CodeShark> but that's still a ways off
13:16 < wumpus> CodeShark: re: splitting up main see https://github.com/bitcoin/bitcoin/pull/8969
13:16 < wumpus> Victorsueca: ad campaigns?!
13:16 < kanzure> Victorsueca: core itself did not run ad campaigns.....
13:17 < wumpus> Victorsueca: I can tell you the bitcoin core project has 0 bitcoins
13:17 < kanzure> wumpus: oh it's broke! :)
13:17 < jtimon> that kind of thing also forces us to discuss little things like: should utilmoneystr be in libconsensus? so far I think everyone thinks it shouldn't except maaku
13:17 < Victorsueca> I mean the thing that was collected on r/bitcoin
13:17 < kanzure> r/bitcoin is unrelated
13:17 < Victorsueca> yeah, but they engage people into giving idea on what to spend the remaining
13:17 < Victorsueca> ideas*
13:18 < MarcoFalke> What happened to the coins gavin used to give out for testing patches?
13:18 < instagibbs_> he gave them away
13:19 -!- K-ballo [~Thunderbi@181.228.43.137] has left #bitcoin-core-dev []     
13:19 < wumpus> either they were from the bitcoin foundation or Gavin paid that out of his own pocket, I don't know
13:19 < jtimon> CodeShark: I'm happy with breaking main.cpp in smaller pieces, maybe get git blame to work with it some day, but I don't think "block connection logic" belongs in libconsensus
13:20 < CodeShark> I'm not even thinking libconsensus yet :p
13:20 < jtimon> ok, BlueMatt, let's say I'm an SPV wallet that only wants to use libbitcoin for verifyScript, verifyHeader and getConsensusFlags
13:21 < jtimon> how does verifyHeader gets the block if I'm never calling libconsensus' processBlock? I just have headers and txs, never full blocks
13:21 < sipa> if you have a blockheaderstore you can provide it with the headers
13:22 < jtimon> I see
13:22 < BlueMatt> jtimon: you can do processheader
13:22 < BlueMatt> which i guess is what sipa said
13:22 < jtimon> yeah, both options are equivalent, yeah, you could do that
13:22 < sipa> right... though i wouldn't mind having a way to just verify a header without processing it
13:22 < sipa> just a different level api
13:23 < sipa> but you'll still need a way to load headers into the black box state object in that case, independently from processheader
13:23 < sipa> which you may need anyway... when loading your header index from disk, perhaps feeding them to processheader one by one is not necessarily the best approach
13:27 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
13:27 < jtimon> why can't this black box object be just an implementation of the function pointers API? that was we can offer both tastes for every storage-dependenant call
13:31 < jtimon> anyway, rewarding dir struct, I'm happy to hear any other ideas besides my simplistic "everything required to validate consensus rules in the consensus dir"
13:33 < Victorsueca> jtimon: maybe inside the consensus dir make a subdir for those required to validate the consensus rules that where there since the beginning
13:33 < jtimon> it feels bad to break the script dir in 2, but I don't feel bad about moving the primitives, for example
13:34 < Victorsueca> then another subdir for those required to validate some BIP-specific rules
13:34 < jtimon> Victorsueca: that's most of them, I think handling deployments with flags is just fine
13:34 < Victorsueca> hmmm
13:36 < jtimon> currently most functions are about validating some rules for a given structure (ie script, tx, header, block), separating stuff per bip would be less clear and maintainable IMO
13:37 < Victorsueca> maybe a subdir for network consensus (such as median time, consensus height, handshakes...) another for transaction validation consensus, another for block validation consensus, another for soft-fork consensus....
13:38 < Victorsueca> I think I just duped libraries on different subdirs right?
13:40 < Victorsueca> we should also consider if a library would fit on more than one subdir then on which one would be more intuitive to find it
13:40 < jtimon> well, some of that stuff is already separated as files
13:41 < jtimon> for others that isn't I think a single file is probably fine
13:42 < jtimon> anyway, I'll go back to try to find what's wrong with my new testchain...
13:42 < Victorsueca> then I think we should put everything in the consensus folder, if there's not much to classify splitting stuff would only make things more unclear
13:44 < jtimon> maybe a script subfolder, but it would be just script.o, interpreter.o and script_error (which maybe should just turn into consensus_error)
13:48 -!- rebroad [~rebroad@node-zyj.pool-118-173.dynamic.totbb.net] has quit [Read error: Connection timed out]     
13:55 -!- jujumax [~jujumax@200.117.99.162] has quit [Remote host closed the connection]     
14:03 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has left #bitcoin-core-dev []     
14:09 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
14:12 < achow101> michagogo: what's the password for bob with your vm?
14:13 < Lightsword> hmm, my testnet node is stuck
14:14 < Lightsword> GBT won’t start since it’s stuck on downloading blocks
14:16 < achow101> michagogo: also, is build.sh your build script?
14:26 -!- rebroad [~rebroad@node-zyj.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev     
14:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jnshpgiqmjkysqxz] has quit [Quit: Connection closed for inactivity]     
14:27 -!- cdecker [~quassel@2a02:aa16:1105:4a80:183c:ad5:f656:aa73] has joined #bitcoin-core-dev     
14:37 -!- rebroad [~rebroad@node-zyj.pool-118-173.dynamic.totbb.net] has quit [Ping timeout: 252 seconds]     
15:01 < michagogo> achow101: It's gitian
15:01 < michagogo> (that's in the description, too)
15:01 < michagogo> And yeah, that's the script I use for building
15:01 < michagogo> It requires a bit of customization (basically, add your name)
15:02 < michagogo> It does the whole build process
15:03 < michagogo> Run it, and it takes care of fetching the tag you give it, building, committing, pushing, and even creating the PR
15:03 < michagogo> (that last part also requires you to create a GitHub token)
15:06 -!- rebroad [~rebroad@node-zyj.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev     
15:12 -!- rebroad [~rebroad@node-zyj.pool-118-173.dynamic.totbb.net] has quit [Ping timeout: 244 seconds]     
15:15 -!- cbit [~Camar@2607:f380:a61:650:942c:9846:af98:857a] has joined #bitcoin-core-dev     
15:19 -!- cbit [~Camar@2607:f380:a61:650:942c:9846:af98:857a] has quit [Ping timeout: 256 seconds]     
15:22 < michagogo> Lauda: ICYMI, my prepackaged gitian builder VM is up at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
15:22 < michagogo> Along with a video showing how I made it, start to finish
15:22 < michagogo> (1 hour, from initial boot from Ubuntu 14.04.5 ISO, including trial and error)
15:22 < michagogo> (and looking stuff up outside the VM)
15:23 < michagogo> achow101: Did you get a chance to try it? Did it work for you?
15:25 < michagogo> And also, I've got to say... having just set it up from scratch, I really don't understand how/why people have trouble with it :-/
15:27 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
15:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
15:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
15:34 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]     
15:34 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
15:45 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Quit: e4xit]     
15:48 -!- cdecker [~quassel@2a02:aa16:1105:4a80:183c:ad5:f656:aa73] has quit [Ping timeout: 250 seconds]     
15:51 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
15:51 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
15:52 < molz> michagogo, can't see the file, have to have a MS account
15:53 < michagogo> molz: Really?
15:53 < michagogo> Hm.     
15:53 < michagogo> I seem to be able to open it in incognito...
15:53 < michagogo> Oh, hmm.
15:54 < molz> oh  i can download it
15:54 < michagogo> Okay, do you have a better way for me to get it to you?
15:56 < michagogo> Maybe I'll make a torrent of it -- does someone have a seedbox that can take ~3.6 GB?
16:05 < molz> michagogo, i'm downloading Gitianbuilder.7z 
16:08 < michagogo> Ah, it's working? Great
16:39 < molz> michagogo, sorry i was afk, but no, i got "network error", can't download Gititanbuilder.7z
16:57 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]     
16:59 -!- alpalp [~allen@2605:6000:f4d6:d600::3] has joined #bitcoin-core-dev     
16:59 -!- alpalp [~allen@2605:6000:f4d6:d600::3] has quit [Changing host]     
16:59 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:05 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
17:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
17:14 -!- andytoshi is now known as grindeltoshi     
17:38 < achow101> michagogo: interesting. My script (the on that is in contrib/) doesn't work. But yours does. Now I need to find what the difference is, because mine does a whole lot more stuff
17:39 -!- so [~so@unaffiliated/so] has quit [Quit: ...]     
17:49 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
17:50 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
17:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
18:17 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
18:20 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has joined #bitcoin-core-dev     
18:20 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Changing host]     
18:20 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
18:34 < luke-jr> sigs pushed for rc2
18:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
18:44 < achow101> michagogo: I got it to work with my script (had to make a few tweaks). Thanks for making the vm image. Maybe part of the issue I have with setting up lxc on my computer is that I use Ubuntu 16.04 instead of 14.04
18:50 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
19:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
19:16 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
19:27 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
19:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
19:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:34 -!- harrymm [~wayne@104.222.140.40] has quit [Remote host closed the connection]     
19:35 -!- harrymm [~wayne@104.222.140.93] has joined #bitcoin-core-dev     
19:38 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
19:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
19:48 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
20:03 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
20:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:10 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
20:25 < luke-jr> https://lwn.net/Articles/704078/ local exploit in all released Linux kernels
20:27 < luke-jr> "An exploit using this technique has been found in the wild."
20:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 265 seconds]     
20:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
20:43 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 265 seconds]     
20:59 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
21:02 < jl2012> is there any way to generate the same block hash every time running regtest?
21:05 < luke-jr> jl2012: by giving it the same blocks?
21:07 -!- roconnor [~roconnor@host-45-58-213-81.dyn.295.ca] has joined #bitcoin-core-dev     
21:08 < jl2012> so i can't generate blocks with the RPC generate command?
21:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:09 < luke-jr> nothing stopping you, but there's no reason to expect that to be deterministic
21:10 < luke-jr> might work if you set a mock time.. maybe
21:10 < jl2012> it'd be nice if it has a detministicgenerate command. Given the same condition, it always returns the same block hash
21:10 < luke-jr> but the conditions are never the same (timestamp)
21:11 < luke-jr> it's not like compiling where it's just a random timestamp being added, the timestamp actually has a role in the blockchain :p
21:12 < jl2012> that could be deterministic too, e.g. just make it always 600s apart
21:12 < luke-jr> seems like it'd defeat the purpose
21:13 < jl2012> sometimes, you want to faithfually repeat the process
21:13 < luke-jr> so try setting a mock time..
21:14 < jl2012> also setting the same pubkey for reward, I guess?
21:14 < luke-jr> or just load a set deterministic wallet ;)
21:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
21:19 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-gnofhwxdjxtqwvlb] has joined #bitcoin-core-dev     
21:23 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:26 < jl2012> thanks
21:36 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:45 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:46 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:01 -!- roconnor [~roconnor@host-45-58-213-81.dyn.295.ca] has quit [Ping timeout: 260 seconds]     
22:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
22:16 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
22:20 -!- ___tau___ [user@gateway/vpn/mullvad/x-bnfqqxndhqddvcxc] has quit [Ping timeout: 260 seconds]     
22:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:34 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 258 seconds]     
22:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
22:44 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
22:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:50 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev     
23:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:11 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]     
23:31 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-gnofhwxdjxtqwvlb] has quit [Quit: Connection closed for inactivity]     
23:36 -!- niska [~niska@68.ip-149-56-14.net] has quit [Ping timeout: 248 seconds]     
23:36 -!- PatBoy [xyz@192.99.249.194] has quit [Ping timeout: 248 seconds]     
23:36 -!- PatBoy [xyz@192.99.249.194] has joined #bitcoin-core-dev     
23:36 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev