01:54:19 <m-relay> <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.
01:57:15 <m-relay> <j​0j0xmr:monero.social> And if we remove it completely and people find another way, then even better - we can patch that too.
02:17:22 <m-relay> <3​21bob321:monero.social> I think someone floated the idea of specific fields
02:44:00 <m-relay> <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
03:28:22 <m-relay> <j​0j0xmr:monero.social> But we can easily remove tx_extra right? That's an easy win.
03:39:22 <m-relay> <j​oiboi.crypto:matrix.org> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/444?s=09
14:42:01 <m-relay> <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?
14:49:44 <DataHoarder> It's Ed25519 keypair
14:50:36 <DataHoarder> so yeah, probably any cryptography library doing basic Curve25519 ops will work
14:51:43 <DataHoarder> tx public key = ScalarBaseMult(tx private key scalar)
14:58:52 <m-relay> <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
14:59:50 <DataHoarder> you can prove someone sent you something in a different way
15:00:23 <DataHoarder> https://www.getmonero.org/resources/user-guides/prove-payment.html
15:00:30 <DataHoarder> x25519 has different semantics
15:00:47 <DataHoarder> and monero uses raw curve25519 in many cases
15:01:11 <m-relay> <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
15:01:26 <DataHoarder> making transactions with custom private keys is also pain, I haven't checked if monero cli allows it
15:03:41 <DataHoarder> I guess instead users could extract the private tx key from what they sent
15:04:10 <m-relay> <s​parrov:monero.social> right i was thinking the one-time key. not using any custom
15:07:42 <DataHoarder> you can verify this yourself, anyhow
15:07:56 <DataHoarder> have a sample tx private key / tx public key + transaction https://p2pool.observer/share/9ba3fde1c95feccec559fe4005310ee43b1b87b52ae00e69a359d380b41f4f46
15:08:32 <DataHoarder> see "Coinbase Private Key" and linked Coinbase Transaction 
15:08:41 <DataHoarder> tx pubkey being 2f5416678026733e54b9c207a021efee8df4fb34ceeed5eedb975207312efa73
15:08:50 <DataHoarder> tx privkey being d22bbd93e1ca55d5bd5ba91770ce4ce606b6d5ef0fac5d87a0a2d0012623d908
15:09:09 <DataHoarder> see if it would pass the conversion on Tor
15:09:48 <DataHoarder> tx being on https://p2pool.io/explorer/tx/e35d10d98cde6e302eba92a5eab0953eab11099ea72d8b0aaae5930d2f260cf4
15:10:32 <DataHoarder> technically people could reuse their private keys right?
15:15:27 <m-relay> <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
15:19:35 <DataHoarder> I'll give it a quick try using golang X25519 package ScalarBaseMult https://pkg.go.dev/golang.org/x/crypto/curve25519#ScalarBaseMult
15:23:48 <DataHoarder> both ScalarBaseMult and X25519 with Point set as Basepoint give different results
15:24:30 <DataHoarder> d22bbd93e1ca55d5bd5ba91770ce4ce606b6d5ef0fac5d87a0a2d0012623d908 => 45e2f997f2fa8b2bcfdeb0d30f897779f53488992c8ea023984e761795e3e417
15:25:28 <DataHoarder> it's different in the end https://crypto.stackexchange.com/questions/84430/difference-between-x25519-vs-ed25519 
15:25:46 <DataHoarder> private keys are basically scalars but everything else differs ofc
16:46:14 <sech1> moneromooo https://github.com/monero-project/monero/blob/c8214782fb2a769c57382a999eaf099691c836e7/src/cryptonote_basic/tx_extra.h#L111-L156 is incosistent with add_mm_merkle_root_to_tx_extra - it misses the length field before depth
16:49:30 <DataHoarder> ^ I was going crazy seeing difference on p2pool new merge mining code vs that old decoder/encoder
16:57:27 <moneromooo> 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.
17:00:17 <DataHoarder> that was also mentioned, yep. so far it writes the length and ... checks the data was the correct length
17:21:08 <sech1> IIRC Length is needed somewhere else, so a parser could skip the tag entirely
17:27:11 <DataHoarder> afaik length can be a max of 32 + 9 bytes right?
17:27:17 <DataHoarder> root hash + max varint size
17:27:51 <DataHoarder> code indeed only reserves one byte for this