the monero community has become obsessed with creating useless CCS/funding proposals ultimately useless shit like another guide (made from someone just copying another guide)

devs like moneromoo who have put thousands of hours into actually coding monero receive nothing while thousands is thrown at useless proposals

devs should just quit or demand a salary.. this situation is so fucking stupid

Wrong channel -> #monero-beef

#monero-beef:monero.social

no this is the correct channel

<qpqp[m]> "devs like moneromoo who have put..." <- Moneromooo is funded via CCSs lol...

Poor example

qpqp: are you a dev? I am betting not...

And AFAIK no Dev requesting funding has failed to raise it.

here is a not even complete list of current ccs (translators not added yet) monerodevs.org/ccs.html

If a dev sees a need, can fill it, and can make that need clear to the community, I have no doubt they will get funded.

But anyways, this is the very wrong channel for this.

Please use #monero-community:monero.social for CCS/funding discussions, qpqp

Hello i have a technical question

I would like to know how to avoid feeling guilty knowing that Monero is being used by pedos and drug dealers

I have nightmares about it

I tried to talk to the priest but he is not well versed in technology

So he didn t understand

Instead of exporting wallet's outputs to the offline wallet and let it sign, I want to keep track of utxos myself. In the above image, the keyImages are not coming from the offline wallet, but from what I keep in my database. How do I find the keyImages and its signatures from the blockchain that belong to my utxos?

moneromooo: could you take a look at the monero github issue tracker? someone posted some fuzzing related things

Thanks.

hyc: could you look at monero-project/monero #8121 and see if I'm missing something ? If ubsan is moaning, it's probably more right than me...

ok

your response looks correct to me. unsigned integer overflow is well defined behavior, not undefined. ubsan is wrong.

OK. Let's see what the reply is then. Thanks.

your question about size_t doesn't really matter. yes, size_t must always be unsigned. and ubsan clearly knows that it was typedef'd to unsigned long, so that's not even a question.

Yes, I thought maybe it's not strictly mandated, like some obscure compilers default char to unsigned.

yeah. sizes cannot be negative...

Sizes must be representable in size_t, but nothing says all size_t values must be valid sizes :)

lol but you can't have it both ways

e.g. on a 32bit machine, if you allowed negative values, size_t would be unable to represent all sizes.

In theory, signed int128_t could do that.

anything larger than 2^31 would not be representable

It'd be a shit choice, mind...

heh

