<kaigoh:gohegan.uk> All, I've been mooting the idea of a different take on Open Alias: using Matrix-esqu federation via .well-known URLs to allow email style alias lookups for crypto addresses. Open Alias is great, but it requires technical knowhow and is fixed to a single wallet address. I'm thinking of allowing fresh addresses per alias lookup, [... too long, see mrelay.p2pool.observer/e/iPrhzt4KSThadE8x ]

you can use subdomains in DNS

so it's not fixed to a single wallet address

infact, this is what openalias internally does when it encounters an @ symbol in the alias

like for example alice⊙ec is translated to alice.example.com before doing a DNS lookup

i think .well-known URLs makes it easier to compromise and tamper with the wallet address linked to the domain than just having it within the DNS

kaigoh:gohegan.uk: ^

<kaigoh:gohegan.uk> Cindy_: Yes, I agree - I'd be inclined to sign data coming from this using per domain keys, offering the option to use a key in a DNS TXT record and / or in .well-known to ensure authenticity.

<kaigoh:gohegan.uk> I meant one alias = one address > <Cindy_> so it's not fixed to a single wallet address

so?

i think if an alias had multiple addresses associated, it would be super confusing

just split stuff into subdomains

<kaigoh:gohegan.uk> Cindy_: This is why I'm asking, to see if there is any benefits to what I'm proposing 😅

i don't see any benefits compared to openalias,

<kaigoh:gohegan.uk> Cindy_: Not from a privacy perspective, and if the end user is just putting bob⊙dc, it doesn't matter from a UX?

but i do see more security holes than openalias

kaigoh: yes, and openalias handles that by turning @'s into .'s

so if a end user is putting bob⊙dc, it'll translate to bob.domain.com

and then fetch info from the DNS lookup of that domain

<kaigoh:gohegan.uk> Cindy_: I know. I'm not ragging on Open Alias, I'm more suggesting Open Alias++

yeah i know

but what's so ++ about it

<kaigoh:gohegan.uk> Fresh address for each alias lookup, wallet accounts by alias. It's just an idea 😉

fresh address?

you mean, a fresh subaddress for a user?

<kaigoh:gohegan.uk> Yeah

the server needs access to the user's private view keys to generate subaddresses for them

which is.. i don't know

a bit too risky

<higherlander:matrix.org> hi

<kaigoh:gohegan.uk> Cindy_: I'd be looking to use wallet RPC, rather than rolling anything from scratch. Again, this sort of input is why I'm asking rather the question, so I appreciate the thoughts.

yeah i know

but like.. how are you planning on generating fresh addresses for the users

is it subaddresses of the user's wallet?

or subaddresses of the server's wallet which it'll forward to the respective user?

forward funds*

<kaigoh:gohegan.uk> My concept is that the domain has its own service running, nothing centralised, much along the lines of if you were using Monero pay or something similar. A request for an alias comes in, say bob⊙dc, it then would return a fresh subaddress from the wallet / account associated with that alias.

so bob's wallet?

<kaigoh:gohegan.uk> Yeah

well, that requires the server to have a copy of bob's private view key

to generate subaddresses

and also bob to be aware of the risks of the server having the private view key

most likely having generated a dedicated wallet for the server to use

<kaigoh:gohegan.uk> Cindy_: Of course. It will also support a static address for the alias per OpenAlias. I'm just thinking about flexibility if someone needed it? I mean, you could do an alias for an invoice, for example?

i don't know how you'd go about making an alias for an invoice

or whether that'd be more efficient than just giving the user a generated address directly or QR code

<munching:unredacted.org> @higherlander:matrix.org: hello!

<munching:unredacted.org> why that profile picture:(

<higherlander:matrix.org> @munching:unredacted.org: hmm, there is an issue

<higherlander:matrix.org> @munching:unredacted.org: the critical issue now has been resolved :)

<munching:unredacted.org> OMG PLSSS HAHHAHAAHA

<munching:unredacted.org> I WISH LIFE WAS ALWAYS THIS WAY

<higherlander:matrix.org> 😆

<munching:unredacted.org> i love it

<higherlander:matrix.org> @munching:unredacted.org: depends on you try: 😉

<munching:unredacted.org> true, i subtly shot my shot at it to get removed and it worked (very ironic wording)

<higherlander:matrix.org> very interesting, let's keep in touch

<munching:unredacted.org> what😭

<munching:unredacted.org> to become friends?

