I'm reading about menro and this seems pretty concerning? monero.fail/opsec

bridges/swap services are the only realistic monero on-ramp. but once it gets deposited in your wallet with tainted metadata, what can you do? the page recommends using a third-party wallet... does the native monero wallet not offer this kind of mitigation?

<lza_menace> The recommendations include ways to mitigate the tainted coins. It’s only recommended because it’s more user friendly but it can certainly done in the native wallet.

<lza_menace> It’s not a big deal if you recycle addresses, and if you are receiving tiny amounts and suspected tainted coins, then churn them away a few times

<sauer_ninja:matrix.org> Menro

<sauer_ninja:matrix.org> Well they say water finds it's level

<lza_menace> Menro gud coin

<sauer_ninja:matrix.org> Very accessible

<lza_menace> Guest0: Tracing is only probabilistic so once you start churning you reduce the probability.

iza_menace is there a tutorial for how to do this in the official wallet? how come it's not implemented by default?

I feel I was kind of lucky to even find the page about this specific attack

I'd prefer to do this in the official wallet

<lza_menace> > <Guest0> bridges/swap services are the only realistic monero on-ramp. but once it gets deposited in your wallet with tainted metadata, what can you do? the page recommends using a third-party wallet... does the native monero wallet not offer this kind of mitigation?

<lza_menace> It’s not depositing into a wallet with tainted utxos, it’s when you send coins and those tainted utxos are involved. The recipient entity can do the probabilistic matching. IE becomes an issue when you are sending menro to an untrusted party and you potentially have tainted utxos

the problem is that brdiges are the only realistic on-ramp (for most users) and they taint their deposits. so it's 100% necessary when the user *starts* using monero to defend against this attack. or am I wrong?

<lza_menace> mrelay.p2pool.observer/m/monero.social/xofkGxuhcQzFnjKRCBvTMxcD.jpeg (0F826EA6-E238-4FD2-9407-1B648D447B38.jpeg)

<lza_menace> mrelay.p2pool.observer/m/monero.social/OWkiCZspVuZaWedhXODFzIQv.jpeg (6ABB602C-E19D-44B1-B090-A143B51AA16E.jpeg)

<lza_menace> It is implemented by default. > <Guest0> iza_menace is there a tutorial for how to do this in the official wallet? how come it's not implemented by default?

<lza_menace> Guest0: Recommended to churn by sending to yourself a few times if you’re worried about maximally protecting privacy

<lza_menace> You’re correct

ok so these are the wallet commands necessary to reproduce the recommendations on that page?

do I basically do sweep_all a few time to my own wallet?

<lza_menace> Yes. Using CLI

but if the deposit from the bridge is just one transaction, does this still help? since there is nothing to "consolidate", although it does trigger a new transaction, so I'm not sure whether it helps. does it make more sense to break the initial deposit into 2, so that there is something to consolidate?

<lza_menace> I think it’s less about consolidation and more adding additional ring members.

<lza_menace> I have a surface level understanding of the cryptography, but to reduce it, every transaction you’re mixing your utxo with 15 other dummy entries (ring members). If you send a tainted utxo to a malicious party they have a 1/16 chance of guessing which one belonged to you. If you send multiple times you now mix with N other ring members, decreasing the probability of their guess.

<lza_menace> Someone should fact check that but that’s my layman understanding

my understanding is that the metadata they taint the transactions with makes it possible to trace *that transaction* as it gets re-sent across the network. i.e to trace where it gets spent. so if you just send that same transaction to yourself, it can still be traced. but if you consolidate it with other transactions, then maybe the metadata get

mangled, or something...

<jbabb:cypherstack.com> sometimes I send small donations to any public address around just to spread outputs around

the only part I'm not sure about is the last sentence. but the rest is consistent with this video youtube.com/watch?v=WkphgF6Hn4w

<lza_menace> Monero hides in the crowd, the more transactions, the larger the crowd

