01:44:02 <misrio87[m]> Hi, how do I connect monero payment to my site? I can't find information on the internet(
01:56:44 <gingeropolous> misrio87[m], maybe this? https://www.monerooutreach.org/merchants/monero-payment-processor-guide.html
01:58:13 <gingeropolous> this seems to be the hot ticket: https://monerointegrations.com/
02:13:37 <hyc> are people running depends builds directly on their main machines? or are they using depends via gitian?
02:14:32 <hyc> the depends packages still sets up native_ccache. I guess it'd be useful if you run on a long lived machine
02:15:09 <hyc> but if nobody is running it that way, we should axe it. otherwise I need to special case it to get rid of it when running under gitian
02:17:52 <selsta> we do use depends + ccache on github CI
02:18:10 <hyc> ok then I'll just tweak it for gitian
02:18:32 <selsta> https://github.com/monero-project/monero/blob/master/.github/workflows/depends.yml
02:19:01 <selsta> I assume this uses native_ccache as I don't see it installed otherwise
02:19:15 <hyc> depends does, see packages.mk
07:07:01 <mj-xmr[m]> <hyc> "are people running depends..." <- It's definitely a good feature to be able to run depends directly (as opposed to gitian)
07:07:45 <mj-xmr[m]> <selsta> "memory leaks reported by asan..." <- I'll have a look on weekend.
16:49:38 <binaryFate> v0.17.2.3 binaries are now available on getmonero.org
16:49:52 <binaryFate> Thanks to everyone who contributed one way or another!
16:50:04 * selsta waits for bug reports
16:53:21 <Rucknium[m]> Question: what is the practical significance of this, specifically regarding jberman 's fix to the mixin selection algorithm? How quick is adoption of a new binary without a hard fork, typically?
16:57:37 <binaryFate> Btw a reminder that melo.tools automatically produces new docker images for all new Monero tags, including last version https://hub.docker.com/r/melotools/monero/tags?page=1&ordering=last_updated
17:03:22 <selsta> Rucknium[m]: we don't have any stats but the daemon prints a message if it's outdated, gui wallets have auto update feature
17:11:13 <Rucknium[m]> I see. I think the rate of adoption could also be estimated via a close examination of the data on the blockchain. Or, more precisely, the rate of adoption among users who are actually broadcasting transactions, weighted by the number of transactions that they broadcast.
17:14:54 <sech1> selsta do you know if 3rd-party wallets use wallet2 or something of their own? They need to apply my fix too.
17:18:04 <hyc> if they're not using wallet2 what's the likelihood they had that previous optimization
17:18:25 <hyc> I would expect most existing wallets are just using wallet2 tho
17:22:53 <selsta> light wallet server / mymonero did not have the integer truncation bug
17:23:07 <selsta> I don't know about the optimized gamma selection thing
17:23:09 <selsta> vtnerd: ^
17:24:40 <Rucknium[m]> selsta: Oops, what is the optimized gamma selection thing? 😬
17:25:11 <selsta> jberman's fix
17:25:15 <selsta> don't know how it's called
17:25:37 <selsta> https://github.com/monero-project/monero/pull/7821
17:28:39 <Rucknium[m]> Oh ok. I thought it was something else. Frankly, it is far from optimal as it stands, even with jberman 's fix. I am working on a deeper overhaul that would provide an optimal solution in a particular sense. (Although to be clear I am not sure it would remain optimal if deliberately manipulated by an adversary. i am trying to think through ways to make it resistant to attack.)
17:39:34 <jberman[m]> lws/mymonero also have the same bug missing earliest spents (that 7821 fixes) because like wallet2, the gamma distr is applied starting from 10 blocks earlier than chain tip (https://github.com/vtnerd/monero-lws/blob/f49fa78d958b4f128e3508fbc7cff868fa97a00b/src/util/gamma_picker.cpp#L86)
17:40:50 <selsta> Would it be possible to take spending behavior from e.g. Bitcoin?
17:41:27 <jberman[m]> I'll submit a PR for it to match wallet2 today vtnerd. I figure integer truncation should also probably match wallet2 spec
17:45:10 <Rucknium[m]> selsta: Answered in DM
17:51:38 <moneromoooo> Ooooh, binary_archive now takes a span in newer source. That totally solves my problem from yesterday :D Thanks vtnerd.
17:51:55 <moneromoooo> Wish I'd seen that before.
17:56:15 <selsta> moneromoooo: --fast-block-sync basically only skips PoW verification, right?
17:56:53 <selsta> or what does it skip exactly?
17:57:45 <moneromoooo> Skips most tx verification also IIRC.
17:58:22 <moneromoooo> If you want the exact set, blockchain.cpp.
18:01:41 <Rucknium[m]> moneromoooo : Are you blocking DMs from Matrix? I was able to DM selsta, but not you. I suppose I could fiddle with an IRC client again.
18:03:13 <moneromoooo> Probably.
18:03:48 <moneromoooo> IIRC the default is to block from unregistered. Avoids spammers.
18:06:18 <Rucknium[m]> Ok I will switch to a Linux box and use a proper IRC client.
18:08:42 <moneromooo> At least one person with [m] in their nick did send me messages fwiw.
18:14:35 <selsta> You have to register your name on Libera Rucknium[m]
18:15:18 <selsta> https://kparal.wordpress.com/2021/06/01/connecting-to-libera-chat-through-matrix/
18:25:08 <jberman[m]> Important update: upon closer reading, it seems I misread monero-lws and it does NOT seem to have the same recent spends are linkable bug. It appears as though its `num_rct_outputs` equivalent starts from the chain tip (https://github.com/vtnerd/monero-lws/blob/f49fa78d958b4f128e3508fbc7cff868fa97a00b/src/util/gamma_picker.cpp#L94), and not from 10 blocks earlier as is the case in wallet2
18:25:08 <jberman[m]> (https://github.com/monero-project/monero/blob/8fde011dbeb56ab92a909710567b964186671247/src/wallet/wallet2.cpp#L1022-L1023). Which means the algo there *is* applying the gamma distr from chain tip, and then throwing away outputs too recent to be spent
18:25:29 <jberman[m]> MyMonero uses this implementation as well. This would be a significant oversight on my part because it means very recent spends observed on chain are NOT 100% guaranteed linkable, since users of monero-lws/MyMonero could still feasibly produce very recent spents as decoys. I'm going to sanity check by running simulations of the code to confirm
18:29:22 <Rucknium[m]> That could also give us an estimate of the proportion of on-chain transactions that are constructed using those two wallets.