-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
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. |
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. |
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. |
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? |
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.
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? |
@nickreynolds. Good idea. This feels like a must regardless. |
Please have a look at issue #21. Opening it up for discussion. |
Closing for now, opting for multiple generators. Alleviates problem of having to update front-end fast enough to support new generators. |
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.
The text was updated successfully, but these errors were encountered: