<s​hortwavesurfer2009:monero.social> Even when things actually exist i still get errors

<p​reland:matrix.org> That’s….. a lotttt of things to be missing

<p​reland:matrix.org> What Java version?

<s​hortwavesurfer2009:monero.social> 21

<s​hortwavesurfer2009:monero.social> github.com/haveno-dex/haveno/blob/master/docs/installing.md

<s​hortwavesurfer2009:monero.social> I'm not even missing anything. The file is clearly right there.

<f​orestfuturist:matrix.org> Test

<m​rcyjanek0:matrix.org> Ah nixos is special in terms of getting things to work, probably doing a .nix port is the way to go.

Community meeting in 2 hour monero-project/meta #979

<s​hortwavesurfer2009:monero.social> Ill be listening to monerotopia at that time

<s​hortwavesurfer2009:monero.social> Hey plowsof. Would that be the place to bring up that i am looking for a dev? For this?

<s​hortwavesurfer2009:monero.social> bounties.monero.social/posts/102/1-…700m-monerujo-add-full-ipv6-support

<s​hortwavesurfer2009:monero.social> Or is there a better venue?

definitely, thanks!

will share along with some other recent payouts from the bounties site

<s​hortwavesurfer2009:monero.social> Thanks. Id really like to find a dev who can get that done.

<s​hortwavesurfer2009:monero.social> Maybe a bigger bounty is needed, idk

<r​4v3r23:monero.social> i2p support is trivial, but good luck getting monerujo to update

<r​4v3r23:monero.social> and btw, your better off paying devsprojects directly instead of bounties

<r​4v3r23:monero.social> and btw, your better off paying devs/projects directly instead of bounties

<s​hortwavesurfer2009:monero.social> They have nothing on the roadmap for it which is why i made it a bounty

<s​hortwavesurfer2009:monero.social> If somebody makes a working PR they will merge it *eventually*

<r​4v3r23:monero.social> whatever you day

<r​4v3r23:monero.social> meanwhile there are plently of wallets that support i2p

<r​4v3r23:monero.social> whatever you say

<s​hortwavesurfer2009:monero.social> I don't see what I2P has anything to do with it.

<r​4v3r23:monero.social> i misread. point still stands

<r​4v3r23:monero.social> youre better off coordinating with m2049r (good luck)

<s​hortwavesurfer2009:monero.social> Cake only supports ipv6 if u use a domain name, moneroujo is a nope, mysu is missing sub accounts so isnt ready for use, and anon doesnt either. So which wallets can i use?

<s​hortwavesurfer2009:monero.social> Yeah, tell me about it

<r​4v3r23:monero.social> if you want sub accounts in anon, make a bounty for it

but its better to send money direclty to projects/devs? xD

<s​hortwavesurfer2009:monero.social> I really would rather not use anon as its slow af

<r​4v3r23:monero.social> that was my next point :)

sidekick soon

<s​hortwavesurfer2009:monero.social> That and they mix the stupid pin pad up and don't let you change it. So for me, being blind, having to find the numbers every single time is a pain in the ass.

<r​4v3r23:monero.social> oh yeah, you had sync problems. sounds like connection issue on your end, especially if you need ipv6 to use a wallet lmao

<r​4v3r23:monero.social> 2 years later...

<r​4v3r23:monero.social> you have an update

<r​4v3r23:monero.social> ?

<s​hortwavesurfer2009:monero.social> I don't absolutely need IPv6, but it is helpful for connecting to my own node, both inside the house and outside.

<s​hortwavesurfer2009:monero.social> And it was not my issue only because other people were experiencing the same thing. And a non couldn't fix it.

<r​4v3r23:monero.social> it works fine. if you complaint is that tor is slow, then dont use tor

<s​hortwavesurfer2009:monero.social> And all other wallets work fine while a non does not.

<s​hortwavesurfer2009:monero.social> I can use other wallets over tour just fine, but Anon does not load for minutes at a time.

<r​4v3r23:monero.social> youre wrong, like others in the chat told you, sync is fine, somethings up with your node/connection/tor

<r​4v3r23:monero.social> i literally use it everyday

<s​hortwavesurfer2009:monero.social> I can use other wallets over tor just fine, but Anon does not load for minutes at a time.

<s​hortwavesurfer2009:monero.social> Nope, all other wallets work over tor. If it were tor all of them would be that bad, but its only anon

