<f​society012:matrix.org> I'm personally very interested in finishing my degree

<g​ingeropolous:monero.social> Joseph Abel: , you've checked out "zero to monero" and .... whats the other one

<g​ingeropolous:monero.social> ?

<g​ingeropolous:monero.social> also these: web.archive.org/web/20190415164302/https://cryptonote.org/standards

<g​ingeropolous:monero.social> cryptonote.org is dead.... wow

<g​ingeropolous:monero.social> i mean, thats the old stuff, but some of it is still relevant, like block structure etc i think

<s​aeedab:matrix.org> 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<clipped message>

<s​aeedab:matrix.org> ary address for example.

"limited per primary address" per account would be more accurate. have to be aware of the lookahead value (and warning/note about it) docs.getmonero.org/interacting/mone…o-wallet-cli-reference/#performance

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

and there is no limit monero.stackexchange.com/a/13941

<s​aeedab:matrix.org> 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.

<s​aeedab:matrix.org> If there is many requests for creating sub-addresses and not many of them be used, what is the consequences? is there any?

<s​aeedab:matrix.org> Since I can't use the same sub-address for different flow and must be unique.

you need to keep track of these events. for anti ddos, and, to simply confirm your default lookahead settings is sane

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

<s​aeedab:matrix.org> I am using monero-lws to watch if any payment has happened on specific address / sub-address. Does that make a difference?

yes, i do not know if any if this is mitigated

<s​aeedab:matrix.org> " time to figure it out" what is the way to figure it out? Ask user to change his wallet?

the service must provide the addresses then

<s​aeedab:matrix.org> There is this proposal for deprecating integrated addresses

<s​aeedab:matrix.org> monero-project/monero #7889

<s​aeedab:matrix.org> This has raised my concern to move on to using the sub-addresses

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)

<s​aeedab:matrix.org> We don't want to be keeping / generating any wallets on our end.

<s​aeedab:matrix.org> Is there a thing on subaddress being expired and not causing the heavy lookahead then?

