<ofrnxmr:xmr.mx> yo > <@longtermwhale:synod.im> qubic had 49% at one point. ofrn "scammer" xmr is downplaying the power qubic has. sell now

this one is getting impersonated in #monero as well

<interestingband:matrix.org> (wtf is happenning)

<rucknium> @interestingband:matrix.org: You asked for evidence of impersonation. Now you've just seen it live :D

<interestingband:matrix.org> Yeah, but you used this as an excuse to remove my writing permissions

<interestingband:matrix.org> and now I'm curios who is this spammer that is writing such stupid insults

<rucknium> You were another reason why I set up stricter moderation in #MRL. Many users complained about you.

<interestingband:matrix.org> I've asked politely kayabanerve about PoS and was waiting for a reply

<interestingband:matrix.org> still waiting

<longtermwhale:synod.im> u won't get a reply

<longtermwhale:synod.im> luke "fed" parker is another scammer

<longtermwhale:synod.im> 200 xmr for a book. serai is never coming out (rug pull)

same talking words as usual for each time

<longtermwhale:synod.im> datahoarder you've been warned

<longtermwhale:synod.im> spreading misinformation about qubic

Literally building tools to spread awareness about Qubic blocks.p2pool.observer

<interestingband:matrix.org> @rucknium: I've asked for a link to "propaganda that was going on in another channel", not impersonation

yes, the one you have pinned in your Discord channel

<longtermwhale:synod.im> i don't have discord

The tools your own staff pins as they are useful

<rucknium> @interestingband:matrix.org: This is true. But impersonation is a form of propaganda.

<longtermwhale:synod.im> what is "staff"? you're crazy datahoarder

staff my balls

sorry #monero-research-lounge it had to be done

<basses:matrix.org> @interestingband:matrix.org: he literally sent irc logs link

on other highlights, added subaddress support + additional tx keys to the InProofV1/2 / OutProofV1/2 creator :D

in go!

Hey, the new UI looks good

when did you update it

a few days ago! SVG as well

it also has pages for all blocks now, including orphans

+ shows withheld transactions if any

example blocks.p2pool.observer/block/15b118…1fa37e3ec76dc79815712753da18057f228

Pretty cool

or blocks.p2pool.observer/block/47536a…bb0563fe6a4bbd0adf8d27e3b0b367e62a3

<interestingband:matrix.org> @rucknium: Many users will complain about insecure cryptography, but you won't do anything about it

<basses:matrix.org> DataHoarder

<basses:matrix.org> mrelay.p2pool.observer/m/matrix.org/JAOzRsaxJEWhTVPFjRSwaoOS.png (clipboard.png)

<basses:matrix.org> does it need all of that?

I load cdn.jsdelivr.net/npm/bootstrap⊙5/dist/css/bootstrap.min.css

DDG no idea why that shows up

(with a checksum)

I don't see DDG locally, so that must be an extension you have

<basses:matrix.org> DataHoarder: I think related to search engine I'm using somehow

I can probably move the CSS in later, everything else is generated SVG :)

<basses:matrix.org> even though I pasted URL directly in url bar

Do you have the DuckDuckGo extension installed

<basses:matrix.org> no just firefox with DDG set to default search engine

<basses:matrix.org> it happens when you visit a link from DDG results

<basses:matrix.org> mrelay.p2pool.observer/m/matrix.org/IomxWpuGeJeJfngcphfJgIQA.png (clipboard.png)

