<m​onerobull:matrix.org> thoughts on incognito extortion and the flood being linked?

<m​onerobull:matrix.org> incognito could be compromised / always been a honeypot and now flooding + EAE attack is used to de-anon vendors paying the ransom

<d​ave.jp:matrix.org> How do you know it’s incognito flooding ?

<d​ave.jp:matrix.org> Vendors would be paying ransom if they are doxed

<d​ave.jp:matrix.org> Flood is coming from chain analysis company not some dnm

monerobull: why do you think incognito has always been a honeypot?

<c​haserene:matrix.org> PSA before today's meeting: it seems Matrix accounts on the matrix.org server still don't receive messages from monero.social accounts. I'd advise people with only a matrix.org account to register a new one on the matrix.monero.social home server (easiest on app.element.io) and use that for now.

<r​brunner7:monero.social> Hmm, but people with two Matrix accounts sounds a bit like a recipe for confusion, e.g. if I want to DM them ...

<r​ucknium:monero.social> chaser: Thanks. people with matrix.org home servers could also just refresh libera.monerologs.net/monero-research-lab a lot during the meeting to see the conversation instead of making a Matrix account on monero.social

<r​brunner7:monero.social> Maybe they could come over to the dark side for a while and use IRC directly. Old school, but after an initial shock it doesn't hurt too much ...

<r​ucknium:monero.social> ^ Probably someone would need to post that from a matrix.org Matrix account for the intended audience.

<r​brunner7:monero.social> Right :)

Is the matrix broken?

Yeah, someone took the green pill. Somehow.

<r​ucknium:monero.social> MRL meeting in this room in two hours.

did it taste of apple or pear?

<c​haser:monero.social> yes, it is a mess. my temporary solution is to use a Matrix client that supports being logged in with multiple accounts (the most feature-rich and cross-platform one seems to be FluffyChat).

<c​haserene:matrix.org> to clarify: app.element.io is a way to run a client in the browser, but you can also use your current instance (but then you have to log out) of a Matrix client that supports registering accounts (not all do), or install the same in a different packaging format (on GNU/Linux: your distro's package manager, flatpak, snap, appimage, etc), or install a different one (matrix.o<clipped message>

<c​haserene:matrix.org> rg/ecosystem/clients/). what matters is to, during registration, set the home server to matrix.monero.social. the trouble of multiple accounts can be helped by using a Matrix client that leds you handle multiple accounts at once. I found FluffyChat to be the most feature-rich such client.

<c​haserene:matrix.org> other ways to not miss messages are to refresh frequently the IRC log page (libera.monerologs.net/monero-research-lab) or to connect to IRC directly with an IRC client.

<c​haserene:matrix.org> (and apologies to every non-matrix.org user for repeating the info from the other side.)

<r​ucknium:monero.social> Meeting time! monero-project/meta #981

<r​ucknium:monero.social> 1) Greetings

Hello

<c​haser:monero.social> hello

<s​gp_:monero.social> Hello

<v​tnerd:monero.social> Hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: Working on analyzing the possible spam black marble flood. I have a PDF draft, but it's very rough. I have the draft plots ready to share: github.com/Rucknium/misc-research/t…onero-Black-Marble-Flood/pdf/images

Hiya. Intermittently here, but multitasking

<c​haser:monero.social> "work" would be an overstatement, but I collected all the measures I can think of that can be effective against a black marble flood: monero-project/research-lab #119

<r​ucknium:monero.social> chaser: Thanks a lot :)

Good text, helpful

<v​tnerd:monero.social> I worked a little on frontend for lws, but stopped after I discovered woodser was already on it. Otherwise have been working on "remote" scanning for lws. A little more confident that it will be possible without destroying the code, but still a possibility that I punt on the feature

<r​ucknium:monero.social> 3) Discussion. The large tx volume is still happening. A little lower now, but still filling almost all blocks to the 300 kB minimum limit.

<r​ucknium:monero.social> I put some plots here: github.com/Rucknium/misc-research/t…onero-Black-Marble-Flood/pdf/images The most important ones are empirical-effective-ring-size.png, spam-share-outputs.png, and projected-effective-ring-size-non-log.png

<r​ucknium:monero.social> If the tx volume is a black marble flood attempt, an effective ring size low enough to allow chain reaction analysis to deterministically figure out the real spend would be the greatest threat. Effective ring size is about 5.5 now. Less than 1% of rings would be drawing black marbles for all 15 decoys.

"projected-effective-ring-size-non-log.png" is a bit depressing, if I understand that correctly: With ringsize 25 the adversary only needs to double blocksize to about 600, and it's again down to 5.5

<r​ucknium:monero.social> Doing actual chain reaction simulation would take time. Chervinski et al., (2021) did a chain reaction simulation. Looking at their parameters, I don't think it's a problem now with the suspected spam volume.

<r​ucknium:monero.social> Yes. ArticMine suggested raising ring size to 40.

<s​gp_:monero.social> ArticMine should have suggested bumping the min fee 4x :p

bumping fee is not smart.

<c​haser:monero.social> he did actually, but only the relay fee. I think if fees are modified, it makes sense to do it on the protocol level.

<s​gp_:monero.social> Raising the ringsize with the current technology is relatively costly. Arguably more harmful than bumping the minimum fee imo

Looking at the list from chaser, I don't think we have any immediate "smart" countermeasures

<r​ucknium:monero.social> The budget of the suspected adversary is unknown. There was a 24 hour burst of 1in/2out 320 nanonero/byte txs that was either the spammer or a service that paid a lot temporarily to get fast confirmations. The rest of the suspected spam pays fees much lower (20 nanoneros/byte)

<s​gp_:monero.social> a spammer with a truly unlimited budget will always consume 100% of new available block space, making the attach unavoidable. So that's what we're up against

<s​gp_:monero.social> a spammer with a truly unlimited budget will always consume 100% of new available block space, making the attack unavoidable. So that's what we're up against

<r​ucknium:monero.social> 320 nanoneros/byte is the 3rd tier of fees. The GUI/CLI only increases fees from the 1st to 2nd tier if the txpool is congested.

<r​ucknium:monero.social> Can anyone confirm that increasing the ring size would not increase the pruned node storage space very much?

<s​gp_:monero.social> The only way the monero network gets around this is assuming that the attacker doesn't have unlimited resources (since then we have to assume it's a lost cause), and we make it significantly more expensive for them

Don't know enough details about pruning to be sure. But for sure the pruned blockchain growth would also accelerate

