--- Day changed Mon Aug 19 2019
07:48 < adiabat> tnaka: Do you mean where to get that slice of uint64s?
07:49 < adiabat> given a block of transactions, you need to look up *where* the deleted elements are, which requires a bridge node
07:50 < adiabat> in this case, you can use forest.ProveBlock() to generate a blockProof
07:51 < adiabat> that blockProof.targets will be the positions of those elements (the []uint64 you can give to pollard.Modify())
12:15 -!- adiabat [~adiabat@63.209.32.102] has quit [Ping timeout: 246 seconds]     
13:15 -!- peevsie [peevsie@gateway/vpn/privateinternetaccess/peevsie] has joined #utreexo     
13:23 -!- adiabat [~adiabat@63.209.32.102] has joined #utreexo     
13:33 -!- peevsie [peevsie@gateway/vpn/privateinternetaccess/peevsie] has quit [Quit: leaving]     
17:22 < tnaka> Thank you.
17:22 < tnaka> Does this mean that the Pollard node needs to ask the forest node for a delete number when the block is updated?
17:22 < tnaka> Shouldn't the Pollard node have the logic to look up the number from Hash?
17:22 < tnaka> The search will take a long time.
20:00 < adiabat> pollards can
20:00 < adiabat> *sorry
20:01 < adiabat> pollard's can't, on their own, figure out what to delete if given an element of the set
20:01 < adiabat> they can't even figure out if that element is contained in the set
20:02 < adiabat> if the element is in the set, and the element is stored in a leaf of the pollard, then they could delete it, but they would have to search for that element
20:03 < adiabat> and yeah that would be a linear search since nothing is ordered, which would take a while.  But the real problem is that they may not have the leaf at all.
20:04 < adiabat> Forest has the data structure to look up a node in the forest from a hash, which is the positionMap map[MiniHash]uint64
20:05 < adiabat> it would be possible to keep this structure and keep track of things with a pollard, but it's only useful for a bridge node, and right now pollard doesn't support bridge node operation
20:05 < adiabat> It would be cool to get a "full pollard" mode working where pollard can be both a sparse node and a full bridge node, and maybe get rid of forest entirely
20:06 < adiabat> that would be great in terms of reducing code complexity; pollard is somehwat simpler code, and forest & pollard do pretty much the same thing but with totally different code
20:07 < adiabat> forest *does* seem more optimized for bridge nodes though because there's no pointer overhead, and it's super easy to serialize to disk, or even leave the whole forest on disk
20:08 < adiabat> still, it would be cool to update pollard so it can be a bridge node.  Maybe a pollard-bridge isn't much bigger / slower than a forest-bridge and we can delete all the forest code