Can anybody help with a supportxmr.com question?

<ravfx:xmr.mx> dontasktoask.com

<cyrix126:gupax.io> @ravfx:xmr.mx: That's like nohello.net 😌

<ravfx:xmr.mx> indeed

<kaigoh:gohegan.uk> Just out of interest, is there a stagenet / testnet version available with FCMP and Carrot up and running? I'm just filtering through all of the nonsense doing the rounds in the usual places and had a thought: if there is a test version out there, can't the FUD be completely and totally thrown out by a simple demo of a new wallet and the data the new view key would make visible?

<intr:unredacted.org> I think you gotta be in #monero-stressnet:monero.social

monero stressnet currently does not have Carrot implemented afaik

<intr:unredacted.org> oh

<munching:unredacted.org> omfggg it’s clearly not that. these people don’t know anything about monero

<plowsof:matrix.org> #monero-stressnet:monero.social

It has carrot transaction output format implemented

Not the wallet new scheme

<monerobull:matrix.org> What is mav smoking

<monerobull:matrix.org> mrelay.p2pool.observer/m/matrix.org/cAFElrKcdmxalqcaNXxrCWTo.png (31483.png)

<shitpost:monero.coffee> I need the view key update, I don't want to plug trezor every time I want to check my balance

I guess that's not happening now, but I wouldn't be opposed to it.

what is not happening now?

If new users come and want to share there transations, let them. I'm not going to do it.

There was no hardfork to add this, it's not even in the codebase test

yea, i mean it is dead as a converstion

There was never an automatic conversion

You are missing the point!

I'm saing... as long as it doesnt compromise my anonynity, I don't care, others can share their transactions.

Indeed, but they can also still do so

you can share proof of transactions with Monero?

Yes.

One sec.

Next MRL meeting is adding Carrot to the discussed items and also OVK. If you want to observe these AFAIK it'd be Wednesday at 17:00 UTC @ #monero-research-lab and on libera.monerologs.net/monero-research-lab (it's a research focused channel, so direct questions or other items are better left for lounge or general monero channels)

Lost_Puppy: view keys already exist, tx keys already exist, and directly InProof/OutProof can be made

These exist cause I could claim I sent you coins on a P2P exchange but you are lying. This allows the sender to prove they sent the coins to you, or for you to show its proper reception

Oh, thanks. Didn't know about that. It's been a while since I've hold it.

The view key is geared towards cold wallets and chosen auditors for businesses, so you don't have to hand out spend keys to your entire wallet or have these online

Looking more and more into it wiht the latest price action.

for example, the Monero general fund shares their view key. With that, we can decode incoming (and parts of outgoing) outputs blocks.p2pool.observer/tx/53084115a…6b5f1072e13012de8d52011fc296b90f614

we still don't know where the funds go to, even full view keys don't say that

after FCMP++, you also can't do output or ring tracing to statistically take a guess at the source

<intr:unredacted.org> @monerobull:matrix.org: the way he cropped up out of nowhere with the view-botted "sieg heil, also, buy monero" posts, and now this... lmao

<intr:unredacted.org> I dunno man

Carrot (the wallet one) also allows your internal history of change outputs and self-sends (your wallet history, attribution) to be kept private even against quantum adversaries github.com/jeffro256/carrot/blob/ma…rot.md#221-internal-forward-secrecy

Also shared a nice overview mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png but it fails to split the tx format (what is being hardforked, and that legacy wallets also will use and benefit) from carrot wallet (which is what has OVK, or Jamtis later down the line, which is the Post-Quantum scheme currently developed)

Thanks for the info. I'll do some homework.

<intr:unredacted.org> @shitpost:monero.coffee: me too.

<intr:unredacted.org> let alone "paper" wallets

<shitpost:monero.coffee> our CCS wallet keepers would have known the monero funds were stolen earlier, not months later :D > <DataHoarder> we still don't know where the funds go to, even full view keys don't say that

<shitpost:monero.coffee> well actually everyone would have known it

you can even tell the drainage blocks.p2pool.observer/tx/ffc82e64d…1278aef0b80a7d16d7ca12ab9a88f5bc56a

as you can tell when outgoing are made

