08:20:57 <triplezzz[m]> 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? 
08:22:39 <sech1> of course the recipient knows, otherwise how would they know they received money and how much
08:23:15 <sech1> oh wait, do you mean decoys? No
08:23:27 <sech1> recipient knows which of the outputs belongs to him
08:23:41 <sech1> ring signature is used in transaction inputs
08:24:14 <triplezzz[m]> I meant output used in ring signature.
08:24:15 <triplezzz[m]> Not output of the transaction
08:24:28 <sech1> it's an input for the recipient
08:24:56 <triplezzz[m]> Yes my wording was bad
08:25:02 <triplezzz[m]> So recipient does not know which of the 16 is the true spend?
08:25:07 <sech1> no
08:25:40 <triplezzz[m]> No they do not, or no you're wrong?
08:25:53 <sech1> English is not my first language :D
08:25:57 <sech1> Recipient doesn't know
08:26:32 <triplezzz[m]> Thank you. Crazy that sethforprivacy would say that
08:28:55 <ofrnxmr[m]> 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.
08:28:55 <ofrnxmr[m]> More of a topic for #monero:monero.social 
08:29:39 <triplezzz[m]> No that's definitely not what was being said
08:29:40 <triplezzz[m]> He must've misspoke 
08:30:15 <triplezzz[m]> When you have a developer saying something crazy I only trust another developer to respond, so I came here
08:59:55 <triplezzz[m]> https://twitter.com/MoneroTalk/status/1633272699756634112 33:40 ofrnxmr 
09:00:17 <triplezzz[m]> 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
09:03:38 <ofrnxmr[m]> Seth isnt a dev, again,  wrong room for discussion 
09:54:41 <rbrunner> 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*
09:55:21 <rbrunner> You can then talk about the enotes that serve as inputs for the transactions, and the enotes that the transactions produces as outputs
09:55:57 <rbrunner> Or, simply as inputs and outputs, because *output* does not have a double meaning anymore that can confuse
09:57:29 <rbrunner> 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?
09:57:44 <rbrunner> To which I would answer: As far as I know, no
10:01:57 <rbrunner> 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.
10:02:10 <rbrunner> And a non-dev question :)
12:36:01 <veggiemaven[m]1> How dumb and difficult would be to make a new monerod implementation in Rust using currently available crates? 
12:36:18 <veggiemaven[m]1> Would this benefit Monero in any meaningful way?
12:36:25 <veggiemaven[m]1> Besides a learning exercise
12:37:02 <someoneelse49549> veggiemaven[m]1: It would be hard, but some important parts are already available as crates
12:37:07 <someoneelse49549> veggiemaven[m]1: see https://github.com/SyntheticBird45/cuprate for motivation of why it should be beneficial
12:37:38 <veggiemaven[m]1> Yes this is what I was thinking. Essentially you would need to implement the database and networking stuff afaik
12:37:39 <veggiemaven[m]1> the cryptography is already done as a crate 
12:37:47 <someoneelse49549> veggiemaven[m]1: actually nop. Some crypto parts like ringCT are available but needs to be adapted as well
12:38:22 <veggiemaven[m]1> What adaptations does it require?
12:38:29 <veggiemaven[m]1> Implementing crypto is above my paycheck
12:38:41 <shalit[m]> someoneelse49549: Can someone explain what the benefit of this?
12:38:48 <someoneelse49549> veggiemaven[m]1: switching from Ristretto Curve to another curve
12:39:15 <someoneelse49549> implementing  MSLAG and CSLAG on top of it
12:39:16 <someoneelse49549> wait a sec
12:39:24 <someoneelse49549> https://github.com/expiredhotdog/RingCT
12:39:25 <someoneelse49549> refering to this repo
12:40:59 <someoneelse49549> 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
12:41:31 <someoneelse49549> s/rewrite/add/
12:41:54 <veggiemaven[m]1> You forgot the most important aspect. Its fun 😀
12:41:55 <shalit[m]> someoneelse49549: You can achieve the same security you have in rust with cpp just by knowing cpp...
12:41:55 <shalit[m]> But the second argument sounds reasonable. Thank you for explaining it
12:42:10 <plowsof11> do we need a Rust room to keep -dev clean of this question every other month 
12:42:31 <veggiemaven[m]1> plowsof11: lol is this a common occurrence?
12:43:25 <someoneelse49549> > <@shalit:matrix.org> You can achieve the same security you have in rust with cpp just by knowing cpp...
12:43:25 <someoneelse49549> > But the second argument sounds reasonable. Thank you for explaining it
12:43:25 <someoneelse49549> 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
12:43:44 <someoneelse49549> plowsof11: there is already #monero-community-dev
12:43:45 <someoneelse49549> veggiemaven[m]1: yes
12:44:43 <veggiemaven[m]1> So should we move the conversation elsewhere? 
12:45:06 <someoneelse49549> yes on monero community dev
12:51:38 <plowsof11> #monero-community-dev:monero.social thanks
14:10:42 <someoneelse49549> Is monerod storing the txpool_meta_t in the long term just to check for alternative chains or am I missing something?
14:21:31 <moneromooo> monerod stores txpool_meta_t in the database. I don't think it's used to check for alternative chains.
14:22:29 <moneromooo> In fact, I am sure it is not. The state of the txpool cannot interfere with alternative chain detection.
14:29:15 <someoneelse49549> But it's being used in Blockchain::handle_alternative_block() to check for txpool metadata on this alt-block.
14:29:55 <someoneelse49549> Anyway I still don't understand why we're keeping it stored in the first place
14:32:12 <moneromooo> 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).
14:32:51 <moneromooo> Where exactly is it used in handle_alternative_block ?
14:33:41 <someoneelse49549> line 2065 : if (m_tx_pool.get_transaction_info(txid, td))
14:34:02 <someoneelse49549> in blockchain.cpp
14:35:04 <moneromooo> Ah yes. That's because an alternative blck might refer to txes not in the current chain.
14:36:10 <someoneelse49549> oh so you check the txpool to get that mysterious parent block
14:37:01 <someoneelse49549> s/parent block/txs/
14:37:02 <someoneelse49549> alright make sense to me
14:38:16 <moneromooo> Not sure what you're asking exactly, but transactions are in the txpool, not blocks. But since blocks are made of txes... kinda ?
14:42:54 <someoneelse49549> 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
14:43:31 <moneromooo> We can keep it in memory. It used to.
14:44:18 <someoneelse49549> So the txpool_meta & txpool_blob tables are useless?
14:44:31 <moneromooo> No...
14:44:46 <someoneelse49549> o
14:44:49 <moneromooo> Those things have to be stored *somewhere*.
14:45:52 <someoneelse49549> so these tables. They don't store _EVERY_ state of the txpool from the beginning right?
14:46:12 <moneromooo> They store only the current state.
14:46:25 <someoneelse49549> omg IT'S SO MUCH CLEAR
14:46:51 <someoneelse49549> thx moneromoo
14:50:51 <someoneelse49549> <someoneelse49549> "What's the purpose of txpool_tx_..." <- . was stuck on this
18:33:37 <ghostway[m]> Sorry for the spam
18:33:37 <ghostway[m]> dangerousfreedom @dangerousfreedom:matrix.org: let's maybe start a new chat unencrypted, or verify your session on your desktop session lol
20:50:43 <Alex|LocalMonero> 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?
20:52:43 <sech1> yes
20:52:58 <sech1> unimportant rate is lowest possible for adding a tx to mempool
20:53:51 <sech1> there is a 5% leeway in monerod code, but using it will make transactions stand out
20:54:29 <sech1> but it's technically allowed to mine transactions with any fee, even zero fee
20:54:37 <sech1> they will just not propagate
21:06:00 <Alex|LocalMonero> <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?
21:07:24 <sech1> other nodes will not accept it. You can mine it solo, but it will not propagate
21:07:33 <sech1> and it will require custom monerod
21:12:58 <Alex|LocalMonero> <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?
21:13:23 <Alex|LocalMonero> <sech1> "and it will require custom..." <- OK got it.
21:15:24 <sech1> custom monerod with fee limit turned off and custom wallet to create zero fee transactions
21:15:43 <sech1> even if you submit tx via RPC, fee limit is checked before adding it to your node's mempool