No idea then :(

why did that turn into an emoji

that should be illegal on IRC

it's just local. I see : ( here

<gingeropolous> how much hashrate did bitmain have with their x5? they went somewhere. is their hash signature gone from the nonce maps?

<captaincanaryllc:captaincanarynode.org> 212kh/s

<captaincanaryllc:captaincanarynode.org> some places still have them avail for purchase

<captaincanaryllc:captaincanarynode.org> @gingeropolous:monero.social:

gingeropolous: afaik sech1 said they came down a bit, but still there

<gingeropolous> @captaincanaryllc:captaincanarynode.org: , where? ive looked

<gingeropolous> yeah @captaincanaryllc:captaincanarynode.org , i meant total hashrate. was it 2gh/s? i know this was answered before but i forget

<gingeropolous> so a publish or perish with an infinite k would essentially make us dependent on a 100% connected internet. Which is probably more probable than the case of a malicious actor attempting selfish mining.

<gingeropolous> ugh that wasn't worded right.

<gingeropolous> but yeah, with an k=infinity, the "only" thing a 51% attacker can do is mine empty blocks.. but they are still competing with the honest miners, so its not 100% censorship. They can't initiate massive re-orgs, so they can't do double spends....

<gingeropolous> and in case the internet does break, then the DNS checkpointing system could be used to get things back on track.

<gingeropolous> the probability that the internet will stay connected is greater than the probability that the monero network will be attacked by massive hashrate

<gingeropolous> there we go

<gingeropolous> no thats not it. damnit. im going to sleep

<gingeropolous> the probability that the internet will split is less than the probabilit that the monero network will get attacked by massive hashrate. yeah i think thats it

<gingeropolous> k = infinity for the win

it'd have been funny if libera.chat would have had a netsplit just now

<torir:matrix.org> In the event that the chain reorgs back to the original chain, I guess. > <@monero.arbo:matrix.org> I missed if someone already asked.... but why the fuck are invalid transactions tuffed back into the mempool

<torir:matrix.org> It's an odd situation, certainly, but it is technically possible for those transactions to become valid again if another reorg restores the original chain.

<torir:matrix.org> I think it's just a rare edge case that didn't come up until now. Sure, the behavior doesn't make sense in this context, but the behavior is correct in the more common situation where only one block is reorged.

<interestingband:synod.im> interestingband:matrix.org still waiting

<interestingband:synod.im> interestingband:matrix.org Btw, do you all understand that it's all about how much money are needed in order to compromise consensus and conduct the worst possible attack (double spending ?) ?

<interestingband:synod.im> interestingband:matrix.org For example, how much money sholud be paid to someone who owns these DNS domains in order to cause chain split (for example two different sets of exchanges that accept XMR) and do actual double spending ?

<interestingband:synod.im> interestingband:matrix.org 0 people here who can verify cryptography is funny

<torir:matrix.org> Okay, so you are proposing an attack where malicious DNS servers present different checkpoints to different nodes to force a chain split? The current proposal I believe is 7 checkpoint servers with 5 needing to agree on a checkpoint before it gets enforced. So you would need to control 5 of the DNS servers to cause a chain spl [... too long, see mrelay.p2pool.observer/e/vYjBrbUKa2lKLUVX ]

<ofrnxmr:xmr.mx> Youre talking to an imposter

<helene:unredacted.org> how come he can still speak

<torir:matrix.org> Whoops.

<helene:unredacted.org> this is truly like the hit video game among us

<torir:matrix.org> Clearly the imposter is speaking in bad faith, but the attack is interesting to think about. It wouldn't be an easy attack to execute, and it would be very easy to detect, since (correct me if I'm wrong), it would be straight-forward to publish the conflicting DNSSEC-signed records and prove that the DNS servers were misbehavi [... too long, see mrelay.p2pool.observer/e/hbrlrbUKMk91US14 ]

<helene:unredacted.org> i love that the impersonator is prepending their messages with the matrix ID of who they're impersonating

<helene:unredacted.org> trying to fool IRC users lol

<helene:unredacted.org> @torir:matrix.org: it's not a real attack simply because you can turn it off, and one chain is gonna keep getting mined while the other isn't

<interestingband:matrix.org> What ?

<interestingband:matrix.org> it allows to do double spending, how is that not a real attack ?

<helene:unredacted.org> if no one trusts that form of consensus i fail to see how it could take over the network

<torir:matrix.org> It seems close to an eclipse attack to me. If pulled off, you could force the victim to have a different view of the chain. As I understand how --enforce-dns-checkpoints works, the victim node will ignore all other blocks if it is presented with valid 5/7 DNS records for an alt chain.

<torir:matrix.org> Of course, you would have to mine all the blocks on the alt chain yourself, so you'd have to invest in mining as well.

<helene:unredacted.org> yeah

<helene:unredacted.org> hence why i feel it would be interesting to have other checkpointing providers that can be configured by the node admin :) would allow for some diversification, if one wants to enable this feature

<torir:matrix.org> It might be possible against an automated exchange or something if you can A) compromise 5 DNS servers run by reasonably well-trusted community members B) convince those community members to tarnish their reputation, since the attack can be proven to have occurred, C) successfully identity the node the exchange uses D) success [... too long, see mrelay.p2pool.observer/e/9ZaErrUKa1A5U1pa ]