<albertlarsan68:albertlarsan.fr> DataHoarder: Is it normal that this page says "Part of the CSS Wallet Drain Incident."?

22:04:42 <br-m> <shitpost:monero.coffee> our CCS wallet keepers would have known the monero funds were stolen earlier, not months later :D > <DataHoarder> we still don't know where the funds go to, even full view keys don't say that

<albertlarsan68:albertlarsan.fr> mrelay.p2pool.observer/m/albertlarsan.fr/XbqFKxpMDNrZmmrqHpVmEeNp.png (image.png)

it's on response to that

I added annotations to the transactions that did the sweep out

follow the link to the blog (from 2023)

<albertlarsan68:albertlarsan.fr> It says CSS, not CCS

well, than THAT is the issue as usual

see plowsof you are not the only one that does CSS :P

that always preys on our minds albertlarsan68 :)

updated it for next restart

<shitpost:monero.coffee> and as far as I know it was on a windows server or pc and it was never audited > <DataHoarder> 22:04:42 <br-m> <shitpost:monero.coffee> our CCS wallet keepers would have known the monero funds were stolen earlier, not months later :D > <DataHoarder> we still don't know where the funds go to, even full view keys don't say that

I mean auditing movements, not the setup

<ofrnxmr:xmr.mx> @monerobull:matrix.org: Crack or meth

<jeffro256> selsta: It has CARROT , the addressing protocol , implemented and integrated, but not the new OVK wallet format integration yet . The crypto is implemented and tested

<ofrnxmr:xmr.mx> @kaigoh:gohegan.uk: For context, the question was about testing / demoing OVK wallets

<ofrnxmr:xmr.mx> Its pretty simple. It shows the same data as restoring from seed. Txids, amounts, times, but not recipient addresses

(or sender addresses)

and FCMP++ removes the ability to do statistical ring analysis

<ofrnxmr:xmr.mx> :P if it showed sender addresses, that would be a backdoor fed move :D lmao

<ofrnxmr:xmr.mx> And to be clear, by sender i mean the address that sent to me

🏃

<jeffro256> @ofrnxmr:xmr.mx: Some people want the tx private keys to be deterministic, so that reloading your seed phrase reloads the tx private keys, and you can make tx proofs even if your wallet cache is deleted

<ofrnxmr:xmr.mx> who are these "some people"

<jeffro256> I'm pretty uncomfortable with that, but I do see the utility

<jeffro256> idk there's some GH issue somewhere

<ofrnxmr:xmr.mx> I do understand that its can be a pain to not be able to provide tx proofs if you restore from seed or from a different wallet w/ the same seed. I can't say that would be a bad thing if its only possible for spend wallets to achieve

<ofrnxmr:xmr.mx> But actually, i like that i can disable saving of recipient info or tx keys, and not even be able to provide such info

you'd still need the recipient address to make the proof, no?

<ofrnxmr:xmr.mx> (i actually dont save recipient info or txkeys)

even if tx key is deterministic based on some method

<plowsof:matrix.org> we've had multiple CSS incidents DataHoarder 😔

outside of specific protocol I don't see the need for deterministic tx key on sender side, as the burning bug is fixed already

<jeffro256> DataHoarder: yes\

as in, deterministic randomnness

and recipient side derivation is enforced for normal wallets

p2pool as implemented uses deterministic keys per output/block/p2pool as it requires these to re-derivate outputs and verify, but that's not on wallet side

<jeffro256> it's so that if you screw up and lost your wallet cache, you can still prove to a third-party that you actually sent funds. it has apparently happened to more than 1 person > <DataHoarder> outside of specific protocol I don't see the need for deterministic tx key on sender side, as the burning bug is fixed already

yeah. no way to make an OutProof without these

also, miners can't make OutProof :P cause monero never saves tx keys used in generating the template

unless you are p2pool

<jeffro256> huh

<jeffro256> i didn't know that lol

(or returns, the tx key is ephemeral in the get template method)

<jeffro256> makes sense, but I never though about it

<jeffro256> You can recover the ECDH if you're the holder of the address, but I see your point

I mention that under blocks.p2pool.observer/proofs

> Monero does not save transaction keys when calling get_block_template. This method is currently only used by P2Pool thanks to it creating templates on its own.

