02:53:14 <hanser[m]> Dear friends, as a beginner, I want to know that in Monero's Source Code if I want to send a tx, whether to call the function "construct_ tx_ with_ tx_ Key()" in `cryptonote_tx_utils.cpp` to generate a tx, and use "Blockchain:: check_tx_Inputs()" in `blockchain.cpp` to check whether the transaction is legal.
02:55:47 <jeffro256[m]> In what context? Are you trying to learn about the core codebase or just trying to build a Monero application? If the latter, you may be better off using a language specific wrapper library like the ones in monero-ecosystem
02:58:12 <hanser[m]> I want to modify the source code of Monroe because it is related to my course project😳
03:01:13 <jeffro256[m]> Yeah you had the general gist. There's a handful of checks besides Blockchain:: check_tx_inputs() to check for transaction validity, but that's where most of it is
03:02:20 <jeffro256[m]> construct_ tx_ with_ tx_ Key is used for creating all the transactions, but there's a lot of work that goes into creating the transactions before calling that function
03:02:38 <jeffro256[m]> Decoy selection and additional pubkey generation, mainly 
03:02:56 <jeffro256[m]> And payment IDs
03:04:06 <hanser[m]> Very Thanks!😀
03:04:27 <jeffro256[m]> If you want the whole shebang from start to finish, I would look at tools::wallet2::create_transactions_2
03:04:53 <jeffro256[m]> Oh and fee estimation 
03:05:11 <jeffro256[m]> Of course!
03:07:00 <hanser[m]> OK, Thank for your great answer!
03:07:00 <hanser[m]> My main change point is about the ring signature verification. I wonder if I can change it to other methods, such as zk-SNARKs...
03:07:39 <jeffro256[m]> Are you in the #monero-research-lounge:monero.social room?
03:07:48 <jeffro256[m]> They talk about things like that all the time
03:08:51 <hanser[m]> Oh I am not in that room.I will go there, very thanks!
05:33:47 <jeffro256[m]> Sorry, not to be pushy, but could we get https://github.com/monero-project/monero/pull/8724 merged sooner rather than later, as long as there are no objections? It's a relatively easier PR to review since it's only removing code, but it has to be rebased every single time there's a change to any RPC call in wallet2
06:56:07 <rbrunner> jeffro256[m] 's proposal to merge #8724 soon gets my support, it makes sense, for the reason mentioned
11:46:28 <monerobull[m]> Whats the current status of multisig?
11:53:06 <ofrnxmr[m]> > greenpillow11: multisig needs security proofs and an audit
11:53:06 <ofrnxmr[m]> Monerobull
12:06:08 <monerobull[m]> I'm guessing rino will look into that?
13:12:37 <plowsof11> after inference had a look : https://community.rino.io/rino-multisig-pr8194-audit-20220627.pdf Rino where satisfied and soon after launched their service on mainnet 
15:25:25 <moneromooo> Rucknium[m]: UkoeHB: you may have an opinion on https://github.com/monero-project/monero/pull/8794 as it touches fake out selection in a slight way.
15:26:07 <moneromooo> Two bits of the code did not consider quite the same range (one ending a block earlier than the other).
15:26:31 <moneromooo> If you prefer using the other bound, it's also a valid fix.
15:36:58 <UkoeHB> moneromooo: what is this 'segregation fork height'?
15:38:58 <moneromooo> A defense against assholes forking monero with its chain intact, leading people to spend pre-fork coins twice on two different chains, causing the ring signatures to be defeated by having two rings with (almost certainly) just one output in common with the same key image
15:39:43 <moneromooo> Well, at the time the party doing this seemed to be an asshole as it was a scam IIRC. May also be done by people who don't know any better.
15:40:01 <moneromooo> It's obsolete now in practice.
15:41:18 <UkoeHB> if obsolete, can it be deleted?
15:41:45 <moneromooo> Probably.
15:42:28 <UkoeHB> ok I see, your solution was to select a proportion of ring members from pre-fork
15:42:47 <jeffro256[m]> <moneromooo> "If you prefer using the other..." <- Which one is the "correct" bound?
15:43:16 <moneromooo> There's not really a correct one I think.
15:44:31 <moneromooo> But I'm not sure. I guess one could try both on an offline chain, not mine, and see what the dameon rejects. If none, it's the larger one.
15:45:26 <moneromooo> In any case, I think the patch does not change the distribution since the generation code is unchanged.
15:47:23 <UkoeHB> the gamma one is probably more right since this line is UB if the default age is 0 rct_offsets[rct_offsets.size() - CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE];
15:52:24 <UkoeHB> however, when selecting outputs to spend and ring members, you can select outputs that are 'current top block - default age - 1' old since they will become spendable in the next block
16:32:26 <jeffro256[m]> Do you mean current top block - default age + 1?
16:32:46 <jeffro256[m]> I mean you can do -1 as well because you can always do older
16:48:31 <UkoeHB> 'current top block - (default age - 1)'  lol
16:48:58 <UkoeHB> or maybe '(current top block + 1) - default age' 
17:12:29 <noloss[m]> "Just get a Glock!" But which one should you buy? We cover our pick of the best Glock models across all calibers and sizes.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/63748a36bf4004a7da83381c71c517059a03c2cb>)
17:36:11 <Rucknium[m]> Thanks for pinging me. I don't know if I will be able to understand the code and its context. The code must make sure that if an output can be selected to be the real spend then it must be eligible as a decoy. If there is any doubt on the two boundaries of the distribution (i.e. most recent spendable output and oldest RCT output) then err on the side of excluding the oldest output(s) as decoys and including the most recent ones.
17:36:12 <Rucknium[m]> jberman could give his opinion too
20:20:14 <serrq[m]> Hey dev team, I am not a developer. I plan to leave Android and switch to Manjaro Plasma Mobile (PinePhone Pro) in the next months.
20:20:14 <serrq[m]> Have you idea about I can manage a Monero wallet in that phone?
20:20:32 <serrq[m]> s/Hey/Hi/
20:35:27 <ceetee[m]> wrong room, use #monero-support:monero.social  for specific software issues or #monero:monero.social