<s​hortwavesurfer2009:monero.social> Mysu is fine over tor as is cake

<r​4v3r23:monero.social> good so dont use it. works fine here and for plenty of others 👍

<s​hortwavesurfer2009:monero.social> Why do you think I'm not using it?That's the exact reason why.

<s​hortwavesurfer2009:monero.social> Not using anon is why i made the bounty on monerujo to begin with. Its a small app size, supports sub accounts, but i cant access my node from off network without manually switching from local 10.0.0.x ip to my plic ipv4. But with v6 i dont have to do that switch each time

<r​4v3r23:monero.social> ?

<m​2049r:matrix.org> Soon

<s​hortwavesurfer2009:monero.social> Ill be listening to monerotopia at that time <<>> it's recorded

<d​iego:cypherstack.com> Where does the unnamed Moner9 Wallet guy hang out?

<d​iego:cypherstack.com> mrcyjanek.net/p/xmruw-monero-wallet

<d​iego:cypherstack.com> He posted here that Stack is a fork from Cake. It isn't.

<r​4v3r23:monero.social> think hes referring to this: github.com/cypherstack/flutter_libmonero

<r​4v3r23:monero.social> matrix.monero.social/_matrix/media/…ero.social/xiEzTQyDZQiiQKTCrliHdotk

<d​iego:cypherstack.com> We use Cake's Monero lib yeah

<m​rcyjanek0:matrix.org> here

<m​rcyjanek0:matrix.org> I was refering to the library used by wallet

<d​iego:cypherstack.com> Cool. All clear. Thanks.

<d​iego:cypherstack.com> Best of luck. Hope your project goes well.

<m​rcyjanek0:matrix.org> Thanks!

<d​iego:cypherstack.com> Wondering if you had considered Monero Serai written in Rust. Coming out around the corner. We're seriously looking at switching over.

<d​iego:cypherstack.com> Not done yet, but looks very promising.

<m​rcyjanek0:matrix.org> I didn't consider switching to it just yet, I've heard of it though, and would love to explorer the possibilities

<d​iego:cypherstack.com> github.com/cypherstack/libxmr

<m​rcyjanek0:matrix.org> cuprate currently looks most promising to me, and I would love to experiment with it - but iirc there is still a long route ahead of the project

<d​iego:cypherstack.com> We've started wrapping it

<m​rcyjanek0:matrix.org> interesting, is it fully compatible monero wallet implemented in rust?

<d​iego:cypherstack.com> Transaction construction, seed generation and restoration

<d​iego:cypherstack.com> That constitutes a "wallet" yes, but nothing beyond that.

<d​iego:cypherstack.com> Well, not quite a full wallet and scanning database functionality needs to be done externally.

<m​rcyjanek0:matrix.org> yeah, then I guess it would require writting everything from scratch

<m​rcyjanek0:matrix.org> yeah

<m​rcyjanek0:matrix.org> so not quite "the thing" I was looking for.

<d​iego:cypherstack.com> Not a problem for Stack since we prefer to use our database structure anyways.

<m​rcyjanek0:matrix.org> I prefer to not touch any of the sensitive code (storing files, encryption, networking) and to let the upstream code do the thing

<d​iego:cypherstack.com> Sounds good.

<m​rcyjanek0:matrix.org> I wonder how porting features such as background sync and coin control would work

<d​iego:cypherstack.com> Well, let is know if we can help or any cross-pollination or anything. We're both Dart-based.

<m​rcyjanek0:matrix.org> Currently I'm getting `dll` and `dylib` to compile to have full cross platform support.

<d​iego:cypherstack.com> Nice!

<m​rcyjanek0:matrix.org> If you would ever want to target SailfishOS (or other exotic mobile linuxes) hit me up as I'd be very happy to help with that

<d​iego:cypherstack.com> Yeah getting windows to work with the cake code is quite the challenge

<d​iego:cypherstack.com> I'd love to!

<m​rcyjanek0:matrix.org> Yeah, it is clearly ios-first app.

<d​iego:cypherstack.com> If youre looking for some extra cash, we're about to put up a bounty to help get the cake lib working for Windows

<d​iego:cypherstack.com> Like we've got a dll building. But the app crashes on seed generation.

<m​rcyjanek0:matrix.org> interesting. I wonder if we hit the same roadblock

<s​hortwavesurfer2009:monero.social> Well, at least you're planting the seeds.

