02:54:51 SafeCurves is not very important in general terms, Bitcoin for example uses Secp256k1 (not compatible with SafeCurves). 02:54:51 (https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses) 02:55:02 **this is a example** 02:56:27 SafeCurves is not very important in general terms, Bitcoin for example uses Secp256k1 (not compatible with SafeCurves). 02:56:29 https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses 02:59:09 **this is a example**, I don't know much about cryptography in Monero, but I believe that more audits will be carried out to ensure security, and I bet there are many people watching the code of Monero, FCMP++ and so on every day. :) 15:21:55 3.14stache: SafeCurves does highlight real criteria. It just is stuck in a 90s/00s view of what criteria matter (IMO). You're right secp256k1 isn't considered safe by SC though :) 15:22:32 That's why we have evaluated to all its criteria, have ensured we pass the ones that matter to us, and are discussing external review we correctly decided which ones matter, yep :) 15:24:35 Side note, on consensus: 15:24:37 I support adding an ASIC-component to RandomX more than two PoW algorithms (one ASIC, one not). There's historically been plenty of multi-PoW coins and they've historically largely been attacked due to not doing it properly. 15:25:52 The Zcash TFL design goals would prevent deep reorgs, may allow reducing the 10-block lock, and could allow PoS opinionation over what PoW chain to follow. We also wouldn't need to define stake as XMR, yet could use any metric we want (1 block mined -> 1 stake, though that'd be problematic due to P2pool and so on). 15:26:19 Separating block building from block mining, as https://github.com/monero-project/research-lab/issues/134 suggests, also could be a solution. 15:40:26 Is adding an asic component to randomx basically just choosing an asic-friendly mining algorithm, with extra steps? Or am I looking at that the wrong way? 16:03:31 sgp_: The distinction to dual-PoW is that dual-PoW has independent difficulties for each algorithm, allowing manipulation on that premise. 16:04:19 If we add an ASIC-degree of say, Scrypt, into RandomX, we could maintain a single difficulty and avoid those attacks as historically observed. 16:05:34 For example, we require the block satisfy the RandomX template _as current_ and then a Scrypt outer-hash simultaneously satisfies the difficulty. 16:06:33 Or we introduce a Scrypt OPCODE into the RandomX VM and then require that when the Scrypt OPCODE is hit, a valid PoW solution for a Scrypt challenge be provided. We'd just have to bound the amount of Scrypt opcodes possibly present and ensure *some* are present. 16:07:30 The question would be how can we make an x86 server farm so inefficient it isn't viable, yet simultaneously, the only ASIC needed is on a USB level (what're those historical bad SHA-512d USB sticks called? They were like, $25?) 16:07:56 But the algorithm itself remains uncompetitive on GPU BUT remains verifiable on traditional hardware. 16:08:29 AND there isn't such a benefit, ASIC manufacturers don't immediately win. 16:08:48 It's just tricky as any time you switch between the CPU and an ASIC, you'll have nontrivial latency, and you'll have to decide an iteration count accordingly. 16:10:30 Shift RandomX viability from anyone with a CPU to anyone with a CPU and physical hardware access, basically, as proven by a requirement-to-be-competitive of widely available, many manufacturers, USB devices. 16:11:40 Unless GCP start allowing anyone to mail in arbitrary USB devices to hook to their VM, or someone just exhausts network bandwidth on a remote hardware solution (so we do need the hash preimage to be large), then... 16:21:49 USB over IP is a thing so physical hardware would probably not be a requirement 16:22:32 Which is why I commented the transfer rate has to exceed feasible bandwidth. 16:23:47 Thunderbolt 3 will do 40 Gbps, though that's far less widely available as desirable. Most VPSs won't offer 40 Gbps. 16:27:44 TBC, I'm not advocating to move forward with this. Monero has options. Do nothing. Move to a different PoW algoritm. Use n PoW algorithms. Adopt PoS. Adopt BFT PoS. Separate block building from mining. All have real trade-offs for security and decentralization. This is just my commentary on moving to a different PoW algorithm, which I initially prefer to n PoW. 16:28:11 yeah I'm not for n pow 16:28:46 My favorite current proposal is likely separating block building from mining, preventing selfish mining, under some assumption. 16:30:10 I proposed a solution premised on TEEs, with unsolved network topology issues. Alternatively, some other criteria could decide blocks to mine before they're mined. 16:32:01 My network topology issues may be immediately solved if we move all gossip into TEEs, actually.... 16:32:31 But that requires every node distributing blocks have one, not just block template producers. 16:33:43 Right now, by inaction, we're doing nothing and witnessing the censorship effected. 16:34:36 That may be the best option, as the censorship is partial. It still is an option and may not be. Hence my commentary on others. 16:35:21 (Partial, as in, no TXs are being censored. Just delayed due to some blocks censoring all TXs from inclusion in them themselves) 16:36:58 Rucknium: boog900: vtnerd: Can we add a delay on block relay if it isn't at the block size limit to balance time to relay empty v full blocks? 16:37:22 rbrunner7: too as I just start pinging people 16:38:13 idk the specifics of the tfl approach (zcash doesn't appear to have settled on theirs yet, unless their gitbook is outdated). But that is probably the direction I lean. Allow the mining market to do its thing while having a sensible guardrail against deep reorgs. That guardrail is of course up for debate. One thing I am against is kneejerk reactions; what we're observing now is ex 16:38:13 actly how nakamoto pow is supposed to work 16:38:24 Like, have block relay speed be independent of block size. 16:38:58 The black marble flooding last year was much worse for tx confirmation delay than the few empty blocks now, FWIW. The wait was in hours for the lowest fee tier. 16:39:22 Yes, but that isn't the issue I want to solve. 16:39:37 A malicious miner can just add their own txs to the block for free. 16:39:49 I wanted to level the playing field on block relay speed. 16:39:59 Again, not the issue Rucknium. 16:40:49 Right now, they're not mining blocks to censor TXs. It's for fast propagation. I'm curious if we can remove fats propagation as being used to attack the network currently. 16:41:05 There are other ways to achieve fast propagation though? 16:41:07 Are you asking this empty block delay idea combined with a TEE? 16:41:15 So this may be pointless. 16:41:20 As boog mentioned the other day, we can speed up relay time for blocks by checking pow and a few other things and then immediately relay 16:41:38 I am not discussing TEEs at all Rucknium 16:41:44 But the bigger blocks will always be a little slower due to size 16:42:16 Blocks should always propagate as fast as possible to avoid wasted hashes and make alt blocks less likely. 16:42:17 I mentioned a way in -lounge yesterday which would close the gap between blocks full of txs and blocks with less txs 16:42:29 Empty blocks will always use less bandwidth and propagate faster. I'm curious if we can fairly delay propagation via honest nodes to account for this. 16:42:41 If we delay empty blocks then they mine 1 tx block, etc 16:43:11 That would avoid malicious miners from achieving faster propagation off the honest network. 16:43:23 blocks are relayed as fluffy blocks now though, aren't they? 16:43:28 With fluffy blocks enabled, how slow are full blocks, really? 16:43:30 vtnerd: I didn't say delay empty blocks. I said delay smaller blocks. 16:43:52 Can't find it now but it was to relay blocks after checking pow but before checking the txs 16:44:21 If it takes 1s for a P2P channel to communicate a full block, and we receive a half full block in 500ms, then we can delay until the full 1s elapses. 16:44:58 It's allg if this ides is worthless. I just wanted to throw it out there as it seems more immediately possible. 16:45:25 According to sech1, Qubic is already losing more blocks in its orphaning attempts than winning the orphan rate. I don't think block propagation matters in this attack. 16:45:32 It's probably marginal 16:45:34 I'm happy if y'all already have a way to improve things :) Sorry for the pings if so. 16:45:50 That's why I pinged you Rucknium :) 16:46:23 sech1 is 10x more knowledgeable about mining than me, at least. 16:48:30 TFL requires miners stake Monero in plaintext and form a BFT consensus. It stops reorgs and could reduce the ten-block lock (if we only take the Finality Layer from Trailing Finality Layer). A TFL takeover (34%) allows censoring miners and a TFL halt (again 34%) would halt the chain in effect. 16:49:16 ... a halt could also be achieved by faulty programming. 16:50:40 We can benefit privacy by encrypting stakes to participate, decrypting the sum in total at the start of the next session, and allowing anyone to use a ZK proof to claim their stake? 16:51:14 Then, we'd have stake TXs identified on-chain, the total stake known, but not know which validator used which stake. 16:51:37 (specifically, which output contributed how much stake) 16:52:08 If we do my GH issue for private timelocks, we also could avoid having stake TXs identified on-chain. 16:52:52 I think a dedicated writeup on the goals of TFL/FL and how to approach those is probably necessary :) 16:52:53 Eg: The goals of "nothing longer than 10 blocks old should be re-orged out" and "we primarily want to reduce the lock from 10 to 2 blocks" are totally different and likely have different appropriate approaches 16:53:13 Yeah, I'll put an issue out tonight or so. 16:54:18 I wasn't trying to put that on you, but if you're interested than cool :) 17:30:23 so already the protocol is "scared" of re-orgs, what with it taking 60 blocks to unlock block rewards 17:31:24 i wonder if we should just push that to 120 or something else ridiculous. Would be a kind of "stake". Might also mitigate an attacker being able to use the mined coins to do anything 18:35:11 https://eprint.iacr.org/2024/677 18:35:19 Oops, sorry, wrong link 18:35:21 https://github.com/monero-project/research-lab/issues/135 19:20:41 The TEE solution also allows reducing the 10-block lock via reducing the possibility and frequency of re-orgs. 19:20:43 The issue is it requires either a stable network connection (and stable gossip network connection), to observe blocks being mined in real time (else being stranded on weird alt chain), or forgoing the TEE's security on the assumption a majority of hash power is TEE'd and has soft-forked such that the longest PoW chain is the TEE-protected chain. 19:21:55 Would the 10-block threshold still exist as a fallback if the finality layer isn't "sufficiently responsive"? 19:22:10 Would/could the 10-block threshold still exist as a fallback if the finality layer isn't "sufficiently responsive"? 19:22:42 We could? But it's not recommended to continue the chain if finality has failed. 19:27:22 Link to this TEE solution? My concern is probably very common but will people running nodes or miners require TEEs under this idea? 19:28:23 so this would be BFT layer on top of the current chain? 19:28:25 what happens if the BFT cannot find consensus because it does not reach 67%? 19:31:04 Link to this TEE solution? My concern is probably very common but will people running nodes or miners require (or have a non-negligible benefit from) TEEs under this idea? 19:32:57 The TEE and FL solutions both achieve largely the same goals. The TEE is only beneficial so long as all supported TEEs are uncompromised. The TEE solution observationally defines the best chain and requires a stable gossip network to avoid being split off. 19:32:59 The FL requires forking Monero itself to support a FL. The FL requires an entire second network to produce consensus certificates, and is premised on PoS. The FL avoids the observational issues depending on network topology, yet achieves properly defined security with well-defined assumptions, albeit we incur the fact that BFT consensus has a 2f+1 optimal bound. 19:33:38 atomfried: It'd stall 19:34:53 https://github.com/monero-project/research-lab/issues/134 19:35:00 CountBleck: 19:38:52 this would go into the tari ootle direction where the pow chooses the validator subset to shuffle them in order to avoid stalling the network i guess 19:43:39 I share the listed concern about centralization, and I'm sure the "will not agree on a PoS solution" sentiment is a lot stronger for TEEs...being able to run nodes/miners on consumer devices (not just enterprise servers) is handy, and SGX has a checkered record 19:44:46 I have no solid idea about how Tari works/operates and would have to refrain from commenting unless sent/linked documentation. 19:45:31 While I tried to make the finality proposal direct as to be potentially accepted, the TEE solution is far less invasive to the network itself. It can be done entirely as a soft fork. 19:46:41 It's approximate to one early comment, about how we can have mining pools choose federalize to choose to ignore 'hostile actors' at the cost of centralizing block production to... 3 mining pools? 19:47:28 Instead of having a 'whitelist' of authorized miners, maintained by a federation of a few, this whitelists any miner who has a connection to a computer with a TEE (probably almost all), as to ensure fair inclusion of both blocks and TXs. 19:47:43 It does slightly centralize. It's no where the federation of top mining pools. 20:13:45 https://github.com/monero-project/research-lab/issues/136 20:13:59 Meta-issue is up over all the proposals I threw out today, with a table comparing them. Commentary welcome. 20:55:19 Added having miners sign the block (for either 100% of the reward or even just 10%). 20:57:10 I want more time to put my thoughts together, but I personally prefer we explore those top 2 options of those listed 21:01:59 I definitely have favoritism to the ideas I bothered to write up full issues for 21:55:35 i don't get em 22:02:39 gingeropolous: Care to elaborate? 22:03:12 i was having a hard time understanding the whole TEE approach, but thanks to gemini it makes more sense. 22:03:37 Please don't use LLMs to summarize my work. It's likely wrong. 22:04:12 The idea with a TEE is it's a computer which can attest the program it's running. That means it can attest it isn't censoring any blocks/transactions. 22:04:46 We can move everyone who _mines or relays_ a block to a TEE-enabled computer in order to achieve block production/propagation which guarantees the produced blocks aren't censoring. 22:06:01 While the TEE could be broken, then we're largely back where we are now. While the TEE isn't broken, it isn't feasible to produce censoring blocks. 22:06:44 to not muddy up your issue, this is what the bots spit out: https://paste.centos.org/view/18507d64 22:07:23 i wasn't fully comprehending what role the TEE was doing. for some reason I missed that with what i read 22:08:32 That paste is fine. Thank you for letting me check if it was correct or not. 22:09:59 Also, we could support a variety of TEEs (though our benefit is only as long as they're all secure), and nodes without a TEE can still receive blocks: they just can't relay them. 22:11:32 so it ultimately just addresses censorship, doesn't do much for re-orgs (?) 22:22:04 So long as the TEE is secure, then it would effectively prohibit reorgs larger than 1 afaik. If the TEE is insecure (any of the chosen ones), then we're back to where we are today, where reorgs can go as far back as the software hardcored checkpoint 22:28:44 Right. Because the TEE attests the node isn't censoring, if we have a healthy network, then it shouldn't be possible to produce an alt-chain *except as the network is not instantaneous*. 22:29:46 Maybe if multiple blocks are honestly mined atop each other within seconds? Getting really lucky? 22:29:58 So you can produce two blocks at the same time, if within natural network latency, or possibly more if the P2P network is degraded. One a block is successfully broadcasted however, everyone will build on it UNLESS they can break integrity (distinct from confidentiality). 22:30:34 We could probably define a 2- or 3-block lock without too much concern. 22:31:06 Then the question is simply if 2-block reorgs are such a performance/privacy issue we still need any lock, or if we can remove it entirely. 23:15:09 How much work would it take to trust new TEE impls or untrust vulnerable ones? 23:24:15 when you say "once a block is successfully broadcasted, everyone will build on it" What if supportxmr receives block A and nanopool receives block B? Wont they build on whatever they got first? how can tee attest that the node isnt censoring? 23:24:17 i'm not understanding 23:25:12 If i decide to limit my txpool size to 0kb, am i censoring? 23:38:05 Or is it censoring if my block isn't propagated fast enough? Or if i reject someone elses block which was produced "before" mine (if so, how to know if it was actually produced beforehand?)