00:27:33 <binaryFate> selsta: https://community.rino.io/blocks/frequencies/ is back up, thanks for letting us know
01:04:41 <garth> I never realized that. Thanks
03:42:50 <Mochi101> selsta, I'll start it syncing as soon as this one is done... Last blocks are slow... Mass adoption is real.
03:43:00 <selsta> mine is at 96%
03:43:32 <Mochi101> I'm at 99%
03:44:07 <selsta> https://www.wired.com/story/bitcoin-fog-roman-sterlingov-blockchain-analysis/
03:48:46 <Mochi101> He should get off and he should sue them for the lost year of life.
05:46:38 <Mochi101> 11635 blocks left... these last ones are difficult...
05:47:40 <Mochi101> Not sure how monerod is calculating that estimated time left but I really don't think it's accurate.
06:01:27 <mesaoptimizer> https://cryptwerk.com/pay-with/xmr/ = cryp Twerk. who even makes these names
06:45:56 <Mochi101> <10k for a full sync selsta!
12:46:54 <Guest63> I sent a transaction to a pre-0.18 node that appears to be bricked (stuck at 2688888). I think my transaction is sitting in their memory pool and is not being relayed, because I can't find the transaction on xmrchain.net. It appears like my wallet balance is Y - X where X is the amount of XMR I sent in a transaction to the bricked node. How can I
12:46:55 <Guest63> confirm that the inputs I used to generate the tranasction sent to the bricked node are considered unspent by my wallet?
12:47:52 <moneromooo> Try "incoming_transfers" in monero-wallet-cli. It'll display all outputs, whether they're spent, and in which tx.
12:48:22 <moneromooo> If that tx is not mined (in your copy of the chain), those outputs will show as unspent.
12:52:37 <Guest63> Okay, I do not see the transaction id of the transaction (6fa3cfa75ef51d194dfbceac9714fd67c89eded4ce7711fe36b2b7ee7d74647c) I relayed to the bricked node there. So I assume that my current balance is correct and I can spend the outputs that I previously used in the transaction to the bricked node.
12:52:54 <Guest63> Is my assumption above correct?
12:53:05 <moneromooo> Yes.
12:53:18 <Guest63> Cheers, thank you for your help. Donated 0.1 XMR to the Dev fund.
12:53:45 <moneromooo> A little pony does a happy dance somewhere.
12:54:01 <Guest63> 66ffb708a0069f55738838f22311d04aba8d0eff2e1660a6fe1856c06f8a23dd
12:54:05 <Guest63> Heading off now. Peace
15:30:13 <Mochi101> selsta, 38h 16m to sync. Starting now with the patched daemon.
15:30:55 <selsta> mine took 8h 10min
15:31:04 <selsta> hopefully the lmdb patches speed things up
15:34:47 <hyc> are you using non-default db-sync-mode? probably should, in this case
15:34:58 <hyc> e.g. db-sync-mode=fast:async:1000000
15:35:43 <Mochi101> just a normy start my daemon with zero flags type sunc
15:35:59 <Mochi101> like anybody off the street would do
15:36:13 <hyc> ok, I guess it'll be a good data point
15:36:19 <Mochi101> ie: normal people who just want to get on the road to mass adoption
15:36:21 <Mochi101> :D
15:36:34 <Mochi101> but now I'm syncing with selsta's patched version
15:36:43 <hyc> but that means there's an automatic sync performed...
15:37:16 <Mochi101> sorry?
15:37:31 <hyc> hang on, looking up the details
15:37:36 <selsta> hyc: isn't that only done after the initial sync?
15:38:43 <Mochi101> selsta, how come you included the wallet cli in the archive? Is it any different?
15:40:02 <dsc_> < Mochi101> ie: normal people who just want to get on the road to mass adoption <== I tried to make Feather as plug-n-play as possible, as the original idea was: "sane defaults for noobs who previously used Electrum wallet" and yes some xmr devs dont like that approach but oh well :P there are different target audiences
15:40:25 <dsc_> Mochi101: also 'normies' (your words) dont use the CLI (I would assume)
15:40:33 <Mochi101> I think targetting the normies is the way to go.
15:40:50 <selsta> we include all CLI tools
15:40:53 <Mochi101> mmm... ok... this is true too dsc_ 
15:41:04 <dsc_> you are a closet expert
15:42:06 <Mochi101> Not an expert dsc_. More of a power user I'd say.
15:42:16 <dsc_> Mochi101: dont hide your inner desire to prefer terminal interfaces, nothing to be ashamed about
15:43:56 <Mochi101> I like the CLI wallet over any GUI wallet. But that probably stems from my experience with the GUI before it could smoothly handle wallets with 10s of thousands of transactions.
15:45:16 <Mochi101> Neither Moneroju or Cake can handle my wallets either.
15:46:12 <Mochi101> I reported this on their Githubs so hopefully they address the issues.
15:46:24 <Mochi101> 23% selsta 
15:53:06 <hyc> ok it seems like the timed fsync the code used to do is gone now, anyway
16:33:34 <Mochi101> A little over 1 hour in and I'm at 50% selsta 
17:32:10 <Mochi101> selsta, did you remove the code for the estimated time left to sync?
17:32:17 <selsta> no
17:32:27 <Mochi101> doesn't seem to be giving me this anymore
17:32:57 <selsta> it should be v0.18.1.0 with the lmdb patch
17:33:12 <Mochi101> 55% and I haven't received one message about estimated hours left to sync
17:33:24 <selsta> it only gets printed once in a while
17:33:32 <selsta> if you scroll up it never got printed?
17:33:43 <Mochi101> nope
17:35:46 <Mochi101> Not that it was very accurate anyways.
17:36:00 <Mochi101> Especially the last 100k blocks.
17:36:00 <selsta> rbrunner: any idea why it would not print?
18:13:01 <rbrunner> I noticed that as well that sometimes it stops to print the ETA estimates, but never got to the bottom of it.
18:13:16 <rbrunner> Most of the time simply restarting the daemon gets the estimates back.
18:14:13 <rbrunner> I think it has to do with the fact that syncing is a quite complicated multi-threaded process, and it seems to have a way to proceed that never passes the point in code anymore where I print
18:15:28 <Mochi101> Maybe the patch makes the syncing so fast that the daemon can't even calculate it anymore.
18:15:30 <Mochi101> :D
18:26:40 <rbrunner> Yeah, genius theory.
18:27:01 <rbrunner> :)
19:15:47 <Mochi101> Oh I got a sync message selsta, rbrunner... finally: 2022-08-15 19:14:47.362 I Synced 1790240/2690289 (66%, 900049 left, 1% of total synced, estimated 10.0 hours left)
19:17:11 <Mochi101> oh manybe because of block size the first 66% of blocks equals 1% of the sync in block size and it can't calculate below 1% ?
19:19:20 <Mochi101> estimated time is going up now though
19:22:44 <rbrunner> It's true that early blocks (2014 to 2016 or so) contain many less txs than later blocks and sync much faster, but it's not extreme enough to completely throw off calculation
19:23:44 <Mochi101> I didn't notice if it had messages or not before 66% synced on the unpatched daemon.
19:24:10 <Mochi101> This really "feels" a lot faster.
19:24:38 <Mochi101> Just my perception though, reality will be in the numbers at the end.
19:24:44 <hyc> did you record timings at various points along the way, the last time?
19:24:56 <Mochi101> hyc, sadly no
19:25:11 <Mochi101> I never thought about it.
19:25:13 <selsta> from what I have seen from IRC chat log timing, so far there is no large difference
19:25:42 <Mochi101> selsta, on a windows system?
19:25:45 <hyc> yeah I would guess at most there will be a small reduction in CPU time
19:26:04 <hyc> and if it's I/O bound anyway, that's not going to matter much
19:26:29 <selsta> let's wait for it to finish
19:26:47 <hyc> the existing code doing explicit Flushes spends a lot of CPU time finding which pages to flush, but the number of I/Os is still what it is
19:27:12 <hyc> with the patch, the explicit Flushes aren't needed, but the number of I/Os is still the same
19:27:53 <moneromooo> You can chek times from log timestmaps, assuming you did not nuke logs.
19:28:27 <selsta> Mochi101: you posted when you started syncing and when you were at specific percentages, so far it looks close to identical
19:28:57 <selsta> addding supercop would speed things up a lot
19:29:39 <hyc> I suppose we could try to test crash recovery by running in a VM and randomly doing kill -9 on the VM while syncing
19:30:05 <hyc> if that corrupts things on the old code but not with the patch, then we won
19:31:19 <rbrunner> By the way, here you can see how much the average block sizes vary depending on height, in that hack that I implemented to improve the estimates:
19:31:20 <rbrunner> https://github.com/monero-project/monero/blob/b6a029f222abada36c7bc6c65899a4ac969d7dee/src/common/util.cpp#L1302
19:33:09 <Mochi101> yeah, I was looking at that earlier rbrunner. That's why I mentioned that it might not be able to calculate before 1% synced by size which is 66% of total blocks