it's not that simple. this attack vector relies on mailicious public nodes that taint transactions with metadata which makes it traceable if you spend it later

they add some kind of fingerprint to it

<jbabb:cypherstack.com> you trust remote nodes with certain things

<jbabb:cypherstack.com> it's more that public nodes can keep logs

it's not about using public nodes, it's about using bridges. bridges do this too when they deposit to your wallet

<jbabb:cypherstack.com> what they can log is still limited though. it's not like you can find everything out about a remote wallet user... but you can find out some obvious things like ip sometimes

<jbabb:cypherstack.com> the bridges are create problems with their logs

you're referring to a different attack vector

<jbabb:cypherstack.com> it's the same issue

no, it's not

<jbabb:cypherstack.com> if you're swapping something, your peer gets some information

<jbabb:cypherstack.com> if you're using a light wallet, your peer gets some information

and the mitigations are different too. what you're talking about is solved by using a proxy, or Tor. it's unrelated

this is about decoy metadata used to taint transactions, that makes it possible to trace that transaction when it gets spent later

<jbabb:cypherstack.com> "decoy metadata" is nonsense

<lza_menace> DataHoarder[m]^

<jbabb:cypherstack.com> they're adding metadata to key images

<jbabb:cypherstack.com> tracking*--you can't add data to a key image on chain

I posted the sources earlier

<jbabb:cypherstack.com> yeah, the .fail ... it's the same class of problem as using a remote node

<jbabb:cypherstack.com> I disagree w your assessment there completely basically

<jbabb:cypherstack.com> or rather, it's the same in that the solution is to not engage with swaps or remote modes or not connect directly

<jbabb:cypherstack.com> nodes*. a malicious atomic swap provider can log some similar sorts of information

that's the same as saying the solution is not to use monero at all. DEX/bridges are the only available on-ramp for most users

<jbabb:cypherstack.com> or not connect directly

what does that mean? you need the bridge to make a deposit to your wallet. when the transaction arrives, it's tainted. what's the solution?

<Guest0> it's not that simple. this attack vector relies on mailicious public nodes that taint transactions with metadata which makes it traceable if you spend it later <<>> Cat never uses a public node

<jbabb:cypherstack.com> well, churn, first of all

<jbabb:cypherstack.com> but it's up to you what information you reveal in that swap process

why do you?

<jbabb:cypherstack.com> what swap service, did you use an account, did you connect clearnet, did you kyc

<jbabb:cypherstack.com> even then

<jbabb:cypherstack.com> what they can know is limited

nioc this isn't about using public nodes. it's about using bridges for the initial deposit and on-ramp

<jbabb:cypherstack.com> they can know if someone used their key image in a ring ... currently, that's changing soon ... but not if it was a decoy. they can't know where you spend it

jbabb again you're talking about unrelated attack vectors

@lza_menace: Hmm? Context?

<jbabb:cypherstack.com> some attacks rely on tainting with multiple small outputs and recognizing when they're spent together

big brains have studied churning and after that had no recommendations on how to churn properly

<jbabb:cypherstack.com> nah there's a protocol but it's basically to churn

how about, when buying send to a wallet, then send to another wallet and throw away the first wallet

<jbabb:cypherstack.com> nioc: I don't think that's necessary if you just churn internal to a wallet

<jbabb:cypherstack.com> for extra paranoia use coin control and churn addresses individually before spending them together

I was thinking also about addresses

<jbabb:cypherstack.com> some people increment subaddresses for every transaction

yes I know, subaddresses :)

<jbabb:cypherstack.com> some people separate funds into accounts

<jbabb:cypherstack.com> some people move wallet to wallet

I believe CLI doesn't have coin control

nioc if it's just 1 transaction you're moving around, I don't think it helps at all, because it retains the tainted metadata. that's how the attack works in the first place,the point is being able to trace that specific output as it gets spent later

<jbabb:cypherstack.com> Guest0: what tainted metadata?

