00:00:59 <m-relay> <j​effro256:monero.social> I hadn't considered that the slots let you guarantee that you bound to chain IDs once
00:01:05 <m-relay> <j​effro256:monero.social> In log(N) size
00:01:47 <m-relay> <j​effro256:monero.social> Is there any code in the core repo which actually verifies branch proofs ?
00:02:08 <m-relay> <j​effro256:monero.social> Or can create them even?
00:22:53 <m-relay> <j​effro256:monero.social> src/crypto/tree-hash.c looks like it contains that code
07:16:39 <sech1> Proof verification is done by the aux chain
07:17:27 <sech1> That code is not used in monerod, as far as I know. But I'm working on adding it to p2pool
17:00:25 <andrey8ezkaro> Hello everybody, i'm using monero-ts to interact with my wallet. How to subscribe on output received, for example? Does it work?
18:19:52 <selsta> can someone explain why it's not possible to simply "cut" the LMDB file? https://github.com/monero-project/monero/issues/9081
18:36:08 <Lyza> he's not wrong though, it would be a really nice feature that like, BTC etc all do. Idk if that would mean using a whole new database or what, but it's hella inconvenient having one fat file
18:43:23 <selsta> or just set --db-sync-mode safe if you prefer safety over speed
18:46:08 <Lyza> is your opinion it's "not possible" or that it doesn't matter if it's one file
18:46:55 <Lyza> I'm not saying it's worth whatever it would take just, other blockchains do it, so it seems possible, and idk, from my perspective nicer
18:48:02 <selsta> can you show me where bitcoin devs recommend "cutting" the blockchain file?
18:48:18 <Lyza> I can show you the blockchain directory of my bitcoin node and how it's full of hundreds of files
18:48:39 <selsta> that doesn't mean that you can delete the last file and resolve corruption
18:49:01 <selsta> unless the bitcoin devs claim this? I would be curious to see this
18:49:51 <Lyza> I've never had a reason to mess with the files manually so I couldn't tell you to be honest, it may very well not work that way
18:50:00 <moneromooo> It's trivially possible but you might not like the side effects :)
18:50:48 <moneromooo> A brute force append only file that gets rotated every N bytes would do. But you'd carry all the history, and it would grow in size at an amazing speed.
18:51:00 <moneromooo> It would also be very slow to look up into.
18:51:10 <moneromooo> But it's easy to see it would work.
18:51:56 <m-relay> <r​ucknium:monero.social> AFAIK `bitcoind` doesn't even have a `pop_blocks` command.
18:52:10 <moneromooo> You could then delete the L last files and restart syncing. The software would have to re-sync to know exactly how many "lost" butes are in the last file (or maybe more than one last file) but doable, if low.
18:52:17 <m-relay> <k​ayabanerve:matrix.org> It has invalidateblock
18:52:36 <m-relay> <k​ayabanerve:matrix.org> So yes, you can enforce a reorg to a specific point.
18:52:48 <Lyza> It looks like bitcoin core used to use Berkeley DB and now uses or is moving to SQLite
18:53:04 <Lyza> if that tells anyone anything
18:53:11 <m-relay> <k​ayabanerve:matrix.org> You can also the re-check that block to resync iirc
18:53:52 <selsta> from what I can see they recommend restoring from backup, resync or using -reindex  / -reindex-chainstate
18:53:59 <selsta> just deleting some files like isn't a good idea
18:54:45 <selsta> Berkeley DB and now SQLite is for the wallet database, they use leveldb for the blockchain itself
18:55:06 <Lyza> gotcha
18:55:09 <moneromooo> Technically, monero stores block and tx blobs, so it could be made to dump most indexed tables, but not the blob tables. Then resync from that.
18:55:36 <moneromooo> It's not a "drop the last N" but you'd save the download, if that's what annoy people for some reason.
18:55:54 <Lyza> "for some reason" hehehe
18:56:07 <moneromooo> Of course it doesn't help you if the blob tables are what's corrupted.
18:56:18 <moneromooo> Well, the download typically isn't the bottleneck is it ?
18:56:35 <moneromooo> Except maybe for people who just want to trust some random internet peer.
18:57:46 <Lyza> Depends on the machine and internet connection I guess but it's often not, people just think it is because their system monitor doens't show disk iops
18:58:04 <moneromooo> Actually... if you'd already verified up to height H, and you dump indexed tables, you can just reindex without verifiying up to H...
18:58:36 <moneromooo> Again, assuming the blobs didn't get shot.
18:59:00 <moneromooo> They do take up a lot of the db though, so they're likely to be shot if corruption happens.
18:59:55 <Lyza> I definitely don't know enough to have much opinion, but if there were more options for DB recovery that didn't involve wiping everything that would be pretty nice
18:59:56 <moneromooo> However, I suppose you can re-download a tx and accept whatever matches its known txid.
19:00:17 <moneromooo> It gets a bit more fiddly though, if you start second guessing what's shot and what's not.
19:00:40 <moneromooo> (ie, if what got shot is the txid keys for a tble)
19:01:34 <moneromooo> Still, I reckon there's a bug in monerod's db txn code that makes something non atomic when it should be.
19:01:45 <moneromooo> Not going to look for it anymore though.
19:03:00 <selsta> the person in the issue seems to have had a power outage + external hdd
19:03:36 <selsta> likely not a monerod bug in this case
19:03:52 <Lyza> I can see why that's a setup someone would *want* to work, but ew