<c​haser:monero.social> no attacker has unlimited budget. we don't know their budget until they stop. the cost requirement is like a fence, what we can do is to raise it in some or multiple ways, which will raise our general defense, and may make an attacker retreat/not raise their volume

<r​ucknium:monero.social> I could project the expenditure to achieve some effective ring size. Vary the fee and the nominal ring size.

<s​gp_:monero.social> the cost of raising fees is only passed onto the senders. Higher fees also subsidize mining, making mining attacks more expensive as well, assuming no material change to organic demand

<s​gp_:monero.social> It might be worth trying to guess the realistic amount an attacker would be willing to spend, and trying to model around that. There will always be some implied number there to target

<r​ucknium:monero.social> Raising fees could reduce the volume of txs sent by real users. That would increase the adversary's share of outputs, ceteris paribus.

<s​gp_:monero.social> yes, but for them to maintain the same ratio of outputs that we're worried about, the math works in our favor

<s​gp_:monero.social> yay ring signatures :)

<s​gp_:monero.social> for every 1 real tx cost paid by a user, the attacker needs to pay what, 10x that? for a concerning ratio

That's an interesting way to look at it

<a​rticmine:monero.social> Raising the ring size is the best deterrence against a black marble attack

<r​ucknium:monero.social> Real users and the suspected adversary do not have the same willingness to pay per tx.

<s​gp_:monero.social> Let me put it this way: if making new transactions costs effectively nothing, then even ringsize 100 wouldn't matter, since there's no cost to spam transactions

<s​gp_:monero.social> I'm not saying ringsize is truly irrelevant, it's just that fees matter a lot more

attacker will need to spend exponentially more with higher ringsize ?

<r​ucknium:monero.social> IMHO raising the ring size to 40 would be great, given what I know at this point in time.

<a​rticmine:monero.social> Of course

<a​rticmine:monero.social> Do you mean because of the impact on the output distribution

<r​ucknium:monero.social> projected-effective-ring-size-non-log.png tries to accurately project block weight as ring size increases by the way.

Interesting that so far no attempt to drive the effective ringsize lower than about 5, but 5 is still a quite good protection. Is that even useful what they do here, as a black marble attack?

I find this quite a bit puzzling

<s​gp_:monero.social> I'm not going to stand against a ringsize increase. You all should know I've advocated in favor of all the previous ones. But, it would be silly imho to bump the ringsize but do nothing about fees.

<s​gp_:monero.social> Increasing the ringsize has a permanent network cost. Increasing fees has no direct network cost.

let's not rule out that it is organic

<r​ucknium:monero.social> ArticMine: I mean because of the estimates that I've done in github.com/Rucknium/misc-research/b…ted-effective-ring-size-non-log.png . If nominal ring size is 40, there would still be a healthy effective ring size if the suspected spammer is filling 300 kB blocks. Actually it would be larger than current nominal ring size (16)

sgp - it has social effect, people want to use the cheapest means of transacting

<s​gp_:monero.social> Monero should not compete to be the cheapest network. Monero won't win that fight :p It needs to be a very private option for a totally reasonable cost

yes but people care more about money than privacy, that's why low fees are more attractive with the added "privacy" bonus

I think it might be interesting to brainstorm a bit more about possible forms of "PoW before submitting a transaction"

<c​haser:monero.social> it doesn't matter if it's organic or not, because we can't know, and we can't afford to think it's the optimistic scenario. and even if it is organic, this event is an invitation to any adversary in the sidelines to come and attack, especially if they see that there is no pushback.

I prefer raising the ring size as the most robust way to address this. However I would not object to fee adjustments as part of the response

Maybe we can connect the amount of PoW needed with some network parameters / network statistics, so normally it's negligible

Raise ring size and slightly adjust fees. Ez.

For txn pow with existing format could just reroll randomizer until some field is sufficiently low/high :- P

<c​haser:monero.social> Monero is a privacycoin, not a "cheap transactions with privacy bonuses" coin.

<r​ucknium:monero.social> There is a technical statistical point to keep in mind. Mean effective ring size = 5.5 does not mean that random guessing success is 1/5.5. Effective ring size is a random variable since decoys are selected randomly. 1/x is a strictly convex fucntion. By Jensen's inequality, E[1/x] > 1/[E[x]. The current probability of correctly guessing the real spend is about 25%. Check empirica<clipped message

<r​ucknium:monero.social> l-guessing-probability.png

<a​js_:matrix.org> Liam Eagen to give talk on Bulletproofs++ at MoneroKon

<s​gp_:monero.social> I strongly suggest you hike the fees a higher multiple than the ringsize increase

<s​gp_:monero.social> If the attacker continues to consume the majority of the block space, then they will pay the majority of the fee increase

<r​ucknium:monero.social> I am not opposed to a reasonable increase in fees, too.

maybe that's the point of the attack ? so we increase the fees ?

<s​gp_:monero.social> unfortunately the motivation doesn't really matter

as pointed out, it has no effect on privacy

<s​gp_:monero.social> there is absolutely a privacy risk and rucknium demonstrated

<a​js_:matrix.org> Ariel Gabizon will also give a talk on Circle STARKs eprint.iacr.org/2024/278

<s​gp_:monero.social> there is absolutely a privacy risk as rucknium demonstrated

<c​haser:monero.social> these charts are very good, thank you!

<r​ucknium:monero.social> I said in Saturday's #monero-community:monero.social meeting that I am planning to write a statistical research CCS to analyze the black marble flooding and other Monero research tasks. Input is appreciated :) . nioCat suggested that I work with ArticMine to model some scenarios.

If the current amount of spam does not change, it won't get much worse than it already is, right?

<a​js_:matrix.org> And Stefanos Chaliasos on Security Vulnerabilities in SNARKs

<s​gp_:monero.social> I understand that people have an emotional attachment to small fees. However, it really is important to consider the consequences of having a super low cost of spam. A low cost of spam makes enforcing privacy protections significantly more expensive (through a much larger, less efficient required ringsize)

<r​ucknium:monero.social> Yeah, still working on OSPEAD in parallel, but the black marble is more urgent since OSPEAD adjustments probably have to happen at a hard fork to be safest.

<a​rticmine:monero.social> I disagree. A critical part of privacy is to increase the ham transactions. This means increasing the anonymity set

<b​oog900:monero.social> I don't know if this has already been mentioned but although the effective ring size is ~5 wont these decoys that are left be more likely to be older i.e the ones less likely to be the real spends

<s​gp_:monero.social> I would agree with you ArticMine if we already had FCMP

