--- Log opened Mon May 25 00:00:31 2020
00:44 -!- dergoegge [~dergoegge@196.240.57.220] has quit [Read error: Connection reset by peer]
00:46 -!- dergoegge [~dergoegge@196.240.57.220] has joined #utreexo
07:37 < kcalvinalvin> adiabat does ibdsim work for you at the moment?
07:38 < kcalvinalvin> It just panics that it couldn't connect to 127.0.0.1 on master
08:07 < dergoegge> kcalvinalvin: is there a log from genproofs that says "blockServer accept error: ..."? is 127.0.0.1:8338 still accepting connections? if not i might know what happened
08:09 < kcalvinalvin> Ah I just didn't have genproofs running. Huh that's cool, didn't know networking stuff is almost there
12:01 -!- dergoegge [~dergoegge@196.240.57.220] has quit [Ping timeout: 246 seconds]
12:22 -!- dergoegge [~dergoegge@196.240.57.220] has joined #utreexo
15:43 -!- dergoegg1 [dergoegge@gateway/vpn/nordvpn/dergoegge] has joined #utreexo
15:46 -!- dergoegge [~dergoegge@196.240.57.220] has quit [Ping timeout: 260 seconds]
16:09 -!- stevenroose [~steven@irc.roose.io] has quit [Quit: ZNC 1.7.4 - https://znc.in]
16:11 -!- stevenroose [~steven@irc.roose.io] has joined #utreexo
17:26 < adiabat> Hi - sorry was offline for the weekend, but back to work :)
17:26 < adiabat> dergoegge: welcome & glad to have more people working on this!
17:27 < adiabat> there are lots of things to work on -- there's also a weekly utreexo call in 13 hours
17:28 < adiabat> if the timezone you're in works for that you're welcome to join & we can talk about what we're working on and good places to start
17:28 < adiabat> or can stick to IRC / github, whichever works
17:28 < adiabat> I should probably update the github project stuff...
17:29 < adiabat> one area I don't think anyone's working on now is an integration test for the cmd side
17:29 < adiabat> something like a script that spins up a bitcoin-core regtest node, mines lots of blocks and makes lots of transactions
17:30 < adiabat> and then the cmd side can go through the blk.dat and rev.dat files it creates
17:30 < adiabat> so we have randomized blk/rev files without having to move around gigabytes, just generate on the fly
17:38 -!- dergoegg1 is now known as dergoegge
17:43 < adiabat> also yeah the #130 issue... commented on that
17:43 < dergoegge> adiabat: i will try to join, but may be i wont make it since my sleep schedule is all fucked up currently... thats at 15:30CET?
17:44 < adiabat> yes 15:30 CET, 9:30am EDT for me
17:45 < adiabat> I'm OK doing it at a different time, kcalvinalvin is in korea and fanquake is in australia so there's not really any good time for everyone heh
17:50 < adiabat> ja: looking at makeDestInRow() ... the comment calling it is a bad sign...
17:52 < dergoegge> no thats fine for me, i have to get my schedule back to normal anyway.
17:55 < adiabat> ok cool it's meet.jit.si/utreexo
17:55 < adiabat> ja: I think there was a reason for the len(hashDirt) != 0 part... but maybe that reason is gone?
17:55 < fanquake> I should be around again tonight
17:56 < adiabat> I should comment more *when* i'm coding, not after...
17:56 < dergoegge> the integration tests sound like a good thing for me to work on, since it doesn't really require indepth knowledge of the accumulator package
17:57 < adiabat> dergoegge: yeah it could even be in python or shell script or something
17:57 < adiabat> I thought something like that would exist in the bitcoin-core test suite but not really I guess
17:57 < ja> how would you get the block data into utreexo from shell script :O ?
17:58 < adiabat> shell script would call bitcoin-cli rpcs a bunch
17:58 < adiabat> to generate a few blk / rev files
17:58 < adiabat> then stop bitcoin-core
17:58 < adiabat> then run cmd genproofs
17:58 < adiabat> and cmd ibdsim
17:59 < adiabat> maybe shell script wouldn't be the best way to do it, but I think you could
18:03 < dergoegge> i could also do it in go and use some bitcoin rpc client library for the rpc calls, that way we wouldn't have to use a different language.
18:03 < adiabat> sure, also true, it can certainly be done from go test as well
18:07 < dergoegge> why does bitcoin core need to be stopped? is that because of parallel access to leveldb? because eventually that shouldn't be the case right?
18:08 < ja> here's a weird idea: you can make c bindings for utreexo and have bitcoind call directly into it
18:09 < adiabat> I guess bitcoin core can keep running... we just need read access to the blk/rev files
18:10 < adiabat> ja: heh yeah, could do that... cfields made the start of a c++ utreexo library too
18:11 < adiabat> I just want to get it like "working" (even if buggy / slow) and then I guess have a spec / other languages / bindings / implementations
18:12 < ja> formal spec like promela or tla+ ? :P
18:12 < ja> regarding reading blk/rev i assume bitcoin doesn't open them in some exclusive mode?
18:13 < ja> *bitcoin-core
18:15 < adiabat> hah not "formal" but more bip-like
18:15 < adiabat> I think it just appends only to blk / rev
18:16 < adiabat> if it re-arranged things in them I'd be pretty ... like, cmon you're writing things in the wrong order *and* reordering the data...?
18:34 < dergoegge> regarding #130: could this also be a bug in bitcoin-core? seems weird that blk and rev files randomly don't have the same order.
18:37 < dergoegge> apperently not: https://bitcoin.stackexchange.com/a/92141/96288
19:54 -!- dergoegge [dergoegge@gateway/vpn/nordvpn/dergoegge] has quit [Ping timeout: 265 seconds]
20:00 < adiabat> dergoegge: yeah it's pretty random, I don't think these .dat files are really meant for external use...
--- Log closed Tue May 26 00:00:31 2020