search

artonomous / artonomous-mvp

A Self-Owning, Self-Sustaining, Self-Improving Autonomous Artist Using the Ethereum Blockchain
158 stars 21 forks source link

Determine what portion of SOUL tokens to grant to start auctions. Need some token engineering help. #26

Closed simondlr closed 5 years ago

simondlr commented 6 years ago

I think this is potentially where we can get some help from token engineering simulations.

For each generator, it donates some SOUL tokens that is staked to that generator to whomever starts each auction.

The goal of this is two-fold:

markusbkoch commented 6 years ago

I like what you said in #21

I feel it's important to design this in such a way that there's no magic numbers involved: eg choosing a hardcoded fee or choosing a hardcoded percentage threshold. These are unknown at this stage, so would rather opt for some more continuous, market-based options.

How about having callers (accounts/bots that start auctions) compete for the fee in a reverse auction?

markusbkoch commented 6 years ago

IMO, though, incentivizing callers is not as needed in Artonomous as it is in CryptoKitties. It's in the generators best interest to start auctions within the 256 blocks period. As long as the system does not make it impossible for them to delegate this task to others, people will come up with different incentivization strategies, both on- and off-chain.

simondlr commented 6 years ago

It's in the generators best interest to start auctions within the 256 blocks period.

I'm not 100% sure what you are referring to here? The blockhash is chosen at the start of the auction itself, so the blockhash limit shouldn't be an issue?

And yes, it seems like the incentive should be enough to start it since it's in the interest of generator creators to kickstart it.

markusbkoch commented 6 years ago

As the start-auction transaction is being processed, the hash of the block it will be included in is unknown. The hash of the previous block could be used, but then people would know the hash (and thus the art piece) before they start the auction, and could decide on whether or not to start it based on that information.

So an interesting design for extracting randomness from block hashes is to use the hash of a "future block". This is a good post on the subject https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620

In cryptokitties, the breeding transaction defines the future block (breeding block + cooldown period). From the point of view of the birthing transaction, that is a block in the past, so its hash is available (for 256 blocks).

Different implementations could achieve the same result in artonomous, such as one auction defining the block of the next, or having two separate transactions to start an auction (something like schedule+start). Clearly defining and simulating them would allow one to prove and/or estimate how well they meet the requirements and what impact they have on other parts of the system.

EDIT: we digress; taking this to #2

simondlr commented 6 years ago

As the start-auction transaction is being processed, the hash of the block it will be included in is unknown.

Oh, derp. Of course. Yes.

The hash of the previous block could be used, but then people would know the hash (and thus the art piece) before they start the auction, and could decide on whether or not to start it based on that information.

I don't initially this is a problem since ultimately it is about letting the generator produce good art, so it will be optimized towards choosing/starting on whomever believes it is good.

A future blockhash doesn't make sense to me, since you need to be able to see the artwork if you want to decide to buy it.

cc @nickreynolds. This is relevant to the discussion in #20.

simondlr commented 5 years ago

Closing for now. Opting to not include a carrot-on-the-stick to kickstart an auction. :)