01:31:08 <politicalweasel[> Unfortunately the meetings are at a bad time for me so I wasn't/won't be able to participate, but this is my humble opinion on why B(3) > A.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6f9f4aea021a5b1d6c99c9a0e284ae7806aceb15>)
01:44:14 <UkoeHB> tevador: I forgot to mention earlier, the biggest benefit of change memos is cross-wallet record consistency. Seraphis has nice view-only wallets, but those wallets will be blind to anything done by the corresponding full wallet.
01:51:14 <UkoeHB> for example, you could record the destination address of the other recipient in a 2-out
01:51:55 <UkoeHB> or a root entropy for the enote ephemeral privkeys
03:47:46 <kgsphinx[m]> I concur.
04:04:59 <kgsphinx[m]> It's like you're reading my mind.
04:05:23 <UkoeHB> who are you talking to?
04:06:22 <kgsphinx[m]> Oh hey, that was a threaded reply to politicalweasel.. maybe your client didn't understand that.  It says it's a beta feature.  Sorry if it's confusing.
04:07:57 <UkoeHB> Please don't do any fancy matrix stuff in bridged channels (threads, edits, etc), it doesn't translate to irc.
04:08:11 <kgsphinx[m]> sure thing
04:08:31 <UkoeHB> thanks
09:11:01 <ErCiccione> I don't see a way to disable threads in the room sadly
11:24:04 <gingeropolous> to me, it seems the most valid argument for B3 is enabling the protocol to be adaptable without a hardfork. I understand the appeal of the memo / messaging aspects, but they seem unnecessary for a value transfer protocol. To borrow the meme, "monero means money.... and memos apparently"
11:25:44 <gingeropolous> now, my freshly caffeinated head might be too "blue sky", but I feel there's gotta be another way around the tx flexibility that doesn't involve permanent memos in each tx. 
11:26:08 <gingeropolous> I think in all of this, option A keeps on missing its little tagline of "coinbase txs still get to have fun"
11:26:26 <gingeropolous> or whatever we call the special sauce that miners get to put into blocks
11:26:40 <sech1> coinbase tx are special, they don't use ring sigs as well
11:28:39 <gingeropolous> so, say in a hard option A environment: would it be possible to modify the relay rules (via a non-hardfork release), such that nodes can relay payloads (tied to the tx, somehow), and then the new tx-rules in those payloads get stuffed into the block header.
11:28:47 <gingeropolous> or coinbase_tx. whatever.
11:33:04 <gingeropolous> this would keep the txs all uniform on chain. the only non-uniformity would exist on the wire. and even if this soft fork scenario required all txs include a payload, they just end up stuffed in the header
11:33:21 <sech1> oh, that's just evil
11:33:35 <sech1> so you want pools to mine tx_extra for each tx into coinbase?
11:34:11 <gingeropolous> maybe?
11:35:01 <sech1> coinbase tx_extra can be limited to 256 bytes, miners don't need a lot
11:39:22 <moneromooo> Merge mining N chains needs something like log(N) * 32 bytes (plus framing). 1 chain->32, 2 chains->64, 4 chains->96. I think.
11:40:59 <gingeropolous> i forget where I read this, but I remember as some point a discussion of why payment_IDs exist. Basically, the gist of the story was this - if you consider the cryptonote protocol, all of its design decisions make sense regarding tx privacy except for payment_IDs. The lore (again, I forget where it came from), is that the protocol was so good at doing its job (being private money), that when the original designers went and had to 
11:41:00 <gingeropolous> integrate into exchanges (or think about being on exchanges), they realized the protocol was so good that they had no way for an exchange to determine whether an output belonged to a particular user. That a user had sent a particular output. Thus, paymend IDs, in stupid cleartext nonsense, were bolted on. 
11:43:24 <gingeropolous> of course, in retrospect, the original cryptonote allowed ringsize = 1 (mixin 0), so who knows what user those dusty memories serve
11:43:58 <gingeropolous> user = utility . s/user/utility/l33t_sed_syntax
11:46:31 <gingeropolous> thus, to me tx_extra always feels like a bolt_on meant to try and make monero (a square peg) fit into a round hole (the current exchange ecosystem, which isn't a p2p ecosystem, but is almost the definition of client-server afaiu, or whatever is the anti-p2p)
11:55:33 <gingeropolous> and I also would opine that soft-fork-ability is a ...... thing that results from bitcoin's ceding of their consensus generation to industry. The bitcoin system has to believe that soft forks are the way forward because they no longer own the consensus mechanism. I personally feel that if you aren't generating blocks, then you're not participating in consensus. Bitcoin's system has gone sideways to that notion. Anyway. Long story short, 
11:55:33 <gingeropolous> I think the real question here is soft-forkability. And I don't think thats an issue because we own our consensus power.
13:47:23 <Alex|LocalMonero> To be fair gingeropolous , payment differentiation is something that literally every merchant needs, not just exchanges.
13:47:30 <Alex|LocalMonero> Heck, private individuals need to differentiate their payments as well.
13:49:55 <moneromooo> CN or bytecoin had this nice idea of having different spend keys with the same view key. That was a nifty use of the double key system.
13:50:15 <gingeropolous> yeah but it doesn't need to be on chain. I don't write a note on the cash in my wallet regarding where it came from.
13:50:18 <moneromooo> I think they worked it out fairly late though.
13:54:44 <gingeropolous> regardless, i could see a monero where option B3 exists, but its baked into the system in such a way that it can be turned on or off. I.e., we pick a default, but there also exist a flag --enable_tx_extra , so that if we decide we don't think its a good idea now, it could be re-enabled. man i talk in circles. have your cake and eat it too!
15:10:26 <M7in[m]> would there be any problems with doing b3 but storing it in the block?
15:11:33 <M7in[m]> other than the node knowing its from your tx
15:11:44 <sech1> all nodes will know
19:24:42 <rbrunner> What do you think about the following proposal:
19:24:48 <rbrunner> In preparation of and as support for further tx_extra discussion we create a new GitHub issue
19:24:53 <rbrunner> The idea is it to be a strictly single-purpose issue: "State your stance on the tx_extra removal question"
19:24:59 <rbrunner> For example preferred solution plus the two or three most important personal arguments, in *brief*
19:25:05 <rbrunner> So it's *not* a vote, and nobody should understand or abuse it as such
19:25:11 <rbrunner> So it's *not* yet another tx_extra discussion issue, people should refrain from discussing there
19:25:16 <rbrunner> Its goals are to get a better overview, and more transparency, over where the dev community currently stands
19:25:23 <rbrunner> Collecting info that is currently strewn over various places, not readily accessible
19:25:30 <rbrunner> Of course, while decidedly not being a vote, it would still allow to better gauge current sentiment
19:37:00 <Alex|LocalMonero> I think the sentiment was made clear in the first meeting, which had the most traction, that the most acceptable solution is the removal of tx_extra.
19:38:10 <Alex|LocalMonero> People who want to keep tx_extra get more talk in because there's a lot more to discuss about how to keep tx_extra, whereas the people who are against tx_extra don't have that much to discuss among each other.
19:38:21 <UkoeHB> there was no conclusive consensus in the first meeting
19:38:45 <Alex|LocalMonero> UkoeHB: Yes there was, the "remove tx_extra" had the clear majority.
19:39:16 <Alex|LocalMonero> Anyone could pick however many options they wanted and "remove" was picked by the most people.
19:39:31 <Alex|LocalMonero> This discussion is prolonged mostly by people who want to keep it in some form.
19:42:04 <rbrunner> You should be for this issue then. What's there to fear? That clear sentiment from the first best-traction meeting would just get clearer, no?
19:45:08 <Alex|LocalMonero> 1. I didn't speak against the issue, I was merely stating that it was already clear which option the most people find acceptable
19:45:08 <Alex|LocalMonero> 2. The sentiment might not necessarily be the same if the traction is not the same. The people who are pro-removal have already spoken out and saw that they are in the majority, while those who are against are in the minority and keep talking and prolonging this issue, so its in their interests to keep voting and discussing it until the pro-removals all get tired of arguing the same points over again.
19:47:22 <Alex|LocalMonero> So, as it stands, its in the interests only of the anti-removal camp to keep discussing this issue ad nauseam.
19:47:47 <UkoeHB> Alex|LocalMonero: there is more than enough weight behind keeping the field to continue discussing it.
19:48:07 <Alex|LocalMonero> And how much weight is enough weight?
19:48:24 <Alex|LocalMonero> Are we looking for a unanimous decision? That's not going to happen.
19:48:25 <UkoeHB> I don't know, but we certainly have more than that
19:48:43 <Alex|LocalMonero> What's your test for "enough" or "not enough"?
19:49:31 <UkoeHB> I won't quibble with you
19:49:54 <Alex|LocalMonero> This is not a quibble, I'm asking for your measure.
19:50:34 <Alex|LocalMonero> What level of consensus do you consider as being "winning" the issue? 80%?
19:51:08 <rbrunner> Well, this proposal is my honest attempt to not prolong the discussion ad nauseam, but to help to finally bring it to a close.
19:51:32 <rbrunner> We are on opposite sides of the opinion spectrum, but share the sentiment that this *has* to come to an end
19:51:57 <Alex|LocalMonero> No sure I'm all for the issue, I'm honestly prepared to discuss this ad nauseam if I have to.
19:52:14 <Alex|LocalMonero> I feel that Monero's design principles are being threatened and I plan to defend them as long as I can.
19:53:09 <rbrunner> For some people it's a transaction construction detail, for other people it's a frontal attack on core design principles :)
19:59:13 <Alex|LocalMonero> Catering to arbitrary data injection onto the chain is absolutely a redefinition of Monero's design principles. All the arguments stating that "we're just trying to help well-intentioned devs not to have to increase the network scan time by 0.1% with stegging", are ignoring that if someone is actually malicious and they want to harm global scan time they will do it with or without tx_extra.
20:00:57 <Alex|LocalMonero> Heck, we had plenty of consensus around tx_extra removal prior to the recent flare up of this discussion. Why wasn't the decision made back then?
20:02:02 <Alex|LocalMonero> There's a post on getmonero.org from over 2 years ago explicitly telling devs don't use tx_extra, we're gonna remove it
20:07:31 <rbrunner> And how does this all help to bring this to an acceptable close that people can compromise on?
20:09:09 <Alex|LocalMonero> There shouldn't be any compromise with arbitrary data injectors, just like there shouldn't be any compromises with any other people who come to Monero from other projects having other ideas that are counter to Monero's principles and what led to Monero having a following that other projects don't have.
20:11:14 <rbrunner> Yeah, we should all be nice to each other, listen to reason, and all. Ah, and not compromise of course. That will surely help. I guess I only get what I deserve for my attempt to move things a tiny bit forward.
20:11:47 <Alex|LocalMonero> We are nice to each other, aren't we?
20:11:59 <rbrunner> Extremely :)
20:12:23 <rbrunner> Just some progress is lacking, if you ask me.
20:12:24 <Alex|LocalMonero> No but seriously I'm for your attempt, post the issue.
20:14:06 <Alex|LocalMonero> I agree, this issue needs to be done with cuz it's hurting other issues.
20:14:18 <Alex|LocalMonero> There's plenty of important other things to discuss.
20:14:42 <Alex|LocalMonero> I've said it once and I'll say it again, the core team should just make a collective decision on this.
20:17:51 <Alex|LocalMonero> UkoeHB: seems to be willing to continue rescheduling this over and over at the detriment of other issues that need discussion until he gets a feeling of consensus, which I'm sure will not happen because there's a fundamental difference in how people treat the very notion of arbitrary data injection into the chain, and those differences seem irreconcilable.
20:32:21 <UkoeHB> is there something else to discuss?
20:33:53 <Alex|LocalMonero> Yes, there are further bullet points in the MRL topics as listed on the issue: https://github.com/monero-project/meta/issues/803
20:34:19 <UkoeHB> those have been there for over a year
20:34:51 <rbrunner> You really fight like a lion, have to give you that. If only the goals would align a bit better ...
20:36:13 <Alex|LocalMonero> UkoeHB: Fair enough. I know you're tired too.
20:38:49 <rbrunner> I am also thinking ahead. I am pretty sure that for Seraphis we have a number of difficult decisions of all sorts waiting. Would be bad if we would have multiple reruns of this type of discussion.
20:40:09 <rbrunner> 2 years of quibbling over important Seraphis decisions, after it would basically be ready, how does that prospect sound?
20:40:34 <rbrunner> *That* worries me a lot more than this silly tx_extra question.
20:41:47 <Alex|LocalMonero> Do you have any particular difficult decision examples?
20:42:51 <rbrunner> Yes. For example that Seraphis makes third-party scanning services much easier. A big chance, and a big potential controversy as well: Should we go all in there, or de-emphasize, or even backtrack and delete the key making this possible?
20:44:14 <Alex|LocalMonero> Do you mean the fact that the view key will allow to see both incoming and outgoing txs?
20:44:34 <rbrunner> Or more technical ones: I am sure people, at some time, will shout bloody murder that `wallet2` will go away.
20:46:25 <rbrunner> Yes to the viewkey question
20:47:23 <rbrunner> Or maybe already that "switch the curve" question, let's see how our decision process will fare with that ...
20:50:25 <tevador> MRL #100 should be added to the meeting agenda, so we can make some progress there.
20:51:12 <Alex|LocalMonero> If I'm being honest, neither of those three issues seem to be as fundamentally contentious as this one. Monero always had the principle of privacy by default but the possibility of voluntary privacy abdication, so the view key is being more functional is just an extension of that.
20:55:59 <Rucknium[m]> tevador: I will add it to the agenda for next meeting. Or someone else can take on agenda-posting duties if they want. 
21:09:21 <UkoeHB> rbrunner: one goal of jamtis is to enable maximally private third-party scanning with the find-received tier. We should spend exactly zero resources on supporting remote scanning that uses anything else.
21:14:45 <tevador> "For example that Seraphis makes third-party scanning services much easier." This statement is not true. It doesn't make them any easier, it just reduces the severity of the resulting privacy loss. I don't see how this could be controversial.
21:15:10 <UkoeHB> tevador: he means to use the view-balance key for remote scanning I think
21:16:20 <tevador> In practice, there is very little difference between the cryptonote view key and the seraphis view balance key.
21:17:29 <rbrunner> I see that I shortened too much. We improve third-party scan possibilities with Jamtis and Seraphis, right? We make them better.
21:17:46 <rbrunner> There are people who think this goes into the wrong direction.
21:18:17 <rbrunner> I saw them on Reddit when news broke that there are new, better third-party scan mechanisms
21:18:43 <rbrunner> Your own daemon for fullest privacy, no compromises.
21:19:07 <rbrunner> No key whatsoever to third parties, even severly restricted ones.
21:19:23 <rbrunner> See how I mean that position?
21:20:38 <tevador> Having a separate find-received key reduces security risks even if you don't shared the key with anyone.
21:21:24 <rbrunner> Some people argue that the key should not exist in the first place.
21:21:38 <rbrunner> You can't share what doesn't exist, right?
21:22:07 <rbrunner> I don't argue pro this position, I just try to get accross that there could be contention.
21:22:15 <rbrunner> That again may strain our decision processes.
21:22:19 <tevador> You can technicallt make a wallet that has k_fr = k_vb if you wish to do so.
21:24:11 <tevador> I guess there are people that would oppose any change whatsoever.
21:25:07 <rbrunner> Yes. Bigger project = more people = more people with extreme positions one way or another = more strain on the decision process
21:32:29 <rbrunner> Have to go. Does not exactly look good for my "State your stance" issue proposal so far, only 1 pro statement until now. Will check the backlog in 8 hours.
21:33:00 <hbs[m]> <Alex|LocalMonero> "If I'm being honest, neither..." <- maybe there is a need for a different explanation of the rationale behind the new view key. What I have seen is an explanation stating that the same info is heuristically already obtainable so that it doesn't change much. But there is a big difference between something that is only statistically possible and something that is certain, and that may worry some. So definitely the
21:33:00 <hbs[m]> question of the new view key will be raised at some point, and will be controversial.
21:34:05 <Alex|LocalMonero> Honestly, I've always seen the inability of the view key to show one the proper balance of the wallet as a design flaw.
21:34:54 <Alex|LocalMonero> View-only wallets are an important use case that's within Monero's core principals and this'll make them work properly.
21:35:42 <hbs[m]> Alex|LocalMonero: I tend to agree on this too, removes plausible deniability which may be very important for some.
21:36:19 <Alex|LocalMonero> Plausible deniability is easily achieved with seed offsets.
21:37:08 <Alex|LocalMonero> Or do you mean the inability to reveal your balance without revealing your private keys?
21:37:24 <tevador> The statistical "attack" already removes any chances of *plausible* deniability. We're talking about 99%+ chance of correctly guessing each spend with the old view key.
21:38:55 <hbs[m]> I mean that some people are worried that the very existence of the new key may be used by some as a pressure mechanism on them to share it. 99% chance is not 100% so that 1% might still save you in some jurisdictions.
21:39:23 <Alex|LocalMonero> It saved OJ didn't it?
21:39:40 <hbs[m]> if the key don't fit...
21:40:19 <Alex|LocalMonero> 😂
21:48:23 <tevador> Does it really make a difference? If there is any doubt if a particular spend is yours, they can just compell you to provide a crytographic proof that none of the decoys produce the key image with your secret spend key.
21:53:55 <hbs[m]> I am not saying it makes a difference, I am just suggesting that a better explanation on the rationale behind those keys be given so the ultra-paranoids don't start thinking a three letter agency is behind the introduction of those new keys
21:55:09 <hbs[m]> So clearly explaining how the same information can be obtained today and how a user could be compelled to provide it with the existing key structure would be a big plus in terms of acceptability of the change.
21:59:03 <tevador> Time for a CCS "explaining Seraphis to dummies".
21:59:44 <ofrnxmr[m]> Off topic for lab
21:59:44 <ofrnxmr[m]> But what are they going to do? Cry on Reddit? Stop all the miners/nodes they dont run? Just because you dont understand something doesnt mean anyone is obligated to ELI5.
21:59:44 <ofrnxmr[m]> One day, chatgpt will have the data and can explain it to those 
22:00:11 <ofrnxmr[m]> LMAO Tevador. Thanks for the Tldr.  I can stop typing
22:04:12 <hbs[m]> let's not forget that many users don't go down the rabbit hole of the transaction protocol, they just need to understand they are safe when they use Monero, and Seraphis might scare them because they will see videos on YT which will incorrectly explain that those new keys are backdoors.
22:04:40 <ofrnxmr[m]> ... #monero-offtopic:monero.social 
22:04:54 <ofrnxmr[m]> YouTube and fud arent lab
22:06:13 <hbs[m]> Sorry this is considered OT, was just bouncing off the original message stating that Seraphis will bring hard decisions
22:06:21 <jberman[m]> "Seraphis for dummies" was basically the goal I had with this talk: https://www.youtube.com/watch?v=xGEBRQU1lzw
22:06:42 <jberman[m]> I go into pros/cons of the view balance key at 4:14
22:08:44 <Rucknium[m]> The probabilistic heuristic for using the incoming view key to see change outputs will probably become less effective when ring size increases with Seraphis, right?
22:08:59 <hbs[m]> The 3rd pro requires a more thorough explanation
22:11:40 <jberman[m]> Yes Rucknium. The cons go into further explaining that 3rd pro hbs
22:13:25 <jberman[m]> I guess it could go deeper
22:13:31 <hbs[m]> Yes it is that kind of explanation that needs to be advertised more openly 
22:15:11 <hbs[m]> clearly stating how the same level of information could be obtained. The only difference being that once the view balance key is shared there is no privacy, whereas the sharing of key images and proofs need to be repeated for each txn/output