<3​21bob321:monero.social> funny you say that. In one of the selfhosted rooms an admin has OCD and bans threads lol

<k​ewbit:matrix.org> How do the milestones work on a CCS?

Kewbit whats the issue?

<s​hortwavesurfer2009:monero.social> matrix.to/#/!gQJbRTGiTuVmJhnVGe:mat….social&via=matrix.org&via=envs.net

<m​onerobull:matrix.org> youtu.be/WkphgF6Hn4w

<3​21bob321:monero.social> Oo random links

<3​21bob321:monero.social> Ima gonna touch it

<m​onerobull:matrix.org> plowsof @plowsof:matrix.org: and ofrnxmr: featured

<k​ewbit:matrix.org> plowsof: No issue I’m just wondering how they work, I expect like normal mile stones?

<k​ewbit:matrix.org> Like do one thing deliver get paid do the next get paid etc etc until completed

Yes. Proposers put an update/payout request in the comments showing how theyve completed the milestone(s) kewbit

<k​ewbit:matrix.org> Ok cool I will post an update shortly

Nice kewbit. Thanks for sharing monerobull 👀

<m​onerobull:matrix.org> Obviously code has to be open for payouts though

<k​ewbit:matrix.org> I work 32 hour shifts on this and often sleep every *other* day, trust me, it's coming very soon.

<k​ewbit:matrix.org> This is partially true, I think there are some binaries embedded but the casn be removed, then we can secure the daemon in docker (which I've done) and or flatpak and snap have certain system access level stuff which can be changed. Docker is nice, you can restrict certain behaviour kernal level, there is a small risk on the java side in that we should maintain our own maven serve<clipped message>

<k​ewbit:matrix.org> r with clones of all packages that we use at least this way another developer who's plugin we depend on is either version locked or we just, again maintain our own forks of each one.

<k​ewbit:matrix.org> This is partially true, I think there are some binaries embedded but the can be removed, then we can secure the daemon in docker (which I've done) and or flatpak and snap have certain system access level stuff which can be changed. Docker is nice, you can restrict certain behaviour kernal level, there is a small risk on the java side in that we should maintain our own maven server<clipped message>

<k​ewbit:matrix.org> with clones of all packages that we use at least this way another developer who's plugin we depend on is either version locked or we just, again maintain our own forks of each one.

<k​ewbit:matrix.org> There is an obvious problem with not embedding woodsers binaries inside the JAR file, is that it they take freeeking hours to compile from source, and all things considered, the community will get what they need in the end however once you finally get it and want to start compiling the app yourselfs make sure you got some damn good hardware to do it on :) I havent tried compiling <clipped message>

<k​ewbit:matrix.org> monerod but I think it takes like 7 hours just for that?

<k​ewbit:matrix.org> We also need to look down the dependancies tree on the Java side of things, it's easier for me to do that with Dart on my side because F-Droid will just reject builds if it finds binaries anywhere AFAIK, maybe there is to dependancy analysis tool that can locate binaries in mave/java etc and I guess we make sure they all build from source in every case. This is top level security <clipped message>

<k​ewbit:matrix.org> paranoia of course and it's an ongoing maintenance consideration, this cant be expected as an immediatelt deliverly, rather something that get more security over times and as we maintain.

<k​ewbit:matrix.org> There is an obvious problem with not embedding woodsers binaries inside the JAR file, is that it they take freeeking hours to compile from source, and all things considered, the community will get what they need in the end however once you finally get it and want to start compiling the app yourselfs make sure you got some damn good hardware to do it on :) I havent tried compiling <clipped message>

<k​ewbit:matrix.org> monerod but I think it takes like 7 hours just for that?

<k​ewbit:matrix.org> We also need to look down the dependancies tree on the Java side of things, it's easier for me to do that with Dart on my side because F-Droid will just reject builds if it finds binaries anywhere AFAIK, maybe there is a dependancy analysis tool that can locate binaries in mave/java etc and I guess we make sure they all build from source in every case. This is top level security p<clipped message>

<k​ewbit:matrix.org> aranoia of course and it's an ongoing maintenance consideration, this cant be expected as an immediatelt deliverly, rather something that get more security over times and as we maintain.

<s​yntheticbird:monero.social> I compiled monerod in under 10 minutes

<k​ewbit:matrix.org> but thisis a dev convo me and woodser need to have

<k​ewbit:matrix.org> which one was it that takes like 7 hours

<k​ewbit:matrix.org> I swear there was something

<s​yntheticbird:monero.social> I don't know but there is no way monerod take more than 30 minutes to compilr

<k​ewbit:matrix.org> What's that on though a threadripper? haha

<k​ewbit:matrix.org> 128 core

<s​yntheticbird:monero.social> 8 threads on a ryzen 3rd gen

<k​ewbit:matrix.org> so I guess I must have be doing something wrong on my 32 core Ryzan 9

<k​ewbit:matrix.org> maybe was compiling too many unnessesary headers or something

<s​yntheticbird:monero.social> Very weird indeed

<k​ewbit:matrix.org> I'm not much into C so canr comment more