<helene:unredacted.org> that's a lot to be asking, honestly :) not impossible, but a lot

<torir:matrix.org> I think a fair mitigation, if we feel the need, would be to have nodes share the DNSSEC-signed records that they see via some gossip protocol. Of course, if we had such a gossip network we wouldn't actually need DNS at all.

<torir:matrix.org> But if we had a gossip network conflicting records could easily be detected.

<helene:unredacted.org> there's quite a few things that can be done overall

<helene:unredacted.org> the problem is also the part where you're trying to isolate DNS requests to a specific IP/requester: it's kind of impossible in most cases

<torir:matrix.org> Yeah, I don't fully understand DNS myself, but my current understanding is that you are likely to use the same DNS server and see the same cached records as at least one other node.

<torir:matrix.org> Especially if you use a big service like Google or Cloudflare's DNS.

<torir:matrix.org> So an even easier mitigation is to just config a big DNS server for your node.

<torir:matrix.org> Or even if you use your ISP's one, your ISP might just proxy to a larger upstream server anyway.

<helene:unredacted.org> The only way you could give different responses to a DNS request is to run custom malicious nameservers for the hijacked domains (and the fact that you're running custom nameservers would have to be visible by everyone), and to reply different things to a specific IP (or packet format, very unlikely unless your resolver is a c [... too long, see mrelay.p2pool.observer/e/hdmdrrUKX2ZjYzRS ]

<helene:unredacted.org> Ironically, the domains being on Cloudflare offers a certainty that they're not being that kind of malicious

<torir:matrix.org> There was a conversation earlier about running custom nameservers, wasn't there, to get around Cloudflare's 300 TTL? Or maybe I mis-skimmed that.

<torir:matrix.org> I dunno. But I do think it is not a realistic attack. Especially compared to the more realistic potential of a double-spend attack from Qubic.

<helene:unredacted.org> well, qubic could have done a double-spend already

<ofrnxmr> They did 117, just not their own

<helene:unredacted.org> they could've been backed by someone who wanted to defraud an exchange or similar :p

<torir:matrix.org> There is already a possibility here for anyone to double-spend. Just automate deposits to an exchange when Qubic is ahead some amount on qubic-snooper.p2pool.observer/tips.txt and withdraw if they don't get a long re-org.

<torir:matrix.org> Or even just automate depositing and withdrawing over and over. If Qubic does another big re-org, you might get lucky.

<torir:matrix.org> If the exchange asks, you have a bad arbitrage script that withdraws automatically when it detects the arbitrage opportunity has disappeared.

<interestingband:matrix.org> huge exchanges already increased number of confirmations

<interestingband:matrix.org> they aren't stupid

<torir:matrix.org> Yeah. There might be one or two out there that haven't.

<torir:matrix.org> Maybe a swap service?

<ofrnxmr> how many for mexc and kucoin?

<ofrnxmr> Last i checked kucoin was 12 and kraken 32

<plowsof:matrix.org> is fixed float still 3? 😅

<interestingband:matrix.org> it's 10

<plowsof:matrix.org> ok good, it was 3 last i checked while this was still going on

<plowsof:matrix.org> "they aren't stupid" sadly it seems kraken was relying on monero wallet cache to actually work and save information

<torir:matrix.org> There is almost certainly a target out there that has not kept up with recent news and increased required confirmations. How many confirmations does BasicSwap require?

<plowsof:matrix.org> a large exchange not backing up information to an external database and relying on monero wallet cache monero-project/monero #10067#issuecomment-3271441030

<torir:matrix.org> On the one hand, when you have to integrate hundreds of coins into your exchange, it can be tricky to fix edge cases for each and every coin. On the other hand... if you were to do the sensible thing, write a generic framework that can handle many types of coin, wouldn't it make sense to store all the information about all wit [... too long, see mrelay.p2pool.observer/e/jKOqr7UKNjMxSU9X ]

<ofrnxmr> @torir:matrix.org: The script (btc) coin moves first

does anybody know how the DNMs have been dealing with the potential reorgs? I assume they have also increased their confirmation times?

<ofrnxmr> Number of xmr confs before releasing the script coin is set to 3 by default, but can be changed by the user

<torir:matrix.org> Where is the option to do that?

<ofrnxmr> basicswap.json, in the monero section

<alexanarcho:matrix.org> What happens if a reorg happens on a coin that was spend as soon as possible?

<alexanarcho:matrix.org> Will both transactions go back to the mempool? Or will the second transaction become completely invalid?

<plowsof:matrix.org> of the 117 or 118 invalidated transactions that we know of, can anything be inferred from/about them with regards to the above^ e.g. we had 8 blocks for people to spend unlocked funds iiuc

09:31:44 <br-m> <torir:matrix.org> There was a conversation earlier about running custom nameservers, wasn't there, to get around Cloudflare's 300 TTL? Or maybe I mis-skimmed that.

The program works and has been tested, whether this setup is to be used is not up to me :)

