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 SMB, based on the bidding strategies provided by the device owners, and the gateway owners, the payments for using downlink / uplink LPWAN resources will be determined.The following parameters are set by the device in bidding strategies of the SMB:

max_bid: the maximum bidding price defined by the device owner shows the upper payment threshold of the device (in MXC tokens) for the downlink request.

max_delay: this parameter defines, under certain circumstances, the maximum acceptable_delay (in seconds) for the packet to be sent. If max_delay is reached, the packet will not be sent and the cloud will notify the client about the rejection of the downlink request.

accepted_delay: the tolerable delay defined by the client (or device owner) to indicate the time period a packet is willing to wait for the lowest possible price. Lowest possible bidding price is the current lowest bid of the available gateways for the device.

Each gateway provides a value on using its resources called min_bid. The device in order to use the gateway downlink resource, should bid at least min_bid value. If multiple devices in a same time wants to use a downlink resource of a gateway, the one which define more max_bid will be the winner.

More details about bidding procedure are provided in MXC Smart Machine Bidding white paper (available in the repository stated below and the MXC website).

Based on downlink / uplink data flow of the device owners and their requests, MXC cloud can provide data driven automated smart machine bidding. max_delay parameter is 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, accepted_delay, and max_bid parameters should be provided by the device owner (or the client) in some way to make a balance between priority of the related uplink/downlink data and the corresponding data transmission cost. These two parameters (accepted_delay, and max_bid) can be automatically provided for the device owner to make this balance.

Your task is to develop an automated solution (e.g. based on Machine learning methods, dynamic algorithms or greedy algorithm) which provides near-optimum value for accepted_delay and max_bid parameters to reduce the total cost of the LPWAN for the user.

In the input file, you will receive max_delay, 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 (preferably in Go) will be evaluated by output efficiency (based on the test cases of LPWAN data simulation), and solution explanation (provided in your documentation). Note that you can provide multiple solutions and do the implementation as much as you want/can. A sample input file and its details will be provided in the below repository: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