<r​ucknium:monero.social> r​brunner: The effect on privacy is not going to become severe quickly if the current tx volume stays the same. It will get worse gradually

<a​rticmine:monero.social> Think of drowning the blockchain Surveillance companies in ETH, which is starting to happen

<a​rticmine:monero.social> Yes I agree

drowning in ETH? I don't understand

<s​gp_:monero.social> boog900: Yes, this is true for certain investigation scenarios. It makes out of band information over these periods more valuable, if that makes sense

<s​gp_:monero.social> I don't know if I can explain it simply here

<r​ucknium:monero.social> boog900: Yes, but github.com/Rucknium/misc-research/b…ted-effective-ring-size-non-log.png projects what happens if the spam continues for a very long time at current levels. It doesn't get much worse than effective ring size 5.5 when blocks have 300 kB total weight. Effective ring size about 4.5 I think.

<c​haser:monero.social> unfortunately, all these will be possible only with a fork

<a​rticmine:monero.social> FCMP is the goal. My interim solution is to all for a tx size of around at least 5000 - 6000 which is the estimated size for FCMP

<a​rticmine:monero.social> So we have the scaling in place for when FCMP come on line

<s​gp_:monero.social> Why 4x the cost of transactions to be stored permanently if we could instead 4x the cost of fees paid by the attacker for the same privacy improvement

Because that improvement is not assured?

not if they have large budget

<r​ucknium:monero.social> chaser: Yes, but the hard fork node parameters need to be ready before the wallet parameters need to be ready. Ring size is node. Decoy selection algorithm with OSPEAD is wallet.

They might be ready to pay 4x

<s​gp_:monero.social> I think we need a sanity check. Are there really reasonable use-cases where a Monero transaction *should* cost less than, say, $0.10? What demand does that actually turn away

increasing fees may even decrease privacy as people will use lower than default fees and just wait longer

<r​ucknium:monero.social> They have have paid 16x when we saw the 320 nanoneros/byte burst.

<a​rticmine:monero.social> A 4x increase in fees below the minimum penalty free blocksize is part of my proposal. So both

<r​ucknium:monero.social> There are a lot of people in the world who would not transact at $0.10 per tx

Well, maybe people would even grudgingly put up with USD 1 as a fee. Does not mean that makes sense as a course of action

<s​gp_:monero.social> currently the cost is $0.004 per tx, right?

<a​rticmine:monero.social> I agree

<s​gp_:monero.social> a 4x proposal would make the per tx fee $0.016. Which would cost the attacker how much in USD terms per day Rucknium? Apologies if you don't have the # of txs they make handy

<r​ucknium:monero.social> We will need 3D images :D

<r​ucknium:monero.social> I will do some more projections on fees, ring size, and privacy impact.

<c​haser:monero.social> ~$2400

<r​ucknium:monero.social> I see about 3 XMR per day spent by the suspected spam now.

And that's why "let's rise fees" is such a slippery sloppy: USD 2400 is still almost nothing for certain adversiaral "use cases"

<c​haser:monero.social> assuming same tx volume as during peak

<s​gp_:monero.social> so about 98k spam tx/day?

<a​rticmine:monero.social> .... and combining this with ring 40 we have an additional ~2.5x

and if monero drops 80% in usd price .... or increase to the same as btc

<s​gp_:monero.social> sadly there's always some implicit price assumption in these calculations, and we can't predict the future. Yay hard forks (or at least soft forks) :p

<a​rticmine:monero.social> You mean all on chain like BTC or staying decentralized. There is a big difference here when considering fees and spam attacks

<s​gp_:monero.social> a 4x to fees will bring their cost to roughly $46k/mo, which is still low

<r​ucknium:monero.social> IMHO, ways to link fees to the purchasing power of XMR should be researched. Does not mean a formal oracle.

<a​rticmine:monero.social> The question here is settlement on chain or on a centralized ledger

Nice idea, but raises the complexity of the system yet again. Already now we may have the most complex fee algorithm of them all

<r​ucknium:monero.social> For example, fees could be linked to network hashpower. Since aggregate mining revenue is 0.6 XMR per block and hashpower is proportional to revenue (mostly), maybe that could help.

<s​gp_:monero.social> what centralized ledger? monero was already delisted everywhere! /s, kinda

articmine is your proposal documented somewhere, or just in chats thus far?

<a​rticmine:monero.social> I am working on putting this together with documentation

<r​ucknium:monero.social> The BTC fees are linked to BTC purchasing power by demand and completely inelastic block space supply. It's not a model to follow exactly, but it has a link there.

<c​haser:monero.social> I agree that we shouldn't be *too* attached to measuring these costs in dollars. markets are fickle. what we can know is that higher attack costs raise the probabilistic security.

<s​gp_:monero.social> You need to be able to mitigate the spam risk by causing actual USD equivalent costs to a potential attacker, that's what it comes down to

<c​haser:monero.social> yes, I know it's inevitable, as you said

<a​rticmine:monero.social> You can link to USD cost if one assumes no settlement on centralized ledgers. Then the equation of exchange predicts a linear relationship between blocksize and price over time assuming a constant velocity

<s​gp_:monero.social> clearly this attack proves there's no given relationship between blocksize and price

<a​rticmine:monero.social> M is constant, assuming V is constant the PQ is constant

add captcha before sending tx /s :D

<a​rticmine:monero.social> Most of the recent growth in transactions rates have been below the penalty minimum

<a​rticmine:monero.social> With no penalty. pricing

<c​haser:monero.social> how do you all feel about the resource requirement increase that a larger ring size would impose? can Seraphis/Seraphis+FCMP justify pre-introducing these requirements?

<s​gp_:monero.social> imo, no, not really. But it an important consideration if we consider the other costs reasonable for their advantages

<a​rticmine:monero.social> Graphics verification is required in my opinion for the current and subsequent proofs

<r​ucknium:monero.social> IMHO, node performance should be benchmarked if ring size would increase to 40. It has to pull lots of data from the database when there are a lot more outputs referenced per ring.,

<a​rticmine:monero.social> We have to take advantage of parallel processing on CPU and GPU

<s​gp_:monero.social> yes but that takes time, resources, testing, etc. bumping the fee does not take effort and comes with no network costs

<s​gp_:monero.social> if the network fee was raised to $0.10, the attacker would be spending $300k per month. Just to give you an idea of how much the fee matters for these mitigations

<s​gp_:monero.social> versus today's $11k

<a​rticmine:monero.social> Not necessarily if the ham drops down by a factor of 10

