01:49:52 <r4v3r23[m]> <selsta> "but it might have only been..." <- can we get it in next release?
06:39:53 <ErCiccione> Can somebody give a quick review to this? https://github.com/monero-project/monero-site/pull/2186
13:03:12 <selsta> r4v3r23[m]: do you use some kind of QR transfer? or is there other software that makes use of the size reduction?
15:07:38 <xmrack[m]> I need help explaining what is going wrong here. I am trying to use get_transactions() but when I pass it a vector of 208 crypto::hash objects it only successfully finds 27 and puts the other 181 into the missed_txs vector. How could it possibly “miss” transactions that are on the blockchain?
15:07:40 <xmrack[m]> https://github.com/moneroexamples/onion-monero-blockchain-explorer/pull/289/commits/3de6cc45da07b6828cdba214983c97f153eeb78e
15:09:31 <DataHoarder> as a note without any context xmrack[m] get_transactions in restricted nodes limits itself to maximum 100 txs
15:11:31 <moneromoooo> Is your blockchain pruned ?
15:48:39 <xmrack[m]> Ugh okay I’ll resync
15:49:16 <Rucknium[m]> xmrack: My guess is that you have a corrupted blockchain: https://libera.monerologs.net/monero-dev/20230224#c210107
15:49:16 <Rucknium[m]> Solution is to sync from genesis again. IMHO monerod should realize it's corrupted and request data from peers to repair the corruption. It's not ideal to have nodes with corrupted blockchains forming parts of the network out there.
16:10:22 <r4v3r23[m]> <selsta> "r4v3r23: do you use some kind of..." <- yes. while it works now, any file size reduction in any of the 4 files (outputs, key images, unsigned tx, signed tx) would imrpove UX greatly
16:18:29 <moneromoooo> Repairing corruption is hard, since you do not really know what is corrupted.
16:19:31 <moneromoooo> Though I suppose monerod could nuke the chain and resync everything. Everything contains every possible set of corruptions...
16:19:41 <moneromoooo> People would get quite annoyed at this I think :D
16:37:53 <Rucknium[m]> Can't the block hashes be used to check for corruption? monerod could notice that txs are being missed, then check the block hashes of the blocks that are supposed to contain those txs. IIRC bitcoind lets you re-check hashes since X block height with an RPC command. Anyway, maybe more trouble than it's worth.
16:43:05 <Rucknium[m]> https://bitcoincore.org/en/doc/24.0.0/rpc/blockchain/verifychain/ is the bitcoind command
16:44:43 <moneromoooo> You could do that. But if your starting point is your chain is corrupted, you cannot know the extent of the corruption.
16:45:02 <moneromoooo> The tx hashes you get from a block could be corrupted for example. That might be why you're not finding them.
16:45:37 <moneromoooo> Now if you ask another node and they do find them, it does suggest they're right, but you can't really tell for most data without a lot of work.
16:46:09 <moneromoooo> In this particular case though, it's likely that the db is pruned.
16:46:33 <moneromoooo> But since the question was ignored, we may never know.
19:15:56 <ofrnxmr[m]> moneromoooo:  xmrack had said the blockchain was not pruned 
19:29:28 <moneromoooo> Oh really. Funny that, I have that missing. Thanks.
19:34:23 <DataHoarder> ^ thanks Matrix bridge dropping messages
22:45:08 <selsta> r4v3r23[m]: there are some merge conflicts :/
22:45:18 <selsta> but will try
23:36:32 <selsta> r4v3r23[m]: PR was merged before we branched to release-v0.18 which means it's still included in release
23:37:19 <selsta> why do you think it's reverted?