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