But from tests they are the first to switch and become consistent

<helene:unredacted.org> RE: monero-project/research-lab #145 I feel that calling them "lucky transactions" is a bit of a misnomer, at least if I understand the proposal correctly

qubic has not been attempting selfish mining as of recent

their blocks are published when found directly now (no withheld transactions either)

but they also only have like max 1-2 txs

most have 0 txs, so back to empty block mining

since they stopped selfish mining their efficiency numbers seem to have gone up, so they are making more by just straight up mining

<helene:unredacted.org> how does blocks.p2pool.observer determine that a block has not been disclosed? it currently marks all of the qubic blocks as "selfish" but it seems that they've been disclosing them so far at least > <DataHoarder> their blocks are published when found directly now (no withheld transactions either)

it doesn't mark as selfish

the red refers to the part behind the background

not the proof :D

<helene:unredacted.org> oh yeah! my bad!

they haven't disclosed view wallets yet

as for how

look at their stratum mined height and id

you can find an id there you don't see in the network, and how many txs it has

I keep track of these - and keep looking for alternate blocks across a large set of monero RPC to find if they ever make it to network

then I cache them and their whole block template, for safe keeping

then they have full information

<helene:unredacted.org> i figured it would work as much :) thanks for the confirmation!

it's a bit more on the face how it works when looking at qubic-snooper.p2pool.observer/tips.txt

<helene:unredacted.org> i somehow find that more clear to look at, so i've been looking at it the most :D

that shows only that status ofc

blocks. is more of an after-the-fact explorer

but also can show any selfish blocks as well, as a bonus (it looks at the data source for tips) but it doesn't add them to database

you can see this in the source code

-nodejs-pools param that allows me to query that similar API internally, could use this for anything else

plus another api for the withheld txs

<helene:unredacted.org> both views have been interesting to look at, thanks for your work and for taking the time to explain it to me! :)

I have a list of transactions that have been invalidated. These were found in blocks 3499670 to 3499676 on the altchain. These are displayed as blue here

irc.gammaspectra.live/3d4322617de1e118/image.png paste.debian.net/hidden/5ea3d92e

these transactions are currently unmined in mempool or no longer found (@rucknium:monero.social should have an archive of these)

in total 115 transactions

I am adding the markings to the blocks page in a bit :)

I still have quite a few stuck transactions on my node p2pool.io/explorer/txpool

They just keep returning after flush_txpool

4 stuck at the moment

sorry I didn't flush after wiping

hmm, this stuck transaction p2pool.io/explorer/tx/ef608776beee2…640fc3f9cf12d6bdcb108259c30140fd1e6 has decoys from today, so after the big reorg. It must be some different reason why it's stuck

Maybe it used decoys from reorg'd blocks? i.e. that wallet was online when reorg happened, and wallet cache got borked somehow. Just a theory

I don't check these, only transactions that were included in blocks on reorgs

I wrote this ""short"" explainer trying to condense invalidated transactions and global output indices irc.gammaspectra.live/6faf582e1accfb25/image.png

I don't know how good the wording is.

<rucknium> DataHoarder: Can you make sure to save the whole txs for archival purposes? My txpool archiver saves txid, fee, weight, and key images of inputs, but not the whole tx.

ouch

lemme see

<rucknium> Otherwise, the archiver would be as large as the blockchain.

Yeah. that's why I didn't want to archive them myself :D

more hoarding I guess

<rucknium> I have nodes that I didn't flush the txs. I can save them if it's not easy for you.

I can save them, just need to add it onto the code

I'll mention which txids I don't have yet

But more importantly, wording notes :)

