06:29:38 <DanrdarkIsnotthe> if the void talks back then you has problem
06:44:21 <DanrdarkIsnotthe> also support is going offshore to india
10:25:38 <plowsof11> lets have a filler meeting this saturday before the usual timeslot on the 8th https://github.com/monero-project/meta/issues/854
11:15:54 <nioc> How do we have a meeting while the bridge is broken?
11:18:03 <DanrdarkIsnotthe> Russia Ukraine bridge?
11:21:46 <plowsof11> how broken is the bridge.. are we talking normal level of broken, or broken broken 
11:22:34 <plowsof11> i think we are at level 1. Bridge requires a daily wake up call else 1st message is dropped
11:27:57 <blankpage[m]> Pre-meeting bridge wake up call will make everything ok?
11:28:49 <nioc> WAKE UP
11:30:11 <DanrdarkIsnotthe> So loud
12:54:40 <john_r365[m]> <boog900[m]> "Here: https://www.youtube.com/..." <- > <@boog900:monero.social> Here: https://www.youtube.com/live/m-qWvfhABrY?feature=share 
12:54:40 <john_r365[m]> > 
12:54:40 <john_r365[m]> > At 37 mins he say it doesn't go away
12:54:40 <john_r365[m]> Thanks for this, had wondered. So Seraphis with full membership proofs doesn't fix the need to lock the outputs of a spend for 10 blocks.
12:58:00 <john_r365[m]> So then, the only way to "fix" this UX issue, so that your non-technical friend or family member doesn't run into it, is to include a feature like Monerujo's Pocket Change into wallets.
12:58:00 <john_r365[m]> Currently Pocket Change may reduce privacy slightly, due to the fingerprinting. 
12:58:00 <john_r365[m]> With full chain membership proofs, does that fingerprinting issue go away?
13:02:03 <sech1> theoretically yes
13:04:55 <plowsof11> tx size (10kb) and possibly fee increase could make churning less attractive. reducing the 10block lock is still a topic for discussion 
13:05:12 <plowsof11> kayabanerve confirms in number 4 (reg the 10block lock) here https://github.com/monero-project/research-lab/issues/100#issuecomment-1608082485 
13:06:13 <kayabanerve[m]> john_r365: Not slightly.
13:06:15 <kayabanerve[m]> Notably.
13:07:02 <kayabanerve[m]> The main issue is any pocket change TX will then have multiple of its outputs selected at time of spend. Monero prefers 2-in to 1-in, so you fan out your outputs, yet the input selection will merge them back in.
13:07:21 <kayabanerve[m]> Even Seraphis with 128-rings will get nuked under pocket change solutions.
13:07:46 <kayabanerve[m]> If we stay on rings, we need to implement coin control if you want to have a viable pocket change.
13:08:07 <kayabanerve[m]> I prefer Monero to not require users know how to manually do coin control.
13:08:40 <kayabanerve[m]> Under ZK-SNARKS, no, this won't matter at all. Pocket change TXs will stand out. TXs spending pocket change won't. The pocket change TXs also shouldn't be linkable to anything else, making their standing out irrelevant.
13:09:16 <kayabanerve[m]> Err, sorry, full chain membership proof. I'm technically not proposing a SNARK. I just have the community colloquialism burned into my head still.
13:11:17 <kayabanerve[m]> Berman just corrected me. It won't do a 2-input immediately. After one TX, with one pocket change input, they'll have distinct TX IDs. Then Monero is willing to do a 2-input TX. This is a trivial EAE pattern though.
13:11:23 <kayabanerve[m]> * trivial EAE-esque pattern
13:11:52 <kayabanerve[m]> It effectively immediately doxes the first TX as spending the pocket change, and the second TX as spending the first TX and the original pocket change.
13:13:08 <kayabanerve[m]> So pocket change does likely entirely remove your sender privacy due to the fundamental nature of rings.
13:13:41 <kayabanerve[m]> It wouldn't under FCMPs, meaning there's a way around the 10-block lock which isn't giving up privacy under FCMPs, despite the lock still existing.
13:16:40 <john_r365[m]> So, with FCMPs (nice acronym) your pocket change TXs stand out, but a TX spending pocket change do not?
13:20:33 <plowsof11> i think with FCMP's - it doesnt matter what you're doing (you could be minting a mordinal , churning pocket change or paying a utility bill - its all the same on chain - to be confirmed*) 
13:22:06 <kayabanerve[m]> Right, and since the pocket change TX itself is unlinkable, who cares?
13:24:17 <kayabanerve[m]> ofrnxmr: ... I just made an issue to shave off 128 bytes if it makes you feel better
13:24:31 <kayabanerve[m]> We'd save tens of percent with BP++, but yeah, that's the numbers on it.
13:26:41 <blankpage[m]> In the meantime, segregating a pocket change wallet (for everyday spending) from a sneaky/savings wallet is possible through careful churning (best practice for churning is forever a WIP)
13:28:56 <blankpage[m]> Dynamic blocksize will handle the increase. Or do you mean "are we increasing the penalty free zone" (300kb)?
13:29:32 <kayabanerve[m]> blankpage: I'm not convinced of the efficiency of churning, though MAGIC is actively funding research on it. So we'll find out.
13:29:40 <kayabanerve[m]> The issue is the input merging.
13:30:08 <kayabanerve[m]> Also, if you segregate pocket change, that's just admitting to giving up privacy on coins you use on a day to day basis.
13:30:22 <kayabanerve[m]> ofrnxmr[m]: ArticMine proposed this re: penalty free zon.
13:30:51 <kayabanerve[m]> ofrnxmr[m]: BP++ hopefully would get us to 6, though I haven't checked the exact math and that could be too optimistic. We'd have to look at Halo 2 after that.
13:31:14 <kayabanerve[m]> s/zon/zone/
13:32:11 <blankpage[m]> I assume that ideal churning practice would involve some careful consolidation of enotes
13:32:59 <blankpage[m]> And might be inefficient from a "number of tx needed to be sure" perspective
13:33:00 <kayabanerve[m]> blankpage: Requiring coin control and every user of Monero to have an understanding + actively consider each spend, or far more advanced input selection algos which would require more info from users at time of spend to work properly.
13:34:22 <kayabanerve[m]> I may have been mistaken.
13:34:46 <kayabanerve[m]> It's not 10kb. It's 50.
13:35:00 <blankpage[m]> Yikes
13:35:01 <kayabanerve[m]> /s :P Now that I'm done giving ofrnxmr a heart attack... it may be 2kb an input, not 4.
13:35:12 <plowsof11> hnng
13:35:29 <kayabanerve[m]> So 2kb * 2 + whatever the TX body + 1kb for the bulletproofs = 5kb, not 4kb.
13:35:31 <kayabanerve[m]> s/*/\*/, s/4kb/10kb/
13:35:54 <plowsof11> can you provide a security proof for those maths
13:36:00 <blankpage[m]> Also variable size from output count and tx_junkdrawer (if it still exists)
13:36:05 <plowsof11> XD Rucknium
13:36:25 <kayabanerve[m]> Ideally, we're 512 AC gates which is 1024 BP gates. 2 ** 11 = 1024. (11 * 64) + (6 * 32) = 896 bytes.
13:37:01 <kayabanerve[m]> Wee have two proofs per input under curve trees. 896 * = just under 2 kb
13:37:21 <kayabanerve[m]> But there's a bit of additional proving data lying around (the vector commitments) which is prob a couple hundred bytes.
13:37:41 <kayabanerve[m]> Though rn, we're 1024 AC gates, 2048 BP gates, so add 128 bytes. Still ~2kb.
13:39:17 <kayabanerve[m]> And then BP++ would still offer a many % reduction.
13:39:37 <kayabanerve[m]> * 896 * 2 = just
13:39:58 <kayabanerve[m]> *That does assume a VC scheme is implemented.
13:40:32 <blankpage[m]> Vc?
13:40:52 <kayabanerve[m]> plowsof: Rucknium https://github.com/kayabaNerve/full-chain-membership-proofs/issues?q=is%3Aopen+is%3Aissue+label%3Asecurity
13:41:06 <kayabanerve[m]> blankpage: https://github.com/kayabaNerve/full-chain-membership-proofs/issues/4
13:41:58 <kayabanerve[m]> We need a BP+ VC or to fall back to BP, which would slightly increase the above proof sizes and hamper future efforts. It's not currently done, so our current sizes/discussions are much worse, but it will be done before anything I recommend for deployment.
13:42:15 <blankpage[m]> Thanks. I am not seeing any messages today from Rucknium which others seem to be seeing based on context. 
13:43:08 <kayabanerve[m]> I am not seeing messages from them. I just tagged them as I thought they'd appreciate the healthy amount of tracking I'm giving to their priority, as it's also mine.
13:44:08 <blankpage[m]> OK so it is not some glitch in the matrix 
13:49:10 <kayabanerve[m]> Updated the MRL issue to clarify I believe I doubled my numbers by accident. I assume 5.5kb is a lot more amenable to everyone than 10?
13:49:13 <ceetee[m]> absolutely
13:50:12 <blankpage[m]> Maybe a CAPS LOCK disclaimer over the Monerokon talk would be a good idea also
13:51:18 <ceetee[m]> hardware has become so much cheaper, that the cost per TX is still going down
13:53:01 <plowsof11> kayaba has reduced FCMP transactions by almost 50% , well done
13:53:48 <kayabanerve[m]> plowsof: I'm doubling all future CCS proposals I make for the rest of my life and expect no complaints
13:53:49 <kayabanerve[m]> :p
13:54:56 <kayabanerve[m]> Ha. Planning a couple soon
13:56:12 <kayabanerve[m]> First, I'm finishing my issue tracker. I'm trying to track out everything that has to be done on the self-contained lib side of things
13:56:15 <blankpage[m]> "Full chain membership proofs" or FCMP is clunky IMO, can we maybe roll with "global signatures" as an analogy to "ring signatures"?
13:56:30 <kayabanerve[m]> blankpage: It's not a signature
13:56:57 <kayabanerve[m]> And then that issue tracker will become the second CCS. A set of already defined tasks, already tracked, broken down with timelines and contributors.
13:57:20 <kayabanerve[m]> At one point I called them Tony proofs. Now I just call them Curve Trees despite using a much more efficient construction internally.
13:57:49 <kayabanerve[m]> It still takes the overall technique from Curve Trees, which arguably wasn't novel. They just did a really tight definition of it.
13:58:01 <kayabanerve[m]> And then I got a tighter definition 😎
13:59:14 <blankpage[m]> Needs to be a short name that gets the concept across for educational materials... like how we are moving to "enotes"
13:59:21 <blankpage[m]> Who is Tony?
14:00:16 <kayabanerve[m]> blankpage: Oh. It was because it was a membership over bulletproofs. MoB.
14:00:30 <kayabanerve[m]> If I meet a guy named Tony who isn't the mob, honestly, just a wasted opportunity.
14:01:52 <monerooo[m]> Moner.ooo Update - Added Localmonero.co
14:01:54 <blankpage[m]> Global proofs? Sounds like something which already means something specific elsewhere
14:02:40 <kayabanerve[m]> GMP sounds equiv to FCMP. GP isn't specific enough IMO.
14:03:38 <kayabanerve[m]> If you force yet another name to exist, even though there's no reason for another name, and it'd solely muddle the waters compared to Curve Trees IMO, I can start thinking of ones. Will likely involve the word "maid" in someway though just to mess with people though. Fair warning :p
14:03:53 <kayabanerve[m]> Membership Always Including ...
14:05:02 <blankpage[m]> Fewer words is better so I vote GMP
14:05:31 <kayabanerve[m]> I vote FCMP because I'm petty and technically, GMPs include outputs from every chain
14:05:36 <kayabanerve[m]> But I'll ack GMPs would be fine :p
14:05:57 <kayabanerve[m]> But in the distant sharded, horizontally scalable future, I'll note we may actually discuss GMPs (not FCMPs)
14:06:35 <blankpage[m]> Like if someone asks me "how does monero hide the sender?" the answer "curve trees" invites further questions rather than a feeling of conceptual understanding
14:07:16 <plowsof11> wownero with FCMP first?
14:07:51 <blankpage[m]> Funky Coin Membership Proofs
14:10:23 <john_r365[m]> blankpage: are we sure that "full chain membership proofs" or FCMPs is going to clear up the confusion that "curve trees" might invite? 😅 Surely either way, further explanation will be needed?
14:13:32 <blankpage[m]> "What is the curve?" "What is the tree?" "Is the tree curved, or the fruit on the tree?"
14:14:35 <kayabanerve[m]> Just call them MPs. N00bs won't know partial existed in the first place. If anyone asks partial or full, we just say why wouldn't it be full
14:14:41 <kayabanerve[m]>  /s :p
14:16:01 <blankpage[m]> This but not sarcastically ^
14:16:48 <kayabanerve[m]> I don't want to be an elitist asshole about not having FCMPs after how long it took us, but the rest can be unironic
14:17:24 <monerobull[m]> monero.town works again :)
14:18:21 <blankpage[m]> Best android Lemmy app?
15:28:26 * hbs[m] uploaded an image: (181KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/OTtZuALejMAWdnnTWuCqDTVQ/PXL_20230627_152706771.jpg >
15:28:27 <hbs[m]> Those containers are lacking Monero stickers 
15:44:56 <monerobull[m]> <blankpage[m]> "Best android Lemmy app?" <- i like gebora
15:45:28 <monerobull[m]> > <@blankpage:monero.social> Best android Lemmy app?
15:45:28 <monerobull[m]>  * i like jerboa
15:45:45 <monerobull[m]> lemmur is also good though
15:49:16 <someoneelse49549> <hbs[m]> "PXL_20230627_152706771.jpg" <- hey, that's my country
15:49:23 <someoneelse49549> * my country. fuck my country
16:04:04 <RavFX[m]> <hbs[m]> "PXL_20230627_152706771.jpg" <- Waste of Monero stickers...
16:04:04 <RavFX[m]> Put them in bus stations or inside the airports so normies actually see them.
17:28:32 <plowsof11> old ledger monero app vulnerability : in 2020 of april, it was possible to have your spend key extracted by simply plugging in to a computer, unlocking, and opening the monero app (with no further interaction) details/video shown here https://deadcode.me/blog/2020/04/25/Ledger-Monero-app-spend-key-extraction.html (it was fixed by Ledger). The author of that article made a pull request recently for some trezor misc. trezor fixes.
17:28:32 <plowsof11> john_r365 opened up a bounty to get it reviewed https://bounties.monero.social/posts/85/ which currently stands as 2.2 xmr. sech1 is currently working through / reviewing the pull request
17:47:29 <monerobull[m]> Lol
18:53:32 <r4v3r23[m]> HWW are garbage
19:02:11 <hbs[m]> They are quite useful if you can have a hardened firmware