02:09:06 <benjamin1492> hi, just a noob lol
05:18:27 <UkoeHB> a afungible[m]1 if you can’t pay the fee, then you can’t make a tx
05:32:12 <baro77[m]> <UkoeHB> "You’d be better off writing a..." <- What’s ch2 ?
05:34:34 <moneromooo> I assume chapter 2.
05:37:31 <baro77[m]> moneromooo: I should wait to be fully waken up in the morning before writing 😂
05:38:27 <baro77[m]> Too much worried to miss the pace lol
08:31:45 <Guest49> Few days ago Someone told me that ge_p2 was of 120 bytes each X Y Z of 40 bytes just for sake of calculation but today I debugged the code and found that when ge_double_scarlarmult_base_vartime() return a point after calculating aG+bH eah of coordinate of the new point returned is not of 32 bytes as stated in ztmw for point addition their is
08:31:46 <Guest49> formula for each coordinate but at last mod is applied on them at every step of point addition and this mod makes that coordinate of 32 bytes as mod q is of 32 bytes but here when calculating function returns point it actually returns each coordinate as 40 bytes and than ge_tobytes() who is responsible for compressing point to present it in key
08:31:46 <Guest49> form instead of point form than ge_tobytes() passes it to fe_tobytes()  which actually is applying mod on the point that has been calculated and also returns comprehensive point. My question is why x,y is not produced as per formula in ztm2.
08:32:50 <Guest49> As formula states when new point's x,y is calculated it goes through mod and than that mod applied point goes to calculated with itself in point doubling
08:36:22 <Guest49> For point doubling P's x,y are used to produced P2 by adding point P+P using the formula of twisted curve where in production of P2 the points produced by applying mod at every step
09:23:50 <afungible[m]> <UkoeHB> "a afungible if you can’t pay the..." <- Yes, I'm aware. My point was even if I top up the wallet with sufficient amount to cover for fees, I cannot transfer out all of my balance. It's the same case again.
09:23:50 <afungible[m]> Isn't this a problem?
09:35:34 <nssy> Are there changes for the upcoming v15,16 fork that pools need to be aware of?
09:36:41 <sech1> Pools only need to update monerod to v0.18
09:36:53 <sech1> P2Pool miners also need to update to p2pool v2.2.1
09:41:57 <nssy> did anything on the blocktemplate change?
09:43:55 <sech1> view tags were added, but they are not a part of the hashing blob for miners, and if pools use get_block_template RPC, they just need to update monerod
09:46:35 <nssy> Cool. Thanks
14:08:15 <UkoeHB> afungible[m]: I see, yes that would be an edge case the current wallet code doesn’t handle. My seraphis lib has an input selection algo that can solve that case
14:17:01 <moneromooo> Even with sweep_all and set ignore-fractional-outputs 0 ?
14:18:41 <afungible[m]> <UkoeHB> "afungible: I see, yes that would..." <- Thanks for acknowledging this.
14:19:03 <UkoeHB> well I didn't test it, you should try moneromooo's test case
14:19:26 <UkoeHB> test settings*
14:19:53 <afungible[m]> moneromooo: sweep_all alone, did not work. I will try 'set ignore-fractional-outputs 0', later today & report back.
14:26:05 <selsta> moneromooo: any idea here? since they run their own node it should be possible to get logs https://github.com/monero-project/monero/issues/8478#issuecomment-1203625277
14:46:28 <moneromooo> selsta: looks like "remove wallet cache, let it resync, try again".
14:46:38 <moneromooo> Alternatively, set reorg-max-depth to a lot.
14:47:02 <selsta> they did say they resynced already
14:47:11 <selsta> a couple comments later
14:48:45 <moneromooo> OK. Then... lemme check whether there are interesting logs currently...
14:52:23 <moneromooo> Hmm. 2 million blocks reorg, that's very wrong...
14:53:12 <moneromooo> Ah, 46k in the logs, looks more plausible.
14:53:51 <moneromooo> No interesting logs. If they can run with a log patch, I can make one now I guess.
14:53:58 <moneromooo> I'll comment.
15:18:28 <selsta> moneromooo: these are the only two output distribution changes i remember https://github.com/monero-project/monero/pull/8404/ https://github.com/monero-project/monero/pull/8433/
15:23:45 <moneromooo> The first one looks totally fine. The second one should be fine, unless bug if the daemon I think.
15:24:05 <moneromooo> Which means it's also fine, really.
15:45:38 <selsta> ok let's wait for logs
15:59:25 <dEBRUYNE> Worthwhile to keep an eye on I guess -> https://twitter.com/stephenlacy/status/1554697077430505473
16:08:51 <theoneandonly011> Hello, Ive been trying to prune my blockchain on ubuntu. It was synchronized yesterday and before going to sleep I ran the ./monero-blockchain-prune instance. It ran all night and this morning it still wasnt done? I started it again this morning and I do not have an confirmation on if it is over or not... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e5fc31845ed79996507fb065075f537eba09cd4e)
16:10:26 <theoneandonly011> doesnt make sense.. I read everywhere that the pruned blockchain should be something like 25-30 gigs?
16:11:42 <theoneandonly011> ls -l /home/ubuntu/.bitmonero/lmdb-pruned/data.mdb
16:11:42 <theoneandonly011>  50220294144 (size)  /home/ubuntu/.bitmonero/lmdb-pruned/data.mdb
16:13:05 <selsta> theoneandonly011: "started it again", what do you mean by that? did you kill it?
16:13:37 <selsta> it would be easier to just resync from scratch with --prune-blockchain instead of using the prune tool
16:14:01 <theoneandonly011> Yes it was stuck after 12+ hours.. 
16:14:25 <theoneandonly011> selsta: I get that but I would like to setup a pruned blockchain on my vps without having to have 100 gigs of storage.
16:14:26 <selsta> are you sure it was stuck or just not finished yet? prune tool takes a long tine
16:14:48 <selsta> yes, like I said sync from scratch with --prune-blockchain, you won't need more than 45gb of space
16:14:49 <theoneandonly011> From what I heard, doing what you say will leave your blockchain to 80+ gigs. Just not take more new space
16:15:22 <dEBRUYNE> No it will prune from scratch
16:15:22 <selsta> what you are saying only applies to pruning existing blockchains, not syncing from scratch
16:16:18 <theoneandonly011> Ok got it, so the solution is to delete all my blockchain data and start over with ./monerod --prune-blockchain?
16:16:38 <selsta> correct
16:16:53 <selsta> and use v0.18 for fast sync
16:17:49 <theoneandonly011> Thank you. I will try that instead
17:02:40 <selsta> so we have a version number problem
17:03:47 <selsta> we usually keep the version number on master branch at v0.18.0.0 - but the ledger app has blocked v0.18.0.0 since ledger support only got added in v0.18.1.0, that would mean everyone who uses the master branch can't use a ledger
17:06:13 <selsta> setting the master version to v0.18.9.9 would work for example but seems a bit odd
17:11:24 <theoneandonly011> <selsta> "it would be easier to just..." <- It works, thank you
17:12:53 <ofrnxmr[m]> 52248924160 is the current pruned chain size 
17:15:11 <jberman[m]> <selsta> "setting the master version to v0..." <- v0.18.99.99 to make it a bit more clear it's not a real version number? I think either way there isn't a perfect solution to this, technically v0.18.0.0 is wrong too. I think v0.18.9.9 would be fine also
17:15:19 <ofrnxmr[m]> Could always set the master branch to 0.18.1.0
17:15:48 <jberman[m]> Also thinking we could give stronger indication in the logs that it's on the master branch when it logs the version number
17:16:04 <selsta> ofrnxmr[m]: but the master v0.18.1.0  is different than the release v0.18.1.0 - it would be confusing
17:16:28 <theoneandonly011> ofrnxmr[m]: oh shit that makes sense then, thank you
17:19:40 <ofrnxmr[m]> selsta:  this is same behavior we currently have with v0.18.0.0 master vs v0.18.0.0 release, no?
17:20:21 <ofrnxmr[m]> Perhaps ledger should change it to v0.18.0.1 and we set master to v0.18.0.1
18:22:38 <aremor[m]> Monero gui wallet has localization? I can’t find it in the source
18:23:05 <selsta> what are you searching for exactly?
18:23:34 <selsta> https://github.com/monero-project/monero-gui/tree/master/translations
18:23:39 <aremor[m]> Different language support
18:23:58 <aremor[m]> smh
18:24:11 <aremor[m]> Thanks didn’t see that
18:25:00 <selsta> if you are trying to add / change translations then you have to do it through translate.getmonero.org
18:30:12 <aremor[m]> I see. So roughly 1000 phrases