not currently, besides the normal cryptography overhead, but carrot also improves on view tags

so the scan time is still constant

(per tx scanned)

<pyratevevo:matrix.org> Cool.

but 1/2^24 outputs are scanned on avg

currently it was 1/256 on avg

<pyratevevo:matrix.org> I still need to figure out things I'm curious about like the network's hypothetical maximum scale and capacity.

<jeffro256> @jeffro256: This also makes the whole drama over the OVKs somewhat pointless. In a scenario where governments are already incredibly invasive and coercing people to hand over view key information, THEY DONT NEED OUTGOING VIEW KEYS. They could tell when you received money and didn't tell them the key image. You could try to [... too long, see mrelay.p2pool.observer/e/ssajjd8KWWhNX1Q1 ]

"oh no outgoing view key? cool, so next step... yeah give spend keys and we will just look around :)"

<jeffro256> This is also assuming after FCMP++, because they REALLY don't need them before FCMP++ b/c of ring signature tomfoolery

<pyratevevo:matrix.org> Speaking of FUD, people were debating if Zachbxt's "news" was nothing more than market manipulation.. Apparently the timeline doesn't add up.

if they want to do X, they don't care it's not supported, they will ask for what gets X in the same process. or ofc, ask for ongoing key images

<intr:unredacted.org> @pyratevevo:matrix.org: even ignoring the spike, monero's market price has already had an upward trend for at least a year before

governments will cry if they have to hit you with a wrench over a spend key

<pyratevevo:matrix.org> @pyratevevo:matrix.org: The idea of Monero being targeted from all fronts, spreading FUD and manipulating the market sound all too silly but highly plausible at the same time.

instead of a outgoing view key

<pyratevevo:matrix.org> @intr:unredacted.org: I think for the price spike specifically it's probably just a coincidence of many things happening, not just 1 bitcoin wallet getting stolen.

<jeffro256> Cindy: Either way, it depends on you whether it comes down to the wrench or not. CARROT can't fix a weak mind

<pyratevevo:matrix.org> Like, let's say that a whole ass country starts using Monero. Millions of people start transacting in XMR mobile wallets. How "big" does the network need to be to accommodate the enormous amount of transactions ? > <@pyratevevo:matrix.org> I still need to figure out things I'm curious about like the network's hypothetical maximum scale and capacity.

<jeffro256> 1 million people X 5 txs per person per day X 365 days/year X 6300 bytes/tx = 11.5 terrabytes per year chain growth

<jeffro256> 6300 is after FCMP++

<jeffro256> Or are you asking about p2p network size ?

<pyratevevo:matrix.org> @jeffro256: Whoa, that's a lot.

<pyratevevo:matrix.org> @jeffro256: I was asking about how the network could handle that m any transactions at the same time.

<pyratevevo:matrix.org> Bandwidth, basically.

<just_another_day:matrix.org> Light wallets are also obviously bad for mandatory privacy... for the same reasons. Most users will happily give their OVK to a large LWS provider for the convenience of not running their own > <@rbrunner7> The outgoing viewkeys allow much better "light wallets". You can entrust somebody running a server for that with your viewkey, or you can run such a server yourself.

<elongated:matrix.org> @just_another_day:matrix.org: Like mymonero did for years

<elongated:matrix.org> Lws should be not be made scalable

<monerobull:matrix.org> yall are insane

<monerobull:matrix.org> btw the niew viewkeys can offload most of the scanning without revealing everything

<monerobull:matrix.org> you could give coinbase your viewkey and have it scan 90% and still have better privacy and UX than we have right now

<monerobull:matrix.org> Its not like Monero is going to get relisted to build a fragile net of known viewkeys

<monerobull:matrix.org> we are already delisted pretty much everywhere, may as well have a better UX for the people that can still figure out how to find it

<kaigoh:gohegan.uk> I'm not suggesting Monero developers are the ones to have to do this, especially as good information, technical information and explanations have already been published on official channels, but the community as a whole really needs an ELI5 / idiots guide to CARROT to clear away the FUD and absolute crap being circulated in the usual places (Reddit etc.)

<kaigoh:gohegan.uk> @kaigoh:gohegan.uk: mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png (image.png)

<intr:unredacted.org> Something like that, yeah

<hbs:matrix.org> @kaigoh:gohegan.uk: "anyone with the key can see" would be more correct

<kiersten5821:matrix.org> so will fcmp require me to create a new seed in the gui/cli wallets? or can i use an existing seed but change the derivation path or something in a new wallet

<ofrnxmr:xmr.mx> To use carrot features youll need a new seed

<kiersten5821:matrix.org> Unfortunate

<pyratevevo:matrix.org> @kiersten5821:matrix.org: Not required, you can still use the old wallet, albeit without the CARROT features.

16:12:54 <br-m> <ofrnxmr:xmr.mx> To use carrot features youll need a new seed

to use carrot-native specific features*

legacy wallets still use the carrot addressing mode and gain some things, too, just not as much

<kiersten5821:matrix.org> is there like a big doc that will explain everything that changes with fcmp?

<kiersten5821:matrix.org> i searched but couldn't find

<ofrnxmr> Fcmp and carrot are different things

