so what do monero peeps make of Tari?

<o​frnxmr:xmr.mx> its coming since ....

the 'big announcement' will come in April for tari

I was able to mostly answer my own questions. Other distro templates I have seen installed the program manually, and xmrig does not appear to even provide tests as templates disable them.

<e​longated:matrix.org> Another chain with tokens

<p​reland:monero.social> Generally just a rapidly increasing feeling of dread and concern

<p​reland:monero.social> Tbh if Tari ends up falling on its face after launch (which I normally wouldn’t expect for an independent crypto, but like….so much has changed in Tari’s structure that idk if it could stand on its own anymore) I will probably go back and try to make a self documentation of what happened…because nearly every step forward it has made in the last couple of years has come at <clipped message>

<p​reland:monero.social> the cost of leaps backwards

<p​reland:monero.social> I don’t think my opinion is very common, and many of those who agree with me likely won’t say anything out of respect for fluffy, but…. I can’t pretend that what’s going on over there isn’t something that basically goes against every belief I have about how this space should be ran.

<e​liz_tg:matrix.org> Hi

<o​frnxmr:xmr.mx> Elaborate

<e​liz_tg:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/vmKArPsdISYCOOAlLwekrENu

<e​liz_tg:matrix.org> The cover page of our upcoming 2nd issue of college-based magazine KALPA (lit. 'to create, prepare, form, compose, invent)

<e​liz_tg:matrix.org> VXcircle (x.com/vxcircleorg) a privacy tech con. based-around our magazine.

<e​liz_tg:matrix.org> we are looking for international submissions for our magazine!

<e​liz_tg:matrix.org> as well as SPONSORs for our mini-tech conf.

<e​liz_tg:matrix.org> This is entirely student-run, but welcome to all academics, hobbyist, students and professionals.

<e​liz_tg:matrix.org> we are based in India.

<p​reland:monero.social> It’s a solution looking for a problem, for one

<p​reland:monero.social> Tari is *cool*, but that doesn’t mean that people will find use cases for it

<e​liz_tg:matrix.org> we need SPONSERs, can anyone help?

<o​frnxmr:xmr.mx> website?

<i​mprevisto:matrix.org> looks fun

<e​liz_tg:matrix.org> me?

<o​frnxmr:xmr.mx> Yes

<e​liz_tg:matrix.org> vxcircle.org is the domain, we didn't setup website yet. if someone can help, we have prepared pitch deck for sponsers. we will setup a SPA website asap!

<e​liz_tg:matrix.org> this is our second issue!

<o​frnxmr:xmr.mx> How can i sponsor? Wise/cash? Btc?

<e​liz_tg:matrix.org> btc/xmr, i will send you pitch deck in dm. it is pretty cheap :)

<e​liz_tg:matrix.org> full page magazine and and something for conference together!

<e​liz_tg:matrix.org> > <@ofrnxmr:xmr.mx> How can i sponsor? Wise/cash? Btc?

<e​liz_tg:matrix.org> btc/xmr, i will send you pitch deck in dm. it is pretty cheap :)

<e​liz_tg:matrix.org> full page magazine ad and and something for conference together!

<o​frnxmr:xmr.mx> Wheres the 1st issue?

<e​liz_tg:matrix.org> drive.google.com/file/d/1qbyWHhHYMv…w9Uipg8apH0ffLq87_/view?usp=sharing

<e​liz_tg:matrix.org> we had published the first issue, and also shared few weeks ago in monero matrix group!

<e​liz_tg:matrix.org> also we did call for papers

<f​areve:matrix.org> @eliz_tg:matrix.orgdid you get my dm?

<o​frnxmr:xmr.mx> yes but i dont reallt accept files from strangers

<o​frnxmr:xmr.mx> you should, at least, switch to proton drive

<e​liz_tg:matrix.org> ah okay, we will keep that in mind from this time :)

<e​liz_tg:matrix.org> i sent you the pdf *pitch deck in dm.

