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

Potential typo in deployCTF? #2

Open
yippee-ki-yay opened this issue Mar 14, 2018 · 3 comments
Open

Potential typo in deployCTF? #2

yippee-ki-yay opened this issue Mar 14, 2018 · 3 comments

Comments

@yippee-ki-yay
Copy link
Contributor

https://github.com/SpankChain/general-state-channels/blob/master/contracts/ChannelRegistry.sol#L30

In the part of the code that should check the signatures of the bytecode to be deployed, the for loop is initialized at 2 and check if it's less than 2, so the for loop never enters.

@yippee-ki-yay yippee-ki-yay changed the title Potential typo in ? Potential typo in deployCTF? Mar 14, 2018
@nginnever
Copy link
Contributor

nginnever commented Mar 14, 2018

Yes good catch. And thanks for the eyes on the repo! Please feel free to fork and put in a small pull request to fix this if you would like a contribution on the project.

I plan to do some big overhauls to this in the coming days including...

  • Building a roadmap and contributions guidelines.
  • Start weekly updates that I will be putting out in the form of a captains log git issue. (daviddias ipfs inspired)
  • Refactor Bond Manager (moving towards Stefan's Gnosis Safe)
  • Refactoring state representation (Optimize for efficiency)
  • "Merkelize" state, sign and store root hashes, and add inclusion proofs. (this will allow state to be modular and for interpreters to only need to care about the subset of state they are responsible for decoding. This should increase the theoretical limit of open channels to the complexity of proving inclusion of correct subset state (O(log N)) and the reconstruction of that specific state (O(c)).
  • Add real tests for the current support channels
    • Single Direction Payment
    • Bidrectional Payment
    • Crypto Kitties Battle Game
    • Any other module that others would like as a sub-channel
  • Work on a hub that can handle connections to many users and all sub-channel systems.
  • Discuss representing state as a pool of transactions that could be executed on chain. Form a merkle root of all transactions that lead to an agreed upon current state. In the event of a final state challenge, highest nonce merkle roots may be stored in the channel manager that define a set of transactions that will lead to a final balance for the multisig. A proof of inclusion will be ran against the current highest nonce root when transactions are ran against now deployed state channels.

@yippee-ki-yay
Copy link
Contributor Author

OK cool, I'm glad this will be moving forward, I'm working currently at my company on utilizing state channels for games and developing and library around it and your research is very helpful.

The Merkalized state is a very interesting approach as logic for some games (other stuff as well) can get quite heavy and onchain resolution may be too costly. We've been thinking of some ways to split the logic up so you only need to handle a subset of computation.

"Discuss representing state as a pool of transactions that could be executed on chain. Form a merkle root of all transactions that lead to an agreed upon current state." - So basically a block of transactions? :D
Not sure if I quite understood the last part but sounds interesting.

@VoR0220
Copy link

VoR0220 commented Mar 14, 2018

@yippee-ki-yay essentially that's what he's describing is a block of transactions. The main takeaway is that they are externalized and the proof exists, and how you assemble to that proof is the key consideration.

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

No branches or pull requests

3 participants