I just heard sethforprivacy say on a podcast that in Monero the recipient knows the true output in a ring signature. I thought that only the sender knows the true output, not the recipient or any external party. Can someone explain?

of course the recipient knows, otherwise how would they know they received money and how much

oh wait, do you mean decoys? No

recipient knows which of the outputs belongs to him

ring signature is used in transaction inputs

I meant output used in ring signature.

Not output of the transaction

it's an input for the recipient

Yes my wording was bad

So recipient does not know which of the 16 is the true spend?

no

No they do not, or no you're wrong?

English is not my first language :D

Recipient doesn't know

Thank you. Crazy that sethforprivacy would say that

Seth has a deeper understanding than ELI5. Im sure he meant that if the origin and the destination are cooperating or the same person, they can deduce the correct spend.

More of a topic for #monero:monero.social

No that's definitely not what was being said

He must've misspoke

When you have a developer saying something crazy I only trust another developer to respond, so I came here

twitter.com/MoneroTalk/status/1633272699756634112 33:40 ofrnxmr

If you want to do something useful contact him and get him to redact his statement, don't tell me what you're "sure" of

Seth isnt a dev, again, wrong room for discussion

Ha, that input - output - input whatever confusion led to the decision to switch to the term *enote* at least for Seraphis for what is so far called *output*

You can then talk about the enotes that serve as inputs for the transactions, and the enotes that the transactions produces as outputs

Or, simply as inputs and outputs, because *output* does not have a double meaning anymore that can confuse

So, your question seems to me to reformulate as: Can the receiver know which of the enotes that were used as input plus decoys is the true spend?

To which I would answer: As far as I know, no

But yeah, as ofrnxmr[m] explained, that's only true if the only data available to check is what's written into the blockchain. If people collude, that's a whole different story.

And a non-dev question :)

How dumb and difficult would be to make a new monerod implementation in Rust using currently available crates?

Would this benefit Monero in any meaningful way?

Besides a learning exercise

veggiemaven[m]1: It would be hard, but some important parts are already available as crates

veggiemaven[m]1: see github.com/SyntheticBird45/cuprate for motivation of why it should be beneficial

Yes this is what I was thinking. Essentially you would need to implement the database and networking stuff afaik

the cryptography is already done as a crate

veggiemaven[m]1: actually nop. Some crypto parts like ringCT are available but needs to be adapted as well

What adaptations does it require?

Implementing crypto is above my paycheck

someoneelse49549: Can someone explain what the benefit of this?

veggiemaven[m]1: switching from Ristretto Curve to another curve

implementing MSLAG and CSLAG on top of it

wait a sec

refering to this repo

shalit[m]: Modularity & security. Modular because if we rewrite it from scratch we can easily make some features easier to rewrite. Secure, because one it's Rust + some decisions & another implementation of the node means a network more resilient to a vulnerability discover on one the nodes

s/rewrite/add/

You forgot the most important aspect. Its fun 😀

someoneelse49549: You can achieve the same security you have in rust with cpp just by knowing cpp...

But the second argument sounds reasonable. Thank you for explaining it

do we need a Rust room to keep -dev clean of this question every other month

plowsof11: lol is this a common occurrence?

> <@shalit:matrix.org> You can achieve the same security you have in rust with cpp just by knowing cpp...

> But the second argument sounds reasonable. Thank you for explaining it

Remind me some hot topic on r/rust. Every cpp developpers say that they can write secure code. Every rust developpers tell it's not possible. Anyway, I would like to tell it's not possible, but I just think this is very hard

plowsof11: there is already #monero-community-dev

veggiemaven[m]1: yes

So should we move the conversation elsewhere?

yes on monero community dev

#monero-community-dev:monero.social thanks

Is monerod storing the txpool_meta_t in the long term just to check for alternative chains or am I missing something?

monerod stores txpool_meta_t in the database. I don't think it's used to check for alternative chains.

In fact, I am sure it is not. The state of the txpool cannot interfere with alternative chain detection.

But it's being used in Blockchain::handle_alternative_block() to check for txpool metadata on this alt-block.

Anyway I still don't understand why we're keeping it stored in the first place

Some of the data can be recovered (like its weight) but it's costly not to cache. Some other data cannot (when it was last relayed).

Where exactly is it used in handle_alternative_block ?

line 2065 : if (m_tx_pool.get_transaction_info(txid, td))

in blockchain.cpp

Ah yes. That's because an alternative blck might refer to txes not in the current chain.

oh so you check the txpool to get that mysterious parent block

s/parent block/txs/

alright make sense to me

Not sure what you're asking exactly, but transactions are in the txpool, not blocks. But since blocks are made of txes... kinda ?

yeah i just want to understand why we can't just keep txpool in memory and handle alternative blocks based on the alt_blk we stored in the db (alt_blocks table). So iirc we can't because new alt-block can reference txs that are not in these previous alt_blocks but maybe in the txpool. Sry I'm confused it's not really explained in zero to monero

We can keep it in memory. It used to.

So the txpool_meta & txpool_blob tables are useless?

No...

o

Those things have to be stored *somewhere*.

so these tables. They don't store _EVERY_ state of the txpool from the beginning right?

They store only the current state.

omg IT'S SO MUCH CLEAR

thx moneromoo

<someoneelse49549> "What's the purpose of txpool_tx_..." <- . was stuck on this

Sorry for the spam

dangerousfreedom @dangerousfreedom:matrix.org: let's maybe start a new chat unencrypted, or verify your session on your desktop session lol

If someone makes a custom Monero wallet that sends fees at a rate lower than the unimportant rate of the cli wallet, will the network reject such a tx?

yes

unimportant rate is lowest possible for adding a tx to mempool

there is a 5% leeway in monerod code, but using it will make transactions stand out

but it's technically allowed to mine transactions with any fee, even zero fee

they will just not propagate

<sech1> "they will just not propagate" <- So if a custom wallet uses your monerod to broadcast a tx with zero fee it won't get rejected?

other nodes will not accept it. You can mine it solo, but it will not propagate

and it will require custom monerod

<sech1> "other nodes will not accept it..." <- Other nodes won't but if the tx is submitted to your normal unmodified monerod then it will?

<sech1> "and it will require custom..." <- OK got it.

custom monerod with fee limit turned off and custom wallet to create zero fee transactions

even if you submit tx via RPC, fee limit is checked before adding it to your node's mempool