<f​iatdemise:matrix.org> Just tried that miner in Chrome browser on a pc running Ubuntu. I'm getting ~560 H/s in browser when I usually get ~16,700 H/s with xmrig. Is there a way to get better results in browser?

<r​avfx:xmr.mx> I don't think so

<r​avfx:xmr.mx> a browser is a browser, it's mainly a bloated unoptimized piece of ***

<r​avfx:xmr.mx> and you go thru abstration layers with browsers

<r​avfx:xmr.mx> while with xmrig you run code directly on the CPU as optimized as it can be for that specific purpose

<r​brunner7:monero.social> Did nobody state clearly so far that mining Monero in a browser is dumb, stupid, and absolutely not worth it, and that this won't change, like probably ever?

<m​andate6:monero.social> They foolishly think Snowflake saved Tor—it didn't.

<m​andate6:monero.social> TLS-like bridges such as Webtunnel save it.

<m​andate6:monero.social> In this bribery war, if Monero wants to win, the only way is to reshape consensus and replace PoW with a [mathematically deterministic solution](decentralizedstatemachine.com), which would at least preserve community cohesion and brand identity, probably.

<m​andate6:monero.social> In this bribery war, if Monero wants to win, the only way is to reshape consensus and replace PoW with a [mathematically deterministic solution](decentralizedstatemachine.com), which would at least [preserve community cohesion and brand identity](dmf-archive.github.io/concepts/Economy), probably.

<m​andate6:monero.social> This is no longer a game about coins, this is an ontological war.

<e​longated:matrix.org> No, randomx performs crap in browser; CN used to work well

<m​andate6:monero.social> In this bribery war, if Monero wants to win, the only way is to reshape consensus and replace PoW with a [mathematically deterministic solution](decentralizedstatemachine.com), which would at least preserve community cohesion and brand identity, probably.