<d​iego:cypherstack.com> cypherstack/flutter_libmonero #61

<m​rcyjanek0:matrix.org> ye

<m​rcyjanek0:matrix.org> `set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)`

<m​rcyjanek0:matrix.org> most likely

<p​lowsof:matrix.org> Meeting time

<m​rcyjanek0:matrix.org> most likely.

<m​rcyjanek0:matrix.org> This is the exact same error I'm getting in monero_c, didn't test if that's the fix yet because I had to leave - but most likely it is. Will reply to the issue once I check it

<p​lowsof:matrix.org> Greetings monero-project/meta #979

<d​iego:cypherstack.com> Please do. Would be thrilled.

<p​lowsof:matrix.org> may i ask Diego Salazar if the cypherstack bp++ 1st payment is being handled/handled?

<d​iego:cypherstack.com> Yes it was. Thanks.

<p​lowsof:matrix.org> thanks for confirming and success further!

<r​ucknium:monero.social> Hi

<p​lowsof:matrix.org> i suppose the biggest highlight of the prev 2 weeks has been the transaction spam* and the resulting discussions (ongoing)

<p​lowsof:matrix.org> Recent bump in block sizes bitinfocharts.com/comparison/monero-size.html#3m Automatic fee has been fixed to go between normal/low depending on mempool status. there is also a new PR to allow miners to limit block weights [here](monero-project/monero #9234) from sech1, suggested by Rucknium

<p​lowsof:matrix.org> hi Rucknium, did you mention having second thoughts about the idea? or?

<m​ichael:monero.social> Hello.

<r​4v3r23:monero.social> yo

<p​lowsof:matrix.org> hi

<r​ucknium:monero.social> Miners self-limiting the size of blocks they produce? No second thoughts about adding the parameter to `get_block_template`. We don't know yet if it is a good idea to suggest that miners actually set the param lower.

<p​lowsof:matrix.org> ah thanks for clarifying

<p​lowsof:matrix.org> its a shame the -events cfp has ended, maybe some talks reg the recent transaction spam could be submitted (if not already ajs_?)

it's a soft deadline

<p​lowsof:matrix.org> hello, we have a cat working for us now. she updates the copyright dates every year [copyCat](monero-project/monero #9252/commits)

articmine has submitted a talk about changes to the dynamic block protocol

now back to laundry

<p​lowsof:matrix.org> awesome, thanks!

<r​ucknium:monero.social> IIRC, you are only supposed to update the copyright year on files that have actually been edited in that year.

*including fees

<p​lowsof:matrix.org> featherwallet.org/changelog tobtoht has been pushing out new versions 👍️ selsta says we are waiting for bF's availability to release 18.3.3 (thank you to the Gitian builders/signers!) github.com/monero-project/gitian.sigs

<p​lowsof:matrix.org> seems sane Rucknium reg copyright changes, im not even sure updating that date even means anything but the core repo gets several pull requests a year of people updating them

<p​lowsof:matrix.org> there was even an open invitation for contributors to update it posted on reddit

<a​js_:matrix.org> CFP deadline ended yesterday, but we might still accept additional talks depending on space availability

<p​lowsof:matrix.org> reddit.com/r/Monero/comments/1bellk…utm_term=1&utm_content=share_button

<p​lowsof:matrix.org> events team has ALOT of updates regarding sponsor payments and other misc things. TheFuzzStone has been offering advice on how to get fiat / cash invoices paid for monerokon (while a bank account is in the workings) - one advice though, please confirm the minimum amounts with TheFuzzStone and do not under any circumstances joke about them !

<p​lowsof:matrix.org> - github.com/monero-project/monero-docs

<p​lowsof:matrix.org> sgp has set up getmonero.dev , which is a fork of github.com/monerodocs/md

<p​lowsof:matrix.org> dan shared that the underlying tech is mkdocs @ github.com/mkdocs/mkdocs

<p​lowsof:matrix.org> does anyone have any input on this?

<r​ucknium:monero.social> We need to figure out domain ownership dead man switches. If they are possible somehow.

<m​rcyjanek0:matrix.org> Very good idea, some technical introduction regarding how to build things that use monero's codebase would be good (I'm willing to contribute that), because it is quite easy to become lost when trying to use the codebase for first time.

<m​rcyjanek0:matrix.org> So not only cli/rpc/gui docs but also wallet2_api.h and possibly libraries for other languages (rpc clients, and ffi).