i think this is not added to the reference wallet yet and is up to developers to use their magic :(

as you can see there are many advantages of integrated address, but they promote address re-use

<s​aeedab:matrix.org> 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?

<s​aeedab:matrix.org> On the other hand do I have to move from integrated address to sub-address at all?

better to ask someone knowledgeable on that, jeffro256 are our integrated addresses safe for future use?

XMRchat gives me the subaddress and i tip that address (it's unique so my comment is attached) right?

<o​frnxmr:xmr.mx> I cant comment on lws

<o​frnxmr:xmr.mx> But for a view wallet (rpc) the subaddresslookahead is not necessary

<o​frnxmr:xmr.mx> Each new request will create a new subaddress and the top subaddr and all prior subaddr will cont to be monitored for funds

<o​frnxmr:xmr.mx> scenario:

<o​frnxmr:xmr.mx> 1. spammer opens 300 requests against view wallet w/o sending any funds

<o​frnxmr:xmr.mx> 2. normal user sends funds on subaddress 301

<o​frnxmr:xmr.mx> 3. view wallet sees the funds (it generated the addr)

<o​frnxmr:xmr.mx> 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)

<s​aeedab:matrix.org> Thanks for explanation ofrnxmr . Do you recommend asking user to like lookup more addresses or change their address what is a better way?

<o​frnxmr:xmr.mx> If they use mobile wallets, they dont have the ability to change the lookahead atm. Probably important for wallets to add that

What situation requires users to do this? Is this for reducing resource usage/costs on the back end?

<o​frnxmr:xmr.mx> You also can only set the lookahead when restoring or creating a wallet.

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> 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

"We don't want to be keeping / generating any wallets on our end" doubt

<o​frnxmr:xmr.mx> 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

<s​aeedab:matrix.org> 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.

<o​frnxmr:xmr.mx> the default lookahead is 50account/200address(per account)

<s​aeedab:matrix.org> 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.

<o​frnxmr:xmr.mx> Which is fine for a regular user. For oerformance, its pregenerating 10000 addresses altogether, but spreading them across accounts.

<o​frnxmr:xmr.mx> 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

<p​lowsof:matrix.org> 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?

<p​lowsof:matrix.org> or am i not fully awake

<o​frnxmr:xmr.mx> If expecting users to use a wallet that does not allow setting the lookahead, then the max sequantial unused addresses generated should ben200

<o​frnxmr:xmr.mx> Since last used addr + 200 is the default lookahead

<o​frnxmr:xmr.mx> no problem with the server

<o​frnxmr:xmr.mx> The issue is with the _spend wallet_ that has no knowledge of what addresses the service has generated and not used

<o​frnxmr:xmr.mx> Example: btcpayserver.

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> Lets pretend lookahead is 10.

<o​frnxmr:xmr.mx> 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

<s​aeedab:matrix.org> User has its own wallet

<s​aeedab:matrix.org> 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

<s​gp_:monero.social> Just to add: the inability to set the lookup when restoring from rpc is very annoying

<s​gp_:monero.social> Just to add: the inability to set the lookahead when restoring from rpc is very annoying

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 👀

<s​gp_:monero.social> monero-project/monero #8954

<s​gp_:monero.social> monero-project/monero #8981

<o​frnxmr:xmr.mx> Its an issue / pr already

<o​frnxmr:xmr.mx> Thx sgp

<s​gp_:monero.social> 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

<s​gp_:monero.social> Ideally it should be reworked to be persistent, or the lookahead should be added as an optional parameter when restoring/creating, or both

<o​frnxmr:xmr.mx> might need someone to resubmit the pr if the author isnt available to fix merge conflicts

<o​frnxmr:xmr.mx> Might be best to add the rpm param to open/restore commands in a separate or, and persistence as well

<s​gp_:monero.social> This is above my pay grade. I can help _fund_ such a fix but not _actually do_ the fix :p

<o​frnxmr:xmr.mx> 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

<p​reland:monero.social> Welp; I’ll have to add a new entry in the P2P message protocol for automatic I2P bootstrapping discovery .-.

<o​frnxmr:xmr.mx> Man what?!

<o​frnxmr:xmr.mx> Bootstrap to what!? R u using ai too??

<o​frnxmr:xmr.mx> I'm melting over here how everyday you seem to have less of an understanding about things youve been working on for a year

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> And actually, i'm in the party of completely removing public-node and bootstrap-daemon=auto

<o​frnxmr:xmr.mx> (that doesnt change the fact that bootstrapping i2p rpc is a hallucination)

<a​non_contributor_xmr:monero.social> Hey. I would like to submit a CCS proposal for part-time maintenance & further development of Monfluo (a fork of Mysu, Android wallet: 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<clippe

<a​non_contributor_xmr:monero.social> 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<clippe

<a​non_contributor_xmr:monero.social> 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?

<o​frnxmr:xmr.mx> Monerujo went their own funding route, feather is funded because tob is a monero core dev. Spirobel's browser api was funded

<o​frnxmr:xmr.mx> But i don't know that we want to create a reliance on ccs for wallets to exist

<a​non_contributor_xmr:monero.social> I see

<r​amoses:beeper.com> 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...

<o​frnxmr:xmr.mx> Thats not to say i'm NACKing it, just that its a slippery slope.

<o​frnxmr:xmr.mx> xmruw was funded as a testbed for monero_c and dart libs, anonero due to contributions such as UR offline signing

<o​frnxmr:xmr.mx> cex for fiat: kraken

<o​frnxmr:xmr.mx> Dex for fiax: haveno reto / retoswap

<o​frnxmr:xmr.mx> cex for crypto: tradeogre, trocador

<o​frnxmr:xmr.mx> dex flr crypto: basicswap

<r​amoses:beeper.com> Kraken allows you to send XMR to self custody (eg. Exodus)?

<o​frnxmr:xmr.mx> 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

tob is not just a monero-core dev 😭 😭

<r​amoses:beeper.com> Got it! Thank you so much for the recommendations.

if the underlying technology is doing something unique / would benefit monero-core - wider ecosystem then it would seem worthwhile to get funding behind it

also i hear unstoppable wallets integration is 99.5% done

<s​yntheticbird:monero.social> r/oddlyspecific

did anyone notice the unstoppablewallet's "subscriptions" where public lol

removed now

Sneakos updates and some other political guy

nvm public. yeah 99.5% reddit.com/r/Monero/comments/1iuolf…_wallet_x_monero_integration_at_995

<o​frnxmr:xmr.mx> plowsof, mysu is a solid wallet, and monfluo seems to be a bit more solid, with QOL improvements like subaccounts and multiwallet support

<o​frnxmr:xmr.mx> Which were some of the main reasons to choose monerujo > mysu. Not monfluo is one of the only "full featured" mobile xmr wallets

r4v3r23 thoughts?

<o​frnxmr:xmr.mx> Now*

<p​reland:monero.social> 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:

<p​reland:monero.social> 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<clipped message>

<p​reland:monero.social> ” method to connect into the network, so the simple mode using I2P should do something similar.

<p​reland:monero.social> 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 <clipped message>

<p​reland:monero.social> 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<clipped message>

<p​reland:monero.social> 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<clipped message>

<p​reland:monero.social> 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.

<p​reland:monero.social> 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<clipped message>

<p​reland:monero.social> 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<clipped message>

<p​reland:monero.social> nding of either Monero or I2P, and you get where we are now.

<p​reland:monero.social> 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.

<p​reland:monero.social> 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

<o​frnxmr:xmr.mx> 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)

<o​frnxmr:xmr.mx> Youre probably wasting your time, and asking for trouble in an implementation that doesn't really make sense

<o​frnxmr:xmr.mx> --proxy=<i2psocks:port> 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

<o​frnxmr:xmr.mx> Simple mode is an ugly hack that just uses --no-sync. Simple bootstrap mode doesnt issues --no-sync - it syncs the blockchain over clearnet

<o​frnxmr:xmr.mx> 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.

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> basically, its a mess on top of a mess

<o​frnxmr:xmr.mx> 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

<3​21bob321:monero.social> plowsofi dmd you, answer me !

<3​21bob321:monero.social> 100% uptime sir

👍

<s​pirobel:kernal.eu> 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 <clipped message>

<s​pirobel:kernal.eu> 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<clipped message>

<s​pirobel:kernal.eu> resses with different customers doesnt magically split it up, because they all got it from the same known entity.

<s​pirobel:kernal.eu> 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<clipped message>

<s​pirobel:kernal.eu> es suspending their XMR withdrawals. <--- can someone explain what this even means? the arguments to deprecate them are flimsy at best

<s​pirobel:kernal.eu> quoted from the github issue:

<s​pirobel:kernal.eu> >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<clipped message>

<s​pirobel:kernal.eu> spending their XMR withdrawals.

<s​pirobel:kernal.eu> \<--- can someone explain what this even means? the arguments to deprecate them are flimsy at best

<s​pirobel:kernal.eu> 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<clipped message>

<s​pirobel:kernal.eu> 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<clipped message>

<s​pirobel:kernal.eu> ddresses with different customers doesnt magically split it up, because they all got it from the same known entity.

<s​pirobel:kernal.eu> 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<clipped message>

<s​pirobel:kernal.eu> 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<clipped message>

<s​pirobel:kernal.eu> dresses with different customers doesnt magically split it up, because they all got it from the same known entity.

<o​frnxmr:xmr.mx> You cant send funds to more than 1 intg address at a time

<o​frnxmr:xmr.mx> Theres only 1 space for payment id in txextra

<s​pirobel:kernal.eu> so the exchange that wants to send non uniform transactions to batch things can just not allow withdrawing to integrated addresses. problem solved

<s​pirobel:kernal.eu> end users can easily make integrated addresses in any case

<p​lowsof:matrix.org> Dan (Is not the man & Braxman Tomsparks Qtip USAID Advocate) Backup: ofrnxmr node stability response team have solved the issue, thank you sirs

<s​pirobel:kernal.eu> end users cant easily make integrated addresses in any case

<o​frnxmr:xmr.mx> The i2p nodes had 100% uptime!

<o​frnxmr:xmr.mx> The "probably" in the quote is just looking for an excuse for binance's empty reserves

<o​frnxmr:xmr.mx> I dont know of any exchange that allows wd to intg address

<s​pirobel:kernal.eu> hands getting waved left and right

<s​pirobel:kernal.eu> yeah it does not make a ton of sense. this issue should just be closed.

[CCS Proposals] Lee Clagett opened merge request #553: vtnerd 2025 Q1 Proposal repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/553