OLD: DIscussion: spam and art forgery

[markusbkoch]

This came up as we discussed the project at @BlockScience.

Allowing an indefinite number of generators to be active at the same time would make it very cheap to create new artwork under the artonomous "brand", which could open the doors to spammers and art forgers.

We do not need to design the solution now, but at this stage we view resolving incentives to spam the system and/or forge art as a system requirement, and would like to know everyone's thoughts on this.

[simondlr]

I'm trying to figure out what forgery will look like if it is generative art?

[markusbkoch]

I might be missing something or overestimating what generators can do, but I was thinking the forger generator would not really do generative art. Instead, it would return images visually indistinguishable from other artworks.

[simondlr]

Ah, yes. I can see it now. It just takes say 10000 copyrighted images. Uses the blockhash as randomizer and just displays the image as a result. Might make more sense then to stick to one hardcoded generator for the MVP whilst we keep thinking on these issues as they crop up for multiple generator support.

[spengrah]

Offering some potential ways to deal with spam/forgery:

• The “ask permission” approach: Proposed generators must apply to the “legit generators” TCR, which is governed by soul tokens. Only generators accepted into that list are eligible to sell art on artonomous.

• The “beg forgiveness” approach: spammers caught generating spam or forgeries get their soul token and eth holdings slashed. Some portion of those tokens is transferred as bounty to the account that identified the forgery. Soul token holders vote to decide the challenge.

These are basically the same mechanism; the difference is mainly in the default eligibility of generators.

What do people think? Any other approaches? Definitely starts getting more complicated, but we knew that would happen when supporting multiple generators 😸

Btw, I’m all for an iterative approach that starts with a true MVP. In fact, the concept of building an MVP (that can be iterated on) with smart contracts is something I want to think through more. Is it just a matter of building on test net, or does it require using upgradability patterns?

_{Sent with GitHawk}