<higherlander:matrix.org> I don't mind, it depends on u

<higherlander:matrix.org> 😆

<munching:unredacted.org> oki sure

<munching:unredacted.org> i hope no one gets mad at us not talking about monero rn

HOW DARE YOU NOT TALK ABOUT MONERO

<higherlander:matrix.org> btw, I research Monero for fun

<higherlander:matrix.org> Cindy_: who would dare do that?

<higherlander:matrix.org> I like privacy-first

<higherlander:matrix.org> so I want to do something on Monero...

<intr:unredacted.org> I wonder if there'd be an interest in porting a Cashu mint to Monero

<intr:unredacted.org> I looked at the Nutshell python implementation and I think it could be paired with a (local) Moneropay instance and a monero-wallet-rpc

<intr:unredacted.org> would need to rip out or disable the Lightning stuff though

<intr:unredacted.org> but I think it would fit well in trusted circles, events/conferences, markets, etc

<intr:unredacted.org> not necessarily for the privacy, but for faster transactions, offline transactions, etc.

<higherlander:matrix.org> Are you sure you have me in mind when you say these? @intr:unredacted.org

<intr:unredacted.org> No, just trying to spark a convo

<higherlander:matrix.org> That's exactly what I'm interested in. 😄

<intr:unredacted.org> oh cool!

<intr:unredacted.org> I think while monero is fantastic for online transactions, in-person transactions could use some UX improvements

<intr:unredacted.org> not a fan of Lightning but Cashu (or really any decent e-cash implementation) could be looked into more

<intr:unredacted.org> I tried dicking around with the test mint and it's pretty fun to use

FCMP++ will probably make that stuff easier

<intr:unredacted.org> could you elaborate?

FCMP++ has transaction chaining

to paraphrase from getmonero.org

"Transaction chaining allows signing a transaction spending another transaction, before the spent transaction is published and mined on-chain. This enables certain layer-two designs for Monero (such as some payment channel protocols)"

<intr:unredacted.org> oh that is neat

<intr:unredacted.org> well, I suppose the fcmp wait continues

it is much safer than looking at 0-conf transactions

<ofrnxmr:xmr.mx> > Yeah, but I guess it will take a lot of work to provide good UI/UX in wallet apps to handle such pre-signing, it's not exactly trivial to get that easy and foolproof. Right now I somehow doubt that devs will really put in the necessary effort. Look how long it took for a comparatively harmless feature like subadresses to get universal support.

<ofrnxmr:xmr.mx> re tx chaining

<intr:unredacted.org> yeah, it would be nice to have more wallet devs on board

<munching:unredacted.org> LMAO NOO > <Cindy_> HOW DARE YOU NOT TALK ABOUT MONERO

<munching:unredacted.org> @intr:unredacted.org: you sound so smart

<munching:unredacted.org> where can i, too, aquire a working brain?

<higherlander:matrix.org> @munching:unredacted.org: 👍️

<intr:unredacted.org> @munching:unredacted.org: I found mine in a pack of Kellogs

<munching:unredacted.org> what the hell is that

<intr:unredacted.org> cereal

<munching:unredacted.org> i see that i need whatever it is

<munching:unredacted.org> oh yes

ofrnxmr:xmr.mx: afaik tx chaining is aimed at people building specific systems or applications on monero, not day-to-day wallet usage

<intr:unredacted.org> DataHoarder: But it would be relevant in a proper Cashu + Monero implementation, right?

(I'm looking at that for some presigned multisig groups in p2pool for aggregation, for fallback)

it probably is, but it's not as strong as HTLC

DataHoarder: Could you elaborate on that? Do you mean like, dust amounts of block rewards are kept track of and paid out later?

it can't be paid out later due to coinbases

but it'd allow say groups of 16 miners to aggregate running counters in single outputs

with fallbacks to exit anytime

at zero cost while aggregating

Sounds like a really interesting idea

yeah. I have the sketches but for that I have to implement FCMP++ stuff as well :)

beta stressnet maybe

How would it work to actually use the outputs if the fee exceeds the amount?

nice

jpk68: the outputs are aggregated, aggregation happens when blocks are mined as txs bundled along in the p2pool block

that's why this can work, we are mining our own blocks and txs :)

and other miners can verify, and the groups can make fallback txs (that pay all the group) ahead of time

so the group balances keeps doing 1 in 2 out (minimum by protocol) where one out is to aggregate again, and the other can be used to remove specific members if they are taking the aggregation

