The use case for such a transaction are coin-joined channel openings which obfuscate the relationships being creating with a channel opening. To encode the output index of the channel within the transaction, an extra byte (maybe two) needs to be added. Identifying channels based solely from blockheight+offsets conjures up some re-org safety concerns.The proofs are larger: to prove which IDs owns a channel, each one needs a merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can skip some though), the two pubkeys (66 bytes), and a signature of the ID using those pubkeys (128 bytes, schnorr would be 64?). Using schnorr multi-signature generated by the four pubkeys would remedy the possibility of non-canonical graphs resulting in differing network views.Christian Decker suggests having passive rotations when an endpoint announces a channel's existence it also sends its rotation interval along. This is superior due to the bandwidth savings of pushing the onion key rotations to the edges themselves. An active rotation might be used in the emergency case of a forced key rotation due to key compromise.Rusty Russell suggests involving some pairing crypto (IBE style) to allow nodes to passively derive keys the "source" node is able to generate the corresponding private key to regain forward secrecy in the case of such a private key leak. He suggests stating the security model/assumptions clearly to reason about the attack scenarios that need to be guarded against.