<r​avfx:xmr.mx> Yeah. Monero hash rate renting went exponential

<r​avfx:xmr.mx> One provider wend from ~30Mh/s wedndesday, to ~300Mh/s this weekend. No idea who is renting, good guys or Qubit assholes...

<1​7lifers:matrix.org> high number = celebrate

<m​onerobull:matrix.org> hey, does anyone know why this one is not mined after over 5 hours in the mempool?

<m​onerobull:matrix.org> xmrchain.net/tx/d6de63a33a073c1c5cb…bc1a90a161d9e8dac665036e164fe127516

<b​oog900:monero.social> Probably a double spend

<m​onerobull:matrix.org> Ah yeah that would explain it

<m​onerobull:matrix.org> But wouldn't the xmrchain node discard it?

<b​oog900:monero.social> monerod doesn't, Cuprate does :)

<b​oog900:monero.social> If the node receives a block with a tx that double spends a tx in its pool monerod won't drop the tx in the pool

<m​onerobull:matrix.org> What's the current rough eta before cuprate is production ready for use with my wallets?

<k​ayabanerve:matrix.org> Qubic SHOULD have RBF, fite me :C

<b​oog900:monero.social> Hopefully the RPC is ready within a few months, a stable release won't be for a while yet.

<k​ayabanerve:matrix.org> *Cuprate

<k​ayabanerve:matrix.org> Not qubic

<b​oog900:monero.social> Once we have the RPC interface you can test with wallets

<s​yntheticbird:monero.social> I'm ready to fight even tho idk the implications of RBF

<k​ayabanerve:matrix.org> Sorry, I'm still quite tired and was reading through the above on *someone* renting hash rate 😅

<m​onerobull:matrix.org> Rbf kills the digital cash usecase

<b​oog900:monero.social> Mining on cuprate won't be recommended until we are stable, so would be wasted until then

<k​ayabanerve:matrix.org> Eh, it makes 0-conf 'less secure'

<m​onerobull:matrix.org> It makes them completely insecure

<m​onerobull:matrix.org> Right now they are secure enough for small in-person payments

<k​ayabanerve:matrix.org> Prior, you could simultaneously send two TXs to netsplit the view of the mempool and have a 50% chance of your TX being the one seen by the store (and a distinct 50% chance of being the one mined)

<m​onerobull:matrix.org> With Rbf it gets way too easy to "double spend"

<k​ayabanerve:matrix.org> With RBF, you can guarantee the ordering so long as a block isn't mined before a store recognizes acceptance

