Confirmed, all Qubic blocks are empty now

<a​ntilt:we2.ee> the attack mode is to create a bubble with their token. Lots of PR needed, its a psychological operation.

<m​onerobull:matrix.org> kek

<m​onerobull:matrix.org> sech1 x.com/c___f___b/status/1953366557423235576

<m​onerobull:matrix.org> your link is broken bcs it applied formatting on the matrix side :P

How generous of them to leave tx fees to Monero pools :)

<m​onerobull:matrix.org> they are literally just giving away fees to honest miners

<m​onerobull:matrix.org> who could have expected that the economic design of PoW actually works

<h​bs:matrix.org> This way they can easily be identified:-)

Came across this (relatively) wacky, US Department of Defence supported/sponsored MIT thesis on cryptocurrency PoW today, if anybody is interested: dspace.mit.edu/bitstream/handle/172…ery-jplowery-sm-sdm-2023-thesis.pdf

<e​longated:matrix.org> Can nodes ignore empty blocks mined if mempool has pending txs ?

you can't see that in consensus in the past

all they have to do is add one tx they control as well

a miner can also get lucky-unlucky and find a block the instant they find another before they get the proper valid set of txs from mempool, so it CAN be empty even in normal conditions

<o​frnxmr:monero.social> Happens even on btc

<e​longated:matrix.org> Seeing lot of empty blocks today

<e​longated:matrix.org> Consecutive empty blocks too

<r​ucknium:monero.social> It will just delay first confirmation of a transaction by a block or two. Much less delay than happened during the black marble flooding, which reached hours for txs paying the lowest fee.

<o​frnxmr:xmr.mx> Also before bugfix where pools werent updating block templates/ lol

<r​ucknium:monero.social> Yes. That, too: rucknium.me/posts/monero-transactions-60-seconds-faster

<l​ordx3nu:matrix.org> Looks like they've gotten pretty lucky recently. 4 in a row

<c​ountbleck:matrix.org> What rate of orphaned blocks would be a sign for concern

<o​frnxmr:xmr.mx> define "sign for concern"

<o​frnxmr:xmr.mx> One could say 10%, one could say 50%, one could say 80+%

<o​frnxmr:xmr.mx> Depends what you define as success. If able to orphan 100% of blocks, particularly if they decide to censor transactions or mine empty blocks, then that would definitely be concerning

<o​frnxmr:xmr.mx> Does that mean 50% of other ppls blocks becoming orphans is OK? No. But not as bad at 100%. What about 10%? Same, not as bad as 50, but still not good.

<o​frnxmr:xmr.mx> Also, defining concern. Does this mean "when we have to make major changes to the protocol to protect honest mining"? Or does it mean "when we have to start paying attention"? Because we're already paying attention

<c​ountbleck:matrix.org> a tangible impact on user experience or network stability

<c​ountbleck:matrix.org> Right now it's barely at half a percent, so I'd assume that has very little impact

<o​frnxmr:xmr.mx> that is so low because they withhold orphans that they arent winning

<o​frnxmr:xmr.mx> If they have 51% of the global hash, they will win more often than not, and can orphan everyones blocks (if they have average luck)

@countbleck:matrix.org and quite some of those come from known pools orphaning each other

33% of them

<c​ountbleck:matrix.org> so they're hurting their own profitability?

<c​ountbleck:matrix.org> That's miserable

<c​ountbleck:matrix.org> oh new toys to play with on

<c​ountbleck:matrix.org> moneroconsensus (sorry I pressed Enter too early)

<o​frnxmr:xmr.mx> anyway, i think some discussions should continue about changing the protocol to lower combat such attacks.

<o​frnxmr:xmr.mx> Couple things that have been suggested

<o​frnxmr:xmr.mx> a) rolling (10 block) reorg depth — to prevent reorgs beyond lock period outputs

<o​frnxmr:xmr.mx> b) hybrid POW+POS (pow favored emission 10:1) "proof of staking pow coinbases" — to eliminate a 51% attack on either side of the network