<ofrnxmr> There should be docs for each

<kiersten5821:matrix.org> i must have terrible search skill because i can't find these docs and can't even find how much bigger a 2 in 2 out tx will be after the upgrade... i'm sure that's been discussed 200x by now though

Carrot github.com/jeffro256/carrot/blob/master/carrot.md + ongoing gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

Carrot is an addressing mode

<kiersten5821:matrix.org> thanks, still would like to know the tx size change though, i remember a long time ago it was more than double or something

a bit more than that :)

I can't remember if we have a single document for FCMP++ part

but you can peek around in my stressnet block explorer stressnet.p2pool.observer that has the current changes (and we are testing FCMP++/Carrot)

you can compare tx sizes

<ofrnxmr> @kiersten5821:matrix.org: 2 in 2 out is about 7.3kb iirc

<ofrnxmr> stressnet.p2pool.observer/tx/3ec782…fb101bf6b30d5f871e7349ed98c55097b01

<kiersten5821:matrix.org> DataHoarder: thanks, really cool

<rucknium> @kiersten5821:matrix.org: Are you trying to build something with Monero?

anyone here used haveno on tails?

<rucknium> @kiersten5821:matrix.org: Write the Qs of a FAQ and it can be filled in by knowledgeable people. Then it can be posted as a blog post to getmonero.org

<kiersten5821:matrix.org> @rucknium: yeah, but these are mostly just general questions out of curiosity. i asked the stuff i needed to know in the research lounge and dev chat a few days ago, haven't had many problem since then

<rucknium> Want to give any hints about what you're building or will it be a surprise later? :)

<kiersten5821:matrix.org> though there were a couple things not in the rpc docs that i had to dig into that i talked about in the monero-docs matrix chat, which is that the change address of a tx doesn't necessarily belong to you, and the pending transfers with the get_transfers rpc call include things in the mempool, but don't refresh it

<kiersten5821:matrix.org> @rucknium: i'm developing a multisig-based bridge for a guy. but yeah those questions about the fcmp stuff weren't related, just curiosity

<rucknium> @kiersten5821:matrix.org: FROSTLASS is an alternative multisig protocol for Monero: github.com/monero-oxide/monero-oxide/tree/main/audits/FROSTLASS

<kiersten5821:matrix.org> @rucknium: some of these have been answered by you guys already or are answered in the doc, but on the user level i think they will be helpful, of course there are many more i'm sure would be enlightening to average nontechnical users that i haven't thought of. most users are not in this chat after all.

<kiersten5821:matrix.org> as as side note, when devving, the docs for xmr seem to be pretty sparse on details so i have to ask a lot of questions here. also, a huge amount of stuff in getmonero.org/resources/user-guides is extremely outdated, like the multisig article, when docs.getmonero.org is the up to date version. overall i think the [... too long, see mrelay.p2pool.observer/e/-KvCqt8KLTR1WjhZ ]

<kiersten5821:matrix.org> Will I need to create a new wallet with a new seed to enjoy the benefits of the upgrade?[... more lines follow, see mrelay.p2pool.observer/e/-KvCqt8KLTR1WjhZ ]

<pyratevevo:matrix.org> @kiersten5821:matrix.org: Would like to see the answers to all these questions too, in a user friendly format.

<just_another_day:matrix.org> And now they've stepped down precisely to push people away from this trust model > <@elongated:matrix.org> Like mymonero did for years

<just_another_day:matrix.org> And yet monero-lws is deliberately made to be a high-performance lws server > <@elongated:matrix.org> Lws should be not be made scalable

<intr:unredacted.org> I might be wrong but I don't believe the full view key is actually necessary for LWS

<sgp_> Lightweight wallets aren't all bad. I have a way better time with my self-custody wallet now that I can 1) connect over Tor and 2) not ever have to sync anything. For those who do self host, it's the best experience with zero compromise

<sgp_> good luck regularly syncing a full-local-sync wallet with a Tor node. It's slow

<just_another_day:matrix.org> @sgp_: Does this mean MyMonero's decision to step down was wrong?

<sgp_> no, I'm just saying I love self hosting my own LWS :)

how necessary is it to sync fully if you already know you haven't gotten any new outputs since the last time you synced

<sgp_> so much so that MAGIC built our own wallet for it :p

<sgp_> Cindy: you need to sync to spend, at least at a high level

is it for decoy selection?

<sgp_> there are workarounds, but no wallets use those

<sgp_> at least no wallet I would recommend

<intr:unredacted.org> on that note, I've been trying skylight + monero-lws but for some reason monero-lws is not giving out subaddresses despite having --max-subaddresses set to 500 or something

or just checking if the key images associated with the outputs have been spent

<sgp_> @intr:unredacted.org: are you on the latest skylight release, and did you install LWS recently? LWS only recently supported subaddresses correctly*

<sgp_> *there are still some quirks, but far fewer than there were a few months ago

<intr:unredacted.org> yeah, monero-lws is lastest checkout, skylight is latest github release

<intr:unredacted.org> latest as in, uhhh, 5 hours ago

<just_another_day:matrix.org> IIRC there was a proposal for probabilistic view keys for light wallets that filter out 255/256 outputs