<k​ewbit:matrix.org> I'm not much into C so cant comment more

<k​ewbit:matrix.org> either way, it seems like there is no excuse for binaries or libs at alll then

<k​ewbit:matrix.org> I say be gone with them

<k​ewbit:matrix.org> add them to the gradle build process

<k​ewbit:matrix.org> woodser:

<k​ewbit:matrix.org> but yeah we'll take this to dev chat

<k​ewbit:matrix.org> One must appreciate that might be quite time consuming for woodser if there is more upstream libs being loaded in from other packages, if it's just monerod and monero-wallet-rpc, perhaps can be done quite quickly

<r​eal_glitch:matrix.org> i guess im one of those braindead people then

<r​eal_glitch:matrix.org> too lazy to install BSX or haveno, waiting for flatpack version, dont have time nor expertise to audit the codebase myself and reaudit it after every single update after my 10-12 hours work shifts, on top of that, add linux and foss ecosystems daily drama and monero itself

<r​eal_glitch:matrix.org> thats why i always check if its source available + it has mass adoption

<r​eal_glitch:matrix.org> because with mass adoption specially for normies, a lot of experts will come either for X/twitter or youtube engagements or some other reason so it will be a lot safer compared to apps with small niche userbase

<r​eal_glitch:matrix.org> i mean, cryptocurrency got popular because people were tired of headache's associated with using fiat money such as tax, geo restrictions, high fee, power outage etc etc

<r​eal_glitch:matrix.org> you cant ask them to reverse engineer the fucking app before using it

<r​eal_glitch:matrix.org> personally im not picky about ui but i dont think monero will reach out to more people anything more than it has now until people can buy it from something as simple and easy to use as cake wallet

<k​ewbit:matrix.org> Optimist of the day

Waiting for flatpak? Bsx runs nodes. currently the best youll get is a flatpak for the core, that still relies on external connections

<r​eal_glitch:matrix.org> relatively speaking

<r​eal_glitch:matrix.org> im pretty sure im one of the most open minded and easy going people in this community

<r​eal_glitch:matrix.org> can you find someone to use an unknown app for financial purpose when feds pouring billions to screw over anything related to monero and privacy

<r​eal_glitch:matrix.org> im stupid enough to use it if you can onboard enough stupid people like me😁

there isnt much xmr available today, was a couple hundred the other day

Xmr seems to sell out pretty fast

<r​eal_glitch:matrix.org> at least its limited to some extent btw ill probably use for monero-btc, so its just 2 nodes right? or i need to run every single available one?

The core runs in a python virtual environment, it doesnt touch your root at all

<r​eal_glitch:matrix.org> at least its limited to some extent btw ill probably use for monero-btc, so its just 2 nodes right? or do i need to run every single available one?

Currently you have to run the particl node as well, (which is ~2gb)

My install script defaults to part, xmr, wow

Wow is also ~2gb

Xmr can easilg be used with a remote node (so if you already have a node, you can use it)

Just copy/paste the first instruction here and then follow prompts. When finished youll be shown a recovery seed. To add btc, after install run `bsx-addcoin`

<r​eal_glitch:matrix.org> ill wait for a bit more adoption as i said

<r​eal_glitch:matrix.org> thanks btw

theres some good liquidity for ltc<>xmr

I cant comment on btc, because i dont ae btc

Dont use* btc

There was something like 100xmr and 200 ltc available the other day.

<o​frnxmr:monero.social> Ltc at sub 1%

<r​eal_glitch:matrix.org> btw what happened to wow

<r​eal_glitch:matrix.org> you guys were going to take over the monero itself at some point

<r​eal_glitch:matrix.org> but hype dissapeared after a month or two

<o​frnxmr:monero.social> So very competitive (or better) than swappers

<o​frnxmr:monero.social> Take over monero? never. Just a complement to xmr. Wow had a release recently rebasing to monero 18.3.4

<o​frnxmr:monero.social> Wow will probably release fcmp++ to mainnet before monero, and i'd hope that wow switches tk randomx so it can be merge mined with xmr.

<o​frnxmr:monero.social> Xmr scaling is an issue, but wow should hopefully be able to shoulder some of the burden if scaling solutions take too long

<o​frnxmr:monero.social> But yeah. If i was you, id run bsx now.

<o​frnxmr:monero.social> uninstalling is easy - just delete the coinswaps folder (and the start scripts)

<r​eal_glitch:matrix.org> well this whole thing will turn off a lot of people from monero

<r​eal_glitch:matrix.org> i dont think associating simple, stable, secure currency like monero to random memecoin is a good idea

<o​frnxmr:monero.social> ?

<r​eal_glitch:matrix.org> meme coins are not popular among non-degen crypto bros

<o​frnxmr:monero.social> You asked about a different project, i answered

<o​frnxmr:monero.social> Wow has nothing 2 do with monero

<o​frnxmr:monero.social> If you dont want to hear about it, maybe dont ask(?)

<o​frnxmr:monero.social> Or ask on Wownero 🤷‍♂️

<r​eal_glitch:matrix.org> y im not blaming you for anything, just talking about wow itself, i think its pointless if its not harmful to monero imo