<p​lowsof:matrix.org> i was asked by at least one person why the license is changed for the unofficial version at getmonero.dev to "Copyright © MoneroDocs.org Contributors, MAGIC Grants, and Other Contributors. MIT Licensed."

<p​lowsof:matrix.org> this was done before 'monero - docs ' on a monero-project repo was considered possible

<p​lowsof:matrix.org> sgp has explained the reasons but theyre not at hand atm

<r​ucknium:monero.social> AFAIK, if MAGIC Grants added any content, then you are supposed to add them to the copyright statement. The MAGIC Monero Fund _committee_ (I know it's confusing) has not helped with getmonero.dev yet by the way.

<p​lowsof:matrix.org> they are named specifically while "Contributors" are not

<p​lowsof:matrix.org> although on github the full list of contributors is visible

<r​ucknium:monero.social> For example, monerofund.org has "© Open Sats Initiative and MAGIC Grants, 2024". The website code was forked from Open Sats. Then we changed the code a lot to fit our requirements.

<r​ucknium:monero.social> Ok. Someone can make a PR to add the full list to the website footer.

<p​lowsof:matrix.org> then we would have people complaining about the infinitely long list of contributors and how we need a javascript search function

<r​ucknium:monero.social> For a permissionless currency, it seems you need the permission from a lot of people to set up anything in the Monero ecosystem.

<p​lowsof:matrix.org> a deadmans switch for domain ownership 🤔 interesting.. i could imagine a few "im not dead, the reminder when to my spam box, can you transfer it back lol"

<p​lowsof:matrix.org> anything else to discuss before getting to the ccs idea list?

<p​lowsof:matrix.org> quick plug of a bounty for adding ipv6 to monerujo , requested by shortwavesurfer2009 bounties.monero.social/posts/102/1-…700m-monerujo-add-full-ipv6-support

<p​lowsof:matrix.org> SNeedleWoods add LegacyEnoteOriginContext for Seraphis [pull request](seraphis-migration/monero #16#issue-2026817626) 🫡

<p​lowsof:matrix.org> ok lets discuss the idea list

<p​lowsof:matrix.org> 5. [CCS updates](ccs.getmonero.org) | [hinto](repo.getmonero.org/monero-project/c…als/-/merge_requests/422#note_23548) | [tobtoht](repo.getmonero.org/monero-project/c…als/-/merge_requests/428#note_23555)

<p​lowsof:matrix.org> a. [Unnamed Monero Wallet development](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/437)

<p​lowsof:matrix.org> aka xmruw

<p​lowsof:matrix.org> Czarek Nakamoto: is here, and has provided a comment comparing his work to valdracs monero-wallet-sdk

<p​lowsof:matrix.org> repo.getmonero.org/monero-project/c…als/-/merge_requests/437#note_23529

<m​rcyjanek0:matrix.org> Correct, it is quite long and technical but it comes down to the fact that both project have different goals and target different usecases.

<m​rcyjanek0:matrix.org> > monero-wallet-sdk focuses on android while xmruw focuses on being cross platform

<m​rcyjanek0:matrix.org> > monero-wallet-sdk focuses on stable api for developers while xmruw focuses on offering as small abstraction as possible

<m​rcyjanek0:matrix.org> > both projects aim for good developer experience (things like IDE suggestions)

<p​lowsof:matrix.org> r4v3r23 has suggested separating monero_c from xmruw

<p​lowsof:matrix.org> the proposal has 2 milestones, is that everything listed under 'plans'?

<m​rcyjanek0:matrix.org> I assume that he meant separating them into 2 CCSes. I'm slightly against this idea because it would make development more annoying and testing rather impossible, the projects monero_c, byteworks, offline_market_data, monero.dart are all separate and can be used easily by 3rd party software.

<m​rcyjanek0:matrix.org> Yes, it is everything listed in plans + some other minor features, such as PoS mode for sellers (which is currently in works), it will allow people to input product IDs and scan them to create real-life PoS experience

<r​4v3r23:monero.social> no, i meant removing the xmruw portion. besides feather (already establshed dev/wallet) all other wallets get funding on their own

<m​rcyjanek0:matrix.org> and the docs update I've mentioned earlier - as I think that I've hit every possible edge case I could while working with monero code.

<p​lowsof:matrix.org> the question is what is the sentiment here, we had comments from tobtoht (who is having a rest after release) and rbrunner. just waiting for a response

<m​rcyjanek0:matrix.org> > all other wallets get funding on their own

<m​rcyjanek0:matrix.org> monero-wallet-sdk did their demo wallet as a part of CCS.

<m​rcyjanek0:matrix.org> you can consider xmruw the same, as it is really "just a demo" of all the libraries mentioned above.

<p​lowsof:matrix.org> that came about because molly required it be created for various reasons (some security related)

<r​4v3r23:monero.social> demo wallet is just that, a demo wallet. your asking for funding for the whole wallet project. its in the title of the ccs

<r​4v3r23:monero.social> i guess all wallets are "just demos" of wallet2

<p​lowsof:matrix.org> the ccs funded tesla to accept monero as payment and coral reef. anything is possible

<r​4v3r23:monero.social> noted

<m​rcyjanek0:matrix.org> Yes, I'm asking to support the full suite, all packages and a wallet. Developing libraries without a proper usecase for them just doesn't work. The wallet itself is not the major task here. monero_c is currently the biggest of them. monero_c wouldn't exist without xmruw, and xmruw can't exist without monero_c.

<p​lowsof:matrix.org> lol

<m​rcyjanek0:matrix.org> My current tests on byteworks pass 100%, but in real-world usecases I've noticed bugs. I can't separate the project without a large cost in terms of how good the software is.

<m​rcyjanek0:matrix.org> My current tests on bytewords pass 100%, but in real-world usecases I've noticed bugs. I can't separate the project without a large cost in terms of how good the software is.

<p​lowsof:matrix.org> there was alot of interest in having monero inside molly, this was merged. from this ccs came the need for monero-wallet-sdk (monero_c)

<p​lowsof:matrix.org> xmruw needs monero_c

<r​4v3r23:monero.social> monero_c doesnt need xmruw

<m​rcyjanek0:matrix.org> Also xmruw targets platforms not officially supported by any wallets - such as SailfishOS and alpine linux (including PostmarketOS). So the entire effort also makes it easier to use monero in privacy enabled setups.

<r​ucknium:monero.social> plowsof: I don't recall seeing comments from rbrunner and tob about this CCS. Is it in the IRC/Matrix logs?

<p​lowsof:matrix.org> sorry moment

<p​lowsof:matrix.org> i clipped the logs of the prev meeting half way* will fix that later

<p​lowsof:matrix.org> tobtohts comment libera.monerologs.net/monero-community/20240302#c337258

<m​rcyjanek0:matrix.org> > monero_c doesnt need xmruw

<m​rcyjanek0:matrix.org> Making the library on its own will require me to write synthetic tests for all the libraries because I wouldn't be able to uncover bugs (such as the one in bytewords).

<m​rcyjanek0:matrix.org> and tests are nowhere near the user testing in terms of how well they catch bugs.

<m​rcyjanek0:matrix.org> and sure I can make demos for each project separately, but that would be just a waste of time, and wouldn't deliver any real project.

<m​rcyjanek0:matrix.org> while now we have a cross platform wallet.

<r​4v3r23:monero.social> also, a couple of devs asked why wallet2_api instead of wallet2.h directly

<r​4v3r23:monero.social> mooo asked that when i firsted mentioned a C lib was being worked on

<r​4v3r23:monero.social> tohtobt also expressed that, saying wallet2_api.h itself is an abstraction on top of wallet2.h

<p​lowsof:matrix.org> rbrunners comments must have came some days later (i will find them unless it was a false memory)

<p​lowsof:matrix.org> commenting on the perceived ease of adapting to seraphis

<m​rcyjanek0:matrix.org> > tobtohts comment

<m​rcyjanek0:matrix.org> line 63: OG response: pastebin.com/NQb5ejWc, I don't want to wait until wallet3 shows up, and I want to work on the project currently, when it comes I'll also do my best to enable people to have a seamless migration if they opted to use monero_c.

<p​lowsof:matrix.org> thanks Czarek i was looking for the paste

<m​rcyjanek0:matrix.org> > also, a couple of devs asked why wallet2_api instead of wallet2.h directly

<m​rcyjanek0:matrix.org> Because there is api, that tends to be more stable than internal functions in general, and it was used by every single lib/wallet I've seen (except for simplewallet).

<m​rcyjanek0:matrix.org> > tohtobt also expressed that, saying wallet2_api.h itself is an abstraction on top of wallet2.h

<m​rcyjanek0:matrix.org> True, a stable abstraction. I didn't feel the need to invent anything from scratch, I've just wrapped already existing code.

<p​lowsof:matrix.org> rbrunners comments a day later libera.monerologs.net/monero-community/20240303#c337362

<m​rcyjanek0:matrix.org> also r4v3r23 you didn't appear to have anything against the way it is being developent, and you were pretty close to the project since day 0.

<r​4v3r23:monero.social> tohtobt mentioned they managed to remove wallet2api and reduce to "libwalletqt -> wallet2.h in most places"

<p​lowsof:matrix.org> "no such brand-new Monero wallet should start today and thus "this late in the game" without the dev(s) having a good long look at Jamtis and Seraphis first, and then add info to their CCS proposal how their project looks in this light."

<p​lowsof:matrix.org> from rbrunner above^

<m​rcyjanek0:matrix.org> sure, but that would cause reinvention of the wallet2_api.h in my usecase, which I didn't feel the need to do. There is a stable API available, so I've decided to use it.

<r​4v3r23:monero.social> i was waiting for it to be stable before making judgement, and that was a major part of the delay

<r​4v3r23:monero.social> this entire thing started from an experiment

<m​rcyjanek0:matrix.org> I can't say anything else except "it happened". I agree that it shouldn't, but since most of the work is already done I think that polishing it is the way to go, to deliver a stable and cross platform wallet and libraries to power many new apps and projects.

<r​ucknium:monero.social> Do we have time to discuss my CCS idea? It's not posted yet, but I would like input on the first draft

<r​ucknium:monero.social> *for the first draft

<m​rcyjanek0:matrix.org> at this point abandoning the project is not an option for me - too much time got put into it. However I need funding to continue working on it, otherwise it will cause huge delays as I'll have to work on other things first

<p​lowsof:matrix.org> yes, but b. Payout request for monero-gui flathub proposal [comment](repo.getmonero.org/monero-project/c…als/-/merge_requests/381#note_23554)

<p​lowsof:matrix.org> in the comment i have linked the stats showing flathub flatpak receiving updates throughout the year. the manifest is on the core repo but not complete. payout request for milestones 2 - 3 - 4 - 5

<p​lowsof:matrix.org> if anyone wants to read / vote / comment on that please do

<p​lowsof:matrix.org> Rucknium can you share your CCS idea(s)?

<r​ucknium:monero.social> This would be 20 hours/week for three months of statistical research to improve Monero's privacy, guide protocol decisions, and respond to Monero developer requests for statistical analysis of code changes where needed. The start would be to analyze the suspected black marble flooding that is happening now. Effects of possible countermeasures, minimal safe parameter levels, and pr<clipped message>

<r​ucknium:monero.social> oviding evidence for and/or against the black marble flooding hypothesis.

<p​lowsof:matrix.org> kinghat: is a monero gui flatpak enjoyer and could offer some feedback.. selsta has seen BMP work through flatpak issues also

<r​ucknium:monero.social> This would be in parallel to the OSPEAD work that is near completion. Basically, the flooding analysis is more urgent since it's happening now. OSPEAD probably has to wait for the next hard fork for safe implementation.

<r​ucknium:monero.social> Other research questions could be ring member binning, Pocket Change privacy, EAE/EABE attack, fee discretization, and 10 block lock adjustment safety.

<r​ucknium:monero.social> I could not research all those topics in a 3 month period of course, but the community can help set research priorities.

<p​lowsof:matrix.org> would this be a similar deliverable as "analysing a flood"?

<p​lowsof:matrix.org> the recent spam is definitely a hot topic. you even shared some figures reg possible ring size degradation

<r​ucknium:monero.social> OSPEAD will suggest an update to Monero's decoy selection algorithm for ring signatures to mimic the real spend age distribution.

<r​ucknium:monero.social> plowsof: The first priority is to research possible critical thresholds of flooding that would be a major threat to user privacy. See how bad it could be _if_ it is actually black marble flooding.

<r​ucknium:monero.social> Then yes do more analysis like "Fingerprinting a Flood". I would re-run our 2021 analysis and also analyze the mempool tx arrival data that we didn't have back in 2021. And maybe try to crawl the network to figre out the possible node origin(s) of the flood.

<r​ucknium:monero.social> There is a risk ,if the effective ring size gets too low, of chain reaction attacks.

<p​lowsof:matrix.org> _some_ of ruckniums previous contributions are detailed here rucknium.me

<r​ucknium:monero.social> This was our analysis back in 2021 of a smaller suspected spam incident: mitchellpkt.medium.com/fingerprinti…ero-transaction-volume-a19cbf41ce60

<r​ucknium:monero.social> The effective ring size analysis and chain reaction threshold analysis would help decide, for example, if mining pools could help by voluntarily self-limiting their block size and/or how raising the ring size to certain levels could help. And any fee changes or dynamic block size changes.

<r​ucknium:monero.social> Any input appreciated :D

will you work with ArticMine on this?

<p​lowsof:matrix.org> positive effects if any of limiting block sizes ... how raising ring sizes could help... looking at fees and dynamic block sizes seems important to a layman like myself

or rather have input from him

<r​ucknium:monero.social> Yes, if ArticMine wants to.

him helping you direction would be great

<r​ucknium:monero.social> ArticMine and I already discussed some preliminary analysis and proposals in #monero-research-lab:monero.social

my vote is merge :D

<r​ucknium:monero.social> Ok I will directly ask him if he wants to work closely on this.

<p​lowsof:matrix.org> some of it is here libera.monerologs.net/monero-research-lab/20240314#c347465

<p​lowsof:matrix.org> irc users cant access the matrix logs is all

<a​ck-j:matrix.org> +1 for Ruck CCS

<r​ucknium:monero.social> I am working on a preliminary document that estimates empirical effective ring size if the tx volume is black marble flooding, long-term projections of effective ring size at several nominal ring size levels, and tx confirmation delay analysis.

<p​lowsof:matrix.org> +1 here

<p​lowsof:matrix.org> +2 if you tell me how i can get on a contributor list with the least mount of work

<r​ucknium:monero.social> And the additional GB added to the blockchain and total fee paid by the attacker if it is an attacker.

<p​lowsof:matrix.org> available for running scripts on server(s) as always

<r​ucknium:monero.social> Well, you already contributed the mempool data collection, so you get a mention :)

<a​ck-j:matrix.org> I’m in favor of having a proper security analysis of the newly proposed scaling definitions.

<a​ck-j:matrix.org> We should have a strong idea of cost to perform a DOS or black marble attack

<p​lowsof:matrix.org> also spackle_xmr, your churn script is gone from github, i was wondering about that

<p​lowsof:matrix.org> thanks for sharing the idea Rucknium and those who left feedback so far

<w​oodser:monero.social> yeah I'm also curious to see more analysis on cost to spam the blockchain

<w​oodser:monero.social> it's not helping us if it's too cheap

<r​ucknium:monero.social> I can add that. It was one of my items in "A Statistical Research Agenda for Monero" github.com/Rucknium/presentations/b…ucknium-Monerotopia-2023-Slides.pdf

<r​ucknium:monero.social> "Monero’s dynamic block size has not received the same amount of research scrutiny as its privacy features."

<1​23bob123:matrix.org> “Organic” “usage”

<p​lowsof:matrix.org> pls do not forget that the "cost" in terms of xmr is HIGH (if xmr was priced around BTC) as sech1 stated we also 5*d the fees recently

<r​ucknium:monero.social> 1) Can the dynamic block size parameters result in undesirable outcomes, e.g. too fast or too slow block size increase?

<r​ucknium:monero.social> 2) The interaction of block size and fee policy is supposed to adjust fee to the purchasing power of a unit of XMR in the future (a type of “oracle” problem). Can this go wrong?

<r​ucknium:monero.social> 3) Is it possible to have a fee policy that discourages adversarial spam but provides low fees for people around the globe?

