Is it possible to delete wallet subaddresses?

how do you mean?

afaiu, they are deterministic, so subaddress at slot 1 will always be x, and subaddress at slot 2 will always be y, etc

i mean, you should be able to transfer everything out of a particular subaddress and to another subaddress or wherever.

but dunno what you mean by delete

delteated?

bahleted

del taco?

To clarify (and out of curiosity), I was wondering whether it's possible to delete the addresses you generate that serve to avoid having you use your primary wallet address

* To clarify (and out of curiosity), I was wondering whether it's possible to delete the addresses you generate that serve to avoid having you use your primary wallet address to receive XMR.

Like, the #1, #2, #3 (and so on) addresses

It's just clutter and I'd like to clear those up

oh, to treat them like one-time addresses?

Exactly!

yah know, there was a subaccount or something at some point that was more like this

i honestly forgot how it all shook out and I've never fiddled with subaddresses that much

lemme fire up the ol' cli

It would be a handy little feature to have in the main Monero GUI wallet and on Cake Wallet

But those addresses seem to appear across my devices that are setup to use my wallet, so perhaps those addresses are permanently tied to my wallet and can't be removed

holy jebus this help menu

okay yeah nuez[m] , if you checkout the cli help

there's account, and then address.

but damn, i have no idea what that syntax is

wonder if there's a readme somewhere

i dunno if address feature exists in the gui

I'm looking at the help output and the commands that are listed, but nothing that would indicate deleting addresses

well, it doesn't delete it i think.

hrm

Ohhh okay. So long as they can be hidden, that's good enough, honestly

yeah.

so basically, when you enter "address new" it creates a new address

and the address is associated with an account (the subaddress)

wow, thats pretty cool

Hmm. For the ability to hide addresses and for this change to occur on any application that hosts your single wallet, that might require an infrastructural update of some kind

I guess it's possible to tolerate having a huge ass list of generated addresses 🤷‍♂️

* I guess it's possible to tolerate having a huge ass list of generated addresses lol 🤷‍♂️

i mean, technically there not really generated, they are just listed. i think its all deterministic so its ultimately just a data management thing, and because i think the wallets lmdb backed now its sorta moot

well, i guess they are generated.

but if you generated like 100 you'd need the wallet to know about all of them because it has to scan the chain for them

ooof.. #bitcoin: "people are a lot more open to donation with lightning than onchain, both because of fees and because they're not leaving a permanent record of their donation, which is something that I'm also not feeling comfortable with when donating"

this is a pretty good proposition for adding XMR as a donation option

sad times. There is a coin for that called monero

actually xmr is perfect for donations and everything else

It was funny hearing McCormack on the privacy podcast recently. BTC is still "maybe privacy by doing these 15 steps and be careful not to mess up at any point" vs SHUM

yes, the cognitive dissonance is incredible

you can do these 15 things, don't do these 30, and even then maybe it won't work when later you do one of these 5 things

... but this is the best optionw e have for freedom and privacy!

seems legit, dumping xmr now

still you can mess up with XMR too, so there are things to be aware of

only a few cases that we know of right

using bitcoin as it exists today is a bit like growing up in a house in a community where all the rooms are bugged and there are nanocameras everywhere. but you knew nothing about them, and then one day many years later you learn about this, and I guess a part of you registers the gravity of it, but the cognitive dissonance kicks in - have people really been listening and seeing everything you thought you were doing in the privacy of your home

your entire life? - and you reason it can't be that bad

or you realize it's just wrong and go live elsewhere (that would be moneroville in our wonderful analogy)

metaphor

thing

is monero on btcpayserver viable today? there was some buzz about it several months ago, then nothing (afaik)

kayront: it was done last year

setup instructions there

fluffypony: do you know anyone who is using it ? i'd like to quickly test how it feels to use

not off the top of my head, no

Think Andreas uses it for his personal shop

^ fluffypony, kayront

ah cool

debug version cant compile

/usr/bin/ld: ../../../monero_crypto_src/amd64/CMakeFiles/monero-crypto-amd64-64-24k.dir/__/__/crypto_sign/ed25519/amd64-64-24k/ge25519_dbl_p1p1.s.o:

relocation R_X86_64_PC32 against symbol `crypto_sign_ed25519_amd64_64_38' can not be used when making a shared object; recompile with -fPIC

there is set(PIC_FLAG "-fPIC") on cmake file

yea, this is known currently

no solution?

you can add -DBUILD_SHARED_LIBS=Off

on cmake file

i'm trying

on makefile there is -D BUILD_SHARED_LIBS=OFF

is possible to compile debug version with depends package

depends has static libraries

dEBRUYNE: i meant with monero payments enabled

i doubt andreas does that

what to do about debug version?

kayront: He has Monero payments enabled, see the tweet

oh.

that's.. unexpected

yet, glorious

he spoke quite well about Monero in a few of his streams earlier this year

basically acknowledging the privacy advantage of Monero

It's a shame Monero never implemented the "address with pre-encrypted target". Then you could do the BTCpay server stuff in JS, in the browser

asymptotically thnx

debug compile with shared_libs=off worked

yanmaani: how does that work?

Inge-: It doesn't because it was never implemented, but

a monero address has 2 bits, a spend key and a view key

you make a nonce, encrypt it to the view key, and you use the view key to identify the transactions

this system would take a view+spend key, generate a random nonce, encrypt it, and discard the view key, and format that as a new type of addr

so address reuse would cause you actual privacy problems

but on the other hand, the address could be generated in the browser

If you think it is of value, you could try describing it in a bit more detail in a post on github.com/monero-project/research-lab

moneromooo: No, this has been proposed and denied

because of the address reuse problem

Ah, fair enough.

does using the same destination address multiple times from different source addresses compromise privacy at all? Or should I use a new subaddress for each transaction both on the sending and receiving end?

If the senders collude, they can deduce they're sending to the same party.

If you have the possibility always use different sub addresses ;)

btw, does mymonero wallet generates different subadresses like monero gui wallet?

Thanks. I'll just use different subaddresses then. I'm new to Monero and trying to build a simple Python app using the cli-wallet-rpc API.