dARCH 2021 Event 0.5 — Services Only

The structure of this event will be very similar to dARCH Event 0. The major difference is going to be that the entries have to use the service model. The total prize pool for this testnet event will be 1,000 DERO

Round 1

Developers will have 3 weeks to develop and share their service.

The first round of judgment is on functionality only, not UX/UI.

5 Winners of 80 DERO each.

Round 2

All 5 winners from round 1 will progress to round 2 and they will have an additional 3 weeks to further develop their ideas. Their idea must maintain a at least the same functionality as the original POC but new features can be added.

3 Winners as follows:

1st Place 300 DERO
2nd Place 200 DERO
3rd Place 100 DERO

Round 1 entries must be made posted on this DERO forum post on or before 7PM UTC, May 1st, 2021. Judges will be the DERO developers and foundation with heavy consideration of input from the community.

Why services?

Services allow developers to use whatever language they choose in order to interact with the DERO network using websockets. This means that developers do not need to use DEROBASIC or DVM in order to create applications or services.

More info on the DERO service model can be found here :

Dero service model
*In-addition to release of private Smart Contracts , DERO has added unique feature on it’s blockchain through which…*forum.dero.io

Latest testnet releases : Releases · deroproject/derohe · GitHub

7 Likes

Here is a placeholder for my competition entry: Ether Seller.

The service is operated by a person who wants to sell Ether for Dero automatically, without using an exchange. The service accepts a fixed amount of Dero (e.g. 1 Dero) and replies with a secret key (hash) that can be used to redeem a fixed amount of Ether (e.g. 0.01 Ether) from an Ethereum smart contract.

The mechanism works as follows: a series of key pairs are generated, secret and public. Each public key is a SHA-256 hash of the corresponding secret key. The public keys are stored in an Ethereum smart contract. The secret keys are stored in the service database. When the service receives the correct amount of Dero, it replies to the transaction with one of the secret keys. The buyer can then use this key to redeem a fixed amount of Ether from the Ethereum smart contract. The redemption process requires two stages, to prevent a third party from potentially grabbing the secret key in the Ethereum transaction pool and then paying a higher transaction fee to steal the Ether. Further details of this will be published in Round 2.

One significant limitation of this service is that users must trust the service provider: there is potential for the service provider to take the Dero and not provide the secret key. So it is not as secure as an atomic swap. In reality, this type of service provider would probably operate within a community where feedback from users can be posted, and transaction amounts would likely be small, to limit losses in the event of fraud.

The service source code will be uploaded to github nearer the Round 1 competition deadline of 1st May, and a service address posted for people to try out.

If the service makes it to Round 2 of the competition, I will develop the Ethereum smart contract and post a live version on one of the Ethereum public testnets, to demonstrate a fully working system between the two blockchains.

10 Likes

DERO Message (dM) or Decentralized Message (dM)

The configuration involves a few pieces such as client services to be ran and hosted locally (similar to a local installation/use of Outlook or other platforms), as well as (V2) a server-side service which will handle unique usernames (V2-pending) and/or other methods for “contact lookup” , but the server service never hosts any encryption/decryption details for your messages (V1 is just deto / dero address).

Each client will have a local site, self-signed cert (V2) most likely or other method, in which will be a simple interface for interacting with their email clients. You can perform 3 separate actions: register (V2 - registering your user address/integrated address to a friendly name [V2-pending], this also validates whether a recipient is valid on sending), get emails (get emails sent to you and decrypt them), send emails (send emails to recipients).

  1. V1: Client enters deto/dero address(s) for contacts; V2: client A gets integrated address (of client B) from server side service via the normal deto address or username [V2-pending] (sent via COMMENT to integrated service addr and returned integrated via response).
  2. Client A encrypts message and sends to SC , STORE() as some random “key” (ensure it doesn’t exist in SC first) and the text of the message is AES-256 encrypted [future pending other methods/alternatives/compression etc.] chacha20poly1305 encrypted (derohe/cipher.go at main · deroproject/derohe · GitHub)
  3. Client A sends COMMENT with variable and decrypt key (formatted: var1/mykey [hex encoded make([]byte, 32, 32)]) for specific message (random decrypt every time) to integrated addr of Client B (received from step 1)
  4. Client B received tx with var / decrypt key and gets message and decrypts to be viewed.

