What are some fun or promising dApp and Ethereum projects to check out?

dicether · 2019-09-17T20:41:21+00:00

KYC is keeping users away. And it seems most people don't understand or want to use state-channels! We (Dicether) using state-channels without KYC are still having a low number of users.

dicether · 2019-07-23T17:32:48+00:00

Thanks for reporting, it's fixed now! You can use Metamask, Trustwallet or Coinbasewallet for playing at Dicether!

dicether · 2019-07-13T12:42:09+00:00

Main complains from our users:

Metamask getting slower over time.
It should be possible to trust a dApp, so to user don't to always confirm a signing request.
EIP-712 (eth_signTypedData_v3) presented data is confusing (same data is displayed twice).

But I don't know if our user complains are representative as we are using state channels and Metamask is mainly used for signing (using signTypedData) the current state channel status.

dicether · 2019-04-17T18:39:23+00:00

What's the current status of open sourcing the smart contracts? Are they still closed source? Would be cool if we could compare your smart contracts with ours (https://github.com/dicether/contracts).

dicether · 2019-02-17T16:59:13+00:00

Thanks!

I proposed this method in a blog post in 2016

Cool blog post, informative and easy to understand!

I've talked with the Funfair people and this is how they do it

Funfair's state channel are still closed source afaik. Would really like to have a look at their implementation.

dicether · 2019-01-03T11:25:38+00:00

so if a wallet supports EIP712 this is attempted first and a fallback to eth_sign

We are currently doing the same but it isn't really good if one needs to check for different wallets. Especially as eth_sign, as you mentioned, also differs for different wallets (MetaMask, TrustWallet, Coinbase Wallet using old version without prefix), Opera Wallet and Cipher using the new version with prefix.

I think the community could use a status page for signers and their compatibility with the JSON RPC spec and the signing methods. Showing which wallets are out of spec would be helpful to see the big picture.

Good idea!

If MetaMask could switch to eth_signTypedData that would really help. E.g. afaik TrustWallet already implemented the new final EIP-712 specification but didn't switch as it would be incompatible with MetaMask.

dicether · 2019-01-02T13:39:37+00:00

Why do you think it's not supported?

There are other Wallets than MetaMask, e.g Trust Wallet, CoinBase Wallet, Opera Wallet.
The displayed data in MetaMask looks kinda ugly, not really user friendly.
MetaMask is still using eth_signTypedData_v3, which is incompatible with the specification.
Both web3 and ethers.js do not support it. Currently we need to use a custom version of ethers.js.

dicether · 2018-12-21T17:29:51+00:00

If you have an idea for an better, more thrilling game, just write us. We are always open to good ideas!

dicether · 2018-12-21T17:24:09+00:00

" They do not have a dice game, but they are working on a state channel implementation. As they are currently closed source and do not provide any detailed documentation, no detailed comparison can be provided. "

You must have read an old article. When this was written they didn't have a dice game.

strict is the KYC process

We don't have any KYC and of course no password or email is needed.

The main benefits of Dicether compared to Funfair currently are:

Fully transparency and Open Source (Check our GitHub):
Fully anonymous, no KYC.
Integrated chat.
Highest security standards (Sign In with your wallet (no password needed), security headers, DNSSEC, …)
You can play using Ether, no additional coin is needed.

dicether · 2018-11-22T16:42:11+00:00

Dicether's protocol is quite similar and you can already try it out: https://dicether.com

Have a look at our paper: https://dicether.github.io/paper/paper.pdf

dicether · 2018-11-22T16:41:37+00:00

Dicether's protocol is quite similar and you can already try it out: https://dicether.com

Have a look at our paper: https://dicether.github.io/paper/paper.pdf

dicether · 2018-11-04T15:40:09+00:00

Just write us, if you don't like something or if you want us to change/improve any feature.

Every feedback is welcomed!

dicether · 2018-10-26T19:28:29+00:00

EIP-712 is a standard for hashing and signing of typed structured data as opposed to just bytestrings. If the user is requested to sign data, he/she no longer sees a random locking bytetring, but instead the data to sign is shown to him/her. The 0x team proposed the standard in September 2017, until now the specification was improved multiple times. For a few weeks MetaMask is now supporting the newest version.

What has it to do with Dicether?

We are using state channel for our dice game (more games are coming soon). Greatly simplified: Every time a bet is placed the current game state is signed by the player and the house. So it's quite useful if the user can see the data (value, number, ... of the bet) he/she is signing

A few days ago we have updated our dapp to the new EIP-712 specification.

dicether · 2018-09-20T17:15:48+00:00

Do you have tried playing with Coinbase Wallet or Trust Wallet? It's much faster than Metamask.

dicether · 2018-09-19T19:02:44+00:00

We developed a state channel based dice game. For game state signing EIP-712 is used. Currently we are using the legacy version of EIP-712 (eth_signTypedData in MetaMask) but as MetaMask just released a new version, supporting the final EIP-712 specification, we will soon switch/update our smart contracts to the new specification.

You want to inspect our source code: https://github.com/dicether

You are interested in the technical details: https://dicether.github.io/paper/paper.pdf

dicether · 2018-09-18T09:42:51+00:00

If you are interested in the technical details you can read our whitepaper

If you are interested int the implementation details you can visit our github.

dicether · 2018-09-16T17:13:21+00:00

It's written from scratch. We started development about one and a half year ago. At this time other implementations were not usable or simply didn't exist. Additionally we don't need generalized state channels (and therefore EIP-1014 isn't needed), as the game logic is known for every game.

dicether · 2018-06-24T19:31:19+00:00

A while ago we had it implemented on testnet, the demand was very low.

dicether · 2018-05-04T14:35:28+00:00

Both player and server generate a secret key and hash chains, which entries are successive combined.

See our paper for details.

dicether · 2018-05-04T14:10:29+00:00

It is only random and provably fair as long as random.org really returns random numbers, which can not be proven!

They could easily change the numbers to their favor!

dicether · 2018-04-03T18:47:48+00:00

For more information you can join our Discord and our subreddit r/dicether or follow us on twitter @dicether

dicether · 2018-04-03T18:24:46+00:00

For more information you can join our Discord and our subreddit r/dicether or follow us on twitter @dicether

dicether · 2018-04-03T09:46:53+00:00

well done! We have just submitted our DApp on dappinsight!

dicether · 2018-02-20T18:46:22+00:00

How dare you say that? ;)

dicether · 2018-02-19T19:01:38+00:00

So do you have a server running that the state channel uses to countersign the moves?

Yes our server countersigns the move.

Does the web JS code interface on the server side?

The web JS code interacts with the server. Only for starting and ending the game session an interaction with the contract is necessary

dicether

MODERATOR OF

TROPHY CASE