13:40:41 d​atahoarder:monero.social: For Carrot outputs, do we have a writeup of how transaction proofs (inproof/outproof) would work/look like?
15:14:44 j​effro256:monero.social: No, not yet, it would be similar to Jamtis though. I've been meaning to start the code for these for a while.
15:15:21 j​effro256:monero.social: For send proofs, you would mainly share the sender-receiver secret, and let the validator decode the output
15:16:17 d​atahoarder:monero.social: yeah, equivalent to tx key, except recoverable to both parties
15:16:33 d​atahoarder:monero.social: so receiver can make an "out proof" as well
15:17:23 d​atahoarder:monero.social: you'd have to prove "spend proof" (actually, how'd that work?) + outproof in one
15:41:51 j​effro256:monero.social: Yeah, sorry I meant "out proof" when I said "sent proof". A spend proof is going to need to request an old FCMP path from the daemon to preserve sender anonymity, that'll require a bit more business logic
15:55:23 DataHoarder: I mean making a "receive proof" but I guess "tx proof" that does both (send and receive?) works
15:55:42 DataHoarder: Receive proof however also proves they controlled at least a view version of the wallet
17:02:45 r​brunner7:monero.social: Meeting in 1 hour
17:04:52 j​effro256:monero.social: Can't you do a "receive proof" by just making an out proof to an address you control? Unless I'm mistaking what a "receive proof" is
17:05:33 DataHoarder: Basically proving you control at least a view version of the wallet keys
17:05:46 DataHoarder: Which is what inproof did too
17:06:13 DataHoarder: I guess a tx proof + signature from wallet would do too
17:06:47 DataHoarder: Too bad that Monero GUI currently does not support signing from subaddresses, only main address, and view wallet key signing is broken there too (works in CLI)
17:08:52 DataHoarder: Generalizing to just "tx proof" I guess is fine, same for sender and receiver.
17:12:31 DataHoarder: I guess you could also just share the anchor and re-derive from there no?
17:12:46 DataHoarder: In the end they will be able to decode and it's shorter
17:15:02 DataHoarder: Ah right. Payment id
17:59:48 r​brunner7:monero.social: Meeting time. Hello! https://github.com/monero-project/meta/issues/1308
18:00:38 s​needlewoods_xmr:matrix.org: hi
18:00:47 j​effro256:monero.social: Howdy
18:01:17 j​berman:monero.social: *waves*
18:01:52 r​brunner7:monero.social: Ok, the regulars are here, thus we can move to the reports from last week
18:03:27 s​needlewoods_xmr:matrix.org: some more fixes, one of the bigger issues that got fixed: `show_transfers` now does show incoming pool txs, but outgoing pending txs still not showing up
18:03:28 s​needlewoods_xmr:matrix.org: ready to push, but I'm a little hesitant, because of all the GitHub spam it creates
18:03:33 s​needlewoods_xmr:matrix.org: and started planning what to do next, I think it's a good idea to continue with replacing wallet2 by the Wallet API in monero-wallet-rpc, because now I'm still relatively familiar with the Wallet API. If you guys have no objections, I'd write a CCS proposal for that, starting in January.
18:04:10 r​brunner7:monero.social: Yes, I think that's the next logical step, monero-wallet-rpc
18:04:30 j​berman:monero.social: Identified and patched issues causing broken and unreliable sync when the pool exceeds the max weight allowed, I'm catching up on people's comments in the stressnet channel now, and planning to work on unexpected slow sync, runaway span OOM's, and tx relay v2 this week / whatever issues people highlight in the stressnet channel
18:05:02 r​brunner7:monero.social: Stressnet causing some stress for you fixing bugs :)
18:06:02 j​berman:monero.social: It's been solid, I'm glad, this one was a lingering bug in FCMP++ integration code that I'm happy is now fixed: https://github.com/seraphis-migration/monero/pull/251
18:06:13 j​effro256:monero.social: Implemented PQ changes to carrot_core, communicating with potential code auditors, and working on updating the benchmark suite. Might take a serious stab at transaction proofs next week
18:06:54 r​brunner7:monero.social: By the way, just curious, where do the block sizes top out currently on stressnet? 10 MB or so?
18:08:25 s​needlewoods_xmr:matrix.org: v1.5 is supposed to be the last version for this stressnet run? There you made quite a few improvements since 1.4v fwiw
18:08:54 r​ucknium:monero.social: 18MB now. A few blocks up to 30MB. However, the actual bytes is not equal to tx weight. I don't know the error factor.
18:08:56 j​berman:monero.social: I recall seeing ofrnxmr mention 19+ MB blocks (although that's not actual MB, just weight, since weight on alpha stressnet is actually much larger than byte size). ofrnxmr / Rucknium may know definitively current peak
18:09:12 j​berman:monero.social: Thank you Rucknium
18:09:17 r​brunner7:monero.social: Impressive
18:10:31 j​berman:monero.social: that's the hope, but we'll see how it goes
18:10:58 j​berman:monero.social: haven't released v1.5 yet, people have been testing a pre-release for v1.5
18:11:10 r​ucknium:monero.social: https://matrix.monero.social/_matrix/media/v1/download/monero.social/QEeyVrGkBYxuaKQuyLMnrYSG
18:11:17 r​ucknium:monero.social: ^ Last week of block weights
18:11:25 r​ucknium:monero.social: From https://stressnetnode1.moneronet.info/
18:11:55 j​effro256:monero.social: Nice graph, thank you
18:12:23 r​brunner7:monero.social: How long like that until you pass mainnet blockchain filesize :) Hyc confirmed today on Reddit that LMDB per se works without problems with terabyte sized files, so nothing to fear.
18:13:25 r​ucknium:monero.social: Almost 95GB unpruned now. Added 30GB in last week because we turned up the spam volume.
18:14:16 r​brunner7:monero.social: Ok, so our streak with impressive progress, at least as I see it, every week continues. Anything special to discuss today?
18:15:18 r​brunner7:monero.social: Does anybody happen to know where we stand with DNS checkpoints? With Qubic almost gone, awfully quiet on that front.
18:16:10 r​brunner7:monero.social: Almost gone as a clear and present danger, I mean
18:16:14 j​effro256:monero.social: I think it's kinda stagnant at the moment, ofrn mentoned something about how there's a bug in the handling of it, but I haven't looked into that
18:16:50 s​needlewoods_xmr:matrix.org: my last information was 0xfffc was investigating, but not sure
18:17:07 r​brunner7:monero.social: Would be a bit sad to not walk the last few meters after quite some journey, no?
18:17:08 j​effro256:monero.social: nice
18:18:26 r​brunner7:monero.social: Ok, looks like we are through for today. Thanks everybody for attending, read you again next week!
18:18:58 s​needlewoods_xmr:matrix.org: thanks everyone, cu
18:21:12 plowsof: for pools' hashrate check https://blocks.p2pool.observer/pools by DataHoarder
18:22:28 o​frnxmr:monero.social: Yeah, a checkpointed block is orphaned before the checkpoint us received -> receive checkpoint -> node rolls back to _before_ the checkpoint -> node refuses to reorg onto the checkpointed chain, because its orphaned + node cannot add blocks to the chain, because they dont match the checkpoint = node stuck
18:25:18 r​brunner7:monero.social: Somehow sounds like a quite tricky problem
18:26:54 r​brunner7:monero.social: Could be it's not what you would call a "bug", but more like a hole of sorts in the "protocol"? I mean, what is the daemon expected to do in such a situation?
20:35:48 o​frnxmr:monero.social: I think its a bug because there exists logic to switch onto an alt chain
20:36:31 o​frnxmr:monero.social: But this code path is skipped, and instread marks the alt chain as orphaned
20:36:54 o​frnxmr:monero.social: If you force the condition to true, it reorgs onto the alt chain as expected
20:37:55 o​frnxmr:monero.social: (of course, forcing `is_a_checkpoint` to true means that it always reorgs onto the alt chain, regardless of if its checkpointed)