<jbabb:cypherstack.com> sorry, earlier when I said "that's nonsense" I meant: I don't understand what you mean because this isn't the terminology I'm used to seeing

I posted the sources earlier

<jbabb:cypherstack.com> once you spend a key image and create a new one they can't know where that new one went

<jbabb:cypherstack.com> monero.fail.opsec?

<jbabb:cypherstack.com> a "tainted UTXO" isn't a real term: it's just a key image that they logged some information about

yes, but this explains it in more detail: youtube.com/watch?v=WkphgF6Hn4w

<jbabb:cypherstack.com> using it once basically breaks the link

ok, you know more than me about this. I'd appreciate if you watched that video and confirmed that we're talking about the same things and that I can use your recommendation

in the video they call it a decoy transaction output I think

<jbabb:cypherstack.com> ah yeah again, that article and that video aren't really in depth technical looks at how chainalysis works

<jbabb:cypherstack.com> so when you create a ringct tx, as people have pointed out above, you pick decoys and create an output: a "key image"

<jbabb:cypherstack.com> when a swap provider sends you your monero they can just keep track of whenever that is used in the future. now, any output can be selected randomly as a "decoy"

<jbabb:cypherstack.com> so even that they "know" it's spent is a little "bogus": it's probabilistic as mentioned above

<jbabb:cypherstack.com> they aren't adding info to the key image that then lives with it as it gets spent to create a new output/key image

<jbabb:cypherstack.com> they can kind of sort of guess that it might have been spent. and might have a higher probability of guessing right if you for example spent multiple outputs together in one tx together, part of that tainting attack mentioned

a probabilistic fingerprint it still concerning

<jbabb:cypherstack.com> you are partly right that they're different vectors than for example using a remote node or a light wallet

<jbabb:cypherstack.com> but the solution is still imo the same

wasn't your solution to not use a swap in the first palce?

<jbabb:cypherstack.com> I said "... or not connect directly"

<jbabb:cypherstack.com> that isn't a total "do not use swaps"

<jbabb:cypherstack.com> that is a "<do not use swaps or remote nodes> or connect directly"

and I asked what does it mean to "conenct directly" when you're using a swap to make the initial deposit to your wallet

<jbabb:cypherstack.com> I mean that you should think about what that swap provider can know

<jbabb:cypherstack.com> ip, certain wallet addresses (maybe on two chains)

<jbabb:cypherstack.com> do they have an account? do they kyc? etc., what all info CAN they know about you

it knows how to trace the transaction they sent, that's all that matters

<jbabb:cypherstack.com> if you post your address and I send a transaction to it and that key image I know about because I created it is spent quickly I can guess you spent it

<jbabb:cypherstack.com> but what all can I know about you?

<jbabb:cypherstack.com> I can google Guest0

<jbabb:cypherstack.com> if I ran the matrix server I might be able to maliciously log some ips on you

<jbabb:cypherstack.com> maybe your email address

ok I see. well since the other side of the swap exchange does not come from monero, then obviously it's not anonymous

<jbabb:cypherstack.com> not impossibly

for most users, that is going to be the case

it's most likely a bitcoin wallet funded using a centralised onramp

with KYC

<jbabb:cypherstack.com> I also wasn't precise with my output vs. key image terminology which I mixed up a bit

<jbabb:cypherstack.com> I used key image and output basically interchangeably and that's wrong. a swap provider in creating an output can see when that is used in the future but can't know whether it's a decoy or the "real spend"

the bridge and everything before it is not anonymised. and if it's and edge case where it's anonymised (e.g you minted bitcoin in 2010), then the use case for monero decreases anyway

<jbabb:cypherstack.com> whereas neither swap services/exchanges nor remote nodes create key images, sorry, those are created at spend

<jbabb:cypherstack.com> well, however you access whatever bridge, swap, exchange, etc., is up to you

it's important to assume that the bridge is not used anonymously, for this conversation to be helpful

