improve readability

[plowsof]

https://github.com/monero-project/meta/issues/906#issuecomment-1773687602

[plowsof]

Logs

< plowsof > Meeting time https://github.com/monero-project/meta/issues/906

< m​onerobull:matrix.org > Hello

< v​ostoemisio:matrix.org > 👋

< c​trej:matrix.org > hello

< plowsof > hello all

< o​frnxmr:monero.social > Hello

__< s​needlewoods_xmr:matrix.org >__ hi

< plowsof > lets discuss some community highlights while people roll in

< p​lowsof:matrix.org > v0.18.3.1 released. boog900 found/patched a bug as a direct result of their CCS ! in this Pull request

< m​onerobull:matrix.org > Cool

< p​lowsof:matrix.org > when will the DNS servers be updated selsta? usually after about a week right? im not seeing any problems reported so far

< p​lowsof:matrix.org > monerobull tested the latest haveno release and noticed a BSOD , leading to an update 🫡

< m​onerobull:matrix.org > Nah

< m​onerobull:matrix.org > Not really

< m​onerobull:matrix.org > I believe the haveno bug was because US and EU use commas and dots differently

< m​onerobull:matrix.org > The BSOD was apparently from the last windows update and has been fixed .... By me upgrading to win11 💀

< p​lowsof:matrix.org > thank you for testing

< p​lowsof:matrix.org > we also had some community members purchase hardware to help with this RandomX PR: Jit compiler for RISC-V - tevador. This will increase RandomX performance on RISC-V cpu's. some volunteers including pauliouk and gingeropolous have purchased risc-v hardware to help testing.

< r​ecanman:agoradesk.com > Hello, apologies for being late

< m​onerobull:matrix.org > Didn't we recently plan to make riscv less efficient lol

< m​onerobull:matrix.org > (by proxy)

< r​ecanman:agoradesk.com > I think it was to require more memory

< m​onerobull:matrix.org > And special Ryzen instructions

< p​lowsof:matrix.org > this would be a PR for the "future" - a world where RISC-V cpu's are widespread

< m​onerobull:matrix.org > Is this kit thing licensed in such a way that bitmain can't use it in closed software?

< m​onerobull:matrix.org > Is this jit thing licensed in such a way that bitmain can't use it in closed software?

< p​lowsof:matrix.org > im not sure about that, i can follow up any Q's about this in #monero-pow or with sech1 if they know

< o​frnxmr:monero.social > Monero PoW

< sech1 > It's BSD 3-clause, so they can use it

< sech1 > But they already used XMRig with is GPLv3, and they didn't disclose the source code

< m​onerobull:matrix.org > :/

< sech1 > So they don't give a damn about licenses

< p​lowsof:matrix.org > lol

< sech1 > X5 miners uses modified XMRig inside

< sech1 > It's GPLv3

< sech1 > Where's the published source code?

< m​onerobull:matrix.org > Their miners are blowing up anyways and they don't pay their employers so I doubt they made much money with xmr 🤷‍♂️

< p​lowsof:matrix.org > planned obsolescence is a feature

< o​frnxmr:monero.social > Lets sue

< o​frnxmr:monero.social > monerokin lawyers

< m​onerobull:matrix.org > Only if you have the next product lined up

< p​lowsof:matrix.org > we owe them 1k for sending empty emails already but thats another issue for #monero-events:monero.social

< m​onerobull:matrix.org > Which I very much doubt

< p​lowsof:matrix.org > the next product is probably mining already

< m​onerobull:matrix.org > Nah no way they developed another one

< m​onerobull:matrix.org > This one was a big failure

< p​lowsof:matrix.org > AI needs cpu's so the future is even brighter for RandomX

< m​onerobull:matrix.org > Ai uses GPU or asics

< p​lowsof:matrix.org > or machine learning.. they like RISC-V

< c​trej:matrix.org > bitmain likely got the cpus far below retail price to make it worthwhile for them. People speculated on engineering samples or similar non-retail silicon

< r​ecanman:agoradesk.com > There was like $10k of memory in there alone, right?

< c​trej:matrix.org > retail price for the specific modules they've used. I'd guess they used whatever modules they were able to source for cheap

< p​lowsof:matrix.org > almost forgetting a special thanks to Rucknium for chasing those none-standard fees Privacy Advisory - exodus wallet users update