<o​frnxmr:xmr.mx> And convert that pdf to something that cam be viewed without downloading (like images)

<e​liz_tg:matrix.org> uploading right now!

<e​liz_tg:matrix.org> i sent you 🔗 to proton drive ofrnxmr @ofrnxmr:xmr.mx: if you're still here.

<e​liz_tg:matrix.org> the first issue was a bootstrap, without sponsors so it was smaller

<e​liz_tg:matrix.org> but we are going big this time!

<e​liz_tg:matrix.org> with selected themes! 50 pages!

<e​liz_tg:matrix.org> > <@eliz_tg:matrix.org> drive.google.com/file/d/1qbyWHhHYMv…w9Uipg8apH0ffLq87_/view?usp=sharing

<e​liz_tg:matrix.org> the first issue was a bootstrap, without sponsors so it was smaller

<e​liz_tg:matrix.org> but we are going big this time!

<e​liz_tg:matrix.org> with selected themes! 50 pages!

<e​liz_tg:matrix.org> including forming a privacy -tech conf. around the mag(zine)

<e​longated:matrix.org> 1 follower on X

<o​frnxmr:monero.social> Racist

<e​longated:matrix.org> Retarded

<e​longated:matrix.org> Do you have pdf of your first issue ?

<o​frnxmr:xmr.mx> Either or

<e​longated:matrix.org> Whatever suits you

<s​iren:kernal.eu> Beautifully done. Can you send me the pitch deck too?

<l​za_menace:monero.social> if i use cuprate to sync can i slap onion-monero-explorer (xmrchain.net) on top of it? it'll be same lmdb path structure and whatnot?

<b​oog900:monero.social> nope, the DBs aren't compatible

<l​za_menace:monero.social> dang. thx

<l​za_menace:monero.social> it's cool that cuprate works though

<l​za_menace:monero.social> i remember when the dev announced it. i rolled my eyes thinking "that'll be the day"

<b​oog900:monero.social> I think most people thought the same

<e​liz_tg:matrix.org> drive.google.com/file/d/1qbyWHhHYMv…w9Uipg8apH0ffLq87_/view?usp=sharing

<e​liz_tg:matrix.org> This first issue was bootstrap, so it was smaller.

<e​liz_tg:matrix.org> but this time we are planning big! with selected themes! 50 pages!

<e​liz_tg:matrix.org> and a privacy/cypherpunk conf. around our magazine.

<e​liz_tg:matrix.org> sent!

<s​yntheticbird:monero.social> i thought the same

<s​yntheticbird:monero.social> the guy who announced this was really stupid

<f​areve:matrix.org> is it safe to say xmr likers are fearful of a great reset by 2030 hence they hold and use the coin?

<e​longated:matrix.org> No

<s​yntheticbird:monero.social> I have not really encountered a lot of "apocalyptic" or "doomers" people in the xmr community tbh

<f​areve:matrix.org> From my experience some cypherpunkers seem to think so

<e​liz_tg:matrix.org> what is great reset? like starting new Blockchain with zero balance?

<e​longated:matrix.org> Don’t project your imaginations

<l​za_menace:monero.social> are --add-peer and --add-exclusive-node still required to allow full tor support?

<m​onero.arbo:matrix.org> I just like the coin. I think it's neat

<l​za_menace:monero.social> *tor network peer discovery

<l​za_menace:monero.social> or if i just do --anonymous-inbound with my onion address i'll find other tor peers from tor seed nodes?

<1​7lifers:matrix.org> im here cuz mining monero on shitboxes is cool

<b​asses:matrix.org> the hard fork is there a roadmap for cuprate?

<b​asses:matrix.org> would be great if you posted anything on the blog too

<s​yntheticbird:monero.social> Cuprate/cuprate #376

<s​yntheticbird:monero.social> ikr. I need to find time to power up the blog again

<e​liz_tg:matrix.org> i wrote this article some time back:

<e​liz_tg:matrix.org> peoplesklub.vxcircle.org/post/3/start-your-country.html

