-
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.
-
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
-
hanser[m]
I want to modify the source code of Monroe because it is related to my course project😳
-
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
-
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
-
jeffro256[m]
Decoy selection and additional pubkey generation, mainly
-
jeffro256[m]
And payment IDs
-
hanser[m]
Very Thanks!😀
-
jeffro256[m]
If you want the whole shebang from start to finish, I would look at tools::wallet2::create_transactions_2
-
jeffro256[m]
Oh and fee estimation
-
jeffro256[m]
Of course!
-
hanser[m]
OK, Thank for your great answer!
-
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...
-
jeffro256[m]
Are you in the #monero-research-lounge:monero.social room?
-
jeffro256[m]
They talk about things like that all the time
-
hanser[m]
Oh I am not in that room.I will go there, very thanks!
-
jeffro256[m]
Sorry, not to be pushy, but could we get
monero-project/monero #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
-
rbrunner
jeffro256[m] 's proposal to merge #8724 soon gets my support, it makes sense, for the reason mentioned
-
monerobull[m]
Whats the current status of multisig?
-
ofrnxmr[m]
> greenpillow11: multisig needs security proofs and an audit
-
ofrnxmr[m]
Monerobull
-
monerobull[m]
I'm guessing rino will look into that?
-
plowsof11
after inference had a look :
community.rino.io/rino-multisig-pr8194-audit-20220627.pdf Rino where satisfied and soon after launched their service on mainnet
-
moneromooo
Rucknium[m]: UkoeHB: you may have an opinion on
monero-project/monero #8794 as it touches fake out selection in a slight way.
-
moneromooo
Two bits of the code did not consider quite the same range (one ending a block earlier than the other).
-
moneromooo
If you prefer using the other bound, it's also a valid fix.
-
UkoeHB
moneromooo: what is this 'segregation fork height'?
-
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
-
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.
-
moneromooo
It's obsolete now in practice.
-
UkoeHB
if obsolete, can it be deleted?
-
moneromooo
Probably.
-
UkoeHB
ok I see, your solution was to select a proportion of ring members from pre-fork
-
jeffro256[m]
<moneromooo> "If you prefer using the other..." <- Which one is the "correct" bound?
-
moneromooo
There's not really a correct one I think.
-
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.
-
moneromooo
In any case, I think the patch does not change the distribution since the generation code is unchanged.
-
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];
-
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
-
jeffro256[m]
Do you mean current top block - default age + 1?
-
jeffro256[m]
I mean you can do -1 as well because you can always do older
-
UkoeHB
'current top block - (default age - 1)' lol
-
UkoeHB
or maybe '(current top block + 1) - default age'
-
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 <
libera.ems.host/_matrix/media/v3/do…a36bf4004a7da83381c71c517059a03c2cb>)
-
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.
-
Rucknium[m]
jberman could give his opinion too
-
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.
-
serrq[m]
Have you idea about I can manage a Monero wallet in that phone?
-
serrq[m]
s/Hey/Hi/
-
ceetee[m]
wrong room, use #monero-support:monero.social for specific software issues or #monero:monero.social