<p​reland:matrix.org> Hmm, that might’ve been the issue

<p​reland:matrix.org> I don’t have the issue now, as it was a temporary local net and I just reset it and started from the beginning, but I was confused as it had happened multiple times

<n​obfg9000:matrix.org> wow this is interesting. apparently they were having some major oscillating hashrate problems that ASERT solves. kind of unique to BCH because miners compete with BTC

<w​oodser:monero.social> --zmq-rpc-bind-port and --zmq-pub used to be options in monero-wallet-rpc, right? were they removed?

<w​oodser:monero.social> or, does monero-wallet-rpc support zmq at all?

<p​reland:matrix.org> That actually gives me an idea for a thought experiment: If all of the equipment currently used to mine BTC was suddenly switched to mine XMR, what would the hash rate of the BTC network (roughly) be?

<p​reland:matrix.org> And before you say it, yes the majority of the network’s current machines would be physically unable to run RandomX; that’s the point. Removing ASICS and others, how powerful is the BTC network *really*?

<s​yntheticbird:monero.social> To do so just substract the sum of all mining pool hashrates to the global hashrate. Make a medium over 1 year and you have your answer.

<s​yntheticbird:monero.social> I don't wanna do numerical comparaison with Monero since randomx and sha256 are order of magnitude different on the performance plan.

It's not just an order of magnitude, in most BTC ASIC cases, they simply CANT do RandomX, full stop. The wafer is etched to take an input, SHA256 it, then output the result on the trace. It cannot run RandomX whatsoever.

@woodser: AFAIK, monero-wallet-rpc does not support ZMQ

maybe those args were included in a copy-and-paste at some point

`git grep -i zmq -- src/wallet/wallet_rpc_server.cpp` shows nothing

<s​yntheticbird:monero.social> Sorry, I ment the hashrate of the same CPU when doing SHA256 and RandomX.

<s​yntheticbird:monero.social> Obviously ASICs can't don RX. I was just saying there is no sense at comparing bitcoin hashrate with monero hashrate, even when excluding asics, because of the pow algo

I wonder if there are any ASICs which can be repurposed for other low memory hashing algos

prob not, if they want their product to be competitive

<s​yntheticbird:monero.social> I mean. At some point someone turned an old nvidia GT into a raid controller. Turns out to gain 500% performance in write. So ig everything is possible

lol. Was the GPU hooked up to disk I/O buses in this mobo?

<s​yntheticbird:monero.social> PCIe i believe

<s​yntheticbird:monero.social> just PCIe on the motherboard iirc.

<n​obfg9000:matrix.org> @preland:matrix.org: good question

<n​obfg9000:matrix.org> perhaps it could be estimated by looking at every bitcoin node/lightning node, sampling average hardware and then figuring out how much idle CPU power they have

<n​obfg9000:matrix.org> mining is always discussed in terms of electricity, but that is really just the day-to-day costs (and kind of an unintentional side effect). the real cost of mining is the depreciation cost of hardware. In the case of generic computing power/CPU mining, a lot of people have personal computing hardware that they are just letting depreciate (as opposed to using BOINC or something)

<p​reland:matrix.org> It always bothers me how some of the more idiotic Bitcoin maxis claim that because their arbitrary hashrate number is larger than our arbitrary hashrate number that that somehow makes our network that much weaker or smaller.

<p​reland:matrix.org> The sheer amount of ways that thinking is wrong is laughable, and honestly anyone using that line of thinking to influence someone’s financial decisions is probably committing a crime just by implying as much.

<p​reland:matrix.org> I don’t care how many bajillion hashes per nanosecond your antminer can do; it can’t even do a single RandomX hash, and will one day become ewaste once “next product” mining rig comes out and makes older ones unprofitable (which is another note for non-ASIC resistant mining: using older hardware isn’t simply inefficient; it will literally cost you money to run, making th<clipped message>

<p​reland:matrix.org> e equipment a liability rather than an asset)

<n​obfg9000:matrix.org> ASIC miners are unique in the sense that you can have multiple parallel ASIC-mined competing cryptocurrencies with different algos (due to specialization), but you cannot really have paralell CPU mined cryptocurrencies (with the exception of memory hardness or some hybrid system), because the dominant cryptocurrency can do 51% attacks on the less dominant one

<n​obfg9000:matrix.org> the problem with ASIC mined cryptocurrencies is that their economic behavior becomes dependent on the economics of producing ASIC miners (and their respective depreciation), which is another factor aside from the centralization of pools, etc...

<n​obfg9000:matrix.org> I think crypto mining will depend on some goodwill on behalf of most miners in the future though (Like BOINC or Seti@Home). I just don't see any other way to prevent selfish mining idk

<p​reland:matrix.org> I don’t think there is a way to prevent “selfish” mining, because all actions have an inherent level of selfishness. Even someone who makes a charitable decision does so because in their minds they are trading something they have (resources, time, etc.) for something they don’t have (a positive outcome in a field they are interested in).

<p​reland:matrix.org> To focus back on crypto, people will always behave selfishly. If it is profitable to run a node, people will run as many as possible. If it is unprofitable, most people will stop running a node. The exceptional few that continue running nodes regardless of profit do so either because they have a significant investment in the network (ie XMR ownership) or have a significant interes<clipped message>

<p​reland:matrix.org> t in the value that XMR provides or represents.

<n​obfg9000:matrix.org> I mean specificially the selfish mining attack, which is a term used in literature

<n​obfg9000:matrix.org> link.springer.com/article/10.1007/s10207-024-00849-5