Anyone willing to lead a meeting this week (e.g. tomorrow) such that we can discuss Triptych and alternatives?

I can lead a meeting if no one else can, but it's during my workday so could be a bit sporadic (work will take precedent if something comes up).

Better to plan a meeting for when as many people who fully understand these protocols are available. I am not aware of the full list of relevant people

if a different address format is required (due to seraphis), is this an opportunity to get rid of subaddress (0,0) having a different prefix than subsequent subaddresses?

boogerlad[m]: It definitely would be nice to have a single uniform format. Off the top of my head, I don’t see any advantages to the normal vs subaddress distinction.

Currently that distinction makes it possible to have just 1 txo pubkey in a tx with many outputs, but in the past I have recommended deprecating that behavior anyway.

with visual distinction of normal address you know if you can derive or not sub-address (because it makes less sense to derive from sub-address if you don't know the current indexes)

that's the only advantage I can think of

h4sh3d: do you mean like when making a view-only wallet?

I meant in general, to know if this address has been derived or not, but I think I confused myself between normal and sub (0,0)

normal address (prefix 4 on mainnet) is the same as subaddress (0,0)

Having a distinct way to represent the primary public spend key + secret view key specifically for the purpose of creating view-only wallets would be desirable. (Call it the view-only key, or w/e). (Perhaps formatted similar to tx proofs: ViewOnly[Incoming]<b58-string>).

Removing the primary address would simplify UX, decrease address reuse, and allow us to rename "subaddresses" to just "addresses".

"Having a distinct way ... " -> With the added benefit that a user no longer has to store/enter two pieces of information (Primary address, Secret View Key) to create a view-only wallet.

For historical reasons we’d probably need to keep the term ‘subaddress’.

I meant like "Create new subaddress" -> "Create new address" in user-facing applications, but I see GUI already does this.

h4sh3d: I think the proposal is to completely deprecate normal addresses.

I guess only 1 address format is enough. First I thought being able to recognize the "master" address is something interesting; to not derive from a sub-address as a root, but in reality that doesn't matter and that's internal wallet stuff, users don't care

Is there any way to learn what specific output you sent someone using a tool that's available today?

I can find what output is sent back as change using Feather or xmrchain.net

but if there is no change, I can't deduce what output I sent to the recipient with any tools I can find

seems easy

I think checktx site identifies the output

Don’t wallets store that kind of info after you make a tx?

Hmm would lose that when restoring to a new device though

Haha stealth addresses make that tricky, actually

UkoeHB: git.featherwallet.org/feather/feather/issues/379#issuecomment-477

isthmus: MobileCoin decided to add a memo to all outputs to (optionally) record a recipient ID mobilecoinfoundation/mcips #4.

To solve the cross-device issue

Ah yea encrypted by the txn key?

yeah

It's mostly useful if you have a local record of recipient IDs, not a generic solution I guess

Ah I remember, it only works if you have a 2-out tx, the recipient ID is recorded in the change output's memo.

Then normal outputs' memos can record the sender ID

dEBRUYNE: re: meeting, 1) it's not clear how many people have actually read all the papers, 2) the papers aren't even completely done yet, 3) there no PoC for performance comparisons (i.e. there is a large set of multiple-choice questions between the papers and an actual implementation). Personally I'd like more time to get performance tests running (2 weeks? hopefully). My branch is here if you want to keep track of my

progress (all I have is a CLSAG mockup right now): github.com/UkoeHB/monero/tree/seraphis_perf.

ty for sharing

Was someone here looking for a rust dev? Someone in -dev was just offering to help in rust

Has anyone looked into a setting up a self-hosted collaborative LaTeX editor? Here are some examples:

Seems maybe not too difficult?

Rucknium[m]: we have self hosted codimd for collaborative markdown, and it works great, but i guess the active community fork is now hedgedoc github.com/hedgedoc/hedgedoc, highly recommended

zkao: Thanks. Does it support LaTeX? We need the maths. Or, I need the maths at least.

i am currently setting up the overleave self-hosted version, i will try it a bit and report back to you all :D

Oh nice! You just started now? Or have you been working on it for a while?

We really need more secure lines of communication for certain things. Not using Google docs, but using CryptPad for instance. Not using Overleaf on their servers, but maybe hosting our own.

i just started now but it is almost done

Oh. so it may be super easy. I'm thinking we could roll this into gingeropolous 's hosting of some Monero stuff. Maybe if we ask nicely.

they have a docker-compose file so its is pretty easy, but let me first get it fully running before i say to much about how easy it is haha

Rucknium[m]: you can do latex in there, e.g. hackmd.io/@dabo/B1U4kx8XI