<o​frnxmr:xmr.mx> c) miner signed coinbases, with 10% going to miner and 90% to whereever you want (pool payouts etc) — i'm not sure how this would effect an adversary. might hurt unattended botnets, but afaict would actually put us in a worse position _today_, since typical botnets are one of the main reasons cutebitc doesnt have 50%

<o​frnxmr:xmr.mx> d) delaying part of the payout on pow emission — incentivizes hodling, but if the coins eventually unlock, i dont think this makes any difference?

<o​frnxmr:xmr.mx> e) tee block producers

<o​frnxmr:xmr.mx> d) firo and dash have "chainlocks" but iiuc, require masternodes

<v​tnerd:monero.social> its not just orphan blocks, you should see some small reorgs (as opposed to just two competing blocks)

`typical botnets are one of the main reasons cutebitc doesnt have 50%` < botnets can sell hashrate on MRR too

<v​tnerd:monero.social> if the conditions aren’t correct, then yes they are just wasting energy

<l​ordx3nu:matrix.org> Qubic hashrate jumped to 2.5 GH

<c​ountbleck:matrix.org> Qubic doesn't seem entirely profit-motivated...does this help prevent attackers who want to take down Monero? (is that a likely threat?)

<v​tnerd:monero.social> lol why wouldn’t they be profit motivated?

<c​ountbleck:matrix.org> > d) delaying part of the payout on pow emission — incentivizes hodling, but if the coins eventually unlock, i dont think this makes any difference?

<c​ountbleck:matrix.org> Qubic doesn't seem entirely profit-motivated...does this help prevent attackers who want to take down Monero? (are such attackers even a likely threat?)

<v​tnerd:monero.social> where did you get this information?

<c​ountbleck:matrix.org> I meant right now wrt XMR, since they're sacrificing XMR rewards in the short-term for long-term marketing/PR

long term it's profit by trying to become 51% so they are the only profitable pool

<v​tnerd:monero.social> mind you the argument for the selfish mining attack is that they are able to squeeze out slightly more revenue than their peers, creating a downward spiral where more people move to that chain

<o​frnxmr:xmr.mx> Problem with a) is that a new node syncing, encountering a chainsplit >10 blocks deep, wouldnt know which side of the chain to follow. I dont know if i see this as an issue, as this is already an issue with sybils and can be worked around by using trusted peers (or seeds) to pull get on the correct chain

<o​frnxmr:xmr.mx> b) people don't like POS, but i think this is less POS and more Proof of POW, since you cant "buy-in", and cant stake coins that have been spent.

<o​frnxmr:xmr.mx> c) explained above

short term they are effectively wasting waaay more

<o​frnxmr:xmr.mx> d) explained above

<o​frnxmr:xmr.mx> e) no comment

<o​frnxmr:xmr.mx> d) no comment

<v​tnerd:monero.social> *that chain -> that pool

<l​ordx3nu:matrix.org> Vtnerd: explorer.jetskipool.ai/xmr-tracker.html

vtnerd: not what is seen according to tracked data

<o​frnxmr:xmr.mx> the othe problem we have today, is that wirh orice falling, monero "profit" falls, and likely the hashrate will too

<o​frnxmr:xmr.mx> Yeah, it doesnt look like any miners are migrating. similarily though, zephyr has more randomx hashrate than monero, and miners didnt migrate. but botnets came online to mined it for profit

<o​frnxmr:xmr.mx> Had* more

<c​ountbleck:matrix.org> Is this dashboard accurate?

<c​ountbleck:matrix.org> I thought >33% of the network hashrate spells trouble

<o​frnxmr:xmr.mx> no

<l​ordx3nu:matrix.org> I think the 2 GH figure seems accurate that has been reported so far today

<o​frnxmr:xmr.mx> the global hash is greater than 5.57+2.27

<l​ordx3nu:matrix.org> Based on the blocks they are finding

<r​avfx:xmr.mx> the red line should be at 5.57 right

<v​tnerd:monero.social> 33%+ means (assuming the selfish mining paper is correct), they can get slightly higher returns than the “standard” model predicts. the reorgs are small so they don’t hurt exchanges, etc.

<v​tnerd:monero.social> theres some variability on the rate of return, because the propagation of the network comes into play