the fallback just makes 1 in 16 out where everyone is pay the aggregation (this is a normal tx with fee anyone can broadcast anytime for normal block inclusion)

that way even if someone disappears the worst case is that you stop the group

Ah, okay

Thanks for explaining :)

what mining pool would you recommend?

I'm currently on moneroocean but maybe there are better ones

p2pool

just need to run a node then. but it would be better of course

Bunnyh: don't need to run a node for p2pool

mine off a remote node

hmm actually how much traffic does a node create monthly

<ofrnxmr:xmr.mx> Depends on # of peers and txs

oh lol the cheapest hetzner VPS still has 20TB monthly cap

could just run a node on my IRC shell, there's really no reason not to

you can host a p2pool node somewhere

really anywhere

p2pool, but monero ocean is fine

<reaster:matrix.reaster.dev> Bunnyh: non thaaaat much, mine would consume around 400-500gb a month

<ofrnxmr:xmr.mx> U have a lot of peers

<reaster:matrix.reaster.dev> obviously if you have many users it could increase but it would be marginal

<reaster:matrix.reaster.dev> probably yeah

<reaster:matrix.reaster.dev> i accept incoming connection so

<ofrnxmr:xmr.mx> So probably 100+ incoming peers and 12 out

<reaster:matrix.reaster.dev> probably, out of curiosity i can see that?

browser.geekbench.com/v6/cpu/compare/2295167?baseline=2295167 is this enough to run a node comfortably?

<rucknium> @reaster:matrix.reaster.dev: Input status into your monerod console.

this is the cheapest node I could get on hetzner a year or so ago

maybe syncing it elsewhere first

do you have a raspberry Pi hanging around?

you could host p2pool on it

<rucknium> Bunnyh: Usually any CPU except an old RaspberryPi would do OK now. FCMP, which will probably be deployed this year, will require more processing power than now. How much more? Hard to be exact.

rucknium: i hope FCMP can run in my intel core i5

yeah I just find this hetzner shell I mainly use as IRC shell being the most stable machine I have. then I have lots of PCs running 24/7 (damn my electricity bills are high!) but the bigger the machine the more likely it either crashes or I tweak something and there's downtime

<rucknium> Cindy_: You could try stressnet on it. But stressnet is much more stressful than mainnet will probably be.

and I have raspberries but deemed too puny years ago for my personal use :)

might be because I only had the very first versions though!

those are probably ancient relics by now

newest raspberry I have is the one that came with a casa node...

terrible user experience on that device btw :p

<rucknium> Old Raspberry Pis do not have hardware acceleration for AES. AFAIK, that is why they are slow.

that is for pow

not specifically cryptography

but yes, that's why it's slow for mining or verifying

even worse in v2 but v2 has commitments that fix this

(for verification)

<reaster:matrix.reaster.dev> @ofrnxmr:xmr.mx: i've restarted it by mistake but after restarting it, got 50out and 20in

I have like 5 or 6 high performance DDR4 machines but never had a single DDR5 machine. got a 5950X and a 5800X3D, kinda hard to choose between them for my main PC now

AMD would earn infinite karma releasin the 5950X3D today

<rucknium> @reaster:matrix.reaster.dev: You don't use the default 12out? That would explain why your bandwidth usage is higher.

<rucknium> IMHO, it's not a good idea to raise the outbound connections limit, especially not as high as 50+

<rucknium> You are just stressing your node and others for little benefit.

<rucknium> And tx relay is very inefficient now. It will get more efficient soon, probably.

<rucknium> You are relaying full txs to all of your connections.

how is that inefficient?

<rucknium> You could check if your peer already has the tx

<rucknium> Then they don't need it because they already have it.

well what if a peer started lying? it seems like the inefficient method is safer in that scenario

<rucknium> Most tx relay messages are redundant since your peer already has the full tx

<rucknium> If your peer is lying, why try to help them at all?

<rucknium> This is tx relay in the txpool (mempool in bitcoin terms)

<rucknium> It's not tx in mined blocks.

<rucknium> Here's the proposed revised tx relay protocol: monero-project/monero #9334

<reaster:matrix.reaster.dev> i set 50/50 > <@rucknium> @reaster:matrix.reaster.dev: You don't use the default 12out? That would explain why your bandwidth usage is higher.

<reaster:matrix.reaster.dev> probably could set more,

