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

Implement Art Generation Staking Hash Contract #3

Closed
simondlr opened this issue Jun 15, 2018 · 8 comments
Closed

Implement Art Generation Staking Hash Contract #3

simondlr opened this issue Jun 15, 2018 · 8 comments

Comments

@simondlr
Copy link
Collaborator

The art generator that uses the blockhashes from the art auction generates art based on a hash pointing to a set of software used to generate the art.

The initial art generator will be: https://mattdesl.svbtle.com/generative-art-with-nodejs-and-canvas.

The hash is thus: 55f74ddc033dc34ca3b11ece54e6e569c24ea7da.

The artonomous soul tokens generated by the curved bond is used to stake towards any hash. The highest ranked hash is regarded as the current art generator.

Old artworks won't change. New artworks will be generated based on the new chosen hash.

@simondlr
Copy link
Collaborator Author

simondlr commented Jun 15, 2018

It's debatable whether it will be too much work to update the generator each time the hash changes, so I'd opt for the new artwork to take an extraordinary amount of tokens staked to switch/change rather than the highest ranked one at any given point in time.

eg, only if 50%+ or 70% of current outstanding tokens are staked to a new hash is it formally switched.

@simondlr
Copy link
Collaborator Author

fwiw. This design for me is the most unsure part of the architecture. If anyone has some reasoning about it, let me know.

It's not explicitly needed, but I think it's novel to be able to also use the soul tokens to improve its art. The deeper question is how you manage to keep the front-end going sufficiently if the hash keeps changing.

When a hash changes, someone needs to commit a change to the front-end code in order to generate the new artwork from the inputs.

@tarrencev
Copy link
Collaborator

A little tangential to the discussion above, but should artwork only be computer generated? Or could it be contributed by a human artist?

I wonder if it makes sense for the proposer of a generation method to receive proceeds from the sale?

In that case, an artist/algo dev could propose their generation method and be rewarded for art sold using it.

@nickreynolds
Copy link
Contributor

Setting a minimum stake percentage for switching could cause issues if there's low participation. I suppose it might be ok if the token holders can vote on that minimum stake percentage as well.

A different solution would be to add a delay to switching generators. Once the top staked generator is switched, it kicks off a ~2-week switchover period that gives clients time to update?

@simondlr
Copy link
Collaborator Author

A little tangential to the discussion above, but should artwork only be computer generated? Or could it be contributed by a human artist?

It should be at least deterministically reproducible given the input of the chosen blockchash, so I'm not sure how human artists could work in this specific implementation. But it's an interesting thought direction.

I wonder if it makes sense for the proposer of a generation method to receive proceeds from the sale?

This would aid the self-improvement of the autonomous artist by further and more quickly generating new and improved generation algorithms.

There might be a way to do it trustlessly: the hash of the software could an IPLD hash containing metadata that has the payment address in it. You can verify CBOR blobs in Solidity (not sure how expensive it is though), so you could perhaps trustlessly eke out an address too.

Another combination is that the staking is both the software hash AND a beneficiary hash.

Soul tokens can be rewarded to the generator algorithm when buying/selling in the curve.

I feel for now, it's probably best to keep it simple. Not sure what others think?

@simondlr
Copy link
Collaborator Author

A different solution would be to add a delay to switching generators. Once the top staked generator is switched, it kicks off a ~2-week switchover period that gives clients time to update?

@nickreynolds. Good idea. This feels like a must regardless.

@simondlr
Copy link
Collaborator Author

Please have a look at issue #21. Opening it up for discussion.

@simondlr
Copy link
Collaborator Author

Closing for now, opting for multiple generators. Alleviates problem of having to update front-end fast enough to support new generators.

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