they also opened 2 other issues (in case you didn't see them)

Oh. Sorry :D

good afternoon. I am new here, just to read, at the begin, and to learn, to become an active developer. I am a software developer since 40 years

Hi.

You may want to idle in #monero-research-lab as well.

moneromoooo thanks

Monero code related questions are welcome here if you need help finding what's where in monero.

moneromoooo thanks. I want to download all the updated source code and, possibly, updated documentation for developer. If i can get all of that with few (git) commands that would be great

git clone github.com/monero-project/monero

I am using ubuntu. I am italian mother language, but I am used to study documentation, currently, in English

and read getmonero.org/library/Zero-to-Monero-2-0-0.pdf for some technical details

thanks. I start immediately

also getmonero.org/resources/developer-guides

thanks again. I arrived the last linked page. I was not sure it was enough. I think I have a more complete view of what I need to efficiently start

That last link is probably a bit out of date, at least for RPC docs.

stilettophiccant: I'm Italian too. Please reach me out if you need any help

<jetsteel[m]> "will.yijinin: And when the..." <- What I am trying to do is, instead of “view-only wallet exports outputs hex to Offline Wallet and then offline wallet exports keyImages back to online view wallet”, I export keyImages to the view-only wallet myself. How can I find my wallet’s utxos’ keyImages and signatures on the blockchain? Is it theoretically possible? Must I sign the outputs hex with offline wallet to get

keyImages?

For spent outputs or unspent outputs ?

It'd only be of use for unspent ones, and those will not be on the chain yet.

Spending an output involves placing that key image and a signature on the chain.

And those two things require knowng the spend secret key.

moneromooo: In the code base I’ve found where the view wallet creates the unsignedTx. I’ve checked Monero/wallet/wallet2.cpp. It seems when `create_transaction_2`, the code fetches unspent outputs. Do the unspent outputs here contain information about the keyImages that offline exports to the view-only wallet?

Yes (assuming it's either on the cold wallet, or on the hot wallet which has imported key images already). Otherwise no.

The view-only wallet creates an unsigned tx from a utxo. Can I not provide keyImages? moneromooo

"Can I not provide keyImages?" is not clear enough. If you're asking "can the view wallet calculate them without help", then no.

moneromooo: If I need to provide keyImages, can I not get it from the offline wallet? Say, I keep track of all the tx hashes, and I scan the block to match keyImages to the txhashes. I know which ones are spent and unspent, so I provide what I remember as KeyImages and signatures to the view wallet, instead of letting offline wallet sign the output hexes.

You can get them from the offline wallet.

* remember as unspents - their KeyImages and

To spend, you'll need ring signatures too. The key image wold not be enough.

Additionally, you seem to be mixing two things (or I am). If you scan blocks to find key images, these are now spent, and public.

You then do not need to ask the cold wallet for them.

moneromooo: So in the above image, the view wallet first scan the blockchain for unspent output hex without keyImages?

The view wallet (which has the secret view key) scans for incoming outputs (unspent yet obviously), and remembers them. It cannot calculate their key image without the secret spend key.

Then it can export those outputs to the cold wallet, which can calculate those key images, and import those key images back.

moneromooo: Is there a method which provide the 10 decoys to the view-only wallet? This would make the whole signing offline process one round. Basically make an offline-view-only wallet. Offline-signing wallet export keyImages to offline-view wallet. offline-view wallet computes the unsignedTx with 10 decoys and keyImages and export unsignedTx to offline-signing wallet. It signs and finally export the tx to an online view wallet to

broadcast it.

The view wallet can select those fake outputs without help.

Well, it asks the daemon via RPC, but it has "live" access to it.

moneromooo: Yes. Currently the process will request offline wallet twice. We were trying to request the offline wallet once. That basically requires wrapping up the four steps offline. Provide output hex and 10 decoys from outside the sdk and the sdk returns a signed tx without making any rpc requests. This assumes the output hex are unspent so the view-only wallet inside the sdk don't need to check if the keyImages are double spent.

Is this possible with the current framework?

IIRC, if you have outputs which the view wallet did not get key images for yet, it'll piggy back on the transaction back and forth to include the output/key images back and forth, so it's one back and forth instead of 2.

For "without making any rpc requests", do you mean dameon RPC requests ? If so, this is needed because the wallet does not have a cache of hte whole chain to get fake out pubkeys.

People have previously floated the idea of the wallet remember a subset of these for later use though.

So I'll assume "Provide output hex and 10 decoys" means that RPC was already done, and so does not count ?

Anyway, in theory, what you say seems possible.

I can't quite recall how the piggybacking works.

moneromooo: yes. A online view-only wallet scans the blockchain for unspent output hex and 10 decoys. Then it provides them to the sdk. In the sdk are the four steps above in the image, except the offline view-only wallet does not check online that the keyImages imported from offline wallet are spent or not. It assumes the output hex are unspent and export the unsigned tx to the offline wallet.

Did you try to sent monero without output/key image export/import, just with the signing back and forth ? It might work, given the piggyback system.

In theory, it should :)

moneromooo: No. The whole process will be: an online view-only wallet scans the blockchain for 10 decoys. Our server remembers our utxos and provide the output hex. Then we export the params to the sdk. Inside the sdk, an offline signing wallet will sign the output hex and export them to an offline-view-only wallet. It calculates the unsigned tx with the keyImages and 10 decoys. But it assumes the keyImages are unspent and do not

request online to check which are spent or unspent. The rest is the same. At last the sdk export the signed tx to an online view-only wallet which broadcast it.

will.yijinin: We were just talking about these issues in #monero-research-lab:matrix.org . You should let us know if any of these address schemes could make your life easier as a merchant/user:

Rucknium: fwiw I'd love to see a view tag inplementes. So, either Plain D or Janus E. Many casual users are going to find light wallets to be the most convenient. We should add more privacy when requesting data from a server via view tag.

Rucknium: while privacy enthusiasts will be running their own daemon, on a privacy linux distro, using tor, and an offline wallet. Most people are going to want to download an app and have it working in less than a minute. I think that makes view tags a must.