00:04:55 <m-relay_> <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
00:05:31 <m-relay_> <v​tnerd:monero.social> Right now we can filter the majority of txes my tracking all decoy+real references
00:05:43 <m-relay_> <v​tnerd:monero.social> *by tracking
00:07:58 <m-relay_> <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
00:09:06 <Cindy> Protocol?
00:09:12 <Cindy> Isn't that apart of consensus?
00:09:24 <Cindy> Like every TX must have 2 outputs even if change is 0
00:10:51 <m-relay_> <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
00:11:19 <m-relay_> <v​tnerd:monero.social> But at least putting in the spec makes all valid implementators aware of the issue
00:11:56 <Cindy> And how do legacy wallet infer which of the output is the change or main
00:12:09 <Cindy> I mean programs like LWS without the spend key
00:12:35 <m-relay_> <v​tnerd:monero.social> Well the change is sent to their key so it's obvious
00:13:01 <m-relay_> <v​tnerd:monero.social> If you do a self send/churn then it's just incoming outputs which is no big deal
00:13:42 <m-relay_> <v​tnerd:monero.social> Or I see, iirc carrot has a way of indicating whether it's change so you know a spend occurred
00:13:52 <Cindy> How do you know the wallet sent that change to themselves
00:14:10 <Cindy> I thought calculating the key image required the spend key
00:14:42 <m-relay_> <v​tnerd:monero.social> With legacy, yes. The wallet sees the change as a receive
00:14:53 <Cindy> Ah I meant legacy not carrot
00:18:15 <UkoeHB> 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.
00:18:15 <m-relay_> <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
00:19:46 <m-relay_> <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
00:20:03 <Cindy> I hope carrot rolls out soon
00:20:23 <Cindy> I don't want to rely on a spend key or periodically exporting key images
02:44:06 <armtux> I set the parameters for IPv6 only, but the sync p2p is still IPv4.
02:46:02 <m-relay_> <o​frnxmr:monero.social> Did u disable ipv4? And did u add ipv6 seed nodes?
02:48:33 <armtux> I disable IPv4 in the parameters by only enable: "p2p-bind-ipv6-address=::" "rpc-use-ipv6=true" "rpc-bind-ipv6-address=::"
03:31:35 <m-relay_> <o​frnxmr:monero.social> --p2p-ignore-ipv4
03:32:56 <m-relay_> <o​frnxmr:monero.social> `--seed-node <arg>` need to add an ipv6 seed
03:37:09 <m-relay_> <o​frnxmr:monero.social> #monero-support
03:38:28 <armtux> ok
10:00:52 <xmr-pr> tobtoht opened pull request #10383: ci: depends: bump container to ubuntu 22.04
10:00:53 <xmr-pr> > https://github.com/monero-project/monero/pull/10383
10:15:52 <xmr-pr> tobtoht opened pull request #10384: ci: bump deprecated actions
10:15:53 <xmr-pr> > https://github.com/monero-project/monero/pull/10384
14:18:08 <whatsayjose1980> the xmr mainnet has gone extremely slow over the last 15mins, is it just me or its really happening
14:20:21 <whatsayjose1980> i am a ping response in range 124ms to 2s
14:21:00 <whatsayjose1980> i am getting a ping response in range 124ms to 2s
14:21:15 <m-relay_> <o​frnxmr:xmr.mx> Just you
14:22:08 <whatsayjose1980> any particular reason?
14:22:08 <m-relay_> <o​frnxmr:xmr.mx> Also, no idea what youre referring to as "xmr mainnet". Connections to monerod peers? Connection to a remote rpc?
14:22:22 <whatsayjose1980> monerod  peers
14:23:04 <m-relay_> <j​pk68:matrix.org> I think he means that the entire network has somehow slowed, by some act of god or something
14:23:22 <m-relay_> <j​pk68:matrix.org> No offense, but I doubt that could happen
14:25:02 <whatsayjose1980> i just checked the overall linkspeed is up and sitting at 2gbps
14:27:55 <whatsayjose1980> also seeing way too many ip getting blocked
14:28:05 <whatsayjose1980> while trying to sync
14:28:47 <whatsayjose1980> any ideas
15:03:07 <m-relay_> <o​frnxmr:xmr.mx> paste.debian.net << send logs
15:03:41 <m-relay_> <o​frnxmr:xmr.mx> And since this isnt development related,  #monero-support
15:59:18 <m-relay_> <j​pk68:matrix.org> Is it fine to use CHECK_AND_ASSERT_MES in networking code?
16:00:51 <m-relay_> <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
16:04:04 <moneromooo> That one returns. CHECK_AND_ASSERT_THROW_MES throws.
18:45:52 <xmr-pr> vtnerd opened pull request #10385: Fix DNS resolve UB [0.18]
18:45:53 <xmr-pr> > https://github.com/monero-project/monero/pull/10385
22:00:52 <xmr-pr> selsta opened pull request #10386: abstract_tcp_server2: add missing return
22:00:53 <xmr-pr> > https://github.com/monero-project/monero/pull/10386
23:45:52 <xmr-pr> selsta opened pull request #10387: abstract_tcp_server2: add missing return [release-v0.18]
23:45:53 <xmr-pr> > https://github.com/monero-project/monero/pull/10387