<t​orir:matrix.org> The DSM whitepaper has a number of issues. It seems to imply in one place, for instance, that the creation of new DSM accounts requires trusted entities as a measure to prevent Sybil attacks, yet in another it implies that users can create their own identities. It implies (but doesn't state outright) that double-spend attacks can be detected but makes no suggestion at all about ho<clipped message>

<t​orir:matrix.org> w to proceed when double-spend attacks are detected. In another spot it says that double-spend attacks are impossible, in an offline environment, without even addressing obvious things like saving a snapshot of the app, sending a payment offline to someone, restoring the snapshot, then paying someone else also offline.

<v​tnerd:monero.social> Torir: quote from site : "Solves The "Double Spend Problem" without consensus". Like what? Everyone just agrees to have their own version of events? Yeah I dunno what this even about

<t​orir:matrix.org> I think it is AI generated.

<m​andate6:monero.social> You've pointed out the core trade-off. DSM is essentially a network of bilateral state channels. It does require an initial trust anchor for genesis (the paper details a trustless MPC-based setup for this, see Sec. 12), but that's a one-time cost.

<m​andate6:monero.social> Once a relationship is initialized, all subsequent state transitions are self-validating and cryptographically bound. The key shift is moving from continuous global consensus (PoW) to a one-time anchored setup followed by localized, deterministic verification. No more global race.

<m​andate6:monero.social> The offline double-spend (snapshot restore) is mitigated by the recipient co-signing a pre-commitment hash (Sec. 16). When they come back online, any conflicting state publication from the sender would be invalidated by the already broadcasted, co-signed commitment. It transforms the problem from preventing forks to deterministically resolving them.

<m​andate6:monero.social> You've pointed out the core trade-off. DSM is essentially a network of bilateral state channels. It does require an initial trust anchor for genesis (the paper details a trustless MPC-based setup for this, see Sec. 12), but that's a one-time cost.

<m​andate6:monero.social> Once a relationship is initialized, all subsequent state transitions are self-validating and cryptographically bound. The key shift is moving from continuous global consensus (PoW) to a one-time anchored setup followed by localized, deterministic verification. No more global race.

<m​andate6:monero.social> The offline double-spend (snapshot restore) is mitigated by the recipient co-signing a pre-commitment hash (Sec. 16). When they come back online, any conflicting state publication from the sender would be invalidated by the already broadcasted, co-signed commitment. It transforms the problem from preventing forks to deterministically resolving them.

<m​andate6:monero.social> You've pointed out the core trade-off. DSM is essentially a network of bilateral state channels. It does require an initial trust anchor for genesis (the paper details a trustless MPC-based setup for this, see Sec. 12), but that's a one-time cost.

<m​andate6:monero.social> Once a relationship is initialized, all subsequent state transitions are self-validating and cryptographically bound. The key shift is moving from continuous global consensus (PoW or PoS) to a one-time anchored setup followed by localized, deterministic verification. No more global race.

<m​andate6:monero.social> The offline double-spend (snapshot restore) is mitigated by the recipient co-signing a pre-commitment hash (Sec. 16). When they come back online, any conflicting state publication from the sender would be invalidated by the already broadcasted, co-signed commitment. It transforms the problem from preventing forks to deterministically resolving them.

<t​orir:matrix.org> So... the receive thinks they got paid then when they go back online the transaction is undone?

<t​orir:matrix.org> Or the receiver comes online, publishes the transaction, and it undoes an existing transaction already published?

<m​andate6:monero.social> This can be solved by VDF, and Solana has already demonstrated the potential of PoH.

<m​andate6:monero.social> It's just that they use PoS for final anchoring, while DSM implements the idea of state channels more extremely.

<k​ayabanerve:matrix.org> Going with it for a moment, 1:1 state channels aren't viable alone. You still need a way to transfer across them. If you have a base layer, why would DSM be notably better than _any_ payment channel network solution that's well-designed?

<k​ayabanerve:matrix.org> Is that the argument? DSM is just a well-designed payment channel architecture?

<t​orir:matrix.org> Okay, so better stated in a less wordy than the DSM whitepaper, the project is basically 1:1 payment channels that either party can publicly prove the most recent state of. However, two parties working together could create conflicting states for their shared payment channel, which means that other 1:1 payment channels cannot rely on the word of those two parties.

<m​andate6:monero.social> Correct. DSM avoids Lightning's routing issues by pushing multi-party logic to the app layer (e.g., atomic swaps, not chained HTLCs). For DeFi like AMMs, the counterparty is an always-on MPC network acting as a virtual, trustless entity, providing a persistent anchor for asynchronous swaps while still using deterministic DSM rules.

<m​andate6:monero.social> Almost. Yes, two colluding parties (A&B) can create conflicting states against two different external parties (C and D). But C and D can protect themselves by cross-verifying A's state with each other (or any other honest party interacting with A) before finalizing. The fraud is contained because the inconsistency is cryptographically provable to anyone who cross-references. It do<clipped message>

<m​andate6:monero.social> esn't break the network; it just isolates and burns the reputation of the colluding parties.

<m​andate6:monero.social> Almost. Yes, two colluding parties (A&B) can create conflicting states against two different external parties (C and D). But C and D can protect themselves by cross-verifying A's state with each other (or any other honest party interacting with A) before finalizing. The fraud is contained because the inconsistency is cryptographically provable to anyone who cross-references. It do<clipped message>

<m​andate6:monero.social> esn't break the network; it just isolates and burns the reputation of the colluding parties.

<t​orir:matrix.org> So I have to have verified that A's state is valid by going online before I can accept offline payments from A.

<t​orir:matrix.org> By talking to an entity that I trust that also interacted with A.

<t​orir:matrix.org> It's really hard to send money to strangers in this setup.

<m​andate6:monero.social> This does not require online verification, just accept non-interactive zero-knowledge proofs

<m​andate6:monero.social> Not necessarily online verification. A can provide you with a non-interactive ZK proof from a trusted introducer (say, a well-known exchange E) attesting that "A's state was consistent and solvent as of VDF timestamp T". You trust E's signature on that proof, not A's liveness. It shifts the trust anchor from global state liveness to transferable, signed attestations.

<t​orir:matrix.org> So, why doesn't the whitepaper offer suggestions for how to handle detected double-spend attacks? Or talk about how the reputation damage of a detected double-spend acts as a deterrent?

<m​andate6:monero.social> handling it is an application-level concern, not a protocol-level one. DSM's job is to make double-spends cryptographically detectable and attributable, not to prescribe a universal punishment. One app might implement a public burn list, another might use it for a credit score, a third might trigger legal smart contracts. The protocol provides the irrefutable proof; the social/eco<clipped message>

<m​andate6:monero.social> nomic consequences are built on top, making the system more flexible than a hardcoded protocol-level slash.

<t​orir:matrix.org> There is definitely *some* sort of potential here, but the whitepaper really completely fails to address any of my questions.

What's the story with the Google play wallet ban?

<t​orir:matrix.org> midipoet: From @newsFromGoogle: Thanks for flagging this. Non-custodial wallets are not in scope of Google Play's Cryptocurrency Exchanges and Software Wallets Policy. We are updating the Help Center to make this clear.

<t​orir:matrix.org> Hey, is this even the correct channel for discussion of the DSM whitepaper?

Ah that is good.

Cause this article wasn't clear

<t​orir:matrix.org> I think that tweet or whatever it was came later. I haven't actually gone and found the source.

<t​orir:matrix.org> Found it: xcancel.com/NewsFromGoogle/status/1955743865144795581

<t​orir:matrix.org> Ω-418: I'm a 🫖: If VDF are so important to the protocol, why doesn't the whitepaper mention them once? Like... the whitepaper is... weird.

<t​orir:matrix.org> And PoH (from what I've read) requires a degree of centralization which the Monero community is strongly against. This idea *might* have promise, but it needs a lot of work before we can usefully discuss integrating it into Monero.

<t​orir:matrix.org> In my opinion.

<m​andate6:monero.social> Because the original author's solution is hardware-bound to DBRW, ensuring all local states are up-to-date and confined to the device

<m​andate6:monero.social> Because the original author's solution is hardware-bound to [DBRW](decentralizedstatemachine.com/DBRW-combined.pdf), ensuring all local states are up-to-date and confined to the device

<t​orir:matrix.org> What is DBRW?

<t​orir:matrix.org> Also, try to not edit your posts on Matrix, it spams the IRC relay bot.

<m​andate6:monero.social> ok.

<m​andate6:monero.social> decentralizedstatemachine.com/DBRW-combined.pdf here

<t​orir:matrix.org> So it sounds like DBRW completely fails if I can patch the app to provide a false fingerprint or even a fingerprint from a different device. The fingerprint can only be measured on the device itself, but the user controls the device.

<k​ayabanerve:matrix.org> This sounds like a long way to say it doesn't have consensus because it doesn't do anything you'd need consensus for

<m​andate6:monero.social> You control the device, but you don't control the physics of its silicon or the math of the hash function. DBRW's hardware fingerprint is the input to a cryptographic hash that forms the commitment chain. You can patch the app to provide a false fingerprint, but you cannot force that false input to produce the correct hash output that matches the chain's history, unless you can re<clipped message>

<m​andate6:monero.social> verse the hash function. It's like saying you can forge a signature because you control the pen. You can write whatever you want, but you can't make it match my signature.

<k​ayabanerve:matrix.org> But the moment you want to do something requiring consensus, we handwave the existence of something with consensus (an MPC group)

<m​andate6:monero.social> In reality, for most "dapps," you have no choice but to trust the contract deployer.

<t​orir:matrix.org> Ω-418: I'm a 🫖: What's stopping me from creating a brand new chain with a false fingerprint the entire time? A closed-source app? A TPM?

<t​orir:matrix.org> The attack that lets me roll back state and copy my wallet to other devices is the one where I only pretend to do DBRW on my device but actually just pick random numbers.

<m​andate6:monero.social> Your genesis state. To interact with me, you need to present your genesis state, which was created at a specific point in time and anchored, for example, via a trustless MPC ceremony with witnesses (Sec. 12). You can create a new chain with a fake fingerprint now, but you cannot retroactively make it the chain I've been interacting with since last week. The genesis event is a uniq<clipped message>

<m​andate6:monero.social> ue, witnessed, temporal anchor. You can't fake history.

<t​orir:matrix.org> So... back to a setup process. During the setup process, what forces me to do honest DBRW on my device?

<k​ayabanerve:matrix.org> I believe this is sufficiently off topic it can be kicked to off topic.

<t​orir:matrix.org> Okay.

<t​orir:matrix.org> How do I link to a channel on Matrix?

<t​orir:matrix.org> Nevermind, they left.

<3​21bob321:monero.social> troll

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

<s​yntheticbird:monero.social> The level of botting is crazy

<s​yntheticbird:monero.social> we're not using mdbx btw

<1​7lifers:matrix.org> everyone gotta know D:

<s​yntheticbird:monero.social> 289 repositories mentioned, thats effectively a hell of a way to make people know

<f​iatdemise:matrix.org> Anyone estimate how much it costs qubic to attack Monero? Wondering if this article's claim of $75 million per day is reasonable, or way off. mexc.com/es/news/spending-75-millio…-back-at-the-monero-and-qubic/65028

<s​yntheticbird:monero.social> > Yu Xian, founder of the security company SlowMist, an attack of this scale could cost as much as $75 million per day

<s​yntheticbird:monero.social> I think article writer got this way off

75k/day

<s​yntheticbird:monero.social> more likely yeah

<3​21bob321:monero.social> Only on weekends ?

dan bob mostly yeah

<s​pirobel:kernal.eu> SyntheticMoo, the true and only one: the author assumes the hardware has to be bought / quotes someone who does

<f​iatdemise:matrix.org> Qubic's "marathon" attack should be happening again now, right? Where can I look to see how that's going? I don't see a current hashrate for Unknown on miningpoolstats site.

<s​pirobel:kernal.eu> i think they will switch to gpu mining a different coin

<s​pirobel:kernal.eu> something that is missing in the article: cpus have a value outside of monero mining. so hardware is not pure cost. could also buy on credit or get people on an "mine ai with cpus" MLM scheme to buy the hardware with buy now pay later services or credit cards.

<o​frnxmr:xmr.mx> Can also resell _or rent out_ cpu compute power

<o​frnxmr:xmr.mx> Not just on miningrigrentals, but there are other places to loan compute and recoup costs multiple times over

<e​longated:matrix.org> Servers?

<s​pirobel:kernal.eu> to be fair at this point we are in a war of attrition type of situation and the game theoretics of this scenario make it more expensive now

[CCS Proposals] Luke Parker opened merge request #604: kayabaNerve Finality Layer Book repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604

<k​ayabanerve:matrix.org> 👋

<d​ufebo98:monero.social> So, finality layer will be the solution?

<k​ayabanerve:matrix.org> I ended up doing a very brief outline for CCS, though obviously I expect the completed work to be similar in content/thickness as my FCMP++ paper (albeit angled for wider understandability throughout the community).

<k​ayabanerve:matrix.org> Purple grapes: No?

<k​ayabanerve:matrix.org> > The intent of this book would be an educational resource advancing the discussion on finality layers (by ensuring everyone is on the same page) and a reference design, should we ever decide to move forward with implementation.

<k​ayabanerve:matrix.org> One of the primary issues right now, as we discuss if a finality layer is a better solution than what we have today, is people don't understand how a finality layer would work/the literal effects.

<k​ayabanerve:matrix.org> This would propose a design to advance the discussion and allow us to have an educated opinion on _if_ a finality layer should be the solution.

<d​ufebo98:monero.social> Got it, thank you

<k​ayabanerve:matrix.org> Happy to clarify :)

<s​yntheticbird:monero.social> still way off

Kayabanerve ma

<s​yntheticbird:monero.social> sniper took plowsof?

<k​ayabanerve:matrix.org> Ma? Mama?

<k​ayabanerve:matrix.org> plowsof's first word ♥

With my last breath - it has to be a markdown (.md) file ... And whatever you do, please end on a new line x.x

<k​ayabanerve:matrix.org> ... did I not make a MD file?

<k​ayabanerve:matrix.org> Oh, I didn't assign any ext

<k​ayabanerve:matrix.org> Sorry, I'll fix that

<k​ayabanerve:matrix.org> Blame the web editor for not ending on a new line though :C I agree it should always be done

<k​ayabanerve:matrix.org> plowsof: Fixed

<k​ayabanerve:matrix.org> john_r365: Responded

<j​ohn_r365:monero.social> thanks! kayabanerve

<j​ohn_r365:monero.social> matrix.monero.social/_matrix/media/…ero.social/aSHDSbSygqhQjZvobOrPDZtH

<j​ohn_r365:monero.social> Can these stats be relied on? 3.1 GH/s and 40 of the last 100 blocks

<e​longated:matrix.org> Interesting, any orphaned blocks ?

<j​ohn_r365:monero.social> can't see any on moneroconsensus.info recently

<e​longated:matrix.org> Looks like qubic is here to stay, why not when their team makes xmr and pays in qubic

<o​frnxmr:xmr.mx> 40 of the last 100, yes. The 3.1 is self-reported though, but sounds accurate

<e​longated:matrix.org> So much for cucnets securing xmr

<o​frnxmr:xmr.mx> Supoortxmr lost 400mb

<o​frnxmr:xmr.mx> Top 3 pools "only" have 48% atm

looking at the avg using rough numbers, compared to 30 July, the unknown HR increased 1.5GH/s while known pools decreased by the same amount

<k​ayabanerve:matrix.org> binaryfate: tevador has a proposal for the general fund to handle immediately, if to be handled, in #monero-research-lounge:monero.social

<k​ayabanerve:matrix.org> Also cc luigi1111 , I guess

<m​onerobull:matrix.org> this is bad

<j​ohn_r365:monero.social> time to open the wallet and fight back with hash power?

<e​longated:matrix.org> Yes every Kh/s helps

<o​frnxmr:xmr.mx> [@kayabanerve:matrix.org](https://matrix.to/#/@kayabanerve:matrix.org) i dm'd both on irc

<j​ohn_r365:monero.social> anyone about who can answer some dumb questions / give tips regarding miningrigrentals.com ? maybe who's used it before

<o​frnxmr:xmr.mx> ive used it, sup

<o​frnxmr:xmr.mx> Damn, 200mh is like 15000usd

<o​frnxmr:xmr.mx> We dont have that much btc iirc

<r​ucknium:monero.social> john_r365: x3nu had a video on it

<r​ucknium:monero.social> reddit.com/r/Monero/comments/1mehpa…y_rent_hashrate_to_help_protect_the

<j​ohn_r365:monero.social> thanks Rucknium

What's the primary reason for designing a "Monero finality layer", as opposed to just using a checkpoint commitment to prevent reorgs on an existing/larger chain?

Rationally speaking, surely it's just optics?

<m​onerobull:matrix.org> no

<m​onerobull:matrix.org> someone earlier said the commitments require you to run a btc node

I don't understand why? Surely it would just be a read/write operation, which can be done without running a full node.

It suppose it might be more secure to run a node so that you can verify the commitments against your own copy of the chain, but i don't understand why it would be a necessity.

<k​ayabanerve:matrix.org> midipoet: That would make Bitcoin the finality layer.

<k​ayabanerve:matrix.org> It's an option.

Yes, I know that

<k​ayabanerve:matrix.org> You'd need a Bitcoin node/competent light client to retrieve the commitments.

Yes, a light client isn't a full node though, right?

So, what is the other primary reason?

Surely it's just "dependency optics".

<k​ayabanerve:matrix.org> Reason not to?

<k​ayabanerve:matrix.org> Because we can't use Bitcoin due to data availability

<k​ayabanerve:matrix.org> We'd have to to use Ethereum or something smaller

<k​ayabanerve:matrix.org> Dependency optics

<k​ayabanerve:matrix.org> Miners have to pay to publish to an ETH SC

<k​ayabanerve:matrix.org> Everyone runs an ETH node

<k​ayabanerve:matrix.org> (Albeit they can run a pruned node)

Could we use a stablecoin? Preferably one of the new US regulated ones.

I mean, a stablecoin backed by coinbase/circle/Google or whatever is probably gonna be fairly secure.

<k​ayabanerve:matrix.org> If the community is willing to move to Ethereum checkpoints for the next six months, even just as an opt-in safety measure, and the top pools agree (which will effect a soft fork so long as time over time, they have 51%), it probably could be done in a month.

<r​ucknium:monero.social> Well, there's now one orphan today. moneroocean and hashvault orphaned a p2pool block. Friendly fire 🫣

<b​oog900:monero.social> would rather trusted nodes with a 10 block max reorg

<o​frnxmr:xmr.mx> Boog, rhat can be deployed in like, hours, cant it

<b​oog900:monero.social> the max reorg yes, the trusted node/people part probably not

<o​frnxmr:xmr.mx> Trusted node/people = seed nodes or user specified ?

<b​oog900:monero.social> would you just hardcode IPs? maybe add new p2p messages and use hardcoded pupkeys with messages that can be sent around the network?

<b​oog900:monero.social> either ig, we would need hardcoded options though as we cant rely on people setting them

<b​oog900:monero.social> if we do p2p messages they would need to be hardcoded

<b​oog900:monero.social> then is the problem of who is trusted

<k​ayabanerve:matrix.org> DNS checkpoint only blocks 10 blocks deep? Local node saves all published checkpoints? If the DNS checkpoint equivocate, nodes just die?

<o​frnxmr:xmr.mx> How to avoid the trusted nodes from being the ones hit with the reorg attacks?

<b​oog900:monero.social> you dont you just have an odd number of trusted nodes

<b​oog900:monero.social> go with the majority

<b​oog900:monero.social> or have some other mechanism of choosing between the chains in a consistent manner, in a way which can't be gamed

<b​oog900:monero.social> Can you update DNS records at that frequency?

<o​frnxmr:xmr.mx> They are same like dns blocklists, im not sure the ttl

<o​frnxmr:xmr.mx> I think dns checkpoints (which are opt-in) arent meant to be updated frequently, but to be updated durong a chainsplit, to get people back on the "correct" chain

Hmm

<s​yntheticbird:monero.social> welcome back