LONGHASH
CRYPTOCON VOL.2

Background:

Cybex.io is a blockchain based decentralized exchange that supports crypto trading. When a user has an intention to perform a large trade, it is useful to have an algorithm to split the order into smaller slices and trade it over a longer period. This feature is referred as ‘Algo Order’ and is widely adopted in regular exchanges.

In decentralized exchange, each sliced order must be signed by the user’s private key. This provides a new challenge to algo orders. In order the place orders automatically, while keeping the private key safe, a user typically has to write its own program and run it in its own machine. This makes it difficult for normal users to use algo orders due to the lack of programming skills.

Design a solution that allows a normal user to execute and manage algo orders.
The following are some basic Algo order types:

TWAP

http://empirica.io/strategies-catalog/twap

VWAP

http://empirica.io/strategies-catalog/vwap

Iceberg

https://www.investopedia.com/terms/i/icebergorder.asp

The solution should be using Cybex API, which is available at the following locations:

Cybex API server documentation

https://apidoc.cybex.io

Sample program to place an order

https://github.com/CybexDex/cybex-python

Solutions will be graded on

User interface friendliness

The ideal solution should be easy enough to attract people without programming skills

Security

As trading involves using private key, the management and storage of the key is a crucial consideration.

Framework Coding quality

MXC foundation focus on connecting Low Power Wide Area Network (LPWAN) technology with the blockchain as an infrastructure for Internet of Things (IoT). MXC automates machine-to-machine (M2M) transactions and provides a device data economy. The pricing policies of data transmissions through gateways in LPWAN are determined by MXC Smart Machine Bidding (SMB). In the MXC SMB, based on bidding strategies provided by the device owners, and the gateway owners, the payments for using downlink / uplink LPWAN resources will be determined. Details and the parameters explanation, are provided in MXC Smart Machine Bidding white paper.

Based on downlink / uplink data flow of the device owners and their requests, MXC cloud can provide data driven automated smart machine bidding. If the device is using single bidding strategies (auction, fixed price), max_bid parameter should be provided by the device owner or the corresponding client.

accepted_delay and max_delay parameters are mainly related to the application and the priority of the data which is known by the device owner/client and is defined by the requirement of the provided application by the device.
At the other hand, max_bid parameter should be provided by the data owner (or client) in some way to make a balance between priority of the related uplink/downlink data and the corresponding data transmission cost. max_bid parameter can be automatically provided for the device owner to make this balance.

Your task is to implement an automated solution which provides near-optimum value for max_bid parameter to reduce cost of the LPWAN for the user. max_bid value should be provided based on the priority of the device data, payment limit which the data owner wants to pay in total (for all of the transactions), and the downlink resource usage history of the device and other devices.

Your program in Go will be evaluated by test cases of LPWAN data simulation. A sample input file and its details will be provided later.

https://gitlab.com/mxc-hackathons/smb

Background :

Data privacy and security has become an increasingly urgent concern worldwide. Large corporations cannot simply collect data from its end users without their knowledge or explicit consent. However, it would be nice if a manufacturer could still collect data generated by its devices without user consent, but do so in a way that’s cryptographically-guaranteed to be anonymous.

In this scenario, the manufacturer would like to collect data from anonymous devices, but it would want to be sure the data it’s receiving is not garbage and is guaranteed to have come from a device it has manufactured. The end user would not mind that its device’s data is being harvested as long as it is impossible to trace that device’s data directly to the end user’s identity.This problem is broadly defined as direct anonymous attestation, and more narrowly defined as a membership proof. An earlier paper ( https://infoscience.epfl.ch/record/128718/files/CCS08.pdf ) had been published with an open-source implementation published ( https://github.com/ing-bank/zkproofs ).

Assumptions :

We assume that the manufacturer has embedded within each device it made with a pair of asymmetric encryption keys, and that hacking the device on-premise to obtain these keys is prohibitively expensive to do. We further assume that the manufacturer is willing disclose the public keys associated with all of its products to the open.

The challenge: HOW to implement an anonymous data collection scheme that allows the manufacturer to anonymously collect data from its end devices without knowing exactly which device it came from?

A device can prove to the manufacturer that it is indeed one of the devices it has created

The manufacturer will construct a temporary X.509 certificate so that a proof does not need to be provided every time, temporary because the end user might want to stop even anonymous data collections

Bonus:

Manufacturer & device both anchor the challenge & proof onto the blockchain

Device anchors its data transmissions onto the blockchain with the temporary certificate