--- Log opened Wed May 27 00:00:32 2020
05:38 < adiabat> ja: it's supposed to be but isn't
05:38 < adiabat> so that's a bug I guess, but doesn't affect correctness, just slows things down
08:04 < ja> adiabat: do you think it would be slower to return a map[uint64]struct{} (basically a set, since the value type is the unit type) ?
08:05 < ja> that wouldn't be in order, but i guess if you can traverse in order, it would be fine?
08:08 < adiabat> yeah there's no ordered maps huh
08:09 < adiabat> also it seems like even without maps it woudln't be to hard to avoid duplicate
08:10 < ja> by enforcing that the new element is bigger than the last and not just unequal?
08:12 < adiabat> possibly...
08:12 < adiabat> if it's always duplicates back and forth yeah
08:13 < adiabat> but does it ever go 140, 141, 134, 144...
08:13 < adiabat> I'm not sure
08:14 < ja> well, changing != to < breaks the tests
08:16 < adiabat> yeah I think it needs to be a bigger change than just that
08:16 < adiabat> I can take a look later this week & maybe get it optimized
08:18 < ja> excellent! i can't grok it...
08:20 < adiabat> heh yeah I think that was an area that was tricky and didn't understand it super well either, and once I got it working just said OK good enough
08:20 < adiabat> but... it's not really good enough
09:15 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
10:25 < dergoegge> i got started on the integration test, but genproofs currently panics and i am unsure if thats my fault or if there is actually something wrong. all the test currently does is mine 101 empty blocks and then run genproofs. i created a draft pr: #132
10:27 < kcalvinalvin> dergoegge interesting WIP PR. Do you plan to remove the json file for the completed PR?
10:29 < dergoegge> yeah i want to get rid of it, i currently dont know a good way to generate lots of test transactions. that file is just used to create 1000 txos.
10:29 < dergoegge> the rpcs sendmany and sendtoaddress are kinda slow, so generating lots of transactions would take a while
10:34 < kcalvinalvin> adiabat any ideas?
11:34 < adiabat> faster than sendtoaddress?
11:34 < adiabat> or why the panic?
11:35 < adiabat> Not sure about panic, for me genproofs runs OK on testnet / mainnet data now
11:35 < adiabat> with current master
11:36 < adiabat> sendmany is probably not as fast because of the sighash problem
11:36 < adiabat> I think it doesn't default to mining to segwit
11:36 < adiabat> so if you can set it to mine to bech32 addresses and send to bech32 addresses that might be faster
11:37 < ja> it doesn't mine to any address per default now, you gotta supply it
11:37 < ja> generate -> generatetoaddress
11:37 < adiabat> also instead of the address list you can just call 
11:37 < adiabat> yup that :)
11:37 < adiabat> oh also
11:38 < adiabat> yeah just getnewaddress and pipe that to sendtoaddress
11:38 < adiabat> but presumably the wallet is slower than the block checking, so that might slow it down
11:38 < adiabat> but more small transactions is maybe faster than fewer large transactions, and for utreexo testing either works
12:15 < kcalvinalvin> adiabat I don't think we even need to do a fake utxoview
12:16 < kcalvinalvin> Everything we need is there! This is exciting :)
12:42 < kcalvinalvin> In my WIP PR, (#128). The directory 'consensus/' isn't getting any complaints by the compiler now :) Haven't tested yet but I think we're there
13:16 < adiabat> I guess the approach I was looking at was to use as much btcd code as possible
13:17 < adiabat> consensus/txvalidation.go is a lot of code but it's all pretty much copied from btcd right?
13:19 < adiabat> ... I mean of course everything in btcd is lowercase which is superannoying, so the newTxValidator() call is private...
13:20 < adiabat> I guess I'm just more coming at it from trying to change / add the fewest things to btcd
13:21 < ja> so you'd have a fork with a diff that just changes capitalization?
13:21 < adiabat> like if all we need is NewUtxoEntry(), and it doesn't touch anything else, that seems like people would be fine merging it
13:21 < adiabat> but changing the txValidator struct so it doesn't have a UtxoViewpoint in it anymore... that's not really something they can merge
13:21 < adiabat> and keep normal btcd operation
13:22 < adiabat> ja: ideally not a fork
13:22 < adiabat> if we open a PR that's just hey can we add NewUtxoEntry() it's like 5 lines and doesn't change anything
13:23 < adiabat> I mean maybe they'd ignore the PR but it seems pretty harmless and easy to merge
13:39 < ja> roasbeef is maintaining it now, so it's all up to him, i guess
13:45 < rjected> Well jcv has been more active, I can help get this merged if you want - it doesn't seem controversial
13:45 < rjected> btcd process to get stuff merged is usually just submit PR, then review, then get maintainer to merge
13:47 < rjected> First step is submit PR though, who wants to do it?
13:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
13:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
14:09 -!- dergoegge [~dergoegge@196.240.57.204] has quit [Ping timeout: 246 seconds]
14:12 -!- dergoegge [~dergoegge@196.240.57.204] has joined #utreexo
14:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
14:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
14:58 < dergoegge> adiabat i have not been able to get genproofs to run in regtest mode, it just panics. you should be able to reproduce this by running the test script in my pr *but* read the top comment in that file first so you dont mess up your bitcoin.conf.
15:01 < adiabat> dergoegge: ok will try the regtest pr, maybe there's something going on that's regtest specific..?  I can think of a few things
15:01 < adiabat> like maybe the regtest blk.dat files have some different formatting
15:01 < adiabat> I think so far I've only looked at testnet / mainnet
15:02 < adiabat> rjected: I think before a PR we should have code that uses it to do something
15:02 < adiabat> if it's just "hey we might want this or use this later" it's not as persuasive
15:02 < adiabat> if it's "hey we have utreexo working calling btcd, with a couple minimal additions (mainly for exporting) we can use it
15:03 < adiabat> that seems like they're more likely to merge it, especially if there's no impact to btcd
15:04 < adiabat> if we can then start working on better integration or getting btcd itself to use utreexo libraries, great
15:04 < adiabat> but that would be later once we've got this genproofs /ibdsim working well
15:04 < dergoegge> adiabat: that could be the case, the error comes from util.GetRawBlockFromFile
15:05 < adiabat> hmm I can check, it might be using a different 4 bytes separating each block
15:40 < dergoegge> also: i tried using sendtoaddress and piping it getnewaddress at first but thats just way to slow or i guess it depends on how many transactions we want in the blocks. should the blocks be full? or are ~10txs per block enough? 
15:46 < rjected> adiabat: yeah you're right there probably should be some need for the export rather than adding an export just in case
15:48 < rjected> But in the event that there is that need, or you have to do some weird workaround to call btcd code, it would be a good idea to pr I think
15:48 < rjected> especially if it's a
15:48 < rjected> *an export / just making something public
15:49 < rjected> changing APIs or making something non backwards compatible would be more difficult (but not impossible, depending on how necessary) to merge
16:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
16:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
17:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
17:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
17:36 < dergoegge> adiabat: i figured out what caused the panic. #133 fixes it.
19:19 < kcalvinalvin> adiabat Ah ok sure. Are you working on it at the moment? I could change to use a pretend utxoviewpoint fairly easily
19:24 < kcalvinalvin> yes txvalidation basically replaces every utxoviewpoint with the actual data it needs
19:24 < kcalvinalvin> Besides that it
19:24 < kcalvinalvin> 's pretty much the same
19:32 -!- dergoegge [~dergoegge@196.240.57.204] has quit [Read error: Connection reset by peer]
19:41 -!- dergoegge [~dergoegge@196.240.57.204] has joined #utreexo
21:16 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds]
22:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
22:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
--- Log closed Thu May 28 00:00:33 2020