@rucknium:monero.social, p2pool api now also returns orphan blocks, monero-blocks had an update to support this new format (and mark blocks as orphan) but old one keeps working, just labels blocks as valid

I have added direct Proof verification (from monero coinbase verification) to qubic-snooper.p2pool.observer/tree ; This currently works with either disclosed pools view keys or disclosed tx private keys for each coinbase tx. Proof is shown and can be clicked to get a full proof in an explorer.

Current pools: P2Pool (all public), MoneroOcean, Qubic (delayed one week). If any other pool wants to disclose their view keys they can be added, otherwise the matching is done via their public APIs and taken at face value (but not verified)

deployed onto blocks.p2pool.observer, also shows when proofs fail. irc.gammaspectra.live/45ebcfb298833c14/image.png qubic does not release view keys for the current week and as such all their blocks will fail verification unless they provide the view keys. Their previous blocks (from last epoch) pass fine!

irc.gammaspectra.live/564f3b491897662a/image.png

Source code is also available on git.gammaspectra.live/P2Pool/blocks.p2pool.observer

Full plot is on blocks.p2pool.observer/fullplot.svg without cutouts

<longtermwhale:matrix.org> Whats the bottleneck on resolving the qubic situation? funding needed?

<longtermwhale:matrix.org> (sry for crosspost)

<syntheticbird> @longtermwhale:matrix.org: Currently research bandwith and productive discussion between research members for a viable solution.

<syntheticbird> my apologies @longtermwhale:matrix.org to be precise multiple long-term solutions has been proposed but they all have tradeoffs or unquantified caveats. Short-term however, DNS based checkpointing is currently being tested.

<ofrnxmr> @longtermwhale:matrix.org anyway, there is a pr open for the dns checkpoints

<rucknium> @longtermwhale:matrix.org: I personally put a lot of time into trying to attract researchers to work on Monero research topics when I was on the MAGIC Monero Fund committee (2022-2024). I had mixed success.

<ofrnxmr> The main things to discuss are

<ofrnxmr> 1. Depth to checkpoint

<ofrnxmr> 2. How many checkpoints to save

<ofrnxmr> 3. How often / what trigger to push new checkpoints[... more lines follow, see mrelay.p2pool.observer/e/7-aazbQKQTlEdWxw ]

<ofrnxmr> 5. Contacting mining pools after releasing new version, to ensure theyve updated and are successfully receiving the checkpoints

<ofrnxmr> Thats a 5

<rucknium> Researchers are very specialized. And there is a lot of inertia. I will try to explain: A researcher's first question is whether a research question fits into their research agenda. Lots of funding can help encourage someone to look at a research question, but funding is not the only term in the equation, let's say.

<rucknium> It takes a lot of effort o get to the research frontier of a research question. You want to do a very good, thorough job. You don't want to misunderstand the system you're trying to study or fail to read papers about the research topic.

<rucknium> to get to*

<rucknium> So, the question needs to fit into your research agenda (now) or at least the question is in a territory that you want to explore and you think will lead to lots of fruitful research.

<longtermwhale:matrix.org> soooo... more monero stickers in universities

<rucknium> With a fast-paced research area like blockchains, the research questions can change while you are trying to work on them. I mean, a research question can become irrelevant/obsolete.

<rucknium> Which is something that happened with some research on churning we were helping to move forward with University of Zurich: by the time things would have been ready to start funding, FCMP was in a late stage, which will make churning an irrelevant research question.

<rucknium> I think more funding can be helpful, but not in short bursts. It is hard to maneuver when you don't know how much fuel you have.

<rucknium> With the MAGIC Monero Fund, we funded vtnerd for 3 months of work. I think it took a month and a half to get it funded when MAGIC was the fundraising agent. When it is the CCS, vtnerd is usually funded in a week or two. The slow funding of vtnerd made me worry that we couldn't fundraiser for less-known researchers when we would need to.

<rucknium> I think frankly @diego:cypherstack.com at Cypher Stack does a pretty good job of handling these challenges. He can bring new and "old" researchers together. Of course, Cypher Stack does not work exclusively on Monero.

<rucknium> Programmers are another beast and I don't have much useful to say about the challenges there, with respect to having more high-skilled programmers work on the Monero protocol.

<rucknium> Cypher Stack has its own centralized decision structure and economic self-interest in acquiring and "deploying" researchers. I think that's why they can be successful. MAGIC and the CCS aren't like that. Well, MAGIC is somewhat centralized, but there is not economic self-interest of the MAGIC committee members to get contracts, etc.

<diego:cypherstack.com> @rucknium: I'll probably have Josh work more on Monero directly. One of my devs. Sneurlax.

<diego:cypherstack.com> Inb4 Cypher Stack is the blockstream of Monero

<syntheticbird> @diego:cypherstack.com: blockstream as Blockstream with a capital B ? I heard they weren't very appreciated

<rucknium> Here is my little manifesto from years ago: "The Monero Project should actively recruit technical talent from universities" reddit.com/r/Monero/comments/pkg3d6…ero_project_should_actively_recruit

<rucknium> My efforts fell short 😢

<diego:cypherstack.com> @syntheticbird: Blockstream hired core devs on Bitcoin to work on Bitcoin. One of the debalces there cuz they said Blockstream accumulated power to change bitcoin

