--- Log opened Thu Nov 12 00:00:14 2020
01:00 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-jfxechrxuoddrluf] has quit [Quit: Idle for 30+ days]
04:02 -!- belcher_ is now known as belcher
05:38 < dergoegge> kcalvinalvin: fine with me. i have time tomorrow. 
05:43 < adiabat> hey tomorrow = friday?  I could go on a call.  would also be nice to get a bitcoind person or two for their perspective
05:45 < kcalvinalvin> fanquake?
05:45 < kcalvinalvin> The usual 10am EST friday is good with me
06:48 < dergoegge> Yes friday. Usual time is also fine with me. Wasnt it 9am EST?
06:53 < kcalvinalvin> oh whoops. 9am it is then
07:16 < ja> kcalvinalvin: it is going ok albeit at a slow pace ;) my next idea was to make an algorithm to convert the forest indices used everywhere to van laarhoven lenses. then i can feed the indices emitted by e.g. remTrans into either the algorithm that actually swaps, or alternatively, one that just animates.
07:18 < ja> because if i have two lenses into a tree, i know how to swap those
07:19 < ja> (swap them graphically)
07:37 < ja> i would like to develop an effectful DSL that allows me to implement the tree manipulation algortihms once more with algebraic datastructures 
07:38 < ja> because my current implementation is just ported line by line from go. it is pure, but really imperative
07:39 < ja> you might say i am somehow making it harder by trying to do it functionally. but i feel like i will only really understand the algorithm once i understand the invariants!
07:41 < ja> it is luckily only imperative within each function. to make it work on ADTs i am still unsure to what degree i am prevented from porting function-by-function
07:44 < ja> so lets say i have a Collapse datatype, and i make some algorithm that seems to do what the go code is doing when swapping collapses. then i can run property testing on that, and then i have to decide how much is part of algorithm and how much is irrelevant. for example, in a ADT utreexo, remapping shouldn't be necessary, right?
07:46 < ja> but a Collapse for a go-utreexo is a pair of numeric indices. for an ADT utreexo, what would it be, a pair of lenses? i don't see why not
07:47 < ja> hmm, i should email Russell O'Connor, he is both interested in FP and in Bitcoin...
12:24 < adiabat> kcalvinalvin: hey sorry I just can't merge #225
12:25 < adiabat> it offends my sensibilities :)
12:25 < adiabat> heh I mean, it may well be faster, but that just means whatever I wrote before is horribly slow
12:25 < adiabat> so posted a comment with something that may be faster than both ways.  hopefully.
12:31 -!- cfields [~cfields@unaffiliated/cfields] has joined #utreexo
13:17 < adiabat> also - I can do a call at 9am EST tomorrow but only for 30 min, I have another call at 9:30
13:17 < adiabat> but probably can figure out what to do in 30 min
13:18 < adiabat> could also call back in after 11 or on IRC etc
15:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
15:23 -!- rjected[m] [rjectedmat@gateway/shell/matrix.org/x-roobkftcqalnmbls] has quit [Ping timeout: 260 seconds]
15:24 -!- rjected[m] [rjectedmat@gateway/shell/matrix.org/x-vyyjcqjxruwgmklv] has joined #utreexo
15:26 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
15:41 < adiabat> also -- just to make sure, for pollard proof ingestion
15:41 < adiabat> we're still hashing all the way up to roots?
15:42 < adiabat> I thought someone (not me) put in code so that it checks only up to existing hashes in the pollard
15:43 < adiabat> I guess not.  Well, should do that next then.  verifyBatchProof() is a bit of a mess....
15:44 < adiabat> making it a method on Pollard wouldn't help make it any simpler I guess.  but would make it a lot faster
15:45 < adiabat> also it's not threaded at all.  hm.  that's where the hashing really needs to be multi-thread, as csn speed is more important than bridge...
15:46 < adiabat> ok... verifyBatchProof().  THEN can start ttl.  they're related, can't really do TTL without changing the verify
16:40 < dergoegge> yeah it hashes all the way up to the top. we had code that checks if a position is cached and does not hash but that was actually a bad idea see #218. 
16:40 < dergoegge> but only hashing up to populated nodes makes a lot of sense
16:41 < dergoegge> its tricky to do though because there could be hashes in the proof that you then dont actually need 
16:43 < dergoegge> or maybe it would work if you just have the correct partial proofs?
16:46 < dergoegge> right now the verify needs the entire proof thats true, so that has to change
16:49 < dergoegge> by making it a method of pollard you mean doing verification and ingestion at the same time?
16:50 < dergoegge> the part that i dont like about verifyBatchProof is this loop: https://github.com/mit-dci/utreexo/blob/98f07897bde61dfe9a8f8d4944183b5f7d4402a7/accumulator/batchproof.go#L179
16:51 < dergoegge> it only exists because the target hashes are included in the proof
18:23 < adiabat> ah right, target hashes shouldn't be in the proof part, we're sending the leafdata anyway so it's redundant to send target hashes
18:28 < adiabat> and yeah, if sending less than the whole proof it needs to match up ... it should be doable but maybe have to change the format of the proof hashes a little
19:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #utreexo
19:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
--- Log closed Fri Nov 13 00:00:15 2020