<r​ucknium:monero.social> ^ Those were some of my research agenda questions from Monerotopia 2023

<p​lowsof:matrix.org> i think we can put an end to the meeting and continue discussion on this. thank you all for attending and sorry for the slow start and going over

<1​23bob123:matrix.org> Probably should just fork monerodocs and modify from there, then things would get started, otherwise we have to wait for core to setup.

<1​23bob123:matrix.org> mkdocs material has client side search so if js is disable still works

<1​23bob123:matrix.org> squidfunk.github.io/mkdocs-material/setup/setting-up-site-search

<1​23bob123:matrix.org> and also can be run offline

<1​23bob123:matrix.org> squidfunk.github.io/mkdocs-material/plugins/offline/?h=offline

plowsof: am I remembering correctly that the 5x fee increase was due to the reduction of tx size and therefore fees brought about by bulletproofs?

<p​lowsof:matrix.org> sech1^ im pretending to be afk because i dont know

<p​lowsof:matrix.org> thanks for the extra context/reasoning if true nioCat

<p​lowsof:matrix.org> thanks Dan 🤐 | alderman (Is not the man & Braxman Tomsparks Advocate )

I don't remember

we went from MLSAG to CLSAG Oct 2020

<r​ucknium:monero.social> IIRC BulletProofs+ reduced tx sizes by about 10%. I am not sure, but I think the Fingerprinting a Flood analysis influenced the 5x fee increase .