<o​frnxmr:xmr.mx> The non-qubic hashrate is 5.57gh. Adding qubic is 5.57+2.27

<o​frnxmr:xmr.mx> Oh wait, maybe those #s are correct then :P lol 2.27/7.84=28.9

<v​tnerd:monero.social> the confusing part is that this qubic operator publicly announced it in such a way that it (likely) had an effect on price. the selfish mining attack/paper still kind of expects a return to be made on this time

<o​frnxmr:xmr.mx> i think some of the price falling comes from the loss of buy pressure from moneroocean. Even if not a lot, it was 24/7, sustained buy pressure

<o​frnxmr:xmr.mx> But also i think there are likely multipke entities taking advantage of the opportunity to "strike while the iron is hot", using "opening" from qubic to pile on

<v​tnerd:monero.social> me being the pessimist, given the wild claims about qubic ai and “proof of useful work”, this person had some other motives …

<v​tnerd:monero.social> and actually now that I think about it, if you are bold you short the coin and just keep “buying” at the lower price whether its through mining or straight exchange coins

<c​ountbleck:matrix.org> could you spell those motives out for me, I don't follow

<v​tnerd:monero.social> no one really pushed back on the claims of ai+useful proof of work from what I saw, so this just keeps going on and on

<o​frnxmr:xmr.mx> also the bot armies

<v​tnerd:monero.social> push qubic up, monero down. I don’t know much about this person to say anything further

<c​ountbleck:matrix.org> Their code isn't even open-source, it's under the "Anti-Military License"

<o​frnxmr:xmr.mx> rumor is they are from bytecoin, or at least one of the relaunches of it

<c​ountbleck:matrix.org> The Aigarth thing *looks* to be a bunch of hype that's trained away from public view, but idk for sure

<o​frnxmr:xmr.mx> They probably use it to post twitter comments lol

<v​tnerd:monero.social> I wouldn’t give them that much credit, the bytecoin authors figured out how to use linkable ring signatures and ECDH (stealth addresses) in a novel way

<v​tnerd:monero.social> I guess merge-mining to attack another coin is somewhat novel, but less so than bytecoin imo

<c​ountbleck:matrix.org> a lot of it looks like a way to (1) generate hype from the AI and crypto bubbles and (2) establish a moral high ground with "ethical AI" and misleading claims about energy consumption

<v​tnerd:monero.social> google ai is telling me that aigarth is attempting agi, which is big news because llm _probably_ wont achieve it

<v​tnerd:monero.social> lol how did you go from ai hype to trying to dump on monero, what a world

<v​tnerd:monero.social> I guess the latter got way more press

<a​ntilt:we2.ee> if, as an investor i expect a 100x bubble to form, i am willing to take some losses mid term... the dynamics are well known and carried out by professionals who design meme coin crazes

<c​ountbleck:matrix.org> As if this random token is going to outsmart the billions invested in both US and Chinese tech giants

<c​ountbleck:matrix.org> and the numerous academic institutions out there

<c​haser:monero.social> in hyc's logs (monero-project/research-lab #102#issuecomment-1528812041), the period that covers the current protocol version (2022-08-13--2023-04-20) has an average ~0.1% orphan rate. people are overreacting at the current 0.4% as if things are okay only if there are no orphans.

<v​tnerd:monero.social> reorgs or orphans

<b​oog900:monero.social> I thought GPUs where best for AI stuff anyway, don't know why they are targeting RandomX which is for CPUs

<v​tnerd:monero.social> he seems to be talking about reorgs in that comment

<b​oog900:monero.social> I thought GPUs were best for AI stuff anyway, don't know why they are targeting RandomX which is for CPUs

<v​tnerd:monero.social> docs.qubic.org/learn/aigarth

<v​tnerd:monero.social> basically, they are claiming technology which has yet to be explained

<c​ountbleck:matrix.org> they do have some strange decisions...the licensing is non-standard (explicitly anti-military), nodes are EFI executables and don't run on an OS, 2 TB of RAM is needed, contracts are apparently made with a limited subset of C++...some amount of thought was put into Qubic, albeit very strange thoughts?

<o​frnxmr:xmr.mx> Because everything on the internet is true

