00:00:12
DataHoarder:
currently it was 1/256 on avg
00:00:37
pyratevevo:matrix.org:
I still need to figure out things I'm curious about like the network's hypothetical maximum scale and capacity.
00:02:29
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 https://mrelay.p2pool.observer/e/ssajjd8KWWhNX1Q1 ]
00:04:06
DataHoarder:
"oh no outgoing view key? cool, so next step... yeah give spend keys and we will just look around :)"
00:04:12
jeffro256:
This is also assuming after FCMP++, because they REALLY don't need them before FCMP++ b/c of ring signature tomfoolery
00:04:19
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.
00:04:43
DataHoarder:
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
00:05:07
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
00:05:26
Cindy:
governments will cry if they have to hit you with a wrench over a spend key
00:05:26
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.
00:05:30
Cindy:
instead of a outgoing view key
00:06:17
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.
00:09:16
jeffro256:
Cindy: Either way, it depends on you whether it comes down to the wrench or not. CARROT can't fix a weak mind
00:10:10
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.
00:15:31
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
00:16:50
jeffro256:
6300 is after FCMP++
00:17:13
jeffro256:
Or are you asking about p2p network size ?
00:25:55
pyratevevo:matrix.org:
@jeffro256: Whoa, that's a lot.
00:26:29
pyratevevo:matrix.org:
@jeffro256: I was asking about how the network could handle that m any transactions at the same time.
00:26:35
pyratevevo:matrix.org:
Bandwidth, basically.
01:09:46
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.
01:55:21
elongated:matrix.org:
@just_another_day:matrix.org: Like mymonero did for years
01:55:36
elongated:matrix.org:
Lws should be not be made scalable
07:47:18
monerobull:matrix.org:
yall are insane
07:47:41
monerobull:matrix.org:
btw the niew viewkeys can offload most of the scanning without revealing everything
07:48:31
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
07:49:35
monerobull:matrix.org:
Its not like Monero is going to get relisted to build a fragile net of known viewkeys
07:50:25
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
08:17:43
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.)
08:52:37
kaigoh:gohegan.uk:
@kaigoh:gohegan.uk: https://mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png (image.png)
09:00:22
intr:unredacted.org:
Something like that, yeah
09:25:56
hbs:matrix.org:
@kaigoh:gohegan.uk: "anyone with the key can see" would be more correct
15:11:33
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
15:12:05
ofrnxmr:xmr.mx:
To use carrot features youll need a new seed
15:14:51
kiersten5821:matrix.org:
Unfortunate
15:16:33
pyratevevo:matrix.org:
@kiersten5821:matrix.org: Not required, you can still use the old wallet, albeit without the CARROT features.
15:26:29
DataHoarder:
16:12:54 <br-m> <ofrnxmr:xmr.mx> To use carrot features youll need a new seed
15:26:31
DataHoarder:
to use carrot-native specific features*
15:27:01
DataHoarder:
legacy wallets still use the carrot addressing mode and gain some things, too, just not as much
15:51:30
kiersten5821:matrix.org:
is there like a big doc that will explain everything that changes with fcmp?
15:51:33
kiersten5821:matrix.org:
i searched but couldn't find
15:58:38
ofrnxmr:
Fcmp and carrot are different things
15:58:52
ofrnxmr:
There should be docs for each
16:01:33
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
16:01:52
DataHoarder:
Carrot https://github.com/jeffro256/carrot/blob/master/carrot.md + ongoing https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243
16:01:56
DataHoarder:
Carrot is an addressing mode
16:08:54
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
16:09:33
DataHoarder:
a bit more than that :)
16:09:51
DataHoarder:
I can't remember if we have a single document for FCMP++ part
16:10:22
DataHoarder:
but you can peek around in my stressnet block explorer https://stressnet.p2pool.observer/ that has the current changes (and we are testing FCMP++/Carrot)
16:10:28
DataHoarder:
you can compare tx sizes
16:12:09
ofrnxmr:
@kiersten5821:matrix.org: 2 in 2 out is about 7.3kb iirc
16:12:49
ofrnxmr:
https://stressnet.p2pool.observer/tx/3ec7827d3241708fc95af81353d79fb101bf6b30d5f871e7349ed98c55097b01
16:14:25
kiersten5821:matrix.org:
DataHoarder: thanks, really cool
16:19:09
rucknium:
@kiersten5821:matrix.org: Are you trying to build something with Monero?
16:21:38
uncle_rae:
anyone here used haveno on tails?
16:30:34
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
16:33:09
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
16:34:19
rucknium:
Want to give any hints about what you're building or will it be a surprise later? :)
16:35:13
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
16:38:55
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
16:52:01
rucknium:
@kiersten5821:matrix.org: FROSTLASS is an alternative multisig protocol for Monero: https://github.com/monero-oxide/monero-oxide/tree/main/audits/FROSTLASS
17:04:32
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.
17:04:32
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 https://www.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 https://mrelay.p2pool.observer/e/-KvCqt8KLTR1WjhZ ]
17:04:33
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 https://mrelay.p2pool.observer/e/-KvCqt8KLTR1WjhZ ]
17:10:16
pyratevevo:matrix.org:
@kiersten5821:matrix.org: Would like to see the answers to all these questions too, in a user friendly format.
20:44:36
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
20:45:18
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
20:47:31
intr:unredacted.org:
I might be wrong but I don't believe the full view key is actually necessary for LWS
20:47:34
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
20:48:37
sgp_:
good luck regularly syncing a full-local-sync wallet with a Tor node. It's slow
20:48:48
just_another_day:matrix.org:
@sgp_: Does this mean MyMonero's decision to step down was wrong?
20:49:13
sgp_:
no, I'm just saying I love self hosting my own LWS :)
20:50:13
Cindy:
how necessary is it to sync fully if you already know you haven't gotten any new outputs since the last time you synced
20:50:23
sgp_:
so much so that MAGIC built our own wallet for it :p
20:50:44
sgp_:
Cindy: you need to sync to spend, at least at a high level
20:50:59
Cindy:
is it for decoy selection?
20:51:08
sgp_:
there are workarounds, but no wallets use those
20:51:18
sgp_:
at least no wallet I would recommend
20:51:32
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
20:51:33
Cindy:
or just checking if the key images associated with the outputs have been spent
20:53:24
sgp_:
@intr:unredacted.org: are you on the latest skylight release, and did you install LWS recently? LWS only recently supported subaddresses correctly*
20:53:24
sgp_:
*there are still some quirks, but far fewer than there were a few months ago
20:53:49
intr:unredacted.org:
yeah, monero-lws is lastest checkout, skylight is latest github release
20:53:57
intr:unredacted.org:
latest as in, uhhh, 5 hours ago
20:54:00
just_another_day:matrix.org:
IIRC there was a proposal for probabilistic view keys for light wallets that filter out 255/256 outputs
20:54:07
just_another_day:matrix.org:
is it still a thing?
20:54:26
intr:unredacted.org:
I can see from the logs from monero-lws that it's not allowing subaddresses
20:54:32
sgp_:
if you bump the lookahead to 20k, let me know if you still see issues with subaddresses
20:54:34
intr:unredacted.org:
but I have no idea if it's a skylight issue or monero-lws issue
20:54:39
intr:unredacted.org:
I'll try that, thank you
20:55:06
sgp_:
no ty for the report and testing it out
20:55:20
intr:unredacted.org:
give me just a few mins
20:57:13
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 😅
20:57:15
DataHoarder:
21:51:48 <Cindy> is it for decoy selection?
20:57:17
DataHoarder:
for a wallet, or for a node?
20:57:19
DataHoarder:
wallet asks node for decoys
20:57:27
DataHoarder:
and ofc, for checking spent key images
20:57:51
DataHoarder:
but wallet syncing doesn't build up its own decoy db
20:57:53
DataHoarder:
it only tracks its own state
20:57:55
DataHoarder:
that's why you can "skip sync" at a specific height
20:59:18
ofrnxmr:xmr.mx:
@kiersten5821:matrix.org: Beta.monerodevs.org those user guides are essentially deprecated
20:59:56
ofrnxmr:xmr.mx:
The new keys are only relevant for new carrot wallets
21:00:18
ofrnxmr:xmr.mx:
The new address type is not visibly distinguishable from old ones
21:01:04
sgp_:
max_subaddresses in config
21:01:25
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
21:01:51
intr:unredacted.org:
oh that is the same thing, fuck me, sorry
21:02:46
just_another_day:matrix.org:
> they cannot see who sent the money, etc > <@kaigoh:gohegan.uk> https://mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png (image.png)
21:02:46
just_another_day:matrix.org:
> unless the sender has shared their view key as well
21:02:54
ofrnxmr:xmr.mx:
the servers default is 50:200 (50 accounts with 200 addresses = 10000 minimum)
21:07:43
intr:unredacted.org:
gotcha, so I deleted the old monero lws database, cleared the wallet from skylight, recreated it, accepted the request
21:08:37
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
21:09:06
intr:unredacted.org:
I'm also noticing a little bar below the wallet balance that's stuck loading
21:09:21
intr:unredacted.org:
it's connecting over my lan, no tor
21:11:39
sgp_:
@intr:unredacted.org: do you select "No Tor" in Tor settings?
21:11:50
intr:unredacted.org:
Yes, that's correct
21:12:03
DataHoarder:
22:03:35 <br-m> <just_another_day:matrix.org> > unless the sender has shared their view key as well
21:12:06
intr:unredacted.org:
it's showing the "no tor" icon below the connected checkmark
21:12:15
DataHoarder:
they cannot see that
21:12:35
DataHoarder:
not directly
21:12:47
just_another_day:matrix.org:
what do you mean?
21:12:48
DataHoarder:
but you can replace view key with "cex"
21:12:51
intr:unredacted.org:
@sgp_:monero.social we can continue this in DM if you prefer
21:13:26
ofrnxmr:xmr.mx:
#skylight-wallet:monero.social
21:13:29
sgp_:
can you join #skylight-wallet:monero.social ? That's the best place for this discussion
21:13:30
DataHoarder:
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
21:14:15
DataHoarder:
not carrot, today too
21:14:27
DataHoarder:
FCMP however does cover this
21:15:43
basses:matrix.org:
@sgp_: why this link is not in readme?
21:17:14
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")
21:17:44
DataHoarder:
FCMP++ is about removing rings
21:17:58
DataHoarder:
you don't need view keys, CEX can do this with outputs they sent you
21:18:26
DataHoarder:
if you sweep multiple of these at the same time in same tx, they can statistically attribute these back
21:18:28
just_another_day:matrix.org:
this isn't only about CEX, merchants can also be pressured to require view keys from clients
21:19:25
DataHoarder:
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
21:19:35
DataHoarder:
without view keys. you don't have to bring them to the conversation
21:19:59
DataHoarder:
it's hard to do, but on certain conditions you could pass this along and tag the outputs of the next tx
21:20:25
just_another_day:matrix.org:
will it be the case with fcmp?
21:20:25
DataHoarder:
it still doesn't give you information on its own, attribution is what they are looking for
21:20:31
DataHoarder:
no, fcmp++ removes rings
21:20:50
DataHoarder:
so you cannot do stuff like https://p2pool.observer/sweeps
21:21:13
just_another_day:matrix.org:
this is great
21:21:26
DataHoarder:
(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)
21:21:49
just_another_day:matrix.org:
but when fcmp is implemented, view keys become relevant
21:21:54
sgp_:
@basses:matrix.org: no good reason. omission
21:22:19
DataHoarder:
suddenly they NEED them to accomplish stuff like this, besides tracking source ips that dandelion++ attempts to make hard
21:22:49
DataHoarder:
or at least, attribution. they don't need keys
21:22:54
DataHoarder:
they may ask for a list of txid and "is this yours"
21:23:22
DataHoarder:
remember you can't outdumb this, they care about the end result not how it gets there
21:24:06
DataHoarder:
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
21:24:32
DataHoarder:
and they can assume you providing these no more = you failed at providing and are evading
21:27:54
DataHoarder:
or, they ask for a spend key via some third party "safe system" :D
21:28:34
DataHoarder:
even worse, forced to do multisig with them!
21:30:49
just_another_day:matrix.org:
it's harder for them to ask for a spend key
21:31:08
just_another_day:matrix.org:
the right to self-custody is relatively well-established
21:31:17
just_another_day:matrix.org:
but the right to privacy isn't
21:32:02
just_another_day:matrix.org:
it's really a question of how many people will choose to comply with a specific request
21:32:25
just_another_day:matrix.org:
i didn't get the "provide proofs" part
21:32:33
DataHoarder:
tx proofs
21:32:47
DataHoarder:
it can establish when you received funds like a view key
21:32:55
DataHoarder:
you can generate these with a view key, too
21:32:56
just_another_day:matrix.org:
but how do they know what tx i have made
21:33:47
DataHoarder:
I'm assuming you gave them a no-balance view key (like a legacy wallet one)
21:33:58
DataHoarder:
so they know when you receive funds, or someone else sent them to you and they know
21:34:11
kiersten5821:matrix.org:
i think he means the system shouldn't have view keys at all, like cash
21:34:19
DataHoarder:
they can ask for key image of each one
21:34:50
DataHoarder:
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
21:35:48
DataHoarder:
as an example from last conversation https://blocks.p2pool.observer/tx/9c78c972c295f31cf3b30240a22c300aff96ac9d4bd886ef96639fcf3b328271
21:36:19
DataHoarder:
they know you received a transaction in 9c78c972c295f31cf3b30240a22c300aff96ac9d4bd886ef96639fcf3b328271, they may or may not have view key for it
21:36:27
DataHoarder:
they can ask for an InProof that shows you indeed received it
21:36:30
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
21:36:34
DataHoarder:
and for you to provide key images
21:36:43
just_another_day:matrix.org:
and only one time for a full view key
21:36:53
DataHoarder:
yes. they'd force this and non-compliance would be same as you moving elsewhere
21:37:03
DataHoarder:
so on https://mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png
21:37:25
DataHoarder:
"forced to share" it means the same that you got view keys or not
21:37:36
DataHoarder:
you should switch wallets
21:37:52
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
21:38:26
DataHoarder:
this is important specially around a PQ Turnstile https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243
21:38:28
DataHoarder:
which explicitly needs the generate image key
21:38:45
just_another_day:matrix.org:
like, currently many wallets don't even support exporting key images
21:38:58
Cindy:
i hate whenever i make a transaction, i have to export the key images
21:39:05
DataHoarder:
you can import seed elsewhere :')
21:39:14
Cindy:
or give the server my spend key (which is retarded)
21:39:15
just_another_day:matrix.org:
if someone asks to do so, most users will just go to another merchant
21:39:28
DataHoarder:
again, they will put the burden on you
21:39:30
Cindy:
this is just for a fundraising wallet
21:39:31
DataHoarder:
they don't care
21:39:32
DataHoarder:
Cindy: multisig too :D
21:39:35
moneromoooo:
That (we should make the compliance as cumbersome as possible so that it's harder) is an interesting way to see it.
21:39:35
just_another_day:matrix.org:
but when we have a single button "make regulators happy", most will just press it
21:40:01
DataHoarder:
legacy wallets as they exist keep being supported
21:40:05
Cindy:
if i could have an outgoing view key, i would publish that in a heartbeat
21:40:09
Cindy:
rather than having to stick with a hack
21:40:14
Cindy:
for my fundraising wallet
21:40:15
moneromoooo:
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.
21:40:31
DataHoarder:
compliance as cumbersome -> also means you make using monero as cumbersome
21:40:33
DataHoarder:
so it can't be used efficiently for multisig, used with cold spend keys
21:40:35
moneromoooo:
Then making it hard to do will just mean fewer people will use monero.
21:41:03
DataHoarder:
which also means cycling wallets is harder
21:41:15
just_another_day:matrix.org:
i'll copy my comment from reddit
21:41:16
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".
21:41:18
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 https://mrelay.p2pool.observer/e/hfK3st8KMXNyUlpE ]
21:41:18
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.
21:41:19
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 https://mrelay.p2pool.observer/e/hfK3st8KMXNyUlpE ]
21:41:33
DataHoarder:
and again, it's not making it transparent and sharing these no longer allows looking at ring elimination as a risk factor
21:41:34
Cindy:
yeah, outgoing viewkeys would make multisig easier
21:41:36
DataHoarder:
(FCMP++)
21:41:48
kiersten5821:matrix.org:
wait, this will cook my multisig setup?
21:41:50
moneromoooo:
In case of coercion, what counts is outright impossibility.
21:42:06
DataHoarder:
there's already a one-click option, give seed wallet, and users comply for the scams :P
21:42:22
Cindy:
with outgoing view keys, everyone automatically gets the latest key iages
21:42:24
Cindy:
images*
21:42:28
moneromoooo:
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.
21:42:36
DataHoarder:
22:42:37 <br-m> <kiersten5821:matrix.org> wait, this will cook my multisig setup?
21:42:38
DataHoarder:
without ability to generate key images internally you can't see what's spent
21:42:40
DataHoarder:
without importing key images or making rounds for all participants
21:43:11
DataHoarder:
this also simplifies hardware wallets, too
21:43:41
DataHoarder:
which many can't export key images too
21:43:43
just_another_day:matrix.org:
but hardware wallets already work well, don't they?
21:43:50
moneromoooo:
The salient point here is whether the party bearing the pain is the one making hte decision.
21:44:15
DataHoarder:
they don't work well, specially if you need to know balances
21:44:17
DataHoarder:
for that you need to have them online
21:44:40
elongated:matrix.org:
@just_another_day:matrix.org: It’s not easy, you need the device connected while wallet syncs
21:44:45
DataHoarder:
not offline
21:44:48
DataHoarder:
you need to do this ... on each device you want to keep track of this
21:44:52
DataHoarder:
connect, sync, etc.
21:45:20
DataHoarder:
you can extract view keys atm, but that still gives no balance
21:45:47
just_another_day:matrix.org:
when i'm using a hw, i just plug it when I want to interact with the wallet
21:46:00
kiersten5821:matrix.org:
i remember a long time ago i was using an airgapped setup
21:46:03
kiersten5821:matrix.org:
and the importation thing cooked me
21:46:11
kiersten5821:matrix.org:
and suddenly it couldn't send anything lol
21:46:15
just_another_day:matrix.org:
For other coins too
21:46:20
kiersten5821:matrix.org:
so much more complicated than bitcoin
21:46:43
elongated:matrix.org:
@just_another_day:matrix.org: For other coins you just need to connect when you want to sign a tx
21:46:48
DataHoarder:
how would a merchant know their balance in hw wallet in cold storage?
21:46:50
DataHoarder:
you putting it online is a no-no
21:47:15
just_another_day:matrix.org:
@elongated:matrix.org: no. You need to get the address from the hw wallet too
21:47:21
DataHoarder:
that is no longer a "cold storage" setup
21:47:23
DataHoarder:
^
21:47:33
just_another_day:matrix.org:
to receive funds to it
21:47:42
just_another_day:matrix.org:
or maybe the saved address was altered
21:47:51
just_another_day:matrix.org:
if you don't reverify it
21:47:53
DataHoarder:
it makes all offline and multisig work as intended
21:47:55
DataHoarder:
nope
21:47:57
DataHoarder:
wallet extracts view key
21:48:01
DataHoarder:
nope
21:48:29
DataHoarder:
that is an extra check
21:48:31
just_another_day:matrix.org:
i'm talking about other coins
21:48:57
just_another_day:matrix.org:
like ledger app doesn't allow you to receive funds without plugging the hw wallet
21:49:00
DataHoarder:
if you copy these elsewhere like bitcoin xpub, you can generate the full tree
21:49:02
DataHoarder:
this is also how electrum or so work with wallets
21:49:04
DataHoarder:
and how multisig works. you can generate it all ahead of time
21:49:12
just_another_day:matrix.org:
because you need to check the address on the device
21:49:32
DataHoarder:
across all members, then ask for sigs
21:49:34
DataHoarder:
for monero: if you have the main address + view key, you can generate the account trees
21:52:25
DataHoarder:
that feature is broken on current hw wallets in monero btw when sending funds to integrated addresses
21:55:02
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".
21:57:03
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
22:02:53
DataHoarder:
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)
22:03:36
Cindy:
the second people with quantum computers counterfeit coins
22:03:39
Cindy:
monero becomes dead
22:04:57
just_another_day:matrix.org:
DataHoarder: are outgoing view keys required for migration?
22:05:05
DataHoarder:
yes, see my previous link
22:05:50
DataHoarder:
well, they would be frozen before that. then turnstile would allow migrations to happen, then frozen
22:05:52
DataHoarder:
https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243
22:06:57
DataHoarder:
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
22:07:21
DataHoarder:
"generate key image" is that just_another_day
22:07:35
DataHoarder:
generate key image + view incoming key = view balance wallet
22:07:51
Cindy:
monero being quantum-safe is really really important
22:08:02
DataHoarder:
see hierarchy https://github.com/jeffro256/carrot/blob/master/carrot.md#52-new-key-hierarchy
22:08:04
DataHoarder:
vs old
22:08:05
just_another_day:matrix.org:
i agree with that
22:08:35
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
22:08:54
DataHoarder:
it might not be safe now Cindy but this is what allows a migration and not a restart
22:08:57
DataHoarder:
it's required for migrating the outputs
22:09:04
DataHoarder:
not after
22:09:12
plowsof:matrix.org:
can i deposit funds to subaddress infinity+1 to hide from quantum hackers
22:09:24
Cindy:
DataHoarder: at a certain point, does migration become impossible?
22:09:29
DataHoarder:
read gist :)
22:09:52
Cindy:
you're my AI!!!
22:09:54
Cindy:
i mean
22:09:56
Cindy:
i'll read i guess
22:09:59
DataHoarder:
again what it says there is not set in stone (they way it'd work)
22:10:00
Cindy:
>_>
22:10:30
DataHoarder:
> i just don't understand why a key that allows viewing balance
22:10:31
DataHoarder:
because it allows proving you control certain outputs in a quantum opponent safe way
22:11:01
DataHoarder:
as the derivation chain is not something a quantum opponent can walk backwards
22:11:32
DataHoarder:
you also need to prove the key image is not spent
22:11:34
DataHoarder:
quantum opponents could fake this for any output otherwise
22:11:55
Cindy:
smh, i can't get unlimited free monero hack
22:12:00
Cindy:
damn you jeffro
22:12:01
Cindy:
and DataHoarder
22:14:46
intr:unredacted.org:
hey kid, want some Quantum Monero ™
22:15:50
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
22:16:04
DataHoarder:
you can do this already
22:16:23
DataHoarder:
you can generate random target addresses with random spend/view keys
22:16:25
DataHoarder:
then scan for them
22:16:37
DataHoarder:
no seeds, all randomly generated
22:17:24
DataHoarder:
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
22:17:33
DataHoarder:
ofc, no hw wallets
22:17:38
DataHoarder:
also it's all online/live!
22:18:35
just_another_day:matrix.org:
yeah this trade-off is obviously in favor of current system
22:22:20
just_another_day:matrix.org:
this upgrade essentially brings two things:
22:22:20
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)
22:22:20
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)
22:22:43
Cindy:
no you can
22:22:49
Cindy:
just sweep all to another wallet
22:23:06
Cindy:
don't disclose your keys
22:23:16
just_another_day:matrix.org:
no i mean the passive monitoring impossible
22:23:37
just_another_day:matrix.org:
unless we count statistical heuristics as a feature
22:24:56
DataHoarder:
> unless you change the address (which is currently impossible)
22:25:09
elongated:matrix.org:
Dude if you are forced to give keys, you stop using that wallet
22:25:10
DataHoarder:
that'd mean changing that key, which makes all addresses generated invalid
22:25:23
DataHoarder:
and also makes the seed words invalid
22:25:33
Cindy:
i don't get the people being worried
22:25:45
Cindy:
when i generated my wallet, there wasn't a creep breathing down my neck for the view key
22:25:54
elongated:matrix.org:
Cindy: Same gang coming from z
22:26:24
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
22:26:28
Cindy:
also btw, you could do this in the same system
22:26:33
DataHoarder:
Jamtis also had this
22:26:37
DataHoarder:
Carrot had this
22:26:45
DataHoarder:
today you could be forced to do this too
22:26:46
Cindy:
if a hypothetical authority forced everyone to give up their view key (CryptoNote scheme)
22:26:58
Cindy:
they could correlate transactions from everyone
22:27:01
DataHoarder:
(Carrot-native could exist *today* but they aren't bothering)
22:27:01
Cindy:
no outgoing view key needed
22:27:10
DataHoarder:
some chains are already using Carrot as-is
22:27:17
Cindy:
just match up TXIDs
22:27:38
DataHoarder:
Cindy: or they could ask people to make such key in an exchange compliant wallet (tm)
22:28:21
DataHoarder:
carrot is an addressing system, which is entirely local to your wallet to some degree
22:28:23
DataHoarder:
you can ... basically make a different one for your own usecase
22:28:41
DataHoarder:
for example for a subset of p2pool outputs I'm looking at that, and it's compatible with the network
22:29:33
Cindy:
if you had everyone's view key, you could track down every XMR down to its codebase transaction
22:29:42
Cindy:
so i don't get this argument
22:29:53
Cindy:
if this is the reason OVKs are bad, then why haven't they done it now
22:30:08
DataHoarder:
^ cause generating a new wallet and sweeping is too easy
22:30:51
DataHoarder:
when they have to they will just bring the book on you and either you comply or else
22:30:53
DataHoarder:
and you can comply in many ways regardless how you have set it up
22:31:00
DataHoarder:
including givin just an excel spreadsheet :')
22:31:30
just_another_day:matrix.org:
but you can drop entries from the spreadsheet
22:31:56
DataHoarder:
then they'd point that out, and flag destruction of evidence/non-compliance
22:32:35
DataHoarder:
like. they courts would get the spend keys as they already do nowadays
22:32:53
Cindy:
they'll ask for the spend keys anyway
22:32:55
DataHoarder:
first thing they do in seizures is get keys, export all data, then move wallets
22:33:01
Cindy:
it's like CEXs
22:33:30
just_another_day:matrix.org:
you don't have to disclose the spend key to the court, do you?
22:33:37
Cindy:
uhh yeah you do
22:33:47
just_another_day:matrix.org:
if things are this bad
22:33:48
Cindy:
if that's what it takes, then yes
22:33:53
DataHoarder:
if they are not certain you have complied? yep
22:33:59
DataHoarder:
they will go as far as needed
22:34:09
Cindy:
do you think they'll stop before?
22:34:15
Cindy:
no, they'll go as far as they can
22:34:23
just_another_day:matrix.org:
i mean, i lost my wallet in a boating accident
22:34:41
Cindy:
they'll ask you when
22:34:42
DataHoarder:
then they will assume destruction of evidence/non-compliance
22:35:06
DataHoarder:
if they are asking for it, they are certain you have had it up till x
22:35:08
Cindy:
if they see that the TX history doesn't match up with the events of your "boating accident"
22:35:11
Cindy:
it'll be even worse
22:35:27
DataHoarder:
they don't ask things they don't know the answer to :D
22:35:35
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
22:36:51
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
22:37:09
Cindy:
you can correlate TXIDs
22:37:15
Cindy:
it doesn't have to be harder than that
22:37:20
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:
22:38:16
Cindy:
like you could correlate the change output of a transaction
22:38:24
Cindy:
and then the main output of the same transaction
22:38:40
Cindy:
to find who sent it, and who received it
22:38:43
just_another_day:matrix.org:
i see
22:38:45
Cindy:
(that is, if the transaction has change)
22:39:20
just_another_day:matrix.org:
but it's a flaw of the current system
22:39:30
just_another_day:matrix.org:
fcmp fixes this
22:39:36
just_another_day:matrix.org:
but OVK brings it back
22:39:53
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
22:40:22
DataHoarder:
23:40:25 <br-m> <just_another_day:matrix.org> but OVK brings it back
22:40:24
DataHoarder:
you can have ovk right now or later
22:40:27
DataHoarder:
even if not added and we lose the ability to migrate to a quantum safe system
22:40:37
DataHoarder:
they can just make an "exchange-approved" wallet
22:40:58
DataHoarder:
see stressnet ongoings, soon beta stressnet
22:41:28
DataHoarder:
they have been fixing old monero issues, not so much fcmp++ issues as the tech debt is showing
22:41:40
just_another_day:matrix.org:
the ability to migrate to a quantum safe system is a strong argument for not delaying anything
22:44:16
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
22:45:59
just_another_day:matrix.org:
well it seems unrealistic to change the direction at this point
22:46:16
just_another_day:matrix.org:
IMO adding more optional transparency features is a dangerous slippery slope
22:46:44
just_another_day:matrix.org:
thank you for responding to my questions
22:47:22
Cindy:
there is a guy on github who wants optional transparency in monero
22:47:54
just_another_day:matrix.org:
well it's against the core essence of the projects
22:48:19
just_another_day:matrix.org:
i guess many guys in three letter agencies also want this
22:48:45
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)
22:50:12
Cindy:
how hard
22:50:56
Cindy:
do i have to keep exporting key images myself
22:51:05
Cindy:
for an accurate balance on my fundraising wallet?
22:52:41
just_another_day:matrix.org:
think about monero as a digital cash
22:52:54
just_another_day:matrix.org:
if you have a box for physical cash donations
22:53:05
just_another_day:matrix.org:
then you don't have view keys to prove everything
22:53:09
Cindy:
here's the problem
22:53:16
Cindy:
if i take money out of the box
22:53:33
Cindy:
the balance may either appear the same or higher than what's actually in the box
22:53:47
Cindy:
(because change outputs fuck up the balance)
22:53:56
Cindy:
usually key images correct this, but if there isn't any
22:54:04
Cindy:
you are stuck looking at a inaccurate balance
22:54:28
Cindy:
sometimes the balance appears 2x inflated than what is actually in the wallet
22:56:24
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.
22:56:24
kayabanerve:matrix.org:
Old addresses will continue to work and new addresses will look indistinguishable. It's how they're sent to that changes.
22:56:24
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 https://mrelay.p2pool.observer/e/jvvKtN8KS3lWMUct ]
22:56:25
just_another_day:matrix.org:
i mean, people still have to trust you that you won't misspend the funds from the box
22:56:56
Cindy:
you don't get what i mean
22:57:00
just_another_day:matrix.org:
so you they can also trust you to publish the remaining balance without a cryptographic proof
22:57:08
Cindy:
me taking money out of the box counts as an addition to it
22:57:14
Cindy:
because of change outputs
22:57:37
kayabanerve:matrix.org:
Cindy: Without being able to see spends via identifying key images, it isn't 2x in theory but infx 😅
22:57:46
Cindy:
exactly :P
22:57:53
kayabanerve:matrix.org:
A wallet which constantly sends itself its own balance which constantly appear to be making more and more money.
22:57:59
kayabanerve:matrix.org:
(without doing anything)
22:58:00
Cindy:
i could make my balance look like i have 1000000000 XMR
22:58:09
Cindy:
if i keep sending myself the same amount of XMR over and over again
22:58:11
kayabanerve:matrix.org:
I know that's your point Cindy, just restating a bit due to the confusion.
22:58:20
plowsof:matrix.org:
@kayabanerve:matrix.org: dont expose my kuno fundraising strategy
22:58:22
Cindy:
i know, thanks
22:58:39
kayabanerve:matrix.org:
I have 20m Monero, here's my view key /s
22:59:15
just_another_day:matrix.org:
i wonder can i get negative amount of monero this way
22:59:26
Cindy:
you can't
22:59:38
Cindy:
i think that's one of the proprieties of ring signatures
22:59:44
Cindy:
the amount must be above zero or something
22:59:50
Cindy:
RingCT*
22:59:56
kayabanerve:matrix.org:
Eh. Only showing where you sent Monero, without claiming you received Monero? Any reasonable person would call you out on that
23:00:07
just_another_day:matrix.org:
no i mean cause an overflow in the UI
23:00:27
just_another_day:matrix.org:
by repeatedly transfering the funds to myself
23:00:53
Cindy:
well you need to do that so many times that you'll probably run out of monero from the fees
23:01:06
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.
23:02:18
Cindy:
OVKs make it easier to publish an accurate balance
23:02:30
Cindy:
because incoming view keys alone make it easy to overly inflate it
23:02:36
just_another_day:matrix.org:
but in practice a custodial bridge on Hyperliquid has beaten serai by a big margin
23:03:01
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 😅 )
23:03:31
kayabanerve:matrix.org:
Yes, centralized solutions without review are faster to develop and deploy than decentralized protocols with external review.
23:03:47
kayabanerve:matrix.org:
Should I have not bothered with Serai due to the existence of Kraken?
23:03:51
Cindy:
just_another_day: you mean a proprietary program?
23:03:59
Cindy:
that nobody can audit?
23:04:01
kayabanerve:matrix.org:
They already handle Monero swaps.
23:04:05
just_another_day:matrix.org:
the bridge doesn't require KYC :)
23:04:23
Cindy:
btw, someone had reverse engineered hyperliquid's binary
23:04:30
Cindy:
and discovered there were some backdoors within it
23:04:35
Cindy:
that allowed admins to fake liquidity
23:04:40
Cindy:
and do other shit i couldn't remember
23:04:45
kayabanerve:matrix.org:
Neither do a variety of instaswap services.
23:04:55
just_another_day:matrix.org:
where can I read about it?
23:05:00
kayabanerve:matrix.org:
Until they suddenly go down of have issues, and users are left holding the bag o' liability
23:05:16
just_another_day:matrix.org:
@kayabanerve:matrix.org: instaswap services set a high fee and have less liquidity than HL
23:05:22
Cindy:
https://blog.can.ac/2025/12/20/reverse-engineering-hyperliquid/
23:05:29
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".
23:05:43
Cindy:
this is what they found from reverse engineering the node binary that hyperliquid ships out
23:05:55
DataHoarder:
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
23:05:57
DataHoarder:
it's literally a centralized wallet
23:06:03
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.
23:06:03
Cindy:
^
23:06:05
DataHoarder:
so yeah.
23:06:11
pyratevevo:matrix.org:
Maybe call it Personal or Local transparency, to better communicate its purpose.
23:06:18
kayabanerve:matrix.org:
It isn't something I have to defend myself on.
23:06:28
Cindy:
kayaba does a lot of hard work
23:06:32
Cindy:
and i like them for doing it
23:06:35
Cindy:
so does DataHoarder
23:08:39
just_another_day:matrix.org:
@kayabanerve:matrix.org: sure. it wasn't a personal attack
23:08:43
redsh4de:matrix.org:
+
23:09:07
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.
23:09:16
kayabanerve:matrix.org:
It kinda fell into a back and forth but it doesn't have to be.
23:09:40
kayabanerve:matrix.org:
Yeah, allg, we're on the same page there :)
23:12:21
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
23:12:53
Cindy:
you'll redistribute your XMR to the miner
23:12:54
DataHoarder:
you are trying to max out 64-bit?
23:12:55
Cindy:
miners*
23:13:12
just_another_day:matrix.org:
yes
23:13:17
Cindy:
DataHoarder: 64-bit from the piconero denomination?
23:13:25
DataHoarder:
lol
23:13:31
DataHoarder:
yeah let's take a look
23:14:01
just_another_day:matrix.org:
16 * 10^18 / 10^12 = 16'000'000
23:14:07
Cindy:
18446744.073709551616
23:14:25
DataHoarder:
18446744073709551615 generated coins
23:14:32
DataHoarder:
but
23:14:34
Cindy:
is that correct?
23:14:37
DataHoarder:
that's 64-bit :P
23:14:41
DataHoarder:
limit
23:15:30
just_another_day:matrix.org:
so there are more piconeros than 64-bit integer fits?
23:15:38
just_another_day:matrix.org:
in circulation
23:15:59
DataHoarder:
no
23:16:01
DataHoarder:
it just means tail emission
23:17:13
DataHoarder:
hrmm
23:17:30
DataHoarder:
wait, yeah, the piconeros is a big shift
23:17:32
DataHoarder:
19 bits
23:18:10
DataHoarder:
1000000000000 is 39 bits
23:18:32
DataHoarder:
well, 40 with rounding
23:19:03
DataHoarder:
a bit above 24 bits of moneros indeed
23:19:04
DataHoarder:
so yep, more piconeros than 64-bit
23:19:27
just_another_day:matrix.org:
interesting
23:22:54
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?
23:31:46
xmr_guyy:
https://github.com/grease-xmr/grease
23:32:26
xmr_guyy:
what's your opinion of payments channels for Monero?
23:33:14
xmr_guyy:
it would be similar to lightning btc network
23:35:12
just_another_day:matrix.org:
imo lightning btc is a failure
23:35:37
just_another_day:matrix.org:
monero should scale onchain
23:44:52
BoBeR182:
why do we even need this
23:44:57
BoBeR182:
XMR is so cheap to send?
23:45:37
ofrnxmr:xmr.mx:
xmr is only cheap to send if youre talking about fiat
23:46:30
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
23:46:48
nioc:
there are probably other ways to do L2 than how btc does it
23:47:10
just_another_day:matrix.org:
Ethereum does L2s
23:47:24
just_another_day:matrix.org:
But it has turing-complete VM
23:47:32
BoBeR182:
dunno about you
23:47:39
just_another_day:matrix.org:
So it's easier for them
23:47:40
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
23:48:20
just_another_day:matrix.org:
can we make the fees lower if monero becomes more expensive?
23:48:42
ofrnxmr:xmr.mx:
Yea. Fees arent consensus, theyre a relay rule
23:49:08
BoBeR182:
but my last trasaction my fee was 0.0247% of my transaction
23:49:12
just_another_day:matrix.org:
so it's a non-problem then?
23:49:34
BoBeR182:
even at 4x at 0.1%
23:49:43
BoBeR182:
i'm okay to pay 1$ to move 1000$
23:50:09
BoBeR182:
much cheaper than credit cards, bank drafts, cash (cost of visiting an ATM, going to the other party etc,)
23:50:18
BoBeR182:
for a privacy preserving digital asset
23:50:24
just_another_day:matrix.org:
i guess if monero mentally costs like bitcoin to you, then it could be a problem...
23:50:28
BoBeR182:
0.1 - 0.025% fees is great
23:50:31
just_another_day:matrix.org:
but then you're rich af
23:50:54
ofrnxmr:xmr.mx:
BoBeR182: Again, its about min $12 per tx at btc volume and valuation
23:51:09
BoBeR182:
br-m: can you explain how you got that number?
23:51:21
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
23:51:33
BoBeR182:
if XMR magically cost more, the fee % still doesn't change
23:51:52
ofrnxmr:xmr.mx:
BoBeR182: 0.00012 xmr for a 1 in 2 out tx
23:51:57
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
23:52:30
ofrnxmr:xmr.mx:
@kiersten5821:matrix.org: I misses a 0. Meant tp say 0.00012
23:52:34
BoBeR182:
when we 100x our transaction volume, i'm sure new ways of sending transactions will appear
23:52:38
BoBeR182:
right now it's really really low
23:52:57
BoBeR182:
seems like this a non issues to everyone unless you're sending under 10$
23:53:02
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?
23:53:32
just_another_day:matrix.org:
the block size is dynamic
23:53:36
just_another_day:matrix.org:
it can grow
23:53:47
ofrnxmr:xmr.mx:
@kiersten5821:matrix.org: the blocks expand
23:53:53
kiersten5821:matrix.org:
the last time there was a spam attack it was growing extremely slowly remember
23:54:23
ofrnxmr:xmr.mx:
thats because the spam was at low fees ( 0.0003 for 1in/2out)
23:54:40
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.
23:55:05
BoBeR182:
probably doable on p2p exchanges
23:55:07
ofrnxmr:xmr.mx:
Wallets are supposed to automatically bump up to the "normal" fee tier when there is congestion
23:55:13
BoBeR182:
but how do you prevent double spends on the credit card
23:55:16
Cindy:
doable on P2P, but very high risk
23:55:24
Cindy:
what if the credit card gets revoked
23:55:32
BoBeR182:
you give them the code, they can just go into walmart and empty the CC and keep your BTC
23:55:36
BoBeR182:
XMR*
23:55:38
ofrnxmr:xmr.mx:
In actual numbers, "unimportant" aka low is 20000 piconero per byte, normal is 80000
23:56:34
ofrnxmr:xmr.mx:
@cranial_luminance:matrix.org: Sure but what's stopping the prepaid card from being swept after you get your xmr?
23:56:48
ofrnxmr:xmr.mx:
Its the easiest way to scam people
23:57:02
Cindy:
the multisig
23:57:12
Cindy:
and trader bonds
23:57:19
BoBeR182:
how do you multisig a creditcard?
23:57:25
Cindy:
oh yeah you mean the card?
23:57:29
Cindy:
yeah that's the problem
23:57:29
ofrnxmr:xmr.mx:
Cindy: That doesnt prevent anything
23:57:32
Cindy:
that's why it's high risk
23:57:32
ofrnxmr:xmr.mx:
Cindy: Yea
23:57:39
BoBeR182:
so lets say I have a $100 visa gift card
23:57:42
BoBeR182:
I sell it to you for XMR
23:57:50
Cindy:
then you revoke the card
23:57:58
BoBeR182:
if it gets spent, how would a 3rd party know it was me or you who spent it
23:58:01
BoBeR182:
who's scamming who
23:58:10
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
23:58:41
ofrnxmr:xmr.mx:
BoBeR182: Exactly. Its the easiest way to scam ppl on p2p, using a gift card
23:59:24
Cindy:
you can still do this in P2P exchanges
23:59:31
Cindy:
it's that, i doubt anyone will take you
23:59:38
Cindy:
from how risky in nature it is
23:59:46
cranial_luminance:matrix.org:
good points all around. but what if there was a way to give the code to the p2p exchange first. is there a way for them to verify if has been used yet? if so, then maybe that could work like an escrow system.
23:59:52
Cindy:
only if someone is daring