<f​areve:matrix.org> @eliz_tg:matrix.orginteresting paper that i will look into

<3​21bob321:monero.social> Yalla

<3​21bob321:monero.social> Also website k thanks mbll bye

<r​ucknium:monero.social> elongated: Do you want it to be put on the MRL agenda this week? Will you be available during the meeting at 17:00 Wednesday?

<o​frnxmr:xmr.mx> Yes please Rucknium

<o​frnxmr:xmr.mx> 1. HF w/ dsa (jeffro coinbase segregation + possible ospead)

<o​frnxmr:xmr.mx> 2. Push V0.19 w/o a HF (master -> release)n

<o​frnxmr:xmr.mx> A) HF w/ dsa (jeffro coinbase segregation + possible ospead) - ideal. Gets ecosystem ready for fcmp hf

<o​frnxmr:xmr.mx> B) Push v0.19 w/o a HF (master -> release). Second option. Removed a lot of technical debt in prep for fcmp hf

<o​frnxmr:xmr.mx> C) B+A w/o HF. Third option. Easiest, not a good idea imo

<e​longated:matrix.org> Rucknium: yes 👍 ofrnxmr looks good also add a point for discussion to increase nominal ringsize

<o​frnxmr:xmr.mx> Fuck that

<o​frnxmr:xmr.mx> Option F, bloat the chain with nonsense

<o​frnxmr:xmr.mx> :)

<o​frnxmr:xmr.mx> I still believe that increasing ring size is far more waste than benefit

<o​frnxmr:xmr.mx> IMO, it makes more sense to disallow anything aside from 2 and 16 out tx's. Which yields, again, better decoys than what we have

<o​frnxmr:xmr.mx> Increasing ring size just doesnt change the % of bad decoys

<e​longated:matrix.org> Fcmp will be a bloat with bigger tx size ?

<o​frnxmr:xmr.mx> Is just bloat w/o addressing the root cause of bad decoys

<o​frnxmr:xmr.mx> iiuc, not for consolidated tx

<e​longated:matrix.org> Dsa is fixing bad decoys ?

<o​frnxmr:xmr.mx> No, its reorganizing them

<3​21bob321:monero.social> Morbs when ?

<o​frnxmr:xmr.mx> If by "dsa" you mean "ospead"

<o​frnxmr:xmr.mx> dsa, decoy selection algo, would improve, yes

<o​frnxmr:xmr.mx> Jeffro's coinbase segregation is also a part of dsa

<e​longated:matrix.org> With higher nominal ringsize it will be harder to reduce effective ringsize by spam attacks

<l​ordx3nu:matrix.org> Please do

<o​frnxmr:xmr.mx> If we wanted to spend a lot of time on dsa: 1. Dont select tx that have sized outside of a reasonable range for the # of inputs/outputs 2. Dont select decoys that have a different number of outputs than your tx 3. dont select decoys that are anything aside from 2 and 16 out 4. Try to select decoys with same number of inputs and outputs

<o​frnxmr:xmr.mx> this is in addition to segregating coinbase tx and ospead

<o​frnxmr:xmr.mx> meaning, if my tx is 1.5kb for 1/2 tx, dont select decoys that are 1.8kb (with shite stuffed in txextra)

<o​frnxmr:xmr.mx> Thats (1)

<e​longated:matrix.org> Can’t we have fixed number of outputs ? Like 2/4/8/16

<r​ucknium:monero.social> It's going on the agenda. As always, anyone is welcome to attend MRL meetings and participate in the discussion.

<o​frnxmr:xmr.mx> 2 is. If my tx in 2/2, try to form a set of decoys that are 2 out, (not accidentally forming a ring on 16 out tx)

<o​frnxmr:xmr.mx> 3 is.. dont even allow tx that are 3-15 out. All decoys should be 2 or 16 out

<o​frnxmr:xmr.mx> 4 is..If tx is 2/2, try to select decoys that are 2/2

