--- Log opened Thu Sep 03 00:00:07 2020
07:35 < adiabat> maybe I'm not explaining the design well... there wouldn't be any wasted space with a sparse forest
07:35 < adiabat> it's basically like how pollard works, but instead of a pointer, it's a byte offset
07:36 < adiabat> I think I'll try to write it, maybe it won't be that complicated
10:24 < adiabat> huh, not really sure where this is going: https://github.com/suryanarayana-sankagiri/utreexo
10:25 < adiabat> maybe they're working on a better / faster hash tree..?
10:36 < dergoegge> hm this comment suggests they are working on proof sizes: https://github.com/BoltonBailey/utreexo/blob/87d6b07709c2f53e2959d62ccb9448783af2d10a/patriciaaccumulator/forest.go#L63
10:43 < dergoegge> there is also some copied rust code in there and names like `AccountState` or `account_data`. maybe they are eth people?
10:50 < adiabat> maybe... I'm skeptical of merkle patricia trees but that's just because I only know of ethereum's one
10:51 < adiabat> back of the envelope, since hashes are uniform, you're going to end up with the same path length for a prefix tree or a regular merkle tree...
10:52 < adiabat> anyway if it does reduce proofs sizes, cool
12:41 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #utreexo
12:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
14:25 < ja> dergoegge: efficiency is less important than correctness, so if it is an explicit uint64, there is no problem. but int is dependent on word size, so that is why i brought it up
14:26 < ja> i don't know if 32-bit support is a goal, but if it is, int should be avoided, i guess?
14:26 < ja> but this thread of course is an issue even if on 64-bit, because of the unsigned->signed conversion, of course, which is why calvin brought it up
14:32 < ja> dergoegge: actually, i wonder why the function takes a signed int at all, since it casts to an unsigned on all uses anyway: https://golang.org/src/math/big/int.go?s=26365:26394#L1022
14:33 < dergoegge> Yeah i am not sure if 32-bit support is a goal but why not? in this case `big.Int.Bit` only takes an int. The whole big.Int thing is a bit of a hack because i use it as a bit set. A custom bit set implementation could just use uint64
14:33 < dergoegge> but it does check if i < 0 so it has to be signed
14:33 < ja> if nobody tests on 32-bit, there is no reason to even attempt to support it
14:33 < ja> since the go stdlib uses machine dependent ints haphazardly like here, we are forced to use them too
14:34 < ja> why not support 32-bit? because we don't use it and it distracts just to worry about it
14:35 < ja> if the stdlib had not machine dependent ints, support would be easy. but as the stdlib is now, it is inheritly fragile imho
14:36 < ja> 32-bit arm machines could be desirable of course? especially if utreexo is supposed to be the only viable mobile full-node
14:39 < ja> dergoegge: but it only panics if i<0. so why even accept this type if you panic on it anyway? surely a library function that cannot panic is desirable over one that can, assuming they provide the same functionality.
14:39 < dergoegge> i think i have an old raspberry pi that could be 32-bit maybe i should try to run it on there and see what happens :D
14:40 < ja> yeah why not? i keep reading about people running bitcoind on raspberries, and it takes them a week to sync, or more. so it sounds like a sensible target for utreexo
14:41 < dergoegge> setting a bit with a negative index doesn't make sense they should have just used an unsigned int for the param
14:42 < ja> yeah, that is my point with the "why even accept this type" comment. that is also why i call the stdlib "hapharardly" typed above
14:43 < ja> even haskell has the same issue, you can only shift by machine sized signed ints. and then it crashes on negative shifts! not what you'd expect from haskell ;)
14:48 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds]
14:51 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #utreexo
18:07 < kcalvinalvin> adiabat http://boltonb2.web.engr.illinois.edu/ looks like this guy?
18:08 < kcalvinalvin> seems to be just a researcher
18:18 < kcalvinalvin> https://scholar.google.com/citations?user=vz0S8igAAAAJ&hl=en
18:18 < kcalvinalvin> Yeah ok two guys from UIUC working on reducing proof sizes...
21:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
21:49 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
22:24 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
22:25 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
--- Log closed Fri Sep 04 00:00:08 2020