<just_another_day:matrix.org> is it still a thing?

<intr:unredacted.org> I can see from the logs from monero-lws that it's not allowing subaddresses

<sgp_> if you bump the lookahead to 20k, let me know if you still see issues with subaddresses

<intr:unredacted.org> but I have no idea if it's a skylight issue or monero-lws issue

<intr:unredacted.org> I'll try that, thank you

<sgp_> no ty for the report and testing it out

<intr:unredacted.org> give me just a few mins

<intr:unredacted.org> stupid question but I don't see any commandline options or mentions in monero-lws docs on lookahead, where do I set it 😅

21:51:48 <Cindy> is it for decoy selection?

for a wallet, or for a node?

wallet asks node for decoys

and ofc, for checking spent key images

but wallet syncing doesn't build up its own decoy db

it only tracks its own state

that's why you can "skip sync" at a specific height

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: Beta.monerodevs.org those user guides are essentially deprecated

<ofrnxmr:xmr.mx> The new keys are only relevant for new carrot wallets

<ofrnxmr:xmr.mx> The new address type is not visibly distinguishable from old ones

<sgp_> max_subaddresses in config

<ofrnxmr:xmr.mx> --max-subaddresses=20000 > <@intr:unredacted.org> on that note, I've been trying skylight + monero-lws but for some reason monero-lws is not giving out subaddresses despite having --max-subaddresses set to 500 or something

<intr:unredacted.org> oh that is the same thing, fuck me, sorry

<just_another_day:matrix.org> > they cannot see who sent the money, etc > <@kaigoh:gohegan.uk> mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png (image.png)

<just_another_day:matrix.org> > unless the sender has shared their view key as well

<ofrnxmr:xmr.mx> the servers default is 50:200 (50 accounts with 200 addresses = 10000 minimum)

<intr:unredacted.org> gotcha, so I deleted the old monero lws database, cleared the wallet from skylight, recreated it, accepted the request

<intr:unredacted.org> with monero-lws-admin debug_database, there's a boatload of "subaddress" objects, but even after I close skylight, open it up, wait for it to connect, hit receive, still only the main address with a warning that it can't use any more subaddresses

<intr:unredacted.org> I'm also noticing a little bar below the wallet balance that's stuck loading

<intr:unredacted.org> it's connecting over my lan, no tor

<sgp_> @intr:unredacted.org: do you select "No Tor" in Tor settings?

<intr:unredacted.org> Yes, that's correct

22:03:35 <br-m> <just_another_day:matrix.org> > unless the sender has shared their view key as well

<intr:unredacted.org> it's showing the "no tor" icon below the connected checkmark

they cannot see that

not directly

<just_another_day:matrix.org> what do you mean?

but you can replace view key with "cex"

<intr:unredacted.org> @sgp_:monero.social we can continue this in DM if you prefer

<ofrnxmr:xmr.mx> #skylight-wallet:monero.social

<sgp_> can you join #skylight-wallet:monero.social ? That's the best place for this discussion

still. in the case everyone shares their view (without balance) keys, you end up with similar issues AND you can tell the balance of each other

not carrot, today too

FCMP however does cover this

<basses:matrix.org> @sgp_: why this link is not in readme?

