11:38:20 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 https://mrelay.p2pool.observer/e/iPrhzt4KSThadE8x ] 11:44:32 you can use subdomains in DNS 11:44:52 so it's not fixed to a single wallet address 11:46:10 infact, this is what openalias internally does when it encounters an @ symbol in the alias 11:46:26 like for example alice⊙ec is translated to alice.example.com before doing a DNS lookup 11:50:28 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 11:52:29 kaigoh:gohegan.uk: ^ 11:54:36 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. 11:55:01 I meant one alias = one address > so it's not fixed to a single wallet address 11:55:17 so? 11:55:30 i think if an alias had multiple addresses associated, it would be super confusing 11:55:50 just split stuff into subdomains 11:57:54 Cindy_: This is why I'm asking, to see if there is any benefits to what I'm proposing 😅 11:58:33 i don't see any benefits compared to openalias, 11:58:40 Cindy_: Not from a privacy perspective, and if the end user is just putting bob⊙dc, it doesn't matter from a UX? 11:58:46 but i do see more security holes than openalias 11:59:02 kaigoh: yes, and openalias handles that by turning @'s into .'s 11:59:16 so if a end user is putting bob⊙dc, it'll translate to bob.domain.com 11:59:27 and then fetch info from the DNS lookup of that domain 11:59:49 Cindy_: I know. I'm not ragging on Open Alias, I'm more suggesting Open Alias++ 12:00:05 yeah i know 12:00:08 but what's so ++ about it 12:01:53 Fresh address for each alias lookup, wallet accounts by alias. It's just an idea 😉 12:02:12 fresh address? 12:02:39 you mean, a fresh subaddress for a user? 12:02:46 Yeah 12:02:59 the server needs access to the user's private view keys to generate subaddresses for them 12:03:05 which is.. i don't know 12:03:07 a bit too risky 12:03:10 hi 12:04:11 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. 12:05:32 yeah i know 12:05:45 but like.. how are you planning on generating fresh addresses for the users 12:05:55 is it subaddresses of the user's wallet? 12:06:10 or subaddresses of the server's wallet which it'll forward to the respective user? 12:06:18 forward funds* 12:07:38 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. 12:08:02 so bob's wallet? 12:08:58 Yeah 12:09:33 well, that requires the server to have a copy of bob's private view key 12:09:39 to generate subaddresses 12:09:53 and also bob to be aware of the risks of the server having the private view key 12:10:02 most likely having generated a dedicated wallet for the server to use 12:10:56 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? 12:14:59 i don't know how you'd go about making an alias for an invoice 12:15:21 or whether that'd be more efficient than just giving the user a generated address directly or QR code 12:40:57 @higherlander:matrix.org: hello! 12:41:13 why that profile picture:( 14:48:49 @munching:unredacted.org: hmm, there is an issue 14:50:14 @munching:unredacted.org: the critical issue now has been resolved :) 14:56:14 OMG PLSSS HAHHAHAAHA 14:56:31 I WISH LIFE WAS ALWAYS THIS WAY 14:57:08 😆 14:59:56 i love it 14:59:58 @munching:unredacted.org: depends on you try: 😉 15:00:47 true, i subtly shot my shot at it to get removed and it worked (very ironic wording) 15:02:56 very interesting, let's keep in touch 15:03:10 what😭 15:03:24 to become friends? 15:03:50 I don't mind, it depends on u 15:03:52 😆 15:04:16 oki sure 15:04:28 i hope no one gets mad at us not talking about monero rn 15:05:28 HOW DARE YOU NOT TALK ABOUT MONERO 15:06:02 btw, I research Monero for fun 15:06:39 Cindy_: who would dare do that? 15:07:26 I like privacy-first 15:08:09 so I want to do something on Monero... 15:09:22 I wonder if there'd be an interest in porting a Cashu mint to Monero 15:09:56 I looked at the Nutshell python implementation and I think it could be paired with a (local) Moneropay instance and a monero-wallet-rpc 15:10:18 would need to rip out or disable the Lightning stuff though 15:10:42 but I think it would fit well in trusted circles, events/conferences, markets, etc 15:11:12 not necessarily for the privacy, but for faster transactions, offline transactions, etc. 15:11:23 Are you sure you have me in mind when you say these? @intr:unredacted.org 15:11:35 No, just trying to spark a convo 15:12:15 That's exactly what I'm interested in. 😄 15:12:21 oh cool! 15:13:08 I think while monero is fantastic for online transactions, in-person transactions could use some UX improvements 15:13:33 not a fan of Lightning but Cashu (or really any decent e-cash implementation) could be looked into more 15:13:51 I tried dicking around with the test mint and it's pretty fun to use 15:15:48 FCMP++ will probably make that stuff easier 15:16:12 could you elaborate? 15:17:24 FCMP++ has transaction chaining 15:17:30 to paraphrase from getmonero.org 15:17:36 "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)" 15:17:47 https://www.getmonero.org/2024/04/27/fcmps.html 15:19:05 oh that is neat 15:19:52 well, I suppose the fcmp wait continues 15:19:57 it is much safer than looking at 0-conf transactions 15:20:55 > 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. 15:20:55 re tx chaining 15:21:47 yeah, it would be nice to have more wallet devs on board 15:24:29 LMAO NOO > HOW DARE YOU NOT TALK ABOUT MONERO 15:25:11 @intr:unredacted.org: you sound so smart 15:25:26 where can i, too, aquire a working brain? 15:25:27 @munching:unredacted.org: 👍️ 15:26:33 @munching:unredacted.org: I found mine in a pack of Kellogs 15:27:11 what the hell is that 15:27:23 cereal 15:27:25 i see that i need whatever it is 15:27:28 oh yes 16:00:25 ofrnxmr:xmr.mx: afaik tx chaining is aimed at people building specific systems or applications on monero, not day-to-day wallet usage 16:46:59 DataHoarder: But it would be relevant in a proper Cashu + Monero implementation, right? 16:47:50 (I'm looking at that for some presigned multisig groups in p2pool for aggregation, for fallback) 16:47:54 it probably is, but it's not as strong as HTLC 17:02:27 DataHoarder: Could you elaborate on that? Do you mean like, dust amounts of block rewards are kept track of and paid out later? 17:02:54 it can't be paid out later due to coinbases 17:03:03 but it'd allow say groups of 16 miners to aggregate running counters in single outputs 17:03:10 with fallbacks to exit anytime 17:03:29 at zero cost while aggregating 17:04:38 Sounds like a really interesting idea 17:05:02 yeah. I have the sketches but for that I have to implement FCMP++ stuff as well :) 17:05:06 beta stressnet maybe 17:05:08 How would it work to actually use the outputs if the fee exceeds the amount? 17:05:10 nice 17:12:37 jpk68: the outputs are aggregated, aggregation happens when blocks are mined as txs bundled along in the p2pool block 17:12:55 that's why this can work, we are mining our own blocks and txs :) 17:13:05 and other miners can verify, and the groups can make fallback txs (that pay all the group) ahead of time 17:13:56 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 17:14:28 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) 17:14:56 that way even if someone disappears the worst case is that you stop the group 17:18:07 Ah, okay 17:18:12 Thanks for explaining :) 18:45:08 what mining pool would you recommend? 18:45:51 I'm currently on moneroocean but maybe there are better ones 18:46:04 p2pool 18:47:31 just need to run a node then. but it would be better of course 18:48:06 Bunnyh: don't need to run a node for p2pool 18:48:08 mine off a remote node 18:48:45 hmm actually how much traffic does a node create monthly 18:49:04 Depends on # of peers and txs 18:50:10 oh lol the cheapest hetzner VPS still has 20TB monthly cap 18:50:34 could just run a node on my IRC shell, there's really no reason not to 18:50:46 you can host a p2pool node somewhere 18:50:52 really anywhere 18:57:48 p2pool, but monero ocean is fine 19:04:26 Bunnyh: non thaaaat much, mine would consume around 400-500gb a month 19:05:06 U have a lot of peers 19:05:08 obviously if you have many users it could increase but it would be marginal 19:05:09 probably yeah 19:05:16 i accept incoming connection so 19:05:37 So probably 100+ incoming peers and 12 out 19:06:12 probably, out of curiosity i can see that? 19:09:12 https://browser.geekbench.com/v6/cpu/compare/2295167?baseline=2295167 is this enough to run a node comfortably? 19:09:27 @reaster:matrix.reaster.dev: Input status into your monerod console. 19:09:34 this is the cheapest node I could get on hetzner a year or so ago 19:10:33 maybe syncing it elsewhere first 19:10:53 do you have a raspberry Pi hanging around? 19:10:57 you could host p2pool on it 19:11:04 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. 19:11:44 rucknium: i hope FCMP can run in my intel core i5 19:12:26 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 19:12:32 Cindy_: You could try stressnet on it. But stressnet is much more stressful than mainnet will probably be. 19:13:00 and I have raspberries but deemed too puny years ago for my personal use :) 19:13:13 might be because I only had the very first versions though! 19:13:28 those are probably ancient relics by now 19:14:41 newest raspberry I have is the one that came with a casa node... 19:14:50 terrible user experience on that device btw :p 19:15:14 Old Raspberry Pis do not have hardware acceleration for AES. AFAIK, that is why they are slow. 19:15:24 that is for pow 19:15:36 not specifically cryptography 19:15:41 but yes, that's why it's slow for mining or verifying 19:16:08 even worse in v2 but v2 has commitments that fix this 19:16:10 (for verification) 19:17:09 @ofrnxmr:xmr.mx: i've restarted it by mistake but after restarting it, got 50out and 20in 19:17:16 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 19:18:08 AMD would earn infinite karma releasin the 5950X3D today 19:19:40 @reaster:matrix.reaster.dev: You don't use the default 12out? That would explain why your bandwidth usage is higher. 19:20:10 IMHO, it's not a good idea to raise the outbound connections limit, especially not as high as 50+ 19:20:25 You are just stressing your node and others for little benefit. 19:20:49 And tx relay is very inefficient now. It will get more efficient soon, probably. 19:21:05 You are relaying full txs to all of your connections. 19:21:05 how is that inefficient? 19:21:25 You could check if your peer already has the tx 19:21:38 Then they don't need it because they already have it. 19:22:12 well what if a peer started lying? it seems like the inefficient method is safer in that scenario 19:22:20 Most tx relay messages are redundant since your peer already has the full tx 19:22:37 If your peer is lying, why try to help them at all? 19:22:53 This is tx relay in the txpool (mempool in bitcoin terms) 19:23:08 It's not tx in mined blocks. 19:24:19 Here's the proposed revised tx relay protocol: https://github.com/monero-project/monero/issues/9334 19:24:37 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. 19:24:37 probably could set more, 19:24:37 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) 19:25:02 ok yes I was dumb about that, it wouldn't help if they are lying they wouldn't relay it further anyway 19:25:11 The draft code is here: https://github.com/monero-project/monero/pull/9933 19:25:15 I'll read it 19:26:19 @reaster:matrix.reaster.dev: You could set inbound limit to 100 and outbound to 12 :D 19:26:48 @rucknium: i will set 100/100 and see if the raspberry burn 19:26:57 although even if it saves on inefficiency what about the security? 19:27:27 but he's getting a good amount of load from the matrix server connected to around 40others matrix servers 🤣 19:27:41 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 19:27:50 and it very well might be 19:27:58 Bunnyh: I don't think it affects security much. Bitcoin does it the new proposed way. 19:28:39 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? 19:28:49 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 19:29:00 with more relaxed latency, it seems there is a bigger window for this analysis, no? 19:29:32 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. 19:29:42 That could be a security issue. 19:29:52 like getting the state of all routers worldwide at the same 100ms window is a different challenge than having a 1000ms window for it 19:30:08 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 19:30:08 from what I've seen, monerod is almost none there 19:30:16 Bunnyh: Dandelion++ protects against IP address origin analysis and is unaffected by tx relay v2 19:30:35 yes probably I don't understand any of that well enough, just wondering :) 19:31:21 Bunnyh: Here was my privacy analysis: https://github.com/monero-project/monero/issues/9334#issuecomment-2307824031 . Also read boog900's comments after mine. 19:31:34 thanks 19:33:15 @reaster:matrix.reaster.dev: @reaster:matrix.reaster.dev: Maybe now, but not during high tx loads. 19:34:05 hmm nodes falling behind in peak tx loads is an interesting weak spot 19:34:16 it must be actually going relatively unnoticed in most scenarios with most coins 19:35:01 is it known what's been the bottleneck in monero's case? 19:35:16 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. 19:35:16 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. 19:36:05 Example: "A lot of 150/2 transactions in the txpool causes memory spike / OOM" https://github.com/monero-project/monero/issues/9317 19:37:14 shouldn't a node be able to protect itself against OOMs? or is there some reason any particular block could take that much memory? 19:37:35 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. 19:38:16 even if the current code worked, I still think the benefits of the significantly reduced bandwidth is worth it. 19:40:07 Here is one of the OOM causes fixed: https://github.com/seraphis-migration/monero/pull/275 19:46:07 wouldn't it be fixable by setting an arbitrary max ram value to monerod? (like what can already be done if in a container) 19:46:07 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) 19:46:56 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 19:47:22 still that's very apocalyptic 😅 19:48:13 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. 21:38:19 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 21:38:22 i want your thoughts on that, as this is a great concern of mine 21:39:03 > mandatory handover of keys 21:39:03 what keys? 21:39:09 ;^) 21:39:12 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 21:39:54 well you might "have to" by law but just ignore it 21:40:23 "you're hiding private keys under the floor boards, aren't you" 21:40:33 The law can simply forbide monero too 21:41:11 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 21:41:39 srecanbozic: if they can force you to give your view keys, what's stopping them from forcing you to give your spend keys too 21:41:39 and that's where we seem to be going potentially... 21:41:51 also btw, you can make a small tweak in the Carrot key derivation 21:42:45 also banning of personal computers or economic discouraging of their use is starting to happen 21:42:45 basically have s_vb set to k_ps 21:42:58 that's probably going to be more effective than outright bans of the internet 21:43:02 (or the view-balance secret set to the prove-spend key i think) 21:43:31 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 21:43:34 Cindy_: (I don't think this helps a self appointed "newbie") 21:43:39 this will make it roughly equivalent to the CryptoNote scheme 21:43:46 where CryptoNote has incoming view keys and spend keys 21:43:57 intr: i'm sure wallet devs will do this automatically 21:44:05 this is just low-level stuff 21:44:23 yeah I'm just saying explaining low level stuff as an answer to a newbie question is probably not getting them any further 21:44:25 lmao 21:44:50 it can't really be helped that privacy will have a learning curve 21:44:58 people are so not used to actual privacy 21:45:01 in much more better layman's term 21:45:39 i don't think wallets will be generated with the view-balance secret derived seperately 21:46:08 it'll be for if the user wants to have wallets that they can let others see what goes in and what goes out 21:46:14 (like fundraisers) 21:46:21 and tucked away in advanced options 21:46:25 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 21:46:30 put a small amount of funds in it 21:46:57 but if you needed to show a wallet with plausible transactions over a certain timeline 21:47:09 then transact from it a few times 21:48:04 "yeah nah I stopped caring about crypto and sheiit, paypal is so much easier" or some bs excuse 21:48:59 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 :) 21:49:20 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 21:49:22 in which case, yeah, make the view key public 21:50:00 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 21:50:10 I wonder if Carrot has anything like that 21:50:14 interesting 21:50:28