<k​ayabanerve:matrix.org> (Assuming the store doesn't run several nodes with anonynous IPs and geographic distribution, cross-checking their mempools to try and find any potential double spends)

<k​ayabanerve:matrix.org> Oh no, something that has a 25% chance of working by anyone who bothers now has a 90% chance of working

<k​ayabanerve:matrix.org> Our insecure idea is even more obviously insecure

<k​ayabanerve:matrix.org> The horror

<m​onerobull:matrix.org> It's a compromise

<m​onerobull:matrix.org> But we don't have to kill it

<k​ayabanerve:matrix.org> 0-conf TXs are a 25% off discount at every store which accepts them, fite me :C

<m​onerobull:matrix.org> Kayaba do you support gun control

<k​ayabanerve:matrix.org> *it's even better if you can send the TX to yourself directly to the major pools, solely sending the TX to the store to other nodes.

<m​onerobull:matrix.org> We don't hand everyone a gun either

<k​ayabanerve:matrix.org> You can get the existing odds to around 90% with a sufficient map of the network.

<b​oog900:monero.social> If you target mining nodes with one tx and other nodes with the other you could probably pull this off with a better probability

<k​ayabanerve:matrix.org> All RBF does is remove the requirement of such a decent map.

<m​onerobull:matrix.org> You can also 3d print your own guns but most people won't bother due to the effort involved

<m​onerobull:matrix.org> Doesn't mean we should openly sell the parts to everyone because "you can also just print them"

<k​ayabanerve:matrix.org> monerobull: I don't think I'd support banning giving guns out on the street if there's a store nearby you can just walk into and get a gun. The existence of a simple door doesn't make a difference IRL.

<k​ayabanerve:matrix.org> Make 0-conf secure or don't use insecure technology

<m​onerobull:matrix.org> People did literally just fraud when they heard of the chase "glitch", because they could

<m​onerobull:matrix.org> If it required filling out a form and a bunch of extra effort, barely anyone would have done that

<m​onerobull:matrix.org> But if it's just two buttons to do the fraud, enough people will be stupid enough to try it

<k​ayabanerve:matrix.org> You realize my concern is with sellers, right?

<k​ayabanerve:matrix.org> Promoting zero-conf is promoting 25-90% off by anyone who cares enough

<m​onerobull:matrix.org> Zero conf is useful for in-person payments and gambling on blockhashes, not much else

<m​onerobull:matrix.org> But for the in-person payments is very useful

<k​ayabanerve:matrix.org> We shouldn't advertise, promote, or enable insecure bs IMO

<m​onerobull:matrix.org> The likelihood that someone will try and rip you off is super low

<k​ayabanerve:matrix.org> RBF is useful

<k​ayabanerve:matrix.org> RBF isn't insecure

<m​onerobull:matrix.org> So are zero conf payments

<k​ayabanerve:matrix.org> Those are insecure though

<m​onerobull:matrix.org> You don't need 100% security on zero conf payments.

<s​yntheticbird:monero.social> kayabanerve be like:

<s​yntheticbird:monero.social> "This is completely insecure and utter shit... Here's why we should think about it for Monero!"

<k​ayabanerve:matrix.org> Go build a PCN

<s​yntheticbird:monero.social> kayabanerve be like:

<s​yntheticbird:monero.social> "This is completely insecure and utter shit... Here's why we should think about it for Monero..."

<m​onerobull:matrix.org> But you absolutely need zero conf to enable smooth in person payments

<m​onerobull:matrix.org> It's a compromise

<k​ayabanerve:matrix.org> Or a PC

<m​onerobull:matrix.org> Monero also compromises on scaling to have better privacy

<s​yntheticbird:monero.social> this

<k​ayabanerve:matrix.org> Or confirmations with latency of less than 10s

<s​yntheticbird:monero.social> VISA is great

<m​onerobull:matrix.org> Here we compromise on zero conf security to make payments instant

<m​onerobull:matrix.org> With reasonable efforts involved to abuse

<k​ayabanerve:matrix.org> SyntheticBird: if re: TEEs, those would've been a layer, not a premise.

<k​ayabanerve:matrix.org> The proper solution is a PC mb

<m​onerobull:matrix.org> A what

<s​yntheticbird:monero.social> I wasn't referring to TEE but thx anw

<k​ayabanerve:matrix.org> Payment channel

<m​onerobull:matrix.org> Ah

<s​yntheticbird:monero.social> aka VISA

<k​ayabanerve:matrix.org> Oh, then what else were you referring to?

<m​onerobull:matrix.org> But what about one-off payments? What benefits would Rbf actually give us? Seems like more downsides than upsides

<s​yntheticbird:monero.social> well this rbf discussion

<k​ayabanerve:matrix.org> PCN mb

<s​yntheticbird:monero.social> also R1CS proposal

<s​yntheticbird:monero.social> i think you said you really disliked it yet made a detailed and appreciated explanations on mrl github

<k​ayabanerve:matrix.org> SB: But I'm saying 0-conf is insecure so we shouldn't think about it

<s​yntheticbird:monero.social> oh my bad im confused

<m​onerobull:matrix.org> Payment channels?

<m​onerobull:matrix.org> Or what does the N add

<s​yntheticbird:monero.social> network

<s​yntheticbird:monero.social> payment channel network

<k​ayabanerve:matrix.org> Yeah SB, it was TEEs and I said insecure but should consider lol

<k​ayabanerve:matrix.org> mb: Network. You don't need a direct connection and can make one-off payments given any indirect route.

<m​onerobull:matrix.org> Why do those require rbf? To do bidding wars in case there is contestation?

<k​ayabanerve:matrix.org> They don't?

<k​ayabanerve:matrix.org> Well, they might, see how much of a fuck up LN has been

<k​ayabanerve:matrix.org> But I'm separately calling for RBF

<k​ayabanerve:matrix.org> I just like RBF

<k​ayabanerve:matrix.org> Fee bumping is good

<m​onerobull:matrix.org> I specifically asked for the benefits of Rbf ?:3

<k​ayabanerve:matrix.org> I think I have a dedicated issue to discuss 'anyone-can-bump' fees...

<k​ayabanerve:matrix.org> Fee bumping.

<m​onerobull:matrix.org> I mean I kinda get it

<k​ayabanerve:matrix.org> I support my R1CS proposal long-term, and I support PCN-support long-term SB.

<m​onerobull:matrix.org> Sucks when there is a backlog and your tx is stuck for an entire day

<s​yntheticbird:monero.social> isn't this in complete opposition with the fee discretization proposal

<m​onerobull:matrix.org> But I appreciate the relative security of zero conf as it is right now

<k​ayabanerve:matrix.org> We just need competent designs to agree on, the bandwidth for it, and the proper timeline.

<k​ayabanerve:matrix.org> No, even with discretization, there'd be prioritization.

<m​onerobull:matrix.org> When I receive a payment, I can tell the other person "got it" as soon as I see it in my wallet

<m​onerobull:matrix.org> I don't want to worst case wait 20 minutes for the first conf

<k​ayabanerve:matrix.org> We can give each TX a canonical, in-consensus weight, as we currently do (but don't technically need to make TXs)

<k​ayabanerve:matrix.org> And then require the prioritization value be from 0 .. 32.

<k​ayabanerve:matrix.org> That's the exponent such that the fee paid is 2**prioritization * weight.

<k​ayabanerve:matrix.org> That also inherently bans zero-fee TXs, which is an interesting anecdote.

<m​onerobull:matrix.org> You want fee bumping for serai right

<m​onerobull:matrix.org> Bcs it's more structured, I understand that

<k​ayabanerve:matrix.org> Uhhhh

<k​ayabanerve:matrix.org> I mean, I want in general.

<k​ayabanerve:matrix.org> I'm not on a crusade to impl it with the HF.

<k​ayabanerve:matrix.org> My 'pushing' for it is just saying "RBF good" anytime it comes up

<k​ayabanerve:matrix.org> But yeah, it'd notably help multisig UX and Serai

<k​ayabanerve:matrix.org> But only if fee bumping is non-interactive

<k​ayabanerve:matrix.org> RBF doesn't enable non-interactive fee bumping

<m​onerobull:matrix.org> Non interactive meaning everyone can bump it?

<k​ayabanerve:matrix.org> monero-project/research-lab #128

<k​ayabanerve:matrix.org> Yeah

<m​onerobull:matrix.org> Interesting

<m​onerobull:matrix.org> And you are saying PCN would "solve" the "one-off in-person" usecase

<m​onerobull:matrix.org> LN has been such a massive failure, I don't know about that

<s​yntheticbird:monero.social> LN is like the first to be deployed and practically only PCN

<s​yntheticbird:monero.social> it was advertised as experimental

<s​yntheticbird:monero.social> yet fanatics started using it like this was production ready

<s​yntheticbird:monero.social> PCN aren't bad

<k​ayabanerve:matrix.org> They also didn't deploy it on Ethereum

<s​yntheticbird:monero.social> there are better designs than LN

<k​ayabanerve:matrix.org> They deployed it on Bitcoin

<k​ayabanerve:matrix.org> My PCN issue proposes a hard fork to support a PCN

<s​yntheticbird:monero.social> and i fully support it, when are taking the weapons

<k​ayabanerve:matrix.org> Not cramming one into what exists + a general purpose soft fork that's presumed sufficient but also doesn't go all the way as it's 'general purpose'

<k​ayabanerve:matrix.org> I don't quite propose enshrining the PCN?

<k​ayabanerve:matrix.org> But see how Bitcoin hadn't adopted the covenant-esque solution named after Lightning. Bitcoin devs aren't adding whatever Lightning needs to be its best self.

<k​ayabanerve:matrix.org> And that's fair, keeping Bitcoin neutral and all

<k​ayabanerve:matrix.org> But my PCN issue did propose explicitly adding full support for a generally agreed upon design

<k​ayabanerve:matrix.org> So hopefully, we can achieve better results, especially with years of existing theory to build on

<o​frnxmr:xmr.mx> its not like rbf would have to be mandatory. You could, as a merchant, require 1 conf for txs that have rbf enabled

<k​ayabanerve:matrix.org> Also, the more I gaslight everyone into believing my solution is correct, the more I get everyone to be quiet about solutions I arbitrarily dislike

<k​ayabanerve:matrix.org> mb: You support 0-conf. Is this related to your support of requiring KYC to access Wikipedia?

<k​ayabanerve:matrix.org> /s :p

<k​ayabanerve:matrix.org> Like obviously, I'm making the point I'm not perfect and in charge lol. There's a reason Monero doesn't have RBF today and that fee bumping issue is likely a better overall solution for my issues (and doesn't conflict with 0-conf as it requires a matching output set).

<k​ayabanerve:matrix.org> It also isn't that important to me as I haven't done anything to promote that issue in months lol

<k​ayabanerve:matrix.org> So take everything here with a grain of salt

<k​ayabanerve:matrix.org> But even if the sole benefit of RBF is it stops people from using 0-conf, I support it, heyoooo

<m​onerobull:matrix.org> someone on reddit said i am against auditing code because i told them its silly to spend millions on auditing haveno (because the cryptography is done by wallet2 anyways)

<k​ayabanerve:matrix.org> ofrnxmr @ofrnxmr:xmr.mx: TX uniformity requires all TXs have RBF or none :/

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/MwdcpliGxCUrPdNdmXaBHdtR

<m​onerobull:matrix.org> this made me so mad >:(

<m​onerobull:matrix.org> nOtEd fReN

<o​frnxmr:xmr.mx> But in ringct, txs arent uniform 😂. Also, we dont have uniform fees

<k​ayabanerve:matrix.org> Also, these designs do complicate the mempool. If we have fee bumping, we have to only accept non-conflicting TXs into the mempool (as current policy) and then distinctly denote TXs which bump the fees. That way, if a fee bumping TX conflicts with another fee bumping TX, one gets mined and for the other, we revert back to its non-bumped version.

<k​ayabanerve:matrix.org> We also have to cover the edge case we receive the fee bump TX before the base TX, and code logic to re-define the base TX.

<o​frnxmr:xmr.mx> Would be nice if we could reject txs that arent following the fee tiers

<k​ayabanerve:matrix.org> monerobull: You should personally rewrite Haveno to use monero-wallet.

<k​ayabanerve:matrix.org> Tbf, the Bisq-forked swap code is probably worth an audit. I've reported a bug before.

<m​onerobull:matrix.org> kayaba is advocating for having non-devs vibecode critical monero infrastructure. noted fren

<k​ayabanerve:matrix.org> Like, lack of cryptographic bugs due to using wallet2 != lack of bugs.

<m​onerobull:matrix.org> yeah i know

<m​onerobull:matrix.org> but like, funds should be always recoverable as long as the basic wallet operations work correctly

<k​ayabanerve:matrix.org> What if it has memory corruption due to relying on code written in unsafe languages?

<k​ayabanerve:matrix.org> mb, you claim you promote a safe society, and yet you use apps written in memory-unsafe languages?

<k​ayabanerve:matrix.org> Would you say you're a hypocrite all of the time or just most of it?

<k​ayabanerve:matrix.org> :pp

<k​ayabanerve:matrix.org> I'll stop joking around so much. *someone*, yes, should do that fee bumping thing as it's a good idea *except* for the cost to the membership proofs (non-issue with CLSAG, issue with FCMPs).

<k​ayabanerve:matrix.org> Eh. No. It should be fine because we have membership/SAL separation. We can still have a batch membership proof so long as we have independent SAL proofs...

<m​onerobull:matrix.org> Best of luck, I remain skeptical of rbf but I can see it's few merits

<k​ayabanerve:matrix.org> The fee bumping proposal isn't RBF in the traditional sense and doesn't conflict with zero-conf if implemented correctly.

<g​ingeropolous:monero.social> so looking for some feedback with monerosim. As i've been developing this, i've come to appreciate that ethshadow really focused on the networking / consensus aspect of ethereum... simulating and testing that. It wasn't really concerned with tx propagation etc. It was mainly node synchronizing, network communications, etc.

<g​ingeropolous:monero.social> So I plan monerosim to be more than that. Currently i'm developing it with an "agent" framework. So, for a given agent (i call them user agents), it can have various attributes and processes. So a user agent will have a node, a wallet, and a python script that governs their behavior (send transactions at this interval, etc).

<g​ingeropolous:monero.social> there are other agents that are just python scripts. For instance, to simulate mining, there is a block controller agent that randomly selects (based on weights that mimic mining hashrate) a mining enabled user agent to be the winner of a given 2 minutes (I haven't bothered with varying the block production to mimic the temporal randomness of block finding). This kind of agent i'<clipped

<g​ingeropolous:monero.social> m referring to as controller agents, or coordinators. Haven't really decided.

<g​ingeropolous:monero.social> with this framework, i hope to eventually expand other controller agents. we can imagine a marketplace agent, which is a python script that gathers monero addresses from the user agents. User agents with the attribute of being a member of marketplace1 can then poll the marketplace agent to get a monero address to send monero to. (this could also be done with just a list of monero <clipped

<g​ingeropolous:monero.social> addresses populated at the start, instead of being dynamic).

<g​ingeropolous:monero.social> i'm also debating integrating scenario / controller scripts. The current agent-based makes it sorta headless. Scenarios can still be orchestrated by agent start times (e.g.,, have a stable network running for 3 hours, then have a bunch of agents start that do 100-fold rate of transaction sending). With a scenario script, we could have a python script that coordinates these behavio<clipped

<g​ingeropolous:monero.social> rs (e.g., at timepoint x, select n user agents and increase tx frequency x fold).

<g​ingeropolous:monero.social> any thoughts?

<a​ntilt:we2.ee> are you running the orig. monerod wrapped in a python skript ?

<g​ingeropolous:monero.social> no, the monerod is called directly. shadow doesn't do well with child processes

<a​ntilt:we2.ee> whats the interface called on a kernel level again?

<g​ingeropolous:monero.social> im not sure what you mean. shadow intercepts system calls

<a​ntilt:we2.ee> well, congrats. Lots of possibilities there... I watched the ethshadow vid and the # of nodes was limited to ~200 iirc ?

<a​ntilt:we2.ee> My idea was from the beginning to model Eigentrust. Then use trust levels to select validators like in Stellar consensus (!=POS). We are in fantasy land right now. TBC

<b​asses:matrix.org> takebackourtech.org/moneros-51-atta…-centralization-vs-decentralization Rucknium