-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BOLT 2&7: exchanging of announcement signatures #92
Comments
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. |
Actually re-reading the spec I think we are mixing a few concerns here, the 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):
|
I think you're right, signing the node ids & bitcoin keys is enough and it's easier to implement this way 👍 |
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.
|
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.
|
Reorders the `channel-id` and `bitcoin-signature-x` fields so that the signed part of the message is contiguous. Simplifies the signing logic not to just simple signatures of a contiguous region of the message, no need to sign signatures, they all commit to the same payload. This also removes the chicken and egg problem @pm47 reported in lightning#92. Furthermore it specifies that the signed payload also includes any future appended fields.
Reorders the `channel-id` and `bitcoin-signature-x` fields so that the signed part of the message is contiguous. Simplifies the signing logic not to just simple signatures of a contiguous region of the message, no need to sign signatures, they all commit to the same payload. This also removes the chicken and egg problem @pm47 reported in #92. Furthermore it specifies that the signed payload also includes any future appended fields.
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'sannouncement-bitcoin-signature
in order to compute theannouncement-node-signature
the way it is currently specified. So we can't actually build validfunding_locked
messages.Maybe we can work around this issue by not including the other node's
announcement-bitcoin-signature
in ourannouncement-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.The text was updated successfully, but these errors were encountered: