00:20:17 Withdrew my TEE proposal due to fundamental issues identified by/in discussion with jberman 00:20:48 ofrnxmr: The TEE can attest the node isn't censoring because it can. That's the point of the TEE. 00:21:34 The node would run within the TEE, and the TEE would enforce configuration values. While we could allow the TX pool size to be configurable, we could also require it be of a minimum value to product block templates. 00:21:58 The TEE wouldn't magically decide block A vs block B. It just wouldn't decide a block based on its preference instead of the logic coded. 00:23:29 FWIW, the fundamental issue with the TEE solution is it doesn't stop an adversary with 51% of the hash power from performing arbitrarily deep re-orgs because it _isn't_ a finality layer. While it does reduce the impact of attacks for an adversary with minority hash power, those attacks already aren't successful so long as the adversary has a minority of hash power: solely annoying. 01:45:57 at what daily moving average orphan rate would you distinguish censorship from network delays? 01:51:40 don't get me wrong, I appreciate your proposals, and I'm actually excited about one of them, but that statement seems a bit too bold. 01:54:03 I think it's clear, right now, someone is mining empty blocks which is censorship (even if solely annoying) 02:01:49 oh, I read that comment as an assessment of the reorg/orphaning situation (you talked about selfish mining there). so we're talking about two distinct forms of censorship here. 02:16:27 here is an existing approach to force-inclusion of transactions, FOCIL: https://eips.ethereum.org/EIPS/eip-7805 02:16:29 "FOCIL implements a robust mechanism to preserve Ethereum’s censorship resistance properties by guaranteeing timely transaction inclusion." 02:16:52 Honestly, it's acceptable if a single entity creates all blocks so long as they do so fairly. 02:17:08 We can definitely refer a lot to the Ethereum ecosystem, yep. 02:18:21 That isn't dissimilar from my most recent comment on the finality layer issue. 02:20:16 that perspective is one part of the Ethereum ecosystem that I really dislike. it disregards redundancy and long-tail risks. 02:20:25 we currently have flags that can be used to create empty txpools or proposed pr to limit block size 02:21:28 I personally am not a fan of allowing either to be set to lower than 2x the short term median, or whatever the max next-block size would be 02:23:38 My issue is less of censoring (though i guess it would be), but about artificially bottlenecking dynamic block sizes 05:25:32 What are the thoughts on Sech1's Block signing proposal? 06:45:43 I think it's too easily evaded, unfortunately. 07:09:15 How does one evade it? (Or is there a link to previous discussion about this?) 08:04:53 It's the right thing to have on the sidelines. We should not advertise in public how to evade it, suffice to say there are ways to harden sech1's PR if need be. 08:06:03 I prior held off on commenting how to evade it, yet the solution is straightforward enough _and_ I'd rather encourage discussing on countermeasures/quash the proposal if it's going to continue to be discussed. 08:06:49 For each user, the mining pool generates a unique private key and sends it to the user. Yes, the user *can* enter a race with the pool to take the 0.06 XMR before the pool can sweep it, yet the pool has an edge. This is before you simply require all users put up a 0.06 XMR deposit in advance, so if they do find a block and manage to win the race, they get slashed. 08:06:51 This is before pools could simply require miners use a TEE for the signing component, so that miners can _sign blocks_ but can't actually _sign transactions_. 08:07:33 Yes, such pools would likely be less popular *except* they'll have higher median payouts _and_ TEE technology is sufficiently widespread it likely isn't a bar to entry for miners. 09:11:47 kayabanerve: thanks for that consensus option table/write up - it is much appreciated. 09:20:50 Yeah, seconded. I am just mildly annoyed that I can't come up with such things, that in hindsight are completely obvious. 09:24:39 (Referring to the possible "sign with your private key" countermeasures) 09:31:32 i actually imagined the 'signing with a private key' mitigation but then figured it was a ridiculously silly idea, as it would probably mean a massive reduction in overall hash power. 09:33:12 using bitcoin as a finality layer i also remembered as an option, but don't really understand the nuances of it. it seems a 'simple enough' mitigation to create a backstop, but comes with a load of FUD/dependency narratives that the 'marketing and spin team' would probably disapprove of. 09:35:30 Monero has a marketing/aping team 🤣 09:35:33 Monero has a marketing/spin team 🤣 09:37:00 Who would send 0.06 xmr to a shady unknown pool owner, just to participate in a fraud ? 09:40:12 If the alternative is mining for a full year withing hitting a solo block? 12:25:52 sech1 proposed 90/10% iirc; anyway, the deeper solution would be to proof in zk a known solution, so the pool owner can not know whom to slash. this needs further research -- there might still be loopholes. Few people can review this stuff; I can't. 12:45:33 btw, I like https://github.com/monero-project/research-lab/issues/135 (open to discussion: how to choose a set of validators) 14:05:30 tevador has brought up https://github.com/monero-project/research-lab/issues/98, and it seems possibly much better at encouraging pool mining? 14:11:08 (compared to signing blocks) 14:55:09 It's also a far more practical 'local PoW' solution than my idea yesterday of an ASIC 🤔🤔🤔 14:55:24 Tbh, I forgot this proposal existed 15:07:43 Eh. Local PoW wouldn't allow renting a VPS. This still would. 15:12:48 **at encouraging solo mining 15:12:54 Geez, what a typo, sorry 15:24:14

