14:05:53 <br-m> <kayabanerve:matrix.org> @loop.ster:matrix.org: You're describing a key escrow service.
14:06:35 <br-m> <kayabanerve:matrix.org> You're just proposing ICP or EigenLayer serve as the key escrow.
14:13:54 <br-m> <kayabanerve:matrix.org> Specifically, the third-party does have the secret if a ciphertext to them for the secret exists. The fact they don't immediately have its plaintext, or may or may not have the ciphertext provided to them, doesn't change they can obtain the secret with trivial collusion.
14:14:17 <br-m> <kayabanerve:matrix.org> Also, with such collusion, they can still authenticate any state which ever existed.
14:42:09 <br-m> <loop.ster:matrix.org> The difference is that
14:42:09 <br-m> <loop.ster:matrix.org> A) they don't escrow a secret. You encrypt a state to their pubkey which is only decrypt after the dispute settles.
14:42:09 <br-m> <loop.ster:matrix.org> B) collusion requires the subversion of the entire ICP consensus protocol
14:42:09 <br-m> <loop.ster:matrix.org> B is the important bit. Whereas previously we were talking about having to build a whole decentralised consensus infra with slashing etc. , ICP already exists and can be used as is to handle disputes. There's no grease-specific private key that needs to be stored in the smart contract ecosystem. The ICP master key suffices.
14:56:21 <br-m> <loop.ster:matrix.org> @kayabanerve:matrix.org: Right, but collusion is not trivial. That's the differentiator
14:57:37 <br-m> <loop.ster:matrix.org> "The fact they don't immediately have its plaintext" -- or in fact, the cipher text. And this is why it's not strictly speaking, an escrow.
16:00:33 <br-m> <kayabanerve:matrix.org> As I said, you're just proposing ICP serve as the key escrow.
16:01:21 <br-m> <kayabanerve:matrix.org> Except as either party has the ciphertext, your adversary can send the ciphertext to the KES ahead of time as part of collusion.
16:01:43 <br-m> <kayabanerve:matrix.org> That isn't a functional difference from the KES having the plaintext for which under collusion, they can incorrectly spend from the channel.
16:02:04 <br-m> <kayabanerve:matrix.org> So it's solely saying 'collusion is hard because of my choice of KES', but it's still a KES.
16:10:54 <br-m> <loop.ster:matrix.org> I've been clear on how I defined escrow. Those semantics are beside the point. Call it a kes if you want.
16:10:54 <br-m> <loop.ster:matrix.org> What I'm trying to establish here is
16:10:54 <br-m> <loop.ster:matrix.org> 1. This is more elegant than grease V1
16:10:54 <br-m> <loop.ster:matrix.org> 2. Is the trust boundary what I'm claiming it is -- the ICP consensus protocol -- or have I missed something.
16:31:31 <br-m> <kayabanerve:matrix.org> This is still a third-party trust assumption and a threshold multisig was already proposed a couple months ago.
16:31:35 <br-m> <kayabanerve:matrix.org> This may simplify the KES but it doesn't change it's fundamentally equivalent.
16:31:46 <br-m> <kayabanerve:matrix.org> That's why I'm pushing back as I am.
16:32:40 <br-m> <kayabanerve:matrix.org> Your pitch was your design removes the KES completely despite preserving the exact same third-party trust assumption which was the issue.
17:58:44 <br-m> <loop.ster:matrix.org> If there was an implication that the 3rd party trust assumption was removed, I apologise -- that was not the intent. I don't believe I made that claim btw, I only said the kes was removed (and it's still distinct in my mind). Of course there will always be a 3rd party trust assumption in this design. But that is not a binary t [... too long, see https://mrelay.p2pool.observer/e/m4ud2pYLTVZkNGli ]
17:58:44 <br-m> <loop.ster:matrix.org> My take-away from the conversation in May was that threshold multisig per se was not the blocker  -- it was the cost and practicality of deploying infrastructure to support a threshold multisig that was sufficiently decentralised and economically incentivised to make collusion infeasible.
17:58:44 <br-m> <loop.ster:matrix.org> With Grease v1 / AuxChannel / Monet, the thorny point is that you ultimately need a smart contract to be able to hold an application-derived private key to sign messages  / encrypt dispute results to the counterparties. And no blockchain offers that (even SNARK-based ones) and DKG doesn't solve the problem. You need en[... more lines follow, see https://mrelay.p2pool.observer/e/m4ud2pYLTVZkNGli ]