<a​rticmine:monero.social> It is a band aid, not address the issue

<c​haser:monero.social> do you approach it as "delay that bump as much as possible, hopefully hardware and uplink will grow by then"?

<s​gp_:monero.social> chaser: sure, that's part of this. Performance improves over time. Further, FCMP benefits are far greater than a moderate ringsize increases. We get a lot more benefit for the same cost

<a​rticmine:monero.social> Uplink is not an issue, and hardware is heavily underutilized with little or no parallel processing

<s​gp_:monero.social> the cake nodes are already having major issues handling rpc connections fwiw. That can be improved, but not in an immediate fashion

<a​rticmine:monero.social> Take the Monero Nodo for example. These devices have a very personal graphics processor that literally sits idle

<a​rticmine:monero.social> They could not take advantage of parallel processing

<s​gp_:monero.social> no, it's the speed of the monerod locks (and related) that's the issue. The whole blockchain currently needs to be stored in ram

<c​haser:monero.social> yes, FMCP is the silver bullet, the cost is that we can't have it at least for over a year, probably more

<a​rticmine:monero.social> We have to deal with the cause instead of just focusing on the symptoms

<r​ucknium:monero.social> Doesn't the RPC performance have little to do with ring size?

the monero blockchain does not reside in RAM

<s​gp_:monero.social> larger transactions will slow down all connections, read/write, etc

<a​rticmine:monero.social> Monero needs to be run on SSD

<a​rticmine:monero.social> Not HDD

<s​gp_:monero.social> it is an ssd :p

<s​gp_:monero.social> nvme

<s​gp_:monero.social> cake nodes already need ram cache to keep up

monerod locking is the biggest problem there

<s​gp_:monero.social> absolutely

<s​gp_:monero.social> and again, these things can be solved, but not with a snap of our fingers

<s​gp_:monero.social> _unlike the minimum fee_

<a​rticmine:monero.social> Why is it locking

4x will do nothing to a professional adversary

<s​gp_:monero.social> that's how monerod is written

<r​ucknium:monero.social> If there was something like a bitcoin electrum server for Monero, maybe you would not have conflicts: blog.keys.casa/electrum-server-performance-report-2022

because back in the mists of time, when monerod's blockchain was entirely RAM resident, you needed fine-grained locking to be able to use it safely

with LMDB transactions you don't really need that any more, but it's a major rewrite to change the interaction style

<a​rticmine:monero.social> So is this a database issue?

no, the database is lock-free.

it is an interface to the database issue

<s​gp_:monero.social> cake is bottlenecked by the lock implementation currently, yes

<a​rticmine:monero.social> So Monero needs to be optimized

<a​rticmine:monero.social> Monerod

yes

<s​gp_:monero.social> which they can design around, but that will take months of testing or for a completely fresh rewrite

the whole blockchain_db pile of code is fuggly

but it was a shim layer between the memory-only blockchain and the DB-oriented one, so it is heavily compromised in many ways

<s​gp_:monero.social> I agree with articmine that this stuff can be optimized, at that it's good to take advantage of the performance that we have. But, I also think Monero should have much higher fees to discourage attacks like this, and yes, even micropayments

*even micropayments - step back in adoption ?

and how much of increase would be enough ? because i don't believe 4x will do anything to an adversary like this

<r​ucknium:monero.social> I will draw some budget lines and indifference curves :D

<s​gp_:monero.social> thanks rucknium, these are always very useful to use in discussions like these

<g​fdshygti53:monero.social> 10 cents is still reasonable territory imo.

10 cents - if price stays at course

<r​ucknium:monero.social> sgp_: I can't tell if you're serious or not 😁

<r​ucknium:monero.social> I will try to figure out a way to compare these things

if we make changes to the fees and suddently price increases 10x which would not be a sci-fi event - it would grow to $1 USD per tx ?

<s​gp_:monero.social> I know you will :)

<a​rticmine:monero.social> Fees impact both ham and spam. To put it bluntly a crude tool. Furthermore imposing an artificially high node relay fee can cause miners to accept transactions directly. This can be a privacy and decentralizion nightmare

<s​gp_:monero.social> soft fork or hard fork, just like we're discussing now. Unfortunately, that's the way it'll have to be to protect privacy before FCMP

there must be a better tool to deter spam. like a PoW required before submitting a txn

<a​rticmine:monero.social> Also if the ham falls by 10x then we are effectively back at 0.01 USD from a spam cost perspective

<s​gp_:monero.social> yup, and hooray, we would need to adjust again. I don't see another way around it, unless we find some pow thing promising I guess

seems that PoW until FMCP is the way ?

<a​rticmine:monero.social> PoW to submit is even worse. For starters it discriminates against most of the developing world

<s​gp_:monero.social> new plan: everyone needs to have an account at the monero kyc blockchain to send transactions

I suppose it's all the same thing, adding a cost to making txns, whether in monetary fees or in resource costs

<s​gp_:monero.social> :p

<r​ucknium:monero.social> PoW spam prevention didn't really work for Nano. They got spammed anyway and had to change their model.

<s​gp_:monero.social> arguably monero has pow as an option already: mine, get xmr, use that to pay fees :p

<a​rticmine:monero.social> They are mostly in the tropics, while the spammer can launch the attack from a cold place

<a​rticmine:monero.social> Call it the ArticMine attack

we need a surge pricing model that takes network topography into account

to think of it, if adversary can spend 3 XMR per day today, he can surely afford PoW attack

<s​gp_:monero.social> yup, and higher fees will also make a PoW attack more expensive

txns from low volume networks get lower fees

yeah make the fee model so complicated they run away just from seeing it :D

<c​haser:monero.social> I'm sympathetic to that. or maybe a multi-faceted approach that distributes the "pain": moderate txPoW, moderate ring size increase, moderate minimum free increase, and modifying the median parmeters as Artic outlined.

<c​haser:monero.social> how do you mean taking network topo into account?

we can't really do it, since we have dandelion / tor / i2p to anonymize txn origin

<a​rticmine:monero.social> I mean instead of PoW to submit consider an XMR micro burn to submit. At least it is fair to those in the tropics

assuming none of those existed, we could see when large volumes are coming from clustered network addressese, like all coming from OVH, or Linode, or AWS

<c​haser:monero.social> that would be a fair trade-off, but a horrible UX. people shouldn't have to understand this choice and make a decision when they transact

<a​rticmine:monero.social> It exposes the reality. I do agree it is a horrible UX

<c​haser:monero.social> I see. I think taking factors external to the blockchain is a very slippery ground.