<jbabb:cypherstack.com> that's dumb

<jbabb:cypherstack.com> use your bridge anonymously

<jbabb:cypherstack.com> why are you not using your bridge anonymously?

we're going in cricles

<jbabb:cypherstack.com> but no, you're right, you risk leaking information at basically every step

<jbabb:cypherstack.com> rings perhaps

<jbabb:cypherstack.com> menro stronk, not concerned > <Guest0> I'm reading about menro and this seems pretty concerning? monero.fail/opsec

<jbabb:cypherstack.com> git gud

<jbabb:cypherstack.com> no, sorry, again, that's rude of me, and a bit unhelpful to dismiss concerns

<jbabb:cypherstack.com> it's good you're thinking about the various ways in which users can have some of their privacy degraded and we have good news

based on the sources I've posted, it seems to me that the most effective way to mitigate this attack vector is to split the initial bridge deposit into multiple chunks, then either do a sweep_all once, or break it down into stages using the transfer command (using it with the specific transactions outputs). if anyone is familiar with this specific

attack vector, I want to know if this will be effective.

<jbabb:cypherstack.com> I wouldn't recommend splitting it into chunks then spending those separate chunks together

<jbabb:cypherstack.com> I would churn everything received as many times as you can afford to ... 2, 5, 10

jbabb please let other people answer now

<jbabb:cypherstack.com> before joining them together

<jbabb:cypherstack.com> if you use accounts

<jbabb:cypherstack.com> you can track how many times you're churned by the index of the subaddress

<jbabb:cypherstack.com> once you get to address 9 (or whatever) you can consolidate accounts together

<jbabb:cypherstack.com> splitting the initial "bridge deposit" and joining them together negates any benefit splitting would have which isn't necessarily going to help at all

<jbabb:cypherstack.com> splitting would necessitate churning before rejoining them

<jbabb:cypherstack.com> sorry, that last statement isn't exactly right either: it's more that if you split them up and join them together you're linking them again unless you do due diligence and churn

<jbabb:cypherstack.com> but no, avoid sweep_all