<c​haser:monero.social> I summed up what monerod reported as the "alternative blockchain size", almost always 2. maybe I was wrong and that means only 1 orphan per event?

<v​tnerd:monero.social> after further thought, an orphan is reorg’ed from the perspective of the “other side” of the network

<o​frnxmr:xmr.mx> "truth: we just mine monero, and produce qubic out of thin air" probably "also, the only ai we use, is for the bots that we use to generate 98% of the dicussion. Even my pfp is ai"

<o​frnxmr:xmr.mx> 2 means

<o​frnxmr:xmr.mx> 001 orphaned

<o​frnxmr:xmr.mx> 001 002 replaced it

<o​frnxmr:xmr.mx> 001a

<o​frnxmr:xmr.mx> 001b 002 *

<v​tnerd:monero.social> I just looked into his post. he’s talking about reorgs from his perspective. there may have been more, its just that he was on the winning side of the reorg

<v​tnerd:monero.social> as in, hyc reported 0.1%, but that was 0.1% reorg from his perspective, not necessarily the total number of reorgs during that period

<v​tnerd:monero.social> and [chaser](matrix.to/#/@chaser:monero.social)people thing there should be 0? yeah with 2min block time the probability goes way up (dont know how much, but certainly higher than btc)

<c​haser:monero.social> does that mean that, to have a realistic measurement, you'd need to collect data from have multiple nodes in diverse locations, and merge the registered reorg events?

<r​ucknium:monero.social> A rough estimate would be to double that 0.1%, assuing no deliberate bock withholding during that time, right? My web app is showing what the `get_alternate_chains` RPC provides. That gets alt chains and orphans that did not necessarily cause a "re-org" according to my node. In other words, when my node sees a block that eventually wins the contested chain, the log won't say "re-o<clipped mess

<r​ucknium:monero.social> rg", it will just say an alternative block was received, AFAIK.

<v​tnerd:monero.social> [chaser](matrix.to/#/@chaser:monero.social) I believe so, for a baseline. because if you happen to direct connect to a pool, you’re going to get those blocks first, whereas someone else may see it from another perspective

<v​tnerd:monero.social> and this is just the standard everyone competing scenario. the selfish mining changes things, but propagation is still important (the paper claims so)

<r​ucknium:monero.social> Alt blocks are discarded by the node on a restart, but `--keep-alt-blocks` as a startup flag will keep them through a restart: docs.getmonero.org/interacting/mone…od-reference/#testing-monero-itself

<o​frnxmr:xmr.mx> Otherwise you have to be connected to every node

<r​ucknium:monero.social> Don't alt blocks still propagate if they achieve the required PoW, regardless of how out of date they are? So the blocks should still be accessible by RPC, if not the log.

<o​frnxmr:xmr.mx> If i am solo-mining, and only have 5 peers, and a mining pool with 1000 peers sends their block out to 200 other miners, chances are that nobody is mining on top of my block

<o​frnxmr:xmr.mx> And my block will be orphaned, and most of the network wont even know it exists

<r​ucknium:monero.social> This PR by jeffro256 would change that behavior AFAIK: "cryptonote_protocol: ignore fluffy blocks past certain depth" monero-project/monero #10023

<o​frnxmr:xmr.mx> Only if you see them by connecting to a peer who has it, iiuc

<o​frnxmr:xmr.mx> Hmm

<v​tnerd:monero.social> it doesn’t get relayed if doesn’t goto “main chain”

<v​tnerd:monero.social> so someone would report it, but nodes running standard clients wont propagate it further until confirmed pow to be best

<a​nnelinlol:matrix.org> is it safe to accept Monero using selfhosted BTCPay and monerod fullnode?

<a​nnelinlol:matrix.org> should any action be performed considering this attack?

<a​nnelinlol:matrix.org> hello by the way :)

<a​nnelinlol:matrix.org> we are first telecom that accepts Monero and huge XMR holders.

<a​nnelinlol:matrix.org> we have two networks and some servers, but they are not free to mine Monero.

<a​nnelinlol:matrix.org> can we help Monero team some other way except buying above 200$?

<v​tnerd:monero.social> You'll want to inspect your confirmations amount, the suggested numbers haven't really changed

<a​nnelinlol:matrix.org> 10 confirmations is enough?

<a​nnelinlol:matrix.org> how safe is mainnet now?

<a​nnelinlol:matrix.org> I see less than 0.5% orphans and having thoughs that all habbwning today is all about media shitspam and not actual takeover, but what’s Monero team standpoint?

<o​frnxmr:xmr.mx> mainnet remains safe. 10 confs remains safe

<a​nnelinlol:matrix.org> any countermeasures ongoing? and maybe some bounties by core team?

<o​frnxmr:xmr.mx> For this to change, the attackers would have to obrain 51% of network hash and roll back the chain by over 10 blocks, as well as replace them wirh empty blocks (or refuse to mine your transactions)

<o​frnxmr:xmr.mx> matrix.to/#/!zxoYuvZdPYtIuWSQnn:mon…mx&via=matrix.org&via=monero.social

<r​ucknium:monero.social> annelinlol: Qubic hasn't really increased its hashpower share in the last one or two weeks. They are doing different annoying things with their current hashpower, but nothing that affects the security of confirmed transactions.

<r​ucknium:monero.social> There is no evidence of any successful nor attempted double-spends by qubic or anyone else.

<o​frnxmr:xmr.mx> you can only double spend your own spends anyway

<r​ucknium:monero.social> And you would be able to see that, contrary to some myths that have appeared.

<v​tnerd:monero.social> Some people don't know about key images work? Damn, what a show

<a​nnelinlol:matrix.org> they claimed that they succeed 51% attack and voluntarily stopped but it looked like very fake and bait to panicsell over all the media

<o​frnxmr:xmr.mx> you can enable dns checkpoibts if that makes you more comfortable

<r​ucknium:monero.social> The most number of blocks they have re-orged is 2 so far. And it is (roughty) exponentially harder to re-org more blocks.

<v​tnerd:monero.social> They claimed 51%? Do you have a link?

<p​reland:monero.social> Are they being ddosed or are they actually just dropping off again

<o​frnxmr:xmr.mx> theyve claimed 44%+ over and over on twitter

<v​tnerd:monero.social> Rucknium: was it them? I guess they'll claim it either way

I thought they stopped after their pool got "ddosed"

<o​frnxmr:xmr.mx> The 2 block reorg was "unknown" pool

<r​ucknium:monero.social> The 2-block re-org at height 3,472,097? I am pretty sure it was them.

<o​frnxmr:xmr.mx> i really think theyre doing what i described the other day. "dark" mining

<o​frnxmr:xmr.mx> i think a mitigation for normal pools would be to peer against one another

<v​tnerd:monero.social> Where did you describe dark mining, can't find it

<o​frnxmr:xmr.mx> Here

<a​nnelinlol:matrix.org> it’s strange, but post from shitter about “we are stopping attack at XMR 250$” is either disappeared or i just cant find it

<a​nnelinlol:matrix.org> x.com/Krash_AK47/status/1953529103908212907

<a​nnelinlol:matrix.org> also x.com/Qubic1000X/status/1953382905209913491

<a​nnelinlol:matrix.org> orig x.com/c___f___b/status/1953350025783742513

<a​nnelinlol:matrix.org> so all of their shit not affecting mainnet currently as I see

<o​frnxmr:xmr.mx> He changed his mind and said that he'd continue the attack id price fell

<o​frnxmr:xmr.mx> I think the price is someone else taking advantage of the environment to liquidate some longs and create fear

<a​nnelinlol:matrix.org> I see the fear. But is that threat real or its just panicsell?

<a​nnelinlol:matrix.org> I have some tasty orders at $200 just for myself. If someone needs to sell $XMR Im here

<a​nnelinlol:matrix.org> Now XMR moving out from the weak hands.

<o​frnxmr:monero.social> I don't think its a panic sell. I think its a "coodinated" effort to create fear, except i dont think cfb is behind the selloff

<e​longated:matrix.org> Both

<o​frnxmr:monero.social> cfb likely wanted the price to remain high, so he can keep the cost of his attack as low as possible

<o​frnxmr:monero.social> Nah, i think triggered liquidations are more likely and panic sell

<e​longated:matrix.org> Not much liquidations on binance perp

<o​frnxmr:monero.social> Likely than*

<a​nnelinlol:matrix.org> its all about advertising their another shitcoin by “we took monero network”

<e​longated:matrix.org> Someone dumped around 276 and then panic sell/sl triggered

<a​nnelinlol:matrix.org> and the price is clearly shows panicsell in range 260-240 imo

<e​longated:matrix.org> This

<a​nnelinlol:matrix.org> if mainnet remains safe and all their fud will be thrown to /dev/null, there is 99% possibilty that we’d restore 300+ levels

<o​frnxmr:monero.social> We can cont liq talk in markets, i just wanted to mention that i dont think the selloff was intentional by cfb

<e​longated:matrix.org> It may not be cfb, but his actions don’t help xmr price

<e​longated:matrix.org> If he was worried about xmr price he wouldn’t be attacking xmr publicly

<e​longated:matrix.org> Anyways we need a decade to bring price importance into monero ecosystem

<e​longated:matrix.org> Last decade was don’t buy monero

<e​longated:matrix.org> anhdres explained it nicely at monerokon

<e​longated:matrix.org> Ah fuck, sorry didn’t notice this was mrll

<t​esttank:matrix.org> Send invite pls

<v​tnerd:monero.social> He was referring to Monero Markets

<o​frnxmr:monero.social> More like "ofrn pretends to rob a bank, and someone else actually starts robbing it"

<o​frnxmr:monero.social> if it gets us to add significant hashrate, it should

<o​frnxmr:monero.social> @rbrunner @rucknium one thing i wonder now, is that peering /connectivity of mining nodes can be gamed to get an advantage - or can be worsened by default

<v​tnerd:monero.social> with respect to selfish mining? or some other thing? the original paper graphed out different propagation statistics and the reward based on that

<o​frnxmr:monero.social> meaning, a node that is multiple hops away from a large mining pool (who likely is very well connected), means a higher likelyhood of your block becoming the one that is reorged out

<v​tnerd:monero.social> poor connectivity by the selfish miner hurts their chances slightly, etc

that's why p2pool blocks get re-broadcasted by all miners

<o​frnxmr:monero.social> Poor connectivity by average miner is the problem. I think its worth studying the network topology to try to discover how many proxies qubic is running

<v​tnerd:monero.social> yeah I mean ruck may be know some of the stats offhand, but good connectivity is desired for a miner. but typically there arent two blocks mined that close together

block transmission is very quick

<o​frnxmr:monero.social> yeah p2pool also recommends peering to supportxmr and hashvault

plus seed nodes are also attached to other major pools so they get blocks quick

<o​frnxmr:monero.social> i imagine qubic also does this

<b​oog900:monero.social> We probably should relay new alt blocks the same as new main chain blocks

<o​frnxmr:monero.social> but which should we mine on? First come first serve?

<b​oog900:monero.social> Yeah, the same as we currently do but when we get an alt blocks that is new we relay it to peers

<v​tnerd:monero.social> why would we do that? that seems detrimental

<b​oog900:monero.social> Because nodes that don't get the alt block need to sync it if that chain wins, slowing down block propagation

<v​tnerd:monero.social> what would the parameters be? you can just relay any alt block, as someone could spam the network with super old blocks, etc. I just don’t know, doesn’t seem like its solving any issue

<v​tnerd:monero.social> *cant just relay any alt block

<b​oog900:monero.social> In cuprate we accept relayed blocks that are within 10 of our chain height so any alt block out of that range is ignored anyway

<b​oog900:monero.social> Yeah its not solving an issue really but it would speed up block propagation in a reorg to reduce wasted hashes

<b​oog900:monero.social> I would also call for only checking the PoW before relaying and then checking the block is valid

<b​oog900:monero.social> As a block full of unknown txs coupd slow block propagation quite a bit

<b​oog900:monero.social> Bitcoin does this fwiw

<v​tnerd:monero.social> relay before checking rest of block? are you sure?

<v​tnerd:monero.social> my initial reaction is that I don’t agree with either suggestion

<v​tnerd:monero.social> the one altchain thing probably helps selfish miners, as per the graph from the original paper

<b​oog900:monero.social> bitcoin/bitcoin #9026

<b​oog900:monero.social> bitcoin/bitcoin #9375

<b​oog900:monero.social> I think this is going to be more necessary when txs could take like 1s to verify with FCMP

<c​ountbleck:matrix.org> hey, dumb question...does selfish mining require that blocks are transmitted with a delay?

<b​oog900:monero.social> Have a block full of them which we haven't seen before and it could take a while for that block to propagate

<v​tnerd:monero.social> There's a private chain being created, yes

<c​ountbleck:matrix.org> (is this the appropriate chat for dumb questions)

<v​tnerd:monero.social> The last message was to CountBleck:

<v​tnerd:monero.social> For those lurking, the last two boog90mess0: messages were for quicker relaying of mainchain blocks, the alt chain suggestion is separate from this

<c​ountbleck:matrix.org> Could there be a way (in node implementations) to disincentivize keeping blocks private?

<c​ountbleck:matrix.org> (or is that what was being discussed earlier?)

<v​tnerd:monero.social> I'm not aware of any counter measures beyond running fairly standard blockchain rules. Maybe someone wrote a response, I can look

<r​ucknium:monero.social> I don't know specific numbers about empirical block propagation time off the top of my head. Older numbers for txs were:

<r​ucknium:monero.social> > About 50 percent of all transactions arrived at all five Monero nodes within a two-second interval. 95 percent all transactions arrived at all five Monero nodes within a five-second interval.

<r​ucknium:monero.social> rucknium.me/posts/monero-pool-transaction-delay

<r​ucknium:monero.social> The disincentive is built in: If you keep blocks private, your private block is not being built upon by other miners, so you are less likely to have your blocks (and their mining rewards) be part of the main consensus chain. This disincentive only reverses if the mining pool has about 33% or greater hashpower share.

<g​ingeropolous:monero.social> didn't bitcoin cash attempt to implement something to protect against this? avalanche? i don't know if it actually works or isn't permissioned, but i remember they put effort into defending against 51% attacks for obvi reasons

<c​ountbleck:matrix.org> so once 33% is exceeded, that disincentive disappears; understood

rucknium 3,472,934 is listed as unknown pool on moneroconsensus, it is pool.xmr.pt which is a small pool

<r​ucknium:monero.social> gingeropolous: IIRC, Bitcoin Cash ABC (now eCash) has implemented Avalance. It is "pre-consensus" of blocks based on the mempool, AFAIK.

<r​ucknium:monero.social> nioc: Thanks. If I could write Go, I would edit `monero-blocks` to pull from the .pt API. I don't want to burden Data Hoarder.

<r​ucknium:monero.social> By the way, my task to estimate unreported hashpower share is stalled. I wrote the suggested algorithm and it doesn't converge. I don't know what the problem is. I will contact the author to see if she has the old code available. The code is probably in R, so no problem there :D

<v​tnerd:monero.social> sciencedirect.com/science/article/pii/S2405959522000443

<v​tnerd:monero.social> Someone suggests spying on the selfish miner lol. No other comment so far, just that people have been writing about countermeasures a bit

<c​ountbleck:matrix.org> I'm guessing this event is going to inspire research of some sort

<c​ountbleck:matrix.org> actually sentence is a nothingburger

<c​ountbleck:matrix.org> actually that sentence is a nothingburger

<c​ountbleck:matrix.org> ...so by publicizing blocks the whole selfish thing would fall apart...what's the downside? Doesn't sech1 have access to the blocks

<v​tnerd:monero.social> I don't know what sech1 is doing. The selfish pool has to provide a template, which includes the hash of the prior block. So you can observe when a private chain is being used

23:40:25 <nioc> rucknium 3,472,934 is listed as unknown pool on moneroconsensus, it is pool.xmr.pt which is a small pool

yes, not all pools are added to the script

see git.gammaspectra.live/WeebDataHoarder/monero-blocks which ones are tracked

<v​tnerd:monero.social> CountBleck: you asked the downside of selfish mining? My best guess (since I've never tried) is making sure you have accurate numbers. If you don't, you are clearly just wasting CPU cycles

That's all correct, but it doesn't make sense to mine on top of an unknown block hash because your own node will not accept your mined block

given it has a standard api should be fairly easy to add

<c​ountbleck:matrix.org> I think I misunderstood you guys

<c​ountbleck:matrix.org> I thought "spying on the selfish miner" was "covertly obtaining the full blocks from the miner due to some oversight", like (what I thought?) sech1 was doing

And relying on what the selfish miner shows (block hashes) is dangerous because they can force you to mine on a complete rubbish hash, removing you from competition entirely

<r​ucknium:monero.social> sech1: Would you say that goes double for when the selfish miners does not have >33% hashpower share? In that case, you would be mining on a chain that has a greater probability of being orphaned.

<v​tnerd:monero.social> sech1 so they give the entire private blockchain to the pool?

<c​ountbleck:matrix.org> I think I misunderstood you guys (and I expressed myself ambiguously)

<v​tnerd:monero.social> Maybe we don't want to give up our info advantage, but certainly some things to think through that the original paper kind of glossed over (including price fluctuations, etc)

they give block templates to pools. There is just one (possibly two, data is unreliable) nodes which run the private blockchain when they're selfish mining

DataHoarder: thx, they only find a couple of blocks a week

given it's nodejs-pool I'll just make that the generic case that MO for example can also use

seems to work fine

no new code, only new entries

<c​ountbleck:matrix.org> nodejs-pool?

<c​ountbleck:matrix.org> oh nvm that was the tiny pool from earlier?

nodejs is the software

implementation

<c​ountbleck:matrix.org> I just didn't know there was Monero pool software written in JavaScript

<c​ountbleck:matrix.org> It looks kinda abandoned

<r​ucknium:monero.social> I've considered adding a plot or table to moneroconsensus.info to detected re-orgs that could be double-spend attacks, but qubic could just double-spend transactions to itself to make it look like there was a double-spend victim, but there would be none at all.

<r​ucknium:monero.social> Thanks, DataHoarder. I'm running the code with the .pt pool added.

wait, there's more coming

<r​ucknium:monero.social> Great :)

<e​longated:matrix.org> Great more ammo for them to fud

update now, added 9 more pools

see git.gammaspectra.live/WeebDataHoard…s/src/branch/master/main.go#L34-L76

I'll probably add a field for "miner attribution" to show any partial or full XMR address as found

some pools report this, so it could be interesting

<r​ucknium:monero.social> 🚀

<r​ucknium:monero.social> Awesome. Running it now.

it'll backfill old data probably :)

if you find any issues with this generic fetching poke me, I bundled all nodejs-pool and cryptonote-pool into the same fetcher type

... except supportxmr which serves the "ts" and "reward" as "numerical strings" (a number inside a quoted string)

so that has a fallback

also, you can probably color code the top 3 pools or so

then bundle all p2pools into one

show ALL the colors!

instead of green/red

<s​packle:monero.social> On the topic of enforcing solo mining by having miners sign with their private key, many people are convinced it is not a viable approach and that there are workarounds. From what I understand of the method Wownero used, workarounds were possible in their case. That said, I would appreciate some input on what might be a more robust approach.

<s​packle:monero.social> The objections I have heard are only valid because signing and PoW are easily separable operations. If the signing is thoroughly integrated into the PoW itself, included directly inside RandomX, I think the objections are moot.

<s​packle:monero.social> After some reflection, this is what I came up with (I imagine something like this has already been discussed elsewhere): The message that is actually signed is a very lengthy product of expanding the RandomX state. An example might be a long concatenation of hashes. So in order to sign, you either need to perform significant work yourself of receive a very lengthy message.

<s​packle:monero.social> If the length of the signed message is bandwidth prohibitive, and the work of expanding is too much for a dispatcher, I believe the scheme holds.

<s​packle:monero.social> I guess you could simply perform an expansion on the nonce by itself and get something similar. Will have to think on it a bit more. I did find the general idea compelling, at least I do not see how the objections I have heard would apply to it.

<s​packle:monero.social> *nonce + block height, etc