attacker would just proxify

I still hope somebody will give submit PoW a bit more thoughts. Over the years we must have spent many person months analysing rings, but almost nothing yet where we could go with that

or use a botnet

sure but that slows them down

<s​gp_:monero.social> it would kill accountless public nodes fwiw

And "It did not work for Nano". Yeah, maybe, but we can do better sometimes. See our "Your can't beat ASICs" breakthrough with RandomX

<a​rticmine:monero.social> Still I have seen nothing better than a ring size increase combined with a 4x increase in the minimum node relay fee below the minimum penalty free blocksize

<s​gp_:monero.social> What if we did >4x min fee increase

realistically - how do these fees compare to a credit card txn fee?

at some point you just have to acknowledge that there is a cost to a well maintained network

<s​gp_:monero.social> with 4x increase and today's prices, that's $46k/mo in fees

<r​ucknium:monero.social> By the way, last meeting I said effective ring size decreases with increased spam in an exponential decay. It is actually hyperbolic decay. The plots look similar.

I don't want to be "only 20% as bad as credit card" for all the hoops you have to jump through with a cryptocurrency

<s​gp_:monero.social> current monero fee per tx starts at $0.0039, or 100x cheaper than a credit card min fee

I react to the thought experiments "What if the fee is 10 US cents"

<s​gp_:monero.social> the US Fed is proposing a cut of the debit card fees to 14.4 cents per transaction

<a​rticmine:monero.social> It is a partial solution, which can be implemented without a hard fork

I really don't want to take any of that as a yardstick. "Look how much worse credit cards still are". Yikes.

<a​rticmine:monero.social> Just do a fee modification

<s​gp_:monero.social> I think it's a reasonable upper bound to consider, even if the ideal is much less than that if there were no spammers

<a​rticmine:monero.social> Credit card fees are a real mess. Even worse when hidden exchange rate surcharges are factored in

what if the "attack" keeps on going after increasing the fee x4 ?

<a​rticmine:monero.social> Certainly not what I would use as a standard

at what point should we consider it organic ? after fee is increased to 10$ usd ?

<s​gp_:monero.social> does anyone oppose to $0.10 fee as a sanity check?

Just look at an all-time chart and stop telling it's organic: bitinfocharts.com/comparison/monero-transactions.html#alltime

<c​haser:monero.social> doing it without a hard fork could have minimal effects. people may just not update to the point release. even with a hard fork, if it's only the relay fee, an attacker can coordinate with a pool (send them their tx's). if there is a fee increase, it should happen on the protocol-level.

<s​gp_:monero.social> not as an actual proposal, but "this is roughly in the 'feels correct' territory"

<r​ucknium:monero.social> $0.10 fee/tx is too high IMHO

No one anywhere is posting on "how to download a wallet", so we don't have many new users now

<s​gp_:monero.social> Rucknium why do you feel it is too high?

If we have to raise fees to 0.10 US cents per transactions to keep a reasonable level of privacy, IHMO we have simply lost.

<a​rticmine:monero.social> I agree

at 10 cents it's 10% of a 1$ coffee

pure rage

Fee increase is a dangerous thing to do

<r​ucknium:monero.social> We can ask Monero users in Argentina.

When price pumps 10x, you will hardfork again to decrease fees?

You mean with a fee explosion we make many new friends there?

<a​rticmine:monero.social> Good point

<s​gp_:monero.social> sec1: there must be an implied value of XMR before FCMP, it's unavoidable

sech1 - switch to log view, we had many events like this

and add to this the current big exchange delisting

<s​gp_:monero.social> clearly we made an assumption about the price of XMR right now and it was too low

all previous events had news linked to them, like Alphabay starting using Monero

<s​gp_:monero.social> the relationship between blocksize and XMR value did not correlate as articmine had hoped

Big exchange delisting and transactions spike didn't happen on the same day

<r​ucknium:monero.social> The skepticism about the spam hypothesis just means it's in my research agenda :). mitchellpkt.medium.com/fingerprinti…ero-transaction-volume-a19cbf41ce60

sech1 - didn't happen the same day because of the price drop, people were scared it will go to zero

after dust settled people came back

<s​gp_:monero.social> regarding the $0.10 is too expensive for people in some countries, unfortunately I don't know how we can possibly plan around accommodating this

<r​ucknium:monero.social> But first: Assume it's a black marble flood and measure potential impacts and options. Then evaluate the spam hypothesis empirically.

<s​gp_:monero.social> even if we don't hike the fees and the attacker keeps spamming, then users will still be priced out since their transactions have too low of a fee to be confirmed

Binance has closed withdrawals most of the time, they couldn't physically release so many coins to so many users, so I don't believe this connection

large amount of people could use Binance to trade between themself without actually doing it on the chain

<s​gp_:monero.social> the transaction fee will always need to be anchored in real network costs, irrespective of one's ability to afford the transaction fee

We could also think a bit about our limited dev time budget. Every person week going into battling this moves Seraphis/Jamtis and FCMPs further out

<c​haser:monero.social> I'm not, but I do oppose gauging protocol parameters in dollars. XMRUSD may halve or 5x in a year.

And Seraphis has a much higher ringsize more "naturally"

azunda to move from Binance to on-chain, they first need to withdraw and withdrawals are nowhere near at the capacity needed for this flood

<a​rticmine:monero.social> The delisting by Binance eliminated a very significant centralized ledger where settlement of XMR was occurring. This is not unlike what has happened with Bitcoin where centralized ledger settlement has taken over

asticmine same, read my message

You both don't understand that it's just not enough coins there to provide all this flood

Numbers don't add up, so maybe 1-2k transactions per day come from Binance refugees, but not more

And all of a sudden almost magically most people only produce 1 in, 2 out transactions. Nice fairy tale, IMHO.

<s​gp_:monero.social> agreed, this is one of the biggest signs. All 1in/2out is impossible to reconcile at this scale

I understand people want to believe in sudden 5x adoption, but reality is more likely to be some spam

<a​rticmine:monero.social> Actually looks at the surge just when Binance delisted. It is close to double

withdrawals were closed but not incoming transactions

they could still do business

now they do it outside

<s​gp_:monero.social> sech1: why are you against raising fees?

because fees are fine?

<a​rticmine:monero.social> bitinfocharts.com/comparison/monero-transactions.html#3m

Compare to BTC fees (in BTC terms vs XMR fees in XMR terms)

azunda, go a bit back in time and look carefully at block before this attack, how transaction sizes vary if they are "organic"