<rucknium> I may try to create a diagram that explains tx invalidation when the output index changes.

I don't think calling entities that explicitly cause invalidated transactions past 10+ reorgs and affect users "malicious attackers"

the diagram: irc.gammaspectra.live/e304f162614845e4/image.png

<rucknium> lol I thought I missed your diagram or something.

I can link it there later once it exists, it's a very internal detail otherwise

<ofrnxmr:xmr.mx> Actual photo of the last mrl in-person meet

I think that's something MRL could put a statement out, specifically around global output index issues on big reorgs / invalidation of these txs?

<rucknium> Probably.

<helene:unredacted.org> keeping them in some transparency log somewhere could be useful eventually anyway if wallets would want to notify users that privacy could be compromised on subsequent transactions (and to push them towards making a change transaction or something to recover somewhat)

I'll be storing them rucknium in json/hex blob but I won't get to use them (I need liveness) but should have them stored for future usage

<rucknium> Thanks!

I'll present an endpoint to fetch these. Note I'll only save txs not mined by others, and only from blocks past +10 deep from tip

so it should have a very limited storage set

<rucknium> DataHoarder: Here's the code for the txpool archiver if you want to run it locally: rucknium.github.io/xmrpeers/reference/txpool.collect.html

got them all stored

115 of them

endpoint for them blocks.p2pool.observer/tx/1ddccf341…84b04a7f6be7d455b4ca206a99ec7f/json

<ofrnxmr:xmr.mx> I thought 117?

not the ones I detected

the others have been mined by other means

I explicitly looked at txs in blocks that I had and were not mined yet/in pool, or that did not exist at all anymore (flushed)

all the others I could find mined

if you have a full list I can compare them

<ofrnxmr:xmr.mx> Ok, will check in a few. Preparing that update for the dns pr

^ as for the endpoint, JSON output, but has the 'blob' entry which should be the full tx

the rest of fields won't get updated, so don't expect double_expect_seen to flip to true

you can see blue blocks in blocks.p2pool.observer as well and get the listing per block

Ctrl+F for 3499660 to scroll there :)

or open full listing

relevant blocks with invalidated transactions

<jeffro256> > <@radanne:matrix.org> mrelay.p2pool.observer/m/matrix.org/BhyBBdUeqPNtFvmgPgSMvavJ.png (image.png)

<jeffro256> This made me laugh out loud. Don't they know not releasing XMR back into the wild doesn't prevent anyone else from receiving / using it, it just raises the price of the remaining units? In what world would the gov auctioning back seized XMR cause increased adoption of XMR amongst criminals?

<basses:matrix.org> @jeffro256: liquidity

<basses:matrix.org> says in the higlighted text

<basses:matrix.org> same reason they don't sell smoke seized crack and some it themselves

<ofrnxmr:xmr.mx> They do tho, if you go to the right sheriffs office

<ofrnxmr:xmr.mx> wouldnt be surprised if they stole a lil xmr here and there too

<ofrnxmr:xmr.mx> I got robbed by border agents before, lol.

<basses:matrix.org> @ofrnxmr:xmr.mx: happens always with corrupted cops

<helene:unredacted.org> that's the big advantage with crack: you can smoke it before they can steal it from you

<basses:matrix.org> @ofrnxmr:xmr.mx: rip

<jeffro256> I understand that they think that that would have a negative effect on liquidity, but which criminal would be buying XMR directly from the government, ostensibly using traceable online payments? And usually criminals are long cash (or XMR in this case), they aren't buying it, so a decrease in liquidity in this direction helps them.

<basses:matrix.org> @basses:matrix.org: in some other corrupted countries they ransom you

<jeffro256> As long as any working DEXs exist, criminals can sell. If the gov allowed selling, the gov could undercut criminals by selling XMR at market value or a loss. But if they choose not to sell, then criminals get to be relatively more important market makers.

<basses:matrix.org> they see crypto as a tool that can be easily used criminals than obtaining cash

<basses:matrix.org> so want to minimize that and while being the biggest holders of such coins

Added a description feature to blocks.p2pool.observer, now mainly has a big box for Qubic blocks.p2pool.observer/block/06beef…fb01d5f73616a5fdff5167c799725ce6db1

> Qubic is now unequivocally considered a malicious attacker, not only affecting end users but additionally harming their privacy permanently.

