Skip to content
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

Allow a channel re-open or a new channel to be created after a close #93

Closed
hackaugusto opened this issue Jul 15, 2016 · 11 comments · Fixed by #297
Closed

Allow a channel re-open or a new channel to be created after a close #93

hackaugusto opened this issue Jul 15, 2016 · 11 comments · Fixed by #297
Assignees

Comments

@hackaugusto
Copy link
Contributor

hackaugusto commented Jul 15, 2016

Remove the channel address from the manager once the channel is settled is a possible solution, this allows a new contract to be created.

@czepluch czepluch self-assigned this Jul 15, 2016
@czepluch
Copy link
Contributor

Should this happen right after settle is called?

@hackaugusto hackaugusto changed the title Remove the channel address from the manager once the channel is settled Allow a channel re-open or a new channel to be created after a close Jul 22, 2016
@hackaugusto
Copy link
Contributor Author

hackaugusto commented Jul 22, 2016

I think so, the users will need to wait for settleTimeout until that can happen, but we don't lose the address from the channel manager (it is useful for third-parties calling unlock and/or updating the transfers)

@czepluch
Copy link
Contributor

czepluch commented Sep 5, 2016

Also clean up the BC when a channel is settled by calling suicide

@czepluch
Copy link
Contributor

If we're planning on making changes to the messages anyway, we might as well add channel_address to the messages, and use this as an identifier to prevent double spending.

@heikoheiko
Copy link
Contributor

I'm strongly against adding another field to the message (making it longer) unless necessary.

There are two alternative ways of solving the problem:

  1. hash the channel_address into the signature. That is sign sha3(msg+channel_address).
  2. Use nonce ranges. I.e. the starting nonce could be block.number * 2^192

I'm in favor of 2)

@czepluch
Copy link
Contributor

I agree 2) is the best solution.

I will however need to change the messages to change the length of the nonce. Right now it's only 8 bytes and I think that's not quite enough. @hackaugusto you see any problems with this?

@hackaugusto
Copy link
Contributor Author

hackaugusto commented Oct 12, 2016

Increasing the nonce field seems backwards, after all the decision to not add a new field is to not increase the message size.

Why not go with option 1?

@czepluch
Copy link
Contributor

Valid point. If we try to avoid increasing the size of the messages, then it makes more sense to go with option 1.

@heikoheiko
Copy link
Contributor

how is 8 bytes not enough? 4bytes for all possible block offsets during the next 100 years and 4 billion transfers during the lifetime of the channels sounds good to me.

@heikoheiko
Copy link
Contributor

my assumption would be that hashing in the address of the contract might be more changes to the code base. but no strong preferences.

@heikoheiko heikoheiko modified the milestone: MVP Oct 19, 2016
@czepluch
Copy link
Contributor

This issue is very close to being done. PR will be submitted tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants