00:01:30 Viewtags im thinking of* but the issue was patched around that time https://github.com/monero-ecosystem/monero-python/pulls?q=author%3Aplowsof+ aaanyway monero-python dev is inactive and hard to reach in my experience 00:08:41 AcceptXMR too kayabanerve .. burning bug 00:10:35 Disclosed by spirobel / boog and patched swiftly by busyboredom 00:11:39 AcceptXMR uses monero-rs a library that unlike monero-serai doesn't keep track of one time addresses so this is arguably a wallet bug as well 00:11:57 not an impl bug 00:12:34 well its an impl bug in the wallet :) 00:13:09 Alt implementations idea great, in 2023 reality : could be better 00:26:03 It's tricky 'cause you don't always know what "wallet" bugs affect your software. AcceptXMR doesn't run a wallet, so I never considered that the burning bug affected it until some smarter people pointed it out. 00:26:03 IMO things like timelocks and the burning bug are a broad ecosystem documentation issue. New devs aren't aware they exist in the first place, and even seeing them in an API in passing isn't sufficient. Newcomers need something in big bold text saying "hey, if you write code to accept monero and you don't check these things, your fly is down". 00:42:04 AFAIK, monero-rs has been done properly and is the only lib we should be discussing here as a re-impl. monero-python doesn't count as a re-impl IMO. 00:42:05 Also, -serai, ofc 00:42:43 BusyBoredom: The burning bug explicitly requires the context of a wallet. Scanning an output does not. monero-rs never grew to have such context. 00:43:07 It does tell you only competent people should impl Monero wallets, and opens a discussion of competent APIs in libs to enable wallets. 00:44:06 monero-serai only lets you scan a TX via an API requiring a context view, and returns outputs wrapped in a struct requiring handling the time lock to access the outputs themselves. 00:44:37 As for your second paragraph, yes. It's all about competency, and I agree libs should inform their users of the competency required. 01:05:29 I'm a little hesitant to use the word "competent" here because I think even very competent devs can step on landmines like these, but I agree with your overall point that devs need to know about relevant vulnerabilities if they're gonna write secure software. 01:11:05 IMHO I don't think throwing around bugs found in other projects is very helpful, we all should know the pros and cons of a new impl by now, from kayaba on reddit: `It increases the likelihood of a chain split, and numerically, increases the amount of vulnerabilities. The point is to reduce the amount of critical vulnerabilities though.` 01:11:05 https://www.reddit.com/r/Monero/comments/161zcgy/comment/jy0ufsz/ 03:04:42 To some degree it is the duty of the library and the Monero project as a whole to provide a clear path to competency. Right now the information necessary to avoid pitfalls is scattered everywhere. 03:07:26 We should focus on making people competent instead of having an endless debate and posturing about who is competent, who is an "ignorant newcomer" and other fun stuff. 03:13:30 We can all agree that we are wicked smart and focus on the sharing knowledge and making Monero a success. 03:15:58 We can all agree that we are all wicked smart and focus on the sharing knowledge and making Monero a success. 03:17:27 We can all agree that we are wicked smart and focus on the sharing knowledge and making Monero a success. 03:19:11 We can all agree that we are wicked smart and focus on sharing knowledge and making Monero a success. 05:50:38 Agreed on the value of documentation, here via a spec 06:04:22 boog900: the Rust node idea wasn’t rejected, but it wasn’t properly discussed either. There’s likely to be more discussion during the next CCS proposal 06:08:16 and plowsof might need a new rubber stamp :p 09:18:41 Boog is going to find issues with consensus rules / disclose them discretely resulting in fixes to monero-core - then everyone who upvoted this proposal will be celebrated as heros. (We could ask why hackerone pot isnt good enough for enticing people to find/report critical vulnerabilities, instead of introducing more bugs / chances of chain splits 09:18:41 with an alt implementation) 10:49:12 anyone have link to kayabaNerve work that is asking funding for? 10:49:44 I see no links to code or paper or anything regarding the proposal 10:51:47 is it this one ? https://github.com/kayabaNerve/full-chain-membership-proofs/ 10:57:09 <4​rkal:matrix.org> hey guys, after quite some time developing. The number one requested feature for MoneroOS has been added. P2Pool support! I'm looking for people to test it out. You can grab the latest release from https://github.com/4rkal/MoneroOS/releases/tag/v0.3.5 . I have also created a seperate matrix room so that we dont fill this one. Join `#moneroOS:matrix.org` if your intrested. 10:57:57 <4​rkal:matrix.org> You can also read wtf MoneroOS is about here: https://github.com/4rkal/MoneroOS/tree/master#moneroos 11:42:03 <1​23bob123:matrix.org> Are you looking for the proposal or the paper for his work? 12:14:36 Just looking at code is not always enough to spot issues, I point to DF and now monero-serai which both found issues with monero after creating an alt impl 12:14:36 Again if you run software that requires your node not be on a minority chain split you shouldn't run an experimental node. 12:14:37 I would also say finding issues with consensus rules is not the only thing an alt node will do, it will also give the network more resilience against attacks on nodes, as a bug/ flaw in one node is unlikely to be an issue in the other 12:14:37 I personally cant spend the amount of time I'm proposing to spend creating a consensus doc, and implementing the rules in Rust for the chance at a hackerone payout if I find a bug 12:21:58 1​23bob123: actual work done 12:25:22 noot was very cool on monerokon ( atomic swap eth-xmr proposal))) 12:26:26 which received money from magic monero fund which collects monero donations from monero community, twitter and other social 12:26:45 but hadn't bothered to publish monero view keys up to date 12:27:52 obviously putting this 'crazy' fund transparency to level 0 12:28:52 but now seems I missed that maintainer of this atomic swap is not noot anymore but 12:29:11 Athanor Labs https://github.com/AthanorLabs/atomic-swap 12:30:18 so monero community donations just became VC seed money? maybe I missed something else 12:31:51 https://monerofund.org/projects/eth_xmr_atomic_swaps 12:32:14 doesn't mention view keys neither Athanor Labs 12:49:10 sgp: Is there anything preventing MAGIC from publishing the view keys for the wallet that accepts donations at monerofund.org? 12:53:49 M​ajesticBank: I don't know why the ETH<>XMR atomic swap repo is under the AthanorLabs organization. AFAIK AthanorLabs doesn't have any other online presence except for the github org. Its other repos look like just support libraries for the atomic swap repo. 12:53:59 You can ask in #ethxmrswap:matrix.org 13:00:51 The MAGIC fundraiser helped get the atomic swaps to beta on mainnet. The funds were not misappropriated. 13:05:19 ive replied to your comment on the proposal. i agree with your position 13:06:12 asking for funding from community without asking for input isnt a good look 13:07:02 should ANONERO also open a retroactive request for 179 XMR now that theyve shipped a sidekick equivalent? 13:07:30 should ANONERO also open a retroactive request for 179 XMR now that theyve shipped a Sidekick equivalent? 13:07:56 r​ucknium: If you as one of most relevant magic member have no idea what's happening it's proving fund members committee is just a charade 13:08:41 as member of the fund I raised concern about view keys and total lack of transparency 13:09:33 The work got done. That's what we checked. The license is open source. 13:09:34 there is misconception and charity and non-profits are created to make no profit, people don't understand it just represent the company 13:09:58 while non profit can pay for example justin 10k monthly for doing w/e maintenance 13:10:21 Let's talk transparency. View keys for funds raised through monerofund.org sounds fine to me. What in addition to that would you like? 13:11:16 I don't need anything, the community needs it 13:11:26 I think any payment to officers has to be reported in public documents. So that could be checked. 13:11:49 bF takes considerable amount of time yearly to make full report 13:11:52 What do you think the community needs? View keys alone? Something else? 13:11:56 about general fund 13:12:47 Ok we could do that. 13:12:54 1) full transparency, bitcoin holdings, bank holdings, full year report 13:13:10 2) applications submits over github 13:14:15 because now I see there is filtering on applications to the fund and what members can vote on 13:15:03 who is making decision on what's being voted on? 13:15:16 We can consider doing application submissions only over GitHub again. People need GitHub accounts to submit there. And it's harder to attach PDFs 13:15:57 The committee makes those decisions by vote. We have meeting minutes posted. We could do better about the delays in meeting minutes 13:17:01 Minutes at the bottom here: https://magicgrants.org/funds/monero/ 13:32:48 Yes, github and transparency is hard, let's just have uncle Sam do it on his own way like he was so far 13:33:32 Why voting discussion is hidden from public if you have nothing to hide ? We comment on the CSS freely and in open 13:34:59 tell me once you are done here and I can restart the bridge to get #monero-swap added 13:39:33 A lot of discussion in the committee happens on voice audio. Voice isn't recorded directly. 13:39:52 M​ajesticBank: You were elected to the committee and then didn't come to meetings. It's fine that you're giving feedback now, but it would have been better to do it as a committee member. 13:45:41 I raised concern of lack of views keys and to support other community project by posting their donation addresses on fund website 13:46:08 on first or second meeting 13:46:46 after being ignored I see no reason to be part of such fund 13:47:23 dig the logs and say I am liar 14:03:38 I do see here in the logs that you brought it up once, but there wasn't a meeting at that time. You brought up several other ideas at the same time, such as posting non-MAGIC fundraisers and dev donation addresses on our website. kayabaNerve responded to the non-MAGIC fundraisers idea, but not the view key idea. 14:22:20 D​ataHoarder: Restart bridge, please :) 14:26:36 doing so 14:33:05 should all be working, plowsof maybe check that room 14:34:24 DataHoarder: Thank you! 14:40:26 Much appreciated DataHoarder 16:30:06 No, I would support that