they're literally the same

you raise fees today, few years down the road you have to drop them because price pumped 10x

stupid

<s​gp_:monero.social> what do you mean fees are fine? fees are supposed to discourage this behavior. Pricing where BTC == XMR makes no sense to me, since the attacker isn't acquiring at those BTC costs

I mean it's a stupid thing to do every time something happens

<s​gp_:monero.social> it's not stupid because the alternative is not having an adequate deterrent

<s​gp_:monero.social> I 100% agree it's shitty

<s​gp_:monero.social> but what else is realistic? not having a deterrent? that's even worse

if it's one or couple more big players that started using some automated tools, the tx could have patterns ?

Really not sure about "no adequate deterrent". They spam well below their technical capacity, no?

If it's a big resourseful attacker, believe me 10x fees won't help

<r​ucknium:monero.social> I plotted the daily tx volume of txs with the "spam fingerprint" (1in/2out 20 nanoneros/byte) in Feb and March 2024: github.com/Rucknium/misc-research/b…ages/spam-fingerprint-tx-volume.png

Bigger ring size could help better

<r​ucknium:monero.social> From about 15,000 to 100,000 in about a day.

<s​gp_:monero.social> we need to draw the line somewhere, else we should just roll out the "we're fucked" map

<c​haser:monero.social> that was a 50% surge which then quickly ended.

<s​gp_:monero.social> bigger ringsize is a similar lever as higher fees, but with more network costs

Plus I'm against raising fees because it will screw up p2pool miners big time

Not until there is a cheap way to consolidate p2pool payouts

i.e. coinbase outputs

<s​gp_:monero.social> that's the real reason you hate it; is there no way to give people fewer, larger outputs?

That's the main reason but not the only one

the USD price is the other one

<r​ucknium:monero.social> IMHO, when (if) ring size increases in next hard fork, make all coinbase output spends ringless like MRL issue #...

if this is an attack, we would need to increase the fee 100x - that's not "ideal".

to even make a dent

You can't just change fees because price is low and fees are cheap. Next you'll have to change them all the time to fit a new XMR price

<s​gp_:monero.social> the ideal state is not being under attack lol. But given we're here, we need to compromise on something

<r​ucknium:monero.social> This one: monero-project/research-lab #108 "Coinbase Consolidation Tx Type"

<s​gp_:monero.social> and I'm begging you all for the compromise to not be massive transactions because we can't agree to make transactions more expensive

With the danger of being a heretic: We do not "have to" do something. I can live with ringsize 5.5 and the danger they will spam more until Seraphis and FCMPs.

sgp pushing hard on fee increase

<a​rticmine:monero.social> It targets the spam and not the ham

is there a hidden agenda ? /s :D

Given the "shitty" alternatives

Transaction sizes will increase with Seraphis anyway, so why not increase ring size a little before that?

<s​gp_:monero.social> I don't know what you mean by ham, but fees literally target the spammer directly by requiring them to pay more, without costs to nodes. And it also benefits miners (p2pool mini dust outputs aside)

Not to forget that we always only talk about 1 out of 3 privacy mechanisms ...

<s​gp_:monero.social> as I said before, I'm not against a ringsize increase. But I am begging you to additionally hike the fees

<a​rticmine:monero.social> Ham legit transactions as opposed to spam

<s​gp_:monero.social> zunda: you must be new here; I've been a (the?) major proponent of most ringsize increases haha

<s​gp_:monero.social> azunda: you must be new here; I've been a (the?) major proponent of most ringsize increases haha

If ring size increase will reduce the efficiency of the spam attack, why increase the fees then?

<s​gp_:monero.social> because fees arguable reduce the efficiency even more

<s​gp_:monero.social> because fees arguably reduce the efficiency even more

i'm from the very beginning, had different names.

Not against an attacker who presumably has huge resources

<s​gp_:monero.social> sech1, if the attacker has near unlimited resources, then a larger ring won't do anything either

we should assume that attacker has close to "infinite" recources when it comes to fees

nor increased fees

<s​gp_:monero.social> they'll just hike their fees and take a higher ratio to account for the stronger ringsize protections

increased fees will only reduce legit on-chain activity, and spam tx will stay the same

<s​gp_:monero.social> which is why we need to accept that they don't have unlimited resources, or else we would need to admit this is all pointless

seems like an attack, on adoption by forcing devs to increase the fee.

if they can afford 3 XMR today, they can afford x4 easily too

Yes "unlimited resources" will overpower everything, that's not a reasonable base for discussion

<s​gp_:monero.social> anyway, I've made my same points three times now. It's clear that most people here would rather have massive transactions than hike the fee to still-reasonable-levels

how long the attacker could sustain the attack while having "just" 1 Mil USD ?

<r​ucknium:monero.social> Ring size 40 is 5.5 Kb for 2in/2out, right? Not massive IMHO.

after increase of the fees

<s​nowman:tetaneutral.net> Fee increase does nothing against an attacker with infinite money to spend. Fcmp, keep devs focused and keep moving forward is the only answer.

Secretely I almost start to hope that our decision process will sort-of-deadlock like it did regarding tx_extra stay/remove, and we just do nothing.

<s​gp_:monero.social> that's over a 2x size increase, no?

<r​ucknium:monero.social> Yes, we are in the 3rd hour of the "meeting". We have run out of new points to make with the current information available.

<r​ucknium:monero.social> yes. Only 2x

I think it's more of a psychological attack than a real black marble attack

<a​lex:agoradesk.com> Guys, let's discuss other solutions please. The fee increase bandaid is pointless in my opinion. I would rather the Monero general fund spend 3 XMR per day to counter-spam and thereby dilute the effect of the attacker until FCMP is deployed.

it's not intensive enough to deanonymize most rings

forcing devs to "do something"

<s​nowman:tetaneutral.net> Agreed

<a​lex:agoradesk.com> sech1 is correct, and so is rbrunner, there is no forced action here.

<a​rticmine:monero.social> I proposed increasing the reference transaction size from 3000 bytes to 8000 bytes, but only increasing the minimum penalty free blocksize from 300000 bytes to 400000 bytes. This requires an increase in the minimum node relay fee of 4x

<a​rticmine:monero.social> The 8000 byte figure is to accommodate full membership proofs with tx sizes around 5500 bytes vs around 2000 bytes now

if price of Monero goes up by 10x the new fee would be painful to some

<a​lex:agoradesk.com> Just raising the fees based on an arbitrary American's understanding of what's reasonable is not how things should be done in Monero.