< p​lowsof:matrix.org > we have a full-house for the active newsletters this week Monero Observer - Revuo Monero - The Monero Standard - Monero Moon

< p​lowsof:matrix.org > are we missing anything obvious? we can move on to proposals then

< r​ecanman:agoradesk.com > This website includes them and some other things, it's pretty nice: https://themonero.dance/

< r​ecanman:agoradesk.com > I'm not sure who maintains it but its pretty nice, there are a couple of broken things though

< p​lowsof:matrix.org > yes alot of missing things, looks nice though

< p​lowsof:matrix.org > i pointed the general fund donation tweeter to the p2pool blockchain explorer (exploremonero still dead)

< p​lowsof:matrix.org > lets move on to the proposals

< m​onerobull:matrix.org > I'd like to thank lza_menace: for the amazing new map for docker monero node. It's so cool

< o​frnxmr:monero.social > Yes, ty lza_menace:

< c​trej:matrix.org > eww, monero.dance has google-analytics.com and gstatic.com javascript. Whoever runs it: is that really necassary?

< p​lowsof:matrix.org > ah yes! 🗺️

< o​frnxmr:monero.social > dⱮartian:

< r​ecanman:agoradesk.com > I didn't notice that, I have it all blocked

< o​frnxmr:monero.social > dⱮartian:

< r​ecanman:agoradesk.com > Maybe someone should contact the above

< o​frnxmr:monero.social > Runs it

< p​lowsof:matrix.org > monerosuite.org is from hundehausen (based on the work of lza_menace too)

< r​ecanman:agoradesk.com > This looks pretty cool, if I can get it working I'll feature it in my next issue of the Monero Standard

< m​onerobull:matrix.org > Is that like an all in one monero deployer?

< p​lowsof:matrix.org > feather wallet tagged a new release. they also need help to verify hashes and such (20~GB of free disk space and time required) https://github.com/feather-wallet/feather/tree/master/contrib/guix#building

< r​ecanman:agoradesk.com > Yes, so many configuration options

< p​lowsof:matrix.org > yes monerosuite is an all in one, similar to xmr.sh

< m​onerobull:matrix.org > Cool

< r​ecanman:agoradesk.com > Includes block explorer, reverse proxy, tor proxy, monitoring, etc.

< o​frnxmr:monero.social > Tor stuff look weird

< p​lowsof:matrix.org > lets move onto the proposals unless

< p​lowsof:matrix.org > CCS proposals

< p​lowsof:matrix.org > we can skip a. Add retroactive funding proposal for FCMPs waiting for merge.

< p​lowsof:matrix.org > and just make everyone waiting for a ccs payout / merges aware that luigi1111 knows about it and will be handling everything soon(tm) - apologies for the delays

< o​frnxmr:monero.social > yup

< p​lowsof:matrix.org > b. dangerousfreedom - wallet work

< m​onerobull:matrix.org > Voting merge

< p​lowsof:matrix.org > DF is waiting for code reviews from his previous CCS

< r​ecanman:agoradesk.com > Seraphis wallet migration is extremely necessary and DF has major contributions

< r​ecanman:agoradesk.com > +merge

< m​onerobull:matrix.org > This is a problem in general right

< p​lowsof:matrix.org > indeed, rbrunner7 has provided some positive feedback

< m​onerobull:matrix.org > Can we hire someone like cypher stack if we can't find reviewers otherwise

< o​frnxmr:monero.social > This

< o​frnxmr:monero.social > Daemon needed too lol

< o​frnxmr:monero.social > Seraphis needs proofs and audits

< o​frnxmr:monero.social > And DF needs reviews

< o​frnxmr:monero.social > Yes

< o​frnxmr:monero.social > -dev and/or mrl and/or nwlb need to sign off

< r​ecanman:agoradesk.com > You'

< p​lowsof:matrix.org > we have devs on the payroll who can use hours to review DFs work

< r​ecanman:agoradesk.com > You're right

< m​onerobull:matrix.org > Are those devs just sitting around doing nothing?

< m​onerobull:matrix.org > I'm pretty sure most work on very specific things

< m​onerobull:matrix.org > Delaying what they work on to review each other's work while we have funds sitting idle is not very efficient

< p​lowsof:matrix.org > koe has had a quick look and said it all seems ok but not actually reviewed it in depth

