00:12:31 DNS rolling checkpoint protocol in flow chart form: https://cryptpad.disroot.org/diagram/#/2/diagram/view/yI43W1RWom0yoODUJzvAB5vAc9X9ujFVAsxGAxgMMyE/embed/ 00:12:45 Not 100% technically accurate, but close. 00:13:40 Maybe DataHoarder and/or @ofrnxmr:xmr.mx could review. There are 5 pages. Click the arrows that appear at the bottom of the screen. 00:15:03 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. 00:15:55 "chain-consistency sanity check" = do not issue checkpoints of blocks that are on different alt chains. Doing so causes nodes to get stuck. 00:18:25 an RPC method to get inclusion of a block in X chain would suffice? 00:18:34 unless it's specific for checkpoints 00:19:15 eg, does h1 have h2 as part of its root? (is h1 in same chain?) 00:19:43 you can do so with a couple of apis (or manually walking previous at the moment as done in checkpointers) 00:20:08 m is depth of checkpoints (m = 2 by default) 00:20:22 R is the number of nodes that the checkpointer pulls from to determine what the checkpoint should be (1 now) 00:20:22 Sis the number of moneropulse domains (7 now) 00:20:38 d_c is sleep delay for checkpointer process of submitting checkpoints to the DNS server (5 minutes now) 00:20:38 d_d is sleep delay for node (daemon) process to check for new DNS checkpoints (2 minutes now) 00:22:15 checkpointer.bin is quite a bit simple :) "Nodes concur on new checkpoint" 00:23:15 The major events are: 00:23:15 FINALIZE_BLOCK: checkpointer.bin submits a checkpoint to the DNS server 00:23:15 BIND_CHECKPOINT: a node with --enforce-dns-checkpoints stores a checkpoint in RAM and beings enforcing it. 00:23:55 DataHoarder: Check the next page for the subroutine. 00:25:17 is that the current or suggested behavior? 00:25:27 BFT is not in checkpointer.bin at the moment 00:26:02 Technically it is the current behavior when R = 1 :) 00:26:53 Yes, it is suggested at this time. 00:27:12 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 00:27:27 and get_block_header_by_hash 00:27:53 this allows the walk to succeed no matter the state (as RPC is not atomic/locked and may change in the middle of iterating) 00:28:14 but I agree on the BFT part otherwise 00:28:36 So you do an iterative walk? That makes sense to prevent the race condition. 00:29:07 More calls, expanding linear in m, I think. 00:29:10 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) 00:29:24 we know an id will be the same across all nodes 00:29:34 I see for BFT it indeed would have to call get_block_header_by_height 00:30:22 but alternatively seeing if the node knows about the hash is enough too, depending on mode (does node think is on current canonical chain, or does node have in its memory and can switch to it) 00:30:40 you get two different behaviors here 00:32:23 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. 00:38:59 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 00:39:19 that's why I focus whether they can switch to a chain, less so what they have as canonical (at depth) 00:41:08 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. 00:41:58 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 00:42:18 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? 00:42:21 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) 00:42:48 we check if the checkpoint we want to place exists, not other way around (see which chains exist) 00:43:18 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 00:44:42 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 00:44:47 concurrence = consensus. Just a different word to avoid getting confused with blockchain consensus. 00:45:08 eventual consistency, favorite words as of late 00:45:54 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) 00:46:36 Consistency has a meaning in statistics already. "Concurrence" is a blank slate. A wide open field :) 00:47:23 I mean, it's specifically what we are attempting with DNS checkpoints and the slowed down update interval https://en.wikipedia.org/wiki/Eventual_consistency 00:47:38 > 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 00:48:28 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) 00:48:54 That sounds fine to me. 00:49:20 I think convergence might be a fine word as well, concurrence has different ... terms in computing as well 00:50:47 as ofrnxmr tried today, any other people that can look into the chain switch issue within monero code? that's effectively a blocker issue 00:50:47 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. https://doi.org/10.1145/357172.357176 00:51:40 But I don't think technically anything done here is truly a BFT algorithm/protocol. 00:51:55 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 00:53:44 Um, flipping through thesuarus, "accord"? 00:55:04 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. 00:56:07 The term doesn't matter too much, I guess. 00:58:13 DataHoarder: 0xfffc will take a crack at it in the AM 00:58:20 amazing to hear 00:58:47 local monero runs checkpointer.bin -> time to issue checkpoint -> checks with secondaries -> checkpoints coherent? 00:59:38 "compatible checkpoint" if BFT passes 01:00:01 as it's not specifically the checkpoint if two altchains exist, but it's compatible for nodes to switch to 01:02:04 Sounds good. Maybe "network-compatible checkpoint" so it is clear that the question is "Can (a supermajority of) the network bind this checkpoint?" 01:03:27 (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.) 01:05:07 Between the time of the supermajority check, the deployment, and the receipt of the checkpoint, a reorg can happen 01:05:07 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) 01:05:45 binding sounds good 01:06:03 committed checkpoint :) 01:06:12 With my hamfisted (wrong) change, my node correctly survived my fork attempt, allowing it to rejoin the checkpointed (locally orphaned) chain 01:07:12 So the idea is right. I think 0x will be able to complete this edge case tomorrow 13:07:25 no selfish mining from qubic in their past marathon 16:41:35 FYI monero-blocks now adds relevant viewkey/txkey/txproof information to CSV for p2pool or moneroocean / hashvault 17:54:14 DataHoarder: It does seem like they’re losing Hashrate pretty fast. Qubics price has dropped drastically over the past month. 17:54:26 it has happened a few times 17:54:38 maybe it's too stretched now 17:58:39 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. 17:58:54 yes, besides end of August 17:59:07 they still had like 2.3 GH/s last week 17:59:14 it's still quite hefty 17:59:38 note a few of their own pools hop away from qubic and mine xmr directly 17:59:46 only come back when selfish mining is ongoing 18:01:14 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. 18:03:56 they also released double the usual, without burn, to miners, which tend to sell :) 18:04:22 yes, less hashrate to them is good, but it's not a permanent thing 18:09:58 When did that occur? 18:10:35 last payout, they gave 100% rewards to miners instead of half 18:12:22 Is that a one time thing, because how would they make any money by doing that indefinitely. 18:12:56 it depends on price based on their epochs. it's a very qubic thing 18:13:06 also if they "think" they had 51% of the whole network 18:16:23 DataHoarder: Did they do that before their last marathon. 18:16:47 Or is it just a rare thing that they do from time to time 18:18:48 it depends on their price action and mining action, they did it once in august as well 18:21:24 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. 18:21:58 the last big drop/slowdown happened also when they did provide this 100% 18:22:31 no purchase + burn and miners sell more, plus you also have dropping profits generally 18:25:50 https://mrelay.p2pool.observer/m/matrix.org/MVdvYUWoKjDumThtzzvPtidc.png (IMG_0848.png) 18:25:51 The last time was in August, but qubic has been losing value for over a month now 22:57:22 https://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.