<a​rticmine:monero.social> As an interim solution this can also accommodate a ring size of 40 or even more

<s​nowman:tetaneutral.net> Can we tie ring size dynamically to spam

<a​rticmine:monero.social> No

due to uniformity problem or other technical problem ?

<c​haser:monero.social> we don't know that.

<a​lex:agoradesk.com> I prefer ArcticMine's solution, but honestly I don't think this is an urgent situation. I think counterspamming until FCMP comes is something people who are worried about this should do. This doesn't require any hardforks or deployments.

the organic growth we had will counter attack the adversary (if it's adversary) more and more

<r​ucknium:monero.social> Uncoordinated counterspam is hard to stop. How do the counterspammers know that the malicious flood is finished?

time is on our side

<a​lex:agoradesk.com> They don't. But after FCMP it doesn't matter.

<a​lex:agoradesk.com> Additionally, counterspammers can declare on /r/Monero that we stop counterspamming for a day to see if the attack subsided.

<a​lex:agoradesk.com> The fundamental issue here is not going to be solved until FCMP, no matter how many bandaids you apply.

<r​ucknium:monero.social> Alex | LocalMonero | AgoraDesk: "The fundamental issue here..." I agree.

<a​rticmine:monero.social> There is also the possibility of multiple black marble attackers working against each other. This attack only works with only one spammer

<r​ucknium:monero.social> (It's a live system and people depend on it for privacy now FWIW.)

<c​haser:monero.social> yes, as was stated last time, we're looking for the least bad strategy (in case we're looking at all)

<a​lex:agoradesk.com> Does anybody want to start a counterspam task force? Let's make a group and coordinate this. PM me.

burn 3xmrday on tx spam or fund FCMP development with it

<a​lex:agoradesk.com> AFAIK, FCMP development doesn't lack funding.

what we really need is more adoption, this attacks would be worthless if we had 100x more real tx

plowsof: why not both?

<c​haser:monero.social> that is very unwise, for the reasons I outlined in my summary on Github. you don't want to make Monero's privacy depend on the unverifiable altruistic actions of trusted parties. moreover, you don't want Monero to be *seen* like that. it would create a disastrous reputation, which would also reflect in the price.

<a​lex:agoradesk.com> Like it or not, rings are a weak point of XMR and have been for a while.

<a​rticmine:monero.social> That is my understanding. If I understand correctly ring 40 would also significantly mitigate the spam. So this looks like a valid option

<a​lex:agoradesk.com> If you're worried about the marbles, without FCMP, this is one solution.

localmonero should fund a tumbler address then. every piconero sent to it will be churned over and over. it can have a vanity address "Sp4mt4skforce"

increasing it was the best idea so far but i would leave fee alone as increasing them by 4x or even 10x will do nothing to let's say chainalysis company that earns millions of dollars

and it will only harm adoption which fixes this

*increasing ring size

as articmine suggested

<c​haser:monero.social> I asked last summer if it lacked talent; the answer was no.

<s​nowman:tetaneutral.net> Has there been any effort to reach out to cake, changenow, trocador, localmonero to see if there is any significant bump in usage since binance delisting

<r​ucknium:monero.social> Yes FCMP needs more talented labour.

<r​ucknium:monero.social> Having capital does not mean that you have labour.

<1​23bob123:matrix.org> Torcador just ask morpheus

<1​23bob123:matrix.org> Not in this room tho

<a​lex:agoradesk.com> Assuming that yes, it still doesn't explain away the 1 in/2out flood.

<s​gp_:monero.social> a​zunda: you realize a >2x increase in the transaction size also means an implied >2x increase in Monero fees right? Just making sure

<c​haser:monero.social> I posted charts of Bisq daily trade numbers and volume in the #monero-research-lounge:monero.social . there is nothing there that would explain this volume (not that it would matter).

<s​gp_:monero.social> a​zunda: you realize a >2x increase in the transaction size also means an implied >2x increase in Monero fees per transaction right? Just making sure

yes

<a​rticmine:monero.social> Not if you increase the minimum penalty free blocksize by the same amount..

nice

<s​gp_:monero.social> ArticMine: I really hope you ask for Cake's opinion before you double node requirements lol. Their monthly node cost is already thousands of dollars. They already move over 200 TB/mo

sgp - and how much do they earn ?

it's probably a fraction of their income...

*small fraction

<a​rticmine:monero.social> In my proposal the minimum penalty free zone would be increased by half. So in terms of the current penalty free blocksize this is equivalent to 150000 bytes. With quadratic scaling the fee would fall back to the current at 300000 bytes equivalent or 800000 bytes.

so on one hand we have a company that earns a lot of money to pay a bit more for their servers and on the other hand ALL users of Monero

<r​ucknium:monero.social> I don't think we know how increasing ring size affects remote node performance. How much of the ring sig data actually needs to be sent to wallets?

<c​haser:monero.social> not that I wish ill on Cake, but calibrating the protocol according to the needs of large centralized RPC providers is quite against the ethos of decentralization.

<r​ucknium:monero.social> Pruning eliminates most rig sig data and it is not supposed to affect wallet operation at all.

<r​ucknium:monero.social> If you need to keep the whole blockchain in RAM, prune the node in RAM.

<s​gp_:monero.social> so we can assume roughly 50% more p2p traffic with this proposal?

<s​gp_:monero.social> unless there's something else I'm missing

<a​rticmine:monero.social> A better solution in my view is to optimize monerod and support large scale parallel processing on CPU and GPU. This will help all users both large and small

<r​ucknium:monero.social> boog900, hinto , SyntheticBird45 : Any comments about how cuprate plans to parallelize?

<a​rticmine:monero.social> It is 2.5x in bandwidth, and the same as expected for FCMP

<a​rticmine:monero.social> FCMP

<s​gp_:monero.social> the issue is that cake can't whip up a custom, prod-ready lmdb reader in a week. In time for FCMP, sure

<a​rticmine:monero.social> This hard fork will not happen in a week. Seriously

<r​ucknium:monero.social> ArticMine: When you have a range of fee and blocksize adjustment options available, I can do some modeling.

<b​oog900:monero.social> better and we will have no locks for RPC requests.

<b​oog900:monero.social> For my last CCS while I was implementing Monero's consensus rules in Cuprate I made an RPC scanner to test them, it gets data like outputs from public node's RPC. I ran it side by side with monerod doing full verification and the RPC scanner completed first around 170,000 blocks ahead

<a​rticmine:monero.social> 👍

<b​oog900:monero.social> monerod was ahead until RCT and then the RPC scanner started to catch up, over taking around block `2428000`

<c​haser:monero.social> that's great news. for scanning speed, is that number relevant though (blocks per full chain scan)? wouldn't a metric like "tx type 6 rings per second" be more descriptive?

<g​ingeropolous:monero.social> some thoughts as im reading through logs. re: raising the fence. adding a tx-pow might do stuff. oh i see rbrunner7 brought that up. And yeah, somehow hooking the PoW difficulty into tx_pool size could be interesting. I share the concern about "real" fees re: the need to have lots of ham for monero's ring sigs to work right. And yeah Rucknium , i've talked about tieing fees to h<clipped me

<g​ingeropolous:monero.social> ashpower. i personally think hashrate is closes we can get to a within-chain metric of monero's extrinsic value. ArticMine , how does PoW to submit discriminate against most of the developing world? I'd imagine the PoW requirement for a single tx would be minimal, but if we could somehow find a way to connect the PoW requirement to volume. Perhaps its at the peer level. I.e., I al<clipped me

<g​ingeropolous:monero.social> ready received a transaction from this peer within the past 10 usec. I need a higher PoW to receive another.

<b​oog900:monero.social> Those exact numbers don't really mean anything more just the point that we are requesting outputs for rings over RPC and we completing verification faster than monerod getting them locally and that monerod becomes significantly slower around RCT.

<b​oog900:monero.social> We don't have a working database yet so until then I don't think any measurements of how fast we can verify txs will be completely accurate. I am planning to bench Cuprate vs monerod more thoroughly though when more is done.

<w​izeguyy:tchncs.de> I realize I'm late to the party, but this has been discussed elsewhere. Network difficulty serves as a responsive and trustless Oracle to the purchasing power of the coins. You should consider setting fee as a function of difficulty

<c​haserene:matrix.org> it is being considered, with the latest mention two messages before yours (hash power and difficulty are highly positively correlated). it looks like now a good deal of the messages from monero.social users are making it through to the matrix.org home server, but maybe some earlier mentions are not visible to you.

<w​izeguyy:tchncs.de> Ah great. Sorry for the noise then 😅

<r​ucknium:monero.social> A really rough draft of my initial privacy impact estimates of the suspected black marble flooding: rucknium.me/html/monero-black-marble-flood.pdf

<r​ucknium:monero.social> It's basically a writeup of the methodology for the plots I shared earlier. This version will be accessible at that link for about 24 hours.

<a​rticmine:monero.social> Thanks for the preview.

<a​rticmine:monero.social> 1) The cost of PoW is dependent on the ambient temperature. This is a common misconception regarding PoW. People do not take the cost or value of the heat produced into account. Most developing countries are at or near the tropics.