< m​onerobull:matrix.org > Unless there's direct benefits from wallet reviewers being familiar with it in the future

< m​onerobull:matrix.org > But it would need to be related, no point in a wallet expert reviewing p2p protocol when they don't plan to ever work with it

< p​lowsof:matrix.org > i defer all serpahis proposals to the NWLB/seraphis workgroup

< p​lowsof:matrix.org > thats my vote

< p​lowsof:matrix.org > hiring outside help from e.g. cypherstack is a good idea

__< s​needlewoods_xmr:matrix.org >__ maybe we need monero-apprenticeship

< p​lowsof:matrix.org > we need experts

< selsta > plowsof: depends on core team availability

< selsta > but yes DNS will be updated after a week or so

< c​trej:matrix.org > specifics about dev work can be discussed in other groups, as long as we take care that devs willing to work can work - and that they are not waiting on the ccs bureaucracy

< p​lowsof:matrix.org > thanks! (DNS tells clients there is an update available)

< c​trej:matrix.org > otherwise agreeing with this

< p​lowsof:matrix.org > i mean on a personal level - DF has attended a monerokon and done other great work for the project - reducing delays is the priority here so he can get funding to continue

< m​onerobull:matrix.org > Can he already move forward even without the review?

< p​lowsof:matrix.org > there where some issues when the previous ccs was posted - which required discussion and changes, can view it in the comments. (perhaps showing a lack of direction because this is all new)

< p​lowsof:matrix.org > give him the tasks that we need and he'll do it

< p​lowsof:matrix.org > lets touch on the other proposals

< p​lowsof:matrix.org > c. XMR BTC Atomic Swaps Desktop GUI - Continued development for 6 months

< o​frnxmr:monero.social > close

< p​lowsof:matrix.org > binarybaron: hasnt had a chance to respond to my comment yet

< p​lowsof:matrix.org > this comment: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/411#note_22562

< m​onerobull:matrix.org > The GUI looks good but it's built on a discontinued protocol

< m​onerobull:matrix.org > BasicSwapDex allows bidirectional monero swaps with BTC and LTC now

< o​frnxmr:monero.social > UnstoppableSwap

< m​onerobull:matrix.org > I'd much rather have someone look into taking BasicSwapDex and ripping out their smsg network and replace it with regular Tor connections

< m​onerobull:matrix.org > Or at least evaluate how feasible that would be

< o​frnxmr:monero.social > Or pokkst etc implement said features in other wallets

< m​onerobull:matrix.org > Yeaj

< m​onerobull:matrix.org > Saw a tweet today

< m​onerobull:matrix.org > Pokkst implementation looks promising

< m​onerobull:matrix.org > Is there any more info than his tweets?

< p​lowsof:matrix.org > pokkst made a PR to the COMIT repo....

< p​lowsof:matrix.org > is he also using the dead protocol?

< p​lowsof:matrix.org > perhaps then its not dead?

< p​lowsof:matrix.org > suspicious https://github.com/comit-network/xmr-btc-swap/pull/1447

< m​onerobull:matrix.org > Hm

< m​onerobull:matrix.org > https://matrix.monero.social/_matrix/media/v1/download/matrix.org/jRrtPURCTbucKTNNvMPLvtSY

< m​onerobull:matrix.org > I want to know how the liquidity providing works

< p​lowsof:matrix.org > looks like the same setup as unstoppable swap

< p​lowsof:matrix.org > i think we can defer discussion after raising some questions here and wait for binarybarons initial response

< p​lowsof:matrix.org > moving on

< p​lowsof:matrix.org > d. Core Monero Concepts

< p​lowsof:matrix.org > the previous video they made was actually proudly shared on some social media sites

< m​onerobull:matrix.org > Unlike the last animation proposal lol

< o​frnxmr:monero.social > My comments earlier are an extension of plowsof. Lower # of videos to 2 + (my suggestion) and do video on importance of nodes etc and another on fungibility/adoption4merchants

< p​lowsof:matrix.org > we have 35 XMR from this proposal https://ccs.getmonero.org/proposals/savandra-videos-for-monero.html . if this Core Monero Concepts is reduced to 2 videos - then it could be almost entirely funded by those funds, and reduce the logisticcs issues with trying to push 4 videos out in a short time span

< o​frnxmr:monero.social > Im ok with more videos following fwiw