<just_another_day:matrix.org> FCMP patches vulnerabilities of (current) incoming view keys, but CARROT simultaneously introduces outgoing view keys to undone this improvement (i'm assuming "less optional privacy is better")

FCMP++ is about removing rings

you don't need view keys, CEX can do this with outputs they sent you

if you sweep multiple of these at the same time in same tx, they can statistically attribute these back

<just_another_day:matrix.org> this isn't only about CEX, merchants can also be pressured to require view keys from clients

what I mean. if you use CEX or merchants and they are just telling "I sent X tx with outputs to Y,Z" they can look back and do that

without view keys. you don't have to bring them to the conversation

it's hard to do, but on certain conditions you could pass this along and tag the outputs of the next tx

<just_another_day:matrix.org> will it be the case with fcmp?

it still doesn't give you information on its own, attribution is what they are looking for

no, fcmp++ removes rings

so you cannot do stuff like p2pool.observer/sweeps

<just_another_day:matrix.org> this is great

(p2pool outputs are known attributed to a specific miner, so you can tell when they sweep in a single tx, that's why we recommend using a different wallet for mining. solo miners also have unique signatures so the same rec also applies there)

<just_another_day:matrix.org> but when fcmp is implemented, view keys become relevant

<sgp_> @basses:matrix.org: no good reason. omission

suddenly they NEED them to accomplish stuff like this, besides tracking source ips that dandelion++ attempts to make hard

or at least, attribution. they don't need keys

they may ask for a list of txid and "is this yours"

remember you can't outdumb this, they care about the end result not how it gets there

if you remove any viewkeys in a special wallet (by making a wallet like old bitcoin lol, you lose wallet.dat and it's all gone, no seeds), besides having issues with quantum opponents, you'd ... be asked to just provide proofs

and they can assume you providing these no more = you failed at providing and are evading

or, they ask for a spend key via some third party "safe system" :D

even worse, forced to do multisig with them!

<just_another_day:matrix.org> it's harder for them to ask for a spend key

<just_another_day:matrix.org> the right to self-custody is relatively well-established

<just_another_day:matrix.org> but the right to privacy isn't

<just_another_day:matrix.org> it's really a question of how many people will choose to comply with a specific request

<just_another_day:matrix.org> i didn't get the "provide proofs" part

tx proofs

it can establish when you received funds like a view key

you can generate these with a view key, too

<just_another_day:matrix.org> but how do they know what tx i have made

I'm assuming you gave them a no-balance view key (like a legacy wallet one)

so they know when you receive funds, or someone else sent them to you and they know

<kiersten5821:matrix.org> i think he means the system shouldn't have view keys at all, like cash

they can ask for key image of each one

view keys are part of how you can have an efficient wallet and scan outputs, it's part of the design not just ... an extra feature

as an example from last conversation blocks.p2pool.observer/tx/9c78c972c…00aff96ac9d4bd886ef96639fcf3b328271

they know you received a transaction in 9c78c972c295f31cf3b30240a22c300aff96ac9d4bd886ef96639fcf3b328271, they may or may not have view key for it

they can ask for an InProof that shows you indeed received it

<just_another_day:matrix.org> but they would need to repeatedly ask for key images > <DataHoarder> they can ask for key image of each one

and for you to provide key images

<just_another_day:matrix.org> and only one time for a full view key

yes. they'd force this and non-compliance would be same as you moving elsewhere

so on mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png

"forced to share" it means the same that you got view keys or not

you should switch wallets

<just_another_day:matrix.org> @kiersten5821:matrix.org: my point was that we should make the compliance as cumbersome as possible so that it's harder to compel people to do so

this is important specially around a PQ Turnstile gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

which explicitly needs the generate image key

<just_another_day:matrix.org> like, currently many wallets don't even support exporting key images

i hate whenever i make a transaction, i have to export the key images

you can import seed elsewhere :')

or give the server my spend key (which is retarded)

<just_another_day:matrix.org> if someone asks to do so, most users will just go to another merchant

again, they will put the burden on you

this is just for a fundraising wallet

they don't care

Cindy: multisig too :D

That (we should make the compliance as cumbersome as possible so that it's harder) is an interesting way to see it.

<just_another_day:matrix.org> but when we have a single button "make regulators happy", most will just press it

legacy wallets as they exist keep being supported

if i could have an outgoing view key, i would publish that in a heartbeat

rather than having to stick with a hack

for my fundraising wallet

If we assume a central auth wants to demand it, then: if it is at all possible, we can assume it will be demanded, wnether easy or not.

compliance as cumbersome -> also means you make using monero as cumbersome

so it can't be used efficiently for multisig, used with cold spend keys

Then making it hard to do will just mean fewer people will use monero.

which also means cycling wallets is harder

<just_another_day:matrix.org> i'll copy my comment from reddit

Making things hard is effective with stuff like "should I use my node or a stranger's", not "can they demand this if it's a pain for me to do".

<just_another_day:matrix.org> "The scenario: a merchant has started accepting Monero. A regulatory agency is unhappy about the inability to identify the source of clients' funds. It recommends that the merchant asks clients to provide the key images to ensure the funds are clean - or face complications. Not necessarily legal complications, maybe just a ban [... too long, see mrelay.p2pool.observer/e/hfK3st8KMXNyUlpE ]

<just_another_day:matrix.org> The merchant faces a choice: they either comply with this recommendation or refuse. Now consider two hypotheses: the clients have a one-click solution to provide the key images, or no such tool exists.

<just_another_day:matrix.org> In the first case, the merchant would likely choose the first option. Most users would comply. Regulators are happy.[... more lines follow, see mrelay.p2pool.observer/e/hfK3st8KMXNyUlpE ]

and again, it's not making it transparent and sharing these no longer allows looking at ring elimination as a risk factor

yeah, outgoing viewkeys would make multisig easier

(FCMP++)

<kiersten5821:matrix.org> wait, this will cook my multisig setup?

In case of coercion, what counts is outright impossibility.

there's already a one-click option, give seed wallet, and users comply for the scams :P

with outgoing view keys, everyone automatically gets the latest key iages

images*

In that case, the centrl auth decides whether they still wnt to demand, If they do, you can't legally use. But they might not demand in the face of impossibility.

22:42:37 <br-m> <kiersten5821:matrix.org> wait, this will cook my multisig setup?

without ability to generate key images internally you can't see what's spent

without importing key images or making rounds for all participants

this also simplifies hardware wallets, too

which many can't export key images too

<just_another_day:matrix.org> but hardware wallets already work well, don't they?

The salient point here is whether the party bearing the pain is the one making hte decision.

they don't work well, specially if you need to know balances

for that you need to have them online

<elongated:matrix.org> @just_another_day:matrix.org: It’s not easy, you need the device connected while wallet syncs

not offline

you need to do this ... on each device you want to keep track of this

connect, sync, etc.

you can extract view keys atm, but that still gives no balance

<just_another_day:matrix.org> when i'm using a hw, i just plug it when I want to interact with the wallet

<kiersten5821:matrix.org> i remember a long time ago i was using an airgapped setup

<kiersten5821:matrix.org> and the importation thing cooked me

<kiersten5821:matrix.org> and suddenly it couldn't send anything lol

<just_another_day:matrix.org> For other coins too

<kiersten5821:matrix.org> so much more complicated than bitcoin

<elongated:matrix.org> @just_another_day:matrix.org: For other coins you just need to connect when you want to sign a tx

how would a merchant know their balance in hw wallet in cold storage?

you putting it online is a no-no

<just_another_day:matrix.org> @elongated:matrix.org: no. You need to get the address from the hw wallet too

that is no longer a "cold storage" setup

^

<just_another_day:matrix.org> to receive funds to it

<just_another_day:matrix.org> or maybe the saved address was altered

<just_another_day:matrix.org> if you don't reverify it

it makes all offline and multisig work as intended

nope

wallet extracts view key

nope

that is an extra check

<just_another_day:matrix.org> i'm talking about other coins

<just_another_day:matrix.org> like ledger app doesn't allow you to receive funds without plugging the hw wallet

if you copy these elsewhere like bitcoin xpub, you can generate the full tree

this is also how electrum or so work with wallets

and how multisig works. you can generate it all ahead of time

<just_another_day:matrix.org> because you need to check the address on the device

across all members, then ask for sigs

for monero: if you have the main address + view key, you can generate the account trees

that feature is broken on current hw wallets in monero btw when sending funds to integrated addresses

<just_another_day:matrix.org> cexes demand kyc. dexes don't. when dexes are easier to use than cexes, most people will choose them. When cexes are easier, most choose to do kyc > <moneromoooo> Making things hard is effective with stuff like "should I use my node or a stranger's", not "can they demand this if it's a pain for me to do".

<just_another_day:matrix.org> no one wants to loose their coins, but less people care about privacy > <DataHoarder> there's already a one-click option, give seed wallet, and users comply for the scams :P

so yeah, you want to make Monero impossible to migrate to a quantum-proof system? we need to place the pieces for this nowadays (and that is why the PQ Turnstile is carrot-native only)

the second people with quantum computers counterfeit coins

monero becomes dead

<just_another_day:matrix.org> DataHoarder: are outgoing view keys required for migration?

yes, see my previous link

well, they would be frozen before that. then turnstile would allow migrations to happen, then frozen

note this is not set in stone nor expected, but in the chance it has to be done, the way addresses and outputs are derived (Carrot) need to be done now, not later

"generate key image" is that just_another_day

monero being quantum-safe is really really important

see hierarchy github.com/jeffro256/carrot/blob/ma…ster/carrot.md#52-new-key-hierarchy

vs old

<just_another_day:matrix.org> i agree with that

<just_another_day:matrix.org> i just don't understand why a key that allows viewing balance but not spending it is required for post-quantum Monero

it might not be safe now Cindy but this is what allows a migration and not a restart

it's required for migrating the outputs

not after

<plowsof:matrix.org> can i deposit funds to subaddress infinity+1 to hide from quantum hackers

DataHoarder: at a certain point, does migration become impossible?

read gist :)

you're my AI!!!

i mean

i'll read i guess

again what it says there is not set in stone (they way it'd work)

>_>

> i just don't understand why a key that allows viewing balance

because it allows proving you control certain outputs in a quantum opponent safe way

as the derivation chain is not something a quantum opponent can walk backwards

you also need to prove the key image is not spent

quantum opponents could fake this for any output otherwise

smh, i can't get unlimited free monero hack

damn you jeffro

and DataHoarder

<intr:unredacted.org> hey kid, want some Quantum Monero ™

<just_another_day:matrix.org> i pointed this idea out in my reddit post btw. It would be good in my opinion, but it seems unrealistic. > <@kiersten5821:matrix.org> i think he means the system shouldn't have view keys at all, like cash

you can do this already

you can generate random target addresses with random spend/view keys

then scan for them

no seeds, all randomly generated

result: you need to continously backup. if you move some stuff around, and don't have the last backup, you lose everything that was returned in change or touched

ofc, no hw wallets

also it's all online/live!

<just_another_day:matrix.org> yeah this trade-off is obviously in favor of current system

<just_another_day:matrix.org> this upgrade essentially brings two things:

<just_another_day:matrix.org> 1. adds a new method to disclose your transaction history in one-click into every wallet (which can be implemented with the current protocol, but probably shouldn't be implemented)

<just_another_day:matrix.org> 2. this new method also allows the other party to passively monitor your wallet without any additional input from you, unless you change the address (which is currently impossible)

no you can

just sweep all to another wallet

don't disclose your keys

<just_another_day:matrix.org> no i mean the passive monitoring impossible

<just_another_day:matrix.org> unless we count statistical heuristics as a feature

> unless you change the address (which is currently impossible)

<elongated:matrix.org> Dude if you are forced to give keys, you stop using that wallet

that'd mean changing that key, which makes all addresses generated invalid

and also makes the seed words invalid

i don't get the people being worried

when i generated my wallet, there wasn't a creep breathing down my neck for the view key

<elongated:matrix.org> Cindy: Same gang coming from z

tbh as I said, all stuff that is trying to weaken or delay FCMP++/Carrot specially around quantum security is basically playing against Monero

also btw, you could do this in the same system

Jamtis also had this

Carrot had this

today you could be forced to do this too

if a hypothetical authority forced everyone to give up their view key (CryptoNote scheme)

they could correlate transactions from everyone

(Carrot-native could exist *today* but they aren't bothering)

no outgoing view key needed

some chains are already using Carrot as-is

just match up TXIDs

Cindy: or they could ask people to make such key in an exchange compliant wallet (tm)

carrot is an addressing system, which is entirely local to your wallet to some degree

you can ... basically make a different one for your own usecase

for example for a subset of p2pool outputs I'm looking at that, and it's compatible with the network

if you had everyone's view key, you could track down every XMR down to its codebase transaction

so i don't get this argument

if this is the reason OVKs are bad, then why haven't they done it now

^ cause generating a new wallet and sweeping is too easy

when they have to they will just bring the book on you and either you comply or else

and you can comply in many ways regardless how you have set it up

including givin just an excel spreadsheet :')

<just_another_day:matrix.org> but you can drop entries from the spreadsheet

then they'd point that out, and flag destruction of evidence/non-compliance

like. they courts would get the spend keys as they already do nowadays

they'll ask for the spend keys anyway

first thing they do in seizures is get keys, export all data, then move wallets

it's like CEXs

<just_another_day:matrix.org> you don't have to disclose the spend key to the court, do you?

uhh yeah you do

<just_another_day:matrix.org> if things are this bad

if that's what it takes, then yes

if they are not certain you have complied? yep

they will go as far as needed

do you think they'll stop before?

no, they'll go as far as they can

<just_another_day:matrix.org> i mean, i lost my wallet in a boating accident

they'll ask you when

then they will assume destruction of evidence/non-compliance

if they are asking for it, they are certain you have had it up till x

if they see that the TX history doesn't match up with the events of your "boating accident"

it'll be even worse

they don't ask things they don't know the answer to :D

<just_another_day:matrix.org> anyway, bringing someone to court is more expensive for them than just asking a view key to get accessed to a cex/merchant

<just_another_day:matrix.org> is it so? how do you know the specific output a ring spends? > <Cindy> if you had everyone's view key, you could track down every XMR down to its codebase transaction

you can correlate TXIDs

it doesn't have to be harder than that

<pyratevevo:matrix.org> Why would you give out the view key to a third party ? > <@just_another_day:matrix.org> this upgrade essentially brings two things:

like you could correlate the change output of a transaction

and then the main output of the same transaction

to find who sent it, and who received it

<just_another_day:matrix.org> i see

(that is, if the transaction has change)

<just_another_day:matrix.org> but it's a flaw of the current system

<just_another_day:matrix.org> fcmp fixes this

<just_another_day:matrix.org> but OVK brings it back

<pyratevevo:matrix.org> How's FCMP++ moving along by the way ? Still on track for some time this year ? > <DataHoarder> tbh as I said, all stuff that is trying to weaken or delay FCMP++/Carrot specially around quantum security is basically playing against Monero

23:40:25 <br-m> <just_another_day:matrix.org> but OVK brings it back

you can have ovk right now or later

even if not added and we lose the ability to migrate to a quantum safe system

they can just make an "exchange-approved" wallet

see stressnet ongoings, soon beta stressnet

they have been fixing old monero issues, not so much fcmp++ issues as the tech debt is showing

<just_another_day:matrix.org> the ability to migrate to a quantum safe system is a strong argument for not delaying anything

<just_another_day:matrix.org> DataHoarder: true. but again, it'll go smoother for them if they get all wallets to automatically support this feature without the need to migrate users to their wallet

<just_another_day:matrix.org> well it seems unrealistic to change the direction at this point

<just_another_day:matrix.org> IMO adding more optional transparency features is a dangerous slippery slope

<just_another_day:matrix.org> thank you for responding to my questions

there is a guy on github who wants optional transparency in monero

<just_another_day:matrix.org> well it's against the core essence of the projects

<just_another_day:matrix.org> i guess many guys in three letter agencies also want this

<kiersten5821:matrix.org> i am starting to agree with this on a directional level, it should be made as hard as possible to surrender your privacy (of course, no clue on a technical level of the feasibility of this)

how hard

do i have to keep exporting key images myself

for an accurate balance on my fundraising wallet?

<just_another_day:matrix.org> think about monero as a digital cash

<just_another_day:matrix.org> if you have a box for physical cash donations

<just_another_day:matrix.org> then you don't have view keys to prove everything

here's the problem

if i take money out of the box

the balance may either appear the same or higher than what's actually in the box

(because change outputs fuck up the balance)

usually key images correct this, but if there isn't any

you are stuck looking at a inaccurate balance

sometimes the balance appears 2x inflated than what is actually in the wallet

<kayabanerve:matrix.org> You will need a new wallet for all benefits of the upgrade. You will not a need wallet to spend your existing outputs via a FCMP, regardless of their age.

<kayabanerve:matrix.org> Old addresses will continue to work and new addresses will look indistinguishable. It's how they're sent to that changes.

<kayabanerve:matrix.org> New wallets have the option of sharing outgoing view keys which allow the holder to calculate a received output's key image, allowing them to detect when it's spent. This can already be reasonably done probabilistically, but now it entirely removes the need to access your private spend key just to sync/restore your bala[... more lines follow, see mrelay.p2pool.observer/e/jvvKtN8KS3lWMUct ]

<just_another_day:matrix.org> i mean, people still have to trust you that you won't misspend the funds from the box

you don't get what i mean

<just_another_day:matrix.org> so you they can also trust you to publish the remaining balance without a cryptographic proof

me taking money out of the box counts as an addition to it

because of change outputs

<kayabanerve:matrix.org> Cindy: Without being able to see spends via identifying key images, it isn't 2x in theory but infx 😅

exactly :P

<kayabanerve:matrix.org> A wallet which constantly sends itself its own balance which constantly appear to be making more and more money.

<kayabanerve:matrix.org> (without doing anything)

i could make my balance look like i have 1000000000 XMR

if i keep sending myself the same amount of XMR over and over again

<kayabanerve:matrix.org> I know that's your point Cindy, just restating a bit due to the confusion.

<plowsof:matrix.org> @kayabanerve:matrix.org: dont expose my kuno fundraising strategy

i know, thanks

<kayabanerve:matrix.org> I have 20m Monero, here's my view key /s

<just_another_day:matrix.org> i wonder can i get negative amount of monero this way

you can't

i think that's one of the proprieties of ring signatures

the amount must be above zero or something

RingCT*

<kayabanerve:matrix.org> Eh. Only showing where you sent Monero, without claiming you received Monero? Any reasonable person would call you out on that

<just_another_day:matrix.org> no i mean cause an overflow in the UI

<just_another_day:matrix.org> by repeatedly transfering the funds to myself

well you need to do that so many times that you'll probably run out of monero from the fees

<kayabanerve:matrix.org> Serai had to design a lot of interesting solutions to achieve accountability when we can't verify when coins are spent _without_ an interactive protocol. OVKs massively simplify such designs. Just any time you want accountability, whether for yourself, for your audience, or for your users, OVKs are _another option_ which can be incredibly useful.

OVKs make it easier to publish an accurate balance

because incoming view keys alone make it easy to overly inflate it

<just_another_day:matrix.org> but in practice a custodial bridge on Hyperliquid has beaten serai by a big margin

<kayabanerve:matrix.org> (Serai doesn't require OVKs and may actually be slow to adopt them due to how we'd have to spend the time updating 😅 )

<kayabanerve:matrix.org> Yes, centralized solutions without review are faster to develop and deploy than decentralized protocols with external review.

<kayabanerve:matrix.org> Should I have not bothered with Serai due to the existence of Kraken?

just_another_day: you mean a proprietary program?

that nobody can audit?

<kayabanerve:matrix.org> They already handle Monero swaps.

<just_another_day:matrix.org> the bridge doesn't require KYC :)

btw, someone had reverse engineered hyperliquid's binary

and discovered there were some backdoors within it

that allowed admins to fake liquidity

and do other shit i couldn't remember

<kayabanerve:matrix.org> Neither do a variety of instaswap services.

<just_another_day:matrix.org> where can I read about it?

<kayabanerve:matrix.org> Until they suddenly go down of have issues, and users are left holding the bag o' liability

<just_another_day:matrix.org> @kayabanerve:matrix.org: instaswap services set a high fee and have less liquidity than HL

<pyratevevo:matrix.org> I think another way to avoid confusion is to refer to the new feature as something other than the loaded "optional transparency".

this is what they found from reverse engineering the node binary that hyperliquid ships out

00:03:25 <br-m> <just_another_day:matrix.org> but in practice a custodial bridge on Hyperliquid has beaten serai by a big margin

it's literally a centralized wallet

<kayabanerve:matrix.org> You are welcome to choose an option you like. I am working on a decentralized option which achieves certain properties I don't believe any existing solution offers. You're welcome to care or not.

^

so yeah.

<pyratevevo:matrix.org> Maybe call it Personal or Local transparency, to better communicate its purpose.

<kayabanerve:matrix.org> It isn't something I have to defend myself on.

kayaba does a lot of hard work

and i like them for doing it

so does DataHoarder

<just_another_day:matrix.org> @kayabanerve:matrix.org: sure. it wasn't a personal attack

<redsh4de:matrix.org> +

<kayabanerve:matrix.org> TBC, I don't feel personally offended. I just want to clarify I think there are reasons for Serai but if you feel other solutions have achieved usable, valuable servicing of users, good for you.

<kayabanerve:matrix.org> It kinda fell into a back and forth but it doesn't have to be.

<kayabanerve:matrix.org> Yeah, allg, we're on the same page there :)

<just_another_day:matrix.org> or have a large balance > <Cindy> well you need to do that so many times that you'll probably run out of monero from the fees

you'll redistribute your XMR to the miner

you are trying to max out 64-bit?

miners*

<just_another_day:matrix.org> yes

DataHoarder: 64-bit from the piconero denomination?

lol

yeah let's take a look

<just_another_day:matrix.org> 16 * 10^18 / 10^12 = 16'000'000

18446744.073709551616

18446744073709551615 generated coins

but

is that correct?

that's 64-bit :P

limit

<just_another_day:matrix.org> so there are more piconeros than 64-bit integer fits?

<just_another_day:matrix.org> in circulation

no

it just means tail emission

hrmm

wait, yeah, the piconeros is a big shift

19 bits

1000000000000 is 39 bits

well, 40 with rounding

a bit above 24 bits of moneros indeed

so yep, more piconeros than 64-bit

<just_another_day:matrix.org> interesting

<just_another_day:matrix.org> does it mean that if someone own all the supply, he wouldn't be able to transfer it in one go?

what's your opinion of payments channels for Monero?

it would be similar to lightning btc network

<just_another_day:matrix.org> imo lightning btc is a failure

<just_another_day:matrix.org> monero should scale onchain

why do we even need this

XMR is so cheap to send?

<ofrnxmr:xmr.mx> xmr is only cheap to send if youre talking about fiat

<ofrnxmr:xmr.mx> And the fees that you're used to, are low-usage fees. Once there is a backlog, to get confirmed, your fees need to be at least 4x as high

there are probably other ways to do L2 than how btc does it

<just_another_day:matrix.org> Ethereum does L2s

<just_another_day:matrix.org> But it has turing-complete VM

dunno about you

<just_another_day:matrix.org> So it's easier for them

<ofrnxmr:xmr.mx> 0.00003 sounds low, but in bitcoin terms thats $3. The fees when there is a backlog is 0.0012 aka $12 at bitcoin value

<just_another_day:matrix.org> can we make the fees lower if monero becomes more expensive?

<ofrnxmr:xmr.mx> Yea. Fees arent consensus, theyre a relay rule

but my last trasaction my fee was 0.0247% of my transaction

<just_another_day:matrix.org> so it's a non-problem then?

even at 4x at 0.1%

i'm okay to pay 1$ to move 1000$

much cheaper than credit cards, bank drafts, cash (cost of visiting an ATM, going to the other party etc,)

for a privacy preserving digital asset

<just_another_day:matrix.org> i guess if monero mentally costs like bitcoin to you, then it could be a problem...

0.1 - 0.025% fees is great

<just_another_day:matrix.org> but then you're rich af

<ofrnxmr:xmr.mx> BoBeR182: Again, its about min $12 per tx at btc volume and valuation

br-m: can you explain how you got that number?

<ofrnxmr:xmr.mx> That means youre paying 12% for a $100 tx, and 2.4% for $500. 2.4% ia about the same as credit

if XMR magically cost more, the fee % still doesn't change

<ofrnxmr:xmr.mx> BoBeR182: 0.00012 xmr for a 1 in 2 out tx

<kiersten5821:matrix.org> you mean $120? > <@ofrnxmr:xmr.mx> 0.00003 sounds low, but in bitcoin terms thats $3. The fees when there is a backlog is 0.0012 aka $12 at bitcoin value

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: I misses a 0. Meant tp say 0.00012

when we 100x our transaction volume, i'm sure new ways of sending transactions will appear

right now it's really really low

seems like this a non issues to everyone unless you're sending under 10$

<kiersten5821:matrix.org> so if the fcmp transactions are 7.2 kb and the block size is still at 300 then it's cooked in terms of tps right?

<just_another_day:matrix.org> the block size is dynamic

<just_another_day:matrix.org> it can grow

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: the blocks expand

<kiersten5821:matrix.org> the last time there was a spam attack it was growing extremely slowly remember

<ofrnxmr:xmr.mx> thats because the spam was at low fees ( 0.0003 for 1in/2out)

<cranial_luminance:matrix.org> is there a way to buy XMR directly with no kyc and with just a prepaid visa card purchased using cash? would be a lot faster than just using cash by mail. think about it: you put some money on a card, someone accepts the offer, you give them the code to the card, you get the XMR.

probably doable on p2p exchanges

<ofrnxmr:xmr.mx> Wallets are supposed to automatically bump up to the "normal" fee tier when there is congestion

but how do you prevent double spends on the credit card

doable on P2P, but very high risk

what if the credit card gets revoked

you give them the code, they can just go into walmart and empty the CC and keep your BTC

XMR*

<ofrnxmr:xmr.mx> In actual numbers, "unimportant" aka low is 20000 piconero per byte, normal is 80000

<ofrnxmr:xmr.mx> @cranial_luminance:matrix.org: Sure but what's stopping the prepaid card from being swept after you get your xmr?

<ofrnxmr:xmr.mx> Its the easiest way to scam people

the multisig

and trader bonds

how do you multisig a creditcard?

oh yeah you mean the card?

yeah that's the problem

<ofrnxmr:xmr.mx> Cindy: That doesnt prevent anything

that's why it's high risk

<ofrnxmr:xmr.mx> Cindy: Yea

so lets say I have a $100 visa gift card

I sell it to you for XMR

then you revoke the card

if it gets spent, how would a 3rd party know it was me or you who spent it

who's scamming who

<ofrnxmr:xmr.mx> I can give you the code to the visa, but i also have the code and i can just spend it 3 seconds after you send me my xmr

<ofrnxmr:xmr.mx> BoBeR182: Exactly. Its the easiest way to scam ppl on p2p, using a gift card