<reaster:matrix.reaster.dev> i really don't stress the machine that much, it's a raspberry pi running on a salvaged old macbook ssd, it's not really getting that much load, and i got a 10gig wan connection (even if the raspberry could only take 1gig max)

ok yes I was dumb about that, it wouldn't help if they are lying they wouldn't relay it further anyway

<rucknium> The draft code is here: monero-project/monero #9933

I'll read it

<rucknium> @reaster:matrix.reaster.dev: You could set inbound limit to 100 and outbound to 12 :D

<reaster:matrix.reaster.dev> @rucknium: i will set 100/100 and see if the raspberry burn

although even if it saves on inefficiency what about the security?

<reaster:matrix.reaster.dev> but he's getting a good amount of load from the matrix server connected to around 40others matrix servers 🤣

isn't it naturally a bit safer regarding analysis if there is a rather inefficient broadcast storm like that? of course need to be mindful about if the inefficiency is actually becoming a problem

and it very well might be

<rucknium> Bunnyh: I don't think it affects security much. Bitcoin does it the new proposed way.

<rucknium> Only security effects may be slower or incomplete tx relay, which could affect 0-conf security. @boog900:monero.social , any thoughts on any security effects of v2 tx relay?

I mean the tighter the latency for global propagationo the more absolute hold a malicious actor would have globally to pinpoint the origin of a transaction

with more relaxed latency, it seems there is a bigger window for this analysis, no?

<rucknium> Bunnyh: It is believed that nodes started to fall behind during the March 2024 tx spam because of inefficient tx relay, plus some other technical debt.

<rucknium> That could be a security issue.

like getting the state of all routers worldwide at the same 100ms window is a different challenge than having a 1000ms window for it

<reaster:matrix.reaster.dev> torrent seeding machines or matrix host machines deals with so much more load from p2p in general, > <@rucknium> @reaster:matrix.reaster.dev: You could set inbound limit to 100 and outbound to 12 :D

<reaster:matrix.reaster.dev> from what I've seen, monerod is almost none there

<rucknium> Bunnyh: Dandelion++ protects against IP address origin analysis and is unaffected by tx relay v2

yes probably I don't understand any of that well enough, just wondering :)

<rucknium> Bunnyh: Here was my privacy analysis: monero-project/monero #9334#issuecomment-2307824031 . Also read boog900's comments after mine.

thanks

<rucknium> @reaster:matrix.reaster.dev: @reaster:matrix.reaster.dev: Maybe now, but not during high tx loads.

hmm nodes falling behind in peak tx loads is an interesting weak spot

it must be actually going relatively unnoticed in most scenarios with most coins

is it known what's been the bottleneck in monero's case?

<boog900> Keeping the protocol secure is the main slow down of tx-relay v2 development, it has become more complicated than I originally thought it would be in order to keep it secure. We have checks to prevent nodes from slowing down tx relay too much.

<boog900> So yeah it is another area for an adversary to attack, however I do think the benefits are worth this, as @rucknium:monero.social said I would argue the current protocol isn't secure, the current code (probably) caused nodes to crash under load.

<rucknium> Example: "A lot of 150/2 transactions in the txpool causes memory spike / OOM" monero-project/monero #9317

shouldn't a node be able to protect itself against OOMs? or is there some reason any particular block could take that much memory?

<rucknium> Bunnyh: Bottlenecks have been worked on for about a year and a half. 2024 after the spam wave, a stressnet was launched. Some fixes then. Three months ago, stressnet with FCMP was launched and fixes are happening.

<boog900> even if the current code worked, I still think the benefits of the significantly reduced bandwidth is worth it.

<rucknium> Here is one of the OOM causes fixed: seraphis-migration/monero #275

<reaster:matrix.reaster.dev> wouldn't it be fixable by setting an arbitrary max ram value to monerod? (like what can already be done if in a container)

<reaster:matrix.reaster.dev> so at worst the node would just "lag" a bit on the tx (which wouldn't be that bad it's not like we get blocks every seconds)

<reaster:matrix.reaster.dev> but it's true that with that kind of direction you could have some tx being just lost somewhere, because the node youre connected to are overwhelmed

<reaster:matrix.reaster.dev> still that's very apocalyptic 😅

<rucknium> The Monero node has a lot of technical debt. Better to try to solve it directly. I don't know if you could just set an RAM arbitrary limit.