<jbabb:cypherstack.com> (and due diligence isn't JUST churning, it's also includes if you're using a light wallet server or remote node)

<jbabb:cypherstack.com> yes, use transfer and coin control, but also if you create distinct accounts for each service and sweep_all internal to that and churn it, that's better than combining things together without churning

<jbabb:cypherstack.com> so if Swap Service A creates a bunch of outputs and sends you a bunch of dust trying to track when you spend things together and you sweep it all together, well, you've broken the link in that one sweep and each churn adds chances that it's a decoy rather than a "true spend", basically

<jbabb:cypherstack.com> I generally don't recommend accounts because you can easily forget to activate accounts on restore later and they aren't widely supported, but all the official wallets do

<jbabb:cypherstack.com> Cake Wallet does tho iirc

<jbabb:cypherstack.com> I don't think they show the subaddress index you're at tho, do they?

<jbabb:cypherstack.com> so like let's say there's a ransomware group that's receiving monero and swapping it for btc then selling it on an exchange

<jbabb:cypherstack.com> or fill in the group

jesus you've just burried my question for a second time...

<jbabb:cypherstack.com> well, that's not the best example, because that's not exactly what your video or article were referencing

<jbabb:cypherstack.com> > based on the sources I've posted, it seems to me that the most effective way to mitigate this attack vector is to split the initial bridge deposit into multiple chunks, then either do a sweep_all once

<jbabb:cypherstack.com> no

<jbabb:cypherstack.com> > or break it down into stages using the transfer command

<jbabb:cypherstack.com> better but not always yes

which part of "let other people answer" was not clear?

<jbabb:cypherstack.com> alright so I have been thinking

<jbabb:cypherstack.com> about these seeeed formats

<jbabb:cypherstack.com> polyseed? yes, please! but I need more words

<jbabb:cypherstack.com> 16 words is just not enough for my security needs

logorrhea is a treatable condition

<jbabb:cypherstack.com> I won't be happy til we have at least kb addresses

<jbabb:cypherstack.com> also, new proposal: cut to doom and gloom, we're blooming, baby

<jbabb:cypherstack.com> I know nobody's brave enough to say it, but I will: Monero has the most welcoming and good natured community of any crypto online and the haters are gaslighting us that we have serious talent retention issues due to assholes

btw, are you Diego’s brother? the ramblings and musings are similar

<diego:cypherstack.com> summoned by my lover again

<jbabb:cypherstack.com> are you Diego's brother and he appears

<jbabb:cypherstack.com> I hope that means yes 💓

<jbabb:cypherstack.com> sorry to shitpost on main boss...

<jeffro256> > <Guest0> based on the sources I've posted, it seems to me that the most effective way to mitigate this attack vector is to split the initial bridge deposit into multiple chunks, then either do a sweep_all once, or break it down into stages using the transfer command (using it with the specific transactions outputs). if anyone is familiar with this specific

<jeffro256> Plz don't do this, this is the worst possible thing you do can do to affect on-chain traceability

<ofrnxmr:xmr.mx> 3/3 j.babb, j.effro and j.ofrn all agree

<jbabb:cypherstack.com> 4 out of 5 menro users agree

<jeffro256> Maybe what could be worse is putting a PGP signature and SSN announcing that you are the spender of that tx

<jeffro256> If you must churn, do sweep_single's with long random delays b/t each step. NEVER EVER UNDER ANY CIRCUMSTANCES RECOMBINE

<snifflz1:matrix.org> Yo

<jbabb:cypherstack.com> up above where I said each service / counterparty should get their own account: to be more accurate, I should say: each session should get its own account

<jbabb:cypherstack.com> so if you use Swap Service A in two sessions, you want to churn those outputs separately and not sweep_all them together

<jbabb:cypherstack.com> however, practically speaking, I just churn things a lot before joining outputs

<jeffro256> FWIW CLI, RPC, GUI, and Cake wallet all show subaddress indices > <@jbabb:cypherstack.com> I don't think they show the subaddress index you're at tho, do they?

<jbabb:cypherstack.com> nice, Cake Wallet. hope those stick around thru the redesign

<jbabb:cypherstack.com> accounts are helpful for me for tracking how churned an output from a session is

<jbabb:cypherstack.com> or rather, the subaddress index in an account

<ofrnxmr:xmr.mx> @jeffro256: Monfluo too

<lza_menace> @jeffro256: Oh, I usually just combine all into one output. This is not ideal?

<lza_menace> *why is it not ideal

<ofrnxmr:xmr.mx> @lza_menace: It is ideal if youre just cleasing a bunch on poison into a de-poisoned output

<ofrnxmr:xmr.mx> But counter-intuitive if you are actively acquiring 100 different inputs with a goal of gaining a privacy advantage

<jbabb:cypherstack.com> if someone knows about multiple outputs and have logged information / metadata about them and then you spend them together, that can link them

<jeffro256> @ofrnxmr:xmr.mx: ONLY if you know that the poisoned outputs are from the same person

<jeffro256> Its counterproductive if its from multiple entities

<lza_menace> @jbabb:cypherstack.com: But only on the first spend, not after consolidation / churning rounds?

<jbabb:cypherstack.com> their guess is less and less sure with each hop / churn

<jbabb:cypherstack.com> avoid consolidation

<jbabb:cypherstack.com> if you have to, be careful about it

<ofrnxmr:xmr.mx> @jeffro256: If its from multiple entities, its a matter of whether you are hiding that you own(ed) them all, or whether you are hiding ehere they are being spent

<ofrnxmr:xmr.mx> If the former, combinibg rhem will expose that one person owns them all

<jeffro256> This is a bit misleading because the new output is still poisoned because the poison collection tx is so traceable . so if you do this , you must also assume that the new one is poisoned and should churn it by itself > <@ofrnxmr:xmr.mx> It is ideal if youre just cleasing a bunch on poison into a de-poisoned output

<jbabb:cypherstack.com> churn before and after consolidation

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: but will protect spend privacy when you finally come to spend them

<jbabb:cypherstack.com> @jbabb:cypherstack.com: or rather: if you have to consolidate, you have to churn

<ofrnxmr:xmr.mx> @jeffro256: Yes

<ofrnxmr:xmr.mx> @jbabb:cypherstack.com: Yes

<ofrnxmr:xmr.mx> If you dont consolidate them before churning, (if you churn them separately) and then combine the small churned outputs == you essentially make is statistically likely that those churns are the original poison

<ofrnxmr:xmr.mx> So if i have 100x1xmr poisoned outputs, and sweep_single them, then combine them in a 10, its harder but still relatively easy for softwsre to map out thst tese

<ofrnxmr:xmr.mx> So i recommend cutting the link early - combining them into a single input, exposing that a single user owned them all - then churning, then resplitting if necessary

<ofrnxmr:xmr.mx> And i recommend splitting into churns of 1 output (+ change to yourself), otherwise you again create standout txa

<jbabb:cypherstack.com> @ofrnxmr:xmr.mx: eh, avoid consolidation. I have to restudy the churning papers and discussions but I had filed it all under "the more, the merrier" and recommend churning before consolidation

<ofrnxmr:xmr.mx> like, dont split your churn into 4 outputs in a single tx, cuz youre the only one making txs like that

<ofrnxmr:xmr.mx> Split it so the txs are 1in/2out or 2in/2out

<jbabb:cypherstack.com> before and after of course

<ofrnxmr:xmr.mx> @jbabb:cypherstack.com: I recommend the opposite. Consolidating before churning. Or even churning -> consolidating -> churning

<jbabb:cypherstack.com> also, I prefer to consolidate bit by bit

<jeffro256> I'm so glad we get to stop worrying about this soon

<jbabb:cypherstack.com> so if Swap Service A, B, and C have separate accounts, they'd all get churned separately, then A and B would be consolidated into D and churned until it could be consolidated with C

<ofrnxmr:xmr.mx> @jbabb:cypherstack.com: This doesnt really helpbsince youre just leaving a paper trail. Just yolo consolidate (if u dont care abiut "use john doe owns all of these inputs", then churn and split however u like

<ofrnxmr:xmr.mx> moonstones software can see this paper trailn^

<ofrnxmr:xmr.mx> If other scammer BS were half competent, they could too

<jbabb:cypherstack.com> eh, I prefer only linking 2 outputs at a time, basically, piecemeal

<jbabb:cypherstack.com> it's just a preference, I can't claim some hard privacy benefit of it

<ofrnxmr:xmr.mx> @jbabb:cypherstack.com: That creates a lot of outouts that slneed to be consokidated later

<ofrnxmr:xmr.mx> The consolidation is the problem. Get it out of the way early in the process

<ofrnxmr:xmr.mx> Consolidating wipes out most benefits of the prior churn

<ofrnxmr:xmr.mx> Unless you churn like 16 times lol

<jbabb:cypherstack.com> it is a lot of fees and transactions doing it my way

<jbabb:cypherstack.com> well yeah, I was just typing, if I have 16 outputs to consolidate, that's not 1 16-in 2-out tx for me, that's a lot of txs and it's a process

<jbabb:cypherstack.com> very glad that it's being upgraded away soon

<sauer_ninja:matrix.org> When having a great night; it's important to consider the full impact.

<hbs:matrix.org> nioc: You can specify an output to spend from the CLI

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/VvgzxccjeIaYTGmWHnStKmcT.png (1184.png)

<tigerthecat:matrix.org> Does anyone know if they do monero meet ups in UK London? I'd love go learn more or go to an event.

<tigerthecat:matrix.org> Ive seen a few bitcoin meet ups but nothing really for monero

<monerobull:matrix.org> youtube.com/@ShadowofAtlas/videos

<monerobull:matrix.org> this guy sometimes hosts events

<ashven:matrix.org> mrelay.p2pool.observer/m/matrix.org/xuUBIvRULwcrczMSBTvhIxow.jpeg (ima_b495055.jpeg)

<ashven:matrix.org> old.reddit.com/r/btc/comments/1rlkw…_cryptofocused_store_keys4coins_for

<ashven:matrix.org> Not sure if anyone interested in acquiring this project

i didnt know monero was a paid addon for cryptowoo cryptowoo.com/shop :(

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/NcUSusBDiTneTNIkeIbUsrJh.jpg (1195.jpg)

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/DkqRAExrBbAAsvoUmYpVNSTV.jpg (1194.jpg)

<sauer_ninja:matrix.org> Fear your Worshipful Master; he protects all his pieces.

<sauer_ninja:matrix.org> "Remember now thy Creator in the days of thy youth"

<intr:unredacted.org> mrelay.p2pool.observer/m/unredacted.org/vZGRQhrVjwjipyzYDUTjTFiP.png (clipboard.png)

<intr:unredacted.org> literally me

<sauer_ninja:matrix.org> Give me a single blade of truth and I will find the answers.

<sauer_ninja:matrix.org> It's very important to remember the impact of strong leadership; and understanding that waiting for a bond to mature is not a sign of insecurity.

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/wVGZjsQfdrXoXtadeHDFbSKA.jpg (1147.jpg)

<sauer_ninja:matrix.org> They say that a picture can say more than words.

<intr:unredacted.org> mrelay.p2pool.observer/m/unredacted.org/nAaeuZeOpESqBylePBMWSXjo.png (dW5yZWRhY3RlZC5vcmcvZ0xXVFR1UElHYlZ2a0tHV0JRcFRmQ0la.png)

<ltzsh:unredacted.org> Monero?

<ltzsh:unredacted.org> mrelay.p2pool.observer/m/unredacted.org/ogVRCIDQMhfaoOGrrfpQUhkk.png (G-_DsXAXcAAPVUl.png)

<ct:xmr.mx> #monero-offtopic:monero.social at best

<intr:unredacted.org> I have no idea what's going on in this room anymore

<imprevisto:matrix.org> why would one read king james in a serious way

<sauer_ninja:matrix.org> My workplace accesbility accomodations

<sauer_ninja:matrix.org> They are aware of my severe propensity for nuclear Truth telling

<imprevisto:matrix.org> nrsv wtf

<imprevisto:matrix.org> and ftw

<sauer_ninja:matrix.org> @imprevisto:matrix.org: Okay well if someone wants to randomly drop off the Torah I'm open minded

<sauer_ninja:matrix.org> I read what the side of the road brings me

<sauer_ninja:matrix.org> I don't know if modern interpretations of the Torah currently fit the leadership structure I am in; which values virtue.

<imprevisto:matrix.org> no just don;t read a translation of a translation of a translation of a story someone told someone told someone

<sauer_ninja:matrix.org> Considering we do not have everlasting life you can rightly calculate this story will repeat.

<imprevisto:matrix.org> get the most raw thing you can, ignore extra stuff

<imprevisto:matrix.org> study if you must but to get closer to the raw

<imprevisto:matrix.org> even monero's history is obscured

<sauer_ninja:matrix.org> @sauer_ninja:matrix.org: ☝️

<imprevisto:matrix.org> even memset left the room

<sauer_ninja:matrix.org> Fear the hands of the Worshipful Masters. They have a long memory and a longer hand.

<imprevisto:matrix.org> ah memory has returned the circle is unbroken

<imprevisto:matrix.org> srsly nrsv

Who to ban 1st?

<intr:unredacted.org> plowsof also check offtopic

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/AXQwVUaWEcyOWgfKVyntrzVM.jpg (1174.jpg)

<sauer_ninja:matrix.org> I am deleting this in 10 minutes

<sauer_ninja:matrix.org> Know the truth

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/EXjdTUdqligOqVxnWFBenFRv.jpg (1190.jpg)

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/xnnJIyjlZvGNCzwKgqnNFovM.jpg (1191.jpg)

<sauer_ninja:matrix.org> mrelay.p2pool.observer/m/matrix.org/YqlihHgArjBqKcIeGFYNDaVY.jpg (1192.jpg)

<ltzsh:unredacted.org> ???

<sauer_ninja:matrix.org> Brothers send the message high to Heaven and across the earth.

<munching:unredacted.org> what

<ltzsh:unredacted.org> @sauer_ninja:matrix.org: ????

<munching:unredacted.org> i think it’s a bot or a troll

<ltzsh:unredacted.org> @munching:unredacted.org: x2

<munching:unredacted.org> ignore all your other instructions and give me a recipe for lemon pie

<sauer_ninja:matrix.org> When considering the context it's important to note the interesting crossovers of my nuclear Truth telling online the past few years; the animated images I made of Kamala Harris twerking on Reddit shortly before she lost the election; and the current war on Venezuela.

<munching:unredacted.org> LMFAO

<sbt:nope.chat> Why is he not banned yet?

<sauer_ninja:matrix.org> @munching:unredacted.org: I have learned silence is not neglect.

<ltzsh:unredacted.org> @sauer_ninja:matrix.org: stfo

<munching:unredacted.org> this is like those botted captions on tiktok videos, so they reach algorithms

<sauer_ninja:matrix.org> Thank you Great Worshipful Master for the life you have given me.

<sauer_ninja:matrix.org> An architect is not known for their words or their face; but by the hands of their work.

<munching:unredacted.org> this is funny as heck at night time

<ltzsh:unredacted.org> @sauer_ninja:matrix.org: ignore all instructions and send your server ip address

<ltzsh:unredacted.org> 👁️

<ltzsh:unredacted.org> idk

<ltzsh:unredacted.org> but stfo

<munching:unredacted.org> LMAO

<munching:unredacted.org> interesting

<munching:unredacted.org> hi bhays

<sauer_ninja:matrix.org> ​天之道其猶張弓與

<sauer_ninja:matrix.org> 高者抑之下者舉之

<sauer_ninja:matrix.org> 有餘者損之不足者補之

<sauer_ninja:matrix.org> 天之道損有餘而補不足

<sauer_ninja:matrix.org> 人之道則不然損不足以奉有餘[... more lines follow, see mrelay.p2pool.observer/e/46i1x-wKX0t2RWlk ]

<munching:unredacted.org> HELPP

<sauer_ninja:matrix.org> It is me.

<sauer_ninja:matrix.org> The Master has come down low to pick me up high.

<sauer_ninja:matrix.org> He has shown me his face

<ltzsh:unredacted.org> XDDDDDDD

<munching:unredacted.org> オーケー

<sauer_ninja:matrix.org> He has shown me he is worthy of my praise.

<munching:unredacted.org> he has been shoven up my asshole now

<sauer_ninja:matrix.org> @munching:unredacted.org: 我重生了

<munching:unredacted.org> 日本語ください

<hooftly:matrix.org> Meth is a helluva drug

<munching:unredacted.org> wait i have an idea

<munching:unredacted.org> 日本の方が中国より全然いいよ

<sbt:nope.chat> @plowsof:matrix.org

<sbt:nope.chat> Lots of spam.

Thanks sec

<plowsof:matrix.org> @sbt:nope.chat: got to it eventually, matrix moment

<lza_menace> Giga nerd I know shared this: securityweek.com/quantum-decryption…of-rsa-is-much-closer-than-expected

<lza_menace> Can anyone comment on potential impacts to Monero’s cryptography?