1 2016-10-20 01:32:12	0|wumpus|"graphics acceleration at 9.81 m/s^2" hahahah genius
   2 2016-10-20 01:33:40	0|sipa|wumpus: based on an old linux joke "the best windows accelerator is one that works at 9.81 m/s^2"
   3 2016-10-20 01:33:45	0|sipa|also, why are you awake?
   4 2016-10-20 01:34:05	0|sipa|i have an excuse, it's 6:30 pm here.
   5 2016-10-20 01:35:12	0|wumpus|I have no excuse
   6 2016-10-20 01:35:27	0|wumpus|it's eh 03:35 here :D
   7 2016-10-20 01:44:55	0|wumpus|the freebsd issue on stack exchange is weird, my gut feeling is that it has something to do with locale settings but I saw nothing of the kind at least with 0.13
   8 2016-10-20 03:01:10	0|wumpus|rc2 executables up https://bitcoin.org/bin/bitcoin-core-0.13.1/test.rc2/
   9 2016-10-20 03:01:39	0|achow101|Did the release email go out?
  10 2016-10-20 03:01:45	0|wumpus|no
  11 2016-10-20 03:02:16	0|achow101|ok. Shouldn't you be asleep?
  12 2016-10-20 03:02:31	0|wumpus|could announce the rc on mailng list, but an rc does not warrant a 'release email'
  13 2016-10-20 03:03:28	0|wumpus|this is only a test, not a release yet
  14 2016-10-20 03:04:00	0|achow101|i meant like the email saying that the rc exists.
  15 2016-10-20 03:04:02	0|achow101|like https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-August/000017.html
  16 2016-10-20 03:04:43	0|wumpus|yea, will send one, but I thought peopel here may be interested in it as well and it's easier to paste an url
  17 2016-10-20 03:05:12	0|achow101|oh ok
  18 2016-10-20 03:08:08	0|wumpus|good time to sneak out a rc2 mail though while the US is distracted with their clown show :)
  19 2016-10-20 05:31:57	0|NicolasDorier|passing flag CLEAN_STACK to libconsensus seems to make crash the whole process.
  20 2016-10-20 05:33:12	0|NicolasDorier|somehow https://github.com/bitcoin/bitcoin/blob/v0.13.1rc2/src/test/data/script_tests.json#L1831
  21 2016-10-20 05:33:15	0|NicolasDorier|now crash
  22 2016-10-20 05:33:21	0|NicolasDorier|when using libconsensus
  23 2016-10-20 05:33:36	0|NicolasDorier|trying to deep what it going on
  24 2016-10-20 05:33:41	0|NicolasDorier|dig
  25 2016-10-20 05:34:52	0|wumpus|strange
  26 2016-10-20 05:35:01	0|wumpus|on master or 0.13.1?
  27 2016-10-20 05:35:11	0|jl2012|does libconsensus has CLEANSTACK flag?
  28 2016-10-20 05:35:13	0|NicolasDorier|downloaded libconsensus from https://bitcoin.org/bin/bitcoin-core-0.13.1/test.rc2/
  29 2016-10-20 05:35:32	0|jl2012|i thought it only has consensus critical flags?
  30 2016-10-20 05:36:03	0|NicolasDorier|jl2012: was working before, and the flags in libconsensus are not reallyused, the flags is coverted into a SCRIPT_VERIFY flag without check
  31 2016-10-20 05:36:05	0|wumpus|no, it doesn't
  32 2016-10-20 05:36:31	0|wumpus|https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h#L50
  33 2016-10-20 05:36:45	0|wumpus|that doesn't crashing is a valid outcome ofcourse
  34 2016-10-20 05:37:11	0|NicolasDorier|and it is not the cause https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.cpp#L88
  35 2016-10-20 05:37:14	0|jl2012|using CLEANSTACK without WITNESS would fail assertion?
  36 2016-10-20 05:37:20	0|NicolasDorier|the flags is converted into SCRIPT_VERIFY
  37 2016-10-20 05:37:26	0|NicolasDorier|not really using the libconsensus flags at all
  38 2016-10-20 05:39:00	0|wumpus|can you post a traceback?
  39 2016-10-20 05:39:46	0|jl2012|https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1505
  40 2016-10-20 05:40:35	0|NicolasDorier|I'm checking if it is not my binding code between C# and C++ which is at fault... But it would be strange as the previous version was working nice. wumpus : how can I do a traceback on windows ? I may be able to use windbg, but not sure if the output of it would be of big use
  41 2016-10-20 05:41:17	0|wumpus|don't ask me how to do debugging on windows :)
  42 2016-10-20 05:41:37	0|jl2012|NicolasDorier: what would happen if you add a WITNESS flag to the test?
  43 2016-10-20 05:41:48	0|NicolasDorier|trying that
  44 2016-10-20 05:41:51	0|NicolasDorier|one sec
  45 2016-10-20 05:43:00	0|NicolasDorier|jl2012: with the flag, no crash
  46 2016-10-20 05:43:55	0|jl2012|so that's the reason
  47 2016-10-20 05:44:18	0|NicolasDorier|yep, can reproduce crash if P2SH|CLEANSTACK not with P2SH|WITNESS|CLEANSTACK... why did the bitcoin C++ test worked fine ?
  48 2016-10-20 05:44:36	0|jl2012|sipa: we should add WITNESS flag to all tests with CLEANSTACK
  49 2016-10-20 05:44:49	0|jl2012|NicolasDorier: I'm also wondering the same
  50 2016-10-20 05:45:16	0|jl2012|maybe it failed before the assertion at L1505 is triggered
  51 2016-10-20 05:45:49	0|NicolasDorier|yeah, and why did it not failed before when using libconsensus OO
  52 2016-10-20 05:45:52	0|NicolasDorier|checking
  53 2016-10-20 05:46:58	0|jl2012|to fix it, search all tests with CLEANSTACK. They should all have P2SH and WITNESS
  54 2016-10-20 05:47:08	0|jl2012|also, all tests with WITNESS must have P2SH
  55 2016-10-20 05:47:40	0|NicolasDorier|jl2012: I'm step by stepping my C# code, and I confirm that this test should pass through those asserts
  56 2016-10-20 05:48:07	0|jl2012|with all 3 flags?
  57 2016-10-20 05:48:36	0|NicolasDorier|with 2 flags. So the assert is the cause of the crash, but why it did not crashed on C++ tests really bother me
  58 2016-10-20 05:49:50	0|wumpus|yes, that is really strange
  59 2016-10-20 05:52:05	0|NicolasDorier|jl2012: also I don't understand why WITNESS should be set at all cost if CLEANSTACK is set
  60 2016-10-20 05:53:23	0|NicolasDorier|I think adding WITNESS to all CLEANSTACK test is the wrong way
  61 2016-10-20 05:53:36	0|NicolasDorier|CLEANSTACK | P2SH should not fail
  62 2016-10-20 05:54:03	0|wumpus|well the P2SH rationale is explained
  63 2016-10-20 05:54:10	0|wumpus|"Disallow CLEANSTACK without P2SH, as otherwise a switch CLEANSTACK->P2SH+CLEANSTACK would be possible, which is not a softfork (and P2SH should be one)."
  64 2016-10-20 05:54:18	0|wumpus|don't know about WITNESS
  65 2016-10-20 05:54:23	0|NicolasDorier|yes for P2SH not a problem
  66 2016-10-20 05:56:15	0|wumpus|NicolasDorier: it's adding the flags in the tes https://github.com/bitcoin/bitcoin/blob/master/src/test/script_tests.cpp#L163
  67 2016-10-20 05:56:42	0|jl2012|Witness script is violation of cleanstack
  68 2016-10-20 05:57:36	0|NicolasDorier|wumpus: oh thanks
  69 2016-10-20 05:57:40	0|wumpus|that explains why the C++ tests do pass, updating the tests would have been clearer.
  70 2016-10-20 05:58:00	0|NicolasDorier|I still think that CLEANSTACK | P2SH should not crash
  71 2016-10-20 05:58:10	0|NicolasDorier|even without this test change
  72 2016-10-20 05:59:21	0|jl2012|It's only a problem if we had a cleanstack softfork before witness
  73 2016-10-20 06:01:01	0|NicolasDorier|jl2012: What I mean is that segwit should not break something that was working before, if it is not activated... Users of libconsensus were passing P2SH | CLEANSTACK
  74 2016-10-20 06:01:14	0|NicolasDorier|now, if they just update the library, their code will crash
  75 2016-10-20 06:01:41	0|NicolasDorier|even if witness is not activated
  76 2016-10-20 06:02:48	0|jl2012|Then we need to remove that assert
  77 2016-10-20 06:03:42	0|NicolasDorier|I think we should yes
  78 2016-10-20 06:03:42	0|wumpus|but CLEANSTACK isn't even part of the libconsensus API
  79 2016-10-20 06:04:05	0|wumpus|you've been relying on undocumented behavior, that can change from release to release
  80 2016-10-20 06:04:30	0|NicolasDorier|mh good point
  81 2016-10-20 06:04:44	0|wumpus|I don't think crashing with an assert is any good way of error handling , but still
  82 2016-10-20 06:05:50	0|wumpus|the asserts are there to prevent bugs, e.g. "this combination of flags should not be used", and through libconsensus it shouldn't even be possible to pass them. Possibly libconsensus should do better input checking on the flag bits.
  83 2016-10-20 06:06:56	0|wumpus|I'm not against removing the asserts if it doesn't actually protect against something dangerous, but the rationale in the comment seems pretty grave
  84 2016-10-20 06:08:01	0|NicolasDorier|I would prefer removing the assert so we don't break code that were using this undoc API if not dangerous. But if we keep it, a comment about it would be very useful
  85 2016-10-20 06:09:12	0|wumpus|one of the arguments against doing libconsensus in the first place was this - as the API is set in stone, it makes us less flexible to change things. Doubly so if even undocumented behavior is considered.
  86 2016-10-20 06:10:20	0|wumpus|guaranteeing one bug-for-bug compatible interface (the consensus itself) ought to be enough of a challenge
  87 2016-10-20 06:10:47	0|NicolasDorier|I agree. But the alternative (making an alt implementation) is even more dangerous I think. One way to fix the problem would be to add a "flags = flags & CONSENSUS_FLAGS"
  88 2016-10-20 06:11:04	0|wumpus|but why do you really need this?
  89 2016-10-20 06:11:43	0|NicolasDorier|if the user passed non consensus flags (like I already did), then the function would just strip the non consensus bits instead of crashing
  90 2016-10-20 06:11:44	0|wumpus|yes I think the call should fail (with an error code, not an assertion) when unrecognized bits are passed in
  91 2016-10-20 06:13:04	0|NicolasDorier|we can do that, I'm still a bit worried as I think lots of people passed SCRIPT_VERIFY_STANDARD to this call.
  92 2016-10-20 06:13:04	0|wumpus|just ANDing them out can be risky too. There is no guarantee that the bits will aways map one to one to internal script verification bits
  93 2016-10-20 06:13:39	0|NicolasDorier|yes I understand. So might be good to do it now before libconsensus is too much use
  94 2016-10-20 06:13:42	0|wumpus|may warrant mentioniong in the release notes then
  95 2016-10-20 06:13:43	0|NicolasDorier|is not
  96 2016-10-20 06:29:19	0|wumpus|ugh, even our own tests make use of this undocumented API
  97 2016-10-20 06:35:59	0|GitHub0|[13bitcoin] 15laanwj opened pull request #8976: libconsensus: Add input validation of flags (06master...062016_10_bitcoinconsensus_input_checking) 02https://github.com/bitcoin/bitcoin/pull/8976
  98 2016-10-20 06:56:30	0|wumpus|NicolasDorier: I'm not entirely convinced of #8976 yet, at the least because it can't pass the combinations required to pass our own tests right now, but I hope it will start a discussion about what we really want the behavior to be here
  99 2016-10-20 06:57:43	0|NicolasDorier|wumpus: We can also expose the whole SCRIPT_VERIFY to libconsensus (it is ok, as I doubt this will ever change)
 100 2016-10-20 06:58:22	0|NicolasDorier|I'm kind of neutral, I think we can break the API and reject wrong flags, libconsensus is not too much used yet for doing that.
 101 2016-10-20 06:58:24	0|wumpus|yes, though I remember back in the day when libconsensus API was drafted there were reasons not to do so
 102 2016-10-20 06:58:52	0|wumpus|I think the point is that only consensus flags are offered, the rest is kind of arbitrary
 103 2016-10-20 06:59:05	0|wumpus|but uhm, we'd have to change our approach to testing at least then
 104 2016-10-20 06:59:54	0|NicolasDorier|yeah, it also make sense. The base of the problem being that the script evaluator has policy AND consensus code :D
 105 2016-10-20 07:00:44	0|wumpus|I hope that will be separated in the future
 106 2016-10-20 07:02:12	0|wumpus|and maybe add a libbitcoin_policy for the other things :-)
 107 2016-10-20 07:04:58	0|GitHub91|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c5875773561c...f2d705629b51
 108 2016-10-20 07:04:59	0|GitHub91|13bitcoin/06master 14215caba 15Pedro Branco: Add consistency check to RPC call importmulti
 109 2016-10-20 07:04:59	0|GitHub91|13bitcoin/06master 14cb08fdb 15Pedro Branco: Add importmulti rpc call
 110 2016-10-20 07:05:00	0|GitHub91|13bitcoin/06master 14f2d7056 15Wladimir J. van der Laan: Merge #7551: Add importmulti RPC call...
 111 2016-10-20 07:05:03	0|GitHub161|[13bitcoin] 15laanwj closed pull request #7551: Add importmulti RPC call (06master...06feature/rpc-import-multi) 02https://github.com/bitcoin/bitcoin/pull/7551
 112 2016-10-20 07:27:55	0|GitHub117|[13bitcoin] 15jonasschnelli opened pull request #8977: [Wallet] Refactor wallet/init interaction (Reaccept wtx, flush thread) (06master...062016/10/fix_wallet_init) 02https://github.com/bitcoin/bitcoin/pull/8977
 113 2016-10-20 08:02:06	0|GitHub145|[13bitcoin] 15jonasschnelli closed pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (06master...062016/09/hd_flex) 02https://github.com/bitcoin/bitcoin/pull/8723
 114 2016-10-20 08:03:11	0|GitHub86|[13bitcoin] 15jonasschnelli reopened pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (06master...062016/09/hd_flex) 02https://github.com/bitcoin/bitcoin/pull/8723
 115 2016-10-20 08:31:36	0|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
 116 2016-10-20 08:32:20	0|wumpus|jonasschnelli: maybe release binaries
 117 2016-10-20 08:32:30	0|wumpus|usually that's more effective to get GUI stuff tested
 118 2016-10-20 08:33:00	0|jonasschnelli|wumpus: 8501 is non GUI RPC only... the GUI diff is large because of the flexible core stats collector.
 119 2016-10-20 08:33:17	0|wumpus|ohh
 120 2016-10-20 08:33:18	0|jonasschnelli|I don't want to scarify the flexible design to keep the GUI diff low. :)
 121 2016-10-20 08:33:54	0|wumpus|bah I'll retest #8959
 122 2016-10-20 08:33:55	0|jonasschnelli|Parts of the statics collector could probably be reused for sipas idea of evicting misbehave score
 123 2016-10-20 08:34:14	0|jonasschnelli|8959 is strange...
 124 2016-10-20 08:34:22	0|jonasschnelli|Maybe a Qt bug
 125 2016-10-20 08:34:23	0|wumpus|seems to work for me
 126 2016-10-20 08:34:36	0|jonasschnelli|Could be a QT-OSX bug
 127 2016-10-20 08:39:07	0|jonasschnelli|i'll test again
 128 2016-10-20 08:40:03	0|wumpus|either that or macosx's triangles are y-axis-reversed :-)
 129 2016-10-20 08:42:44	0|jonasschnelli|wumpus: looks like. :) I guess is a Qt bug
 130 2016-10-20 08:42:51	0|jonasschnelli|*it's
 131 2016-10-20 08:43:09	0|wumpus|turning the pyramid upside down
 132 2016-10-20 08:43:14	0|jonasschnelli|we could add something in platformstyles... *duck*
 133 2016-10-20 08:43:14	0|wumpus|do we have sorting triangles anywhere else?
 134 2016-10-20 08:43:20	0|jonasschnelli|yes. TX table
 135 2016-10-20 08:43:29	0|wumpus|are they reversed too?
 136 2016-10-20 08:43:36	0|jonasschnelli|let me check
 137 2016-10-20 08:43:53	0|jonasschnelli|Correct there for me
 138 2016-10-20 08:44:01	0|jonasschnelli|wumpus: can you check on Ubuntu?
 139 2016-10-20 08:44:26	0|wumpus|yes
 140 2016-10-20 08:44:38	0|jonasschnelli|Hmm... so its a bug in our codebase
 141 2016-10-20 08:45:28	0|wumpus|huh. The tx one on ubuntu is: up-pointing pyramid is descending, down-pointing pyramid is ascending
 142 2016-10-20 08:46:54	0|jonasschnelli|So at least the "bug" behavior is identical.
 143 2016-10-20 08:47:00	0|jonasschnelli|IMO its an upstream Qt bug
 144 2016-10-20 08:47:00	0|wumpus|tried with balance. same for date. up=most recent date first, down=oldest date first
 145 2016-10-20 08:47:21	0|wumpus|I don't know anymore, I've lost perspective how it is supposed to be. Should try some other qt app maybe
 146 2016-10-20 08:48:02	0|wumpus|reverted my ACK
 147 2016-10-20 08:48:08	0|jonasschnelli|If its the opposite direction on OSX its certainly an upstream issue. I don't think platforms have a different sort-pyramid-direction... :)
 148 2016-10-20 08:48:57	0|wumpus|in principle the validity of #8959 is based on one thing: does order == Qt::DescendingOrder really sort descending?
 149 2016-10-20 08:49:29	0|wumpus|we should inspect the sorted list insome other way
 150 2016-10-20 08:49:38	0|wumpus|along with the input to the operator
 151 2016-10-20 09:06:45	0|wumpus|jonasschnelli: ok, so the original code was correct
 152 2016-10-20 09:07:02	0|wumpus|the arrow behavior is strange, but should not be corrected by changing the sorting code
 153 2016-10-20 09:07:38	0|jonasschnelli|wumpus: look like, but with the original code, i get a strange initial state
 154 2016-10-20 09:07:45	0|jonasschnelli|First click results in only changing the arrow. :)
 155 2016-10-20 09:08:03	0|wumpus|it looks like initially the thing is not sorted at all
 156 2016-10-20 09:08:04	0|jonasschnelli|dam those little GUI glitches
 157 2016-10-20 09:08:24	0|wumpus|it only ends up in that sorting function *after* clicking the column the first time
 158 2016-10-20 09:08:27	0|jonasschnelli|Ah. That could be.. so it takes the default arrow direction which could be different
 159 2016-10-20 09:11:43	0|michagogo|I wonder if my attempt to make a gitian-building vbox appliance will work, or crash and burn.
 160 2016-10-20 09:18:20	0|jonasschnelli|michagogo: isn't the idea that everyone should setup it's own VM (security)?
 161 2016-10-20 09:19:58	0|wumpus|well if everyone would start using michagogo's image that would be a problem
 162 2016-10-20 09:21:25	0|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
 163 2016-10-20 09:21:52	0|jonasschnelli|michagogo: Yes. I think its generally a good idea and it might lead to better docs as well.. :)
 164 2016-10-20 09:22:00	0|michagogo|Since so many people seem to have trouble with it, while I have a working setup...
 165 2016-10-20 09:22:12	0|jonasschnelli|though, wumpus did create an awesome gitian doc
 166 2016-10-20 09:22:25	0|michagogo|People say it doesn't work :-(
 167 2016-10-20 09:22:50	0|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
 168 2016-10-20 09:22:54	0|jonasschnelli|Yes. Maybe we should provide a non LXC version
 169 2016-10-20 09:23:19	0|michagogo|i.e. if the only reason it works for me is that I already have the environment set up
 170 2016-10-20 09:23:33	0|michagogo|Maybe I'll turn on VBox's video recording feature
 171 2016-10-20 09:23:36	0|jonasschnelli|heh... I guess same here. :)
 172 2016-10-20 09:24:24	0|jonasschnelli|michagogo: you could turn your working system into an appliance (including your bitcoin private keys)
 173 2016-10-20 09:24:38	0|michagogo|jonasschnelli: actually, someone asked for that first
 174 2016-10-20 09:24:53	0|michagogo|But yeah, not gonna do that
 175 2016-10-20 09:25:01	0|jonasschnelli|yes. better not
 176 2016-10-20 09:25:27	0|michagogo|No Bitcoin private keys in there, but gpg, probably ssh, and also token for github, chrome, etc.
 177 2016-10-20 09:26:04	0|michagogo|(I use the VM whenever I want to do/try something in Linux, not just for gitian)
 178 2016-10-20 09:48:08	0|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
 179 2016-10-20 09:50:26	0|Victorsueca|morning
 180 2016-10-20 09:58:40	0|wumpus|morning
 181 2016-10-20 09:59:01	0|btcdrak|wumpus: achow101 script work great with --kvm
 182 2016-10-20 09:59:34	0|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
 183 2016-10-20 09:59:51	0|wumpus|if not a relevant problem anymore we could just switch the guide to KVM
 184 2016-10-20 10:00:00	0|Victorsueca|windows update force-restarted my computer last night while I was sleeping :/
 185 2016-10-20 10:01:44	0|rabidus_|new spyware installed
 186 2016-10-20 10:01:57	0|luke-jr|wee, master no longer builds
 187 2016-10-20 10:02:25	0|luke-jr|guess importmulti wasn't ready :<
 188 2016-10-20 10:02:32	0|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>}’)
 189 2016-10-20 10:02:52	0|michagogo|wumpus: I assume it's still an issue... nested virtualization is hard
 190 2016-10-20 10:03:12	0|michagogo|But I do think anyone who's able should use KVM... AFAIK it tends to work much, much better
 191 2016-10-20 10:05:19	0|michagogo|Hm, should I try making this with the Ubuntu Server ISO?
 192 2016-10-20 10:05:33	0|luke-jr|does this actually compile for anyone? it looks like boost::variant *intentionally* omits operator!=
 193 2016-10-20 10:07:43	0|wumpus|does what actually compile for anyone?
 194 2016-10-20 10:08:53	0|luke-jr|wumpus: importmulti or master
 195 2016-10-20 10:09:39	0|wumpus|yes - it passes travis and builds here locally
 196 2016-10-20 10:09:43	0|luke-jr|:/
 197 2016-10-20 10:09:58	0|luke-jr|how is CTxDestination.Get() != CTxDestination.Get() working?
 198 2016-10-20 10:12:46	0|Victorsueca|Will try compiling master here
 199 2016-10-20 10:13:16	0|wumpus|the intention would be to compare whether the two destinations are the same
 200 2016-10-20 10:16:56	0|wumpus|I think the importmulti code could be cleaned up quite a bit
 201 2016-10-20 10:17:04	0|luke-jr|hm, looks like boost added it in some newer version
 202 2016-10-20 10:18:48	0|wumpus|looks like the variant comparison is mostly used for "consistency checks"
 203 2016-10-20 10:19:08	0|GitHub145|[13bitcoin] 15luke-jr opened pull request #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (06master...06compat_importmulti_oldboost) 02https://github.com/bitcoin/bitcoin/pull/8980
 204 2016-10-20 10:19:46	0|luke-jr|!(a==b) works
 205 2016-10-20 10:19:47	0|gribble|Error: "(a==b)" is not a valid command.
 206 2016-10-20 10:19:58	0|wumpus|that's crazy
 207 2016-10-20 10:20:03	0|sipa|gribble disagrees
 208 2016-10-20 10:20:05	0|luke-jr|heh
 209 2016-10-20 10:20:12	0|Victorsueca|lol
 210 2016-10-20 10:20:41	0|wumpus|hahahah
 211 2016-10-20 10:21:11	0|luke-jr|why does C++ make it possible to have a==b && a!=b ? :p
 212 2016-10-20 10:22:15	0|wumpus|I think most/all languages with overloaded operators allow that
 213 2016-10-20 10:23:46	0|luke-jr|I knew Perl did, but I figured that was because it was Perl ;x
 214 2016-10-20 10:24:32	0|wumpus|same with > versus <=  and < versus >=. I think there's even legitimate cases for that, e.g. NaNs
 215 2016-10-20 10:28:45	0|GitHub49|13bitcoin/060.13 145f6b312 15Wladimir J. van der Laan: doc: Add missing credit to release notes...
 216 2016-10-20 10:28:45	0|GitHub49|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/5f6b312e51dadaf40ea68c0f85bbb4e51fa987f1
 217 2016-10-20 10:31:40	0|sipa|wumpus: from 0.13 release notes: "This is a new majir versiob release"
 218 2016-10-20 10:31:45	0|sipa|*major
 219 2016-10-20 10:35:27	0|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?
 220 2016-10-20 10:35:29	0|GitHub87|[13bitcoin] 15paveljanik opened pull request #8981: Wshadow: Do not shadow argument with a local variable (06master...0620161020_Wshadow_rpcdump) 02https://github.com/bitcoin/bitcoin/pull/8981
 221 2016-10-20 10:35:44	0|wumpus|yes, the 0.13 release notes definitely need some updating still
 222 2016-10-20 10:38:51	0|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?
 223 2016-10-20 10:39:42	0|Victorsueca|NULLDUMMY?
 224 2016-10-20 10:39:55	0|Victorsueca|wut
 225 2016-10-20 10:40:04	0|sipa|Victorsueca: bip147
 226 2016-10-20 10:40:13	0|GitHub48|[13bitcoin] 15s-matthew-english opened pull request #8982: Eliminating Inconsistencies in Textual Output (06master...06patch-6) 02https://github.com/bitcoin/bitcoin/pull/8982
 227 2016-10-20 10:40:15	0|michagogo|Hm, actually
 228 2016-10-20 10:40:19	0|sipa|i wonder if release notes shouldn't be written and tracked in a separate repository
 229 2016-10-20 10:40:23	0|michagogo|Do we call it two soft-forks?
 230 2016-10-20 10:40:35	0|michagogo|Maybe it's more accurate to drop the s
 231 2016-10-20 10:40:37	0|wumpus|michagogo: no, it should be called one, I think mentioning only segwit would be fine
 232 2016-10-20 10:40:46	0|michagogo|since it's one softfork, with two components
 233 2016-10-20 10:41:44	0|Victorsueca|maybe it would be better if we named bip147 something other than nulldummy
 234 2016-10-20 10:41:54	0|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
 235 2016-10-20 10:42:29	0|wumpus|e.g. the release notes need to be final at the same time the release is final
 236 2016-10-20 10:42:47	0|wumpus|otherwise they can't be included with the release, they can't be uploaded to bitcoin.org and other places, etc
 237 2016-10-20 10:42:57	0|wumpus|posted to the mailing lists
 238 2016-10-20 10:43:20	0|wumpus|could do the editing of the release notes in another repo then include it before final, sure...
 239 2016-10-20 10:43:29	0|wumpus|or heck ,even google docs
 240 2016-10-20 10:44:21	0|wumpus|that's easier for collaborative editing I guess
 241 2016-10-20 10:45:12	0|sipa|well it could remove the issue of retroactive changes
 242 2016-10-20 10:45:47	0|sipa|and the ambiguity of whether to edit doc/release-notes in 0.13 vs doc/release-notes-0.13 in master
 243 2016-10-20 10:45:55	0|wumpus|retroacive changes are always a problem
 244 2016-10-20 10:46:16	0|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
 245 2016-10-20 10:46:32	0|wumpus|and is cleaned out on the 0.13 branch for the next release from there
 246 2016-10-20 10:47:10	0|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
 247 2016-10-20 10:47:34	0|sipa|fair enough, it is less ambiguous than i thought
 248 2016-10-20 10:47:47	0|sipa|but it's still confusing
 249 2016-10-20 10:48:35	0|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
 250 2016-10-20 10:49:10	0|wumpus|at some point it needs to be checked in as doc/release-notes.md
 251 2016-10-20 10:49:32	0|wumpus|in principle only the state at the final tag matters, the filecould be non-existent before and after that
 252 2016-10-20 10:49:34	0|Victorsueca|what about this: do the docs on a separate repo, when it's release time then clone to bitcoin
 253 2016-10-20 10:49:50	0|wumpus|I don't think that's any less confusing though
 254 2016-10-20 10:50:00	0|wumpus|maybe the current way of working should just be documented better
 255 2016-10-20 10:50:57	0|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
 256 2016-10-20 10:51:34	0|wumpus|and to be honest I've never found anyone confused by this. Current 0.13 release notes? are on the 0.13 branch
 257 2016-10-20 10:51:48	0|wumpus|current 0.14 release notes are on the master branch
 258 2016-10-20 10:51:58	0|wumpus|those are for the next release on either branch
 259 2016-10-20 10:53:21	0|wumpus|the advantage of doing it this way is that pulls can update the release notes atomically with the thing they introduce
 260 2016-10-20 10:53:24	0|wumpus|not that anyone bothers
 261 2016-10-20 10:57:23	0|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...
 262 2016-10-20 10:58:10	0|wumpus|should make sure that the file still gets included in the tarballs though
 263 2016-10-20 10:58:18	0|wumpus|(and all the other distributions)
 264 2016-10-20 11:04:02	0|GitHub133|13bitcoin/060.13 14c9a5bad 15Wladimir J. van der Laan: doc: Update blurb in release notes...
 265 2016-10-20 11:04:02	0|GitHub133|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/c9a5baddeef3d8721a7c71acf070f92a3d8d43a3
 266 2016-10-20 11:24:11	0|luke-jr|☺ deterministic git assembly of Knots' branch in 30 seconds :P
 267 2016-10-20 11:26:03	0|Victorsueca|i'm currently testing if master can be built successfully
 268 2016-10-20 11:26:57	0|luke-jr|Victorsueca: it will likely depend on your boost version
 269 2016-10-20 11:32:12	0|Victorsueca|lastest probably, I installed it 2 days ago
 270 2016-10-20 11:34:17	0|sipa|installed how?
 271 2016-10-20 11:34:38	0|Victorsueca|with apt-get
 272 2016-10-20 11:35:05	0|sipa|that way you get the version from your distro's repository
 273 2016-10-20 11:35:13	0|sipa|that's very very unlikely to be the latest
 274 2016-10-20 11:35:22	0|Victorsueca|it's ubuntu
 275 2016-10-20 11:35:35	0|sipa|likely not even the latest at the time the distribution was released
 276 2016-10-20 11:37:47	0|Victorsueca|do unit tests mess with the default data directory or they create some temp dir to do the tests?
 277 2016-10-20 11:38:03	0|wumpus|they create temp directories
 278 2016-10-20 11:38:36	0|wumpus|if they touch the data directory that would be a bug
 279 2016-10-20 11:39:06	0|Victorsueca|so it's _safe_ to run the scripts in the qa folder
 280 2016-10-20 11:42:00	0|wumpus|those are not the unit tests, but functional tests, but the same holds
 281 2016-10-20 11:43:57	0|Victorsueca|wumpus: would be helpful if I run any of those and paste the outputs?
 282 2016-10-20 11:44:46	0|wumpus|only if they fail, I guess
 283 2016-10-20 11:45:22	0|wumpus|you can run all of them with qa/pull-tester/rpc-tests.py
 284 2016-10-20 11:47:25	0|Victorsueca|wumpus: is it currently more needed to test master or 0.13.1rc2?
 285 2016-10-20 11:53:12	0|sipa|unless you have an unusual setup, running rpc or unit tests won't teach us anything new
 286 2016-10-20 11:53:52	0|sipa|using bitcoind/-qt in your own ways may, however (though always be cautious about things that could lose you money)
 287 2016-10-20 11:54:05	0|Victorsueca|AFAIK there are few devs using windows
 288 2016-10-20 11:54:13	0|sipa|ah, yes
 289 2016-10-20 11:54:17	0|Victorsueca|I use Windows x64
 290 2016-10-20 11:54:27	0|sipa|i thought you were on ubuntylu
 291 2016-10-20 11:54:34	0|sipa|*ubuntu
 292 2016-10-20 11:54:47	0|Victorsueca|I use ubuntu to cross-compile the builds
 293 2016-10-20 11:54:54	0|sipa|do the rpc tests even work on windows?
 294 2016-10-20 11:55:40	0|Victorsueca|not sure, worth trying I guess
 295 2016-10-20 11:58:15	0|luke-jr|I kinda doubt they would
 296 2016-10-20 12:14:23	0|Victorsueca|looks like my boost version was right, master built successfully
 297 2016-10-20 12:17:59	0|Victorsueca|error at rpc-tests.py https://softnet.homenet.org/zerobin/?a149e1289bc5714f#2PzAq4zVrcQJl9WrUgIBfA7hpiVEIA44Ml8QRANe2HE=
 298 2016-10-20 12:19:36	0|luke-jr|wrong Python version
 299 2016-10-20 12:20:04	0|Victorsueca|need python 3?
 300 2016-10-20 12:20:10	0|luke-jr|yes
 301 2016-10-20 12:25:51	0|michagogo|I might have successfully set up a machine for Gitian building
 302 2016-10-20 12:26:12	0|michagogo|It was pretty much just as easy as I thought it might be
 303 2016-10-20 12:26:45	0|michagogo|I even migrated over my apt-cacher-ng cache from my other machine
 304 2016-10-20 12:27:36	0|achow101|michagogo: but does it actually build the binaries properly?
 305 2016-10-20 12:27:48	0|michagogo|achow101: That's my next test
 306 2016-10-20 12:28:05	0|michagogo|I made the base VM and that seems to work as far as sanity-checking
 307 2016-10-20 12:28:20	0|michagogo|Snapshotting it now, and then I'll test an actual build
 308 2016-10-20 12:28:47	0|michagogo|Gitian is actually broken atm (make-base-vm tries to copy a file that doesn't exist)
 309 2016-10-20 12:29:01	0|michagogo|But there's already a PR that fixes it, so I just cherry-picked that in
 310 2016-10-20 12:29:28	0|achow101|yeah, i noticed that.
 311 2016-10-20 12:30:57	0|michagogo|And I turned on VBox's video capture option, so I have a video of everything I did
 312 2016-10-20 12:43:29	0|Victorsueca|Error again https://softnet.homenet.org/zerobin/?586fe4c0934c7d9c#fMLN5XtScV/cdqkwjN6dTkLU17hjkL0iiNGW81x7aNw=
 313 2016-10-20 12:45:04	0|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
 314 2016-10-20 12:45:14	0|michagogo|then it tried to fall back to bitcoincore.org and got a 4040
 315 2016-10-20 12:45:15	0|michagogo|-0
 316 2016-10-20 12:45:22	0|michagogo|Oversight?
 317 2016-10-20 12:53:20	0|timothy|hi, can you please consider adding man pages to linux tar too?
 318 2016-10-20 12:53:26	0|timothy|instead of git repository only
 319 2016-10-20 13:00:39	0|Victorsueca|running it on a ubuntu enviroment brings a similar error https://softnet.homenet.org/zerobin/?e1589c342242901a#RUf6mKsZzrb+JBznhaaAraDxb57s0DayDGRm1JgU5Bo=
 320 2016-10-20 13:00:45	0|Victorsueca|so it's not windows fault
 321 2016-10-20 13:05:01	0|Victorsueca|any ideas?
 322 2016-10-20 13:05:19	0|michagogo|achow101: Seems to be working so far
 323 2016-10-20 13:05:34	0|michagogo|Running an actual gitian build, it's built linux depends up until native_protobuf
 324 2016-10-20 13:05:43	0|michagogo|Working on boost atm
 325 2016-10-20 13:07:33	0|michagogo|OpenSSL...
 326 2016-10-20 13:09:08	0|michagogo|Okay, if anyone's interested in taking a look, it should go up soon at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
 327 2016-10-20 13:10:38	0|michagogo|It's being compressed atm, once it's done it'll start uploading
 328 2016-10-20 13:23:28	0|GitHub167|[13bitcoin] 15rebroad opened pull request #8983: Show block height and size when received (06master...06ShowBlockHeightAndSizeWhenReceived) 02https://github.com/bitcoin/bitcoin/pull/8983
 329 2016-10-20 13:33:38	0|achow101_|michagogo: how did you get lxc to work? Did you have to change anything in gitian's scripts?
 330 2016-10-20 13:35:53	0|BlueMatt|why do i see so many nodes failing version handshake?
 331 2016-10-20 13:35:58	0|BlueMatt|on 13.1
 332 2016-10-20 13:41:34	0|Lightsword|BlueMatt, only on 0.13.1 and not 0.13.0?
 333 2016-10-20 13:44:04	0|BlueMatt|dunno, didnt try 13
 334 2016-10-20 13:44:44	0|BlueMatt|still, ProcessMessage FAILED on version messages is new to me
 335 2016-10-20 13:44:55	0|BlueMatt|did xt/classic/unlimited break something?
 336 2016-10-20 13:46:24	0|Victorsueca|BlueMatt: not getting those errors here
 337 2016-10-20 13:47:14	0|Lightsword|BlueMatt, got an example of one it fails against?
 338 2016-10-20 13:48:24	0|sipa|BlueMatt: nExpectedServices could cause this
 339 2016-10-20 13:48:33	0|BlueMatt|no, because it otherwise prints the peer's ip messages after version processing works
 340 2016-10-20 13:48:34	0|BlueMatt|:/
 341 2016-10-20 13:49:00	0|sipa|when a node does not have the services in its version message listed that we expected it to have, we disconnect
 342 2016-10-20 13:49:01	0|BlueMatt|sipa: no, ProcessMessages(version, 102 bytes) FAILED peer=10
 343 2016-10-20 13:49:17	0|BlueMatt|oh, yea, that might be it
 344 2016-10-20 13:49:19	0|BlueMatt|since it returns false
 345 2016-10-20 13:49:19	0|sipa|yes, ProcessMessages returns false in that case
 346 2016-10-20 13:49:34	0|BlueMatt|huh, funny, I've seen a bunch of those on fresh nodes
 347 2016-10-20 13:50:04	0|Victorsueca|BlueMatt: maybe it's gmaxwell's aggressive witness peer search disconnection non-witness nodes to free connection slots
 348 2016-10-20 13:50:28	0|Victorsueca|disconnecting*
 349 2016-10-20 13:50:33	0|BlueMatt|no, it is almost surely the nServicesExpected & ~nServices check
 350 2016-10-20 13:50:33	0|sipa|Victorsueca: no, that's for chossing which peers to connect to
 351 2016-10-20 13:50:55	0|sipa|BlueMatt: to be fair, we probably had no idea about what services were circulating
 352 2016-10-20 13:51:08	0|sipa|maybe some reachable nodes became pruned
 353 2016-10-20 13:51:22	0|sipa|but their ips kept circulati g
 354 2016-10-20 14:01:39	0|tulip|BlueMatt: I was seeing that a lot too.
 355 2016-10-20 14:03:01	0|tulip|I didn't think to take a packet capture until after it calmed down sadly.
 356 2016-10-20 14:04:12	0|BlueMatt|tulip: naa, see comments above, its pretty clear what it is
 357 2016-10-20 14:05:54	0|tulip|BlueMatt: ok, needs more sensible error messages. there's a couple of those hanging around with peer connection.
 358 2016-10-20 14:06:34	0|tulip|if you use a proxy the errors it prints are basically noise, but that's solvable by just switching to another tmux window :)
 359 2016-10-20 14:10:50	0|Victor_sueca|damn, power outage
 360 2016-10-20 14:13:52	0|Victorsueca|and router has +30 second ping :D
 361 2016-10-20 14:22:36	0|BlueMatt|tulip: -debug=net will show it
 362 2016-10-20 14:22:44	0|BlueMatt|that error message should probably not need debug=net
 363 2016-10-20 14:55:25	0|achow101|michagogo: did you upload it yet? All I see is a .webm file which I can't play
 364 2016-10-20 15:25:18	0|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:
 365 2016-10-20 15:25:50	0|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);
 366 2016-10-20 15:25:50	0|NicolasDorier|It would make things easier to extend in the future and prevent to rely on undoc flags for script policy validation
 367 2016-10-20 15:25:50	0|NicolasDorier|void* libconsensus_createValidationContext();
 368 2016-10-20 15:25:50	0|NicolasDorier|void libconsensus_setConsensusFlags(void* context, int flags);
 369 2016-10-20 15:25:50	0|NicolasDorier|void libconsensus_setPolicyValidation(void* context, bool value);
 370 2016-10-20 15:26:11	0|NicolasDorier|so the whole undoc flags would be wrapped into the "PolicyValidation" boolean
 371 2016-10-20 15:27:05	0|sipa|NicolasDorier: but libconsensus' purpose is not to test policy
 372 2016-10-20 15:27:24	0|sipa|the same risks don't apply, you can use any implementation for that
 373 2016-10-20 15:27:51	0|sipa|and exposing that functionality means we need to maintain it, which makes it impossible in the future to split off policy validation elsewhere
 374 2016-10-20 15:29:12	0|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 :(
 375 2016-10-20 15:29:31	0|NicolasDorier|but well, I understand the point that you don't want the burden of maintaining it
 376 2016-10-20 15:29:33	0|sipa|well maybe you can create a libbitcoinscript
 377 2016-10-20 15:29:43	0|sipa|that does everything scripting, but isn't consensus
 378 2016-10-20 15:30:06	0|sipa|imho it's a mistake that in our own code the policy script evaluator is mixed with consensus logic
 379 2016-10-20 15:30:16	0|sipa|but that's a controversial opinion, i'm aware
 380 2016-10-20 15:31:27	0|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
 381 2016-10-20 15:31:56	0|sipa|it would imply we have two separate script interpreter implementations
 382 2016-10-20 15:32:22	0|sipa|one just for consensus, one for everything
 383 2016-10-20 15:32:32	0|sipa|the first one would only need to be touched for consensus changes
 384 2016-10-20 15:33:21	0|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
 385 2016-10-20 15:33:31	0|wumpus|I agree with sipa, I'm not against a libbitcoin_policy or such, but mixiing it with consensus is a bad idea
 386 2016-10-20 15:33:50	0|sipa|NicolasDorier: i don't want "abstract" anything in consensus code, to the extent possible
 387 2016-10-20 15:34:01	0|sipa|NicolasDorier: that makes it much harder to reason about all code interactions
 388 2016-10-20 15:35:19	0|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.
 389 2016-10-20 15:35:48	0|NicolasDorier|I mean it would be the easiest way I see to separate consensus code from policy code
 390 2016-10-20 15:35:54	0|NicolasDorier|in script evaluator
 391 2016-10-20 15:36:42	0|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
 392 2016-10-20 15:37:11	0|NicolasDorier|wumpus: yes, only for injecting things that are only part of policy
 393 2016-10-20 15:37:34	0|sipa|NicolasDorier: but how complicated would such an injector need to be to implement something like lows, or nullfail, or csv?
 394 2016-10-20 15:37:52	0|wumpus|(e.g. as long as injection points are a no-op when validating for consensus)
 395 2016-10-20 15:37:54	0|sipa|NicolasDorier: if for every new policy you need to add new injection places, it's no better than what you started with
 396 2016-10-20 15:39:10	0|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?
 397 2016-10-20 15:39:12	0|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
 398 2016-10-20 15:39:33	0|wumpus|(when testing libconsensus)
 399 2016-10-20 15:39:42	0|sipa|wumpus: i'd say so
 400 2016-10-20 15:39:47	0|wumpus|ok!
 401 2016-10-20 15:39:52	0|sipa|define a value that is the or of all flags that are in consensus
 402 2016-10-20 15:40:00	0|sipa|if any others are set, skip the test
 403 2016-10-20 15:40:34	0|wumpus|yes, I added a bitcoinconsensus_SCRIPT_FLAGS_VERIFY_ALL that is all the flags in libconsensus ORed
 404 2016-10-20 15:41:02	0|wumpus|let's see if that leaves enough tests :)
 405 2016-10-20 15:41:11	0|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
 406 2016-10-20 15:41:38	0|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, ...
 407 2016-10-20 15:41:44	0|wumpus|I don't think it's urgent enough for a last-minute change to 0.13.1
 408 2016-10-20 15:42:28	0|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"
 409 2016-10-20 15:42:36	0|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
 410 2016-10-20 15:43:19	0|wumpus|and it's easier (esp. organization and review-wise) to do such things if they *don't* need to touch consensus code
 411 2016-10-20 15:44:26	0|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 ?
 412 2016-10-20 15:44:37	0|wumpus|yes, I'd like that
 413 2016-10-20 15:44:55	0|NicolasDorier|indeed would be cool
 414 2016-10-20 15:45:50	0|NicolasDorier|doing such a thing would be easy to review as well.
 415 2016-10-20 15:46:49	0|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
 416 2016-10-20 15:46:57	0|sipa|NicolasDorier: not just EvalScript. Everything in script/*
 417 2016-10-20 15:47:15	0|sipa|(most of it would go away in the consensus version, of course)
 418 2016-10-20 15:48:08	0|NicolasDorier|mh interesting indeed.
 419 2016-10-20 15:48:33	0|sipa|I once tried to simplify CScript::operator<< because it is very inconvenient to use
 420 2016-10-20 15:48:45	0|sipa|turns out, changing it would have been a hard fork
 421 2016-10-20 15:49:17	0|sipa|which was so scary that i really didn't want to touch consensus' CScript anymore
 422 2016-10-20 15:50:09	0|wumpus|yes dodged a bullet there
 423 2016-10-20 15:50:22	0|NicolasDorier|in C++ is there a way to split the implementation of a class in several file ?
 424 2016-10-20 15:50:27	0|sipa|yes
 425 2016-10-20 15:50:33	0|sipa|but you shouldn't :)
 426 2016-10-20 15:50:55	0|wumpus|the implementation can be split into multiple files, the definition must be in one place, generally
 427 2016-10-20 15:50:58	0|NicolasDorier|well, we could split CScript what belongs to consensus and what not
 428 2016-10-20 15:51:00	0|sipa|see core_io.h with core_write.cpp and core_read.cpp for exmample
 429 2016-10-20 15:51:04	0|sipa|NicolasDorier: die
 430 2016-10-20 15:51:13	0|NicolasDorier|ahah is this so contentious :D
 431 2016-10-20 15:51:39	0|sipa|NicolasDorier: now the users of your class' dependencies depend on _how_ they use the class
 432 2016-10-20 15:52:11	0|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
 433 2016-10-20 15:52:15	0|wumpus|you can put the functions everywhere
 434 2016-10-20 15:52:19	0|sipa|indeed
 435 2016-10-20 15:52:54	0|sipa|leveldb uses a struct with a {char* ptr; size_t size} in many places
 436 2016-10-20 15:53:12	0|sipa|allowing processing routines to be independent from storage
 437 2016-10-20 15:53:15	0|wumpus|we need a slice abstraction too
 438 2016-10-20 15:53:21	0|sipa|slice, that's it
 439 2016-10-20 15:53:43	0|wumpus|golang has that pretty much as central data representation :)
 440 2016-10-20 15:54:19	0|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
 441 2016-10-20 15:54:26	0|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
 442 2016-10-20 15:54:32	0|NicolasDorier|you could wrap your char* by one of those
 443 2016-10-20 15:54:32	0|sipa|there wouldn't even be a CScriot
 444 2016-10-20 15:54:37	0|sipa|just an EvalScript
 445 2016-10-20 15:55:00	0|sipa|there could be a CScriptBuilder with the << operators etc for convenience
 446 2016-10-20 15:55:05	0|wumpus|right - script generation isn't part of consensus
 447 2016-10-20 15:55:13	0|sipa|exactly
 448 2016-10-20 15:55:20	0|sipa|it would just be utikity
 449 2016-10-20 15:55:28	0|NicolasDorier|wumpus: by "Slice" abstraction, you mean a structure  {*array, index, count} ?
 450 2016-10-20 15:55:44	0|wumpus|NicolasDorier: yes
 451 2016-10-20 15:55:59	0|wumpus|I think in golang it's a kind of shared pointer. Not sure though how they do memory internally
 452 2016-10-20 15:56:09	0|wumpus|in leveldb it's just a *
 453 2016-10-20 15:56:34	0|wumpus|so they don't 'hold' the memory, they just reference it, which is slightly more error prone but maybe lower overhead
 454 2016-10-20 15:57:30	0|wumpus|in any case for one-off methods like consensus calls the distinction doesn't matter
 455 2016-10-20 15:57:36	0|wumpus|consensus has no state and will never hold on to your slices
 456 2016-10-20 15:58:06	0|wumpus|OK OK the statelessness not true if you include the caches
 457 2016-10-20 15:58:16	0|wumpus|*current* libconsensus has no state
 458 2016-10-20 15:59:54	0|michagogo|achow101: I don't think I did more than what gitian's README says
 459 2016-10-20 15:59:56	0|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
 460 2016-10-20 16:00:31	0|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)
 461 2016-10-20 16:00:35	0|wumpus|not sure what you mean there, script is just a char*,size effectively. It has no internal structure
 462 2016-10-20 16:00:46	0|michagogo|And yeah, the ova isn't fully uploaded yet
 463 2016-10-20 16:01:08	0|michagogo|OneDrive says it's uploaded 1.2 out of 3.6 GB
 464 2016-10-20 16:01:24	0|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
 465 2016-10-20 16:01:58	0|michagogo|Unfortunately it looks like it doesn't show a speed or time estimate, unlike Dropbox...
 466 2016-10-20 16:01:58	0|wumpus|on the C# size you could re-add all the syntactic sugar that you want, esp if you use it for non-consensus
 467 2016-10-20 16:02:26	0|NicolasDorier|yeah with extension method :))
 468 2016-10-20 16:02:27	0|wumpus|(e.g. if you *want* GetSigOpsCount implies you're doing policy)
 469 2016-10-20 16:02:45	0|NicolasDorier|ah GetSigOpsCount I though it was part of consensus my bad
 470 2016-10-20 16:03:42	0|michagogo|The Linux gitian build worked on the new appliance:  https://www.irccloud.com/pastebin/RpH8KGPY/
 471 2016-10-20 16:04:06	0|wumpus|hm you're right I think, though if possible that would be used internally by libconsensus and not exposed
 472 2016-10-20 16:04:57	0|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
 473 2016-10-20 16:05:14	0|michagogo|achow101: Hm, odd
 474 2016-10-20 16:05:25	0|michagogo|You said you weren't able to play the webm?
 475 2016-10-20 16:05:50	0|michagogo|VLC seems to be playing it without a problem...
 476 2016-10-20 16:06:07	0|michagogo|Looks like Chrome is doing just fine as well
 477 2016-10-20 16:06:20	0|achow101|it didn't work in whatever default video player ubuntu uses. I'll try vlc
 478 2016-10-20 16:07:00	0|michagogo|It's about an hour long
 479 2016-10-20 16:07:19	0|achow101|yeah, it works in vlc
 480 2016-10-20 16:07:29	0|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
 481 2016-10-20 16:07:45	0|michagogo|Trial, error, and all
 482 2016-10-20 16:08:05	0|michagogo|(also with some pauses while I looked stuff up outside the VM...)
 483 2016-10-20 16:11:33	0|achow101|why do you need apt-cacher-ng
 484 2016-10-20 16:13:25	0|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
 485 2016-10-20 16:14:02	0|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
 486 2016-10-20 16:14:47	0|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)
 487 2016-10-20 16:15:00	0|achow101|ok
 488 2016-10-20 16:19:10	0|michagogo|Lauda: You may be interested in this too
 489 2016-10-20 16:19:32	0|michagogo|In the meantime it's up to 1.3 GB...
 490 2016-10-20 16:20:02	0|michagogo|Actually, just realized I can check Resource Monitor
 491 2016-10-20 16:24:41	0|michagogo|Looks like OneDrive is currently uploading at about 250-300KB/s
 492 2016-10-20 16:26:28	0|michagogo|achow101: Looks like it should show up in 2-3 hours
 493 2016-10-20 16:26:45	0|michagogo|(assuming a steady rate)
 494 2016-10-20 16:32:10	0|Lauda|thanks michagogo
 495 2016-10-20 16:34:58	0|wumpus|luke-jr, Victorsueca: the RPC tests work on windows, but are currently disabled there in travis because of timeout issues
 496 2016-10-20 16:35:54	0|wumpus|see https://github.com/bitcoin/bitcoin/pull/8227
 497 2016-10-20 16:37:48	0|jonasschnelli|sipa, available?
 498 2016-10-20 16:38:46	0|sipa|jonasschnelli: yes
 499 2016-10-20 16:39:19	0|cfields_|BlueMatt: ping. #8969 ready for review/testing?
 500 2016-10-20 16:39:25	0|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
 501 2016-10-20 16:39:38	0|Victorsueca|wumpus: I tried it and there's some error with subprocess.py https://softnet.homenet.org/zerobin/?586fe4c0934c7d9c#fMLN5XtScV/cdqkwjN6dTkLU17hjkL0iiNGW81x7aNw=
 502 2016-10-20 16:39:58	0|jonasschnelli|sipa: NotifyHeaderTip is only used by the gui and IMO it should just reflect whats inside pindexBestHeader... not?
 503 2016-10-20 16:40:41	0|Victorsueca|wumpus: a similar error occurs even on a ubuntu env https://softnet.homenet.org/zerobin/?6b8aa1b1b6e5aca7#MhP7eiv7h8L7mHC9LMAIk6ytlzsmY2Hv+3t7I7WnUtQ=
 504 2016-10-20 16:41:26	0|sipa|jonasschnelli:  remember thinking about that, and that we should indeed just switch to using pindexBestHeader
 505 2016-10-20 16:41:58	0|jonasschnelli|sipa: Okay. Let me try a PR. I'd like to fix https://github.com/bitcoin/bitcoin/issues/8984 with it as well
 506 2016-10-20 16:42:48	0|BlueMatt|cfields_: sure! go for it
 507 2016-10-20 16:43:02	0|BlueMatt|cfields_: though maybe first do 8968 first, and review those separately
 508 2016-10-20 16:43:21	0|BlueMatt|cfields_: 8969 should be pretty simple without 8968
 509 2016-10-20 16:43:44	0|cfields_|BlueMatt: got it, thanks
 510 2016-10-20 16:44:02	0|BlueMatt|sipa: got a chance to rebase 8515? I got sucked into making fibre support variable bw depending on the remote node
 511 2016-10-20 16:44:03	0|BlueMatt|:/
 512 2016-10-20 16:44:05	0|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.
 513 2016-10-20 16:44:10	0|BlueMatt|and fighting with hosts about their shitty routing
 514 2016-10-20 16:44:33	0|BlueMatt|cfields_: no rush, so is debugging the shitty, shitty world of chinese internet
 515 2016-10-20 16:44:42	0|cfields_|heh
 516 2016-10-20 16:44:45	0|sipa|BlueMatt: will do
 517 2016-10-20 16:46:38	0|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
 518 2016-10-20 16:47:11	0|BlueMatt|cfields_: yea, we talked about this in milan...decided against it because it was late even then
 519 2016-10-20 16:47:32	0|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?
 520 2016-10-20 16:48:16	0|BlueMatt|cfields_: it should never cause deadlock since cs_main should always be the first lock, I believe
 521 2016-10-20 16:48:47	0|BlueMatt|maybe sipa want to comment since he was the one claiming so in milan
 522 2016-10-20 16:48:59	0|cfields_|BlueMatt: specifically, it's holding it while grabbing cs_vSend/cs_vRecvMsg that worry me
 523 2016-10-20 16:49:04	0|cfields_|agh, brb.
 524 2016-10-20 17:04:36	0|GitHub157|[13bitcoin] 15jonasschnelli opened pull request #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (06master...062016/10/fix_gui_overlay) 02https://github.com/bitcoin/bitcoin/pull/8985
 525 2016-10-20 17:33:42	0|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'?
 526 2016-10-20 17:34:34	0|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".
 527 2016-10-20 17:34:53	0|wumpus|I agree
 528 2016-10-20 17:36:12	0|Victorsueca|wumpus: is my error related to what you said or it's a different thing?
 529 2016-10-20 17:39:24	0|wumpus|Victorsueca: I don't really know
 530 2016-10-20 17:40:23	0|wumpus|what does "El sistema no puede encontrar el archivo especificado" mean?
 531 2016-10-20 17:40:42	0|Victorsueca|The system couldn't find the specified file
 532 2016-10-20 17:41:18	0|wumpus|ohh, no that's a different problem. You could try setting the environment variable BITCOIND to the location where bitcoind is
 533 2016-10-20 17:41:50	0|wumpus|looks like it's simply notable to find the daemon
 534 2016-10-20 17:42:25	0|sipa|s/notable/unable/ ?
 535 2016-10-20 17:42:31	0|Victorsueca|thanks, will try
 536 2016-10-20 17:43:20	0|Victorsueca|should I set it to the directory where bitcoind is or directly to the bitcoind.exe file?
 537 2016-10-20 17:43:41	0|wumpus|the file
 538 2016-10-20 17:47:46	0|Victorsueca|wumpus: done, exactly the same error
 539 2016-10-20 17:48:14	0|Victorsueca|ohh wait, didn't restart the terminal...
 540 2016-10-20 17:48:27	0|sipa|wallet/rpcdump.cpp:1020:13: warning: ‘nLowestTimestamp’ may be used uninitialized in this function [-Wmaybe-uninitialized] int64_t nLowestTimestamp;
 541 2016-10-20 17:50:57	0|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
 542 2016-10-20 17:53:03	0|Victorsueca|well, the bash is on C:\UNIX\bitcoinalpha
 543 2016-10-20 17:53:19	0|Victorsueca|which is where I cloned the master branch of the git repository
 544 2016-10-20 17:53:24	0|sipa|Victorsueca: i don't think this channel is right for helping you debug these things
 545 2016-10-20 17:54:28	0|Victorsueca|sipa: well, maybe something is wrong with the rpc tests in which case it should be fixed
 546 2016-10-20 17:55:05	0|Victorsueca|first i'm trying to figure out if I did something wrong or the python script has some bug
 547 2016-10-20 17:55:07	0|wumpus|"maybe". But you should first try to debug it locally, before making allegations like that
 548 2016-10-20 17:55:26	0|wumpus|the QA tests are run by many people on many platforms
 549 2016-10-20 17:55:40	0|achow101|Victorsueca: what's the problem again? I'll see if I can replicate
 550 2016-10-20 17:56:01	0|Victorsueca|achow101: I posted the link above
 551 2016-10-20 17:56:11	0|Victorsueca|wumpus: few on windows AFAIK
 552 2016-10-20 17:56:20	0|wumpus|no, really ,they are being run on windows
 553 2016-10-20 17:56:36	0|Victorsueca|hmmm ok
 554 2016-10-20 17:56:56	0|Victorsueca|any instructions on how to dump extra debug info?
 555 2016-10-20 17:57:33	0|wumpus|I think you need general python debugging tools
 556 2016-10-20 17:57:53	0|wumpus|there's nothing bitcoin specific about not being able to execute the right executable
 557 2016-10-20 17:59:34	0|Victorsueca|well, don't know if this is relevant but trying rpc-tests.py on a ubuntu enviroment brings out the same error
 558 2016-10-20 18:00:02	0|Victorsueca|I guess that would discard being something windows-specific
 559 2016-10-20 18:00:15	0|michagogo|achow101: .6 GB to go
 560 2016-10-20 18:01:25	0|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
 561 2016-10-20 18:01:28	0|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
 562 2016-10-20 18:01:47	0|Victorsueca|sipa: yep, likely
 563 2016-10-20 18:02:16	0|wumpus|even a backtrace seems to be problematic
 564 2016-10-20 18:02:37	0|Victorsueca|wumpus: that's because windows is made to fail, M$ doesn't care because you already paid for the license :P
 565 2016-10-20 18:03:02	0|wumpus|Victorsueca: well in the case of linux much likely no one paid for anything, it seems to be something with transparency of APIs
 566 2016-10-20 18:04:00	0|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
 567 2016-10-20 18:04:35	0|Victorsueca|in M$ they already have the money so they can use to to make even more crap software
 568 2016-10-20 18:07:09	0|sipa|referring to microsoft M$ isn't particularly meaningful - every company tries to make money
 569 2016-10-20 18:07:43	0|michagogo|Hm, just saw this morning's (last night's, really) wallops
 570 2016-10-20 18:07:58	0|michagogo|I wonder if we're in scope
 571 2016-10-20 18:09:09	0|sipa|michagogo: link?
 572 2016-10-20 18:09:17	0|michagogo|http://freenode.net/news/community
 573 2016-10-20 18:09:34	0|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.)
 574 2016-10-20 18:09:56	0|wumpus|sipa: looks like it may be a false positive, nLowestTimestamp is supposed to be only set and used in the case of fRescan
 575 2016-10-20 18:11:24	0|achow101|Victorsueca: wumpus: replicated the problem, found the issue (I think)
 576 2016-10-20 18:12:23	0|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
 577 2016-10-20 18:13:26	0|achow101|It seems the the RPC_TESTS_DIR returns the path with unix style e.g /mnt/c/... and it isn't liking that
 578 2016-10-20 18:13:28	0|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 :-)
 579 2016-10-20 18:15:19	0|Victorsueca|achow101: maybe adding shell=True would solve it?
 580 2016-10-20 18:15:29	0|wumpus|achow101: but he tried to override BITCOIND already
 581 2016-10-20 18:15:42	0|wumpus|no, don't add shell=True please, that's a security disaster
 582 2016-10-20 18:15:50	0|Victorsueca|lol yeah
 583 2016-10-20 18:16:11	0|sipa|BlueMatt: remabsed 8515
 584 2016-10-20 18:16:18	0|sipa|*rebased
 585 2016-10-20 18:16:35	0|sipa|sometimes i fail to understand my own fingers.
 586 2016-10-20 18:17:27	0|achow101|Victorsueca: it's because both of us built using WSL
 587 2016-10-20 18:17:49	0|achow101|the problem is with the SRCDIR variable. If you go to qa/tests_config.py you'll see why
 588 2016-10-20 18:18:43	0|Victorsueca|achow101: no such file
 589 2016-10-20 18:18:59	0|achow101|sorry, qa/pull-tester/test_config.py
 590 2016-10-20 18:20:09	0|Victorsueca|ahh lol
 591 2016-10-20 18:20:22	0|Victorsueca|variables are in unix-like paths
 592 2016-10-20 18:21:23	0|achow101|but fixing there's another error after fixing that
 593 2016-10-20 18:26:30	0|Victorsueca|achow101: which one?
 594 2016-10-20 18:26:52	0|achow101|%1 is not a valid Win32 application
 595 2016-10-20 18:27:01	0|achow101|that happens when I run it again
 596 2016-10-20 18:27:48	0|Victorsueca|i'm still getting the same error tho
 597 2016-10-20 18:28:03	0|GitHub0|13bitcoin/06master 147942d31 15Luke Dashjr: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions
 598 2016-10-20 18:28:03	0|GitHub0|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f2d705629b51...0e228557f239
 599 2016-10-20 18:28:04	0|GitHub0|13bitcoin/06master 140e22855 15Wladimir J. van der Laan: Merge #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions...
 600 2016-10-20 18:28:18	0|achow101|check your path and make sure it is correct. Use forward slashes instead of backslashes
 601 2016-10-20 18:28:18	0|GitHub21|[13bitcoin] 15laanwj closed pull request #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (06master...06compat_importmulti_oldboost) 02https://github.com/bitcoin/bitcoin/pull/8980
 602 2016-10-20 18:28:39	0|BlueMatt|sipa: thanks
 603 2016-10-20 18:31:18	0|gmaxwell|bleh why are we using boost::variant?
 604 2016-10-20 18:33:13	0|wumpus|don't know, ask satoshi? that has been used for the base58 stuff as long as I remember at least
 605 2016-10-20 18:33:24	0|sipa|nope, i introduced it.
 606 2016-10-20 18:33:47	0|sipa|jonasschnelli: how do you unhide the catching up overlay?
 607 2016-10-20 18:33:48	0|wumpus|I guess it's a convenient way to do that
 608 2016-10-20 18:34:10	0|sipa|gmaxwell: well because it's exactly what we need for CTxDestination... a tagged union
 609 2016-10-20 18:34:27	0|wumpus|I absolutely doubt it's the hardest thing to replace if we really were to want toget rid of hoost
 610 2016-10-20 18:34:34	0|sipa|wumpus: absolutely
 611 2016-10-20 18:34:39	0|wumpus|why is it such an issue for you gmaxwell ?
 612 2016-10-20 18:34:45	0|sipa|though it's not trivial either
 613 2016-10-20 18:35:16	0|sipa|as using a C union with non-trivial types in it is asking for problems
 614 2016-10-20 18:35:43	0|achow101|Victorsueca: the second I error I ran into is because python.exe isn't being called where normally it will with linux
 615 2016-10-20 18:35:59	0|achow101|tl;dr don't run the rpc tests on windows because windows does stupid things
 616 2016-10-20 18:36:01	0|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
 617 2016-10-20 18:36:23	0|Victorsueca|achow101: thanks, will put that on a bitcoin block so everybody knows ;)
 618 2016-10-20 18:37:05	0|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' ?
 619 2016-10-20 18:37:16	0|wumpus|the usualy way in C++ would be something with subclasses
 620 2016-10-20 18:38:27	0|sipa|yuck. that means the child classes need to know that they're part of a union
 621 2016-10-20 18:38:32	0|wumpus|sipa: sure, feel free to make it more obvious
 622 2016-10-20 18:38:43	0|sipa|wumpus: i don't know Qt :)
 623 2016-10-20 18:39:17	0|wumpus|sipa: well evertying is a compromise, I'm sure some other solution could be thought up without that drawback
 624 2016-10-20 18:39:30	0|wumpus|without having to go into boost template hell
 625 2016-10-20 18:39:51	0|sipa|i guess my poreferred solution would be to reimplement boost::variant :)
 626 2016-10-20 18:40:05	0|sipa|c++ really lacks a tagged union
 627 2016-10-20 18:40:08	0|wumpus|bleh
 628 2016-10-20 18:40:30	0|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
 629 2016-10-20 18:41:13	0|cfields_|sipa: iirc c++14 adds std::variant and/or std::any
 630 2016-10-20 18:41:14	0|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
 631 2016-10-20 18:41:31	0|sipa|cfields_: aha!
 632 2016-10-20 18:41:31	0|wumpus|we *don't * want to support half of bost as part of bitcoin core
 633 2016-10-20 18:42:17	0|cfields_|sipa: bah, both c++17 :(
 634 2016-10-20 18:42:57	0|wumpus|are we at c++17 yet?
 635 2016-10-20 18:43:00	0|sipa|cfields_: oh, so we only need to wait until 2022 until we can use it in Bitcoin Core?
 636 2016-10-20 18:43:09	0|wumpus|yes
 637 2016-10-20 18:43:12	0|cfields_|heh
 638 2016-10-20 18:43:47	0|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
 639 2016-10-20 18:44:12	0|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 :)
 640 2016-10-20 18:44:25	0|sipa|afaik c++14/17 change much less than what c++11 changed wrt to c++03
 641 2016-10-20 18:44:28	0|wumpus|we only need time, and that elapses automatically
 642 2016-10-20 18:44:30	0|cfields_|wumpus: yep, see std::filesystem :)
 643 2016-10-20 18:44:46	0|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.
 644 2016-10-20 18:45:00	0|cfields_|sipa: yes, true
 645 2016-10-20 18:45:07	0|sipa|how many headers does testnet have?
 646 2016-10-20 18:45:22	0|gmaxwell|wumpus: but it wuld be inaccurate to say it's such an issue.. it's now, I was just asking.
 647 2016-10-20 18:46:00	0|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
 648 2016-10-20 18:46:25	0|wumpus|it's apparently just hard to support something like that in c++
 649 2016-10-20 18:46:36	0|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...)
 650 2016-10-20 18:46:53	0|wumpus|gmaxwell: well you're welcome to implement it in a better way! :)
 651 2016-10-20 18:47:11	0|sipa|it's preferctly applicable in cases where you can say "an X is either a Y or a Z"
 652 2016-10-20 18:47:24	0|cfields_|gmaxwell: yes, the more c++ish way of doing it almost certainly implies try/catch+dynamic_cast, which i find pretty nasty
 653 2016-10-20 18:47:34	0|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
 654 2016-10-20 18:47:36	0|sipa|cfields_: puke
 655 2016-10-20 18:47:59	0|gmaxwell|(and yes, I also believe polymorphism is generally ill-advised based on the same argument)
 656 2016-10-20 18:48:24	0|sipa|found the C programmer.
 657 2016-10-20 18:48:24	0|wumpus|cfields_: or as I said above, subclasses and the visitor pattern. NOt that that would really be any improvement in type safety
 658 2016-10-20 18:48:50	0|wumpus|sigh, let's not get into that discussino
 659 2016-10-20 18:49:03	0|cfields_|wumpus: yes, that'd be much cleaner
 660 2016-10-20 18:49:20	0|sipa|(though i would agree with saying that such constructions are often used in places where they're unnecessary and harmful)_
 661 2016-10-20 18:49:25	0|wumpus|cfields_: sipa didn't like it because the subclasses have to know they're part of an union
 662 2016-10-20 18:49:42	0|cfields_|wumpus: yes, that'd be the "tag" part :p
 663 2016-10-20 18:49:59	0|cfields_|oh, i see what you mean
 664 2016-10-20 18:50:09	0|wumpus|sure, polymorphism is certainly overused in some cases, espeically in the beginnign when it was new and everything had to be an object
 665 2016-10-20 18:50:11	0|sipa|*switch topic* what is testnet's height?
 666 2016-10-20 18:50:16	0|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.
 667 2016-10-20 18:50:24	0|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)
 668 2016-10-20 18:50:36	0|wumpus|gmaxwell: yes - it's even worse in java code generally :)
 669 2016-10-20 18:50:37	0|gmaxwell|sipa: on segwit nodes 1009190
 670 2016-10-20 18:50:40	0|cfields_|as of a min or two ago
 671 2016-10-20 18:50:49	0|sipa|cfields_: thanks. trying to sync headers over a really slow connection
 672 2016-10-20 18:55:49	0|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' ?
 673 2016-10-20 18:55:54	0|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.
 674 2016-10-20 18:56:07	0|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
 675 2016-10-20 18:56:11	0|jonasschnelli|Yes. It's a bit hidden. What about clicking on the progress bar in the status bar?
 676 2016-10-20 18:56:19	0|sipa|and a real tagged union would be much more useful
 677 2016-10-20 18:56:32	0|wumpus|sipa: good point
 678 2016-10-20 18:57:03	0|sipa|jonasschnelli: that'd be useful too
 679 2016-10-20 18:57:13	0|sipa|(it was the first thing i tried)
 680 2016-10-20 18:57:53	0|wumpus|so I think stopping support for windows 32-bit in 0.15 would make sense
 681 2016-10-20 18:58:23	0|achow101|meeting?
 682 2016-10-20 18:58:30	0|wumpus|in two minutes!
 683 2016-10-20 18:58:39	0|sipa|one and a half
 684 2016-10-20 18:58:42	0|achow101|aw man, my clock's fast
 685 2016-10-20 18:59:14	0|Victorsueca|what meeting?
 686 2016-10-20 18:59:23	0|jl2012|the last windows with 32-bit is windows 7?
 687 2016-10-20 18:59:28	0|achow101|Victorsueca: dev meeting
 688 2016-10-20 18:59:45	0|achow101|jl2012: windows10 has a 32 bit version
 689 2016-10-20 18:59:50	0|Victorsueca|^
 690 2016-10-20 19:00:04	0|Victorsueca|achow101: is it going to be broadcasted?
 691 2016-10-20 19:00:12	0|achow101|it happens right here on irc
 692 2016-10-20 19:00:12	0|CodeShark|it's here
 693 2016-10-20 19:00:15	0|wumpus|#startmeeting
 694 2016-10-20 19:00:16	0|lightningbot|Meeting started Thu Oct 20 19:00:15 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 695 2016-10-20 19:00:16	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 696 2016-10-20 19:00:25	0|wumpus|proposed topics?
 697 2016-10-20 19:00:38	0|sipa|proposed cheer: yay for 0.13.1rc
 698 2016-10-20 19:00:45	0|CodeShark|^ :DDD
 699 2016-10-20 19:00:51	0|jonasschnelli|heh
 700 2016-10-20 19:00:56	0|wumpus|yay for 0.13.1rc, haven't heard of any real problems yet
 701 2016-10-20 19:01:16	0|achow101|hmm. where's gmaxwell-ping-bot
 702 2016-10-20 19:01:23	0|wumpus|not that it says much given how short it's been out, but ok, it's somewhat promising :)
 703 2016-10-20 19:01:54	0|CodeShark|if only execution paths with problems tended to occur first :p
 704 2016-10-20 19:02:03	0|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
 705 2016-10-20 19:02:07	0|jtimon|proposed topic: libconsensus: do we want to expose a verifyBlock function or a processblock one? do we want to expose verifyHeader and verifyTx ?
 706 2016-10-20 19:02:34	0|btcdrak|here
 707 2016-10-20 19:02:51	0|instagibbs_|present
 708 2016-10-20 19:02:51	0|wumpus|ah yes I have another topic about the libconsensus interface: what to do with undocumented flags
 709 2016-10-20 19:02:59	0|btcdrak|ping jl2012
 710 2016-10-20 19:03:08	0|jl2012|yes
 711 2016-10-20 19:03:10	0|wumpus|jl2012 was already here
 712 2016-10-20 19:03:35	0|jtimon|wumpus: like bip113 ? or more like bip30 ?
 713 2016-10-20 19:03:46	0|wumpus|jtimon: https://github.com/bitcoin/bitcoin/pull/8976
 714 2016-10-20 19:03:53	0|wumpus|#topic libconsensus
 715 2016-10-20 19:04:05	0|wumpus|currently it's possible to pass non-consensus flags into libconsensus
 716 2016-10-20 19:04:08	0|wumpus|e.g. policy only flags
 717 2016-10-20 19:04:25	0|CodeShark|yes, that should be pulled out
 718 2016-10-20 19:04:26	0|sipa|i believe we should not expose policy functions in libconsensus
 719 2016-10-20 19:04:50	0|sipa|as that would make it impossible to later split off policy code into a separate codebase
 720 2016-10-20 19:04:52	0|BlueMatt|sipa: ack
 721 2016-10-20 19:05:01	0|sipa|and consensus code should end up being isolated
 722 2016-10-20 19:05:04	0|wumpus|ok so that means you agree with #8976
 723 2016-10-20 19:05:10	0|instagibbs_|was there thought otherwise? (I'm outsider to this work)
 724 2016-10-20 19:05:20	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8976
 725 2016-10-20 19:05:21	0|CodeShark|yeah, doesn't seem very controversial
 726 2016-10-20 19:05:22	0|jtimon|I agree, currently it is not possible (at least using bitcoinconsensus_verifyScript)
 727 2016-10-20 19:05:32	0|instagibbs_|ah I see what you mean
 728 2016-10-20 19:05:32	0|wumpus|no, I don't think so. But people may be relying on this. I don't know anyone that does though.
 729 2016-10-20 19:05:37	0|wumpus|and NicolasDorier is okay with it
 730 2016-10-20 19:05:50	0|BlueMatt|wumpus: dont have a strong opinion, but I'm fine with that
 731 2016-10-20 19:06:04	0|wumpus|if there is to be a policy script library it'll need to be separate imo
 732 2016-10-20 19:06:15	0|jtimon|btw, currently the flags in script/bitcoinconsensus.h and in script/interpreter.h need to match, that shouldn't be the case
 733 2016-10-20 19:06:20	0|sipa|jonasschnelli: agree
 734 2016-10-20 19:06:20	0|wumpus|this is lib*consensus*
 735 2016-10-20 19:06:23	0|sipa|eh, jtimon: agree
 736 2016-10-20 19:06:38	0|wumpus|jtimon: no, they don't need to match, that's just an artifact
 737 2016-10-20 19:06:56	0|sipa|wumpus: is there are translation layer?
 738 2016-10-20 19:07:00	0|wumpus|although it's no longer possible to change the flags now
 739 2016-10-20 19:07:10	0|wumpus|ABI for libconsensus is fixed
 740 2016-10-20 19:07:20	0|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
 741 2016-10-20 19:07:22	0|wumpus|sipa: no, that was never added
 742 2016-10-20 19:07:28	0|sipa|we should add one
 743 2016-10-20 19:07:35	0|jtimon|agreed
 744 2016-10-20 19:07:35	0|sipa|and keep the flags for the existing bits
 745 2016-10-20 19:07:40	0|sipa|as passthrough
 746 2016-10-20 19:07:42	0|wumpus|yes, there should be a translation layer, though the current bits can no longer be changed
 747 2016-10-20 19:07:45	0|wumpus|agreed
 748 2016-10-20 19:07:47	0|sipa|but new ones can fill up the holes
 749 2016-10-20 19:08:12	0|jtimon|btw, related branch: https://github.com/jtimon/bitcoin/commits/0.13-consensus-flags
 750 2016-10-20 19:08:15	0|wumpus|at the lesat we should add the error when invalid flags are passed
 751 2016-10-20 19:08:27	0|CodeShark|is anyone using these flags as ints rather than just as an enum?
 752 2016-10-20 19:08:31	0|wumpus|this will discourage people from doing what they're doing now, e.g. treating it as a pass-through
 753 2016-10-20 19:09:06	0|sipa|CodeShark: we're already abusing enum here. it's a bit field, not an enum
 754 2016-10-20 19:09:06	0|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
 755 2016-10-20 19:09:14	0|sipa|the enum is just an easy way to give the constants name
 756 2016-10-20 19:09:15	0|jtimon|CodeShark: AFAIK there used always like if (flags & MY_FLAG)
 757 2016-10-20 19:09:37	0|sipa|for almost all operations we do with these enums, they decay into integers
 758 2016-10-20 19:09:41	0|wumpus|yes
 759 2016-10-20 19:09:56	0|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?
 760 2016-10-20 19:10:09	0|sipa|CodeShark: that breaks the ABI
 761 2016-10-20 19:10:13	0|wumpus|you can't shuffle the bits because it would break the *binary* interface
 762 2016-10-20 19:10:18	0|CodeShark|oh...
 763 2016-10-20 19:10:20	0|sipa|you can't link with an older version of the library in that case
 764 2016-10-20 19:10:23	0|CodeShark|ok
 765 2016-10-20 19:10:30	0|CodeShark|gotcha
 766 2016-10-20 19:10:44	0|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
 767 2016-10-20 19:11:08	0|sipa|without recompiling your client
 768 2016-10-20 19:11:10	0|wumpus|arguably the SEGWIT bit can be moved until 0.13.1 is finalized, but meh
 769 2016-10-20 19:11:24	0|sipa|indeed, meh.
 770 2016-10-20 19:12:06	0|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
 771 2016-10-20 19:12:10	0|CodeShark|sipa: so you're saying we can reuse the bits that get vacated when we remove the policy flags
 772 2016-10-20 19:12:24	0|sipa|CodeShark: yes
 773 2016-10-20 19:12:34	0|sipa|as those were never part of the abi
 774 2016-10-20 19:12:38	0|wumpus|CodeShark: the policy flags were never really allowed by the interface, it's a bug that it posibble to specify them at all
 775 2016-10-20 19:12:41	0|sipa|*api
 776 2016-10-20 19:12:59	0|wumpus|this is what #8976 fixes by adding input checking on the flags
 777 2016-10-20 19:13:14	0|jtimon|and my preference would be to expose a GetConsensusFlags call in libconsensus too
 778 2016-10-20 19:13:35	0|wumpus|what would that do?
 779 2016-10-20 19:13:36	0|jtimon|to hide the bip9 and previous developments stuff
 780 2016-10-20 19:14:12	0|jtimon|you call it, now you know which flags to use verifyScript, verifyTx or verifyBlock (or verifyBlock could call it internally)
 781 2016-10-20 19:14:44	0|sipa|and you pass in all block headers?
 782 2016-10-20 19:14:52	0|jtimon|https://github.com/jtimon/bitcoin/blob/0.13-consensus-flags/src/versionbits.cpp#L153
 783 2016-10-20 19:15:21	0|jtimon|no, the same CBlockIndex interface used for verifyHeader
 784 2016-10-20 19:15:59	0|sipa|i really don't like turning our internal representation for headers into an index
 785 2016-10-20 19:16:00	0|jtimon|similar to https://github.com/bitcoin/bitcoin/pull/8493
 786 2016-10-20 19:16:12	0|sipa|*into an interface
 787 2016-10-20 19:16:14	0|CodeShark|sipa: agreed
 788 2016-10-20 19:16:22	0|CodeShark|it could be done better
 789 2016-10-20 19:16:25	0|jtimon|other ideas to interface with storage ?
 790 2016-10-20 19:16:32	0|CodeShark|without exposing all that crap
 791 2016-10-20 19:16:33	0|jtimon|CodeShark: how?
 792 2016-10-20 19:16:46	0|sipa|just have an API where you can create a blockindexstore, and you give it headers
 793 2016-10-20 19:17:00	0|sipa|which are copied into the blockindexstore
 794 2016-10-20 19:17:04	0|CodeShark|yes
 795 2016-10-20 19:17:18	0|jtimon|so libconsensus remains coupled with our storage?
 796 2016-10-20 19:17:28	0|sipa|that's my personal preference
 797 2016-10-20 19:17:33	0|CodeShark|well...hmmm
 798 2016-10-20 19:17:36	0|jtimon|I wasn't planning on taking any headers from callers
 799 2016-10-20 19:17:39	0|kanzure|i don't mean to go all pointy hair or anything, but what is current expectation around libconsensus separation milestone timelines
 800 2016-10-20 19:17:55	0|sipa|kanzure: nobody even agrees what libconsensus means.
 801 2016-10-20 19:18:00	0|kanzure|perfect
 802 2016-10-20 19:18:19	0|CodeShark|the header storage engine is quite trivial, actually
 803 2016-10-20 19:18:37	0|CodeShark|not sure it needs an abstract DB interface...but on the other hand...
 804 2016-10-20 19:18:39	0|wumpus|I think the previous conslusion was that libconsensus should remain coupled with the current caching layer, but not with leveldb
 805 2016-10-20 19:18:42	0|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
 806 2016-10-20 19:18:53	0|BlueMatt|we already discussed this in milan
 807 2016-10-20 19:19:04	0|wumpus|so the *memory* storage is part of libconsensus
 808 2016-10-20 19:19:08	0|wumpus|the disk storage is not
 809 2016-10-20 19:19:13	0|BlueMatt|that
 810 2016-10-20 19:19:13	0|CodeShark|ok
 811 2016-10-20 19:19:14	0|jtimon|BlueMatt: yeah, you and me discussed it a little, with no conclusion
 812 2016-10-20 19:19:29	0|wumpus|right,we discussed that in Milan
 813 2016-10-20 19:19:31	0|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
 814 2016-10-20 19:19:33	0|kanzure|meaning of "storage" has to be carefully defined
 815 2016-10-20 19:19:46	0|sipa|they're perfectly compatible with a store into which you can load headers, though
 816 2016-10-20 19:20:12	0|jtimon|sipa: so let's break the API, users of libconsensus++ may have a more stable API, but less flexibility and control too
 817 2016-10-20 19:20:17	0|jonasschnelli|We are speaking of a in-memory only store, right?
 818 2016-10-20 19:20:31	0|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
 819 2016-10-20 19:20:34	0|wumpus|jonasschnelli: yes. as currently used for the headers
 820 2016-10-20 19:20:37	0|BlueMatt|but i think that is further out on the horizon
 821 2016-10-20 19:20:46	0|wumpus|BlueMatt: agreed, that's no issue right now
 822 2016-10-20 19:20:58	0|BlueMatt|also because refactoring every use of CBlockIndex into an api right now would be a ton of work/review/diff
 823 2016-10-20 19:21:07	0|sipa|the criterion would be that we ourself want to use it
 824 2016-10-20 19:21:13	0|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
 825 2016-10-20 19:21:26	0|wumpus|s/not support/support not/
 826 2016-10-20 19:21:27	0|sipa|if the API somehow needs to miss features, e.g. because adding some cache is hard, that goal is already broken
 827 2016-10-20 19:21:28	0|CodeShark|no need for premature optimization here
 828 2016-10-20 19:21:38	0|CodeShark|header storage is not a bottleneck ;)
 829 2016-10-20 19:21:44	0|sipa|CodeShark: it's not premature optimized. it's breaking existing optimization
 830 2016-10-20 19:21:51	0|kanzure|CBlockIndex usage is not necessarily libconsensus-only, right?
 831 2016-10-20 19:21:57	0|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
 832 2016-10-20 19:21:59	0|sipa|storage isn't, but block index traversal needs to be past
 833 2016-10-20 19:22:01	0|sipa|*fast
 834 2016-10-20 19:22:06	0|kanzure|i mean that's only because nobody wants to maintain a CBlockIndex and also libconsensus, ya?
 835 2016-10-20 19:22:21	0|sipa|kanzure: i have no clue what you're talking about
 836 2016-10-20 19:22:34	0|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
 837 2016-10-20 19:22:50	0|sipa|storage... port?
 838 2016-10-20 19:22:52	0|sipa|wth?
 839 2016-10-20 19:22:57	0|wumpus|I think a good goal should be that we could use libconsensus ourselves, at least it will have one client then :)
 840 2016-10-20 19:22:58	0|kanzure|(i was responding to "refactoring every use of CBlockIndex into an api".)
 841 2016-10-20 19:23:21	0|CodeShark|let's not get sidetracked
 842 2016-10-20 19:23:26	0|Victorsueca|sipa: not a network port obv
 843 2016-10-20 19:23:26	0|wumpus|please, let's not split hairs over definitions
 844 2016-10-20 19:23:28	0|wumpus|any other topics?
 845 2016-10-20 19:23:36	0|cfields_|wumpus: +1. As a side-effect, that also forces devs to become familiar with it.
 846 2016-10-20 19:23:57	0|gmaxwell|sorry, went to sleep during API discussions. I agree that the library should be used by bitcoin core if it is to exist. :)
 847 2016-10-20 19:24:06	0|gmaxwell|(I also support it existing, to be clear!)
 848 2016-10-20 19:24:10	0|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
 849 2016-10-20 19:24:10	0|wumpus|cfields_: right, so it's possible to fork bitcoin core but still use the same libconsensus, for example
 850 2016-10-20 19:25:05	0|wumpus|gmaxwell: if some topic isn't interesting to you, you don't need to be loud about that
 851 2016-10-20 19:25:13	0|jonasschnelli|Would it hurt if the libb*'s blockstorage be completly decoupled from the CBlockIndex, new structures, etc. as a first step?
 852 2016-10-20 19:25:33	0|sipa|jonasschnelli: we're not even talking about block storage
 853 2016-10-20 19:25:40	0|CodeShark|we're still on headers :p
 854 2016-10-20 19:25:40	0|jonasschnelli|sorry, heards
 855 2016-10-20 19:25:42	0|jonasschnelli|headers
 856 2016-10-20 19:26:05	0|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)
 857 2016-10-20 19:26:30	0|kanzure|external caller == other wallet?
 858 2016-10-20 19:26:31	0|jtimon|you guys want a processBlock function, not a verifyBlock one
 859 2016-10-20 19:26:44	0|sipa|jtimon: i think exposing verification functions at different levels is useful
 860 2016-10-20 19:26:49	0|jtimon|kanzure: yep, a wallet, an alternative implementation, whatever
 861 2016-10-20 19:26:53	0|sipa|exposing headers, individual block, total block, ...
 862 2016-10-20 19:27:08	0|jtimon|sipa: cool, BlueMatt seem to think it's not
 863 2016-10-20 19:27:08	0|sipa|jtimon: but the question is about whether or not to abstract out the state needed for that
 864 2016-10-20 19:27:23	0|sipa|those are independent questions
 865 2016-10-20 19:27:26	0|jtimon|in any case, you don't want a verifyHeader independent of storage
 866 2016-10-20 19:27:57	0|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.
 867 2016-10-20 19:28:02	0|sipa|i think it would hurt our own usage of it, as it means fewer opportunities to improve memory usage
 868 2016-10-20 19:28:06	0|jtimon|sipa: I think "is it needed" it's not the question, nothing is needed, the wuestion is what we want to do
 869 2016-10-20 19:28:19	0|sipa|what i want to do is have the consensus code abstracted out
 870 2016-10-20 19:28:22	0|wumpus|it is needed if it is used by us
 871 2016-10-20 19:28:31	0|sipa|modularized
 872 2016-10-20 19:28:38	0|jtimon|kanzure: I highly doubt libbitcoin will ever use a libconsensus that's coupled to bitcoin's storage and concurrency, for example
 873 2016-10-20 19:28:50	0|BlueMatt|jtimon: I have no problem exposing a verifyblock function that makes no external state lookups, but I dont think its so useful
 874 2016-10-20 19:28:50	0|sipa|that doesn't mean we need to abstract out every data structure it uses
 875 2016-10-20 19:29:07	0|BlueMatt|jtimon: I dont see much use for a verifyblock function that makes external state calls when you could just do processnewblock
 876 2016-10-20 19:29:08	0|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.
 877 2016-10-20 19:29:33	0|CodeShark|breaking out the storage engine can be done independently
 878 2016-10-20 19:29:50	0|wumpus|BlueMatt: yes, I remember we discussed that before, too :)
 879 2016-10-20 19:29:51	0|kanzure|what is the concurrency coupling that jtimon mentions in particular
 880 2016-10-20 19:30:00	0|sipa|CodeShark: we're not really talking about (disk) storage here, just in-memory representation of data structures
 881 2016-10-20 19:30:07	0|BlueMatt|wumpus: yes, this is exactly the discussion we had in milan
 882 2016-10-20 19:30:15	0|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)
 883 2016-10-20 19:30:43	0|BlueMatt|jtimon: have you spoken much to these folks? (I dont know, just asking, would love to see their responses)
 884 2016-10-20 19:31:13	0|jtimon|kanzure: if it's to cut down on work we can have both, that was my conclusion from a previous discussion with luke
 885 2016-10-20 19:31:17	0|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
 886 2016-10-20 19:31:34	0|sipa|yes, abstracting the data structures can still happen later
 887 2016-10-20 19:31:39	0|wumpus|I think this is typical bitcoin scope creep
 888 2016-10-20 19:31:45	0|CodeShark|yes - modularization is what's most important, then we can further optimize each unit
 889 2016-10-20 19:31:48	0|kanzure|sounds like an emphasis on code movement first
 890 2016-10-20 19:31:49	0|jtimon|BlueMatt: mostly only to erik from libbitcoin, but yeah, probably we should ask around before trying to guess what they want
 891 2016-10-20 19:31:51	0|wumpus|nothing will ever get done this way and we keep repeating the same discussions
 892 2016-10-20 19:32:29	0|wumpus|+tons of huge code changes that will take ages to review
 893 2016-10-20 19:32:46	0|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"
 894 2016-10-20 19:33:00	0|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
 895 2016-10-20 19:33:47	0|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
 896 2016-10-20 19:33:57	0|CodeShark|the focus for now should be on separation of units and removing dependencies
 897 2016-10-20 19:33:58	0|jtimon|well, all I want is to have a common and clear idea of what libconsensus should be
 898 2016-10-20 19:34:10	0|sipa|while we already have optimized data structures, and not abstracting them out leaves more opportunities for future such optimizations
 899 2016-10-20 19:34:15	0|wumpus|it should be a libarary that we ourselves can use for consensus validation
 900 2016-10-20 19:34:36	0|wumpus|sipa: exactly! *not* exposing something as part of the API leaves flexibility to improve things later
 901 2016-10-20 19:34:47	0|jtimon|CodeShark: but then people won't "see the point" of taking consensus code out of main...
 902 2016-10-20 19:34:47	0|wumpus|sipa: putting it in the API/ABI effectively sets it in stone
 903 2016-10-20 19:34:55	0|CodeShark|?
 904 2016-10-20 19:35:07	0|CodeShark|there
 905 2016-10-20 19:35:13	0|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.
 906 2016-10-20 19:35:31	0|morcos|For instance I disagree a bit with the flexibility when it comes to cache optimization for pcoinstip.
 907 2016-10-20 19:35:33	0|CodeShark|there's a very simple justification for it - moving the code out of main.cpp means far simpler merging of code changes
 908 2016-10-20 19:35:44	0|jtimon|CodeShark: ie #8337 #8329
 909 2016-10-20 19:35:54	0|morcos|But we don't have to answer all those questions right now
 910 2016-10-20 19:36:02	0|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
 911 2016-10-20 19:36:12	0|sipa|morcos: agree
 912 2016-10-20 19:36:13	0|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).
 913 2016-10-20 19:36:58	0|CodeShark|kanzure: indeed
 914 2016-10-20 19:37:02	0|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
 915 2016-10-20 19:37:37	0|sipa|jtimon: well things may not be easy
 916 2016-10-20 19:37:40	0|jtimon|kanzure: I would love that
 917 2016-10-20 19:37:45	0|CodeShark|let's not get hung up on how the lib API will be exposed and start working on moving code into separate units
 918 2016-10-20 19:38:03	0|Chris_Stewart_5|^
 919 2016-10-20 19:38:09	0|BlueMatt|^
 920 2016-10-20 19:38:13	0|jeremyrubin|^
 921 2016-10-20 19:38:16	0|sipa|v
 922 2016-10-20 19:38:17	0|jtimon|CodeShark: I'm happy with that
 923 2016-10-20 19:38:21	0|jtimon|I tried that too
 924 2016-10-20 19:38:23	0|Chris_Stewart_5|always one sipa..
 925 2016-10-20 19:38:53	0|jtimon|but some people asked for the final API...
 926 2016-10-20 19:38:54	0|sipa|i'd really just want to see a proposal of a directory structure
 927 2016-10-20 19:39:01	0|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.
 928 2016-10-20 19:39:12	0|sipa|which explains code responsible for what belongs where
 929 2016-10-20 19:39:20	0|jtimon|sipa: I gave you one: all consensus fles except those in crypto to the consensus dir
 930 2016-10-20 19:39:28	0|sipa|jtimon: that's not an answer
 931 2016-10-20 19:39:36	0|jtimon|it is one you don't like
 932 2016-10-20 19:39:39	0|sipa|there is code shared between consensus and non-consensus
 933 2016-10-20 19:39:47	0|sipa|what happens to script? is it split up again?
 934 2016-10-20 19:39:51	0|sipa|where does the signing code go?
 935 2016-10-20 19:40:02	0|jtimon|but I really don't see how can we make a subrepository or subtree out of libconsensus otherwise
 936 2016-10-20 19:40:04	0|kanzure|sipa did you read jtimon's libconsensus doc by any chance
 937 2016-10-20 19:40:05	0|sipa|do we duplicate consensu logic?
 938 2016-10-20 19:40:10	0|jtimon|sipa: signing code is not consensus
 939 2016-10-20 19:40:14	0|sipa|sigh
 940 2016-10-20 19:40:18	0|sipa|i know that
 941 2016-10-20 19:40:30	0|jtimon|it remains in the common package
 942 2016-10-20 19:40:41	0|jtimon|and the script dir
 943 2016-10-20 19:40:52	0|sipa|ok, i'll shut up about it
 944 2016-10-20 19:41:01	0|wumpus|I think this is monipolizing the meeting. ANy othe topics to be discussed?
 945 2016-10-20 19:41:04	0|sipa|i can't seem to get my point across
 946 2016-10-20 19:41:15	0|jtimon|no, you brought this point more times
 947 2016-10-20 19:41:23	0|CodeShark|can we set as a goal to prioritize some moveonly PRs?
 948 2016-10-20 19:41:29	0|sipa|yes, and i have never seen you give an answer to my question
 949 2016-10-20 19:41:47	0|CodeShark|sipa, jtimon, let's save that for after the meeting
 950 2016-10-20 19:42:27	0|CodeShark|can we agree for the time being to define a directory structure and prioritize moveonly PRs?
 951 2016-10-20 19:42:36	0|jtimon|sure I really want to understand his concerns better. It seems related to the discussion we had around luke's script "debugger"
 952 2016-10-20 19:42:43	0|wumpus|I can't prioritize moveonly PRs. There's just too much happening
 953 2016-10-20 19:42:57	0|CodeShark|wumpus: the idea is that they should be super simple to review
 954 2016-10-20 19:43:05	0|sipa|CodeShark: you underestimate it
 955 2016-10-20 19:43:14	0|michagogo|achow101: looks like it finished uploading, if you want to try it
 956 2016-10-20 19:43:20	0|sipa|moving the code is easy. deciding where things belong is not.
 957 2016-10-20 19:43:21	0|wumpus|but if people prioritize reviewing them, sure
 958 2016-10-20 19:43:23	0|kanzure|oh is review the bottleneck? i keep thinking it's "lots of other rebase work" for other pulls.
 959 2016-10-20 19:43:37	0|jtimon|wumpus: I think it being a priority for reviewers is more important
 960 2016-10-20 19:43:39	0|wumpus|kanzure: that's also an issue
 961 2016-10-20 19:43:40	0|sipa|kanzure: imho the bottleneck is no agreement about what should be done
 962 2016-10-20 19:43:41	0|michagogo|Wait, it's Thursday... sorry, didn't realize meeting was happening
 963 2016-10-20 19:43:52	0|jtimon|kanzure: I strongly feel review is the bottleneck
 964 2016-10-20 19:44:17	0|instagibbs_|proposed topic: rc2 issues, etc?
 965 2016-10-20 19:44:19	0|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.
 966 2016-10-20 19:44:30	0|kanzure|oh. alright.
 967 2016-10-20 19:44:32	0|jtimon|CodeShark: also I think you understimate the potential for disagreements
 968 2016-10-20 19:44:34	0|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?
 969 2016-10-20 19:44:54	0|CodeShark|can we at least agree to start discussing a directory structure? ;)
 970 2016-10-20 19:45:00	0|CodeShark|(after this meeting, of course)
 971 2016-10-20 19:45:03	0|jtimon|CodeShark: ACK
 972 2016-10-20 19:45:32	0|wumpus|Chris_Stewart_5: you tell me
 973 2016-10-20 19:45:42	0|morcos|Someone should schedule a small in-person retreat for people who really want to work on libconsensus, to make some headway
 974 2016-10-20 19:45:57	0|kanzure|Chris_Stewart_5: perhaps sipa could make a proposal if we ask nicely.
 975 2016-10-20 19:46:01	0|jtimon|I already buried my hopes of libconsensus becoming eventually C
 976 2016-10-20 19:46:01	0|wumpus|Chris_Stewart_5: preventing the topic from being discussed is quite easy, but I think that would be seen as censorship :)
 977 2016-10-20 19:46:05	0|Chris_Stewart_5|This is ALL libbconsensus right? Is tehre any concrete proposals?
 978 2016-10-20 19:46:25	0|instagibbs_|14 minutes in case anyone wants to discuss anything else
 979 2016-10-20 19:46:41	0|jtimon|Chris_Stewart_5: afaik the most concrete proposal right now is #8493
 980 2016-10-20 19:46:42	0|wumpus|instagibbs_: I asked in the beginning, don't think there's any issues with rc2 yet
 981 2016-10-20 19:46:45	0|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
 982 2016-10-20 19:47:04	0|Chris_Stewart_5|Thanks, i'll take a look at it.
 983 2016-10-20 19:47:16	0|kanzure|ah 8493 is expose verifyheader. ok.
 984 2016-10-20 19:47:21	0|instagibbs_|wumpus: ok great
 985 2016-10-20 19:48:07	0|CodeShark|so any other topics?
 986 2016-10-20 19:48:08	0|Chris_Stewart_5|rc2 issues?
 987 2016-10-20 19:48:17	0|wumpus|which rc2 issues?
 988 2016-10-20 19:48:41	0|BlueMatt|the lack of rc2 issues =D
 989 2016-10-20 19:48:43	0|Chris_Stewart_5|*crickets*
 990 2016-10-20 19:48:50	0|wumpus|19:46 < wumpus> instagibbs_: I asked in the beginning, don't think there's any issues with rc2 yet
 991 2016-10-20 19:48:59	0|kanzure|i think he was asking to hear for any
 992 2016-10-20 19:49:01	0|wumpus|if there are, feel free to say so
 993 2016-10-20 19:49:14	0|achow101|what about killing off windows 32 bit builds?
 994 2016-10-20 19:49:31	0|jonasschnelli|I guess in 0.15
 995 2016-10-20 19:49:33	0|wumpus|that's not an urgent topic really
 996 2016-10-20 19:49:36	0|wumpus|yes, 0.15 I'd say too
 997 2016-10-20 19:50:10	0|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
 998 2016-10-20 19:50:24	0|sipa|are there likely some who don't know?
 999 2016-10-20 19:50:30	0|wumpus|they both expected this to stilll last only 6 months or so no longer
1000 2016-10-20 19:50:31	0|wumpus|old hw
1001 2016-10-20 19:50:36	0|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.
1002 2016-10-20 19:50:52	0|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
1003 2016-10-20 19:50:54	0|wumpus|so that would time with 0.15, which is fine with me, no hurry
1004 2016-10-20 19:51:27	0|Victorsueca|gmaxwell: the lastest travis build seems to have failed for master
1005 2016-10-20 19:51:31	0|instagibbs_|jonasschnelli: yeah i suggested this a bit ago
1006 2016-10-20 19:51:43	0|jonasschnelli|25 blocks as "normal" confirmation speed sounds ridiculous
1007 2016-10-20 19:51:45	0|achow101|jonasschnelli: I think it's a good idea
1008 2016-10-20 19:51:47	0|instagibbs_|i dont understand why having different command line and GUI behavior like that is "good"
1009 2016-10-20 19:51:57	0|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
1010 2016-10-20 19:52:13	0|jonasschnelli|Yes. I fear that as well. :)
1011 2016-10-20 19:52:15	0|sipa|it seems reasonable that the default in gui and rpc is the same
1012 2016-10-20 19:52:19	0|instagibbs_|morcos: "match between command-line and GUI" is a starting point :)
1013 2016-10-20 19:52:21	0|BlueMatt|jonasschnelli: I'm for 25
1014 2016-10-20 19:52:23	0|BlueMatt|25 is good
1015 2016-10-20 19:52:24	0|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
1016 2016-10-20 19:52:26	0|jonasschnelli|And the slider should probably not touch nTxConfirmTarget!
1017 2016-10-20 19:52:30	0|jonasschnelli|global!
1018 2016-10-20 19:52:31	0|morcos|then you might have to pay areally high fee
1019 2016-10-20 19:52:33	0|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.
1020 2016-10-20 19:52:37	0|morcos|which is priobably not what you want
1021 2016-10-20 19:53:01	0|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
1022 2016-10-20 19:53:13	0|morcos|more intelligent fee estimation would maybe gauge the current conditions against historical conditions or something.
1023 2016-10-20 19:53:21	0|gmaxwell|Is anyone working on improving the estimator generally, right now?
1024 2016-10-20 19:53:34	0|jonasschnelli|I think there are some users fooled by the fact that RPCs sendto* uses different fee estimations then the "default" GUI send method.
1025 2016-10-20 19:53:46	0|gmaxwell|It could use improvement, though I think bumping is more important.
1026 2016-10-20 19:53:49	0|jonasschnelli|I mean only different confirmations targets
1027 2016-10-20 19:53:53	0|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
1028 2016-10-20 19:54:01	0|MarcoFalke|ok
1029 2016-10-20 19:54:02	0|jonasschnelli|Someone should review the new bumpfee PR.
1030 2016-10-20 19:54:18	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8456
1031 2016-10-20 19:54:25	0|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
1032 2016-10-20 19:54:29	0|morcos|but nothing that really got polished
1033 2016-10-20 19:54:35	0|wumpus|yes, we *must* have a bumpfee for 0.14
1034 2016-10-20 19:54:40	0|kanzure|morcos: had you looked at bramc's work on fee estimation?
1035 2016-10-20 19:55:36	0|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.
1036 2016-10-20 19:55:45	0|morcos|But an algorithm for bumping when you guess too low makes sense.
1037 2016-10-20 19:56:09	0|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.
1038 2016-10-20 19:56:40	0|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
1039 2016-10-20 19:57:04	0|gmaxwell|I was just wondering if there was anything ongoing at the moment.
1040 2016-10-20 19:57:11	0|gmaxwell|(since the subject came up)
1041 2016-10-20 19:57:11	0|jonasschnelli|What about changing the default confirmation target to 6 for RPC interface and the GUI once we have the bumpfee cmd?
1042 2016-10-20 19:57:16	0|Victorsueca|as example, most of my transactions where I set the fee slider to 25 it confirmed on the next 2 blocks
1043 2016-10-20 19:57:23	0|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
1044 2016-10-20 19:57:31	0|jonasschnelli|Victorsueca: users made different experiences with that
1045 2016-10-20 19:57:51	0|gmaxwell|morcos: And that is what it must do, esp when there is no bump. :)
1046 2016-10-20 19:57:51	0|morcos|thats why i hesitate to set the default to 2
1047 2016-10-20 19:58:08	0|jtimon|2 mins
1048 2016-10-20 19:58:20	0|morcos|jonasschnelli: i like 6, and i'd be fine with that....
1049 2016-10-20 19:58:26	0|instagibbs_|overpaying is fine until we have bump, heh
1050 2016-10-20 19:58:31	0|gmaxwell|I would be too.
1051 2016-10-20 19:58:47	0|Victorsueca|jonasschnelli: yeah, I seen too lots of people blaming slow transactions even with recommended fee, but not my case for some reason
1052 2016-10-20 19:58:49	0|CodeShark|wouldn't overpaying tend to raise fees up?
1053 2016-10-20 19:59:05	0|CodeShark|for everyone
1054 2016-10-20 19:59:20	0|wumpus|only if everyone is going to do that
1055 2016-10-20 19:59:21	0|morcos|CodeShark: ah, that is one of bramc's concerns.  i think the existing algo is pretty resistant to that
1056 2016-10-20 19:59:30	0|jtimon|CodeShark: I could think of some kind of overpaying race
1057 2016-10-20 19:59:31	0|jonasschnelli|Most important is probably review of mrbandrews's bumpfee (https://github.com/bitcoin/bitcoin/pull/8456)
1058 2016-10-20 19:59:36	0|morcos|yes unless literally everyone does it
1059 2016-10-20 19:59:39	0|MarcoFalke|We should just set it to a random value *ducks*
1060 2016-10-20 19:59:40	0|instagibbs_|Assuming everyone is transacting at the same exact time, sure. But there's time preferences in real life, week/weekend patterns
1061 2016-10-20 19:59:41	0|instagibbs_|etc
1062 2016-10-20 19:59:55	0|wumpus|instagibbs_: +1
1063 2016-10-20 19:59:58	0|instagibbs_|bitcoin businesses will do settlement on sunday evening to avoid fees
1064 2016-10-20 20:00:01	0|sipa|TINGELINGELING
1065 2016-10-20 20:00:08	0|wumpus|#endmeeting
1066 2016-10-20 20:00:09	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-20-19.00.log.html
1067 2016-10-20 20:00:09	0|lightningbot|Meeting ended Thu Oct 20 20:00:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
1068 2016-10-20 20:00:09	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-20-19.00.html
1069 2016-10-20 20:00:09	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-20-19.00.txt
1070 2016-10-20 20:00:26	0|instagibbs_|I mean they *do* today, not just hypoethical.
1071 2016-10-20 20:00:32	0|kanzure|am interested to see resolution to jtimon/sipa concerns at some point
1072 2016-10-20 20:00:56	0|jonasschnelli|I think we want resolution on the long term plan since 2 years or more. :)
1073 2016-10-20 20:01:17	0|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
1074 2016-10-20 20:01:41	0|sipa|jtimon: i'll write my question done in a more detailed and clear way, then
1075 2016-10-20 20:01:44	0|instagibbs_|urgh, my 0.13.1 rc1 node has *0* segwit connections
1076 2016-10-20 20:01:44	0|kanzure|jtimon, perhaps illustrate with an old pull request that shows a code move that matches what you are trying to explain
1077 2016-10-20 20:01:44	0|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
1078 2016-10-20 20:01:54	0|sipa|kanzure: NO
1079 2016-10-20 20:01:58	0|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.
1080 2016-10-20 20:01:58	0|sipa|kanzure: i don't want to see code
1081 2016-10-20 20:02:00	0|morcos|wumpus: yes agree entirely
1082 2016-10-20 20:02:11	0|gmaxwell|instagibbs_: yea, apply rc2 directly to forehead.
1083 2016-10-20 20:02:13	0|sipa|kanzure: the code to move things is huge, but trivial
1084 2016-10-20 20:02:18	0|jtimon|I believe some code duplication is unavoidable once bitcoin core only talks to libconsensus' C API, for example, the primitives
1085 2016-10-20 20:02:58	0|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.
1086 2016-10-20 20:03:06	0|instagibbs_|gmaxwell: yeah, a little surprising to me how unaggressive behavior was
1087 2016-10-20 20:03:07	0|kanzure|(or i misunsterood a comment from a few minutes ago)
1088 2016-10-20 20:03:24	0|sipa|kanzure: hmm, at this point i do not suggest creating another library
1089 2016-10-20 20:03:37	0|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
1090 2016-10-20 20:03:39	0|instagibbs_|Speaking of which what is the intention of having outgoing connections that can't serve you data you want at all?
1091 2016-10-20 20:03:43	0|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
1092 2016-10-20 20:04:00	0|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...
1093 2016-10-20 20:04:09	0|sipa|jtimon: i'll write some things down... now lunchtime
1094 2016-10-20 20:04:23	0|jtimon|sure, np
1095 2016-10-20 20:04:36	0|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
1096 2016-10-20 20:05:27	0|gmaxwell|morcos: yes. Though that control loop may be rather slow.
1097 2016-10-20 20:06:01	0|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
1098 2016-10-20 20:06:11	0|instagibbs_|wumpus: and I don't think that's likely as long as there exists different time preferences alone
1099 2016-10-20 20:06:16	0|instagibbs_|which clearly exist
1100 2016-10-20 20:06:24	0|wumpus|Victorsueca: some people would find the fee unacceptable and choose a longer confirmation period
1101 2016-10-20 20:07:05	0|wumpus|not everyone cares for transactions to confirm very quickly, and wants to pay a premium for that
1102 2016-10-20 20:07:37	0|Victorsueca|wumpus: right, I guess that force would balance the whole thing
1103 2016-10-20 20:07:50	0|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
1104 2016-10-20 20:08:11	0|wumpus|jtimon: we have a problem with review everywhere, unfortunately
1105 2016-10-20 20:08:40	0|CodeShark|as sipa said, deciding where the code should go is the hard part - moving it is easy
1106 2016-10-20 20:08:51	0|wumpus|jtimon: after all the time we've not really managed to find morepeople that will review code changes
1107 2016-10-20 20:08:52	0|jtimon|kanzure: by libconsensus++ I mean another library that calls the basic libconsensus, but it also handles storage and processes blocks
1108 2016-10-20 20:09:10	0|wumpus|jtimon: sometimes I despair a bit
1109 2016-10-20 20:09:14	0|CodeShark|the review that's needed is on the directory structure and unit definitions - the moveonly PRs are easy
1110 2016-10-20 20:09:27	0|Victorsueca|CodeShark: move it all to /dev/null lol that would be easy
1111 2016-10-20 20:09:48	0|jtimon|CodeShark: well, after the easy moveonlies
1112 2016-10-20 20:09:57	0|Victorsueca|unfortunately the real thing is not that easy
1113 2016-10-20 20:10:13	0|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
1114 2016-10-20 20:10:22	0|jtimon|there's little parts that you want to take, mostly from ConnectBlock
1115 2016-10-20 20:10:58	0|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
1116 2016-10-20 20:11:09	0|wumpus|jtimon: I have honestly no idea how to better organize this, or to find people that will help
1117 2016-10-20 20:11:19	0|jtimon|wumpus: I understand, we have a big bottleneck in review in general
1118 2016-10-20 20:11:32	0|CodeShark|the majority of the work that's needed here is not in writing code, though
1119 2016-10-20 20:11:38	0|CodeShark|nor reviewing code
1120 2016-10-20 20:11:41	0|CodeShark|it's more conceptual
1121 2016-10-20 20:12:27	0|kanzure|i suppose my last message is more re: large refactors, more than it is about moves.
1122 2016-10-20 20:12:43	0|wumpus|kanzure: that's certainly a dynamic that happens, large changes were delayed until after segwit to avoid giving segwit devs extra work
1123 2016-10-20 20:12:45	0|CodeShark|how should we pull out different units? what are their interdependencies? how should our directory structure look?
1124 2016-10-20 20:12:58	0|kanzure|wumpus: sure. yes.
1125 2016-10-20 20:13:01	0|jtimon|my intuition is that we simply need more developers. at first they may be more review demanding, but later they review too
1126 2016-10-20 20:13:18	0|CodeShark|we're talking design decisions here, though - not so much code
1127 2016-10-20 20:13:31	0|wumpus|jtimon: we have plenty of people writing pulls, though much fewer thtat do useful review
1128 2016-10-20 20:13:51	0|CodeShark|once we agree on the design decisions, writing and reviewing code will go much more smoothly
1129 2016-10-20 20:13:58	0|wumpus|maybe we should add a rule that for every pull you submit youshould thoroughly review another one :p
1130 2016-10-20 20:14:05	0|morcos|wumpus: 5
1131 2016-10-20 20:14:08	0|instagibbs_|heh :) review without writing is hard though
1132 2016-10-20 20:14:13	0|kanzure|wumpus: unfortunately that degrades into a quid pro quo situation
1133 2016-10-20 20:14:18	0|CodeShark|but if we keep bikeshedding on design decisions while reviewing PRs it will never happen
1134 2016-10-20 20:14:19	0|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
1135 2016-10-20 20:14:19	0|kanzure|or a quid pro quo review scheme or something
1136 2016-10-20 20:14:42	0|jtimon|it can have subdirs, sure, but I'm not convinced it will need them
1137 2016-10-20 20:15:15	0|CodeShark|the directory structure needn't be cast in stone - it just needs to be something that works well enough for now
1138 2016-10-20 20:15:33	0|CodeShark|anything is better than stuffing everything into main.cpp :p
1139 2016-10-20 20:15:49	0|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
1140 2016-10-20 20:16:02	0|jtimon|sorry for showing code, but this is what I would do first "for cheap": https://github.com/bitcoin/bitcoin/pull/8328
1141 2016-10-20 20:16:17	0|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
1142 2016-10-20 20:16:25	0|CodeShark|but that's still a ways off
1143 2016-10-20 20:16:35	0|wumpus|CodeShark: re: splitting up main see https://github.com/bitcoin/bitcoin/pull/8969
1144 2016-10-20 20:16:47	0|wumpus|Victorsueca: ad campaigns?!
1145 2016-10-20 20:16:59	0|kanzure|Victorsueca: core itself did not run ad campaigns.....
1146 2016-10-20 20:17:03	0|wumpus|Victorsueca: I can tell you the bitcoin core project has 0 bitcoins
1147 2016-10-20 20:17:14	0|kanzure|wumpus: oh it's broke! :)
1148 2016-10-20 20:17:28	0|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
1149 2016-10-20 20:17:30	0|Victorsueca|I mean the thing that was collected on r/bitcoin
1150 2016-10-20 20:17:35	0|kanzure|r/bitcoin is unrelated
1151 2016-10-20 20:17:54	0|Victorsueca|yeah, but they engage people into giving idea on what to spend the remaining
1152 2016-10-20 20:17:59	0|Victorsueca|ideas*
1153 2016-10-20 20:18:15	0|MarcoFalke|What happened to the coins gavin used to give out for testing patches?
1154 2016-10-20 20:18:27	0|instagibbs_|he gave them away
1155 2016-10-20 20:19:16	0|wumpus|either they were from the bitcoin foundation or Gavin paid that out of his own pocket, I don't know
1156 2016-10-20 20:19:19	0|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
1157 2016-10-20 20:20:02	0|CodeShark|I'm not even thinking libconsensus yet :p
1158 2016-10-20 20:20:37	0|jtimon|ok, BlueMatt, let's say I'm an SPV wallet that only wants to use libbitcoin for verifyScript, verifyHeader and getConsensusFlags
1159 2016-10-20 20:21:27	0|jtimon|how does verifyHeader gets the block if I'm never calling libconsensus' processBlock? I just have headers and txs, never full blocks
1160 2016-10-20 20:21:51	0|sipa|if you have a blockheaderstore you can provide it with the headers
1161 2016-10-20 20:22:02	0|jtimon|I see
1162 2016-10-20 20:22:05	0|BlueMatt|jtimon: you can do processheader
1163 2016-10-20 20:22:12	0|BlueMatt|which i guess is what sipa said
1164 2016-10-20 20:22:32	0|jtimon|yeah, both options are equivalent, yeah, you could do that
1165 2016-10-20 20:22:38	0|sipa|right... though i wouldn't mind having a way to just verify a header without processing it
1166 2016-10-20 20:22:45	0|sipa|just a different level api
1167 2016-10-20 20:23:12	0|sipa|but you'll still need a way to load headers into the black box state object in that case, independently from processheader
1168 2016-10-20 20:23:42	0|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
1169 2016-10-20 20:27:58	0|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
1170 2016-10-20 20:31:30	0|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"
1171 2016-10-20 20:33:48	0|jtimon|it feels bad to break the script dir in 2, but I don't feel bad about moving the primitives, for example
1172 2016-10-20 20:33:48	0|Victorsueca|jtimon: maybe inside the consensus dir make a subdir for those required to validate the consensus rules that where there since the beginning
1173 2016-10-20 20:34:27	0|Victorsueca|then another subdir for those required to validate some BIP-specific rules
1174 2016-10-20 20:34:30	0|jtimon|Victorsueca: that's most of them, I think handling deployments with flags is just fine
1175 2016-10-20 20:34:58	0|Victorsueca|hmmm
1176 2016-10-20 20:36:14	0|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
1177 2016-10-20 20:37:26	0|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....
1178 2016-10-20 20:38:15	0|Victorsueca|I think I just duped libraries on different subdirs right?
1179 2016-10-20 20:40:26	0|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
1180 2016-10-20 20:40:47	0|jtimon|well, some of that stuff is already separated as files
1181 2016-10-20 20:41:14	0|jtimon|for others that isn't I think a single file is probably fine
1182 2016-10-20 20:42:39	0|jtimon|anyway, I'll go back to try to find what's wrong with my new testchain...
1183 2016-10-20 20:42:44	0|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
1184 2016-10-20 20:44:29	0|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)
1185 2016-10-20 21:12:02	0|achow101|michagogo: what's the password for bob with your vm?
1186 2016-10-20 21:13:46	0|Lightsword|hmm, my testnet node is stuck
1187 2016-10-20 21:14:28	0|Lightsword|GBT won’t start since it’s stuck on downloading blocks
1188 2016-10-20 21:16:36	0|achow101|michagogo: also, is build.sh your build script?
1189 2016-10-20 22:01:17	0|michagogo|achow101: It's gitian
1190 2016-10-20 22:01:24	0|michagogo|(that's in the description, too)
1191 2016-10-20 22:01:37	0|michagogo|And yeah, that's the script I use for building
1192 2016-10-20 22:01:55	0|michagogo|It requires a bit of customization (basically, add your name)
1193 2016-10-20 22:02:18	0|michagogo|It does the whole build process
1194 2016-10-20 22:03:08	0|michagogo|Run it, and it takes care of fetching the tag you give it, building, committing, pushing, and even creating the PR
1195 2016-10-20 22:03:22	0|michagogo|(that last part also requires you to create a GitHub token)
1196 2016-10-20 22:22:04	0|michagogo|Lauda: ICYMI, my prepackaged gitian builder VM is up at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
1197 2016-10-20 22:22:17	0|michagogo|Along with a video showing how I made it, start to finish
1198 2016-10-20 22:22:39	0|michagogo|(1 hour, from initial boot from Ubuntu 14.04.5 ISO, including trial and error)
1199 2016-10-20 22:22:49	0|michagogo|(and looking stuff up outside the VM)
1200 2016-10-20 22:23:12	0|michagogo|achow101: Did you get a chance to try it? Did it work for you?
1201 2016-10-20 22:25:30	0|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 :-/
1202 2016-10-20 22:52:55	0|molz|michagogo, can't see the file, have to have a MS account
1203 2016-10-20 22:53:02	0|michagogo|molz: Really?
1204 2016-10-20 22:53:03	0|michagogo|Hm.
1205 2016-10-20 22:53:13	0|michagogo|I seem to be able to open it in incognito...
1206 2016-10-20 22:53:56	0|michagogo|Oh, hmm.
1207 2016-10-20 22:54:01	0|molz|oh  i can download it
1208 2016-10-20 22:54:08	0|michagogo|Okay, do you have a better way for me to get it to you?
1209 2016-10-20 22:56:21	0|michagogo|Maybe I'll make a torrent of it -- does someone have a seedbox that can take ~3.6 GB?
1210 2016-10-20 23:05:15	0|molz|michagogo, i'm downloading Gitianbuilder.7z
1211 2016-10-20 23:08:40	0|michagogo|Ah, it's working? Great
1212 2016-10-20 23:39:40	0|molz|michagogo, sorry i was afk, but no, i got "network error", can't download Gititanbuilder.7z