< v​ostoemisio:matrix.org > When would this be decided and allocated? I discussed a bit with xenu and we are open to shorten it to 2 videos to start if it makes sense. But if we could choose freely we would like to keep it to 4 videos as the initial proposal, less administration

< v​ostoemisio:matrix.org > About the script and topics I refer to x3nu to comment 👍️

< m​onerobull:matrix.org > Let vosto work without needing to deal with us again every few weeks thankd

< p​lowsof:matrix.org > the hive mind will make it so. if reducing to 2 videos , then its possible that the price is halfed and it goes to funding for 0.x XMR?

< c​trej:matrix.org > which comment?

< v​ostoemisio:matrix.org > this comment

< p​lowsof:matrix.org > and absorbs the savandra funds (thus closing that proposal for good)

< v​ostoemisio:matrix.org > this comment ceetee

< p​lowsof:matrix.org > similar path to AcceptXMR

< v​ostoemisio:matrix.org > this feedback, ceetee

< p​lowsof:matrix.org > currently this proposal is 72XMR - halving it to 2 videos makes 36 XMR meaning if people want it to be 2, we could fund it with the 35 XMR , and put it to funding with 1 XMR

< p​lowsof:matrix.org > bish bang bosh

< l​ordx3nu:matrix.org > the general idea is to have a full suite of videos discussing intermediate topics about Monero. So for example the four topics in the proposal show this. We also have future plans for videos as well to help with adoption and understanding: e.g. atomic swaps, seraphis. By doing a buik order now we can focus on four topics that have a lot of merit and content and I believe it would

< l​ordx3nu:matrix.org > benefit the community to have videos like this they can just link to a noobie that will introduce them to these ideas.

< l​ordx3nu:matrix.org > and you guys have already seen the quality from the tail emission/dynamic blockswize vid :_)

< l​ordx3nu:matrix.org > and you guys have already seen the quality from the tail emission/dynamic blockswize vid :)

__< s​needlewoods_xmr:matrix.org >__ yeah it was visually appealing

< l​ordx3nu:matrix.org > if two videos is more convenient that works as well. we can again show we are capable of producing quality to make future funding more valuable

< v​ostoemisio:matrix.org > If it's not a big deal for the community I'd prefer the current proposal but like x3nu says we are open to changing it

< o​frnxmr:monero.social > Seraphis and stomic swaps?

< p​lowsof:matrix.org > so we have several options here , move to funding as, move to funding as is -= to the 35 XMR, half it and -= 35 so it requires 1 xmr to complete funding

< p​lowsof:matrix.org > if halfing people need to decide on what 2 vids they want

< c​trej:matrix.org > from the proposal:

< c​trej:matrix.org > >• Random X: Understanding the significance of ASIC resistance

< c​trej:matrix.org > >• Breaking down the how-to and the rationale for P2Pool.

< c​trej:matrix.org > >• Nodes: Why every Monero enthusiast should consider running one.

< c​trej:matrix.org > >• Fungibility: Explaining its essence in the context of Monero.

< p​lowsof:matrix.org > overall i am +1 for vost and xenu to produce more videos for us

< r​ecanman:agoradesk.com > As am IU

< r​ecanman:agoradesk.com > As am I

< o​frnxmr:monero.social > i am as well

< p​lowsof:matrix.org > some discussion to finalise what is going to happen is needed

< l​ordx3nu:matrix.org > that's not in this proposal, but we have future plans for that, yes. we need to wait until more work is done on them though before spending time on it

< r​ecanman:agoradesk.com > RandomX and fungibility I think are good if halfing

< o​frnxmr:monero.social > But making videos that only last a few months is retarded

< m​onerobull:matrix.org > do we nee d a p2pool how-to? breaking it down sure but i believe there are already good tutorials

< p​lowsof:matrix.org > i apologise for spelling halfing wrong and misleading you all. halving *

< o​frnxmr:monero.social > Landscape forever changing on atomic awaps, seraphis, p2pool, even fungibility

< v​ostoemisio:matrix.org > Keep proposal as is, redistribute funding to ours, 35/72 xmr in the funding, that's optimal IMO

< r​ecanman:agoradesk.com > RandomX and fungibility I think are good if halving

< v​ostoemisio:matrix.org > 34 or 35, whatever was left in savandra's

