00:56:36 <locustlord> hey guys
00:56:59 <locustlord> how do I use xmr.to to convert bitcoin to monero?
00:57:48 <niocbrrrrrr> they only do monero>btc
00:58:13 <niocbrrrrrr> you need to use a different service for btc>xmr
00:58:40 <locustlord> shoot
00:58:52 <locustlord> that's what it looked like niocbrrrrrr
06:44:56 <Kurogane> Hello, anyone know this issue and how to fix? https://bpa.st/raw/QFJA
08:12:36 <xmrmatterbridge> <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.
08:13:16 <Jackman2> Kurogane
09:03:55 <xmrmatterbridge> <rbrunner7> 黒鉄?
11:32:22 <ErCiccione[m]> Announcement on getmonero of the GUI 0.16: https://web.getmonero.org/2020/05/30/monero-GUI-0.16-released.html
13:08:53 <goldmine_compact> Wow, monero-wallet-cli 0.16 is lightning fast (at least in conjunction with my own node). Thanks for the great work.
14:34:10 <KrishnAncap[m]> hi
18:17:27 <zib> Fun saving 20% space by activating fs compression. Thought the lmdb was compressed heh.
22:19:19 <endor00[m]> How does the current ring member selection work, exactly? Because sometimes I see some weird ring member selection for some inputs
22:19:54 <endor00[m]> Like this one: https://xmrchain.net/tx/ed3e393ef3d756cbea10915d82face7a226dd6d104bb3c0fddd01f29faa875a6
22:20:09 <endor00[m]> Key image 00 has one member from 2017, and all the others are at most a month and a half old
22:20:26 <jwinterm> it is weighted to have more recenpt outputs
22:20:34 <jwinterm> since most often people respend quickly
22:22:37 <endor00[m]> Right, but that's still a massive gap
22:23:20 <jwinterm> I don't think that is too unusual
22:23:28 <endor00[m]> Kinda sticks out like a sore thumb
22:23:32 <jwinterm> it is supposed to pick mostly recent and a few older ones as decoys
22:23:42 <jwinterm> can't find exact algo in code
22:23:50 <jwinterm> you could ask in dev or research-lab channels
22:24:04 <moneromooo> That ASCII art is scaled to the range in use, so is confusing.
22:24:27 <jwinterm> or just ask mooo cause I'm sure he knows
22:24:42 <azy> have you seen wownero's ascii art?
22:25:09 <endor00[m]> I'm looking at the individual timestamps directly
22:25:51 <jwinterm> kind of weird that the word "decoy" does not appear at all in the entire source code
22:26:43 <endor00[m]> 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
22:27:46 <endor00[m]> Perhaps it's just my intuition that is wrong, but I would expect a few more decoys from 2019/2018 for the same image
22:29:15 <moneromooo> Why is it weird ? That's a word people who do not code started using. They're fake outs in the code.
22:30:04 <jwinterm> I just see and hear the word decoy most often used to describe non-spending ring sig members
22:30:15 <jwinterm> and it doesn't appear at all in the source code
22:30:20 <jwinterm> surprising maybe
22:30:21 <jwinterm> maybe not
22:30:47 <moneromooo> It's fashion. A few years ago people mostly talked about mixins.
22:31:05 <jwinterm> yea, it's hard to parse through the amount of search results you get for "mixin" tho
22:31:08 <moneromooo> Despite those outputs never being called mixins in the source either :)
22:35:20 <moneromooo> Anyway, the fake outs are selected using a gamma distribution. More weight to young outputs as jwinter said.
22:35:55 <moneromooo> 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.
22:37:02 <moneromooo> 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).
22:38:48 <endor00[m]> <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
22:40:07 * endor00[m] uploaded an image: timestamps.png (9KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/RwMmQGpiQIwUjQHxRdwoBqDB >
22:40:15 <endor00[m]> ^ like that
23:17:22 <magnum90> hello
23:20:46 <magnum90> i'm trying to transfer for new chain but is not possible even after %blocks
23:20:56 <magnum90> any help on this https://paste.laravel.io/c1c1a57d-cece-4d13-aeda-3b30147c856e
23:24:30 <moneromooo> The wallet seems to be getting very very old outputs. Is the daemon synced ?
23:25:24 <magnum90> yes
23:25:57 <magnum90> is new chain everything work fine
23:26:32 <magnum90> except transfer
23:27:59 <moneromooo> Can you run these in the daemon:
23:28:37 <moneromooo> status
23:28:46 <moneromooo> output_histogram @0
23:29:35 <magnum90> 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
23:29:38 <moneromooo> 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 ?
23:29:49 <magnum90> from genesis
23:30:01 <moneromooo> Hmm. Height 373 should definietly not be v12. Is that a fork (a new coin) ?
23:30:07 <magnum90> new
23:30:26 <moneromooo> THen you might have mentioned that instead of making me waste my time.
23:30:52 <moneromooo> I assume you made code changes ?
23:31:00 <magnum90> yes
23:31:15 <magnum90> everything is working fine
23:31:18 <moneromooo> Then your work to debug ^_^
23:31:56 <moneromooo> 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)
23:32:04 <moneromooo> Low confidence.
23:32:35 <magnum90> if i go to height 1500 chance are better ?
23:32:38 <moneromooo> Yeah, actually probably not. 373 should be easily far enough.
23:33:17 <magnum90> why is this here fee_level.first == 0.0. THROW EXCEPTION:
23:33:33 <magnum90> no change on fee and emission
23:33:48 <magnum90> only on hardfork file  and genesis
23:35:35 <moneromooo> Well, your debug time since you changed the code.
23:36:16 <magnum90> yea
23:36:31 <magnum90> Error: not enough outputs for specified ring size = 11:output amount = 0.00, found outputs to use = 7Please use sweep_unmixable
23:36:48 <magnum90> always this message
23:36:54 <magnum90> even on sweep_single
23:37:04 <magnum90> or sweep_unmixable
23:37:27 <moneromooo> That one does sound like not enough outputs, but 373 is easily enough, unless you changed the lock time ?
23:37:40 <magnum90> no i didnt change anything
23:38:28 <magnum90> i change for tests reason unlock_Window to 0
23:38:54 <magnum90> and wallet says that amount is unlocked
23:42:33 <magnum90> block 0 has version 1 and block 1 has version 12
23:43:46 <magnum90> maybe another CURRENT_TRANSACTION_VERSION is need
23:45:01 <magnum90> i changed RECENT_OUTPUT_RATIO to 0 but still same output
23:46:42 <endor00[m]> <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?
23:48:56 <magnum90> is wallet issue and not daemon ?
23:49:38 <magnum90> moneromooo ?
23:49:47 <moneromooo> If they're more spread out, it won't follow the same gamma distribution will it.
23:50:19 <moneromooo> magnum90: I don't know.
23:52:08 <magnum90> the first error is about fees "fee_level.first == 0.0"
23:52:20 <magnum90> no changes on fees so why this error
23:57:46 <magnum90> Daemon is recent enough, requesting rct distribution
23:58:02 <magnum90> maybe more daymons are needed
23:58:16 <magnum90> i'm testing with only two pc
23:58:40 <magnum90> maybe monero need more tahn 2 daemons to create outputs?