<o​frnxmr:xmr.mx> 2 and 16 really all that is needed

<o​frnxmr:xmr.mx> The rest are uncommon and therefore make for terrible decoys and terrible privacy tx

<o​frnxmr:xmr.mx> Ty sar

<e​longated:matrix.org> 16 for sending 3 actual outputs won’t be bloat ?

<r​ucknium:monero.social> ofrnxmr: Those extra rules are hard to implement because the get_output_distribution endpoint that's used to construct txs doesn't send that type of information.

<e​longated:matrix.org> 2/8/16 is also fine

<o​frnxmr:xmr.mx> fwiw, i believe tob and oxfffc ack the concept of at least pushing master to release

<o​frnxmr:xmr.mx> Its not

<o​frnxmr:xmr.mx> Men lie, women lie, numbwra dont. 2 and 16 or bust

<e​longated:matrix.org> I don’t have stars but more than 3 output txs would be a good %

<r​ucknium:monero.social> Plus, the research on the privacy risk of including decoys with unusual numbers of ins/outs doesn't really exist (yet). Just for p2pool outputs, which of course are many-output txs.

<e​longated:matrix.org> Stats *

<o​frnxmr:xmr.mx> Its common sense.

<o​frnxmr:xmr.mx> Ruck, when you go to pay for your vps using monero, what are the chances that you're sending a multi-out tx?

<o​frnxmr:xmr.mx> Or when you buy a hat on DNM, or shop at the corner store

<r​ucknium:monero.social> Maybe I got a multi-output tx from another source. Then my spend to a VPS is an actual spend of a multi-output tx.

<o​frnxmr:xmr.mx> they are _all_ 2 out tx

<o​frnxmr:xmr.mx> Those can be padded to 16 and your spend is a 2

<o​frnxmr:xmr.mx> The chance of you spending a 3 to buy your vps is slim->none

<o​frnxmr:xmr.mx> If you come to my shop, and your decoys are 3-15 out tx, i know the real spend.

<o​frnxmr:xmr.mx> Even creating pocketchange and churning is best done via a series of 2 out tx

<o​frnxmr:xmr.mx> Just imagine a situation where monero is doing 300k tx/day, and its mostly spam (like btc). How to destroy the decoy set for casual observers? Spam easily identifiable outputs, like 14 out

<o​frnxmr:xmr.mx> I also believe that there should be a distribution such as 11x2 out, and 5x16 out in each ring. Not left up to luck

<r​ucknium:monero.social> With intentional spam, that would be bad, yes. Yet, the spam last year was 1in/2out. They could have done it differently, of course.

<e​longated:matrix.org> Yes that can be changed in dsa to reduce % of such decoys

<e​longated:matrix.org> 2/16 is also fine if % of tx above 3 outputs is a small %

<o​frnxmr:xmr.mx> By eliminating those tx types. 2 and 16. (you can pad to 16 w/o being much of a size issue imo)

<e​longated:matrix.org> Or we can go with 2/8/16

<o​frnxmr:xmr.mx> So if you wanted to send a 3-15, it would appear as a 16

<o​frnxmr:xmr.mx> 11x2s and 5x16s. Where are the 8s going?

<o​frnxmr:xmr.mx> no room for those junk outputs

<o​frnxmr:xmr.mx> Just pad the 8s to 16

<e​longated:matrix.org> I don’t mind small increase

<o​frnxmr:xmr.mx> Its a decrease in nominal ring size to include 8s

<o​frnxmr:xmr.mx> Even 16s decrease ring size for retail users, but industry needs privacy too

<o​frnxmr:xmr.mx> increasing ring size is increasing cost for everybody w/o much benefit, especially if youre increasing to make room to save money so people can send 8s for cheap

<e​longated:matrix.org> What is the fcmp tx size ?

<o​frnxmr:xmr.mx> If you forced all tx to be 2, then there would be 8x more tx from industrial uses, which poisons rings

<o​frnxmr:xmr.mx> jeffro256 !

