hey guys

how do I use xmr.to to convert bitcoin to monero?

they only do monero>btc

you need to use a different service for btc>xmr

shoot

that's what it looked like niocbrrrrrr

Hello, anyone know this issue and how to fix? bpa.st/raw/QFJA

<rbrunner7> My first attempt would be to delete the wallet cache file, the file that has simply the name of the wallet, and of course *not* the .keys file. The wallet will see the missing file and regenerate it.

Kurogane

<rbrunner7> 黒鉄?

Announcement on getmonero of the GUI 0.16: web.getmonero.org/2020/05/30/monero-GUI-0.16-released.html

Wow, monero-wallet-cli 0.16 is lightning fast (at least in conjunction with my own node). Thanks for the great work.

hi

Fun saving 20% space by activating fs compression. Thought the lmdb was compressed heh.

How does the current ring member selection work, exactly? Because sometimes I see some weird ring member selection for some inputs

Like this one: xmrchain.net/tx/ed3e393ef3d756cbea1…e7a226dd6d104bb3c0fddd01f29faa875a6

Key image 00 has one member from 2017, and all the others are at most a month and a half old

it is weighted to have more recenpt outputs

since most often people respend quickly

Right, but that's still a massive gap

I don't think that is too unusual

Kinda sticks out like a sore thumb

it is supposed to pick mostly recent and a few older ones as decoys

can't find exact algo in code

you could ask in dev or research-lab channels

That ASCII art is scaled to the range in use, so is confusing.

or just ask mooo cause I'm sure he knows

have you seen wownero's ascii art?

I'm looking at the individual timestamps directly

kind of weird that the word "decoy" does not appear at all in the entire source code

in that tx, most images have ring members spanning a few months at most (like, feb 2020 to may 2020), and then some have 10 members from 2020 and one from 2019/2018/2017

Perhaps it's just my intuition that is wrong, but I would expect a few more decoys from 2019/2018 for the same image

Why is it weird ? That's a word people who do not code started using. They're fake outs in the code.

I just see and hear the word decoy most often used to describe non-spending ring sig members

and it doesn't appear at all in the source code

surprising maybe

maybe not

It's fashion. A few years ago people mostly talked about mixins.

yea, it's hard to parse through the amount of search results you get for "mixin" tho

Despite those outputs never being called mixins in the source either :)

Anyway, the fake outs are selected using a gamma distribution. More weight to young outputs as jwinter said.

If you want to understand why it sometimes picks old ones, consider that if it never did, you could not spend old outs without them being pinpointed as the real spend.

It roughly approximates the expected actual spend behaviour based on studying the partially known spend distribution in monero based on mixin 0 and deductions from a few years back (see paper by Miller et al).

<moneromooo "If you want to understand why it"> I'm aware of that - It's just that picking 10 members from 2020 and 1 from 2017 for one key image makes the 2017 one stick out a lot - even for a gamma distribution

^ like that

hello

i'm trying to transfer for new chain but is not possible even after %blocks

any help on this paste.laravel.io/c1c1a57d-cece-4d13-aeda-3b30147c856e

The wallet seems to be getting very very old outputs. Is the daemon synced ?

yes

is new chain everything work fine

except transfer

Can you run these in the daemon:

status

output_histogram @0

Height: 373/373 (100.0%) on mainnet, not mining, net hash 6.18 kH/s, v12, up to date, 1(out)+1(in) connections, uptime 0d 1h 57m 31s

Oh, when you mean new chain, do you mean you updated monerod (it's the same chain really, no conversion) or are you starting from the genesis block ?

from genesis

Hmm. Height 373 should definietly not be v12. Is that a fork (a new coin) ?

new

THen you might have mentioned that instead of making me waste my time.

I assume you made code changes ?

yes

everything is working fine

Then your work to debug ^_^

It *might* be that thew wallet is asking for too many fake outs (it asks for more than it needs in case some are unusable)

Low confidence.

if i go to height 1500 chance are better ?

Yeah, actually probably not. 373 should be easily far enough.

why is this here fee_level.first == 0.0. THROW EXCEPTION:

no change on fee and emission

only on hardfork file and genesis

Well, your debug time since you changed the code.

yea

Error: not enough outputs for specified ring size = 11:output amount = 0.00, found outputs to use = 7Please use sweep_unmixable

always this message

even on sweep_single

or sweep_unmixable

That one does sound like not enough outputs, but 373 is easily enough, unless you changed the lock time ?

no i didnt change anything

i change for tests reason unlock_Window to 0

and wallet says that amount is unlocked

block 0 has version 1 and block 1 has version 12

maybe another CURRENT_TRANSACTION_VERSION is need

i changed RECENT_OUTPUT_RATIO to 0 but still same output

<endor00[m] "timestamps.png"> Sorry, just realized I forgot to ask the question I was leading up to: does it make sense to think that these inputs should be a little more 'spread out' (while still maintaining a gamma distribution) over this large time range, and suspect that the 2017 one is the real spend because it's too far from the others?

is wallet issue and not daemon ?

moneromooo ?

If they're more spread out, it won't follow the same gamma distribution will it.

magnum90: I don't know.

the first error is about fees "fee_level.first == 0.0"

no changes on fees so why this error

Daemon is recent enough, requesting rct distribution

maybe more daymons are needed

i'm testing with only two pc

maybe monero need more tahn 2 daemons to create outputs?