V1 Summary: Clients share keys directly via rpc_COMMENT. Messages are encrypted with unique keys for every message (persists keys via tx look back and SC variable lookup).

V2 Summary: Server service knows no difference other than integrated addr for deto addresses (to be replaced with username or other unique id services in future), clients share keys directly. Messages are encrypted with unique keys for every message (persists keys via tx look back and SC variable lookup)

Github: dero-smartcontracts/DERO-Message at main · Nelbert442/dero-smartcontracts · GitHub

2021/04/22 10:09:56 [Main] DERO Message Service (client) :  This is under heavy development, use it for testing/evaluations purpose only
2021/04/22 10:09:56 [Main] Using wallet RPC endpoint 127.0.0.1:40403
2021/04/22 10:09:56 [Main] Persistant store for processed txids created in 'Dero_Message_c9b5132661147b603715cb43251c0db5a30d3925'
2021/04/22 10:09:56 [processReceivedMessages] Watching destination wallet rpc endpoint 127.0.0.1:60603
2021/04/22 10:09:56 [Website] Starting website at port 8080
2021/04/22 10:09:56 [API] Set stats collect interval to 10s
2021/04/22 10:09:56 [API] Starting API on 0.0.0.0:8224
2021/04/22 10:10:11 [API-sendMessageCall] Received message to be sent/processed: {deto1qxszqj0n53n4upw3mggf32yav5s22x5nlktwsvkfqzrrfrwajzewdxcuv9zmc Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. }
2021/04/22 10:10:11 [processSendingMessages] original string (len: 226):
Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know.
2021/04/22 10:10:11 [encryptAndSend] Encrypted text: [7 140 51 113 9 22 233 13 25 246 188 11 221 215 97 176 129 212 171 168 24 0 207 178 43 50 226 0 89 198 232 191 233 210 68 215 153 124 138 253 27 141 65 250 223 100 255 42 174 152 10 203 107 78 216 249 133 118 12 6 47 60 105 245 153 80 60 84 162 40 98 91 151 36 43 28 107 86 154 133 140 228 92 218 218 7 100 5 65 40 146 254 7 69 131 228 220 17 48 74 63 7 179 192 218 210 70 206 231 83 150 234 67 89 52 222 197 225 55 216 34 30 234 164 157 176 220 171 41 1 182 169 164 38 150 118 164 46 20 34 148 227 14 99 96 250 224 85 251 0 59 220 83 39 32 115 8 79 8 161 137 111 28 162 136 24 135 236 0 154 46 137 138 181 212 162 42 191 162 199 188 97 57 99 64 72 70 90 184 201 175 200 228 195 43 179 66 165 70 252 200 205 84 11 184 161 38 50 187 14 40 171 181 177 180 21 95 100 143 229 249 137 101 136 130 176 196 217 140 43 225 233 249 254 1 188 190 143 227 84 68 251 44 245 119 211 154 105 122 186 48 113 220 131]
2021/04/22 10:10:11 [encryptAndSend] Ciphertext: 078c33710916e90d19f6bc0bddd761b081d4aba81800cfb22b32e20059c6e8bfe9d244d7997c8afd1b8d41fadf64ff2aae980acb6b4ed8f985760c062f3c69f599503c54a228625b97242b1c6b569a858ce45cdada076405412892fe074583e4dc11304a3f07b3c0dad246cee75396ea435934dec5e137d8221eeaa49db0dcab2901b6a9a4269676a42e142294e30e6360fae055fb003bdc53272073084f08a1896f1ca2881887ec009a2e898ab5d4a22abfa2c7bc6139634048465ab8c9afc8e4c32bb342a546fcc8cd540bb8a12632bb0e28abb5b1b4155f648fe5f989658882b0c4d98c2be1e9f9fe01bcbe8fe35444fb2cf577d39a697aba3071dc83
2021/04/22 10:10:11 [processSendingMessages] Sending transfers tx...
2021/04/22 10:10:12 [Graviton-StoreSentTX] Storing &{1619100612 deto1qxszqj0n53n4upw3mggf32yav5s22x5nlktwsvkfqzrrfrwajzewdxcuv9zmc fe04e8790de030 [70 193 28 165 115 160 59 97 128 148 68 109 34 91 107 208 22 142 75 206 131 57 2 88 187 14 182 252 18 142 169 42]}
2021/04/22 10:10:12 [sendTx] TX Sent and stored
2021/04/22 11:08:47 [processReceivedMessages] varName: fe04e8790de030, passwordString: 46c11ca573a03b618094446d225b6bd0168e4bce83390258bb0eb6fc128ea92a
2021/04/22 11:08:47 [receiveAndDecrypt] results from SC found for fe04e8790de030.. continuing
2021/04/22 11:08:47 [Graviton-StoreTX] Storing &{1619104122 [70 193 28 165 115 160 59 97 128 148 68 109 34 91 107 208 22 142 75 206 131 57 2 88 187 14 182 252 18 142 169 42] fe04e8790de030 455ebec1b8c83c360333a32976f5d4ef40d3c1277e7429a65d0b272283a41ce1 Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. deto1qxqzm56tzvf6ahp5f5yjmepydqvcz95cs84n3zrgwuv4j4ky0na3xrgh5k5xj}
2021/04/22 11:08:47 [receiveAndDecrypt] TX Received and stored
2021/04/22 11:08:47 [processReceivedMessages] DecryptedText:
Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know.