<e​longated:matrix.org> So 2/16 should be fine

<o​frnxmr:xmr.mx> I think 5.5kb for 2 input tx

<e​longated:matrix.org> We can try increase nominal ringsize to get close to 5.5kb for 16 output txs and make network ready for fcmp

<e​longated:matrix.org> 2/16

<o​frnxmr:xmr.mx> increasing ring size to 5.5kb w/o fcmp is an easy way to say FU to node operators

<o​frnxmr:xmr.mx> And to increase fees substantially

<o​frnxmr:xmr.mx> FCMP should come with a fee/byte decrease in order to maintain current fee levels for standard tx

<o​frnxmr:xmr.mx> imo, this hf should be done quick and easy. The "wants" would be nice to have, but i dont think we should waste too much time improving decoys unless we are also planning to cancel fcmp.

<o​frnxmr:xmr.mx> The low hanging fruit is all i ask for

<s​gp_:monero.social> Personally I hate that fees are so low

<o​frnxmr:xmr.mx> jeffro's coinbase segregation pr, and push from master to release.

<s​gp_:monero.social> But that's just my opinion

<o​frnxmr:xmr.mx> They are low in terms of $, not in terms of xmr

<s​gp_:monero.social> Yeah but $ is what matters. No way around that

<o​frnxmr:xmr.mx> In terms of xmr, they are equivalent to 3000sats

<s​gp_:monero.social> We can't predict the XMR/use price

<s​gp_:monero.social> *usd

<o​frnxmr:xmr.mx> Cant HF for $ fees

<s​gp_:monero.social> Low block size by default, allow block size growth for only aggressive fee increases on fee ladders, allow the free market to take care of it

<s​gp_:monero.social> But I know that's unpopular

<o​frnxmr:xmr.mx> the normal fee tier is 0.0001, remembwr

<o​frnxmr:xmr.mx> Low fee doesnt really allow for block size growth

<o​frnxmr:xmr.mx> 0.00003)

<s​gp_:monero.social> I think it's too permissive on the size for the low fee

<s​gp_:monero.social> I don't care if the fee is 0, make the max window for that initial tier small

<o​frnxmr:xmr.mx> Blocks dont grow very fast at all @ low fee (look at the spam from last yr)

<s​gp_:monero.social> Good they shouldn't. But I think such spam should have caused a much larger fee increase

<o​frnxmr:xmr.mx> We barely hit like 330kb with maxed outbdaily tx (not growing bcuz they were low fee)

<o​frnxmr:xmr.mx> My plan for fees is: if >360 block backlog + average fee in txpool is > 3x low fee = increase to tier 3

<o​frnxmr:xmr.mx> if the avg fee in txpool is low, then we shouldnt be paying to increase block size so spammer can get low fee txmined

<s​gp_:monero.social> Why the backlog check?

<o​frnxmr:xmr.mx> ^

<o​frnxmr:xmr.mx> If the backlog is less than 12hrs, then were all using tier 2 (normal) fee already, and blocks will grow at a relatively quick pace and we shouldnt risk dropped tx

<o​frnxmr:xmr.mx> If the backlog is big, but its spam, no need to make room for them.

<o​frnxmr:xmr.mx> if the backlog is big but its organic, then we should (pay to) increase blocksize faster

<o​frnxmr:xmr.mx> So lets say we have some major adoption and real tx flood in, using auto (normal) fee and end up with a 360 block backlog. Normal fee is not enough, and people will have to wait 12hrs for their tx to confirm. So we would then increase fees to lvl 3, which would increase the blocksize and clear out the backlog

<o​frnxmr:xmr.mx> If the 360 blocks was spam, then we dont need to increase blocksize any faster than normal fee, ethic would also ensure that normal users tx are all mined on short time, and hopefully the spam tx would be dropped after 72hrs

<o​frnxmr:xmr.mx> My struggle with this is that i need someone to help me write the code to check size of tx pool / total fees to check the avg fee/byte