hi folks, did someone break importing key images? 😛

context is I have keyimage files saved from last year and it looks like the latest version of monero wont import my keyimages anymore: paste.centos.org/view/9a9ffc60

i suppose my question is if the keyimage file is required to be exported with the same monero cli version

did the format change? paste.centos.org/view/5de091d2

sigh

like do we really need to change the key image file format :(

I suppose at a minimum itd be nice to get a message that the keyimage file is an old version

muff1nman[m]: see monero-project/monero #6690

you can activate load-deprecated-formats to load the old format

05:53 <muff1nman[m]> like do we really need to change the key image file format :( <-- according to PR reduces attack surface, fewer known crashes and less boost overall is quite an improvement, though I agree that the error message could be better

hello

i have an old issue about compiling for android on docker

there is a ExternalProject_Add(generate_translations_header

that dont work

this create a binary with gcc and insert it to be used for compiling translations files

but for some reasons insert dont work

the reason is that is trying to compile with clang and gcc

any help about error with translations files?

PSA: Ledger monero app now out of developer mode, v 1.7.3 available

If anyone's interested in a "city builder" multiplayer game on a chain (based on monero code), feel free to join ##townforge and see the links in /topic (testnet only atm, I want to see what balance changes are needed).

Also on Reddit: old.reddit.com/r/Monero/comments/j6…ge_private_blockchain_game_released

I look forward to the echo this will generate :)

moneromooo: i thought the game idea is cool, and then you mentioned ultima online 🤗

Technically I didn't, syksy did :D Never played it so I dunno whether the comparison is apt.

so i dont really understand it, but why would there be a need to have any xmr changes to use xmr in the game?

Because all the game rules are consensus rules. All nodes check what a player does it allowed by game rules.

Including automated deposits/withdrawals, but also stuff like building where, materials, farming, etc, etc. Everything is.

got ya

so its not like just transferring value in game which would have been ok to use xmr?

That's basically what using monero would have been. A way to pay in, then a typical game with a central server that decides what goes on. Which is... not so interesting.

Wider appeal though, since you woud not have to wait for a block for your actions to become "real".

As it is, that's the bit that's annoying. Waiting for blocks for everything.

So it's not gonna go well with non crypto types at all :)

But it makes it interesting.

Technically anyway.

yes it does

ill be following along.

i always wondered if you could make a game around mining ore out of the ground as the games main economy that would be tied to mining crypto. so there would be game value and outside value as well.

Kinda what it does here. There's a "last resort" supply of building materials you can buy. That money goes into the town treasuries, which gets redistributed to players with time based on how well they do in game.

I don't think that waiting for blocks kills the game,...it just becomes part of the challange of the game.

And then it just becomes normal.

Right, but it won't appeal to FPS types, say.

You do stuff, and then you wait a minute for it to be confirmed.

creators vs destructors :)

so will the game currency have the ability to atomic swap with xmr?

:D

i dont game, but i loved UO.

I don't think so. I asked sarang whether it was possible in theory, and it is, but it would make the monero txes stand out (as in, "this is an atomic swap with townforge") so I dropped the idea.

would this not be an issue for the BTC <> XMR CCS proposal?

Apparently not.

Then again I can modify the TF code however I want to make this happen if it doesn't impact monero privacy, but I'm not a crypto geek so I don't want to do such a crypto scheme myself or I'll screw things up.

Now, if someone who knew what they were doing were to actually work on such a scheme where the monero side doens't scream "I am an atomic swap" then I'd be all for it.

i hear ya. really cool project either way.

Thank you :)

the BTC-XMR atomic swap works because it relies on BTC scripting support

for XMR-TF, one or the other chain needs to add something like script operations

otherwise no go

And I could add whatever's needed since I don't need to restrict myself to existing monero consensus.

what happens to an atomic swap txn if it winds up being in an alt chain?

gets undone I suppose

AFAIK it becomes minable again on the other (main) chain.

Question: Does the monero-wallet-cli support environment variables (instead of command line args)? Because I can't find anything in various docs sites.

No.

Not in general.

Another Q: What is the recommended way to receive XMR from a 3rd party (e.g. a regulated exchange). Should I just create an "integrated address" and re-use it everytime I receive XMR from same sender?

create a subaddress

integrated addresses are deprecated

An integrated address is just packaged standard address plus short encrypted payment id. You can do that if you want to know where it comes from, bit it won't prevent the sender from knowng they're sending to the same address.

but yes, use one per sender

Is the "unofficial" docs site monerodocs.org trustworthy? E.g. the explanation of the differences between subaddress and integrated in monerodocs.org/public-address/subaddress ?

My impression was the integrated address is somewhat "ephemeral" because unless I note it down, I can't find it, but it starts with a 4... like any primary address. Whereas the subaddresses can be found under primary address, but start with an 8 ...

At a very quick glance, it seems ok.

Integrated address is standard address, pretty much.

It is an encoded way of sayinbg "please send to this standard address, while adding payment id XXXX to the tx".

In my mind, the integrated address was like an "invoice", I create it and after it gets paid it is never reused. Whereas subaddresses are for more permanent use. But you said the integrated addresses are deprecated.

Invoice as you mention is a sane use, yes. Subaddresses are not really meant to be reused, though they technically can.

Both integrated addresses and subaddresses can do the invoice case well.

Only subaddresses require access to the .. private view key?

Good point, you need the secret view key to generate a subaddress.

If today you were asked to create a new eshop that accepted Monero payments, would you ask customers to pay to an integrated address or to a subaddress?

Subaddress.

I would strongly prefer generating per-customer subaddresses

or per transaction, but could be a bit much to keep track of

Per customer seems good, since reusing the same per customer does not imply they can be seen to be the same on the chain.

OK, so the suggestions in section "Integrated addresses vs subaddresses" of monerodocs.org/public-address/integrated-address are not quite correct.

Which bits ?

"Individuals should prefer subaddresses to receive payments. This is to improve privacy in certain scenarios. See article on subaddresses for details. Businesses accepting payments in an automated way should prefer integrated addresses. The rationale is as follows: ..."

well, their arguments are sound enough.

I also noticed that during the past 30 days a Chinese mining pool has shot up to #3 position with ~130MH/s. I assume it's a good thing ?

@Inge- sure, but @hyc said above that int.addresses are deprecated. That's why I asked.

Anyway, in both cases of subaddresses or int.addresses, the balance is stored in the primary address, right? So if I delete the wallet files and restore from the 25 word seed, it will find all funds sent to subaddresses.

Yes.

Ah, I just tried deleting a test wallet and re-creating it from just the 25 word seed. When I create new subaddresses they are the same and in the same order as before, so I assume they are created deterministically. Whereas integrated addresses have a random ID, different everytime. Is my understanding correct?

They are deterministic, yes. Integrated addresses use whatever uint64_t you give. The "integrated_address" command in monero-wallet-cli does roll a random one if you don't give it one.

Do we agree that if I can prove a Tx in the GUI (latest 0:17.0:1) this means it was sent and received ? The guy tell me it doesn't show up

tell him to restore from seed, that can help in some cases where funds are not showing up for whatever reason

thx gonna tell him that

coppa: If the tx is actually present on the blockchain, yes

dEBRUYNE: thanks

There ought to be something like "integrated addresses for untrusted exchanges"

so you generate a master address, and then you can generate subaddresses from that in JS

so you could give your master address to the exchange, and it could do address derivation in the web client