<diego:cypherstack.com> When many of the devs were just looking to continue working on Bitcoin but not starve.

<diego:cypherstack.com> And no alternatives were offered other than that they should work on it for free for the love of the game.

<diego:cypherstack.com> Thanks for the kind words @rucknium:monero.social:

I only shill

ofrnxmr: the big point still, 5/7 without matching records individually (instead of matching the whole record-set) will not work with that new size if continuous updates are expected

something that could be a compromise there is to match record-wise, up to the highest that all agree properly OR that existed previously in the node (which allows rolling)

that way higher ones only come into effect once enough records have all agreed, without "holes"

<ofrnxmr:xmr.mx> DataHoarder: Right, thats point 1 and 2

<longtermwhale:matrix.org> nioc: i think every major core contributor who is with us for more than 3 years should get a 5k direct donation, where is @plowsof:matrix.org for coordination 😇

not only. this is about the way we verify DNS records

(the technical part within monerod) and not the part of how we select them

even if we just expose one, DNS latencies on subpar setups will cause them to mismatch most of the time

with 3/4 that was "doable" due to random chances that entire record set matches

since you are a longtermwhale I think that you should act on your idea

<ofrnxmr:xmr.mx> To have matching records, at the time of the checks (5 minutes), the values of 5/7 have to match

it's a nice thought

and that's as said assuming all domains work fine - if two are down/unreachable all the others have to match

<ofrnxmr:xmr.mx> yea, but if were starting with moneropulse-only, theyll likely all be up

remember a slight off time (something cached for longer, tiered caches) already moves you into the previous window. DNS replication is not instant

<longtermwhale:matrix.org> nioc: thats why i am here

ok to illustrate the example. state of 1-7 is all consistent. new checkpoint is pushed [T=0] records TTL is 5m

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Its more of an issue if we have to deal with independent updating of records

T+1 client1 checks, 1-2 has new state, 3-7 nope

T+2 client2 checks, 1-5 has new state, 5-7 nope (valid)

we push new records

[T = 3]

T+4 client1 checks, 1-2 has new new state, 3-5 has "new" state, 6-7 has olderstate. mismatch again

the difference is T+4 is using ISP and ISP is using a upstream dns with tiered cache

this can repeat until by random chance they all match

client2 uses a recursive resolver with minor caching

<ofrnxmr:xmr.mx> I think thats only an issue if TTL and caching is less than or equal to the check time

remember. they don't respect TTL

ttl is a hint

DNS providers and OS and everything in between will do garbage with it

it's a system with eventual consistency

<ofrnxmr:xmr.mx> Again why we'd be recommending the pools use specific dns providers

but given we check records as a set, no single set will be consistent

yeah, and minor to no local caching. Recursive resolver setup

but still - it's DNS. It can fail in fun ways, which is also why we have the 5/7 (or 3/4) before, assuming domains being taken out is not even incorporated

I am using a recursive resolver and docker domains keep resolving to bogus ips

why? because TTL

and local system caches differently, ofc, then requests to my recursive resolver, which needs minor caching, and one of the different sets is outdated but gets served + refreshed in the background

<ofrnxmr:xmr.mx> before it was half +1, 3/4 because of there were only 4 in the codebase, but essentially the rule was "more than half"

before we also didn't want to update them continously

eventual consistency works for that. you set new ones, and wait for rules to deploy

<ofrnxmr:xmr.mx> DataHoarder: And they were only checked once per hour

it takes 5m or 8h, don't care, eventual consistency

<ofrnxmr:xmr.mx> Which is why i think updating them every 10mins and checking every 5 should work

but - our new records will be continuously updated and active

<ofrnxmr:xmr.mx> Assuming local dns caching is irrellevant

that is now how DNS is expected to work, setting the records != client asking and seeing that record

the timer on each domain can be different - causing the issue where domains end up desync'd from each other

<ofrnxmr:xmr.mx> Why would they be different if they are all updated at the same time, from the same accoint, on the same provider?

provider has regional dns

these records get pushed async, not atomically

these spread slowly across their systems

even by the time we push a new one some of their systems might not have updated

usually it can be faster

<ofrnxmr:xmr.mx> Well i think we should just test it

<ofrnxmr:xmr.mx> Get BF to add a new subdomain like testpoints.moneropulse.xx

yes. we need to gather more data with proves all about

testpoints exists :D

but it's empty

<ofrnxmr:xmr.mx> And we can check on our vsrious machines to see if they are updating in sync

basically, make a set of records that updates each minute with a known token

for that specific time

or a counter, that works too

note in a desired setup they all wouldn't be on the same provider on the same account - as that's a single point of failure

<ofrnxmr:xmr.mx> Just need to run whatever script we plan on running, with whatever params we plan on using

<ofrnxmr:xmr.mx> And check them locally

you cannot issue them every N minutes either\=

<ofrnxmr:xmr.mx> DataHoarder: Were not looking for long term solutions here

monero heights might go faster or slower than that

<ofrnxmr:xmr.mx> Were looking for immediate rollout to prevent current malicious activity

yes, but the short term solution should consistently work

<ofrnxmr:xmr.mx> DataHoarder: Yes, i said every *5 and *0 block, which is roughly every 10mins

also - let's log the MDEBUG