I think fee change was after that

<r​ucknium:monero.social> Fingerprinting a Flood estimated "At the time, the exchange rate for Monero was about 200 USD per XMR, so the cost of generating ~365,000 transactions would have been $1,000. A 2-in/2-out transaction weighs about 1.93 kB so these transactions would have added about 700 MB to the chain, at a cost of $1.40 per MB."

bulletproofs Oct 2018

<1​23bob123:matrix.org> github.com/monero-project/monero-docs. plowsof maybe luigi can enable discussion on repo?

<1​23bob123:matrix.org> docs.github.com/en/discussions/quic…thub-discussions-on-your-repository

<1​23bob123:matrix.org> Dont want to have to make matrix room/irc for docs

<r​ucknium:monero.social> Some of the discussion about the 5x fee increase in the August 2022 hard fork happened here: monero-project/research-lab #70

xmrack has one specifically for spam :P

<r​ucknium:monero.social> If we feel the need to hide how the dynamic block size works to prevent its misuse, that is not a good place to be in. Not a criticism of your decision, spackle.

Streisand effect

<s​packle_xmr:matrix.org> Fair enough. Looking at the current tx activity, I can easily imagine that it is someone running a modified version of the 'fracture' script that I wrote. The possibility made me uncomfortable with having it public.

<1​23bob123:matrix.org> Be like solana delete mempool 😬