yep, on new derivation method you can

but not before

<jeffro256> Might be useful if you're a pool miner to prove you didn't make a wack template

(outproof vs inproof)

also if it had been saved/provided separately

it would have fixed the Tari burn bug

<jeffro256> ah did it re-use tx keys ?

where the pubkey was overwritten on the tx, it could have been fetched from the tx priv

see this example 85c9e0e2fa7d843b6698d6aa9c51e0dcda030126805654d9e91a68d720268764

err blocks.p2pool.observer/block/85c9e0…0dcda030126805654d9e91a68d720268764

7 bytes of tx pub were overwritten

you can recover with view key + bruteforcing these (and doing derivations)

56 bit keyspace with some reductions, but still vastly too slow even for the thrown together GPU code

<jeffro256> ohhhh

<jeffro256> That's unfortunate

(which I made for fun git.gammaspectra.live/WeebDataHoarder/tari-tx-brute )

<jeffro256> They've got 72057594037927936 combos to try. Better start soon...

I wonder what sort of entropy you'd have available

:)

given that post FCMP++ txs can be signed without the membership proof for example

<jeffro256> Not all bits make valid points on the Ed25519 subgroup, so definitely less than that, but still sucks

yeah, it's about a 50% decoding

then view tag

so about 8 bit reduction

<jeffro256> 50% decoding? I would've though that the vast majority of time spent was doing the Ed25519 scalar-point mult

sadly the CUDA waves don't have that good granularity

maybe an FPGA can do the bulk, then requeue

I mean bit space

50% fail/succeed

so -1 bit

<jeffro256> Do you know how much Tari was affected?

it was not tari, but Monero

one sec, I have the amounts

<jeffro256> Oh i see > <DataHoarder> 50% fail/succeed

02:12:26 <DataHoarder> there's a total of 139.641137792160 XMR that I could find "lost" to the Tari bug

I can recalculate the list (it's part of the finder program in that repo) but seems debian paste deleted it now

but about deterministic entropy, what do you have even in an offline wallet? and wallet could have been synced without all txs (synced at a specific height for example)

I guess you could take the inputs as entropy, local derivations, but ofc, destination cannot be stored in any way

<jeffro256> You could use a function of your spend key or view key (for hiding), plus the spent key images (for inter-tx burning), plus local output index (for intra-tx burning)

<jeffro256> key images + local output index are public, so all the offline needs to remember permanently is the spend key or view key, depending on which they use

that'd affect internal moves transparency

which I guess don't need this

<jeffro256> wdym

it's adding an extra scheme that can be played with outside of the current context, so care would need to be had to not introduce any shortcuts against any quantum capable adversary

<jeffro256> Oh yeah I see. Yeah that's correct.

<jeffro256> If you were using the new 6-key wallet in the CARROT spec, you'd want to use the view-balance secret instead of the potentially leakable k_v

<jeffro256> I don't think it really matters for legacy wallets either way, since any QC with one of their Monero addresses can peel off k_s and k_v, which reveals the whole tx history anyways

in that case even if you import key images with a view incoming key wallet, you can't create this deterministic derivation

<jeffro256> Well if your hot wallet only has k_v, then the cold wallet would have to do it. If the hot wallet had s_vb, then the hot wallet could do it

<jeffro256> It depends on how you set it up

generate deterministic derivation secret? :)

I guess as long as it's doing the similar derivations via H(...) you can't walk it backwards even from a quantum adversary perspective

<jeffro256> @jeffro256: To expand on this, in either case, to make a tx proof as a QC, you need to know both the ephemeral public key (which is on the chain), and one the Monero addresses of the receiver. Without deterministic tx keys, a QC can still derive the tx key if it knows the receiver by computing the ECDH directly, then finding r s.t. ECDH = 8 r K^j_v.

<jeffro256> DataHoarder: Hmmmmm......

<kayabanerve:matrix.org> @jeffro256:monero.social: monero-wallet supports deterministic entropy for ephemeral keys.

<jeffro256> You federal agent

<kayabanerve:matrix.org> lol

but yep jeffro256 that is what I mean, it's a "shortcut" pathway to jump derivation tiers