<d​atahoarder:monero.social> For Carrot outputs, do we have a writeup of how transaction proofs (inproof/outproof) would work/look like?

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

<j​effro256:monero.social> For send proofs, you would mainly share the sender-receiver secret, and let the validator decode the output

<d​atahoarder:monero.social> yeah, equivalent to tx key, except recoverable to both parties

<d​atahoarder:monero.social> so receiver can make an "out proof" as well

<d​atahoarder:monero.social> you'd have to prove "spend proof" (actually, how'd that work?) + outproof in one

<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

I mean making a "receive proof" but I guess "tx proof" that does both (send and receive?) works

Receive proof however also proves they controlled at least a view version of the wallet

<r​brunner7:monero.social> Meeting in 1 hour

<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

Basically proving you control at least a view version of the wallet keys

Which is what inproof did too

I guess a tx proof + signature from wallet would do too

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)

Generalizing to just "tx proof" I guess is fine, same for sender and receiver.

I guess you could also just share the anchor and re-derive from there no?

In the end they will be able to decode and it's shorter

Ah right. Payment id

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1308

<s​needlewoods_xmr:matrix.org> hi

<j​effro256:monero.social> Howdy

<j​berman:monero.social> *waves*

<r​brunner7:monero.social> Ok, the regulars are here, thus we can move to the reports from last week

<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

<s​needlewoods_xmr:matrix.org> ready to push, but I'm a little hesitant, because of all the GitHub spam it creates

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

<r​brunner7:monero.social> Yes, I think that's the next logical step, monero-wallet-rpc

<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

<r​brunner7:monero.social> Stressnet causing some stress for you fixing bugs :)

<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: seraphis-migration/monero #251

<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

<r​brunner7:monero.social> By the way, just curious, where do the block sizes top out currently on stressnet? 10 MB or so?

<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

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

<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

<j​berman:monero.social> Thank you Rucknium

<r​brunner7:monero.social> Impressive

<j​berman:monero.social> that's the hope, but we'll see how it goes

<j​berman:monero.social> haven't released v1.5 yet, people have been testing a pre-release for v1.5

<r​ucknium:monero.social> matrix.monero.social/_matrix/media/…ero.social/QEeyVrGkBYxuaKQuyLMnrYSG

<r​ucknium:monero.social> ^ Last week of block weights

<r​ucknium:monero.social> From stressnetnode1.moneronet.info

<j​effro256:monero.social> Nice graph, thank you

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

<r​ucknium:monero.social> Almost 95GB unpruned now. Added 30GB in last week because we turned up the spam volume.

<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?

<r​brunner7:monero.social> Does anybody happen to know where we stand with DNS checkpoints? With Qubic almost gone, awfully quiet on that front.

<r​brunner7:monero.social> Almost gone as a clear and present danger, I mean

<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

<s​needlewoods_xmr:matrix.org> my last information was 0xfffc was investigating, but not sure

<r​brunner7:monero.social> Would be a bit sad to not walk the last few meters after quite some journey, no?

<j​effro256:monero.social> nice

<r​brunner7:monero.social> Ok, looks like we are through for today. Thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> thanks everyone, cu

for pools' hashrate check blocks.p2pool.observer/pools by DataHoarder

<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

<r​brunner7:monero.social> Somehow sounds like a quite tricky problem

<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?

<o​frnxmr:monero.social> I think its a bug because there exists logic to switch onto an alt chain

<o​frnxmr:monero.social> But this code path is skipped, and instread marks the alt chain as orphaned

<o​frnxmr:monero.social> If you force the condition to true, it reorgs onto the alt chain as expected

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