<s​packle_xmr:matrix.org> Not that any of my very simple scripts are great achievements. As others have noted, it is easy to write (bad) spam scripts.

<s​packle_xmr:matrix.org> If someone is actually running what I wrote as an attack, one of the bigger hints is how inept it has been so far.

:D

<k​inghat:matrix.org> how has the increase in tx had on avg confirmation time?

only affects getting into a block if you use min/unimportant fee setting

other than that 2 min/block

<k​inghat:matrix.org> sorry, first confirm. iirc the gui defaults to auto which is "slow".

<k​inghat:matrix.org> assuming slow is what the majority of people use.

No idea about th gui but AIUI starting with 0.18.3.2 the auto fee adjustment should be working

Works in the CLI

selsta^

<t​hilool:matrix.org> Hello, is there a reason why the Linux 64 bit version of monero-cli v0.18.3.2 is not available for download on get Montero.org?

<t​hilool:matrix.org> Only the 32bit is available. Or is the file name simply not updated?

<t​hilool:matrix.org> Thx!

<t​hilool:matrix.org> I mean of course getmonero.org

<t​hilool:matrix.org> Stupid autocorrect

i see Linux 64 link under download -> cli which points tohttps://downloads.getmonero.org/cli/linux64

are you not able to see that @ getmonero.org/downloads

<t​hilool:matrix.org> Yes but when you run the download you get the 0.18.3.1 file 🤔

<1​23bob123:matrix.org> Someone else said this

<1​23bob123:matrix.org> Clear browser cache/history ?

try this downloads.getmonero.org/cli/linux64_please

i sanity checked that the 18.3.2 binary is inside the download zip (thankfully it is)

<t​hilool:matrix.org> That was the issue...thx for the fast help.

<t​hilool:matrix.org> Must remember that for the next time 🙂

for next time you would have to click downloads.getmonero.org/cli/linux64_please_again_lol

and so on.. the new link just avoids the cache (or clear the cache)

19:42 <m-relay> <k​inghat:matrix.org> sorry, first confirm. iirc the gui defaults to auto which is "slow". <-- auto switches between slow and normal depending on backlog

<p​lowsof:matrix.org> thanks for confirming