<j​0j0xmr:monero.social> What kind of protocols? You mean because something like Serai needs it? We shouldn't sacrifice fungibility just to not inconvenience some projects.

<j​0j0xmr:monero.social> And if we remove it completely and people find another way, then even better - we can patch that too.

<3​21bob321:monero.social> I think someone floated the idea of specific fields

<j​effro256:monero.social> That's the thing: we really can't from an information theory perspective. There's no way to prove that a public key isn't encoding other information besides its public key. Theres also scalars chosen in some proofs that we can't realistically enforce the value of

<j​0j0xmr:monero.social> But we can easily remove tx_extra right? That's an easy win.

<j​oiboi.crypto:matrix.org> repo.getmonero.org/monero-project/c…proposals/-/merge_requests/444?s=09

<s​parrov:monero.social> hey. am I correct to assume the secret tx key (that the sender generates and has in cache) and the tx public key (that is inscribed onchain and can be viewed for example with xmrchain given a tx id). are these two a pair? a standard EdDSA keypair? can I generate the tx public key using only secret tx key? with openssl or something?

It's Ed25519 keypair

so yeah, probably any cryptography library doing basic Curve25519 ops will work

tx public key = ScalarBaseMult(tx private key scalar)

<s​parrov:monero.social> aha, curve25519. so I was thinking. could I use this to gatekeep a tor service using tor's client authorization, which is x25519. for example ask some people to send monero. then i scrape my incoming txns, authorize the tx public keys. then users could access the service using their secret tx key. or am i wilding here

you can prove someone sent you something in a different way

x25519 has different semantics

and monero uses raw curve25519 in many cases

<s​parrov:monero.social> that requires a communication channel to send the proof tho. couldn't you just use the keypair? are they not suppose to be bidirectional or something like that

making transactions with custom private keys is also pain, I haven't checked if monero cli allows it

I guess instead users could extract the private tx key from what they sent

<s​parrov:monero.social> right i was thinking the one-time key. not using any custom

you can verify this yourself, anyhow

have a sample tx private key / tx public key + transaction p2pool.observer/share/9ba3fde1c95fe…ee43b1b87b52ae00e69a359d380b41f4f46

see "Coinbase Private Key" and linked Coinbase Transaction

tx pubkey being 2f5416678026733e54b9c207a021efee8df4fb34ceeed5eedb975207312efa73

tx privkey being d22bbd93e1ca55d5bd5ba91770ce4ce606b6d5ef0fac5d87a0a2d0012623d908

see if it would pass the conversion on Tor

tx being on p2pool.io/explorer/tx/e35d10d98cde6…53eab11099ea72d8b0aaae5930d2f260cf4

technically people could reuse their private keys right?

<s​parrov:monero.social> right, reuse possible but not an issue for what i have in mind. and so the conversion should theoretically work then unless some translation is needed because of different semantics for x25519. unless semantics means incompatible

I'll give it a quick try using golang X25519 package ScalarBaseMult pkg.go.dev/golang.org/x/crypto/curve25519#ScalarBaseMult

both ScalarBaseMult and X25519 with Point set as Basepoint give different results

d22bbd93e1ca55d5bd5ba91770ce4ce606b6d5ef0fac5d87a0a2d0012623d908 => 45e2f997f2fa8b2bcfdeb0d30f897779f53488992c8ea023984e761795e3e417

it's different in the end crypto.stackexchange.com/questions/…ifference-between-x25519-vs-ed25519

private keys are basically scalars but everything else differs ofc

moneromooo github.com/monero-project/monero/bl…yptonote_basic/tx_extra.h#L111-L156 is incosistent with add_mm_merkle_root_to_tx_extra - it misses the length field before depth

^ I was going crazy seeing difference on p2pool new merge mining code vs that old decoder/encoder

Looking at the code, it seems the length is not technically needed. It's a shame the length isn't handled by the calling code like, say, PNG.

that was also mentioned, yep. so far it writes the length and ... checks the data was the correct length

IIRC Length is needed somewhere else, so a parser could skip the tag entirely

afaik length can be a max of 32 + 9 bytes right?

root hash + max varint size

code indeed only reserves one byte for this