< l​ordx3nu:matrix.org > well for fungibility that isn't really about technology but moreso the characteristic of fungibility because monero isn't perfectly fungible

< l​ordx3nu:matrix.org > so we will have example of what we mean by that and benefits of fungibility

< r​ecanman:agoradesk.com > I have to leave the meeting. Goodbye everyone and thank you plowsof for moderation

< v​ostoemisio:matrix.org > x3nu: Is probably up to work on the scripts while we wait for the second half funding, x3nu ? No time would be wasted

< l​ordx3nu:matrix.org > atomic swaps and seraphis are indeed constantly changing. althought seraphis I think would be ideal once it is finalized because this is the largest hardfork in Monero's history

< o​frnxmr:monero.social > Right. So why makeba video on fungibikity when xmr is not yet fungible?

< o​frnxmr:monero.social > Ita like making news reports on "whats to come"

< p​lowsof:matrix.org > recanman vote on the last one before you leave?

< p​lowsof:matrix.org > e. escapethe3RA Monero Observer maintenance (2023 Q4)

< o​frnxmr:monero.social > merge

< l​ordx3nu:matrix.org > it would be like making a video on privacy but monero isn't perfectly private. it isn't an on or an off switch but an ideal that development for Monero aims for

< r​ecanman:agoradesk.com > +merge, Monero observer I look at all the time

< p​lowsof:matrix.org > monero.observer left our minds, but never our hearts and has been back the past week pushing out content as usual

< o​frnxmr:monero.social > Didnt check price, bur merge if same as last

< p​lowsof:matrix.org > thanks for attending recanman

< p​lowsof:matrix.org > price is the same rates as the prev

< r​ecanman:agoradesk.com > I checked almost every day on whether monero.observer was back. It's great. Goodbye

< m​onerobull:matrix.org > i suggest you to set up an rss reader instead

< o​frnxmr:monero.social > G2g too

< o​frnxmr:monero.social > back in a few

< m​onerobull:matrix.org > https://matrix.monero.social/_matrix/media/v1/download/matrix.org/XvlSJVtviXKzgOWYRKVgYwjz

< m​onerobull:matrix.org > its so good

< l​ordx3nu:matrix.org > we think it would be a good idea to introduce the topic as part of running a node because the question of "what can I do to help Monero" comes up a lot. it wouldn't be a literal guide but a guide emphasizing the difference between centarlized pools and p2pool and why long term p2pool is what we should aim for

< m​onerobull:matrix.org > yeah that is good

< plowsof > thanks all for attending, we can call an end to the meeting here. we have to come to a decision on how to move forward with the core monero concepts proposal asap

Automated by this

[plowsof]

Logs

< Rucknium > Meeting in this room in 1.5 hours.

< Rucknium > Meeting time! https://github.com/monero-project/meta/issues/908

< Rucknium > 1. Greetings

< rbrunner > Hello

< v​tnerd:monero.social > Hi

< Rucknium > 2. Updates. What is everyone working on?

< v​tnerd:monero.social > Me: back on subaddressses. No ETA, but been contacted by multiple people about it now, so it's hopefully done soon^tm

< Rucknium > me: Writing down some early thoughts about analyzing PocketChange privacy. I also read the Ciphertrace employee's statement for the defense in the Bitcoin Fog case.

< rbrunner > Anything really surprising there, in that statement?

< Rucknium > Yes. It is interesting to see Chainalysis and Ciphertrace fight. I can discuss in the discussion section.

< Rucknium > 3. Discussion. What do we want to discuss?

< rbrunner > If nothing else pressing, please do report about that fight :)

< Rucknium > Here is the filing from the Ciphertrace employee: https://storage.courtlistener.com/recap/gov.uscourts.dcd.232431/gov.uscourts.dcd.232431.159.1.pdf

< Rucknium > This was filed after a short filing from Chaianlysis that responded to some questions by the court. The Chainalysis statement said that their methodology was not peer reviewed and it did not have a defined false positive rate (error rate).

< Rucknium > My opinion is that the problems with Chaianlysis's methodology do not mean that blockchain surveillance is completely ineffective (i.e. that bitcoin privacy is "good enough"), but that Chainalysis's methodology is unscientific and unfit for producing the evidence up to the standard of proof in a legal system with strong protections for the accused.

< Rucknium > If blockchain surveillance is more scientific, then yes bitcoin still has major privacy problems.

