13:55:47 b​inarybaron:matrix.org: sure thing
13:56:25 b​inarybaron:matrix.org: You tell me haha 😅. If I remember correct, I think you wrote this library.
13:56:33 b​inarybaron:matrix.org: You tell me haha 😅. If I remember correctly, I think you wrote this library.
14:58:15 b​oog900:monero.social: yeah sounds goods to me, I can't see many people caring that equivalent addresses on different networks wont be equivalent
15:57:27 b​inarybaron:matrix.org: I'm building an extension for arbitrary data in `tx_extra`. I don't want to break too much stuff or interfer with what Serai / future Monero upgrades might use the field for. Its going to be around 256 bytes long. We'll use the `ARBITRARY_DATA_MARKER` defined in `monero-oxide` and content will be encrypted with a shared secret.
15:57:27 b​inarybaron:matrix.org: https://gist.github.com/binarybaron/86d2b2d24e0ce943d6ee6bbd4a0eb7f2
15:57:29 b​inarybaron:matrix.org: anyone wanna look over it and comment if there are any obvious issues with the approach?
18:37:07 k​ayabanerve:matrix.org: The limit on extra != the limit on ExtraField::Nonce. You'd need a bespoke ExtraField, to use multiple, to break compliance, or abuse to actually write 1 KB.
18:39:41 k​ayabanerve:matrix.org: I'd define `l` as a u8 accordingly.
18:39:41 k​ayabanerve:matrix.org: I'd also apply a DST when deriving the ChaCha key.
18:39:43 k​ayabanerve:matrix.org: Do you require the padding have any distribution? I'd specify it as zeroes.
18:40:14 k​ayabanerve:matrix.org: Please encrypt the marker and let the only fingerprint be the constant length padded to (255 bytes or so).
18:40:58 k​ayabanerve:matrix.org: I do support using ARBITRARY_DATA_MARKER. Monero as-is ignores it and it was reasonably chosen. Doing something bespoke will likely cause Monero's codebase to not support parsing these.
18:41:20 k​ayabanerve:matrix.org: Or you'll be back at using ARBITRARY_DATA_MARKER, but then you should piggy-back for the wider set of users.
18:42:14 k​ayabanerve:matrix.org: I'd suggest b'HRMS' as a marker in-ciphertext.
18:43:52 k​ayabanerve:matrix.org: I'd also suggest steganography. You can get a decent amount of data in existing transactions depending on how/what you do. Specifically, if you revert to a ring size of 10, you'd receive 186 bytes. That has a loss of privacy to the message recipient, but isn't fingerprintable on-chain, which I'd assume is the larger concern given today's ring signatures.
18:54:08 b​inarybaron:matrix.org: Yes, I'd use zeroes. It is encrypted anyway so there is no need for them to be randomly generated.
18:54:24 b​inarybaron:matrix.org: Agreed. I was intending to do this.
18:56:18 b​inarybaron:matrix.org: I have thought about this but I wanted my code to depend largely on APIs exposed by `monero-oxide` without requiring any patches. Can you comment on the complexity of doing this?
18:56:19 b​inarybaron:matrix.org: Loss of privacy to the message recipient is not a concern in our case at all as the spent enote was created by the recipient.
19:01:31 b​inarybaron:matrix.org: Ok, thank you for noting that. This means that `monero-oxide` makes a decision to limit me to 254 bytes (`MAX_ARBITRARY_DATA_SIZE`). This should be enough for us. Around 200 bytes are enough for us. Did I understand this correctly? This is a (fairly) arbitrary limit enforced by `monero-oxide` not related to a specific consensus/relay policy?
19:01:47 b​inarybaron:matrix.org: Thank you for taking the time to comment. I truly appreciate it.
19:03:14 b​inarybaron:matrix.org: Do those specific characters have any meaning or did you choose them at random?
19:03:53 r​edsh4de:matrix.org: probably HeRMeS
19:04:07 b​inarybaron:matrix.org: Yeah true I see it now
19:04:09 b​inarybaron:matrix.org: silly me
19:05:07 b​inarybaron:matrix.org: This also means we'd have to find a different way at the next hardfork. Is there a similar way to embed arbitrary data with FCMP++? If there isn't, I'd go with `tx_extra`.
19:15:21 k​ayabanerve:matrix.org: Your byte seems like a marker but more of a magic sequence, which are traditionally four bytes, hence the suggestion.
19:15:23 k​ayabanerve:matrix.org: I'd specify they're zero. I wouldn't simply use zero.
19:15:25 k​ayabanerve:matrix.org: You'd need a custom CLSAG signer. Specifically, you'd need to choose a subset of the decoy responses to place your message within. You may be able to reasonably achieve that with a seeded RNG which yields legitimate RNG until it switches to the decoy values, but you'd need to know when to switch which would be introspective.
19:17:34 k​ayabanerve:matrix.org: There's 1060 or so bytes by relay, consensus with the next HF
19:17:35 k​ayabanerve:matrix.org: There's ExtraField::Nonce which is where this should go if we assume a Monero transaction is a help desk and you ask it for something and it guides you somewhere. When we consider it's more like a battlefield sieged by mortar shells, that does go out the window.
19:17:37 k​ayabanerve:matrix.org: The Nonce field is limited to 255 bytes.
19:17:39 k​ayabanerve:matrix.org: The first byte is a marker, 0 for an unencrypted payment ID and 1 for an encrypted payment ID. oxide appropriates 127 for arbitrary data.
19:17:41 k​ayabanerve:matrix.org: 255 bytes - 1 byte marker = 254 bytes of room
19:18:06 k​ayabanerve:matrix.org: You would need a distinct solution at the HF, but at the HF, the privacy impact of bespoke TX extras is isolated.
19:18:29 k​ayabanerve:matrix.org: With ring signatures, this likely is decently usable for EAE attacks.