and for P2Pool blocks.p2pool.observer/block/978d24…c35d0c8859d27957f125ce263833954af0b

<sneedlewoods_xmr:matrix.org> thank you a lot DataHoarder for all the work

I do what I can besides hoarding data :)

Really most of this is thanks to me reimplementing p2pool in Golang here git.gammaspectra.live/P2Pool/consensus and as a side effect implementing half of monero utilities

so I always have something almost "drop-in" for about any section of it

<helene:unredacted.org> oh damn a go randomx implementation

oh yeah. also random side project

<torir:matrix.org> Couldn't the senders of the 115 invalidated transactions preserve some of their privacy by crafting custom transactions that contain all the exact same decoys except the ones that were invalidated?

that is what ringdb would allow, yes

except it got invalidated as well in the reorg

<ofrnxmr:xmr.mx> DataHoarder: yup lmao

<rucknium> AFAIK, there is no custom code written to do that. You also need info from the node about re-orgs, which could introduce its own privacy risk if you don't run your own node.

<rucknium> That idea also wouldn't work properly if the invalidated output is the real spend. Privacy actually could be better in that case because you could construct a ring with none of the same ring members (by index). You would have to handle that case separately.

does crack have 12 decimal places?

<ofrnxmr:xmr.mx> No

only 10

<ofrnxmr:xmr.mx> Only 2

<ofrnxmr:xmr.mx> Sometimes 4

he's on crack

<radanne:matrix.org> @jeffro256: Yes, the paradox of the official story is quite funny :) May or may not be the true intent. A) naive but true B) great use for secret agencies C) could be used for PoS if we ever gone down that route

<privacyx> I would like ask and try and understand what trade offs if monero tail emissions where raised from 0.6XMR to say 1 XMR which would increase mining rewards and profitability and have very small immediate affect on inflation going from 0.8% to 1.2% which would go back down is there something Im missing,? I see it would increase [... too long, see mrelay.p2pool.observer/e/4aekxbUKRkpNOXRy ]

<rucknium> Expectations are very important to economic behavior. Break expectations and you break a lot of things.

<rucknium> The Monero protocol won't do that.

> from 0.6XMR to say 1 XMR which would increase mining rewards and profitability

that's looking at current situation and $ directly

it'll increase rewards. profitability attracts people

then it'll become unprofitable again

as there are people that mine monero at a premium to get it anonymously

besides yeah. emission expectations.

<radanne:matrix.org> Non-profitability is a protective feature of PoW, not a bug. An adversary eventually runs out of resources. Mining will become profitable if NGU. Then more miners join, more security is added, and then it becomes non-profitable again. Deliberately engineering sustained profitability would undermine decentralization and security. It would invite attacks or monopolies.

<ofrnxmr> The only positive if increasing the emission would do is, theoretically, make for a more fair distribution. But not in practice. that would only work if the assumption that the majority of miners are normal people. 70mh miners on p2pool, 100s of mh available for rent, thousands being run by cfb. Increasing the emission only ho [... too long, see mrelay.p2pool.observer/e/u8axxrUKQjRRMzlV ]

<ofrnxmr> There are projects with 5, 10% emission rates, and the result is that there is an increase of sell pressure as compared to the current supply.

<ofrnxmr> Increasing emission doesnt fix anything. Why stop at 1xmr? Why not 10? Why not 100?

qubic has not been selfish mining this entire marathon so far

<ofrnxmr> Answer: you arent creating value out of thin air.

their efficiency keeps going up thanks to that

<ofrnxmr> DataHoarder: I imagine they got yelled at by one of their investors or exchange partners

well, they also made less overall with selfish

they don't have a proper implementation of it

<ofrnxmr> Therrs a high chance that one of their exchange partners (like mexc) had to deal with a broken wallet due to invalidated tz

or the network vs simulation differs

also very likely. CfB was surprised at how could the txs not be on both branches

started asking questions, then started doing damage control with the tweets about how it was not possible to invalidate txs

<ofrnxmr> Yep

<lordx3nu:matrix.org> @ofrnxmr: I saw a screenshot on twitter where cfb said they would no longer go over 9 block reorgs because they didn't want to invalidate transactions. 100% damage control

<rucknium> I thought this was made clear to CfB, but I'm not in the Discord servert

<rucknium> server*

they also instantly started trying to ask community/validators to vote to turn off selfish

