Hi, how do I connect monero payment to my site? I can't find information on the internet(

misrio87[m], maybe this? monerooutreach.org/merchants/monero-payment-processor-guide.html

this seems to be the hot ticket: monerointegrations.com

are people running depends builds directly on their main machines? or are they using depends via gitian?

the depends packages still sets up native_ccache. I guess it'd be useful if you run on a long lived machine

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

we do use depends + ccache on github CI

ok then I'll just tweak it for gitian

I assume this uses native_ccache as I don't see it installed otherwise

depends does, see packages.mk

<hyc> "are people running depends..." <- It's definitely a good feature to be able to run depends directly (as opposed to gitian)

<selsta> "memory leaks reported by asan..." <- I'll have a look on weekend.

v0.17.2.3 binaries are now available on getmonero.org

Thanks to everyone who contributed one way or another!

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?

Btw a reminder that melo.tools automatically produces new docker images for all new Monero tags, including last version hub.docker.com/r/melotools/monero/tags?page=1&ordering=last_updated

Rucknium[m]: we don't have any stats but the daemon prints a message if it's outdated, gui wallets have auto update feature

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.

selsta do you know if 3rd-party wallets use wallet2 or something of their own? They need to apply my fix too.

if they're not using wallet2 what's the likelihood they had that previous optimization

I would expect most existing wallets are just using wallet2 tho

light wallet server / mymonero did not have the integer truncation bug

I don't know about the optimized gamma selection thing

vtnerd: ^

selsta: Oops, what is the optimized gamma selection thing? 😬

jberman's fix

don't know how it's called

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.)

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 (github.com/vtnerd/monero-lws/blob/f…7a00b/src/util/gamma_picker.cpp#L86)

Would it be possible to take spending behavior from e.g. Bitcoin?

I'll submit a PR for it to match wallet2 today vtnerd. I figure integer truncation should also probably match wallet2 spec

selsta: Answered in DM

Ooooh, binary_archive now takes a span in newer source. That totally solves my problem from yesterday :D Thanks vtnerd.

Wish I'd seen that before.

moneromoooo: --fast-block-sync basically only skips PoW verification, right?

or what does it skip exactly?

Skips most tx verification also IIRC.

If you want the exact set, blockchain.cpp.

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.

Probably.

IIRC the default is to block from unregistered. Avoids spammers.

Ok I will switch to a Linux box and use a proper IRC client.

At least one person with [m] in their nick did send me messages fwiw.

You have to register your name on Libera Rucknium[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 (github.com/vtnerd/monero-lws/blob/f…7a00b/src/util/gamma_picker.cpp#L94), and not from 10 blocks earlier as is the case in wallet2

(github.com/monero-project/monero/bl…/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

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

That could also give us an estimate of the proportion of on-chain transactions that are constructed using those two wallets.