<r​eal_glitch:matrix.org> and monero should solve its scaling issue by itself not by another meme coin

<o​frnxmr:monero.social> Well, its taken xmr like 6 years without solving anything

<o​frnxmr:monero.social> (since bulletproofs)

<o​frnxmr:monero.social> We run stressnet and can grow the chain by 60gb in a month or 2 at 35tps

<r​eal_glitch:matrix.org> because network is not encountering much of a bottleneck on scaling

<r​eal_glitch:matrix.org> i mean, look at btc

<o​frnxmr:monero.social> ^

<o​frnxmr:monero.social> Btc is capped to 600ktx/day, 7tps.

<o​frnxmr:monero.social> Thats not enough for a single major city

<r​eal_glitch:matrix.org> so you want to reset the network every few years? this time wow, few years later new coin, new coin...

<o​frnxmr:monero.social> ? No

<o​frnxmr:monero.social> At a certain tps, the blockchain will fail to sync.

<o​frnxmr:monero.social> Need to spread that out until scaling measures are able to keep up.

<o​frnxmr:monero.social> Fcmp enabkes payment channels (like ln). Were like 10 months away from even thinking about that

<o​frnxmr:monero.social> s/fail to sync/will fall behind when syncing

<r​eal_glitch:matrix.org> correct me if im wrong

<r​eal_glitch:matrix.org> from my understanding of wow

<r​eal_glitch:matrix.org> it uses almost all of the monero''s core features but i really dont understand how its superior and is going to solve the scaling issue

<r​eal_glitch:matrix.org> i thought wow fans say that because wow network is new and lightweight because of lackof transaction history

<r​eal_glitch:matrix.org> there are no innovation or new techniques to improve existing monero features right?

<r​eal_glitch:matrix.org> correct me if im wrong

<r​eal_glitch:matrix.org> from my understanding of wow

<r​eal_glitch:matrix.org> it uses almost all of the monero''s core features but i really dont understand how its superior and is going to solve the scaling issue

<r​eal_glitch:matrix.org> i thought wow fans say that because wow network is new and lightweight because of lack of transaction history

<r​eal_glitch:matrix.org> there are no innovation or new techniques to improve existing monero features right?

<o​frnxmr:monero.social> Its not superior. It can absorb some tps and keep the blockchains separate and smaller

<o​frnxmr:monero.social> Wow isnt new. Its been around for 6yrs

<r​eal_glitch:matrix.org> i mean, 2m marketcap

<o​frnxmr:monero.social> Wow has the same scalability as monero (actually slightly worse, due to larger ring sizes at 22)

<o​frnxmr:monero.social> But features are the same. Wow doesnt have any magic bullets that monero dlesnt

<o​frnxmr:monero.social> Wow DID implement bulletproofs before monero, which ultimately helped monero implement bulletproofs

<o​frnxmr:monero.social> wow also hard forked to limit tx_extra, whereas monero is only a relay rule

<o​frnxmr:monero.social> Anyway, this is community channel

<o​frnxmr:monero.social> Monero Offtopic or Wownero if you want to talk about wownero

<r​eal_glitch:matrix.org> you cant convince business owners or normies to switch to wow for a year or two and come back again

<r​eal_glitch:matrix.org> at most its just a small group of hardcore monero fans that will only result in increasing your chance to get caught on a smaller forest compared to monero itself,

<o​frnxmr:monero.social> The monero topic can be boiled down to: monero has a max viable tps.

<o​frnxmr:monero.social> Higher than that, snd monero becomes unusable.

<o​frnxmr:monero.social> id rather hold xmr and wow, than xmr and btc ormr and ltc

<o​frnxmr:monero.social> i have no love for transparent or optional privacy coins, or for projects that have dev fees, or gimmicky features. Theres no reason for me to go xmr+btc/ltc/doge when i can go xmr+wow

<r​eal_glitch:matrix.org> i dont have enough money to worry about that, xmr did swallow all my funds like it was nothing

<r​eal_glitch:matrix.org> i will contact you again when i became a billionaire

<r​eal_glitch:matrix.org> i dont have enough money to worry about that, xmr did swallow all my funds like it was nothing

<r​eal_glitch:matrix.org> i will contact you again when i become a billionaire

<o​frnxmr:monero.social> The adoption bull case for monero is "we are not ready"

Robust and modular wallet-rpc library is now fully funded! ccs.getmonero.org/proposals/spirobel_robust_modular_wallet_rpc.html @luigi1111

<s​yntheticbird:monero.social> Best Code of Conduct on earth even ofrnxmr can agree on that one: ruby-lang.org/en/conduct

<s​yntheticbird:monero.social> or call it woke.

<s​yntheticbird:monero.social> or can't call it woke.

<3​21bob321:monero.social> - When interpreting the words and actions of others, participants should always assume good intentions

<3​21bob321:monero.social> Lol

<r​brunner7:monero.social> As far as I know game theory has proven mathematically that this is the optimal strategy: At first encounter, assume good intentions / cooperate. After that, with repeated encounters, tit-for-tat.

i agree

the repeated encounters is the tricky part