--- Log opened Wed Jan 26 00:00:41 2022
03:43 < Earnestly> Your website and information is confusing people with regards to what problem you're actually solving.  You suggest blockchain size isn't a scalability issue, so implying that users will have to store the entire chain regardless of utreexo.  The only thing utreexo does is reduce size of 4GB utxo set, which is irrelevant when compared to blocks
03:44 < Earnestly> This doesn't make sense to me as I would assume your intention is to reduce that storage requirement as well
03:44 < Earnestly> Otherwise what's the point
03:44 < Earnestly> > The current system state, however, is much smaller, at under 4GB, and deals with only who owns what right now.  This state size has generally increased over time, but has in fact decreased a bit this year.
03:45 < Earnestly> The next sentence mentions it being discarded, this is how I read it, but it's not clear
03:45 < Earnestly> All talks focus on utxo size
03:46 < Earnestly> > The history, despite its much larger size, is not in fact the scalability concern
03:46 < Earnestly> > not in fact the scalability concern
03:47 < Earnestly> This is extremely misleading, or implies that utreexo does not deal with this issue, and is completely irrelevant because 4GB is nothing when the history is 400GB
08:27 < dergoegge> earnest: the storage requirement for the chain history can already be reduced by running a pruned node (iirc Bitcoin Core allows pruning the history down to 550 MB)
08:27 < dergoegge> when running a pruned node your main storage burden becomes the utxo set (this is probably the mode in which utreexo makes the most sense)
08:27 < dergoegge> the utxo database is currently multiple GB in size (currently 4-5 GB as you mentioned) and stored on disk with lots of reads/writes happening during Initial Block Download (IBD)
08:27 < dergoegge> if all you have is a HDD then IBD will take significantly longer given all the read/writes.
08:27 < dergoegge> with utreexo this storage requirement is reduced since the utxo set now fits entirely into RAM (a node that runs on a HDD will sync just as fast as one utilizing a SSD, whether or not you choose to store the entire history)
08:28 < Earnestly> I see, so it is just about utxo size.  I thought there was more to it
13:19 -!- Earnestly [~earnest@user/earnestly] has left #utreexo [WeeChat 3.4]
15:59 < adiabat> Earnestly: blockchain storage size isn't really an issue as pruning has been possible for many years
16:00 < adiabat> oh.  gone.  well yeah didn't seem like they were interested anyway
16:00 < adiabat> kcalvinalvin: pushed a commit in the nilswap branch which *maybe* fixes your issue but... it's not good.  I think it also breaks a lot of caching things
16:01 < adiabat> in the 1, 3, 4, 5 example... well that example is OK.  but imagine a similar setup where 8 is missing (along with 2, 3)
16:02 < adiabat> moving something into position 9 is possible, but you can't populate the childred of 9: 2, 3
16:02 < adiabat> that would need 8 to exist for the pointers to be there.  Right now you can't put an "empty" 8 with niece pointers as that messes everything up
16:03 < adiabat> I don't know how often that will actually happen though, but it might in some cases.  maybe it's not a huge deal to lose some data you wanted to remember.  Seems not great though.
20:57 < kcalvinalvin> Gone before you could explain the cool things you can do!
20:58 < kcalvinalvin> I don't really think any of us are that excited *just* the pruned nodes being smaller so I get his sentiment a bit
20:59 < kcalvinalvin> adiabat: cool I'll take a look
21:00 < kcalvinalvin> Also, is there a website about utreexo?
21:01 < kcalvinalvin> I guess this? https://www.media.mit.edu/projects/utreexo/overview/
21:02 < kcalvinalvin> What do you guys think about https://github.com/mit-dci/utreexo/issues/337#issuecomment-1020924928
21:03 < kcalvinalvin> Like it works. I need to check if things are erroneously remembered but I don't think they are
21:28 < adiabat> the n.remember part?
21:28 < adiabat> It "fixes" the problem, but just by remembering almost everything
21:29 < adiabat> it makes it so that any node which is remembered will also have its sibling remembered.
21:29 < adiabat> maybe that's an OK way to fix it for now; crank up the caching rather than crank it down with being able to swap nils around
21:49 < kcalvinalvin> It is a one liner :)
--- Log closed Thu Jan 27 00:00:42 2022