< Rucknium > The Ciphertrace filing criticized the lack of false positive rates and Chainalysis's use of expanded change output classification rules. They call it "heuristic 2 (behavioral)", which I guess has some meaning in the original case documents that I have not read.

< Rucknium > "Therefore, the discrepancy rate between Ciphertrace and Chainalysis Bitcoin Fog attribution is roughly 67%."

< rbrunner > Those pages and pages of documented errors are pretty depressing, and damning.

< Rucknium > The filing also has discrepancy rates for other entities like AlphaBay

< rbrunner > Found it.

< rbrunner > This is a quite rare look into the workings of these companies, right? Probably so far only their customers get such details.

< Rucknium > The filing from the Ciphertrace employee says that maybe the defendant (Roman Sterlingov) was accused since he had the only KYC'ed account among all the suspected Bitcoin Fog operator withdrawals.

< rbrunner > Did you find any heuristic in there that surprised you personally? That you never heard about, or thought that it would not work well enough?

< Rucknium > Consider if the defendant was targeted by a different entity in a different place. Would a dictatorship allow him to review the evidence against him? What about a criminal gang coming to rob him? False accusations are as big of a threat, if not more, to users of transparent coins.

< Rucknium > rbrunner: Mostly the filing refers to papers that have been posted publicly. One "new" statement is that Ciphertrace said that they do try to link bitcoin addresses/txs to IP addresses: "Ciphertrace collects IP addresses via our own node operation and links them to bitcoin addresses."

< Rucknium > That's not surprising, but I had not seen a public statement from them that this is part of their surveillance

< rbrunner > Ok

< rbrunner > After reading this diagonally, Ciphertrace looks anyway much more "dangerous" than their competitor there ...

< Rucknium > "Blockchain forensics should only be used to generate investigatory leads. Standing alone, they are insufficient as a primary source of evidence. What is striking about this case is the conclusions reached without any corroborating evidence for the blockchain forensics."

< Rucknium > My note on Monero real spend classification using tx fungibility defects has a formula for the false positive rate, so I am ahead of Chainalysis in that regard: https://github.com/Rucknium/misc-research/tree/main/Monero-Fungibility-Defect-Classifier/pdf

< rbrunner > :)

< Rucknium > Ciphertrace was purchased by MasterCard, so their business outlook may be different from Chainalysis now.

< rbrunner > Maybe they looked at both before buying and reached a good conclusion

< Rucknium > Standards of evidence are going to be different for a court of law and advertising targeting, to take the two extremes.

< rbrunner > The court case will go on, based on these filings, I assume?

< Rucknium > MasterCard is probably doing regulatory compliance based on risks scores. Maybe some ad targeting too

< Rucknium > I guess so. I think the prosecution is pushing for a plea deal like usual, so maybe they are in plea deal negotiations or if the defense thinks their side is strong enough they could take it to an actual trial.

< rbrunner > Somehow amazing how all those cryptocurrency funds and ETFs that spring up now risk loss of some of their funds because they turn out to be "dirty"

< rbrunner > No wonder MasterCard tries to find something solid

< Rucknium > Ironically Ciphretrace has permitted no peer review of their Monero "tracing" methodology. I would have guessed with the Mastercard purchase that they would stop working on it, but IIRC they released a statement at the August 2022 hard fork saying you can run but you can't hide, Monero users.

< Rucknium > Anyway, I have been thinking about the privacy impact of users of Monerujo's PocketChange (and any similar system) to split wallet contents into multiple outputs to get around the 10 block lock.

< Rucknium > There are two components: privacy before the PC tx and privacy after.

< Rucknium > The biggest privacy impact in the post-PC txs would be if transactions consolidate outputs from the PC tx in a single tx later.

< Rucknium > You would see two or more rings in the later tx that reference multiple outputs from the original PC tx

< Rucknium > So we would want to know how often that ring pattern would occur as a coincidence when a tx actually has nothing to do with a PC tx

< rbrunner > I guess such a consolidation can happen quite easily

< Rucknium > I think that the false positive rate is going to be a function of the number of txs on the blockchain with more than two outputs, their age, and the decoy selection algorithm.

< Rucknium > All roads lead back to the decoy selection algorithm and questions about what wallet2 actually does.

< Rucknium > The DSA wasn't very important for the analysis of guessibility of real spends with tx fungibility defects because....well, just because

