<k​ayabanerve:matrix.org> Withdrew my TEE proposal due to fundamental issues identified by/in discussion with jberman

<k​ayabanerve:matrix.org> ofrnxmr: The TEE can attest the node isn't censoring because it can. That's the point of the TEE.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

<c​haser:monero.social> at what daily moving average orphan rate would you distinguish censorship from network delays?

<c​haser:monero.social> 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.

<k​ayabanerve:matrix.org> I think it's clear, right now, someone is mining empty blocks which is censorship (even if solely annoying)

<c​haser:monero.social> 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.

<c​haser:monero.social> here is an existing approach to force-inclusion of transactions, FOCIL: eips.ethereum.org/EIPS/eip-7805

<c​haser:monero.social> "FOCIL implements a robust mechanism to preserve Ethereum’s censorship resistance properties by guaranteeing timely transaction inclusion."

<k​ayabanerve:matrix.org> Honestly, it's acceptable if a single entity creates all blocks so long as they do so fairly.

<k​ayabanerve:matrix.org> We can definitely refer a lot to the Ethereum ecosystem, yep.

<k​ayabanerve:matrix.org> That isn't dissimilar from my most recent comment on the finality layer issue.

<c​haser:monero.social> that perspective is one part of the Ethereum ecosystem that I really dislike. it disregards redundancy and long-tail risks.

<o​frnxmr:monero.social> we currently have flags that can be used to create empty txpools or proposed pr to limit block size

<o​frnxmr:monero.social> 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

<o​frnxmr:monero.social> My issue is less of censoring (though i guess it would be), but about artificially bottlenecking dynamic block sizes

<a​rticmine:monero.social> What are the thoughts on Sech1's Block signing proposal?

<k​ayabanerve:matrix.org> I think it's too easily evaded, unfortunately.

<c​ountbleck:matrix.org> How does one evade it? (Or is there a link to previous discussion about this?)

<d​oedl...:zano.org> 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.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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_.

<k​ayabanerve:matrix.org> 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.

kayabanerve: thanks for that consensus option table/write up - it is much appreciated.

<r​brunner7:monero.social> Yeah, seconded. I am just mildly annoyed that I can't come up with such things, that in hindsight are completely obvious.

<r​brunner7:monero.social> (Referring to the possible "sign with your private key" countermeasures)

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.

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.

<e​longated:matrix.org> Monero has a marketing/aping team 🤣

<e​longated:matrix.org> Monero has a marketing/spin team 🤣

<d​oedl...:zano.org> Who would send 0.06 xmr to a shady unknown pool owner, just to participate in a fraud ?

<r​brunner7:monero.social> If the alternative is mining for a full year withing hitting a solo block?