Considering
- opening channels is not something you do often AND
- you wait minimum 6 blocks before announcing the channel AND
- you should perhaps wait even longer to increase your anonymity set AND
- either channel party can create the proof (the one with the beefiest hw) AND
- it can likely be optimized quite a lot AND
- hardware acceleration tends to become more widespread
I think we can quickly get proving times down to something reasonable.
I understand why you say that. I myself spent some time convincing myself this was safe (I’m happy to hear a counterargument).
The thinking here is that these public keys are never revealed to anyone other than the two channel counterparties (and they have all the information to leak the existence of the channel anyway of course), hence it is “semi-private”.
If they leak, then an observer can obviously link the channel to the output. But that is still not worse than today, where the link is already public and gossiped around.
I do get the confusion that a “public key that should be kept private” could bring though. And I believe you could indeed do a ECDH as an alternative. The problem with that as I see it, is that you need to give the prover access to the private key (or give it access to APIs that can perform the ECDH). With the hash of public keys we currently do the LN implementation can just spit out a regular channel accnouncement, then this external tool can convert it to a ZK proof before it gets broadcasted.