< rbrunner > This consolidation problem does not get smaller if more and more wallets start to implement such a feature, right?

< Rucknium > But how densely the DSA selects from certain regions of the output set matters a lot for PC analysis because the probability of selecting multiple outputs from the same exact transaction in a large sea of transactions is going to depend a lot of how big that sea is.

< Rucknium > rbrunner: I think if there are more txs with greater than two outputs on chain, then a classification rule that uses multiple outputs from the same tx would have a higher false positive rate. How much more? The math has to be written.

< Rucknium > I don't think I will develop the PocketChange analysis much further at this time unless I get a sudden lightning bolt of insight. I would probably put it in a list of possible projects to work on in a CCS later.

< Rucknium > Priorities would be set partially based on community input.

< Rucknium > I am giving advice to a research group that is planning to recreate the BTC transaction graph with Monero rules. gingeropolous thought it would be a good idea to do that.

< Rucknium > A lot of things need to be modified. I am wondering if I am missing anything:

< rbrunner > I don't understand. BTC transaction graph with Monero rules - what rules?

< Rucknium > You need to eliminate the 10 block lock and even allow child txs within the same block. I guess you could do the idea of referencing by TXID instead out sequential output index

< Rucknium > Have a private testnet where you broadcast and confirm the same txs in the BTC blockchain, but with monerod.

< Rucknium > tx verification for mining blocks is going to take a very long time. I wonder if there is a way to just turn it off.

< rbrunner > Sound a bit crazy, at first read.

< Rucknium > They will need a lot of SSD space. I guess 3 TB at least

< Rucknium > Why is it crazy?

< rbrunner > Maybe I don't understand yet how that could possibly be useful.

< Rucknium > You need coin emission to match BTC's emission.

< rbrunner > Should this demonstrate that we could handle the same amount of transactions?

< Rucknium > There are databases with entity labels on BTC transactions and addresses. Like centralized exchanges. The BTC tx graph can give you the behavioral parameters to simulate what EAE attacks could look like.

< Rucknium > The main purpose of doing this would be to analyze the privacy of Monero when you have a ground truth of what an actual tx graph would be.

< Rucknium > You would need to eliminate the limit on the number of tx outputs.

< rbrunner > You mean you could let loose some heuristics on that new Monero-fied blockchain and then could see exactly how good they were?

< Rucknium > Yes

< rbrunner > Clever. But probably is anything but trivial.

< rbrunner > But already the dropped 10 block limit would disturb things, I guess

< Rucknium > Why not just create a simulation in Python or R? There would be pros and cons to doing a simulation. A real blockchain is what the research group wants to do.

< rbrunner > So let them research, I would say :)

< Rucknium > Methods based on timing analysis wouldn't apply in the exact same way, right.

< Rucknium > Right, but I want to warn them if there's things that need to be modified so they are not surprised later.

< rbrunner > Good idea. I think mining is no problem, you can easily accept arbitrarily low difficulties.

< rbrunner > There is a switch in monerod already I think for that, to create a large blockchain easily

< Rucknium > Yes. I pointed them to https://github.com/moneroexamples/private-testnet

< rbrunner > Yup, " --fixed-difficulty 100 " as a daemon start flag

< rbrunner > Maybe the growth limits of the blocks need to get relaxed

< rbrunner > Or even dropped, if you want the same transactions in the same blocks?

< Rucknium > We can end the meeting. Let me know if you think of anything major that they would have to modify.

Automated by this

[rottenwheel]

@plowsof Grabbed 10/14/2023 community meeting log from libera.monerologs.net. See paste.

• Create a new text file, copy and paste what you see here, name it 'formatlog.sh'
• Make the script executable by running chmod u+x formatlog.sh
• Run .sh script locally ./formatlog.sh 1014_communitymeeting.txt > clean.1014_communitymeeting.txt where former was raw log from site as seen in paste above and latter had the log after passing through the script.

• See final output here.

  Integrate it with your workflow if possible.

[plowsof]

thank you for the sed IRC parser/format script . we now have multiple implementations of the log parsing algorithm (Python and Bash), not only has the ecosystem been advanced, it is now more robust!

[plowsof]

I will push the changes (from your suggestions soon) - infact the entire thing is now much simpler.. no need to bother with word wrapping now either :+1: