Closed manoranjith closed 2 years ago
Seb mentioned that this will not work if the client uses incrementing nonces per participant set (he could do that for whatever reason). So two ideas: 1) Either we generate the ProposalID separately. 2) We remove the option to set a nonce manually and always draw it uniform random.
What do you think? @manoranjith
I think, we can leave the nonce part as such and generate proposal id separately, using a uniform random source.
Have updated the PR. Now the proposal ID is generated using a random source, independent of the nonce share. Can you have a look @matthiasgeihs.
If it looks good, then I can squash the commit and rebase onto main.
@manoranjith Can you rebase?
I have rebased. I am currently, extracting the points from our discussions and writing a proposal that describes the mechanism for proposal ID and the rationale behind it.
Do you think, we should wait for it to be completed and include its reference in the commit message before merging ?
For me it's fine since we agree about the changes. In this sense I see the proposal as optional here. I would propose to merge if you agree.
As described in #301, use the proposer nonce share as the proposal ID.
Also,
Update the tests for proposal ID generation by removing the assertions that check if the proposal ID changes when the channel parameters change.
Make the ProposalID a field of BaseChannel proposal, as it does not depend on the type of channel proposal and remove the proposal ID method from
ChannelProposal
interface.Closes #301.