Figure out what needs to go in standard contract library

[ssadler]

PYCC should have a module pycc.standard, which includes a schema with contracts that you can take "off the shelf" for use in your blockchain.

• Tokens is fundamental, it's expected that every application would want to make heavy use of tokens.
• Faucet is a pretty basic one that could be useful in quite a few cases, and is very useful as a "hello world" example of how CC contracts work due to it's simplicity.

What else should or could be provided?

[ca333]

There was high demand and 3rd party interest for "gambling" related CCs - maybe a dice, lotto or 'roulette' sort of contract?

[ssadler]

There was high demand and 3rd party interest for "gambling" related CCs - maybe a dice, lotto or 'roulette' sort of contract?

@ca333 I feel like these things are more "apps" so they should have their own repos, with branding, frontends etc. But, we should make them easy to create, by providing the necessary primitives. Off the top of my head:

• Random numbers (have we solved this one? @Alrighttt?)
• Accounts (v hard to do a lottery without this)

Anything else I may be missing?

[ca333]

• Random numbers (have we solved this one? @Alrighttt?)

we don't have a proper generic/high level blockchain based RNG (yet) afaik - having one would def solve a lot.

we have a more experimental and vuln lotto CC ref. implementation:
https://github.com/komodoplatform/komodo/blob/master/src/cc/lotto.cpp
https://github.com/komodoplatform/komodo/blob/master/src/cc/CClotto.h

• Accounts (v hard to do a lottery without this)

+1, certainly needed for many casino related apps

[Alrighttt]

@ssadler

* Random numbers (have we solved this one? @Alrighttt?)

We can use notarization hashes or momom data as entropy, but this limits many use cases as it can only happen every 3 minutes at the fastest. It happens every ~10 minutes using default iguana configuration. I believe this is a sufficient source of entropy as it's highly unlikely a single person/party can influence it. (actually, everyone can influence it. Spam some txes and you can be relatively sure no one is entropy grinding.)

@jl777 used a method in Dice CC which can support faster times. The "dealer" would create entropy, hash this entropy and broadcast this hash inside a transaction. The "bettor" would then choose one of the dealer's utxos and bet against it. Dealer would then be forced to reveal entropy within some time frame or the bet would default to a loss. Once entropy is revealed, either party can finalize it. I recall some issues with this concept, but I can't remember exactly what they were. If you're interested, can try to dig through on chat logs from the discord server.

https://beacon.nist.gov/home
@dimxy has done some work on pushing data from this api on chain via the "decentralized trustless oracles" concept. I believe this could could allow a dapp to get a new source of entropy per block time.

* Accounts (v hard to do a lottery without this)

very hard, but not impossible. Payments CC is an example of a CC that can handle the huge amount of utxos that would be needed.

[ssadler]

I made an issue #8 for the RNG thing.

[dimxy]

in the kogs game project we need randoms created more often (several times in a block)

[ssadler]

@dimxy could you look at issue #8? See if option 3 would work?