Glad to see tevador back 15:55:55 I agree that this block signing proposal can be technically circumvented by a malicious pool or even a botnet. The real question is at what cost to the malicious pool or botnet? 15:55:55 My proposed modification of this proposal is to li.mit the signing requirements to one tx with at least 0.006 XMR. 15:55:57 An honest centralized pool would see a fee burden of 1% which is within the range of typical fees that are charged for pool use. Unlike a fee this 1% is in effect a lottery to the benefit of the small bashers. 15:55:59 On the other hand a malicious pool or a botnet would have the burden of the distribution of private keys to all the miners. If the private keys are unique then the burden becomes increasingly burdensome as the number of small bashers increases. For a botnet this adds significant risks of exposure. On the other hand if a single private key is used then the malicious pool or botnet becomes vulnerable to a steal from the thief counterattack. 15:56:03 At this point we come to the use of a TEE ( Trusted Execution Environment). When the owner of the device or computer is treated as the adversary, this becomes nothing more than hardware DRM, which like all forms of DRM have been proven vulnerable to attacks over the years. 15:56:05 I will address the burden of security by obscurity. If this burden is primarily on the malicious pool or botnet the more this gets publicly disclosed the better. I see forcing the malicious pool or botnet to use DRM to be a major victory. The use of TEEs in this situation is a sign of weakness not strength. 15:56:07 Finally I will point out the value of a strong copyleft GPL / AGPL V3+. These licenses give permission to circumvent the DRM, effectively paving the way for legal counterattacks against a malicious pool or botnet. 15:57:36 People unaware they're mining monero, if they become aware and win a lottery, could steal back 1% of a block reward if they win a technical race? 15:58:37 Or, if the botnet maintainer uses a TEE, if the victim decaps their CPU and pulls out a silicon microscope and/or run experimental PoCs from GH which are source code only? 16:01:10 If the victims of a botnet become aware, that becomes a major cost to the botnet operator. 16:02:41 For a major botnet LE might just do that. Again major risk to the botnet operator 16:03:32 Even better if the TEE has been back doored by LE 16:06:38 The 10% and comments that this key signing would make centralized pools uneconomical understandably has led to very valid opposition to the proposal 16:08:22 Dropping the % to 1% and actually being supportive of honest centralized pools changes the dynamics in my view 16:09:54 I do not believe LE will perform a TEE break for a race for $20 of unswept funds in a mutually held private key 16:10:53 They will perform a TEE break to take down a major North Korean botnet 16:13:43 When it comes to TEEs I am very strongly opposed to the Monero project using them. Forcing our adversaries to use them on the other hand is an excellent idea that I fully support. 16:15:00 Except there's only $15 * 60 blocks in flight, even with a 10% fee 16:15:13 And it'd require code exec on the victim's computer 16:15:41 If they have control to the C2 server, they can shut it down without quibbling over $1,000 16:19:38 If the botnet operator uses different keys for each victim. That in itself is a burden and also provides a significant counter attack vector 16:20:18 10% is way too much 16:21:22 The key here is the cost difference between honest and dishonest centralization pool mining 16:21:50 I am opposed to 10% for the record 16:22:21 1% I support 16:25:04 I believe that TEEs are either compromised or will become compromised by governments and LE 17:10:13 >a malicious pool or a botnet would have the burden of the distribution of private keys to all the miners. 17:10:15 +1 17:18:27 https://a16zcrypto.com/posts/article/trusted-execution-environments-tees-primer/ 17:24:22 The fact that TEEs have been used for DRM since the 1990's is actually evidence that TEEs have and will be compromised. 17:24:23 After all what percentage of pirated content on The Pirate Bay dot org was ordinary released with DRM? This tells me that the DRM was compromised and consequently any TEE used was also compromised. 17:24:41 Originally 21:00:08 Do we realy want to cut out botnets from mining? In the end they are securing the network