BOLT 2&7: exchanging of announcement signatures

[pm47]

BOLT 2&7: exchanging of announcement signatures

[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 <[email protected]> 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 <[email protected]> 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 😉