08:45:39 <DataHoarder> FYI https://libera.chat/news/llm-etiquette
08:46:04 <DataHoarder> Given we have public logs out note those may be scanned by external companies training content for AI anytime
10:16:26 <m-relay> <j​ohn_r365:monero.social> @vThor & rbrunner7: was just catching up on your convo re Monero's SeedSigner. I'd add my agreement that 2 versions should exist. The existing amnesiac version, and one that has persistent memory, and has its security strengthened in some way. For example, requiring a passphrase that doesn't get stored - or other methods.
10:17:49 <m-relay> <j​ohn_r365:monero.social> Reiterating what has already been said, it seems like a great DIY hardware wallet solution, but if every user has to keep printed QR codes in proximity to the device, users who want convenience are likely to be put off.
14:00:24 <m-relay> <a​js_:matrix.org> MKC3 call for workshops/presentations up https://x.com/MoneroKon/status/1860321346380533986
14:00:55 <m-relay> <a​js_:matrix.org> Deadline December 7th
14:01:17 <m-relay> <m​onerobull:monero.social> Why do early?
14:01:20 <m-relay> <a​js_:matrix.org> Please retweet and invite potential speakers
14:01:27 <m-relay> <m​onerobull:monero.social> Why so early?
14:01:46 <m-relay> <a​js_:matrix.org> C3 planning has a tight schedule unfortunately
14:02:10 <m-relay> <m​onerobull:monero.social> Ah never mind I thought this is about mk
14:04:02 <m-relay> <a​js_:matrix.org> We need more Monero representation at C3. It is great they are open to hosting us since hacker type events tend to be very anti-crypto
14:15:04 <m-relay> <r​ottenwheel:kernal.eu> That's what vast majority of SeedSigner users do, the fork XMRSigner is derived from. Best they can do is be able to eject the microSD card after boot. That is what a stateless signer is... 🙄 Cc. rbrunner7
14:16:27 <m-relay> <r​ottenwheel:kernal.eu> You'd need to partition the microSD somehow to make a "persistent" environment on the Pi. I'd recommend to think of what the word stateless means; let alone understand what features and limitations both the Pi and the XMRSigner have.
15:00:14 <vthor> john_r365: this will be the case, not yet 100% sure how I will implement it exactly, but this will happen defenitely.
15:00:54 <plowsof> Meeting in 1 hr https://github.com/monero-project/meta/issues/1113
15:06:04 <m-relay> <r​ottenwheel:kernal.eu> As long as you let one decide between persistent and stateless, I'm game. vthor
15:06:28 <m-relay> <r​ottenwheel:kernal.eu> Good luck figuring out how to do persistent though lol, will be interesting to see.
15:12:25 <vthor> rottenwheel: I don't like really the thought to safe the seeds on the same microSD card - although it is probably the cheapest option, it is not the best. On my research for NFC payment on weak hardware I found cheap SPI secure elements and SPI flash, which could be sourced in quantities of 100 for below $5.
15:14:17 <m-relay> <r​ottenwheel:kernal.eu> vthor the more you talk about ways to implement persistent state for XMRSigner, the less I like the idea, and I already oppose and disagree with it 100% as-is...
15:14:40 <vthor> rottenwheel, It will result in two different build, I don't like incactive code in the image. Could even be happen to go to 3 version (but not sure, need some time to think and thinkering about and analyze different threat models - and best would be to get some actual user input, why they want to have certain version)
15:15:05 <m-relay> <r​ottenwheel:kernal.eu> Beyond my bias, sounds stupid, for lack of a better word, to add more components, as that would effectively bar current SeedSigner users and owners from trying XMRSigner in the first place...
15:15:29 <m-relay> <r​ottenwheel:kernal.eu> Don't break the stateless concept. What the other two individuals claim to be a UX hurdle, is the main selling point of the SeedSigner project.
15:15:55 <m-relay> <r​ottenwheel:kernal.eu> I find it hard to understand how instead of looking at it from the security perspective, they latch on the UI/UX inconvenience...
15:16:36 <m-relay> <r​ottenwheel:kernal.eu> Cool, yeah, all WIP. I've said my piece. Congrats on getting fully funded, sir. 😊
15:18:53 <vthor> No, the stateless version will be always 100% staeless, not even microSD storing. And a version with microSD storing, need to see... And discous with actual user.
15:19:55 <vthor> rottenwheel, thank you very much! Hopen to see you in CDMX, but missed you.
15:20:33 <vthor> Need to walk the white monster before he pees on my feets. afk.
16:00:22 <plowsof> Meeting time https://github.com/monero-project/meta/issues/1113 
16:00:25 <plowsof> greetings!
16:01:08 <m-relay> <o​frnxmr:monero.social> howdy
16:01:40 <plowsof> whats been going on since the last meeting? Monerotpia happened https://monerotopia.com/ 
16:01:51 <m-relay> <0​xfffc:monero.social> Hello everyone
16:02:27 <plowsof> MKC3 call for workshops/presentations up https://x.com/MoneroKon/status/1860321346380533986 - ajs 
16:03:05 <plowsof> 0xfff made a PR making some improvements to --no-initial-sync and wallet-rpc?
16:03:41 <plowsof> kewbit teased a CCS update for the haveno-gui... the monero -serai/wallet ccs proposal from kayabanerve has been merged https://ccs.getmonero.org/funding-required/
16:03:41 <m-relay> <o​frnxmr:monero.social> Make wallet-rpc great for the first time since bytecoin
16:04:11 <msvb-lab> Hello.
16:05:30 <plowsof> in my recent ccs update, i tallied up the funds we've repurposed or donated to the general fund from abandonned ccs proposals. 384.06 repurposed. 161.85 returned to the general fund https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/503#note_27312
16:05:31 <vthor> Hi!
16:05:47 <m-relay> <0​xfffc:monero.social> https://github.com/monero-project/monero/pull/9579
16:05:59 <m-relay> <o​frnxmr:monero.social> Boooo 👎
16:06:19 <plowsof> i look forward to testing this 0xfffc thank you
16:06:29 <m-relay> <o​frnxmr:monero.social> We should instead repurpose the old gemeralfund btc and xmr addresses funds from black hole to transparency report
16:06:49 <m-relay> <0​xfffc:monero.social> ( You’re welcome. My pleasure. )
16:07:15 <ofrnxmr> https://github.com/monero-project/monero/pull/9579 one of @0xfffc's fixes
16:07:47 <plowsof> thanks
16:09:33 <plowsof> XMRSigner from vthor originating from repurposed funds :) but now his own work has been funded (was discussed today here) 
16:10:34 <plowsof> ofrnxmr did you mention wallet-rpc using insane bandwidth amounts if left running 24/7?
16:10:53 <plowsof> ive never ran it at home so wouldn't notice 
16:11:36 <m-relay> <0​xfffc:monero.social> I believe this should alleviate the problem: https://github.com/monero-project/monero/pull/9574
16:11:36 <plowsof> News: [Monero Observer](https://www.monero.observer/) - [Revuo Monero](https://revuo-xmr.com/)
16:11:50 <plowsof> oh, another PR 
16:11:59 <m-relay> <o​frnxmr:monero.social> Yes
16:12:36 <plowsof> Siren/Stnby of digilol/moneropay are probably effected , as well as alot of merchants/swappers then 
16:12:59 <m-relay> <o​frnxmr:monero.social> Like gb's per hr if a service utilizes close_wallet inbeteren open_wallet calls
16:13:46 <plowsof> good catch 
16:13:58 <m-relay> <0​xfffc:monero.social> Yes. It was basically days (or even months of? of computation wasted overall.
16:14:05 <m-relay> <o​frnxmr:monero.social> leads to very very much increased time to respond the longer the service is running
16:14:29 <m-relay> <o​frnxmr:monero.social> Resyncs the same blocks over and over.. and over again
16:14:35 <vthor> 0xfffc: but this will only avoid long opening time on open a wallet, would it be easy to quick fix the also the restore wallet from seed? (I suspect the long time on weak hardware comes from generating addresses on restore)
16:14:46 <plowsof> perhaps this is when i need to kill the process by grabbing its pid 
16:15:03 <m-relay> <o​frnxmr:monero.social> I think there still may be an off-by-1 issue, as it syncs 2 blocks everytime it receives 1 more now
16:15:46 <m-relay> <0​xfffc:monero.social> Great catch. I will try to fix it. Will dm you about it. 🙏🏻
16:15:57 <m-relay> <s​tnby:kernal.eu> Huh?
16:16:50 <plowsof> "if a service utilizes close_wallet inbeteren open_wallet calls" - ofrnxmr above. if moneropay does this then could be suffering from delays/bandwidth usage 
16:16:53 <m-relay> <o​frnxmr:monero.social> tldr: these wallet-rpc issues should help projects, like moneropay, to function better
16:17:46 <m-relay> <o​frnxmr:monero.social> It also doesnt seem to refresh at open like its supposed to. Takes 20secs
16:18:22 <m-relay> <s​iren:kernal.eu> Yeah the resync thing is very annoying
16:18:56 <plowsof> nice
16:19:35 <plowsof> anything else to bring up? else we can move on to the ccs ideas 
16:20:28 <plowsof> articmine shared thoughts on FCMP in MRL today which raised further discussion https://libera.monerologs.net/monero-research-lab/20241123 
16:20:54 <plowsof> specifically the "post on  FCMP++ costs and transaction sizes"
16:22:00 <plowsof> MRL can weigh in on this further.. now then 
16:22:53 <plowsof> moving on, ccs ideas:
16:22:56 <plowsof>   a. [Carrot animated video](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/506)    
16:23:12 <plowsof> close/merge? 
16:23:50 <plowsof> not enough positive engagement around this, looks like it will be closed 
16:24:40 <dEBRUYNE> plowsof: As a side note, was the FCMP++ video officially released, or not yet? 
16:24:56 <m-relay> <o​frnxmr:monero.social> I think this is a close, no engagement from proposer
16:25:09 <plowsof> vostoemissio released a video , yes, thanks 
16:25:12 <m-relay> <o​frnxmr:monero.social> Not yet, xenu and vost redoing some of the script
16:25:44 <m-relay> <o​frnxmr:monero.social> The video they released was a pre-release, and kaya commented some inaccuracies
16:25:58 <m-relay> <o​frnxmr:monero.social> So theyre going to fix up and rerelease
16:26:41 <plowsof> thanks debruyne, here is vostos comment, open for feedback as above https://libera.monerologs.net/monero-community/20241121#c462513
16:26:58 <plowsof> closing Carrot animated video 
16:27:28 <plowsof>   b. [CryptoCheckout WordPress plugin (for WooCommerce) & Shopify app](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/514)    
16:27:43 <plowsof> close/merge?
16:27:46 <m-relay> <o​frnxmr:monero.social> Close
16:28:01 <m-relay> <o​frnxmr:monero.social> Oh, for community news
16:28:33 <m-relay> <o​frnxmr:monero.social> Haveno Development  and #haveno:development are the new homes for haveno dev on matrix and irc
16:28:44 <plowsof> a close from me. also special thanks for mrnaif from bitcart.io for sharing his insight regarding getting on to the shopify app store and such 
16:29:22 <plowsof> the proposer of the above didnt even know how it was done and dropped the premise immediately 
16:29:42 <plowsof> closing cryptocheckout 
16:29:57 <plowsof>   c. [Monerotopia 2024 Marketing and Publicity](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/515)    
16:30:30 <plowsof> this was pre-approved, pending the upcoming update from geonic , we can move on unless that is on hand 
16:30:40 <plowsof> at hand*
16:31:04 <m-relay> <o​frnxmr:monero.social> +1 plowsof
16:31:05 <dEBRUYNE> plowsof: ty
16:31:25 <m-relay> <o​frnxmr:monero.social> Seems the event went well though. Congrats
16:31:45 <plowsof> 👏
16:31:57 <plowsof>   d. [Gingeropolous 1TB MRC upgrade](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/516)    
16:32:54 <m-relay> <o​frnxmr:monero.social> Mrl i think liked this, but i again have mt reservations about continuously trusting folks who are irresponsible with our security and privacy
16:33:06 <m-relay> <o​frnxmr:monero.social> I think someone else should run the mrl lab pcs
16:33:10 <plowsof> 20 xmr, ram for MRL who expressed a need for it , and with positive updoots 
16:33:48 <m-relay> <o​frnxmr:monero.social> Ginger refused to share the ips that he was forwarding to, and it took community whitehats to pry the info from internet logging or nslookup
16:34:17 <m-relay> <o​frnxmr:monero.social> And he deleted ips and still refused to share
16:34:22 <m-relay> <r​ucknium:monero.social> Maybe gingeropolous can do a sysadmin security short course :)
16:34:34 <m-relay> <r​ucknium:monero.social> I wouldn't mind doing one myself
16:34:37 <m-relay> <o​frnxmr:monero.social> Dodges any questions about the subject
16:35:14 <m-relay> <o​frnxmr:monero.social> i dont think it eas irresponsible due to being uneducated, but simply due to negligence
16:35:20 <m-relay> <o​frnxmr:monero.social> then tried to cover it up
16:35:38 <m-relay> <o​frnxmr:monero.social> And still pretends like nothing happened
16:35:42 <m-relay> <h​into:monero.social> hello
16:35:44 <m-relay> <l​ordx3nu:matrix.org> Re fcmp video: revisions made just waiting for Luke
16:35:45 <m-relay> <l​ordx3nu:matrix.org> Re carrot: vosto and I have expressed interest for doing an animated vid for this though not sure if there is enough interest
16:35:53 <plowsof> Rucknium is one of the main consumers of ram, if i could click my heels then Rucknium would be setting the hardware up in house for other MRL members
16:36:21 <m-relay> <l​ordx3nu:matrix.org> Waiting for Luke to sign off*
16:36:47 <plowsof> blame kayabanerve for any issues moving forward, noted 
16:36:59 <m-relay> <l​ordx3nu:matrix.org> Thanks
16:37:12 <plowsof> thanks for sharing the update Xenu 💪
16:37:14 <m-relay> <l​ordx3nu:matrix.org> 😁
16:39:23 <m-relay> <r​ucknium:monero.social> Most of the expense of the MRC hardware was covered by gingeropolous. The implicit deal, I think, is that ging provides most of the hardware free-of-charge since he's mining Monero on it when the CPU threads are free. I hope that ging gives a fuller explanation for what happened with node.moneroworld.com , but consider that getting greenfield owned or rented hardware would be expe<clipped message>
16:39:23 <m-relay> <r​ucknium:monero.social> nsive for the CCS.
16:40:32 <m-relay> <r​ucknium:monero.social> Even with this proposal, ging is paying for the machine. The CCS is just for the RAM (which isn't really needed for mining)
16:40:48 <m-relay> <o​frnxmr:monero.social> Yeah, lets just keep funding his mining operation. I think that's messed up
16:40:59 <plowsof> merging gingeropolous - we could fund sech1 to purchase expensive monero mining equipment and let MRL use it upon request too 
16:41:19 <m-relay> <o​frnxmr:monero.social> Didnt we pay for the rigs with prior ccs' too? I might be mistaken here
16:41:25 <m-relay> <r​ucknium:monero.social> No, he doesn't need this RAM for mining
16:41:33 <plowsof> ah ok
16:41:34 <m-relay> <o​frnxmr:monero.social> Why not just let ruck buy the ram for himself
16:41:53 <m-relay> <r​ucknium:monero.social> With a prior CCS, large SSDs were purchased. Again, that's what research needs, not mining
16:42:09 <nioCat> we are not funding his mining operation, his mining operation is being used by MRL
16:42:25 <m-relay> <r​ucknium:monero.social> nioCat has it right
16:42:27 <m-relay> <o​frnxmr:monero.social> thank niocat
16:42:44 <plowsof> thanks mbull 
16:42:49 <plowsof> moving on
16:42:53 <m-relay> <h​into:monero.social> Rucknium: curious, what is the setup for storing the DB in ram?
16:42:59 <m-relay> <o​frnxmr:monero.social> thanks mbll
16:43:18 <m-relay> <r​ucknium:monero.social> In an R `data.table`
16:43:44 <m-relay> <r​ucknium:monero.social> You want the columns?
16:44:55 <m-relay> <h​into:monero.social> are those stored/reusable by other programs?
16:45:40 <m-relay> <r​ucknium:monero.social> Basically no. It's for statistical analysis. You cannot run the blockchain from this, if that's what you are asking.
16:46:33 <plowsof>   e. [v1docq47 - monerotopia 2024 voiceovers and working on xmr.ru](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/517)    
16:47:08 <plowsof> i've shared this proposal in the xmr.ru matrix room, continued positive support that gets him merged is coming in 
16:47:40 <m-relay> <o​frnxmr:monero.social> Voting merge on account of successful history and always getting funding
16:49:27 <m-relay> <r​ucknium:monero.social> An R `data.table` is extremely fast for statistical analysis, especially for data that has a hierarchical structure like Monero: block -> tx -> ring -> ring member
16:49:27 <m-relay> <r​ucknium:monero.social> https://h2oai.github.io/db-benchmark/
16:49:55 <m-relay> <r​ucknium:monero.social> The downside is that it keeps the data in RAM, so if you have lots of data, you need lots of RAM.
16:50:26 <plowsof> looks like v1docq47 will be merged shuld the trend in feedback continue after its sat for a bit longer
16:51:11 <plowsof> Any other business? 
16:51:32 <plowsof> Are we all waiting for a general fund transparency report?
16:52:55 <m-relay> <o​frnxmr:monero.social> Generalfund 0 1 2 3 4 and 5
16:52:58 <m-relay> <h​into:monero.social> does each program that needs `data.table` map LMDB data to a `data.table` on startup before continuing?
16:54:19 <plowsof> we can end the meeting here then. thank you all for attending 
16:54:50 <m-relay> <r​ucknium:monero.social> All data is pulled in through JSON-RPC queries. It takes about 18 hours to get all data since the bock height RingCT was introduced. There isn't a simple data dump from the LMDB because it's not well-documented and has C++ serialization objects.
16:55:28 <m-relay> <a​js_:matrix.org> Planning meeting starting in #monerokon:matrix.com
16:56:13 <m-relay> <a​js_:matrix.org> Planning meeting starting in #monerokon:matrix.org
16:56:29 <m-relay> <r​ucknium:monero.social> It asks `get_block` and `get_transactions` : https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/code/output-index.R#L114-L128
17:35:56 <m-relay> <r​ottenwheel:kernal.eu> Video was taken down after kayaba's feedback as far as I can tell.
17:37:15 <m-relay> <r​ottenwheel:kernal.eu> Do you have heels? 🧐😳
17:37:27 <m-relay> <v​ostoemisio:matrix.org> We've revised it 👍
17:38:18 <m-relay> <v​ostoemisio:matrix.org> https://drive.proton.me/urls/CCSB8WSXXR#NdDCBXmKgTP5
17:38:19 <m-relay> <v​ostoemisio:matrix.org> Still pending Luke's feedback though
18:43:18 <m-relay> <w​teme:matrix.org> Hello. watched Andy Y on the opt out podcast and ended up here.
20:32:55 <m-relay> <3​21bob321:monero.social> Soon™️