--- Log opened Wed Oct 28 00:00:59 2020
02:35 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
02:35 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
04:51 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #utreexo
04:54 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
07:55 -!- belcher_ is now known as belcher
08:51 < ja> adiabat: is there no libetarian option in your state? :O that should make it more than one bit :P
11:16 < adiabat> OK true there's actually a couple bits of data
11:17 < adiabat> actually one of the things to vote on is ranked choice voting, so that will increase the bits per year of the process if that wins
12:21 < ja> adiabat: as far as i can see, ranked-choice voting is already in effect in maine. i don't think the public gets to decide on that specifically, in this election. and i wrong?
12:22 < ja> *am
12:35 < adiabat> In Massachusetts, one of the ballot options is for ranked choice in future elections
12:36 < adiabat> so we can catch up to Maine
12:39 < ja> aah great! exciting!
12:49 < adiabat> yeah also there's a "right to repair" one that makes cars have to have more open firmware stuff so that's nice
12:50 < adiabat> new perplexing problem: block 104573 somehow doesn't get written to the proofs...
12:52 < adiabat> no wait 104572 gets skipped
12:52 < adiabat> anyway I don't see anything weird about the blocks... so why...
13:07 < adiabat> ... that too is intermittent.  Sometimes works ok, sometimes skips a block...
13:12 < adiabat> hmmm... I can't get the bug to happen again.  Does that mean the bug is fixed?
13:13 < adiabat> fixed enough to merge maybe... :)
13:15 < adiabat> I think it makes sense to merge, because if it takes hours of cpu time to trigger a bug, that's a version we should be running on test servers
13:16 < adiabat> also maybe I did something wrong.  I kind of doubt it though, maybe there's just some weird bug where genproofs rarely skips a block
13:16 < adiabat> & maybe it depends on the block & rev files which are strange anyway
13:17 < ja> is it PR 206?
13:19 < adiabat> yeah 206
13:19 < adiabat> I just want to finally be done with it, have spent way too much time on it
13:20 < adiabat> I'll try one or two more times but can't get it to fail now
13:35 < ja> adiabat: i left a comment
14:00 < dergoegge> we dont add op_return outputs to the accumulator because they cant be spend right? but would it not make sense to include them anyway for the case that somebody wants to prove that they included some data with op_return at a specific height?
14:00 < dergoegge> i guess the bridges would have more to store then...
14:01 < dergoegge> but it would enable pruned nodes to check op_return commitments
14:49 < adiabat> I don't think it's worth it to throw op_returns into the accumulator...
14:50 < adiabat> if they want a proof of whatever the op_return means they can use SPV proofs the way they do now
14:50 < adiabat> I can't think of any advantage a utreexo proof would give over the current SPV ones
19:00 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-pxseioohccmgrxvz] has quit [Ping timeout: 260 seconds]
19:03 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-ovtfecsoawfrexqq] has joined #utreexo
20:20 < adiabat> When I merge in the mapless batchproof code I can't get it to work...
20:42 < adiabat> hey dergoegge or kcalvinalvin - could you help check the flatttl branch - there's some interaction with the newer batchproof stuff
20:42 < adiabat> I think
20:43 < adiabat> I didn't change much about the accumulator stuff so it's probably some tiny thing; I changed mainly the serialization of the batchproof but I don't think that broke anything
20:43 < adiabat> what I did change that's maybe conflicting is that the batchProof is now always unsorted
20:44 < adiabat> so bp.Targets is always in block order, not sorted accumulator order
20:45 < adiabat> hm actually I'm pretty sure it's that
20:45 < adiabat> bp gets handed around everywhere
20:46 < adiabat> if something is sorting bp.Targets or doing bp.Targets = bp.Targets[1:] or things like that
20:46 < adiabat> I could instead go to the CSN side and make a deep copy of the AccProof and hand that to the accumulator functions
20:47 < adiabat> might do that for now to merge it, but really that's not a user friendly library
20:47 < adiabat> Because CSNs have to call several accumulator functions in a rom with the same bp
20:48 < adiabat> They call Verify, which calls (bp *BatchProof) Reconstruct()
20:48 < adiabat> Then they call (p *Pollard) IngestBatchProof(), which calls verifyBatchProof() on it
20:49 < adiabat> then they call pollard.Modify() though by then it's basically over, so as long as the targets make it intact to there should be OK
21:20 < adiabat> yeah it's not sorting targets I don't think.... it's something else
21:20 < adiabat> forest and pollard don't agree at all
21:23 < adiabat> I get different swaps for them... even though they're getting the same dels
21:29 < adiabat> ugh never mind
21:29 < adiabat> the internal sorting wasn't in pollard after merge
21:46 < adiabat> anyway it sortof works
21:46 < adiabat> not sure if merge-able but I do really want to merge it because I hate dealing with git
21:47 < adiabat> it usually gets a couple hundred thousand blocks into testnet.  Whcih is pretty good.  Sometimes there's a weird error though where it skips a block
21:47 < adiabat> and that's on the genproofs side it seems
21:56 < adiabat> anyway, kcalvinalvin - if you want to test it beforehand cool but I think I'll merge it tomorrow
21:56 < adiabat> it's not like master works perfectly either; this does seem to introduce a bug but it's a hard one to track down
22:37 < kcalvinalvin> Unit test are broken with 206
22:39 < kcalvinalvin> I'll make a PR to your PR
22:46 < kcalvinalvin> Ok it's def faster haha
--- Log closed Thu Oct 29 00:00:01 2020