Taproot, Lightning and gossip

What has to happen in order for taproot channels to be gossiped? What needs to happen to the gossip protocol?

During a recent space on twitter, there was an interesting discussion about Lightning future. In particular very interesting on my opinion what told by Elle Mouton (thank you for this interesting discussion).

It was asked:

I know you mentioned taproot that got the update to gossip, basically, that will need to take place for taproot channels. So like, what has to happen? In order for taproot channels to be gossiped. What needs to happen to the gossip protocol?

Current status

So basically, currently, with lightning channels, the outputs are P2SH. And they're just a 2/2 multisig. And basically, what we do when we announce the channel, is we announce all the parts of that output so that everybody on the network who wants to confirm that it is a channel can check. This is actually a to have to multisig, and it belongs to this node and this node, I'm happy to put it in my graph and use it as a channel. So like, that is how things currently work. So we have this quite strict list of things we want to check in a channel announcement to make sure that I can be happy to put this and to say that this is a channel and I will use it.

What changes with taproot and why?

But with taproot, the optics look completely different. So it's, it's literally just one key that's on-chain. And who knows what's in that key? So and it's really hard to prove what's in the key. So first of all, the messages we currently use don't work for this. So if we use the current set of gossip messages, and we, broadcast a taproot channel and announced it with these messages, the nodes would get it and they will say: “I don't know what to do with this, I'm not going to use this channel”. So we need a whole new set of messages for taprootchannels.

This is still very much in the design phase. So this is not fixed even. But basically what it needs to do is allow nodes to know how to verify. So there's still debate on how we should do this. Because with current lightning channels, if I'm an attacker, and I want to spam the network with these channels that aren't actually channels, it's still going to cost me quite a bit because I have to actually construct these to have multisig transactions. And if I have to spend if I want to spend from them, I have to put two big signatures on chain. So it actually does cost me something to spam the network with fake channels currently. With taproot channels that's not the case because two signatures becomes one signature, so I can very easily now create spam, actually. So the big question we're trying to answer now is: how are we going to? How are we going to make sure that these outputs are like, bound enough to the lightning contexts so that we can say, okay, we trust this is a lightning channel, we're going to use it