<srecanbozic:matrix.org> hello everyone. i come here with a privacy concern regading "optional transparency", or outgoing view keys. i am afraid this will eventually translate into mandatory handover of outgoing and incoming view keys to regulatory state bodies, effectively abolishing privacy

<srecanbozic:matrix.org> i want your thoughts on that, as this is a great concern of mine

<intr:unredacted.org> > mandatory handover of keys

<intr:unredacted.org> what keys?

<intr:unredacted.org> ;^)

well the same logic would apply to private keys, you don't have to tell anyone you own monero so they can't ask for either kind of key

well you might "have to" by law but just ignore it

<intr:unredacted.org> "you're hiding private keys under the floor boards, aren't you"

<cyrix126:gupax.io> The law can simply forbide monero too

maybe if all internet communications were tracked and unless you had a legit authorised reason for any transmission or receival of data you just weren't allowed to it would become a bit hard to use monero

srecanbozic: if they can force you to give your view keys, what's stopping them from forcing you to give your spend keys too

and that's where we seem to be going potentially...

also btw, you can make a small tweak in the Carrot key derivation

also banning of personal computers or economic discouraging of their use is starting to happen

basically have s_vb set to k_ps

that's probably going to be more effective than outright bans of the internet

(or the view-balance secret set to the prove-spend key i think)

less tech savvy friends of mine already talking like they are about to submit to the "you will stream your compute and be happy" era

<intr:unredacted.org> Cindy_: (I don't think this helps a self appointed "newbie")

this will make it roughly equivalent to the CryptoNote scheme

where CryptoNote has incoming view keys and spend keys

intr: i'm sure wallet devs will do this automatically

this is just low-level stuff

<intr:unredacted.org> yeah I'm just saying explaining low level stuff as an answer to a newbie question is probably not getting them any further

<intr:unredacted.org> lmao

it can't really be helped that privacy will have a learning curve

people are so not used to actual privacy

in much more better layman's term

i don't think wallets will be generated with the view-balance secret derived seperately

it'll be for if the user wants to have wallets that they can let others see what goes in and what goes out

(like fundraisers)

and tucked away in advanced options

<intr:unredacted.org> anyway, just like with bitcoin, don't acquire your coins from a KYC exchange, never use non-custodial wallets, and if a time comes where it's mandatory to reveal the view key, and they suspect you have muh 'nero, generate a decoy wallet

<intr:unredacted.org> put a small amount of funds in it

but if you needed to show a wallet with plausible transactions over a certain timeline

<intr:unredacted.org> then transact from it a few times

<intr:unredacted.org> "yeah nah I stopped caring about crypto and sheiit, paypal is so much easier" or some bs excuse

could be interesting if it was possible to have a wallet that cannot even know its own tx history, only what it now has access to. then it would be literally impossible to provide view keys :)

<intr:unredacted.org> in a more realistic scenario, the only case where the government or tax office would actually get wind of you having coins, is if you're a business accepting xmr or something

<intr:unredacted.org> in which case, yeah, make the view key public

<intr:unredacted.org> Bunnyh: I believe the old jamtis spec had a set of keys for that, where it can only calculate the balance. And another key which can only be used to generate addresses

<intr:unredacted.org> I wonder if Carrot has anything like that

interesting

<intr:unredacted.org> I was really hyped about that stuff

that just seems like a nightmare if you attempted to have multiple copies of it

<intr:unredacted.org> wdym

like how are you supposed to back it up if it's also meant to forget its history?

<intr:unredacted.org> the keypairs were part of the wallet, just like you can create a view-only wallet now you could create a balance-only wallet, or an address generation-only wallet

<intr:unredacted.org> I think there were 4 tiers

<intr:unredacted.org> but its been a while since I've looked into it I may be misremembering

<srecanbozic:matrix.org> okay thank you guys for all your inputs. means a lot :)

<pyratevevo:matrix.org> I always thought this was a little too blackpill for me and didn't think it'd happen. But it actually sounds like it's the plan. > <Bunnyh> also banning of personal computers or economic discouraging of their use is starting to happen

think the current model is just fine of course. probably someone is even using the view only feature for legit purposes! respect to them

<intr:unredacted.org> the current state of view only? yeah I use it

<intr:unredacted.org> for Moneropay mostly

<pyratevevo:matrix.org> Cindy_: But does it affect other users ? Like if it can somehow lead to myself getting made because both my sender and the receiver of my coins have their viewkeys out in public ?