12 Likes

Here is a placeholder for my competition entry: swap_xmr_dero

The dero’s user send some dero to the service, then the service request the tradeogre api to get the rate dero/xmr, and it send monero to the user’s address.

More info in readme.md.

This is a prototype. Do not use in any mainnet.
I need a feature to detect new block and new tx to make it better.

10 Likes

Code now uploaded for ETH Seller:

7 Likes

Don’t know if this is gonna be my final entry, since I’m already invested in my NFT project and might want to continue that. Maybe you guys can decide what you find cooler.
Anyway, here’s a little play project I developed to test the limits (or lack thereof) of the service protocol.

File Sharing over Dero network

Allows wallets to share actual files between each other.
No matter the file type, no matter the extension, and no matter the size.
In fact, the “limit” of ~128 bytes per payload is easily “bypassed” by splitting the files into multiple parts, sending them in multiple TXs, and re-assembling them together on the receiving end.
A final TX with the SHA256 checksum of the file is also sent to the receiver so that the client can verify the integrity of the file.
Of course, the larger the file is, the more it’s going to cost to send it and the more it’s going to bloat the chain. On testnet it’s just 0.00001 DERO per TX; on mainnet I expect there will be higher fees. Therefore, WHENEVER possible, users should avoid using this system and stick to IPFS/something else.
However, if someone really wants to make use of a private peer-to-peer file transfer over a secure network like Dero, they technically can and this prototype shows how. It supports both text and binary (encoded in base64) files.
Oh, and on an important note - that will sound obvious to those who know how the protocol works - sender and receiver don’t need to be online simultaneously in order for the file transfer to happen.

Here’s the source code: dARCH-smart-contracts/dero-file-sharing/cmd at main · Peppinux/dARCH-smart-contracts · GitHub

And here are some screenshots:



10 Likes

I’m doing my part too :sweat_smile:

8 Likes

DERO GUARD is a decentralized VPN service.

A marketplace based on Smart Contracts will be available to list anyone offering this service.

To register as an exit node provider, you will just have to register with the service address and put your asking price for 1GB of bandwidth and your location.

A user wishing to use a VPN must register with the service by making a transaction from his DERO address with the DERO amount to calculate his bandwidth credit.

Based on wireguard, a gui client will be built to be easier to use it.

Source code: GitHub - Slixe/dero-guard

For more details, please see README.md on GitHub.

11 Likes

Ckd: Open web services for dApps (WIP)

Hey all,

I’m not sure this qualifies as a Service in its current state, but the project aims to include a collection of Services dApp developers can easily integrate (e.g. npm install ckd-react) into their apps. Regardless, thought I’d post here.

I’m not the best writer, so I did a video to go into details:

https://www.youtube.com/watch?v=Fklet5MSm6w

Source code:

7 Likes

Project updated for the second round.

6 Likes

Ran into issues posting too many links, so check out this GitHub comment for my round 2 updates.

3 Likes

DERO Guard as a Desktop app

Connected to a VPN:

Disconnected:

On connecting:

Provider list:

Refill GB:

Service side:

New GitHub link: dero-guard · GitHub

Mobile version coming soon…

Credits: @Litarvan & me

13 Likes