Viewtags im thinking of* but the issue was patched around that time github.com/monero-ecosystem/monero-python/pulls?q=author%3Aplowsof+ aaanyway monero-python dev is inactive and hard to reach in my experience

AcceptXMR too kayabanerve .. burning bug

Disclosed by spirobel / boog and patched swiftly by busyboredom

<b​oog900:monero.social> 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

<b​oog900:monero.social> not an impl bug

<b​oog900:monero.social> well its an impl bug in the wallet :)

Alt implementations idea great, in 2023 reality : could be better

<b​usyboredom:monero.social> 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.

<b​usyboredom:monero.social> 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".

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> Also, -serai, ofc

<k​ayabanerve:matrix.org> BusyBoredom: The burning bug explicitly requires the context of a wallet. Scanning an output does not. monero-rs never grew to have such context.

<k​ayabanerve:matrix.org> It does tell you only competent people should impl Monero wallets, and opens a discussion of competent APIs in libs to enable wallets.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> As for your second paragraph, yes. It's all about competency, and I agree libs should inform their users of the competency required.

<b​usyboredom:monero.social> 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.

<b​oog900:monero.social> 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.`

<b​oog900:monero.social> reddit.com/r/Monero/comments/161zcgy/comment/jy0ufsz

<s​pirobel:monero.social> 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.

<s​pirobel:monero.social> 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.

<s​pirobel:monero.social> We can all agree that we are wicked smart and focus on the sharing knowledge and making Monero a success.

<s​pirobel:monero.social> We can all agree that we are all wicked smart and focus on the sharing knowledge and making Monero a success.

<s​pirobel:monero.social> We can all agree that we are wicked smart and focus on the sharing knowledge and making Monero a success.

<s​pirobel:monero.social> We can all agree that we are wicked smart and focus on sharing knowledge and making Monero a success.

<k​ayabanerve:matrix.org> Agreed on the value of documentation, here via a spec

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

and plowsof might need a new rubber stamp :p

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

with an alt implementation)

anyone have link to kayabaNerve work that is asking funding for?

I see no links to code or paper or anything regarding the proposal

is it this one ? github.com/kayabaNerve/full-chain-membership-proofs

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

<4​rkal:matrix.org> You can also read wtf MoneroOS is about here: github.com/4rkal/MoneroOS/tree/master#moneroos

<1​23bob123:matrix.org> Are you looking for the proposal or the paper for his work?

<b​oog900:monero.social> 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

<b​oog900:monero.social> Again if you run software that requires your node not be on a minority chain split you shouldn't run an experimental node.

<b​oog900:monero.social> 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

<b​oog900:monero.social> 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

1​23bob123: actual work done

noot was very cool on monerokon ( atomic swap eth-xmr proposal)))

which received money from magic monero fund which collects monero donations from monero community, twitter and other social

but hadn't bothered to publish monero view keys up to date

obviously putting this 'crazy' fund transparency to level 0

but now seems I missed that maintainer of this atomic swap is not noot anymore but

Athanor Labs github.com/AthanorLabs/atomic-swap

so monero community donations just became VC seed money? maybe I missed something else

doesn't mention view keys neither Athanor Labs

<r​ucknium:monero.social> sgp: Is there anything preventing MAGIC from publishing the view keys for the wallet that accepts donations at monerofund.org?

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> You can ask in #ethxmrswap:matrix.org

<r​ucknium:monero.social> The MAGIC fundraiser helped get the atomic swaps to beta on mainnet. The funds were not misappropriated.

<r​4v3r23:monero.social> ive replied to your comment on the proposal. i agree with your position

<r​4v3r23:monero.social> asking for funding from community without asking for input isnt a good look

<r​4v3r23:monero.social> should ANONERO also open a retroactive request for 179 XMR now that theyve shipped a sidekick equivalent?

<r​4v3r23:monero.social> should ANONERO also open a retroactive request for 179 XMR now that theyve shipped a Sidekick equivalent?

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

as member of the fund I raised concern about view keys and total lack of transparency

<r​ucknium:monero.social> The work got done. That's what we checked. The license is open source.

there is misconception and charity and non-profits are created to make no profit, people don't understand it just represent the company

while non profit can pay for example justin 10k monthly for doing w/e maintenance

<r​ucknium:monero.social> Let's talk transparency. View keys for funds raised through monerofund.org sounds fine to me. What in addition to that would you like?

I don't need anything, the community needs it

<r​ucknium:monero.social> I think any payment to officers has to be reported in public documents. So that could be checked.

bF takes considerable amount of time yearly to make full report

<r​ucknium:monero.social> What do you think the community needs? View keys alone? Something else?

about general fund

<r​ucknium:monero.social> Ok we could do that.

1) full transparency, bitcoin holdings, bank holdings, full year report

2) applications submits over github

because now I see there is filtering on applications to the fund and what members can vote on

who is making decision on what's being voted on?

<r​ucknium:monero.social> We can consider doing application submissions only over GitHub again. People need GitHub accounts to submit there. And it's harder to attach PDFs

<r​ucknium:monero.social> The committee makes those decisions by vote. We have meeting minutes posted. We could do better about the delays in meeting minutes

<r​ucknium:monero.social> Minutes at the bottom here: magicgrants.org/funds/monero

Yes, github and transparency is hard, let's just have uncle Sam do it on his own way like he was so far

Why voting discussion is hidden from public if you have nothing to hide ? We comment on the CSS freely and in open

tell me once you are done here and I can restart the bridge to get #monero-swap added

<r​ucknium:monero.social> A lot of discussion in the committee happens on voice audio. Voice isn't recorded directly.

<r​ucknium:monero.social> 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.

I raised concern of lack of views keys and to support other community project by posting their donation addresses on fund website

on first or second meeting

after being ignored I see no reason to be part of such fund

dig the logs and say I am liar

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> D​ataHoarder: Restart bridge, please :)

doing so

should all be working, plowsof maybe check that room

<r​ucknium:monero.social> DataHoarder: Thank you!

Much appreciated DataHoarder

<s​gp:magicgrants.org> No, I would support that