12016-10-20T00:05:22 *** Alina-malina has quit IRC
22016-10-20T00:09:22 *** Alina-malina has joined #bitcoin-core-dev
32016-10-20T00:15:17 *** cbit has quit IRC
42016-10-20T00:23:45 *** alpalp has quit IRC
52016-10-20T00:31:17 *** alpalp has joined #bitcoin-core-dev
62016-10-20T00:34:36 *** d_t has quit IRC
72016-10-20T00:44:53 *** cbit has joined #bitcoin-core-dev
82016-10-20T00:53:32 *** AaronvanW has quit IRC
92016-10-20T01:03:49 *** cbit has quit IRC
102016-10-20T01:25:38 *** jujumax has joined #bitcoin-core-dev
112016-10-20T01:32:12 <wumpus> "graphics acceleration at 9.81 m/s^2" hahahah genius
122016-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"
132016-10-20T01:33:44 <sipa> also, why are you awake?
142016-10-20T01:34:04 <sipa> i have an excuse, it's 6:30 pm here.
152016-10-20T01:35:12 <wumpus> I have no excuse
162016-10-20T01:35:26 <wumpus> it's eh 03:35 here :D
172016-10-20T01:38:03 *** Yogh_ has quit IRC
182016-10-20T01:38:46 *** Yogh has joined #bitcoin-core-dev
192016-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
202016-10-20T01:45:56 *** fengling has joined #bitcoin-core-dev
212016-10-20T02:03:17 *** jujumax has quit IRC
222016-10-20T02:22:07 *** wasi has quit IRC
232016-10-20T02:23:02 *** DigiByteDev has joined #bitcoin-core-dev
242016-10-20T02:26:48 *** wasi has joined #bitcoin-core-dev
252016-10-20T02:27:31 *** instagibbs has quit IRC
262016-10-20T02:30:18 *** Victorsueca has quit IRC
272016-10-20T02:32:02 *** shaiguit1r has quit IRC
282016-10-20T02:32:14 *** shaiguitar has joined #bitcoin-core-dev
292016-10-20T02:38:54 *** davec has quit IRC
302016-10-20T02:39:12 *** davec has joined #bitcoin-core-dev
312016-10-20T02:40:12 *** rebroad has quit IRC
322016-10-20T02:46:12 *** Alopex has quit IRC
332016-10-20T02:47:17 *** Alopex has joined #bitcoin-core-dev
342016-10-20T02:49:13 *** alpalp has quit IRC
352016-10-20T02:55:04 *** rebroad has joined #bitcoin-core-dev
362016-10-20T03:01:10 <wumpus> rc2 executables up https://bitcoin.org/bin/bitcoin-core-0.13.1/test.rc2/
372016-10-20T03:01:39 <achow101> Did the release email go out?
382016-10-20T03:01:45 <wumpus> no
392016-10-20T03:02:16 <achow101> ok. Shouldn't you be asleep?
402016-10-20T03:02:31 <wumpus> could announce the rc on mailng list, but an rc does not warrant a 'release email'
412016-10-20T03:03:27 <wumpus> this is only a test, not a release yet
422016-10-20T03:04:00 <achow101> i meant like the email saying that the rc exists.
432016-10-20T03:04:02 <achow101> like https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-August/000017.html
442016-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
452016-10-20T03:05:11 <achow101> oh ok
462016-10-20T03:05:49 *** Alina-malina has quit IRC
472016-10-20T03:08:08 <wumpus> good time to sneak out a rc2 mail though while the US is distracted with their clown show :)
482016-10-20T03:18:11 *** Alopex has quit IRC
492016-10-20T03:19:16 *** Alopex has joined #bitcoin-core-dev
502016-10-20T03:33:49 *** MarcoFalke has joined #bitcoin-core-dev
512016-10-20T03:53:06 *** To7 has quit IRC
522016-10-20T04:00:52 *** MarcoFalke has left #bitcoin-core-dev
532016-10-20T04:07:35 *** Chris_Stewart_5 has quit IRC
542016-10-20T04:16:07 *** wasi has quit IRC
552016-10-20T04:16:49 *** wasi has joined #bitcoin-core-dev
562016-10-20T04:44:45 *** aalex has quit IRC
572016-10-20T04:48:26 *** aalex has joined #bitcoin-core-dev
582016-10-20T04:57:05 *** Alina-malina has joined #bitcoin-core-dev
592016-10-20T05:00:12 *** dermoth has quit IRC
602016-10-20T05:01:05 *** dermoth has joined #bitcoin-core-dev
612016-10-20T05:04:39 *** Giszmo has quit IRC
622016-10-20T05:07:40 *** DigiByteDev has quit IRC
632016-10-20T05:08:28 *** jtimon has quit IRC
642016-10-20T05:31:57 <NicolasDorier> passing flag CLEAN_STACK to libconsensus seems to make crash the whole process.
652016-10-20T05:32:13 *** tunafizz has joined #bitcoin-core-dev
662016-10-20T05:33:12 <NicolasDorier> somehow https://github.com/bitcoin/bitcoin/blob/v0.13.1rc2/src/test/data/script_tests.json#L1831
672016-10-20T05:33:15 <NicolasDorier> now crash
682016-10-20T05:33:21 <NicolasDorier> when using libconsensus
692016-10-20T05:33:36 <NicolasDorier> trying to deep what it going on
702016-10-20T05:33:41 <NicolasDorier> dig
712016-10-20T05:34:51 <wumpus> strange
722016-10-20T05:35:01 <wumpus> on master or 0.13.1?
732016-10-20T05:35:11 <jl2012> does libconsensus has CLEANSTACK flag?
742016-10-20T05:35:13 <NicolasDorier> downloaded libconsensus from https://bitcoin.org/bin/bitcoin-core-0.13.1/test.rc2/
752016-10-20T05:35:31 <jl2012> i thought it only has consensus critical flags?
762016-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
772016-10-20T05:36:05 <wumpus> no, it doesn't
782016-10-20T05:36:31 <wumpus> https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h#L50
792016-10-20T05:36:45 <wumpus> that doesn't crashing is a valid outcome ofcourse
802016-10-20T05:37:11 <NicolasDorier> and it is not the cause https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.cpp#L88
812016-10-20T05:37:14 <jl2012> using CLEANSTACK without WITNESS would fail assertion?
822016-10-20T05:37:19 <NicolasDorier> the flags is converted into SCRIPT_VERIFY
832016-10-20T05:37:25 <NicolasDorier> not really using the libconsensus flags at all
842016-10-20T05:39:00 <wumpus> can you post a traceback?
852016-10-20T05:39:46 <jl2012> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1505
862016-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
872016-10-20T05:41:17 <wumpus> don't ask me how to do debugging on windows :)
882016-10-20T05:41:36 <jl2012> NicolasDorier: what would happen if you add a WITNESS flag to the test?
892016-10-20T05:41:48 <NicolasDorier> trying that
902016-10-20T05:41:50 <NicolasDorier> one sec
912016-10-20T05:42:59 <NicolasDorier> jl2012: with the flag, no crash
922016-10-20T05:43:54 <jl2012> so that's the reason
932016-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 ?
942016-10-20T05:44:36 <jl2012> sipa: we should add WITNESS flag to all tests with CLEANSTACK
952016-10-20T05:44:48 <jl2012> NicolasDorier: I'm also wondering the same
962016-10-20T05:45:15 <jl2012> maybe it failed before the assertion at L1505 is triggered
972016-10-20T05:45:49 <NicolasDorier> yeah, and why did it not failed before when using libconsensus OO
982016-10-20T05:45:52 <NicolasDorier> checking
992016-10-20T05:46:58 <jl2012> to fix it, search all tests with CLEANSTACK. They should all have P2SH and WITNESS
1002016-10-20T05:47:08 <jl2012> also, all tests with WITNESS must have P2SH
1012016-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
1022016-10-20T05:48:07 <jl2012> with all 3 flags?
1032016-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
1042016-10-20T05:49:50 <wumpus> yes, that is really strange
1052016-10-20T05:52:05 <NicolasDorier> jl2012: also I don't understand why WITNESS should be set at all cost if CLEANSTACK is set
1062016-10-20T05:53:22 <NicolasDorier> I think adding WITNESS to all CLEANSTACK test is the wrong way
1072016-10-20T05:53:35 <NicolasDorier> CLEANSTACK | P2SH should not fail
1082016-10-20T05:54:02 <wumpus> well the P2SH rationale is explained
1092016-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)."
1102016-10-20T05:54:18 <wumpus> don't know about WITNESS
1112016-10-20T05:54:23 <NicolasDorier> yes for P2SH not a problem
1122016-10-20T05:54:35 *** rebroad has quit IRC
1132016-10-20T05:54:45 *** aalex has quit IRC
1142016-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
1152016-10-20T05:56:42 <jl2012> Witness script is violation of cleanstack
1162016-10-20T05:57:36 <NicolasDorier> wumpus: oh thanks
1172016-10-20T05:57:40 <wumpus> that explains why the C++ tests do pass, updating the tests would have been clearer.
1182016-10-20T05:58:00 <NicolasDorier> I still think that CLEANSTACK | P2SH should not crash
1192016-10-20T05:58:10 <NicolasDorier> even without this test change
1202016-10-20T05:58:26 *** aalex has joined #bitcoin-core-dev
1212016-10-20T05:59:20 <jl2012> It's only a problem if we had a cleanstack softfork before witness
1222016-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
1232016-10-20T06:01:14 <NicolasDorier> now, if they just update the library, their code will crash
1242016-10-20T06:01:41 <NicolasDorier> even if witness is not activated
1252016-10-20T06:02:48 <jl2012> Then we need to remove that assert
1262016-10-20T06:03:41 <NicolasDorier> I think we should yes
1272016-10-20T06:03:42 <wumpus> but CLEANSTACK isn't even part of the libconsensus API
1282016-10-20T06:04:04 <wumpus> you've been relying on undocumented behavior, that can change from release to release
1292016-10-20T06:04:30 <NicolasDorier> mh good point
1302016-10-20T06:04:44 <wumpus> I don't think crashing with an assert is any good way of error handling , but still
1312016-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.
1322016-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
1332016-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
1342016-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.
1352016-10-20T06:10:20 <wumpus> guaranteeing one bug-for-bug compatible interface (the consensus itself) ought to be enough of a challenge
1362016-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"
1372016-10-20T06:11:03 <wumpus> but why do you really need this?
1382016-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
1392016-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
1402016-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.
1412016-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
1422016-10-20T06:13:39 <NicolasDorier> yes I understand. So might be good to do it now before libconsensus is too much use
1432016-10-20T06:13:42 <wumpus> may warrant mentioniong in the release notes then
1442016-10-20T06:13:43 <NicolasDorier> is not
1452016-10-20T06:29:19 <wumpus> ugh, even our own tests make use of this undocumented API
1462016-10-20T06:34:32 *** Alina-malina has quit IRC
1472016-10-20T06:34:32 *** Alina-malina has joined #bitcoin-core-dev
1482016-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
1492016-10-20T06:49:04 *** rebroad has joined #bitcoin-core-dev
1502016-10-20T06:50:06 *** molz has quit IRC
1512016-10-20T06:50:32 *** moli has joined #bitcoin-core-dev
1522016-10-20T06:52:39 *** nickler has quit IRC
1532016-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
1542016-10-20T06:57:34 *** BashCo has quit IRC
1552016-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)
1562016-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.
1572016-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
1582016-10-20T06:58:51 <wumpus> I think the point is that only consensus flags are offered, the rest is kind of arbitrary
1592016-10-20T06:59:05 <wumpus> but uhm, we'd have to change our approach to testing at least then
1602016-10-20T06:59:39 *** nickler has joined #bitcoin-core-dev
1612016-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
1622016-10-20T07:00:43 <wumpus> I hope that will be separated in the future
1632016-10-20T07:02:11 <wumpus> and maybe add a libbitcoin_policy for the other things :-)
1642016-10-20T07:04:58 <GitHub91> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c5875773561c...f2d705629b51
1652016-10-20T07:04:59 <GitHub91> bitcoin/master cb08fdb Pedro Branco: Add importmulti rpc call
1662016-10-20T07:04:59 <GitHub91> bitcoin/master 215caba Pedro Branco: Add consistency check to RPC call importmulti
1672016-10-20T07:05:00 <GitHub91> bitcoin/master f2d7056 Wladimir J. van der Laan: Merge #7551: Add importmulti RPC call...
1682016-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
1692016-10-20T07:07:29 *** MarcoFalke has joined #bitcoin-core-dev
1702016-10-20T07:20:07 *** BashCo has joined #bitcoin-core-dev
1712016-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
1722016-10-20T07:36:16 *** laurentmt has joined #bitcoin-core-dev
1732016-10-20T07:36:22 *** laurentmt has quit IRC
1742016-10-20T07:36:46 *** laurentmt has joined #bitcoin-core-dev
1752016-10-20T07:38:43 *** JackH has joined #bitcoin-core-dev
1762016-10-20T07:44:13 *** aalex has quit IRC
1772016-10-20T07:47:20 *** Guyver2 has joined #bitcoin-core-dev
1782016-10-20T07:48:23 *** aalex has joined #bitcoin-core-dev
1792016-10-20T07:52:00 *** moli has quit IRC
1802016-10-20T07:52:12 *** moli has joined #bitcoin-core-dev
1812016-10-20T07:57:49 *** Eliel has quit IRC
1822016-10-20T07:58:16 *** laurentmt has quit IRC
1832016-10-20T07:59:28 *** aalex has quit IRC
1842016-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
1852016-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
1862016-10-20T08:03:25 *** aalex has joined #bitcoin-core-dev
1872016-10-20T08:06:51 *** Eliel has joined #bitcoin-core-dev
1882016-10-20T08:14:33 *** aalex has quit IRC
1892016-10-20T08:17:47 *** molz has joined #bitcoin-core-dev
1902016-10-20T08:18:23 *** aalex has joined #bitcoin-core-dev
1912016-10-20T08:18:43 *** Guyver2 has quit IRC
1922016-10-20T08:21:12 *** moli has quit IRC
1932016-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
1942016-10-20T08:32:19 <wumpus> jonasschnelli: maybe release binaries
1952016-10-20T08:32:24 *** rebroad has quit IRC
1962016-10-20T08:32:30 <wumpus> usually that's more effective to get GUI stuff tested
1972016-10-20T08:33:00 <jonasschnelli> wumpus: 8501 is non GUI RPC only... the GUI diff is large because of the flexible core stats collector.
1982016-10-20T08:33:16 <wumpus> ohh
1992016-10-20T08:33:17 <jonasschnelli> I don't want to scarify the flexible design to keep the GUI diff low. :)
2002016-10-20T08:33:53 <wumpus> bah I'll retest #8959
2012016-10-20T08:33:54 <jonasschnelli> Parts of the statics collector could probably be reused for sipas idea of evicting misbehave score
2022016-10-20T08:34:14 <jonasschnelli> 8959 is strange...
2032016-10-20T08:34:22 <jonasschnelli> Maybe a Qt bug
2042016-10-20T08:34:23 <wumpus> seems to work for me
2052016-10-20T08:34:35 <jonasschnelli> Could be a QT-OSX bug
2062016-10-20T08:39:06 <jonasschnelli> i'll test again
2072016-10-20T08:39:49 *** laurentmt has joined #bitcoin-core-dev
2082016-10-20T08:40:02 <wumpus> either that or macosx's triangles are y-axis-reversed :-)
2092016-10-20T08:41:32 *** laurentmt has quit IRC
2102016-10-20T08:42:44 <jonasschnelli> wumpus: looks like. :) I guess is a Qt bug
2112016-10-20T08:42:50 <jonasschnelli> *it's
2122016-10-20T08:43:09 <wumpus> turning the pyramid upside down
2132016-10-20T08:43:14 <jonasschnelli> we could add something in platformstyles... *duck*
2142016-10-20T08:43:14 <wumpus> do we have sorting triangles anywhere else?
2152016-10-20T08:43:20 <jonasschnelli> yes. TX table
2162016-10-20T08:43:29 <wumpus> are they reversed too?
2172016-10-20T08:43:36 <jonasschnelli> let me check
2182016-10-20T08:43:53 <jonasschnelli> Correct there for me
2192016-10-20T08:44:01 <jonasschnelli> wumpus: can you check on Ubuntu?
2202016-10-20T08:44:26 <wumpus> yes
2212016-10-20T08:44:37 <jonasschnelli> Hmm... so its a bug in our codebase
2222016-10-20T08:45:27 <wumpus> huh. The tx one on ubuntu is: up-pointing pyramid is descending, down-pointing pyramid is ascending
2232016-10-20T08:45:38 * wumpus confused
2242016-10-20T08:46:43 * paveljanik was always confused...
2252016-10-20T08:46:54 <jonasschnelli> So at least the "bug" behavior is identical.
2262016-10-20T08:46:59 <wumpus> tried with balance. same for date. up=most recent date first, down=oldest date first
2272016-10-20T08:47:00 <jonasschnelli> IMO its an upstream Qt bug
2282016-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
2292016-10-20T08:48:01 <wumpus> reverted my ACK
2302016-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... :)
2312016-10-20T08:48:56 <wumpus> in principle the validity of #8959 is based on one thing: does order == Qt::DescendingOrder really sort descending?
2322016-10-20T08:49:11 *** AaronvanW has joined #bitcoin-core-dev
2332016-10-20T08:49:11 *** AaronvanW has joined #bitcoin-core-dev
2342016-10-20T08:49:29 <wumpus> we should inspect the sorted list insome other way
2352016-10-20T08:49:38 <wumpus> along with the input to the operator
2362016-10-20T08:51:30 *** Ylbam has joined #bitcoin-core-dev
2372016-10-20T09:06:45 <wumpus> jonasschnelli: ok, so the original code was correct
2382016-10-20T09:07:02 <wumpus> the arrow behavior is strange, but should not be corrected by changing the sorting code
2392016-10-20T09:07:38 <jonasschnelli> wumpus: look like, but with the original code, i get a strange initial state
2402016-10-20T09:07:44 <jonasschnelli> First click results in only changing the arrow. :)
2412016-10-20T09:08:02 <wumpus> it looks like initially the thing is not sorted at all
2422016-10-20T09:08:04 <jonasschnelli> dam those little GUI glitches
2432016-10-20T09:08:23 <wumpus> it only ends up in that sorting function *after* clicking the column the first time
2442016-10-20T09:08:27 <jonasschnelli> Ah. That could be.. so it takes the default arrow direction which could be different
2452016-10-20T09:08:47 *** laurentmt has joined #bitcoin-core-dev
2462016-10-20T09:11:43 <michagogo> I wonder if my attempt to make a gitian-building vbox appliance will work, or crash and burn.
2472016-10-20T09:14:32 *** jujumax has joined #bitcoin-core-dev
2482016-10-20T09:14:51 *** laurentmt has quit IRC
2492016-10-20T09:18:20 <jonasschnelli> michagogo: isn't the idea that everyone should setup it's own VM (security)?
2502016-10-20T09:19:09 *** DigiByteDev has joined #bitcoin-core-dev
2512016-10-20T09:19:58 <wumpus> well if everyone would start using michagogo's image that would be a problem
2522016-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
2532016-10-20T09:21:52 <jonasschnelli> michagogo: Yes. I think its generally a good idea and it might lead to better docs as well.. :)
2542016-10-20T09:21:59 <michagogo> Since so many people seem to have trouble with it, while I have a working setup...
2552016-10-20T09:22:12 <jonasschnelli> though, wumpus did create an awesome gitian doc
2562016-10-20T09:22:24 <michagogo> People say it doesn't work :-(
2572016-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
2582016-10-20T09:22:54 <jonasschnelli> Yes. Maybe we should provide a non LXC version
2592016-10-20T09:23:19 <michagogo> i.e. if the only reason it works for me is that I already have the environment set up
2602016-10-20T09:23:33 <michagogo> Maybe I'll turn on VBox's video recording feature
2612016-10-20T09:23:36 <jonasschnelli> heh... I guess same here. :)
2622016-10-20T09:24:24 <jonasschnelli> michagogo: you could turn your working system into an appliance (including your bitcoin private keys)
2632016-10-20T09:24:38 <michagogo> jonasschnelli: actually, someone asked for that first
2642016-10-20T09:24:52 <michagogo> But yeah, not gonna do that
2652016-10-20T09:25:01 <jonasschnelli> yes. better not
2662016-10-20T09:25:27 <michagogo> No Bitcoin private keys in there, but gpg, probably ssh, and also token for github, chrome, etc.
2672016-10-20T09:26:04 <michagogo> (I use the VM whenever I want to do/try something in Linux, not just for gitian)
2682016-10-20T09:27:19 *** timothy has quit IRC
2692016-10-20T09:27:20 *** drizztbsd has joined #bitcoin-core-dev
2702016-10-20T09:27:50 *** drizztbsd is now known as timothy
2712016-10-20T09:33:14 *** timothy has quit IRC
2722016-10-20T09:33:17 *** drizztbsd has joined #bitcoin-core-dev
2732016-10-20T09:33:47 *** drizztbsd is now known as timothy
2742016-10-20T09:35:00 *** timothy has quit IRC
2752016-10-20T09:35:03 *** drizztbsd has joined #bitcoin-core-dev
2762016-10-20T09:35:34 *** drizztbsd is now known as timothy
2772016-10-20T09:41:24 *** Victorsueca has joined #bitcoin-core-dev
2782016-10-20T09:41:25 *** jujumax has quit IRC
2792016-10-20T09:41:25 *** Victor_sueca has joined #bitcoin-core-dev
2802016-10-20T09:48:06 *** timothy has quit IRC
2812016-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
2822016-10-20T09:48:09 *** drizztbsd has joined #bitcoin-core-dev
2832016-10-20T09:48:37 *** Victor_sueca has quit IRC
2842016-10-20T09:48:40 *** drizztbsd is now known as timothy
2852016-10-20T09:48:48 *** aalex has quit IRC
2862016-10-20T09:50:25 <Victorsueca> morning
2872016-10-20T09:50:55 *** timothy has quit IRC
2882016-10-20T09:50:58 *** drizztbsd has joined #bitcoin-core-dev
2892016-10-20T09:51:28 *** drizztbsd is now known as timothy
2902016-10-20T09:52:06 *** drizztbsd has joined #bitcoin-core-dev
2912016-10-20T09:52:37 *** drizztbsd is now known as timothy
2922016-10-20T09:54:37 *** DigiByteDev has quit IRC
2932016-10-20T09:58:40 <wumpus> morning
2942016-10-20T09:59:00 <btcdrak> wumpus: achow101 script work great with --kvm
2952016-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
2962016-10-20T09:59:50 <wumpus> if not a relevant problem anymore we could just switch the guide to KVM
2972016-10-20T09:59:59 <Victorsueca> windows update force-restarted my computer last night while I was sleeping :/
2982016-10-20T10:01:44 <rabidus_> new spyware installed
2992016-10-20T10:01:56 <luke-jr> wee, master no longer builds
3002016-10-20T10:02:25 <luke-jr> guess importmulti wasn't ready :<
3012016-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>}â)
3022016-10-20T10:02:51 <michagogo> wumpus: I assume it's still an issue... nested virtualization is hard
3032016-10-20T10:03:12 <michagogo> But I do think anyone who's able should use KVM... AFAIK it tends to work much, much better
3042016-10-20T10:03:25 *** aalex has joined #bitcoin-core-dev
3052016-10-20T10:04:52 *** cdecker has joined #bitcoin-core-dev
3062016-10-20T10:05:18 <michagogo> Hm, should I try making this with the Ubuntu Server ISO?
3072016-10-20T10:05:33 <luke-jr> does this actually compile for anyone? it looks like boost::variant *intentionally* omits operator!=
3082016-10-20T10:07:43 <wumpus> does what actually compile for anyone?
3092016-10-20T10:08:53 <luke-jr> wumpus: importmulti or master
3102016-10-20T10:09:39 <wumpus> yes - it passes travis and builds here locally
3112016-10-20T10:09:43 <luke-jr> :/
3122016-10-20T10:09:57 <luke-jr> how is CTxDestination.Get() != CTxDestination.Get() working?
3132016-10-20T10:12:45 <Victorsueca> Will try compiling master here
3142016-10-20T10:13:15 <wumpus> the intention would be to compare whether the two destinations are the same
3152016-10-20T10:16:56 <wumpus> I think the importmulti code could be cleaned up quite a bit
3162016-10-20T10:17:04 <luke-jr> hm, looks like boost added it in some newer version
3172016-10-20T10:18:48 <wumpus> looks like the variant comparison is mostly used for "consistency checks"
3182016-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
3192016-10-20T10:19:46 <luke-jr> !(a==b) works
3202016-10-20T10:19:46 <gribble> Error: "(a==b)" is not a valid command.
3212016-10-20T10:19:58 <wumpus> that's crazy
3222016-10-20T10:20:02 <sipa> gribble disagrees
3232016-10-20T10:20:05 <luke-jr> heh
3242016-10-20T10:20:11 <Victorsueca> lol
3252016-10-20T10:20:41 <wumpus> hahahah
3262016-10-20T10:21:11 <luke-jr> why does C++ make it possible to have a==b && a!=b ? :p
3272016-10-20T10:22:14 <wumpus> I think most/all languages with overloaded operators allow that
3282016-10-20T10:23:46 <luke-jr> I knew Perl did, but I figured that was because it was Perl ;x
3292016-10-20T10:24:32 <wumpus> same with > versus <= and < versus >=. I think there's even legitimate cases for that, e.g. NaNs
3302016-10-20T10:28:44 <GitHub49> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/5f6b312e51dadaf40ea68c0f85bbb4e51fa987f1
3312016-10-20T10:28:45 <GitHub49> bitcoin/0.13 5f6b312 Wladimir J. van der Laan: doc: Add missing credit to release notes...
3322016-10-20T10:31:40 <sipa> wumpus: from 0.13 release notes: "This is a new majir versiob release"
3332016-10-20T10:31:45 <sipa> *major
3342016-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?
3352016-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
3362016-10-20T10:35:44 <wumpus> yes, the 0.13 release notes definitely need some updating still
3372016-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?
3382016-10-20T10:39:42 <Victorsueca> NULLDUMMY?
3392016-10-20T10:39:54 <Victorsueca> wut
3402016-10-20T10:40:04 <sipa> Victorsueca: bip147
3412016-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
3422016-10-20T10:40:15 <michagogo> Hm, actually
3432016-10-20T10:40:18 <sipa> i wonder if release notes shouldn't be written and tracked in a separate repository
3442016-10-20T10:40:23 <michagogo> Do we call it two soft-forks?
3452016-10-20T10:40:35 <michagogo> Maybe it's more accurate to drop the s
3462016-10-20T10:40:36 <wumpus> michagogo: no, it should be called one, I think mentioning only segwit would be fine
3472016-10-20T10:40:46 <michagogo> since it's one softfork, with two components
3482016-10-20T10:41:44 <Victorsueca> maybe it would be better if we named bip147 something other than nulldummy
3492016-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
3502016-10-20T10:42:29 <wumpus> e.g. the release notes need to be final at the same time the release is final
3512016-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
3522016-10-20T10:42:57 <wumpus> posted to the mailing lists
3532016-10-20T10:43:19 <wumpus> could do the editing of the release notes in another repo then include it before final, sure...
3542016-10-20T10:43:29 <wumpus> or heck ,even google docs
3552016-10-20T10:44:20 <wumpus> that's easier for collaborative editing I guess
3562016-10-20T10:45:12 <sipa> well it could remove the issue of retroactive changes
3572016-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
3582016-10-20T10:45:54 <wumpus> retroacive changes are always a problem
3592016-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
3602016-10-20T10:46:32 <wumpus> and is cleaned out on the 0.13 branch for the next release from there
3612016-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
3622016-10-20T10:47:34 <sipa> fair enough, it is less ambiguous than i thought
3632016-10-20T10:47:46 <sipa> but it's still confusing
3642016-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
3652016-10-20T10:49:09 <wumpus> at some point it needs to be checked in as doc/release-notes.md
3662016-10-20T10:49:32 <wumpus> in principle only the state at the final tag matters, the filecould be non-existent before and after that
3672016-10-20T10:49:33 <Victorsueca> what about this: do the docs on a separate repo, when it's release time then clone to bitcoin
3682016-10-20T10:49:50 <wumpus> I don't think that's any less confusing though
3692016-10-20T10:50:00 <wumpus> maybe the current way of working should just be documented better
3702016-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
3712016-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
3722016-10-20T10:51:47 <wumpus> current 0.14 release notes are on the master branch
3732016-10-20T10:51:57 *** laurentmt has joined #bitcoin-core-dev
3742016-10-20T10:51:58 <wumpus> those are for the next release on either branch
3752016-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
3762016-10-20T10:53:24 <wumpus> not that anyone bothers
3772016-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...
3782016-10-20T10:58:10 <wumpus> should make sure that the file still gets included in the tarballs though
3792016-10-20T10:58:18 <wumpus> (and all the other distributions)
3802016-10-20T11:04:02 <GitHub133> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/c9a5baddeef3d8721a7c71acf070f92a3d8d43a3
3812016-10-20T11:04:02 <GitHub133> bitcoin/0.13 c9a5bad Wladimir J. van der Laan: doc: Update blurb in release notes...
3822016-10-20T11:07:08 *** Ylbam has quit IRC
3832016-10-20T11:07:22 *** jannes has joined #bitcoin-core-dev
3842016-10-20T11:24:11 <luke-jr> ⺠deterministic git assembly of Knots' branch in 30 seconds :P
3852016-10-20T11:26:03 <Victorsueca> i'm currently testing if master can be built successfully
3862016-10-20T11:26:57 <luke-jr> Victorsueca: it will likely depend on your boost version
3872016-10-20T11:32:12 <Victorsueca> lastest probably, I installed it 2 days ago
3882016-10-20T11:34:17 <sipa> installed how?
3892016-10-20T11:34:38 <Victorsueca> with apt-get
3902016-10-20T11:35:05 <sipa> that way you get the version from your distro's repository
3912016-10-20T11:35:13 <sipa> that's very very unlikely to be the latest
3922016-10-20T11:35:21 <Victorsueca> it's ubuntu
3932016-10-20T11:35:35 <sipa> likely not even the latest at the time the distribution was released
3942016-10-20T11:35:51 *** laurentmt has quit IRC
3952016-10-20T11:35:53 *** cryptapus has joined #bitcoin-core-dev
3962016-10-20T11:37:47 <Victorsueca> do unit tests mess with the default data directory or they create some temp dir to do the tests?
3972016-10-20T11:38:03 <wumpus> they create temp directories
3982016-10-20T11:38:36 <wumpus> if they touch the data directory that would be a bug
3992016-10-20T11:39:05 <Victorsueca> so it's _safe_ to run the scripts in the qa folder
4002016-10-20T11:42:00 <wumpus> those are not the unit tests, but functional tests, but the same holds
4012016-10-20T11:43:57 <Victorsueca> wumpus: would be helpful if I run any of those and paste the outputs?
4022016-10-20T11:44:46 <wumpus> only if they fail, I guess
4032016-10-20T11:45:22 <wumpus> you can run all of them with qa/pull-tester/rpc-tests.py
4042016-10-20T11:47:24 <Victorsueca> wumpus: is it currently more needed to test master or 0.13.1rc2?
4052016-10-20T11:47:33 *** Cory has quit IRC
4062016-10-20T11:53:12 <sipa> unless you have an unusual setup, running rpc or unit tests won't teach us anything new
4072016-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)
4082016-10-20T11:54:04 <Victorsueca> AFAIK there are few devs using windows
4092016-10-20T11:54:13 <sipa> ah, yes
4102016-10-20T11:54:16 <Victorsueca> I use Windows x64
4112016-10-20T11:54:26 <sipa> i thought you were on ubuntylu
4122016-10-20T11:54:34 <sipa> *ubuntu
4132016-10-20T11:54:47 <Victorsueca> I use ubuntu to cross-compile the builds
4142016-10-20T11:54:54 <sipa> do the rpc tests even work on windows?
4152016-10-20T11:55:40 <Victorsueca> not sure, worth trying I guess
4162016-10-20T11:57:44 *** rebroad has joined #bitcoin-core-dev
4172016-10-20T11:58:14 <luke-jr> I kinda doubt they would
4182016-10-20T12:03:15 *** jujumax has joined #bitcoin-core-dev
4192016-10-20T12:04:22 *** fengling has quit IRC
4202016-10-20T12:04:25 *** alpalp has joined #bitcoin-core-dev
4212016-10-20T12:09:15 *** DigiByteDev has joined #bitcoin-core-dev
4222016-10-20T12:14:22 <Victorsueca> looks like my boost version was right, master built successfully
4232016-10-20T12:17:59 <Victorsueca> error at rpc-tests.py https://softnet.homenet.org/zerobin/?a149e1289bc5714f#2PzAq4zVrcQJl9WrUgIBfA7hpiVEIA44Ml8QRANe2HE=
4242016-10-20T12:19:36 <luke-jr> wrong Python version
4252016-10-20T12:20:03 <Victorsueca> need python 3?
4262016-10-20T12:20:10 <luke-jr> yes
4272016-10-20T12:22:55 *** jtimon has joined #bitcoin-core-dev
4282016-10-20T12:25:51 <michagogo> I might have successfully set up a machine for Gitian building
4292016-10-20T12:26:11 <michagogo> It was pretty much just as easy as I thought it might be
4302016-10-20T12:26:44 <michagogo> I even migrated over my apt-cacher-ng cache from my other machine
4312016-10-20T12:27:36 <achow101> michagogo: but does it actually build the binaries properly?
4322016-10-20T12:27:47 <michagogo> achow101: That's my next test
4332016-10-20T12:28:05 <michagogo> I made the base VM and that seems to work as far as sanity-checking
4342016-10-20T12:28:19 <michagogo> Snapshotting it now, and then I'll test an actual build
4352016-10-20T12:28:47 <michagogo> Gitian is actually broken atm (make-base-vm tries to copy a file that doesn't exist)
4362016-10-20T12:29:01 <michagogo> But there's already a PR that fixes it, so I just cherry-picked that in
4372016-10-20T12:29:27 <achow101> yeah, i noticed that.
4382016-10-20T12:30:45 *** fengling has joined #bitcoin-core-dev
4392016-10-20T12:30:57 <michagogo> And I turned on VBox's video capture option, so I have a video of everything I did
4402016-10-20T12:43:28 <Victorsueca> Error again https://softnet.homenet.org/zerobin/?586fe4c0934c7d9c#fMLN5XtScV/cdqkwjN6dTkLU17hjkL0iiNGW81x7aNw=
4412016-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
4422016-10-20T12:45:13 <michagogo> then it tried to fall back to bitcoincore.org and got a 4040
4432016-10-20T12:45:15 <michagogo> -0
4442016-10-20T12:45:21 <michagogo> Oversight?
4452016-10-20T12:51:32 *** mkarrer has quit IRC
4462016-10-20T12:53:20 <timothy> hi, can you please consider adding man pages to linux tar too?
4472016-10-20T12:53:26 <timothy> instead of git repository only
4482016-10-20T12:53:33 *** mkarrer has joined #bitcoin-core-dev
4492016-10-20T12:56:51 *** alpalp has quit IRC
4502016-10-20T12:58:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4512016-10-20T13:00:39 <Victorsueca> running it on a ubuntu enviroment brings a similar error https://softnet.homenet.org/zerobin/?e1589c342242901a#RUf6mKsZzrb+JBznhaaAraDxb57s0DayDGRm1JgU5Bo=
4522016-10-20T13:00:44 <Victorsueca> so it's not windows fault
4532016-10-20T13:05:01 <Victorsueca> any ideas?
4542016-10-20T13:05:19 <michagogo> achow101: Seems to be working so far
4552016-10-20T13:05:34 <michagogo> Running an actual gitian build, it's built linux depends up until native_protobuf
4562016-10-20T13:05:42 <michagogo> Working on boost atm
4572016-10-20T13:07:33 <michagogo> OpenSSL...
4582016-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
4592016-10-20T13:10:37 <michagogo> It's being compressed atm, once it's done it'll start uploading
4602016-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
4612016-10-20T13:30:13 *** achow101_ has joined #bitcoin-core-dev
4622016-10-20T13:32:18 *** achow101_ has joined #bitcoin-core-dev
4632016-10-20T13:33:38 <achow101_> michagogo: how did you get lxc to work? Did you have to change anything in gitian's scripts?
4642016-10-20T13:35:53 <BlueMatt> why do i see so many nodes failing version handshake?
4652016-10-20T13:35:58 <BlueMatt> on 13.1
4662016-10-20T13:41:34 <Lightsword> BlueMatt, only on 0.13.1 and not 0.13.0?
4672016-10-20T13:44:03 <BlueMatt> dunno, didnt try 13
4682016-10-20T13:44:38 *** Chris_Stewart_5 has quit IRC
4692016-10-20T13:44:44 <BlueMatt> still, ProcessMessage FAILED on version messages is new to me
4702016-10-20T13:44:55 <BlueMatt> did xt/classic/unlimited break something?
4712016-10-20T13:46:24 <Victorsueca> BlueMatt: not getting those errors here
4722016-10-20T13:47:12 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4732016-10-20T13:47:14 <Lightsword> BlueMatt, got an example of one it fails against?
4742016-10-20T13:48:08 *** harrymm has quit IRC
4752016-10-20T13:48:23 <sipa> BlueMatt: nExpectedServices could cause this
4762016-10-20T13:48:32 <BlueMatt> no, because it otherwise prints the peer's ip messages after version processing works
4772016-10-20T13:48:33 <BlueMatt> :/
4782016-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
4792016-10-20T13:49:01 <BlueMatt> sipa: no, ProcessMessages(version, 102 bytes) FAILED peer=10
4802016-10-20T13:49:17 <BlueMatt> oh, yea, that might be it
4812016-10-20T13:49:19 <sipa> yes, ProcessMessages returns false in that case
4822016-10-20T13:49:19 <BlueMatt> since it returns false
4832016-10-20T13:49:33 <BlueMatt> huh, funny, I've seen a bunch of those on fresh nodes
4842016-10-20T13:50:03 <Victorsueca> BlueMatt: maybe it's gmaxwell's aggressive witness peer search disconnection non-witness nodes to free connection slots
4852016-10-20T13:50:27 <Victorsueca> disconnecting*
4862016-10-20T13:50:33 <BlueMatt> no, it is almost surely the nServicesExpected & ~nServices check
4872016-10-20T13:50:33 <sipa> Victorsueca: no, that's for chossing which peers to connect to
4882016-10-20T13:50:54 <sipa> BlueMatt: to be fair, we probably had no idea about what services were circulating
4892016-10-20T13:51:08 <sipa> maybe some reachable nodes became pruned
4902016-10-20T13:51:22 <sipa> but their ips kept circulati g
4912016-10-20T13:51:40 *** Chris_Stewart_5 has quit IRC
4922016-10-20T13:51:52 *** harrymm has joined #bitcoin-core-dev
4932016-10-20T13:52:49 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4942016-10-20T13:54:32 *** aalex has quit IRC
4952016-10-20T13:57:21 *** Ylbam has joined #bitcoin-core-dev
4962016-10-20T13:58:23 *** aalex has joined #bitcoin-core-dev
4972016-10-20T14:01:39 <tulip> BlueMatt: I was seeing that a lot too.
4982016-10-20T14:03:00 <tulip> I didn't think to take a packet capture until after it calmed down sadly.
4992016-10-20T14:04:12 <BlueMatt> tulip: naa, see comments above, its pretty clear what it is
5002016-10-20T14:04:50 *** laurentmt has joined #bitcoin-core-dev
5012016-10-20T14:05:31 *** laurentmt has quit IRC
5022016-10-20T14:05:53 <tulip> BlueMatt: ok, needs more sensible error messages. there's a couple of those hanging around with peer connection.
5032016-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 :)
5042016-10-20T14:07:20 *** Victor_sueca has joined #bitcoin-core-dev
5052016-10-20T14:09:48 *** Victorsueca has quit IRC
5062016-10-20T14:10:50 <Victor_sueca> damn, power outage
5072016-10-20T14:10:57 *** Victor_sueca is now known as Victorsueca
5082016-10-20T14:13:51 <Victorsueca> and router has +30 second ping :D
5092016-10-20T14:16:41 *** To7 has joined #bitcoin-core-dev
5102016-10-20T14:20:17 *** Victorsueca has quit IRC
5112016-10-20T14:21:28 *** Victorsueca has joined #bitcoin-core-dev
5122016-10-20T14:22:29 *** jujumax has quit IRC
5132016-10-20T14:22:36 <BlueMatt> tulip: -debug=net will show it
5142016-10-20T14:22:44 <BlueMatt> that error message should probably not need debug=net
5152016-10-20T14:24:13 *** Expanse is now known as nOgAnOo
5162016-10-20T14:24:15 *** Giszmo has joined #bitcoin-core-dev
5172016-10-20T14:24:34 *** nOgAnOo has quit IRC
5182016-10-20T14:24:34 *** nOgAnOo has joined #bitcoin-core-dev
5192016-10-20T14:24:34 *** nOgAnOo has quit IRC
5202016-10-20T14:24:34 *** nOgAnOo has joined #bitcoin-core-dev
5212016-10-20T14:25:12 *** Chris_Stewart_5 has quit IRC
5222016-10-20T14:28:20 *** jujumax has joined #bitcoin-core-dev
5232016-10-20T14:35:58 *** timothy has quit IRC
5242016-10-20T14:43:36 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5252016-10-20T14:46:52 *** achow101_ has quit IRC
5262016-10-20T14:50:04 *** Chris_Stewart_5 has quit IRC
5272016-10-20T14:52:48 *** achow101_ has joined #bitcoin-core-dev
5282016-10-20T14:53:02 *** achow101_ has quit IRC
5292016-10-20T14:55:25 <achow101> michagogo: did you upload it yet? All I see is a .webm file which I can't play
5302016-10-20T14:57:48 *** Cory has joined #bitcoin-core-dev
5312016-10-20T14:58:21 *** Cory has joined #bitcoin-core-dev
5322016-10-20T14:58:55 *** Guest12765 has joined #bitcoin-core-dev
5332016-10-20T14:59:15 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5342016-10-20T14:59:30 *** Guest12765 has joined #bitcoin-core-dev
5352016-10-20T15:04:34 *** instagibbs has joined #bitcoin-core-dev
5362016-10-20T15:09:36 *** Chris_Stewart_5 has quit IRC
5372016-10-20T15:24:38 *** timothy has joined #bitcoin-core-dev
5382016-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:
5392016-10-20T15:25:50 <NicolasDorier> void* libconsensus_createValidationContext();
5402016-10-20T15:25:50 <NicolasDorier> void libconsensus_setConsensusFlags(void* context, int flags);
5412016-10-20T15:25:50 <NicolasDorier> void libconsensus_setPolicyValidation(void* context, bool value);
5422016-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);
5432016-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
5442016-10-20T15:26:11 <NicolasDorier> so the whole undoc flags would be wrapped into the "PolicyValidation" boolean
5452016-10-20T15:27:05 <sipa> NicolasDorier: but libconsensus' purpose is not to test policy
5462016-10-20T15:27:24 <sipa> the same risks don't apply, you can use any implementation for that
5472016-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
5482016-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 :(
5492016-10-20T15:29:31 <NicolasDorier> but well, I understand the point that you don't want the burden of maintaining it
5502016-10-20T15:29:33 <sipa> well maybe you can create a libbitcoinscript
5512016-10-20T15:29:43 <sipa> that does everything scripting, but isn't consensus
5522016-10-20T15:30:05 <sipa> imho it's a mistake that in our own code the policy script evaluator is mixed with consensus logic
5532016-10-20T15:30:16 <sipa> but that's a controversial opinion, i'm aware
5542016-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
5552016-10-20T15:31:56 <sipa> it would imply we have two separate script interpreter implementations
5562016-10-20T15:32:21 <sipa> one just for consensus, one for everything
5572016-10-20T15:32:32 <sipa> the first one would only need to be touched for consensus changes
5582016-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
5592016-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
5602016-10-20T15:33:50 <sipa> NicolasDorier: i don't want "abstract" anything in consensus code, to the extent possible
5612016-10-20T15:34:01 <sipa> NicolasDorier: that makes it much harder to reason about all code interactions
5622016-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.
5632016-10-20T15:35:48 <NicolasDorier> I mean it would be the easiest way I see to separate consensus code from policy code
5642016-10-20T15:35:54 <NicolasDorier> in script evaluator
5652016-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
5662016-10-20T15:37:11 <NicolasDorier> wumpus: yes, only for injecting things that are only part of policy
5672016-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?
5682016-10-20T15:37:52 <wumpus> (e.g. as long as injection points are a no-op when validating for consensus)
5692016-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
5702016-10-20T15:38:28 *** jannes has quit IRC
5712016-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?
5722016-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
5732016-10-20T15:39:32 <wumpus> (when testing libconsensus)
5742016-10-20T15:39:41 <sipa> wumpus: i'd say so
5752016-10-20T15:39:47 <wumpus> ok!
5762016-10-20T15:39:52 <sipa> define a value that is the or of all flags that are in consensus
5772016-10-20T15:40:00 <sipa> if any others are set, skip the test
5782016-10-20T15:40:34 <wumpus> yes, I added a bitcoinconsensus_SCRIPT_FLAGS_VERIFY_ALL that is all the flags in libconsensus ORed
5792016-10-20T15:41:02 <wumpus> let's see if that leaves enough tests :)
5802016-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
5812016-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, ...
5822016-10-20T15:41:43 <wumpus> I don't think it's urgent enough for a last-minute change to 0.13.1
5832016-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"
5842016-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
5852016-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
5862016-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 ?
5872016-10-20T15:44:37 <wumpus> yes, I'd like that
5882016-10-20T15:44:55 <NicolasDorier> indeed would be cool
5892016-10-20T15:45:49 <NicolasDorier> doing such a thing would be easy to review as well.
5902016-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
5912016-10-20T15:46:56 <sipa> NicolasDorier: not just EvalScript. Everything in script/*
5922016-10-20T15:47:15 <sipa> (most of it would go away in the consensus version, of course)
5932016-10-20T15:48:08 <NicolasDorier> mh interesting indeed.
5942016-10-20T15:48:33 <sipa> I once tried to simplify CScript::operator<< because it is very inconvenient to use
5952016-10-20T15:48:45 <sipa> turns out, changing it would have been a hard fork
5962016-10-20T15:49:17 <sipa> which was so scary that i really didn't want to touch consensus' CScript anymore
5972016-10-20T15:50:09 <wumpus> yes dodged a bullet there
5982016-10-20T15:50:22 <NicolasDorier> in C++ is there a way to split the implementation of a class in several file ?
5992016-10-20T15:50:27 <sipa> yes
6002016-10-20T15:50:32 <sipa> but you shouldn't :)
6012016-10-20T15:50:49 *** rebroad has quit IRC
6022016-10-20T15:50:55 <wumpus> the implementation can be split into multiple files, the definition must be in one place, generally
6032016-10-20T15:50:58 <NicolasDorier> well, we could split CScript what belongs to consensus and what not
6042016-10-20T15:51:00 <sipa> see core_io.h with core_write.cpp and core_read.cpp for exmample
6052016-10-20T15:51:04 <sipa> NicolasDorier: die
6062016-10-20T15:51:12 <NicolasDorier> ahah is this so contentious :D
6072016-10-20T15:51:39 <sipa> NicolasDorier: now the users of your class' dependencies depend on _how_ they use the class
6082016-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
6092016-10-20T15:52:15 <wumpus> you can put the functions everywhere
6102016-10-20T15:52:19 <sipa> indeed
6112016-10-20T15:52:54 <sipa> leveldb uses a struct with a {char* ptr; size_t size} in many places
6122016-10-20T15:53:11 <sipa> allowing processing routines to be independent from storage
6132016-10-20T15:53:15 <wumpus> we need a slice abstraction too
6142016-10-20T15:53:21 <sipa> slice, that's it
6152016-10-20T15:53:43 <wumpus> golang has that pretty much as central data representation :)
6162016-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
6172016-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
6182016-10-20T15:54:32 <sipa> there wouldn't even be a CScriot
6192016-10-20T15:54:32 <NicolasDorier> you could wrap your char* by one of those
6202016-10-20T15:54:37 <sipa> just an EvalScript
6212016-10-20T15:55:00 <sipa> there could be a CScriptBuilder with the << operators etc for convenience
6222016-10-20T15:55:05 <wumpus> right - script generation isn't part of consensus
6232016-10-20T15:55:13 <sipa> exactly
6242016-10-20T15:55:19 <sipa> it would just be utikity
6252016-10-20T15:55:28 <NicolasDorier> wumpus: by "Slice" abstraction, you mean a structure {*array, index, count} ?
6262016-10-20T15:55:44 <wumpus> NicolasDorier: yes
6272016-10-20T15:55:59 <wumpus> I think in golang it's a kind of shared pointer. Not sure though how they do memory internally
6282016-10-20T15:56:09 <wumpus> in leveldb it's just a *
6292016-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
6302016-10-20T15:57:30 <wumpus> in any case for one-off methods like consensus calls the distinction doesn't matter
6312016-10-20T15:57:36 <wumpus> consensus has no state and will never hold on to your slices
6322016-10-20T15:58:06 <wumpus> OK OK the statelessness not true if you include the caches
6332016-10-20T15:58:16 <wumpus> *current* libconsensus has no state
6342016-10-20T15:59:54 <michagogo> achow101: I don't think I did more than what gitian's README says
6352016-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
6362016-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)
6372016-10-20T16:00:34 <wumpus> not sure what you mean there, script is just a char*,size effectively. It has no internal structure
6382016-10-20T16:00:45 <michagogo> And yeah, the ova isn't fully uploaded yet
6392016-10-20T16:01:08 <michagogo> OneDrive says it's uploaded 1.2 out of 3.6 GB
6402016-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
6412016-10-20T16:01:58 <michagogo> Unfortunately it looks like it doesn't show a speed or time estimate, unlike Dropbox...
6422016-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
6432016-10-20T16:02:26 <NicolasDorier> yeah with extension method :))
6442016-10-20T16:02:27 <wumpus> (e.g. if you *want* GetSigOpsCount implies you're doing policy)
6452016-10-20T16:02:44 <NicolasDorier> ah GetSigOpsCount I though it was part of consensus my bad
6462016-10-20T16:03:42 <michagogo> The Linux gitian build worked on the new appliance: https://www.irccloud.com/pastebin/RpH8KGPY/
6472016-10-20T16:04:06 <wumpus> hm you're right I think, though if possible that would be used internally by libconsensus and not exposed
6482016-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
6492016-10-20T16:05:14 <michagogo> achow101: Hm, odd
6502016-10-20T16:05:25 <michagogo> You said you weren't able to play the webm?
6512016-10-20T16:05:49 <michagogo> VLC seems to be playing it without a problem...
6522016-10-20T16:06:07 <michagogo> Looks like Chrome is doing just fine as well
6532016-10-20T16:06:20 <achow101> it didn't work in whatever default video player ubuntu uses. I'll try vlc
6542016-10-20T16:06:59 <michagogo> It's about an hour long
6552016-10-20T16:07:19 <achow101> yeah, it works in vlc
6562016-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
6572016-10-20T16:07:33 *** jujumax has quit IRC
6582016-10-20T16:07:45 <michagogo> Trial, error, and all
6592016-10-20T16:08:05 <michagogo> (also with some pauses while I looked stuff up outside the VM...)
6602016-10-20T16:11:33 <achow101> why do you need apt-cacher-ng
6612016-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
6622016-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
6632016-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)
6642016-10-20T16:14:59 <achow101> ok
6652016-10-20T16:19:10 <michagogo> Lauda: You may be interested in this too
6662016-10-20T16:19:31 <michagogo> In the meantime it's up to 1.3 GB...
6672016-10-20T16:20:02 <michagogo> Actually, just realized I can check Resource Monitor
6682016-10-20T16:21:51 *** jujumax has joined #bitcoin-core-dev
6692016-10-20T16:24:40 <michagogo> Looks like OneDrive is currently uploading at about 250-300KB/s
6702016-10-20T16:25:57 *** cdecker has quit IRC
6712016-10-20T16:26:13 *** jujumax has quit IRC
6722016-10-20T16:26:28 <michagogo> achow101: Looks like it should show up in 2-3 hours
6732016-10-20T16:26:45 <michagogo> (assuming a steady rate)
6742016-10-20T16:27:05 *** rebroad has joined #bitcoin-core-dev
6752016-10-20T16:32:09 <Lauda> thanks michagogo
6762016-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
6772016-10-20T16:35:53 <wumpus> see https://github.com/bitcoin/bitcoin/pull/8227
6782016-10-20T16:37:48 <jonasschnelli> sipa, available?
6792016-10-20T16:38:46 <sipa> jonasschnelli: yes
6802016-10-20T16:39:19 <cfields_> BlueMatt: ping. #8969 ready for review/testing?
6812016-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
6822016-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=
6832016-10-20T16:39:58 <jonasschnelli> sipa: NotifyHeaderTip is only used by the gui and IMO it should just reflect whats inside pindexBestHeader... not?
6842016-10-20T16:40:41 <Victorsueca> wumpus: a similar error occurs even on a ubuntu env https://softnet.homenet.org/zerobin/?6b8aa1b1b6e5aca7#MhP7eiv7h8L7mHC9LMAIk6ytlzsmY2Hv+3t7I7WnUtQ=
6852016-10-20T16:41:25 <sipa> jonasschnelli: remember thinking about that, and that we should indeed just switch to using pindexBestHeader
6862016-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
6872016-10-20T16:42:48 <BlueMatt> cfields_: sure! go for it
6882016-10-20T16:43:02 <BlueMatt> cfields_: though maybe first do 8968 first, and review those separately
6892016-10-20T16:43:20 <BlueMatt> cfields_: 8969 should be pretty simple without 8968
6902016-10-20T16:43:32 *** jujumax has joined #bitcoin-core-dev
6912016-10-20T16:43:43 <cfields_> BlueMatt: got it, thanks
6922016-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
6932016-10-20T16:44:03 <BlueMatt> :/
6942016-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.
6952016-10-20T16:44:10 <BlueMatt> and fighting with hosts about their shitty routing
6962016-10-20T16:44:33 <BlueMatt> cfields_: no rush, so is debugging the shitty, shitty world of chinese internet
6972016-10-20T16:44:42 <cfields_> heh
6982016-10-20T16:44:45 <sipa> BlueMatt: will do
6992016-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
7002016-10-20T16:47:10 <BlueMatt> cfields_: yea, we talked about this in milan...decided against it because it was late even then
7012016-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?
7022016-10-20T16:48:15 <BlueMatt> cfields_: it should never cause deadlock since cs_main should always be the first lock, I believe
7032016-10-20T16:48:46 <BlueMatt> maybe sipa want to comment since he was the one claiming so in milan
7042016-10-20T16:48:58 <cfields_> BlueMatt: specifically, it's holding it while grabbing cs_vSend/cs_vRecvMsg that worry me
7052016-10-20T16:49:04 <cfields_> agh, brb.
7062016-10-20T16:55:04 *** BashCo has quit IRC
7072016-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
7082016-10-20T17:19:30 *** DigiByteDev has quit IRC
7092016-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'?
7102016-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".
7112016-10-20T17:34:53 <wumpus> I agree
7122016-10-20T17:36:11 <Victorsueca> wumpus: is my error related to what you said or it's a different thing?
7132016-10-20T17:38:15 *** BashCo has joined #bitcoin-core-dev
7142016-10-20T17:39:23 <wumpus> Victorsueca: I don't really know
7152016-10-20T17:40:22 <wumpus> what does "El sistema no puede encontrar el archivo especificado" mean?
7162016-10-20T17:40:41 <Victorsueca> The system couldn't find the specified file
7172016-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
7182016-10-20T17:41:50 <wumpus> looks like it's simply notable to find the daemon
7192016-10-20T17:42:25 <sipa> s/notable/unable/ ?
7202016-10-20T17:42:31 <Victorsueca> thanks, will try
7212016-10-20T17:43:19 <Victorsueca> should I set it to the directory where bitcoind is or directly to the bitcoind.exe file?
7222016-10-20T17:43:41 <wumpus> the file
7232016-10-20T17:44:24 *** laurentmt has joined #bitcoin-core-dev
7242016-10-20T17:44:29 *** laurentmt has quit IRC
7252016-10-20T17:47:46 <Victorsueca> wumpus: done, exactly the same error
7262016-10-20T17:48:14 <Victorsueca> ohh wait, didn't restart the terminal...
7272016-10-20T17:48:27 <sipa> wallet/rpcdump.cpp:1020:13: warning: ânLowestTimestampâ may be used uninitialized in this function [-Wmaybe-uninitialized] int64_t nLowestTimestamp;
7282016-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
7292016-10-20T17:52:29 *** gmaxwell has quit IRC
7302016-10-20T17:53:03 <Victorsueca> well, the bash is on C:\UNIX\bitcoinalpha
7312016-10-20T17:53:18 <Victorsueca> which is where I cloned the master branch of the git repository
7322016-10-20T17:53:24 <sipa> Victorsueca: i don't think this channel is right for helping you debug these things
7332016-10-20T17:54:28 <Victorsueca> sipa: well, maybe something is wrong with the rpc tests in which case it should be fixed
7342016-10-20T17:55:05 <Victorsueca> first i'm trying to figure out if I did something wrong or the python script has some bug
7352016-10-20T17:55:07 <wumpus> "maybe". But you should first try to debug it locally, before making allegations like that
7362016-10-20T17:55:26 <wumpus> the QA tests are run by many people on many platforms
7372016-10-20T17:55:40 <achow101> Victorsueca: what's the problem again? I'll see if I can replicate
7382016-10-20T17:56:01 <Victorsueca> achow101: I posted the link above
7392016-10-20T17:56:11 <Victorsueca> wumpus: few on windows AFAIK
7402016-10-20T17:56:20 <wumpus> no, really ,they are being run on windows
7412016-10-20T17:56:35 <Victorsueca> hmmm ok
7422016-10-20T17:56:56 <Victorsueca> any instructions on how to dump extra debug info?
7432016-10-20T17:57:32 <wumpus> I think you need general python debugging tools
7442016-10-20T17:57:53 <wumpus> there's nothing bitcoin specific about not being able to execute the right executable
7452016-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
7462016-10-20T18:00:02 <Victorsueca> I guess that would discard being something windows-specific
7472016-10-20T18:00:15 <michagogo> achow101: .6 GB to go
7482016-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
7492016-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
7502016-10-20T18:01:47 <Victorsueca> sipa: yep, likely
7512016-10-20T18:02:16 <wumpus> even a backtrace seems to be problematic
7522016-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
7532016-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
7542016-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
7552016-10-20T18:04:34 <Victorsueca> in M$ they already have the money so they can use to to make even more crap software
7562016-10-20T18:07:09 <sipa> referring to microsoft M$ isn't particularly meaningful - every company tries to make money
7572016-10-20T18:07:42 <michagogo> Hm, just saw this morning's (last night's, really) wallops
7582016-10-20T18:07:57 <michagogo> I wonder if we're in scope
7592016-10-20T18:09:08 <sipa> michagogo: link?
7602016-10-20T18:09:17 <michagogo> http://freenode.net/news/community
7612016-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.)
7622016-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
7632016-10-20T18:11:24 <achow101> Victorsueca: wumpus: replicated the problem, found the issue (I think)
7642016-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
7652016-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
7662016-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 :-)
7672016-10-20T18:15:04 *** gmaxwell has joined #bitcoin-core-dev
7682016-10-20T18:15:19 <Victorsueca> achow101: maybe adding shell=True would solve it?
7692016-10-20T18:15:29 <wumpus> achow101: but he tried to override BITCOIND already
7702016-10-20T18:15:42 <wumpus> no, don't add shell=True please, that's a security disaster
7712016-10-20T18:15:50 <Victorsueca> lol yeah
7722016-10-20T18:16:11 <sipa> BlueMatt: remabsed 8515
7732016-10-20T18:16:17 <sipa> *rebased
7742016-10-20T18:16:35 <sipa> sometimes i fail to understand my own fingers.
7752016-10-20T18:17:26 <achow101> Victorsueca: it's because both of us built using WSL
7762016-10-20T18:17:49 <achow101> the problem is with the SRCDIR variable. If you go to qa/tests_config.py you'll see why
7772016-10-20T18:18:42 <Victorsueca> achow101: no such file
7782016-10-20T18:18:58 <achow101> sorry, qa/pull-tester/test_config.py
7792016-10-20T18:20:09 <Victorsueca> ahh lol
7802016-10-20T18:20:22 <Victorsueca> variables are in unix-like paths
7812016-10-20T18:21:23 <achow101> but fixing there's another error after fixing that
7822016-10-20T18:25:32 *** rebroad has quit IRC
7832016-10-20T18:26:29 <Victorsueca> achow101: which one?
7842016-10-20T18:26:52 <achow101> %1 is not a valid Win32 application
7852016-10-20T18:27:01 <achow101> that happens when I run it again
7862016-10-20T18:27:48 <Victorsueca> i'm still getting the same error tho
7872016-10-20T18:28:03 <GitHub0> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f2d705629b51...0e228557f239
7882016-10-20T18:28:03 <GitHub0> bitcoin/master 7942d31 Luke Dashjr: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions
7892016-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...
7902016-10-20T18:28:18 <achow101> check your path and make sure it is correct. Use forward slashes instead of backslashes
7912016-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
7922016-10-20T18:28:38 <BlueMatt> sipa: thanks
7932016-10-20T18:30:05 *** Yogh has quit IRC
7942016-10-20T18:31:17 <gmaxwell> bleh why are we using boost::variant?
7952016-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
7962016-10-20T18:33:23 <sipa> nope, i introduced it.
7972016-10-20T18:33:47 <sipa> jonasschnelli: how do you unhide the catching up overlay?
7982016-10-20T18:33:48 <wumpus> I guess it's a convenient way to do that
7992016-10-20T18:34:10 <sipa> gmaxwell: well because it's exactly what we need for CTxDestination... a tagged union
8002016-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
8012016-10-20T18:34:34 <sipa> wumpus: absolutely
8022016-10-20T18:34:39 <wumpus> why is it such an issue for you gmaxwell ?
8032016-10-20T18:34:44 <sipa> though it's not trivial either
8042016-10-20T18:35:16 <sipa> as using a C union with non-trivial types in it is asking for problems
8052016-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
8062016-10-20T18:35:58 <achow101> tl;dr don't run the rpc tests on windows because windows does stupid things
8072016-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
8082016-10-20T18:36:23 <Victorsueca> achow101: thanks, will put that on a bitcoin block so everybody knows ;)
8092016-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' ?
8102016-10-20T18:37:15 <wumpus> the usualy way in C++ would be something with subclasses
8112016-10-20T18:38:26 <sipa> yuck. that means the child classes need to know that they're part of a union
8122016-10-20T18:38:32 <wumpus> sipa: sure, feel free to make it more obvious
8132016-10-20T18:38:43 <sipa> wumpus: i don't know Qt :)
8142016-10-20T18:39:16 <wumpus> sipa: well evertying is a compromise, I'm sure some other solution could be thought up without that drawback
8152016-10-20T18:39:30 <wumpus> without having to go into boost template hell
8162016-10-20T18:39:51 <sipa> i guess my poreferred solution would be to reimplement boost::variant :)
8172016-10-20T18:40:05 <sipa> c++ really lacks a tagged union
8182016-10-20T18:40:08 <wumpus> bleh
8192016-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
8202016-10-20T18:40:32 * sipa is maybe biased by Haskell, where tagged union is pretty much the only way to construct new types
8212016-10-20T18:41:13 <cfields_> sipa: iirc c++14 adds std::variant and/or std::any
8222016-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
8232016-10-20T18:41:30 <wumpus> we *don't * want to support half of bost as part of bitcoin core
8242016-10-20T18:41:31 <sipa> cfields_: aha!
8252016-10-20T18:42:17 <cfields_> sipa: bah, both c++17 :(
8262016-10-20T18:42:56 <wumpus> are we at c++17 yet?
8272016-10-20T18:43:00 <sipa> cfields_: oh, so we only need to wait until 2022 until we can use it in Bitcoin Core?
8282016-10-20T18:43:09 <wumpus> yes
8292016-10-20T18:43:11 <cfields_> heh
8302016-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
8312016-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 :)
8322016-10-20T18:44:25 <sipa> afaik c++14/17 change much less than what c++11 changed wrt to c++03
8332016-10-20T18:44:28 <wumpus> we only need time, and that elapses automatically
8342016-10-20T18:44:30 <cfields_> wumpus: yep, see std::filesystem :)
8352016-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.
8362016-10-20T18:45:00 <cfields_> sipa: yes, true
8372016-10-20T18:45:06 <sipa> how many headers does testnet have?
8382016-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.
8392016-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
8402016-10-20T18:46:25 <wumpus> it's apparently just hard to support something like that in c++
8412016-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...)
8422016-10-20T18:46:52 <wumpus> gmaxwell: well you're welcome to implement it in a better way! :)
8432016-10-20T18:47:10 <sipa> it's preferctly applicable in cases where you can say "an X is either a Y or a Z"
8442016-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
8452016-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
8462016-10-20T18:47:35 <sipa> cfields_: puke
8472016-10-20T18:47:59 <gmaxwell> (and yes, I also believe polymorphism is generally ill-advised based on the same argument)
8482016-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
8492016-10-20T18:48:24 <sipa> found the C programmer.
8502016-10-20T18:48:49 <wumpus> sigh, let's not get into that discussino
8512016-10-20T18:49:03 <cfields_> wumpus: yes, that'd be much cleaner
8522016-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)_
8532016-10-20T18:49:25 <wumpus> cfields_: sipa didn't like it because the subclasses have to know they're part of an union
8542016-10-20T18:49:42 <cfields_> wumpus: yes, that'd be the "tag" part :p
8552016-10-20T18:49:59 <cfields_> oh, i see what you mean
8562016-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
8572016-10-20T18:50:11 <sipa> *switch topic* what is testnet's height?
8582016-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.
8592016-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)
8602016-10-20T18:50:36 <wumpus> gmaxwell: yes - it's even worse in java code generally :)
8612016-10-20T18:50:37 <gmaxwell> sipa: on segwit nodes 1009190
8622016-10-20T18:50:40 <cfields_> as of a min or two ago
8632016-10-20T18:50:49 <sipa> cfields_: thanks. trying to sync headers over a really slow connection
8642016-10-20T18:53:33 *** K-ballo has joined #bitcoin-core-dev
8652016-10-20T18:54:07 * wumpus should start running a dedicated testnet node again
8662016-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' ?
8672016-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.
8682016-10-20T18:56:03 *** instagibbs_ has joined #bitcoin-core-dev
8692016-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
8702016-10-20T18:56:10 <jonasschnelli> Yes. It's a bit hidden. What about clicking on the progress bar in the status bar?
8712016-10-20T18:56:19 <sipa> and a real tagged union would be much more useful
8722016-10-20T18:56:31 <wumpus> sipa: good point
8732016-10-20T18:57:03 <sipa> jonasschnelli: that'd be useful too
8742016-10-20T18:57:13 <sipa> (it was the first thing i tried)
8752016-10-20T18:57:52 <wumpus> so I think stopping support for windows 32-bit in 0.15 would make sense
8762016-10-20T18:58:13 *** jujumax has quit IRC
8772016-10-20T18:58:16 *** rebroad has joined #bitcoin-core-dev
8782016-10-20T18:58:22 <achow101> meeting?
8792016-10-20T18:58:30 <wumpus> in two minutes!
8802016-10-20T18:58:39 <sipa> one and a half
8812016-10-20T18:58:41 <achow101> aw man, my clock's fast
8822016-10-20T18:59:14 <Victorsueca> what meeting?
8832016-10-20T18:59:22 <jl2012> the last windows with 32-bit is windows 7?
8842016-10-20T18:59:27 <achow101> Victorsueca: dev meeting
8852016-10-20T18:59:30 *** harrymm has quit IRC
8862016-10-20T18:59:44 <achow101> jl2012: windows10 has a 32 bit version
8872016-10-20T18:59:49 <Victorsueca> ^
8882016-10-20T18:59:59 *** jcorgan has joined #bitcoin-core-dev
8892016-10-20T19:00:04 <Victorsueca> achow101: is it going to be broadcasted?
8902016-10-20T19:00:11 <achow101> it happens right here on irc
8912016-10-20T19:00:12 <CodeShark> it's here
8922016-10-20T19:00:15 <wumpus> #startmeeting
8932016-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.
8942016-10-20T19:00:15 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
8952016-10-20T19:00:24 <wumpus> proposed topics?
8962016-10-20T19:00:38 <sipa> proposed cheer: yay for 0.13.1rc
8972016-10-20T19:00:45 <CodeShark> ^ :DDD
8982016-10-20T19:00:50 <jonasschnelli> heh
8992016-10-20T19:00:55 <wumpus> yay for 0.13.1rc, haven't heard of any real problems yet
9002016-10-20T19:01:15 <achow101> hmm. where's gmaxwell-ping-bot
9012016-10-20T19:01:23 <wumpus> not that it says much given how short it's been out, but ok, it's somewhat promising :)
9022016-10-20T19:01:53 <CodeShark> if only execution paths with problems tended to occur first :p
9032016-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
9042016-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 ?
9052016-10-20T19:02:23 *** Guyver2 has joined #bitcoin-core-dev
9062016-10-20T19:02:34 <btcdrak> here
9072016-10-20T19:02:50 <wumpus> ah yes I have another topic about the libconsensus interface: what to do with undocumented flags
9082016-10-20T19:02:51 <instagibbs_> present
9092016-10-20T19:02:59 <btcdrak> ping jl2012
9102016-10-20T19:03:01 * paveljanik here
9112016-10-20T19:03:08 <jl2012> yes
9122016-10-20T19:03:10 <wumpus> jl2012 was already here
9132016-10-20T19:03:35 <jtimon> wumpus: like bip113 ? or more like bip30 ?
9142016-10-20T19:03:46 <wumpus> jtimon: https://github.com/bitcoin/bitcoin/pull/8976
9152016-10-20T19:03:53 <wumpus> #topic libconsensus
9162016-10-20T19:04:05 <wumpus> currently it's possible to pass non-consensus flags into libconsensus
9172016-10-20T19:04:07 <wumpus> e.g. policy only flags
9182016-10-20T19:04:25 <CodeShark> yes, that should be pulled out
9192016-10-20T19:04:26 <sipa> i believe we should not expose policy functions in libconsensus
9202016-10-20T19:04:35 *** Chris_Stewart_5 has joined #bitcoin-core-dev
9212016-10-20T19:04:49 <sipa> as that would make it impossible to later split off policy code into a separate codebase
9222016-10-20T19:04:52 <BlueMatt> sipa: ack
9232016-10-20T19:05:00 <sipa> and consensus code should end up being isolated
9242016-10-20T19:05:04 <wumpus> ok so that means you agree with #8976
9252016-10-20T19:05:10 <instagibbs_> was there thought otherwise? (I'm outsider to this work)
9262016-10-20T19:05:20 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8976
9272016-10-20T19:05:21 <CodeShark> yeah, doesn't seem very controversial
9282016-10-20T19:05:22 <jtimon> I agree, currently it is not possible (at least using bitcoinconsensus_verifyScript)
9292016-10-20T19:05:32 <instagibbs_> ah I see what you mean
9302016-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.
9312016-10-20T19:05:37 <wumpus> and NicolasDorier is okay with it
9322016-10-20T19:05:50 <BlueMatt> wumpus: dont have a strong opinion, but I'm fine with that
9332016-10-20T19:06:04 <wumpus> if there is to be a policy script library it'll need to be separate imo
9342016-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
9352016-10-20T19:06:20 <wumpus> this is lib*consensus*
9362016-10-20T19:06:20 <sipa> jonasschnelli: agree
9372016-10-20T19:06:23 <sipa> eh, jtimon: agree
9382016-10-20T19:06:38 <wumpus> jtimon: no, they don't need to match, that's just an artifact
9392016-10-20T19:06:56 <sipa> wumpus: is there are translation layer?
9402016-10-20T19:07:00 <wumpus> although it's no longer possible to change the flags now
9412016-10-20T19:07:10 <wumpus> ABI for libconsensus is fixed
9422016-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
9432016-10-20T19:07:22 <wumpus> sipa: no, that was never added
9442016-10-20T19:07:28 <sipa> we should add one
9452016-10-20T19:07:35 <sipa> and keep the flags for the existing bits
9462016-10-20T19:07:35 <jtimon> agreed
9472016-10-20T19:07:40 <sipa> as passthrough
9482016-10-20T19:07:42 <wumpus> yes, there should be a translation layer, though the current bits can no longer be changed
9492016-10-20T19:07:45 <wumpus> agreed
9502016-10-20T19:07:46 <sipa> but new ones can fill up the holes
9512016-10-20T19:08:12 <jtimon> btw, related branch: https://github.com/jtimon/bitcoin/commits/0.13-consensus-flags
9522016-10-20T19:08:15 <wumpus> at the lesat we should add the error when invalid flags are passed
9532016-10-20T19:08:26 <CodeShark> is anyone using these flags as ints rather than just as an enum?
9542016-10-20T19:08:31 <wumpus> this will discourage people from doing what they're doing now, e.g. treating it as a pass-through
9552016-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
9562016-10-20T19:09:06 <sipa> CodeShark: we're already abusing enum here. it's a bit field, not an enum
9572016-10-20T19:09:14 <sipa> the enum is just an easy way to give the constants name
9582016-10-20T19:09:15 <jtimon> CodeShark: AFAIK there used always like if (flags & MY_FLAG)
9592016-10-20T19:09:36 <sipa> for almost all operations we do with these enums, they decay into integers
9602016-10-20T19:09:41 <wumpus> yes
9612016-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?
9622016-10-20T19:10:08 <sipa> CodeShark: that breaks the ABI
9632016-10-20T19:10:13 <wumpus> you can't shuffle the bits because it would break the *binary* interface
9642016-10-20T19:10:18 <CodeShark> oh...
9652016-10-20T19:10:19 <sipa> you can't link with an older version of the library in that case
9662016-10-20T19:10:23 <CodeShark> ok
9672016-10-20T19:10:30 <CodeShark> gotcha
9682016-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
9692016-10-20T19:11:08 <sipa> without recompiling your client
9702016-10-20T19:11:10 <wumpus> arguably the SEGWIT bit can be moved until 0.13.1 is finalized, but meh
9712016-10-20T19:11:23 <sipa> indeed, meh.
9722016-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
9732016-10-20T19:12:10 <CodeShark> sipa: so you're saying we can reuse the bits that get vacated when we remove the policy flags
9742016-10-20T19:12:24 <sipa> CodeShark: yes
9752016-10-20T19:12:34 <sipa> as those were never part of the abi
9762016-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
9772016-10-20T19:12:40 <sipa> *api
9782016-10-20T19:12:58 <wumpus> this is what #8976 fixes by adding input checking on the flags
9792016-10-20T19:13:14 <jtimon> and my preference would be to expose a GetConsensusFlags call in libconsensus too
9802016-10-20T19:13:32 *** Guest12765 has quit IRC
9812016-10-20T19:13:35 <wumpus> what would that do?
9822016-10-20T19:13:36 <jtimon> to hide the bip9 and previous developments stuff
9832016-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)
9842016-10-20T19:14:44 <sipa> and you pass in all block headers?
9852016-10-20T19:14:52 <jtimon> https://github.com/jtimon/bitcoin/blob/0.13-consensus-flags/src/versionbits.cpp#L153
9862016-10-20T19:15:09 *** harrymm has joined #bitcoin-core-dev
9872016-10-20T19:15:11 *** Cory has joined #bitcoin-core-dev
9882016-10-20T19:15:20 <jtimon> no, the same CBlockIndex interface used for verifyHeader
9892016-10-20T19:15:59 <sipa> i really don't like turning our internal representation for headers into an index
9902016-10-20T19:15:59 <jtimon> similar to https://github.com/bitcoin/bitcoin/pull/8493
9912016-10-20T19:16:11 <sipa> *into an interface
9922016-10-20T19:16:13 <CodeShark> sipa: agreed
9932016-10-20T19:16:22 <CodeShark> it could be done better
9942016-10-20T19:16:24 <jtimon> other ideas to interface with storage ?
9952016-10-20T19:16:31 <CodeShark> without exposing all that crap
9962016-10-20T19:16:33 <jtimon> CodeShark: how?
9972016-10-20T19:16:46 <sipa> just have an API where you can create a blockindexstore, and you give it headers
9982016-10-20T19:17:00 <sipa> which are copied into the blockindexstore
9992016-10-20T19:17:04 <CodeShark> yes
10002016-10-20T19:17:18 <jtimon> so libconsensus remains coupled with our storage?
10012016-10-20T19:17:28 <sipa> that's my personal preference
10022016-10-20T19:17:33 <CodeShark> well...hmmm
10032016-10-20T19:17:36 <jtimon> I wasn't planning on taking any headers from callers
10042016-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
10052016-10-20T19:17:54 <sipa> kanzure: nobody even agrees what libconsensus means.
10062016-10-20T19:17:59 <kanzure> perfect
10072016-10-20T19:18:19 <CodeShark> the header storage engine is quite trivial, actually
10082016-10-20T19:18:37 <CodeShark> not sure it needs an abstract DB interface...but on the other hand...
10092016-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
10102016-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
10112016-10-20T19:18:53 <BlueMatt> we already discussed this in milan
10122016-10-20T19:19:03 *** Cory has joined #bitcoin-core-dev
10132016-10-20T19:19:04 <wumpus> so the *memory* storage is part of libconsensus
10142016-10-20T19:19:05 *** Cory has quit IRC
10152016-10-20T19:19:08 <wumpus> the disk storage is not
10162016-10-20T19:19:12 <BlueMatt> that
10172016-10-20T19:19:13 <CodeShark> ok
10182016-10-20T19:19:14 <jtimon> BlueMatt: yeah, you and me discussed it a little, with no conclusion
10192016-10-20T19:19:29 <wumpus> right,we discussed that in Milan
10202016-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
10212016-10-20T19:19:32 <kanzure> meaning of "storage" has to be carefully defined
10222016-10-20T19:19:45 <sipa> they're perfectly compatible with a store into which you can load headers, though
10232016-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
10242016-10-20T19:20:16 <jonasschnelli> We are speaking of a in-memory only store, right?
10252016-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
10262016-10-20T19:20:33 <wumpus> jonasschnelli: yes. as currently used for the headers
10272016-10-20T19:20:36 <BlueMatt> but i think that is further out on the horizon
10282016-10-20T19:20:45 <wumpus> BlueMatt: agreed, that's no issue right now
10292016-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
10302016-10-20T19:21:06 <sipa> the criterion would be that we ourself want to use it
10312016-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
10322016-10-20T19:21:26 <wumpus> s/not support/support not/
10332016-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
10342016-10-20T19:21:28 <CodeShark> no need for premature optimization here
10352016-10-20T19:21:38 <CodeShark> header storage is not a bottleneck ;)
10362016-10-20T19:21:44 <sipa> CodeShark: it's not premature optimized. it's breaking existing optimization
10372016-10-20T19:21:51 <kanzure> CBlockIndex usage is not necessarily libconsensus-only, right?
10382016-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
10392016-10-20T19:21:59 <sipa> storage isn't, but block index traversal needs to be past
10402016-10-20T19:22:00 <sipa> *fast
10412016-10-20T19:22:06 <kanzure> i mean that's only because nobody wants to maintain a CBlockIndex and also libconsensus, ya?
10422016-10-20T19:22:20 <sipa> kanzure: i have no clue what you're talking about
10432016-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
10442016-10-20T19:22:50 <sipa> storage... port?
10452016-10-20T19:22:51 <sipa> wth?
10462016-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 :)
10472016-10-20T19:22:57 <kanzure> (i was responding to "refactoring every use of CBlockIndex into an api".)
10482016-10-20T19:23:20 <CodeShark> let's not get sidetracked
10492016-10-20T19:23:25 <wumpus> please, let's not split hairs over definitions
10502016-10-20T19:23:26 <Victorsueca> sipa: not a network port obv
10512016-10-20T19:23:27 <wumpus> any other topics?
10522016-10-20T19:23:36 <cfields_> wumpus: +1. As a side-effect, that also forces devs to become familiar with it.
10532016-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. :)
10542016-10-20T19:24:05 <gmaxwell> (I also support it existing, to be clear!)
10552016-10-20T19:24:10 <wumpus> cfields_: right, so it's possible to fork bitcoin core but still use the same libconsensus, for example
10562016-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
10572016-10-20T19:25:04 <wumpus> gmaxwell: if some topic isn't interesting to you, you don't need to be loud about that
10582016-10-20T19:25:08 *** Cory has joined #bitcoin-core-dev
10592016-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?
10602016-10-20T19:25:32 <sipa> jonasschnelli: we're not even talking about block storage
10612016-10-20T19:25:40 <jonasschnelli> sorry, heards
10622016-10-20T19:25:40 <CodeShark> we're still on headers :p
10632016-10-20T19:25:42 <jonasschnelli> headers
10642016-10-20T19:25:45 *** gmaxwell has left #bitcoin-core-dev
10652016-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)
10662016-10-20T19:26:30 <kanzure> external caller == other wallet?
10672016-10-20T19:26:31 <jtimon> you guys want a processBlock function, not a verifyBlock one
10682016-10-20T19:26:44 <sipa> jtimon: i think exposing verification functions at different levels is useful
10692016-10-20T19:26:49 <jtimon> kanzure: yep, a wallet, an alternative implementation, whatever
10702016-10-20T19:26:53 <sipa> exposing headers, individual block, total block, ...
10712016-10-20T19:27:07 <sipa> jtimon: but the question is about whether or not to abstract out the state needed for that
10722016-10-20T19:27:08 <jtimon> sipa: cool, BlueMatt seem to think it's not
10732016-10-20T19:27:23 <sipa> those are independent questions
10742016-10-20T19:27:26 <jtimon> in any case, you don't want a verifyHeader independent of storage
10752016-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.
10762016-10-20T19:28:01 <sipa> i think it would hurt our own usage of it, as it means fewer opportunities to improve memory usage
10772016-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
10782016-10-20T19:28:19 <sipa> what i want to do is have the consensus code abstracted out
10792016-10-20T19:28:21 <wumpus> it is needed if it is used by us
10802016-10-20T19:28:31 <sipa> modularized
10812016-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
10822016-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
10832016-10-20T19:28:50 <sipa> that doesn't mean we need to abstract out every data structure it uses
10842016-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
10852016-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.
10862016-10-20T19:29:33 <CodeShark> breaking out the storage engine can be done independently
10872016-10-20T19:29:50 <wumpus> BlueMatt: yes, I remember we discussed that before, too :)
10882016-10-20T19:29:51 <kanzure> what is the concurrency coupling that jtimon mentions in particular
10892016-10-20T19:30:00 <sipa> CodeShark: we're not really talking about (disk) storage here, just in-memory representation of data structures
10902016-10-20T19:30:07 <BlueMatt> wumpus: yes, this is exactly the discussion we had in milan
10912016-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)
10922016-10-20T19:30:42 <BlueMatt> jtimon: have you spoken much to these folks? (I dont know, just asking, would love to see their responses)
10932016-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
10942016-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
10952016-10-20T19:31:33 <sipa> yes, abstracting the data structures can still happen later
10962016-10-20T19:31:38 <wumpus> I think this is typical bitcoin scope creep
10972016-10-20T19:31:45 <CodeShark> yes - modularization is what's most important, then we can further optimize each unit
10982016-10-20T19:31:48 <kanzure> sounds like an emphasis on code movement first
10992016-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
11002016-10-20T19:31:51 <wumpus> nothing will ever get done this way and we keep repeating the same discussions
11012016-10-20T19:32:29 <wumpus> +tons of huge code changes that will take ages to review
11022016-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"
11032016-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
11042016-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
11052016-10-20T19:33:56 <CodeShark> the focus for now should be on separation of units and removing dependencies
11062016-10-20T19:33:57 <jtimon> well, all I want is to have a common and clear idea of what libconsensus should be
11072016-10-20T19:34:10 <sipa> while we already have optimized data structures, and not abstracting them out leaves more opportunities for future such optimizations
11082016-10-20T19:34:14 <wumpus> it should be a libarary that we ourselves can use for consensus validation
11092016-10-20T19:34:17 *** rebroad has quit IRC
11102016-10-20T19:34:36 <wumpus> sipa: exactly! *not* exposing something as part of the API leaves flexibility to improve things later
11112016-10-20T19:34:46 <wumpus> sipa: putting it in the API/ABI effectively sets it in stone
11122016-10-20T19:34:47 <jtimon> CodeShark: but then people won't "see the point" of taking consensus code out of main...
11132016-10-20T19:34:55 <CodeShark> ?
11142016-10-20T19:35:07 <CodeShark> there
11152016-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.
11162016-10-20T19:35:30 <morcos> For instance I disagree a bit with the flexibility when it comes to cache optimization for pcoinstip.
11172016-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
11182016-10-20T19:35:43 <jtimon> CodeShark: ie #8337 #8329
11192016-10-20T19:35:54 <morcos> But we don't have to answer all those questions right now
11202016-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
11212016-10-20T19:36:11 <sipa> morcos: agree
11222016-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).
11232016-10-20T19:36:58 <CodeShark> kanzure: indeed
11242016-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
11252016-10-20T19:37:37 <sipa> jtimon: well things may not be easy
11262016-10-20T19:37:40 <jtimon> kanzure: I would love that
11272016-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
11282016-10-20T19:38:02 <Chris_Stewart_5> ^
11292016-10-20T19:38:09 <BlueMatt> ^
11302016-10-20T19:38:12 <jeremyrubin> ^
11312016-10-20T19:38:16 <sipa> v
11322016-10-20T19:38:17 <jtimon> CodeShark: I'm happy with that
11332016-10-20T19:38:21 <jtimon> I tried that too
11342016-10-20T19:38:23 <Chris_Stewart_5> always one sipa..
11352016-10-20T19:38:53 <jtimon> but some people asked for the final API...
11362016-10-20T19:38:54 <sipa> i'd really just want to see a proposal of a directory structure
11372016-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.
11382016-10-20T19:39:12 <sipa> which explains code responsible for what belongs where
11392016-10-20T19:39:20 <jtimon> sipa: I gave you one: all consensus fles except those in crypto to the consensus dir
11402016-10-20T19:39:28 <sipa> jtimon: that's not an answer
11412016-10-20T19:39:36 <jtimon> it is one you don't like
11422016-10-20T19:39:38 <sipa> there is code shared between consensus and non-consensus
11432016-10-20T19:39:46 <sipa> what happens to script? is it split up again?
11442016-10-20T19:39:51 <sipa> where does the signing code go?
11452016-10-20T19:40:02 <jtimon> but I really don't see how can we make a subrepository or subtree out of libconsensus otherwise
11462016-10-20T19:40:03 <kanzure> sipa did you read jtimon's libconsensus doc by any chance
11472016-10-20T19:40:05 <sipa> do we duplicate consensu logic?
11482016-10-20T19:40:09 <jtimon> sipa: signing code is not consensus
11492016-10-20T19:40:14 <sipa> sigh
11502016-10-20T19:40:18 <sipa> i know that
11512016-10-20T19:40:30 <jtimon> it remains in the common package
11522016-10-20T19:40:41 <jtimon> and the script dir
11532016-10-20T19:40:52 <sipa> ok, i'll shut up about it
11542016-10-20T19:41:00 <wumpus> I think this is monipolizing the meeting. ANy othe topics to be discussed?
11552016-10-20T19:41:04 <sipa> i can't seem to get my point across
11562016-10-20T19:41:15 <jtimon> no, you brought this point more times
11572016-10-20T19:41:23 <CodeShark> can we set as a goal to prioritize some moveonly PRs?
11582016-10-20T19:41:29 <sipa> yes, and i have never seen you give an answer to my question
11592016-10-20T19:41:47 <CodeShark> sipa, jtimon, let's save that for after the meeting
11602016-10-20T19:42:26 <CodeShark> can we agree for the time being to define a directory structure and prioritize moveonly PRs?
11612016-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"
11622016-10-20T19:42:43 <wumpus> I can't prioritize moveonly PRs. There's just too much happening
11632016-10-20T19:42:57 <CodeShark> wumpus: the idea is that they should be super simple to review
11642016-10-20T19:43:05 <sipa> CodeShark: you underestimate it
11652016-10-20T19:43:13 <michagogo> achow101: looks like it finished uploading, if you want to try it
11662016-10-20T19:43:19 <sipa> moving the code is easy. deciding where things belong is not.
11672016-10-20T19:43:20 <wumpus> but if people prioritize reviewing them, sure
11682016-10-20T19:43:23 <kanzure> oh is review the bottleneck? i keep thinking it's "lots of other rebase work" for other pulls.
11692016-10-20T19:43:36 <jtimon> wumpus: I think it being a priority for reviewers is more important
11702016-10-20T19:43:39 <wumpus> kanzure: that's also an issue
11712016-10-20T19:43:39 <sipa> kanzure: imho the bottleneck is no agreement about what should be done
11722016-10-20T19:43:41 <michagogo> Wait, it's Thursday... sorry, didn't realize meeting was happening
11732016-10-20T19:43:43 * michagogo scrolls up
11742016-10-20T19:43:52 <jtimon> kanzure: I strongly feel review is the bottleneck
11752016-10-20T19:44:17 <instagibbs_> proposed topic: rc2 issues, etc?
11762016-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.
11772016-10-20T19:44:30 <kanzure> oh. alright.
11782016-10-20T19:44:31 <jtimon> CodeShark: also I think you understimate the potential for disagreements
11792016-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?
11802016-10-20T19:44:54 <CodeShark> can we at least agree to start discussing a directory structure? ;)
11812016-10-20T19:45:00 <CodeShark> (after this meeting, of course)
11822016-10-20T19:45:03 <jtimon> CodeShark: ACK
11832016-10-20T19:45:32 <wumpus> Chris_Stewart_5: you tell me
11842016-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
11852016-10-20T19:45:57 <kanzure> Chris_Stewart_5: perhaps sipa could make a proposal if we ask nicely.
11862016-10-20T19:46:01 <jtimon> I already buried my hopes of libconsensus becoming eventually C
11872016-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 :)
11882016-10-20T19:46:05 <Chris_Stewart_5> This is ALL libbconsensus right? Is tehre any concrete proposals?
11892016-10-20T19:46:24 *** jujumax has joined #bitcoin-core-dev
11902016-10-20T19:46:25 <instagibbs_> 14 minutes in case anyone wants to discuss anything else
11912016-10-20T19:46:41 <jtimon> Chris_Stewart_5: afaik the most concrete proposal right now is #8493
11922016-10-20T19:46:41 <wumpus> instagibbs_: I asked in the beginning, don't think there's any issues with rc2 yet
11932016-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
11942016-10-20T19:47:04 <Chris_Stewart_5> Thanks, i'll take a look at it.
11952016-10-20T19:47:15 <kanzure> ah 8493 is expose verifyheader. ok.
11962016-10-20T19:47:21 <instagibbs_> wumpus: ok great
11972016-10-20T19:48:07 <CodeShark> so any other topics?
11982016-10-20T19:48:08 <Chris_Stewart_5> rc2 issues?
11992016-10-20T19:48:16 <wumpus> which rc2 issues?
12002016-10-20T19:48:21 *** ___tau___ has joined #bitcoin-core-dev
12012016-10-20T19:48:40 <BlueMatt> the lack of rc2 issues =D
12022016-10-20T19:48:43 <Chris_Stewart_5> *crickets*
12032016-10-20T19:48:50 <wumpus> 19:46 < wumpus> instagibbs_: I asked in the beginning, don't think there's any issues with rc2 yet
12042016-10-20T19:48:59 <kanzure> i think he was asking to hear for any
12052016-10-20T19:49:01 <wumpus> if there are, feel free to say so
12062016-10-20T19:49:14 <achow101> what about killing off windows 32 bit builds?
12072016-10-20T19:49:31 <jonasschnelli> I guess in 0.15
12082016-10-20T19:49:33 <wumpus> that's not an urgent topic really
12092016-10-20T19:49:36 <wumpus> yes, 0.15 I'd say too
12102016-10-20T19:49:48 *** gmaxwell has joined #bitcoin-core-dev
12112016-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
12122016-10-20T19:50:24 <sipa> are there likely some who don't know?
12132016-10-20T19:50:29 <wumpus> they both expected this to stilll last only 6 months or so no longer
12142016-10-20T19:50:31 <wumpus> old hw
12152016-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.
12162016-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
12172016-10-20T19:50:54 <wumpus> so that would time with 0.15, which is fine with me, no hurry
12182016-10-20T19:51:27 <Victorsueca> gmaxwell: the lastest travis build seems to have failed for master
12192016-10-20T19:51:30 <instagibbs_> jonasschnelli: yeah i suggested this a bit ago
12202016-10-20T19:51:43 <jonasschnelli> 25 blocks as "normal" confirmation speed sounds ridiculous
12212016-10-20T19:51:45 <achow101> jonasschnelli: I think it's a good idea
12222016-10-20T19:51:46 <instagibbs_> i dont understand why having different command line and GUI behavior like that is "good"
12232016-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
12242016-10-20T19:52:12 <jonasschnelli> Yes. I fear that as well. :)
12252016-10-20T19:52:14 <sipa> it seems reasonable that the default in gui and rpc is the same
12262016-10-20T19:52:18 <instagibbs_> morcos: "match between command-line and GUI" is a starting point :)
12272016-10-20T19:52:21 <BlueMatt> jonasschnelli: I'm for 25
12282016-10-20T19:52:23 <BlueMatt> 25 is good
12292016-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
12302016-10-20T19:52:26 <jonasschnelli> And the slider should probably not touch nTxConfirmTarget!
12312016-10-20T19:52:30 <jonasschnelli> global!
12322016-10-20T19:52:30 <morcos> then you might have to pay areally high fee
12332016-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.
12342016-10-20T19:52:37 <morcos> which is priobably not what you want
12352016-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
12362016-10-20T19:53:13 <morcos> more intelligent fee estimation would maybe gauge the current conditions against historical conditions or something.
12372016-10-20T19:53:20 <gmaxwell> Is anyone working on improving the estimator generally, right now?
12382016-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.
12392016-10-20T19:53:46 <gmaxwell> It could use improvement, though I think bumping is more important.
12402016-10-20T19:53:49 <jonasschnelli> I mean only different confirmations targets
12412016-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
12422016-10-20T19:54:01 <MarcoFalke> ok
12432016-10-20T19:54:02 <jonasschnelli> Someone should review the new bumpfee PR.
12442016-10-20T19:54:17 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8456
12452016-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
12462016-10-20T19:54:29 <morcos> but nothing that really got polished
12472016-10-20T19:54:35 <wumpus> yes, we *must* have a bumpfee for 0.14
12482016-10-20T19:54:40 <kanzure> morcos: had you looked at bramc's work on fee estimation?
12492016-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.
12502016-10-20T19:55:45 <morcos> But an algorithm for bumping when you guess too low makes sense.
12512016-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.
12522016-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
12532016-10-20T19:57:04 <gmaxwell> I was just wondering if there was anything ongoing at the moment.
12542016-10-20T19:57:11 <gmaxwell> (since the subject came up)
12552016-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?
12562016-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
12572016-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
12582016-10-20T19:57:31 <jonasschnelli> Victorsueca: users made different experiences with that
12592016-10-20T19:57:51 <gmaxwell> morcos: And that is what it must do, esp when there is no bump. :)
12602016-10-20T19:57:51 <morcos> thats why i hesitate to set the default to 2
12612016-10-20T19:58:08 <jtimon> 2 mins
12622016-10-20T19:58:19 <morcos> jonasschnelli: i like 6, and i'd be fine with that....
12632016-10-20T19:58:25 <instagibbs_> overpaying is fine until we have bump, heh
12642016-10-20T19:58:31 <gmaxwell> I would be too.
12652016-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
12662016-10-20T19:58:48 <CodeShark> wouldn't overpaying tend to raise fees up?
12672016-10-20T19:59:05 <CodeShark> for everyone
12682016-10-20T19:59:19 <wumpus> only if everyone is going to do that
12692016-10-20T19:59:20 <morcos> CodeShark: ah, that is one of bramc's concerns. i think the existing algo is pretty resistant to that
12702016-10-20T19:59:29 <jtimon> CodeShark: I could think of some kind of overpaying race
12712016-10-20T19:59:31 <jonasschnelli> Most important is probably review of mrbandrews's bumpfee (https://github.com/bitcoin/bitcoin/pull/8456)
12722016-10-20T19:59:36 <morcos> yes unless literally everyone does it
12732016-10-20T19:59:39 <MarcoFalke> We should just set it to a random value *ducks*
12742016-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
12752016-10-20T19:59:41 <instagibbs_> etc
12762016-10-20T19:59:54 <wumpus> instagibbs_: +1
12772016-10-20T19:59:58 <instagibbs_> bitcoin businesses will do settlement on sunday evening to avoid fees
12782016-10-20T20:00:01 <sipa> TINGELINGELING
12792016-10-20T20:00:08 <wumpus> #endmeeting
12802016-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)
12812016-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
12822016-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
12832016-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
12842016-10-20T20:00:25 <instagibbs_> I mean they *do* today, not just hypoethical.
12852016-10-20T20:00:32 <kanzure> am interested to see resolution to jtimon/sipa concerns at some point
12862016-10-20T20:00:55 <jonasschnelli> I think we want resolution on the long term plan since 2 years or more. :)
12872016-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
12882016-10-20T20:01:41 <sipa> jtimon: i'll write my question done in a more detailed and clear way, then
12892016-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
12902016-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
12912016-10-20T20:01:44 <instagibbs_> urgh, my 0.13.1 rc1 node has *0* segwit connections
12922016-10-20T20:01:54 <sipa> kanzure: NO
12932016-10-20T20:01:58 <sipa> kanzure: i don't want to see code
12942016-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.
12952016-10-20T20:01:59 <morcos> wumpus: yes agree entirely
12962016-10-20T20:02:11 <gmaxwell> instagibbs_: yea, apply rc2 directly to forehead.
12972016-10-20T20:02:13 <sipa> kanzure: the code to move things is huge, but trivial
12982016-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
12992016-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.
13002016-10-20T20:03:06 <instagibbs_> gmaxwell: yeah, a little surprising to me how unaggressive behavior was
13012016-10-20T20:03:07 <kanzure> (or i misunsterood a comment from a few minutes ago)
13022016-10-20T20:03:23 <sipa> kanzure: hmm, at this point i do not suggest creating another library
13032016-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
13042016-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?
13052016-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
13062016-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...
13072016-10-20T20:04:09 <sipa> jtimon: i'll write some things down... now lunchtime
13082016-10-20T20:04:22 <jtimon> sure, np
13092016-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
13102016-10-20T20:05:27 <gmaxwell> morcos: yes. Though that control loop may be rather slow.
13112016-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
13122016-10-20T20:06:10 <instagibbs_> wumpus: and I don't think that's likely as long as there exists different time preferences alone
13132016-10-20T20:06:16 <instagibbs_> which clearly exist
13142016-10-20T20:06:23 <wumpus> Victorsueca: some people would find the fee unacceptable and choose a longer confirmation period
13152016-10-20T20:07:04 <wumpus> not everyone cares for transactions to confirm very quickly, and wants to pay a premium for that
13162016-10-20T20:07:31 *** cryptapus has quit IRC
13172016-10-20T20:07:36 <Victorsueca> wumpus: right, I guess that force would balance the whole thing
13182016-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
13192016-10-20T20:08:11 <wumpus> jtimon: we have a problem with review everywhere, unfortunately
13202016-10-20T20:08:39 <CodeShark> as sipa said, deciding where the code should go is the hard part - moving it is easy
13212016-10-20T20:08:50 <wumpus> jtimon: after all the time we've not really managed to find morepeople that will review code changes
13222016-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
13232016-10-20T20:08:57 *** e4xit has joined #bitcoin-core-dev
13242016-10-20T20:09:10 <wumpus> jtimon: sometimes I despair a bit
13252016-10-20T20:09:13 <CodeShark> the review that's needed is on the directory structure and unit definitions - the moveonly PRs are easy
13262016-10-20T20:09:27 <Victorsueca> CodeShark: move it all to /dev/null lol that would be easy
13272016-10-20T20:09:48 <jtimon> CodeShark: well, after the easy moveonlies
13282016-10-20T20:09:57 <Victorsueca> unfortunately the real thing is not that easy
13292016-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
13302016-10-20T20:10:22 <jtimon> there's little parts that you want to take, mostly from ConnectBlock
13312016-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
13322016-10-20T20:11:09 <wumpus> jtimon: I have honestly no idea how to better organize this, or to find people that will help
13332016-10-20T20:11:11 *** rebroad has joined #bitcoin-core-dev
13342016-10-20T20:11:19 <jtimon> wumpus: I understand, we have a big bottleneck in review in general
13352016-10-20T20:11:32 <CodeShark> the majority of the work that's needed here is not in writing code, though
13362016-10-20T20:11:38 <CodeShark> nor reviewing code
13372016-10-20T20:11:40 <CodeShark> it's more conceptual
13382016-10-20T20:12:26 <kanzure> i suppose my last message is more re: large refactors, more than it is about moves.
13392016-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
13402016-10-20T20:12:45 <CodeShark> how should we pull out different units? what are their interdependencies? how should our directory structure look?
13412016-10-20T20:12:57 <kanzure> wumpus: sure. yes.
13422016-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
13432016-10-20T20:13:17 <CodeShark> we're talking design decisions here, though - not so much code
13442016-10-20T20:13:31 <wumpus> jtimon: we have plenty of people writing pulls, though much fewer thtat do useful review
13452016-10-20T20:13:35 *** davec has quit IRC
13462016-10-20T20:13:50 <CodeShark> once we agree on the design decisions, writing and reviewing code will go much more smoothly
13472016-10-20T20:13:58 <wumpus> maybe we should add a rule that for every pull you submit youshould thoroughly review another one :p
13482016-10-20T20:14:05 <morcos> wumpus: 5
13492016-10-20T20:14:07 <instagibbs_> heh :) review without writing is hard though
13502016-10-20T20:14:12 <kanzure> wumpus: unfortunately that degrades into a quid pro quo situation
13512016-10-20T20:14:17 <CodeShark> but if we keep bikeshedding on design decisions while reviewing PRs it will never happen
13522016-10-20T20:14:19 <kanzure> or a quid pro quo review scheme or something
13532016-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
13542016-10-20T20:14:35 *** davec has joined #bitcoin-core-dev
13552016-10-20T20:14:42 <jtimon> it can have subdirs, sure, but I'm not convinced it will need them
13562016-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
13572016-10-20T20:15:33 <CodeShark> anything is better than stuffing everything into main.cpp :p
13582016-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
13592016-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
13602016-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
13612016-10-20T20:16:24 <CodeShark> but that's still a ways off
13622016-10-20T20:16:35 <wumpus> CodeShark: re: splitting up main see https://github.com/bitcoin/bitcoin/pull/8969
13632016-10-20T20:16:47 <wumpus> Victorsueca: ad campaigns?!
13642016-10-20T20:16:59 <kanzure> Victorsueca: core itself did not run ad campaigns.....
13652016-10-20T20:17:03 <wumpus> Victorsueca: I can tell you the bitcoin core project has 0 bitcoins
13662016-10-20T20:17:14 <kanzure> wumpus: oh it's broke! :)
13672016-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
13682016-10-20T20:17:29 <Victorsueca> I mean the thing that was collected on r/bitcoin
13692016-10-20T20:17:35 <kanzure> r/bitcoin is unrelated
13702016-10-20T20:17:54 <Victorsueca> yeah, but they engage people into giving idea on what to spend the remaining
13712016-10-20T20:17:59 <Victorsueca> ideas*
13722016-10-20T20:18:15 <MarcoFalke> What happened to the coins gavin used to give out for testing patches?
13732016-10-20T20:18:27 <instagibbs_> he gave them away
13742016-10-20T20:19:12 *** K-ballo has left #bitcoin-core-dev
13752016-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
13762016-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
13772016-10-20T20:20:01 <CodeShark> I'm not even thinking libconsensus yet :p
13782016-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
13792016-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
13802016-10-20T20:21:50 <sipa> if you have a blockheaderstore you can provide it with the headers
13812016-10-20T20:22:02 <jtimon> I see
13822016-10-20T20:22:04 <BlueMatt> jtimon: you can do processheader
13832016-10-20T20:22:11 <BlueMatt> which i guess is what sipa said
13842016-10-20T20:22:32 <jtimon> yeah, both options are equivalent, yeah, you could do that
13852016-10-20T20:22:38 <sipa> right... though i wouldn't mind having a way to just verify a header without processing it
13862016-10-20T20:22:45 <sipa> just a different level api
13872016-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
13882016-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
13892016-10-20T20:27:18 *** MarcoFalke has left #bitcoin-core-dev
13902016-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
13912016-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"
13922016-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
13932016-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
13942016-10-20T20:34:27 <Victorsueca> then another subdir for those required to validate some BIP-specific rules
13952016-10-20T20:34:30 <jtimon> Victorsueca: that's most of them, I think handling deployments with flags is just fine
13962016-10-20T20:34:57 <Victorsueca> hmmm
13972016-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
13982016-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....
13992016-10-20T20:38:15 <Victorsueca> I think I just duped libraries on different subdirs right?
14002016-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
14012016-10-20T20:40:47 <jtimon> well, some of that stuff is already separated as files
14022016-10-20T20:41:13 <jtimon> for others that isn't I think a single file is probably fine
14032016-10-20T20:42:39 <jtimon> anyway, I'll go back to try to find what's wrong with my new testchain...
14042016-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
14052016-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)
14062016-10-20T20:48:46 *** rebroad has quit IRC
14072016-10-20T20:55:41 *** jujumax has quit IRC
14082016-10-20T21:03:20 *** jcorgan has left #bitcoin-core-dev
14092016-10-20T21:09:30 *** d_t has joined #bitcoin-core-dev
14102016-10-20T21:12:01 <achow101> michagogo: what's the password for bob with your vm?
14112016-10-20T21:13:46 <Lightsword> hmm, my testnet node is stuck
14122016-10-20T21:14:28 <Lightsword> GBT wonât start since itâs stuck on downloading blocks
14132016-10-20T21:16:35 <achow101> michagogo: also, is build.sh your build script?
14142016-10-20T21:26:17 *** rebroad has joined #bitcoin-core-dev
14152016-10-20T21:27:04 *** Ylbam has quit IRC
14162016-10-20T21:27:59 *** cdecker has joined #bitcoin-core-dev
14172016-10-20T21:37:21 *** rebroad has quit IRC
14182016-10-20T22:01:17 <michagogo> achow101: It's gitian
14192016-10-20T22:01:24 <michagogo> (that's in the description, too)
14202016-10-20T22:01:37 <michagogo> And yeah, that's the script I use for building
14212016-10-20T22:01:55 <michagogo> It requires a bit of customization (basically, add your name)
14222016-10-20T22:02:17 <michagogo> It does the whole build process
14232016-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
14242016-10-20T22:03:21 <michagogo> (that last part also requires you to create a GitHub token)
14252016-10-20T22:06:22 *** rebroad has joined #bitcoin-core-dev
14262016-10-20T22:12:00 *** rebroad has quit IRC
14272016-10-20T22:15:04 *** cbit has joined #bitcoin-core-dev
14282016-10-20T22:19:33 *** cbit has quit IRC
14292016-10-20T22:22:04 <michagogo> Lauda: ICYMI, my prepackaged gitian builder VM is up at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
14302016-10-20T22:22:17 <michagogo> Along with a video showing how I made it, start to finish
14312016-10-20T22:22:39 <michagogo> (1 hour, from initial boot from Ubuntu 14.04.5 ISO, including trial and error)
14322016-10-20T22:22:49 <michagogo> (and looking stuff up outside the VM)
14332016-10-20T22:23:12 <michagogo> achow101: Did you get a chance to try it? Did it work for you?
14342016-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 :-/
14352016-10-20T22:27:20 *** aalex has quit IRC
14362016-10-20T22:27:24 *** Guyver2 has quit IRC
14372016-10-20T22:28:28 *** aalex has joined #bitcoin-core-dev
14382016-10-20T22:34:35 *** aalex has quit IRC
14392016-10-20T22:34:58 *** aalex has joined #bitcoin-core-dev
14402016-10-20T22:45:37 *** e4xit has quit IRC
14412016-10-20T22:48:34 *** cdecker has quit IRC
14422016-10-20T22:51:23 *** e4xit has joined #bitcoin-core-dev
14432016-10-20T22:51:34 *** d_t has quit IRC
14442016-10-20T22:52:54 <molz> michagogo, can't see the file, have to have a MS account
14452016-10-20T22:53:01 <michagogo> molz: Really?
14462016-10-20T22:53:02 <michagogo> Hm.
14472016-10-20T22:53:12 <michagogo> I seem to be able to open it in incognito...
14482016-10-20T22:53:56 <michagogo> Oh, hmm.
14492016-10-20T22:54:01 <molz> oh i can download it
14502016-10-20T22:54:07 <michagogo> Okay, do you have a better way for me to get it to you?
14512016-10-20T22:56:21 <michagogo> Maybe I'll make a torrent of it -- does someone have a seedbox that can take ~3.6 GB?
14522016-10-20T23:05:15 <molz> michagogo, i'm downloading Gitianbuilder.7z
14532016-10-20T23:08:40 <michagogo> Ah, it's working? Great
14542016-10-20T23:39:40 <molz> michagogo, sorry i was afk, but no, i got "network error", can't download Gititanbuilder.7z
14552016-10-20T23:57:04 *** PRab has quit IRC
14562016-10-20T23:59:18 *** alpalp has joined #bitcoin-core-dev
14572016-10-20T23:59:19 *** alpalp has joined #bitcoin-core-dev