search

KomodoPlatform / pycc

Crypto-Conditions for Komodo in Python
5 stars 5 forks source link

Providing entropy #8

Open ssadler opened 4 years ago

ssadler commented 4 years ago

Many applications will require ~random numbers~ entropy. Entropy is distinct from a random number provided by deterministic RNG because parties know that it exists but don't know what it is, yet. This issue is to discuss how best to provide it.

quotes from @alrighttt

  1. Notariser entropy

    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.)

Note: there's actually an ethereum contract which provides random entropy and allows anyone to submit a transaction to add to the entropy

  1. Dealer entropy

    @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.

  2. Preimage entropy

Another idea: 2 parties, Alice and Bob, both provide a hash where the preimage contains a random seed. After the hashes are confirmed on chain, alice and bob both reveal the preimages, and the random entropy is the hash of both of their preimages. So far, no collisions have been found in sha256, but to make it a little harder there could be a common prefix requirement. This seems very simple so maybe there's some issue with it? It's basically the same as dealer but both parties provide their hash in a single transaction together.

  1. NIST provided

@alrighttt also mentioned:

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.

This seems like it could be useful for some applications, since the NIST interface appears to provide an indexable and signed sequence of random numbers, so that parties could agree on the random number of some future index and then the verification of that random number can be checked on-chain without additional I/O by using the NIST provided pubkey.

There is also https://www.cloudflare.com/leagueofentropy/ and maybe other projects.

A good result would probably be to provide several options with pros and cons of each, and provide an interface to them in a module like pycc.entropy or similar.

jl777 commented 4 years ago

a DTO using NIST can provide new entropy every minute. using each one as a seed to a deterministic random algo would provide an arbitrary number of entropy values

ssadler commented 4 years ago

a DTO using NIST can provide new entropy every minute. using each one as a seed to a deterministic random algo would provide an arbitrary number of entropy values

You could get extra random values, yes, but you couldn't increase the frequency of unknown values (entropy). I should probably edit the title.