<rucknium> DNS rolling checkpoint protocol in flow chart form: cryptpad.disroot.org/diagram/#/2/di…DUJzvAB5vAc9X9ujFVAsxGAxgMMyE/embed

<rucknium> Not 100% technically accurate, but close.

<rucknium> Maybe DataHoarder and/or @ofrnxmr:xmr.mx could review. There are 5 pages. Click the arrows that appear at the bottom of the screen.

<rucknium> Writing this made me wonder if it would be easy to write a chain-consistency sanity check into the actual monerod code. Now, checkpointer.bin performs the check before issuing the checkpoints.

<rucknium> "chain-consistency sanity check" = do not issue checkpoints of blocks that are on different alt chains. Doing so causes nodes to get stuck.

an RPC method to get inclusion of a block in X chain would suffice?

unless it's specific for checkpoints

eg, does h1 have h2 as part of its root? (is h1 in same chain?)

you can do so with a couple of apis (or manually walking previous at the moment as done in checkpointers)

<rucknium> m is depth of checkpoints (m = 2 by default)

<rucknium> R is the number of nodes that the checkpointer pulls from to determine what the checkpoint should be (1 now)

<rucknium> Sis the number of moneropulse domains (7 now)

<rucknium> d_c is sleep delay for checkpointer process of submitting checkpoints to the DNS server (5 minutes now)

<rucknium> d_d is sleep delay for node (daemon) process to check for new DNS checkpoints (2 minutes now)

checkpointer.bin is quite a bit simple :) "Nodes concur on new checkpoint"

<rucknium> The major events are:

<rucknium> FINALIZE_BLOCK: checkpointer.bin submits a checkpoint to the DNS server

<rucknium> BIND_CHECKPOINT: a node with --enforce-dns-checkpoints stores a checkpoint in RAM and beings enforcing it.

<rucknium> DataHoarder: Check the next page for the subroutine.

is that the current or suggested behavior?

BFT is not in checkpointer.bin at the moment

<rucknium> Technically it is the current behavior when R = 1 :)

<rucknium> Yes, it is suggested at this time.

then it uses get_last_block_header to get the block hash - all the walking is done on block hashes, not get_height or get_block_header_by_height

and get_block_header_by_hash

this allows the walk to succeed no matter the state (as RPC is not atomic/locked and may change in the middle of iterating)

but I agree on the BFT part otherwise

<rucknium> So you do an iterative walk? That makes sense to prevent the race condition.

<rucknium> More calls, expanding linear in m, I think.

yes, and hashes can always be cached (plus sanity check later on that these still exist in monero to prevent a restart flushing a misconfigured monerd)

we know an id will be the same across all nodes

I see for BFT it indeed would have to call get_block_header_by_height

but alternatively seeing if the node knows about the hash is enough too, depending on mode (does node think <hash> is on current canonical chain, or does node have <hash> in its memory and can switch to it)

you get two different behaviors here

<rucknium> I think the checkpointing nodes shouldn't have switched to an alt chain at this point. If they have, then let them do it without setting a checkpoint then. It could have been a benign shallow re-org.

if that's done - producing reorgs and attacker publishing half of these across the network would pause checkpointing, even if all checkpointer nodes have access to the alt blocks

that's why I focus whether they can switch to a chain, less so what they have as canonical (at depth)

<rucknium> I think you had the idea of a two-tier node polling: One main node and then checking with other nodes for sanity, instead of having R nodes, all with equal voting weight.

yep, that'd be my preferred method for the first iteration. It checks that other nodes have the checkpoint we want to place in their block db, verified

<rucknium> I think "checking if can switch" would work with the former, but not the latter, since you can have a supermajority that can switch to multiple alt chains. Then, which one to reach concurrence about?

this may be the canonical or altchain, but the key part is that they can switch to it (we aren't on our own little branch)

we check if the checkpoint we want to place exists, not other way around (see which chains exist)

so even if other secondary check nodes have 3-4 chains, we get block by hash and confirm they have verified it locally - they will be able to switch to that one

if we can't acquire consensus there - it is likely there are a few legit alternate chains (or we are on our own isolated island) and then it is fail-safe to await other nodes to agree or receive the blocks before we shift checkpoints to higher ones

<rucknium> concurrence = consensus. Just a different word to avoid getting confused with blockchain consensus.

eventual consistency, favorite words as of late

the key part is a node can serve their alternate blocks by hash directly - so we can verify they have them (this is done already on the specific checkpointer node, to also verify it CAN move to this one as well)

<rucknium> Consistency has a meaning in statistics already. "Concurrence" is a blank slate. A wide open field :)

I mean, it's specifically what we are attempting with DNS checkpoints and the slowed down update interval en.wikipedia.org/wiki/Eventual_consistency

> An eventually consistent system ensures that if no new updates are made to a given data item, eventually all read accesses to that item will return the last updated value

