11:06:01 I'm personally very interested in finishing my degree 11:56:12 Joseph Abel: , you've checked out "zero to monero" and .... whats the other one 11:56:13 ? 11:58:49 also these: https://web.archive.org/web/20190415164302/https://cryptonote.org/standards/ 11:58:54 cryptonote.org is dead.... wow 11:59:26 i mean, thats the old stuff, but some of it is still relevant, like block structure etc i think 13:05:35 Hello! is there any limitation to sub addresses compared to integrated addresses? I am trying to be able to detect payments on a specific primary address and currently using integrated address to add a payment id to the primary address. If I were to switch to sub-addresses which noticeable difference would it have? I read somewhere that number of sub-addresses are limited per prim 13:05:36 ary address for example. 13:12:28 "limited per primary address" per account would be more accurate. have to be aware of the lookahead value (and warning/note about it) https://docs.getmonero.org/interacting/monero-wallet-cli-reference/#performance 13:14:52 other than that^ the subaddress has to be generated using the view-only wallet details. must the users do this? must the service? are they to be generated 'on demand' (potential ddos) or in batches and sent to a database for lookup? the subaddress itself becomes the payment id in effect 13:15:59 and there is no limit https://monero.stackexchange.com/a/13941 13:17:56 The app does takes primary address and secret view key from the user ( does not create the wallet by itself ). For integrated address ( current implementation ) it is be generated on demand. 13:18:47 If there is many requests for creating sub-addresses and not many of them be used, what is the consequences? is there any? 13:19:28 Since I can't use the same sub-address for different flow and must be unique. 13:19:52 you need to keep track of these events. for anti ddos, and, to simply confirm your default lookahead settings is sane 13:21:13 if i am able to keep requesting sub addresses - if everything is configured fine - one day you would see alert "Hey! you have 1 million sub-ads, your wallet cache only has 0.99 lookahead! time to figure it out 13:21:31 I am using monero-lws to watch if any payment has happened on specific address / sub-address. Does that make a difference? 13:22:02 yes, i do not know if any if this is mitigated 13:22:27 " time to figure it out" what is the way to figure it out? Ask user to change his wallet? 13:22:46 the service must provide the addresses then 13:23:36 There is this proposal for deprecating integrated addresses 13:23:38 https://github.com/monero-project/monero/issues/7889 13:23:40 This has raised my concern to move on to using the sub-addresses 13:23:50 ensuring the subaddress is unique / not used for something else - you can also let sub ads expire after a certain time and warn user that sending after the expiry means funds are lost (like a payment request in your electrum-like wallets) 13:23:59 We don't want to be keeping / generating any wallets on our end. 13:25:18 Is there a thing on subaddress being expired and not causing the heavy lookahead then? 13:25:48 i think this is not added to the reference wallet yet and is up to developers to use their magic :( 13:27:06 as you can see there are many advantages of integrated address, but they promote address re-use 13:28:31 To make sure I have understood this correctly, if there are many sub-addresses generated for a specific primary address and the app is not the side that is generating wallets for its users, we should not let the number of subadresses exceed a specific amount? and if yes what is the reasonable amount? 13:28:54 On the other hand do I have to move from integrated address to sub-address at all? 13:31:17 better to ask someone knowledgeable on that, jeffro256 are our integrated addresses safe for future use? 13:32:49 XMRchat gives me the subaddress and i tip that address (it's unique so my comment is attached) right? 13:32:54 I cant comment on lws 13:33:55 But for a view wallet (rpc) the subaddresslookahead is not necessary 13:34:02 Each new request will create a new subaddress and the top subaddr and all prior subaddr will cont to be monitored for funds 13:36:27 scenario: 13:36:28 1. spammer opens 300 requests against view wallet w/o sending any funds 13:36:30 2. normal user sends funds on subaddress 301 13:36:32 3. view wallet sees the funds (it generated the addr) 13:36:34 4. Spend wallet does not see the funds (its lookahead is only 200, and doesnt know that the view wallet received funds on addr 301) 13:42:31 Thanks for explanation ofrnxmr . Do you recommend asking user to like lookup more addresses or change their address what is a better way? 13:44:21 If they use mobile wallets, they dont have the ability to change the lookahead atm. Probably important for wallets to add that 13:45:53 What situation requires users to do this? Is this for reducing resource usage/costs on the back end? 13:46:26 You also can only set the lookahead when restoring or creating a wallet. 13:46:26 recommended: add instruction for users. instruction: when creating a wallet for the service, use feather wallet and set the lookahead to like 20000 addresses and 1 account 13:47:30 plowsof: it doesnt bother/effect the backend. But the person receiving the $ (using cake etc) wont be able to access it if the lookahead (in cake) is too low 13:49:04 "We don't want to be keeping / generating any wallets on our end" doubt 13:49:59 situation that req it is: spammer forces service's view wallet to generate more subaddresses than the lookahead, then a real user send funds. Because the spend wallet has no knowledge of the subaddresses generated, spend wallet wont see the funds that were sent to the subaddress beyond its lookahead 13:50:04 It is for a system where anyone ( using a public route ) can generate their own subaddress/integrated address and pay to that. Which 200 is a normal number if there are many address generation requests. 13:51:20 the default lookahead is 50account/200address(per account) 13:52:36 It is for a system where anyone ( using a public route ) can generate their own subaddress/integrated address and pay to that. Which 200 seems like a low number if there are many address generation requests. 13:53:12 Which is fine for a regular user. For oerformance, its pregenerating 10000 addresses altogether, but spreading them across accounts. 13:53:12 for a service, its probably better to change the spend wallet lookahead to 1/10000 or similar. No need for the extra subaccounts being pregenerated 14:13:22 saeedab: might need #monero-community-dev:monero.social "if there are many sub-addresses generated for a specific primary address and the app is not the side that is generating wallets for its users, we should not let the number of subadresses exceed a specific amount?" you're planning on giving users of a service a view-only wallet to generate a payment subaddress to pay to? address re-use? 14:14:03 or am i not fully awake 14:20:56 If expecting users to use a wallet that does not allow setting the lookahead, then the max sequantial unused addresses generated should ben200 14:22:04 Since last used addr + 200 is the default lookahead 14:24:25 no problem with the server 14:25:05 The issue is with the _spend wallet_ that has no knowledge of what addresses the service has generated and not used 14:27:02 Example: btcpayserver. 14:27:02 If i make 201 fake invoices on cakepay, then whomever holds the spendkey to the external cakepay wallet must use an increased lookahead, or the spend wallet wont see the spends beyond the lookaheadb 14:28:22 Lets pretend lookahead is 10. 14:28:22 the spend wallet only "looks ahead" 10 subaddresses beyond the last time it saw funds. if view wallet had 10 fake invoices, and on the 11th someone sent funds, the spend wallet wouldnt know about 1. The view wallet generating 11 addresses 2. The funds on the 11th address 14:29:17 User has its own wallet 14:29:18 Gives app the address and secret view key and we listen listen to transactions on integrated addresses generated by the app. But we want to switch to subaddress 14:49:30 Just to add: the inability to set the lookup when restoring from rpc is very annoying 14:49:38 Just to add: the inability to set the lookahead when restoring from rpc is very annoying 15:02:04 Thanks for the info ofrnxmr, saeedab, the disconnect between view only and spend wallet is messy, Add subaddress look ahead to generate from keys / json should be a feature request 👀 15:11:09 https://github.com/monero-project/monero/issues/8954 15:11:13 https://github.com/monero-project/monero/pull/8981 15:11:15 Its an issue / pr already 15:11:35 Thx sgp 15:12:19 The PR takes one reasonable approach, which is a new RPC call, but it _doesn't persist_ which is annoying. Better than nothing, but not ideal 15:13:34 Ideally it should be reworked to be persistent, or the lookahead should be added as an optional parameter when restoring/creating, or both 15:16:18 might need someone to resubmit the pr if the author isnt available to fix merge conflicts 15:17:32 Might be best to add the rpm param to open/restore commands in a separate or, and persistence as well 15:25:42 This is above my pay grade. I can help _fund_ such a fix but not _actually do_ the fix :p 16:21:04 The former should be easy enough for the right person, and the latter possibly has someone available to add the parameter.. i'll see if i can wake someone up 16:31:22 Welp; I’ll have to add a new entry in the P2P message protocol for automatic I2P bootstrapping discovery .-. 16:36:25 Man what?! 16:36:27 Bootstrap to what!? R u using ai too?? 16:37:18 I'm melting over here how everyday you seem to have less of an understanding about things youve been working on for a year 16:40:47 I'm trying very hard to not be rude, but I'm an idiot myself yet somehow you manage to leave me dumbfounded, flabbergasted, in shock etc. Please tell me its AI :D 16:42:46 And actually, i'm in the party of completely removing public-node and bootstrap-daemon=auto 16:42:50 (that doesnt change the fact that bootstrapping i2p rpc is a hallucination) 17:39:04 Hey. I would like to submit a CCS proposal for part-time maintenance & further development of Monfluo (a fork of Mysu, Android wallet: https://codeberg.org/acx/monfluo), but seeing that the latest "wallet proposal" (for Unstoppable Wallet) was rejected I want to ask here beforehand if such a proposal would have a chance (just testing the waters here, obviously I am not expecting a ny sort of confirmation that a proposal would be accepted)? There was a lot of criticism for that proposal which (hopefully) would not be applicable here, but one of the points was that it would be a "yet another wallet" and I am wondering whether it would also be the case here? Monfluo is explicitly non-commercial (no in-app swapping, no converting to other cryptos, no fiat on/of f-ramps, so I make no money from that, and such simplicity is the core idea behind the wallet), if that makes a difference. Any opinions on that? 17:50:25 Monerujo went their own funding route, feather is funded because tob is a monero core dev. Spirobel's browser api was funded 17:50:49 But i don't know that we want to create a reliance on ccs for wallets to exist 17:51:05 I see 17:51:35 Hey guys, I would like to ask you how are you buying Monero for self custody? I just couldn't find anywhere to buy it, the exchanges that I found wouldn't allow self custody... 17:52:31 Thats not to say i'm NACKing it, just that its a slippery slope. 17:52:32 xmruw was funded as a testbed for monero_c and dart libs, anonero due to contributions such as UR offline signing 17:53:23 cex for fiat: kraken 17:53:24 Dex for fiax: haveno reto / retoswap 17:53:26 cex for crypto: tradeogre, trocador 17:53:28 dex flr crypto: basicswap 17:54:19 Kraken allows you to send XMR to self custody (eg. Exodus)? 17:56:03 Personally i'm a big fan of mysu/monfluo (i dont like the new name 😆, or removal of monerochan), and would like to see it continue to improve 17:57:14 tob is not just a monero-core dev 😭 😭 17:57:17 Got it! Thank you so much for the recommendations. 18:00:31 if the underlying technology is doing something unique / would benefit monero-core - wider ecosystem then it would seem worthwhile to get funding behind it 18:02:04 also i hear unstoppable wallets integration is 99.5% done 18:02:44 r/oddlyspecific 18:02:51 did anyone notice the unstoppablewallet's "subscriptions" where public lol 18:02:56 removed now 18:03:03 Sneakos updates and some other political guy 18:04:06 nvm public. yeah 99.5% https://www.reddit.com/r/Monero/comments/1iuolfq/unstoppable_wallet_x_monero_integration_at_995/ 18:08:55 plowsof, mysu is a solid wallet, and monfluo seems to be a bit more solid, with QOL improvements like subaccounts and multiwallet support 18:10:23 Which were some of the main reasons to choose monerujo > mysu. Not monfluo is one of the only "full featured" mobile xmr wallets 18:10:52 r4v3r23 thoughts? 18:10:59 Now* 18:24:49 No you’re good, I didn’t really explain it (admittedly I’m pretty bad at this entirely), so I’ll try to be as verbose as I can rn: 18:24:50 Basically the bounty wants a “one-click” solution for the implementation, with it being explicitly compared to how Haveno handles Tor connections (so the end user of the gui doesn’t have to do anything in terms of setup other than a single toggle switch). This also needs to be accessible for *all modes, including Simple mode*. Simple mode currently uses the “auto bootstrap 18:24:52 ” method to connect into the network, so the simple mode using I2P should do something similar. 18:24:54 You can already bootstrap to I2P nodes by manually specifying the b32 address in a command as well as the proxy, so thankfully that portion of the implementation is basically golden (although as I’m saying this, I have a sneaking suspicion that transactions might not be sent through the bootstrap node, though as I’m saying *this*, I have a feeling that they are since tx-proxy 18:24:56 doesn’t work when bootstrapping via a clearnet node, though it could still be different; anyways). That only leaves the implementation of the auto itself. This currently doesn’t work because while the peer messages will submit their rpc port over the network (if they are set to public), it doesn’t support sending an alternate address for the rpc. This doesn’t matter for no 18:24:58 rmal nodes, but since I2P doesn’t support ports(or technically speaking each address can be considered a host+port construct), the rpc port parameter isn’t usable for an i2p rpc, and worse, *the “host” address of the rpc is different from the p2p address*. This, in essence, means that, in one form or another, the only way for i2p rpc destinations to be broadcast over the n 18:25:00 etwork would be the addition of another variable that would be sent over the network (or editing the rpc port variable, but this would almost definitely break the network, so no). The variable would follow similar conventions to the rpc port variable (being optional is the biggest one). This is my full reasoning. 18:25:02 I will be the first to admit that I am not happy with my progress despite a year of on-and-off development. Most of the early work that I did ended up fruitless, with attempts to recover the work of past attempts coming up short, attempts to implement “best case” protocols like SAMv3 failing and running into friction with existing solutions, and misunderstandings and miscommun 18:25:04 ications between myself and the terms of the bounty resulting in sudden upheaval of my work. Add to this the fact that I have done this with no intermediate compensation (not asking for any, this isn’t a kewbit situation) while balancing it with work on other projects and some major life changes, and also the not unimportant fact that I took on the bounty without a full understa 18:25:06 nding of either Monero or I2P, and you get where we are now. 18:25:08 I do not disagree with your assessment that the auto bootstrap option is somewhat flawed, and if it is removed and the simple wallet connection method is transferred to something else, I will not be angry or frustrated. Same goes if I make an implementation for i2p auto bootstrapping and it goes nowhere. It’s what I signed up for over a year ago, and I’m okay with that. 18:25:57 Also I don’t think I’ve said it, but genuinely thank you for the help; you have probably saved me nearly 12 hours worth of banging against a wall and using strace and random documentation to figure out what is going on/going wrong 18:30:52 the only way to transfer i2p to auto bootstrap, is to have a public-node flag that was knowledgeable about your i2p bind for rpc (monerod has no knowledge of it), also to have knowledge of whether your peers are accepting i2p connections (so the new public-node i2p flag would have to be transferred over tx-proxy and anonymous-inbound) 18:30:54 Youre probably wasting your time, and asking for trouble in an implementation that doesn't really make sense 18:32:05 --proxy= does _not_ work for blockchain sync, and is essentially --no-sync. So while this may work for `simple mode`, it definitely will not work for simple-bootstrap mode 18:32:53 Simple mode is an ugly hack that just uses --no-sync. Simple bootstrap mode doesnt issues --no-sync - it syncs the blockchain over clearnet 18:35:26 you can only sync the blockchain from clearnet nodes (you can use a sock proxy that can reach clearnet nodes. you cannot sync blockchain from i2p or onion nodes. 18:36:55 Monero requires users to specify anonymous-inbound to notify peers about your incoming txproxy hidden services. It only relays hidden services to other hidden services. Clearnet peers dont get messages about hidden services 18:37:38 So you cant / shouldnt share your "new rpc public-node i2p" message without tx-proxy to be able to relay it to fellow obion or i2p peers 18:38:27 basically, its a mess on top of a mess 18:40:25 We should be using something like torcontrol or i2p sam to find and share our hidden services. The current method of specifying manually isnt a good one. It allows me to input plowsof's hidden service as my own if i felt like it 20:55:00 <3​21bob321:monero.social> plowsofi dmd you, answer me ! 20:55:36 <3​21bob321:monero.social> 100% uptime sir 21:19:54 👍 21:37:07 this proposal is there since forever and will most likely never get implemented. There is no good reason for you to switch to subaddresses. They only make sense for end users that want to use just one wallet but have multiple only identities that they dont want to see connected. So picture someone who sells catnip otc and sometimes receives birthday money from their grandma. They 21:37:08 dont want their grandma to know under any circumstances about their OTC catnip trading activity. if grandma where to browse a catnip trading board and see the address she already knows is her grandsons, she knows. That is the reason these addresses are used. For a merchant this makes zero sense. Because they have a website that is known as this one entity. Sharing different subadd 21:37:10 resses with different customers doesnt magically split it up, because they all got it from the same known entity. 21:38:06 ALSO: Integrated addresses are a serious problem for entities that batch their outgoing transfers. When a bunch of withdrawals are batched together, they may include no more than one integrated address, since a tx may include no more than one payment ID. This causes unnecessary congestion through artificial scarcity, which probably contributed to the recent events of major exchang 21:38:08 es suspending their XMR withdrawals. <--- can someone explain what this even means? the arguments to deprecate them are flimsy at best 21:39:17 quoted from the github issue: 21:39:18 >Integrated addresses are a serious problem for entities that batch their outgoing transfers. When a bunch of withdrawals are batched together, they may include no more than one integrated address, since a tx may include no more than one payment ID. This causes unnecessary congestion through artificial scarcity, which probably contributed to the recent events of major exchanges su 21:39:20 spending their XMR withdrawals. 21:39:22 \<--- can someone explain what this even means? the arguments to deprecate them are flimsy at best 21:39:47 this proposal is there since forever and will most likely never get implemented. There is no good reason for you to switch to subaddresses. They only make sense for end users that want to use just one wallet but have multiple online identities that they dont want to see connected. So picture someone who sells catnip otc and sometimes receives birthday money from their grandma. The 21:39:48 y dont want their grandma to know under any circumstances about their OTC catnip trading activity. if grandma where to browse a catnip trading board and see the address she already knows is her grandsons, she knows. That is the reason these addresses are used. For a merchant this makes zero sense. Because they have a website that is known as this one entity. Sharing different suba 21:39:50 ddresses with different customers doesnt magically split it up, because they all got it from the same known entity. 21:40:19 this proposal is there since forever and will most likely never get implemented. There is no good reason for you to switch to subaddresses. They only make sense for end users that want to use just one wallet but have multiple online identities that they dont want to see connected. So picture someone who sells catnip otc and sometimes receives birthday money from their grandma. The 21:40:20 y dont want their grandma to know under any circumstances about their OTC catnip trading activity. if grandma were to browse a catnip trading board and see the address she already knows is her grandsons, she knows. That is the reason these addresses are used. For a merchant this makes zero sense. Because they have a website that is known as this one entity. Sharing different subad 21:40:22 dresses with different customers doesnt magically split it up, because they all got it from the same known entity. 21:47:08 You cant send funds to more than 1 intg address at a time 21:47:57 Theres only 1 space for payment id in txextra 21:50:03 so the exchange that wants to send non uniform transactions to batch things can just not allow withdrawing to integrated addresses. problem solved 21:50:18 end users can easily make integrated addresses in any case 21:50:25 Dan (Is not the man & Braxman Tomsparks Qtip USAID Advocate) Backup: ofrnxmr node stability response team have solved the issue, thank you sirs 21:51:05 end users cant easily make integrated addresses in any case 21:51:49 The i2p nodes had 100% uptime! 21:53:25 The "probably" in the quote is just looking for an excuse for binance's empty reserves 21:53:26 I dont know of any exchange that allows wd to intg address 22:13:17 hands getting waved left and right 22:13:56 yeah it does not make a ton of sense. this issue should just be closed. 22:14:24 [CCS Proposals] Lee Clagett opened merge request #553: vtnerd 2025 Q1 Proposal https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/553 22:15:05 -xmr-pr- [css-proposals] vtnerd opened pull request #553: vtnerd 2025 Q1 Proposal 22:15:05 -xmr-pr- > https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/553