it was made clear, we tested it on testnet, we talked about it, he quoted the messages of us talking about it

<rucknium> I created this exact situation on testnet to show it was possible

it's no mistake, they got everything wrong and did an active attack not only against miners but Monero users

<rucknium> Well, not exact. I did an exactly 10-block re-org, not 18-block

as I have labeled them on blocks.p2pool.observer, Qubic is now unequivocally considered a malicious attacker, not only affecting end users but additionally harming their privacy permanently.

before it was plating with profits, delaying transactions, some spam of txs or not helping around

<rucknium> I'm a little overloaded on workload right now, but I will try to write a blog post for my own blog with diagrams about how txs can get invalidated with 10+ re-orgs

it was an attack, malicious? that was less 100% clear

yeah. good luck specifically with also explaining how the global output index get generated and referred to :)

<rucknium> Those invalidated txs are still in the testnet txpool: testnet.xmrchain.net/txpool

<rucknium> They should drop out in about 12 hours since that will be a full week since they were invalidated.

<rucknium> DataHoarder: It isn't that hard, is it?

They should publish view keys on wednesday, but I don't see much point on them rotating these keys

<lordx3nu:matrix.org> heres a discord screenshot: xcancel.com/AvdiuSazan/status/1967539290566713709

rucknium: well, with this you have a second abstraction layer as how the first refer and the second refer to first

it's clear how they are referred, making it look nice, is different

<rucknium> You mean the cumulative sum notation?

<rucknium> It's my job to make it look nice (sometimes)

refer to image.png meme :)

<rucknium> which is not easy, but worth it. To communicate to the community and others.

I have tried to do a similar visualization for p2pool observer with the sweep tool

didn't get anywhere so I just show a table and links

<syntheticbird> @lordx3nu:matrix.org: There is only one men speaking in this screenshot

<rucknium> This will be static with a single example, so won't be too hard I think.

example p2pool.observer/transaction-lookup?…25df90ef578ca012258f34308ec53e38071

well you have the list. hopefully you get a 2in 2out that got reorg'd (but not invalidated) and then a 2in 2out that got invalidated

<basses:matrix.org> @lordx3nu:matrix.org: why it says AI generated content at left bottom?

^ this tx is a good example of adding up previous sweeps as well

there was a meme in that cutout

<lordx3nu:matrix.org> i am not sure. I don't use discord

<rucknium> Anyway, I found two useful things for DNS checkpointing:

<rucknium> 1. set_log checkpoints:TRACE will print all of the enforced checkpoints every time the node makes a DNS request for them.

<rucknium> 2. If you put a checkpoints.json file into the directory with the blockchain, it will putllthat every time it checks DNS records. (I have not tested this yet, but I will soon) :github.com/monero-project/monero/bl…a/src/checkpoints/checkpoints.h#L40

<rucknium> That looks like another way to manage checkpoints. Before, adding an RPC method to add checkpoints to a node had been discussed.

<rucknium> I don't think this was documented anywhere except in this Reddit post from 2014: reddit.com/r/Monero/comments/2ixfe4…_missives_weekly_report_october_6th

<rucknium> I now have testnet checkpointing at these seven domains using a delegated DNS server though monero-highway : checkpoints2.redteam.cash checkpoints2.moneroconsensus.info checkpoints2.moneronet.info checkpoints2.townforgepool.net checkpoints2.townforger.net checkpoints2.moneroresearch.info checkpoints2.bchmempool.space

<rucknium> That matches the number of moneropulse checkpointing domains that will be used for the next release. So, the tests can be fully realistic.

<rucknium> The tests are not easy because of DNS record propagation latency.

<rucknium> A few timing parameters can be adjusted to get good behavior of the system, but we don't know the exact best parameter values yet.

<rucknium> These parameters are: DNS record TTL, frequency of nodes checking DNS records, and frequency of the DNS records being updated to the latest "finalized" block.

Additionally: checkpoints.gammaspectra.live uses Monero-highway dns-checkpoints but also has secondary DNS replication setup, with instant updates via ZMQ

<puff1k:matrix.org> If pubic is douing "bad thing", harming economy, project, etc. Why we can't just report their leader to police, for "managing big botnet for attacking a service" and at least win some time to think about an update before any significant damage is done?

<ofrnxmr:xmr.mx> Theres nothing stopping you from doing so