if we find out other nodes can't switch out to a new checkpoint, we wait without writing new records to let them also catch up (or fail-safe in case we are split)

<rucknium> That sounds fine to me.

I think convergence might be a fine word as well, concurrence has different ... terms in computing as well

as ofrnxmr tried today, any other people that can look into the chain switch issue within monero code? that's effectively a blocker issue

<rucknium> As reminder, reference to BFT supermajority would be strictly greater than 2/3rd polled participants agreeing. That theshold is mentioned in the original article: Lamport, L., Shostak, R., & Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3), 382–401. doi.org/10.1145/357172.357176

<rucknium> But I don't think technically anything done here is truly a BFT algorithm/protocol.

I agree with having 2/3rd+1 supermajority for the secondary nodes. Given it's at depth, these blocks would have replicated already with plenty of time

<rucknium> Um, flipping through thesuarus, "accord"?

<rucknium> Eventual consistency is a goal, but I'm trying to label what happens when one of the decision makers (checkpointer.bin or monerod) decides that enough voters have voted affirmatively for a checkpoint.

<rucknium> The term doesn't matter too much, I guess.

<ofrnxmr:xmr.mx> DataHoarder: 0xfffc will take a crack at it in the AM

amazing to hear

local monero runs checkpointer.bin -> time to issue checkpoint -> checks with secondaries -> checkpoints coherent?

"compatible checkpoint" if BFT passes

as it's not specifically the checkpoint if two altchains exist, but it's compatible for nodes to switch to

<rucknium> Sounds good. Maybe "network-compatible checkpoint" so it is clear that the question is "Can (a supermajority of) the network bind this checkpoint?"

<rucknium> (Is "bind" the right word here? To me, "bind" sounds right since nodes cannot back out of a checkpoint, once set, without the node being restarted.)

<ofrnxmr:xmr.mx> Between the time of the supermajority check, the deployment, and the receipt of the checkpoint, a reorg can happen

<ofrnxmr:xmr.mx> Whem i release my fork, its intentionally to cause some nodes to fork off (the ones who have yet to be bound by the checkpoint)

binding sounds good

committed checkpoint :)

<ofrnxmr:xmr.mx> With my hamfisted (wrong) change, my node correctly survived my fork attempt, allowing it to rejoin the checkpointed (locally orphaned) chain

<ofrnxmr:xmr.mx> So the idea is right. I think 0x will be able to complete this edge case tomorrow

no selfish mining from qubic in their past marathon

FYI monero-blocks now adds relevant viewkey/txkey/txproof information to CSV for p2pool or moneroocean / hashvault

<barthman132:matrix.org> DataHoarder: It does seem like they’re losing Hashrate pretty fast. Qubics price has dropped drastically over the past month.

it has happened a few times

maybe it's too stretched now

<barthman132:matrix.org> DataHoarder: They simply just don’t have as much hashrate as they used to. Qubic in the past sometimes would have like 3gh/s of hashrate. Now at best they’re getting 2 gh/s. Also qubics price has dropped by over 40% in one month.

yes, besides end of August

they still had like 2.3 GH/s last week

it's still quite hefty

note a few of their own pools hop away from qubic and mine xmr directly

only come back when selfish mining is ongoing

<barthman132:matrix.org> Qubics price has dropped 25% in 7 days, so most of the drop has happened in a week. Now they’re getting on marathon at best 2gh/s.

they also released double the usual, without burn, to miners, which tend to sell :)

yes, less hashrate to them is good, but it's not a permanent thing

<barthman132:matrix.org> When did that occur?

last payout, they gave 100% rewards to miners instead of half

<barthman132:matrix.org> Is that a one time thing, because how would they make any money by doing that indefinitely.

it depends on price based on their epochs. it's a very qubic thing

also if they "think" they had 51% of the whole network

<barthman132:matrix.org> DataHoarder: Did they do that before their last marathon.

<barthman132:matrix.org> Or is it just a rare thing that they do from time to time

it depends on their price action and mining action, they did it once in august as well

<barthman132:matrix.org> DataHoarder: If it is like a one time thing from time to time. Then it isn’t really a big factor imo. I don’t think that’s what’s causing the price drop of qubic right now.

the last big drop/slowdown happened also when they did provide this 100%

no purchase + burn and miners sell more, plus you also have dropping profits generally

<barthman132:matrix.org> mrelay.p2pool.observer/m/matrix.org/MVdvYUWoKjDumThtzzvPtidc.png (IMG_0848.png)

<barthman132:matrix.org> The last time was in August, but qubic has been losing value for over a month now

<spirobel:kernal.eu> youtu.be/q29fKfFJadM?t=313 there is a video from may where a miner compared the calculator vs the actual rewards and ended up with half. maybe miners are slowly waking up to the fact that they are getting screwed. the question is really if miners are acting rationally and if they have the right information.