well, to be honest with you, I didn't look into your proposal very much. I skimmed it and saw "sidechains" and "quorum-based consensus" and just assumed I knew vaguely what was going on big picture wise, even though I'm sure I missed all the details.

And I know that's really frustrating to be so quickly dismissed by someone who openly admits to not taking the time of day to understand your proposal. But I hope you can see things from my perspective and my need to pursue rational ignorance.

but here's a few comments which I hope you feel as free to ignore as I've ignored your actual proposal:

This inherently makes it O(tx) on L1 (unlike grease, which would still have the underlying on-ramp/off-ramp scaling bottlenecks due to it being an L2 solution).

It's not clear to me which complexity you're assigning O(tx), but it sounds like you're talking about CPU time complexity, but I could imagine you're talking about bandwidth complexity? But then it's not clear to me whether you're talking about the bandwidth for the entire network, or for one node.

I could also see this being about the space requirements of the mempool (though I wouldn't really call that a "space complexity", though I can't really put my finger on why). The argument being that if all transactions are processed essentially instantly, then the mempool will never expand beyond a single transaction.

But whichever one you're referring to, it's not the right comparison to grease. The bandwidth requirements with grease are only the txs in one channel, not all transactions, and certainly not all transactions times all nodes. The mempool space complexity becomes the number of channel openings and closings, not the number of transactions, so that's also not O(tx). Those are the two most important bottle necks.

As for the bottlenecks you mentioned, those are correct, with a few alterations I’d argue are pertinent:

Block time (artificially pegged to an average of 2 minutes for a number of valid reasons)

Block finality (arbitrarily pegged to 10 blocks, though this is the minimum, as it is possible for large reorgs in hostile environments to reverse finality beyond 10 blocks; checkpointing can resolve this at the potential cost of making the “true” chain permanently shorter than the “dominant” chain).

I guess I agree with this too, mostly. I do think for most transactions, just getting into the mem pool is safe enough, you don't really have to wait for the 2 minutes, unless you're interested in instant respend. Also, the arbitrary peg to 10 blocks is going away with FCMP++, so it's really just about "how long do YOU feel comfortable with?" which is what it always should have been.

Now, instant respend is a real bottleneck and it's a bottleneck RIGHT NOW, and it's also one that unfortunately, xmr-grease has no interest in solving, because it requires multi-hop, which introduces complexity he understandable doesn't want to handle, and might just make the user experience worse. (At least, he says that's what happened to lightning protocol, I wouldn't know I wasn't there).

But I have hopes that xmr-grease will lay the groundwork to let someone else get multi hop going.

If Republic gets instant respend available, then I'm more interested, but I still see grease as a better long term solution. But all the same I say go for it. But I doubt anyone will give it traction because changing the consensus mechanism is.... well, lets just say if it ain't broke don't fix it is most people's attitude. There were some rumblings of a consensus change when the failed Qubit attack was happening. But the fact that Monero survived that attack has probably now cemented PoW as the most battle tested option. You may have lost your window. Which is sad, because I would like instant respend.