o/

they're watching what I'm doing.

Hi, kinda new here - is there a way to join the public testnet if there is one?

Or is there a way to test monero - well specifically dandelion++

run monerod --testnet, boom you're there

can someone kindly kick off the workflows for monero-project/monero #8665 ?

""Couldn't open wallet: internal error: failed to deserialize keys buffer"" . old.reddit.com/r/monerosupport/comm…cant_import_keys_file_to_gui_wallet . any ideas?

only thing comes to mind is version incompatiblity, or wrong password

but both of those have already been mentioned in that post

I came up with a possible way to create much shorter Monero address, which would be especially useful for Seraphis-Jamptis, and would allow customized addresses.

Basically, once you have a wallet with some coins in it, you send a special "TX" to the blockchain, which doesn't move money (apart from fees required). That TX would contain the full actual address, and an alias.

This system would allow the creation of custom human-readable addresses.

do you then expect the consensus software to prevent duplicate aliases?

we already have OpenAlias ...

hyc: Exactly

hyc: OpenAlias is centralized and not trustless. DNS controls OpenAlias addresses

xfedex[m]: Or just ignore them

ignoring them would be bad, since allowing duplicates to accumulate in the chain would make it harder to actually look up the correct one to use

The advantage of OpenAlias using DNS is that it's an inherently hierarchical namespace, which pretty much eliminates the possibility of collisions / duplicates

with your scheme, there's nothing to prevent squatters from registering well known names before their real users do

hyc: Not sure, but I think it's the same on Ethereum Name System

well...

s/squatters/scammers/ in this case

What if instead of including a custom name for address, you include in the tx the first 20 bytes of the address' keccak hash? Addresses would be shorter without the danger of "name stealing"

OpenAlias is neat, shame .onion doesn't have the ability for tagging arbitrary records on top

xfedex[m]: that would not work with monero's privacy tech (specifically the proofs we need for tx inputs)

UkoeHB: I think you misunderstood what I meant. Once you have a wallet with some coins in it, you send a special "TX" to the blockchain, which doesn't move money (apart from fees required). That TX would contain the full actual address, and its 20-bytes hash.

Any node can thus know that the 20-byte hash translates to the address, and sender node can translate that hash into actual address before sending

monero uses onetime addresses, which are masked user addresses (unique per enote onchain)

I know, in fact the 20-byte hash address would not go on-chain

we also have subaddresses

doesnt seem practical to record all users subaddresses in the chain

Yes, in fact only main wallet address would get stored.

why

the goal of subaddresses is to reduce address reuse

Another way I just thought of: instead of storing the "addresshash>address" on the blockchain, it could be stored on IPFS

on IPFS, fees would be zero, so subaddresses could be shortened too

that would probably be more appropriate than on the monero chain

advertising a fixed address would be ok for some things, like donation addresses I suppose

really the same usecases as OpenAlias

xfedex[m]: "OpenAlias is centralized and not trustless. DNS controls OpenAlias addresses"

I don't understand. DNS is not centralized. I ran my own DNS server for years, and I was free to set up whatever second-level domain I wanted

<rbrunner> "I don't understand. DNS is not..." <- DNS is not centralised but the control is in your governments hands.

Sure. A case of finding the lesser evil. On the one side, the Swiss government that, in theory, could snuff out my domain

On the other hand mechanisms like IPFS with potentially grave spam problems, duplicates without clear resolution, and other niceties

Or bloating our blockchain with non-fungible / recognizable name-setting transactions.

I just saw that DNX TXT entries can have a length of up to 255 characters without any special measures.

So we are probably good with 200 character Jamtis addresses and OpenAlias

*DNS

OpenAlias uses a bit more glue, for example, you need "oa1:xmr recipient_address=" at the start, and maybe "; recipient_name=[...]" afterwards

that is another 43 characters

which leaves just 12 characters for recipient_name

why would you bother with recipient_name ?

you already have foo.sub.domain

you can have it contain the whole character set

> At a minimum, the recipient_address key-value must exist.

that is what you need, but if you want to say for example "Project ABC Donations 🐱"

there are also further keys, anyhow

tx_description / tx_payment_id / tx_amount / address_signature / checksum

but that would probably also grow too large even with old address scheme

that said those keys seem overly verbose

well, if it goes over 255, that's just multiple strings in most cases in the response

hi folks, could I get a LGTM for monero-project/monero #8673 ?

selsta: the FTBFS came from particularly strict gcc flags

this is the debian policy, so it's keeping debian from building. I could commit this patch to debian, but I wanted to check with you folks first.

cjac: where did you add this GCC flag? and why does it cause the compiler to get killed?

if you add some kind of "treat warnings as errors" flag it wouldn't kill the compiler as far as i'm aware

cjac: "this is the debian policy, so it's keeping debian from building." <- package maintainers are free t use whatever compiler options they like

you're only highlighting a warning, not an error

jtgrassie, selsta: no problem. I can patch the debian package, but our policy is to try to offer upstream first. If you don't want this patch, no worries.