<a​rticmine:monero.social> 2) The processing impact is going to be higher on older less capable devices. Again this is more prevalent in poorer developing countries.

<a​rticmine:monero.social> The attacker can on the other hand launch the spam from a cold developed country. Canada comes to mind. So think of this as the ArticMine attack. It works best when it is nice and cold. Say -40

<a​rticmine:monero.social> C or F

<a​rticmine:monero.social> The spammer stays warm using the heat produced by the attack in face of the very cold temperatures

<c​haser:monero.social> that was an enlightening part of your Monerotopia interview: the way the current protocol provides security is very energy-efficient (the only parties doing PoW are specialized and can be at the most efficient locations, regardless of where users are). but I want to point out that in a protocol with txPoW, the reasons for hashing aren't the same: miners hash for the block reward a<clipped message>

<c​haser:monero.social> nd fees above penalty; senders hash for inclusion. you can't offload txPoW to miners; the practical equivalent would be to simply raise fees.

<j​ack_ma_blabla:matrix.org> it would be a sci-fi event

<j​ack_ma_blabla:matrix.org> Proof of Work (PoW) on mobile devices? How many transactions per second does the attacker need to perform right now? And how many VPS can easily handle it? It's absurdly easy to scale for an attacker. Unless you want mobile users to do PoW for a few hours before they can broadcast a transaction.

<g​ingeropolous:monero.social> yeah, they stay warm but they get extremely throttled. and/or they have to own a lot of IPs (of course, ipv6 or i2p/tor negates this). meanwhile someone in the tropics doesn't need to hit as high a diff, because the node that receives their transaction hasn't seen a tx from that IP yet. a lot of moving parts with that one though

<g​ingeropolous:monero.social> i think you could tie it to peer ID. Node A goes "man, there are a lot of txs coming from Peer B. I'm going to only accept txs from B if they submit a higher difficulty"

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/eenMzjFuRGnlzhUJnjllEnSu

<g​fdshygti53:monero.social> We might have a TX stuck in the mempool since ~40 minutes

<g​fdshygti53:monero.social> weird

<g​ingeropolous:monero.social> wheres the data pulled from

<g​fdshygti53:monero.social> My public node

<g​ingeropolous:monero.social> so node A goes "OK, i'll remake the package with a higher diff" and then sends it.

<c​haser:monero.social> ok, let's note we are talking about two distinct txPoW designs:

<c​haser:monero.social> 1. one is enforced on the network level, tied to node identities

<c​haser:monero.social> 2. the other enforced on the protocol level (I have been referring to this so far)

<c​haser:monero.social> network-level txPoW offers some interesting options (e.g. for wallets that use RPC providers, the provider could take on the burden of the txPow). however, just like with the minimum node relay fee, this can be circumvented by a black marble attacker by colluding with the mining pools.

<g​ingeropolous:monero.social> of course, if thats the case, node B would know that node A was the originator of the tx

<g​ingeropolous:monero.social> but a standard operation of a node would be to repackage some transactions that get kicked back

<g​ingeropolous:monero.social> i think this ends up being a graph theory thing

<g​ingeropolous:monero.social> how did neo do it or whatever the coin was

<g​ingeropolous:monero.social> did they have any fancy stuff?

<g​ingeropolous:monero.social> chaser: , ah, protocol level. yeah that could make sense too.

<g​ingeropolous:monero.social> honestly the "colluding with mining pools" is like... well, nothing holds together with that branch of logic

<g​ingeropolous:monero.social> regarding a PoW-based blockchain cryptocurrency network. IMO.

<c​haser:monero.social> why doesn't it? in the standard Nakamoto setting, which applies to Monero too, miners are solely interested in turning their expenditure on hardware and electricity to money, in the way that provides the widest profit margin. they couldn't care less about the ethos of a network, its health, its community or any such factor. we are not at the mercy, nor under the protection, of miners.