<v​tnerd:monero.social> Technically you can't until carrot outgoing view keys get deployed. Then the view balance tier can track all incoming and outgoing

<v​tnerd:monero.social> Right now we can filter the majority of txes my tracking all decoy+real references

<v​tnerd:monero.social> *by tracking

<v​tnerd:monero.social> After fcmp++ legacy wallet can only infer spends by incoming change. If an attacker does a sweep this will be completely missed. The protocol by every wallet is to add change, even if zero, so lws like backends can identify them

Protocol?

Isn't that apart of consensus?

Like every TX must have 2 outputs even if change is 0

<v​tnerd:monero.social> The carrot spec says specifically that wallets should it. It's not consensus and totally non enforceable, thus the attacker sweep scenario

<v​tnerd:monero.social> But at least putting in the spec makes all valid implementators aware of the issue

And how do legacy wallet infer which of the output is the change or main

I mean programs like LWS without the spend key

<v​tnerd:monero.social> Well the change is sent to their key so it's obvious

<v​tnerd:monero.social> If you do a self send/churn then it's just incoming outputs which is no big deal

<v​tnerd:monero.social> Or I see, iirc carrot has a way of indicating whether it's change so you know a spend occurred

How do you know the wallet sent that change to themselves

I thought calculating the key image required the spend key

<v​tnerd:monero.social> With legacy, yes. The wallet sees the change as a receive

Ah I meant legacy not carrot

In the current impl, dummy enotes are sent to dummy addresses, but in Carrot that changes. Carrot enotes are attributable, i.e. 'send' vs 'change', however any tx author can build an enote as 'change' so it isn't 100% reliable.

<v​tnerd:monero.social> Legacy wallets will use the carrot protocol after fcmp++ but won't have all the features of the newer keys. Tracking spends with legacy is handled differently pre/post fcmp++. Before fcmp it's handled by tracking the decoy list of the rings. Post fcmp it's handled by the carrot protocol marking an output of the tx as change - the backend records all inputs and let's the spend key figure it out

<v​tnerd:monero.social> Yes, the backend is blinded from attacks. Otoh, the spend webhooks of lws are actually very useful with new/carrot addresses as it knows exactly when an event occurred

I hope carrot rolls out soon

I don't want to rely on a spend key or periodically exporting key images

I set the parameters for IPv6 only, but the sync p2p is still IPv4.

<o​frnxmr:monero.social> Did u disable ipv4? And did u add ipv6 seed nodes?

I disable IPv4 in the parameters by only enable: "p2p-bind-ipv6-address=::" "rpc-use-ipv6=true" "rpc-bind-ipv6-address=::"

<o​frnxmr:monero.social> --p2p-ignore-ipv4

<o​frnxmr:monero.social> `--seed-node <arg>` need to add an ipv6 seed

<o​frnxmr:monero.social> #monero-support

ok

tobtoht opened pull request #10383: ci: depends: bump container to ubuntu 22.04

> monero-project/monero #10383

tobtoht opened pull request #10384: ci: bump deprecated actions

> monero-project/monero #10384

the xmr mainnet has gone extremely slow over the last 15mins, is it just me or its really happening

i am a ping response in range 124ms to 2s

i am getting a ping response in range 124ms to 2s

<o​frnxmr:xmr.mx> Just you

any particular reason?

<o​frnxmr:xmr.mx> Also, no idea what youre referring to as "xmr mainnet". Connections to monerod peers? Connection to a remote rpc?

monerod  peers

<j​pk68:matrix.org> I think he means that the entire network has somehow slowed, by some act of god or something

<j​pk68:matrix.org> No offense, but I doubt that could happen

i just checked the overall linkspeed is up and sitting at 2gbps

also seeing way too many ip getting blocked

while trying to sync

any ideas

<o​frnxmr:xmr.mx> paste.debian.net << send logs

<o​frnxmr:xmr.mx> And since this isnt development related, #monero-support

<j​pk68:matrix.org> Is it fine to use CHECK_AND_ASSERT_MES in networking code?

<v​tnerd:monero.social> It's more important to note whether it throws or returns a code and then writing the rest to match behavior

That one returns. CHECK_AND_ASSERT_THROW_MES throws.

vtnerd opened pull request #10385: Fix DNS resolve UB [0.18]

> monero-project/monero #10385

selsta opened pull request #10386: abstract_tcp_server2: add missing return

> monero-project/monero #10386

selsta opened pull request #10387: abstract_tcp_server2: add missing return [release-v0.18]

> monero-project/monero #10387