they have another +5 ahead

<ofrnxmr:xmr.mx> Its not easy to get these leads

depth 6, monero couple behind

> monero heights 3489459 to 3489462 could be orphaned by qubic (possible 5 blocks, current 3 blocks)

from what I saw they wait until the actual max possible amount, or 9

sometimes they are too slow pushing their alt chain and monero overtakes them and they lose it

<ofrnxmr:xmr.mx> I cant help but think that they have >51% hashpower

they have been able to spot higher bursts

<vtnerd> They are likely doing bursts, as discussed earlier

22-02 UTC is when we tend to see it, coinciding with lowest monero power

<ofrnxmr:xmr.mx> ginger gave them the idea

<ofrnxmr:xmr.mx> :P

<vtnerd> It's somewhat obvious if the goal is max pr effort too

someone also gave them the idea about putting their own txs in :)

<ofrnxmr:xmr.mx> and about mining offline

really all the github PRs is about discussing not hypothetical anymore but having an active incident discussed in the open and giving attacker countermeasures

ok monero got there

5=5

reorg?

yep, reorg

aaand they are instantly +1

+2

<datahoarder> mrelay.p2pool.observer/p/ipbNuLAKVHFtODZW/1.txt (code snippet, 18 lines)

<datahoarder> how it looked just before reorg, if anyone wants to consider where checkpoints would have been nice

<ofrnxmr:xmr.mx> this is making 144 look defeatable

they don't care about profit

they care about the idea of showing profit

<ofrnxmr:xmr.mx> Since they are able to get 3 blocks ahead

but they are just burning xmr for PR, not giving to miners

<ofrnxmr:xmr.mx> They had a poll about doing 29 block reorgs lol

we have seen them get +11 ahead not just deep

yeah, maybe September as they say. they need more fresh PR as their doge and AGI training one is not really going much further

<ofrnxmr:xmr.mx> for the dns checkpoints, the dns is probably the weakest link

indeed

+3 ahead/deep

<ofrnxmr:xmr.mx> My node and your node might not see the same records, and definelty arent checking at the same time

yep, that's why I mentioned with rolling checkpoints at least the last N will coincide

maybe not exactly the tip

<ofrnxmr:xmr.mx> The main problem is if mining pools split, even temporarily, then start competing with one another

<vtnerd> there’s also the small amount of solo miners that will get split off. not sure what percentage that is though

<ofrnxmr:xmr.mx> DataHoarder: The problem is if any of the checkpoints are created from a reorg

I was writing a shim for the DNS updaters so they can point to each other and agree ahead of time what they see

and share alt blocks they see (which is why I was adding ZMQ for alt blocks)\

<ofrnxmr:xmr.mx> We had issue where 520 was good, 533 good, 525 reorged chain, 527 good, = broken

that way they are always aware of alts, and can select the chain

I don't see hashrate increase from their solution network

but this is defeatable, all they need is xmrig set with a custom higher difficulty

then it won't report shares that don't find blocks

so it will never be seen :)

<ofrnxmr:xmr.mx> @vtnerd: Was ~2-5%

need a consensus network for the DNS checkpoint nodes :')

monerod also has been veery sluggish the last hour

monero*

<ofrnxmr:xmr.mx> Or a patch for the checkpointing node to reject all reorgs 💀

it all adds up

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: this wont work

<datahoarder> Reorgs can come at different times indeed

<ofrnxmr:xmr.mx> there's gotta be a better way

<datahoarder> Something I noticed is that alt blocks don't really get broadcasted or travel around

<datahoarder> even if close to tip

<datahoarder> I have a few custom patches to push these

checkpointing nodes should be all aware of the same alt chains as each other to be able to make good selections

given they are selecting from a bit behind, as well, not just the tip

if they are aware of the existence of two for a height they have to stamp a checkpoint for, that's when they need a deterministic way (given equal states at that point) to select this and publish the dns records

that brings more issues, that monero alone currently doesn't sync this up (you need helpers/patches to push blocks via rpc, monitor alts and make these available to others)

<bawdyanarchist:matrix.org> Question about mining and timestamps. Do hashers in a pool update the header timestamp in real-time as they hash? Or do pools push a timestamp, and the hashers never change it?

Pools push a blob, the blob has the timestamp

The miners just change the nonce field

usually pools push new tasks every few seconds

Why not make the dns checkpoints using .oinion addresses? So there is no worry about issue keys and seized domains

<gingeropolous> @rucknium:monero.social: , dunno if its easy to do, but might be cool for the moneroconsensus thing to show the timestamps of the blocks

TriggerCoder: not everyone has tor on their nodes

Onion address is effectively just one Ed25519 key

morning, seems qubic is having issues irc.gammaspectra.live/4fef6fbad228100a/7_deep_qubic_orphan.png

^ this happens when blocks are found in quick succession close to their tip

they tried to reorg but monero found rest of blocks faster than they could

they are really getting hit by their slow block propagation

<unt0ld:matrix.org> DNS checkpointing is giving to many the impression the devs are just centralizing the coin to themselves at this point. Doesn't all DNS checkpointing effectively do is let reputable miners collaborate? So why not have this as a separate project among legit miners to collaborate among themselves instead. Nothing to do with devs [... too long, see mrelay.p2pool.observer/e/7KOpybAKajZHR1pX ]

miners and big merchants

<monerobull:matrix.org> @unt0ld:matrix.org: we can also phone up supportxmr and the other big pools and tell them to 51% attack against qubic, same effect, simpler to do than developing anything new

<unt0ld:matrix.org> well miners can do a lot of things. for example if i was a big miner, to protest the low mining reward, i would create a cartel to not mine low fee tx lol

<unt0ld:matrix.org> Maybe it doesn't matter though. This collaboration feature can be included in monerod I guess. It doesn't have to be DNS records. Just give node addresses for your node to collaborate with and the nodes do it through zmq or something fast like that

<monerobull:matrix.org> reorg incoming

<unt0ld:matrix.org> "and they keep coming and the won't stop coming"

<monerobull:matrix.org> ok no reorg just a normal block

they lost it :) > <monerobull:matrix.org> reorg incoming

irc.gammaspectra.live/2cb6f98c8e4be398/image.png

this current one, they are depth +2 so they can at least take one out

<gingeropolous> though dunno if timestamp of the block itself or when it is seen by the node would be more relevant

<rucknium> @gingeropolous:monero.social: Done moneroconsensus.info

<rucknium> Only have timestamps on main chain blocks because get_alternate_chains RPC calls gives limited info about alt blocks. I think I would have to query for each alt block header individually by block hash to get timestamp data.

<rucknium> It's the same reason the app assumes alt blocks have nonzero txs.

that timestamp is quite verbose :D

<rucknium> I could reduce it to Unix epoch seconds :P

<rucknium> It won't collide with its height block at the same height since alt blocks don't have timestamps displayed.

<rucknium> There are several papers on checkpointing PoW blockchains. This looks like a good one: Karakostas & Kiayias (2020) "Securing Proof-of-Work Ledgers via Checkpointing" eprint.iacr.org/2020/173

<rucknium> I don't think there's time to read, evaluate, and implement one of these papers' proposals.

could assume utc and do like 28-11-25 11:25:56