BOLT 2&7: exchanging of announcement signatures

[pm47]

I think there might be a chicken-and-egg issue in the way we exchange announcement signatures with funding_locked messages.

Each party can compute its own announcement-bitcoin-signature, but it needs the other party's announcement-bitcoin-signature in order to compute the announcement-node-signature the way it is currently specified. So we can't actually build valid funding_locked messages.

Maybe we can work around this issue by not including the other node's announcement-bitcoin-signature in our announcement-node-signature (channel id needs to be included)? It would still prove that each node owns their respective bitcoin address, which can be linked to an actual tx, and that both nodes agreed on the announcement.

[Roasbeef]

Excellent find! I'm not sure how we missed this the first time around...

I think your suggested solution is pretty straightforward. To eliminate the circular dependency nodes simply sign the channel auth digest (channelID+Bitcoin keys), leaving out the other parties signature from that digest.

Additionally, I think we need to enforce an additional constraint on the signatures within the announcement themselves. In order for us to possibly implement hash-based state reconciliation (rsync algo, hash time series, Patricia trie, etc), we need to ensure that only one encoding of the signature is accepted. Otherwise, our encoding won't be deterministic. In order words, we should enforce a low S (just like in Bitcoin) encoding for all announcement signatures propagated within the network.

[cdecker]

Actually re-reading the spec I think we are mixing a few concerns here, the funding_locked message, which is part of the channel lifecycle messages are being misused to also transfer the signatures. Maybe we should split the signatures out into their own messages? That way we would have explicit opt-in to channel announcements by both parties.

And is there a point to also signing the signatures at all? Maybe we should reorder fields so that we have the 4 signatures at the beginning and they simply sign everything below the signature fields (offset 256):

[64:node-signature-1]
[64:node-signature-2]
[64:bitcoin-signature-1]
[64:bitcoin-signature-2]
[8:channel-id]
[33:node-id-1]
[33:node-id-2]
[33:bitcoin-key-1]
[33:bitcoin-key-2]
[2:len]
[len:features]

[pm47]

is there a point to also signing the signatures at all?

I think you're right, signing the node ids & bitcoin keys is enough and it's easier to implement this way 👍

[rustyrussell]

Olaoluwa Osuntokun <notifications@github.com> writes:

Excellent find! I'm not sure how we missed this the first time around... I think your suggested solution is pretty straightforward. To eliminate the circular dependency nodes simply sign the channel auth digest (channelID+Bitcoin keys), leaving out the other parties signature from that digest. Additionally, I think we need to enforce an additional constraint on the signatures within the announcement themselves. In order for us to possibly implement hash-based state reconciliation (rsync algo, hash time series, Patricia trie, etc), we need to ensure that only _one_ encoding of the signature is accepted. Otherwise, our encoding won't be deterministic. In order words, we should enforce a _low S_ (just like in Bitcoin) encoding for all announcement signatures propagated within the network.

Yech, we still have to deal with signer malleability, which is infinite. I think we need to somehow "segregate" the "witness" part of the announcements from the hashing of the announcement itself. Unfortunately I don't know of anyone who has experience with how to do that... Cheers, Rusty.

[rustyrussell]

Pierre-Marie Padiou <notifications@github.com> writes:

> is there a point to also signing the signatures at all? I think you're right, signing the node ids & bitcoin keys is enough and it's easier to implement this way 👍

Ack, let's do it. Thanks, Rusty.

[cdecker]

The chicken-and-egg problem should be addressed by #96, while the discussion about splitting off the signature exchange from the channel lifecycle is being tracked in #97. Seems this is fixed, closing 😉