Motivation

Advanced orders such as stop limit, allows users to place an order to cap profit, or loss on the system automatically. This has been a frequent requested feature. The biggest challenge to doing this on the blockchain is how can we hide the stop price from the public. It's a valid concern because when other traders know where the stop is, they are incentivized to push the price up or down, and activate automated limit order to execute. When large stops cluster, and get triggered automatically, the price of the asset falls fast, and open opportunities for other traders to buy in cheap.

Scope

Ideally, we need a solution where it works without any interaction from the trader from the point when the order is placed. Computation time should be comparable to plaintext comparisons. And ideally it does not change the existing consensus protocol.

Research

We've looked at the most advanced research in cryptography including Zero knowledge proof, Homomorphic Encryption, Secure Function Evaluation, and Secure Computation Execution. The most well known solution is Yao's millionaire problem. It essentially goes, out of N millionaires, how do we know which millionaire is the richest without revealing their information. Most of these solutions require online interaction to obscure the message, or provide some proof. Unfortunately, we can't expect trader to be online, which is the feature in itself. Other solution such as Homomorphic encryption requires both inputs to be encrypted. The use case is for encryption data, send to someone else to compute, and send encrypted result back to the original user with the private key to decrypt. For us, trader stop and future price are separate, and so it does not apply directly. There are other solution such as SFE, requires too much computation time. Shared secret such as Shamir can be done, but requires too many rounds of communication.

If we can't encrypt the code or input, then the next best thing is input and code obfuscation. XOR operator is the most popular because of its simplicity.

Let's suppose m is the Message, and S is secret. The cipher is M XOR S.
C = M XOR S

To decrypt,
M = C XOR S

Other techniques can be used in addition to obscure such as block ciphering , encoding the code into string, Dead code insertion, register reassignment, subroutine re-ordering, instruction subroutine, and code transportation. See 4

Design

We propose to extend the existing limit order by introducing an "encoded_script":

signed_transaction sell_asset(string seller_account, string amount_to_sell, string symbol_to_sell, string min_to_receive, string symbol_to_receive, string encoded_script, uint32_t timeout_sec = 0, bool fill_or_kill = false, bool broadcast = false)

This encoded script is generated by a compiler then evaluated by each block producer.

Compiler

We will provide an open compiler which takes a high level script then convert and obfuscate the code in webassembly, then encoded as base64.

P(limit_price, stop_price, order_type) = EncodeBase64(Compile(limit_price, stop_price, order_type))

Execution

The block producer will execute the web assembly code in a closed environment with an input (such as the current price), the program will produce a limit order. Once the order has been produced, the limit order is marked for deletion and will not be executed in the future.

P = DecodeBase64(encoded_script)
P(current_price) = limit_order || none

Obfuscation

Suppose we break up an int64 in 8 bytes, XOR it with one of the random byte in the dataset, shuffle the 8 bytes where it is "shifting and combining back to int64.

Combined, we have 8 bytes for stop, 8 bytes for limit, and 2x8 bytes for dummy values. We shuffle data ordering. The guesser has to choose 8 from 32 = 35960 combinations.

RSA based instead of XOR

Pohlig-hellman is a good shared secret encryption to apply.

C=M^e(mod p)
where M is the message, e is the key, and p is a prime number.
Plain = C^d mod p

This produces much larger cipher say, 4 x the original bytes. This increases the range of bytes to choose from 32 out of 128. eg 1477806921502280666682474774300 combinations to choose from.

How much work it takes to find the stop price?

1. Listen to each block
2. Decode the user script back into assembly but the stop price is in pieces
3. Every script would look different (different inputs, different code), it is difficult to extract value.

Cost & Limitation

We must immediately set a limit on # of bytes that can be submitted and executed to prevent abuse (say 10Kbytes). Any transaction that does not meet this criteria will be rejected immediately. We may consider adding a whitelist of assembly instructions to prevent any unexpected execution (even though it's in a safe environment). In addition, the cost of platform fee for the order can be calculated based on the # of bytes submitted.

Extensibility

Two areas open up for future work on top of this protocol changes.

1. The compiler is independent of the blockchain protocol since it is generated on client side. That means, we can innovate more on the obfuscation without significant change.

2. More advanced orders can be added without changing the client protocol.

Links

1. https://medium.com/@juliankoh/introduction-to-privacy-preserving-smart-contracts-e7bdc1a121b1
2. https://blog.ethereum.org/2016/01/15/privacy-on-the-blockchain/
3. https://blog.ethereum.org/2014/12/26/secret-sharing-daos-crypto-2-0/
4. https://sensorstechforum.com/advanced-obfuscation-techniques-malware/
5. https://www.andreafortuna.org/cybersecurity/malware-obfuscation-techniques-four-simple-examples/
6. https://stackoverflow.com/questions/31678344/compare-two-integers-using-bit-operator
7. https://profsims.com/encryption/poh

Dear Quanta community, I want to propose my services as a Quanta Block Producer

Please vote for

Who I am?

Biography about your credentials (finance and/or tech), when you know about QUANTA, and any relevant work experience/and project.

Your setup

Hardware (specs), datacenter, location.

Summary:
*
*
*

Contact:
Telegram: ...
LinkedIn: ..

Allowing individuals to engage in market making on QuantaDex would improve its liquidity.

https://github.com/CoinAlpha/hummingbot/issues/new/choose

Motivation

We need to introduce a maker-taker "market fee" system to incentivize market maker coming into the platform. The maker typically get a lower fee, or rebate compared to the taker. This added incentivize drives them to place more orders in the system, facilitating liquidity in the system.

Approach

The general approach is to introduce a number of parameters in the genesis.json which will be allowed to voted upon by DPOS.

Fees are deducted from the receiving asset. Suppose a transaction of:

Buyer A buys 1 BTC for 4000 USD and Seller B sells 1 BTC for 4000 USD

Additionally, assume the buyer is the taker, and seller is the maker.

The fee to buyer A pay is in BTC, and the fee to seller B is paid in USD

Fees configuration

market_fee - Asset's market fee is already set by the asset issuer, will assumed for taker fee.

maker_rebate_percent_of_fee - ranges from 0, to 100% for full rebate, or > 100% for transfer from the taker fee. Maximum is 200%

Taker fee is calculated as, market_fee - (market_fee * maker_rebate_percent_of_fee). Negative number reflects, fees coming from taker.

referrer_rebate_percent_of_fee - ranges from 0 to 100% of the total available fees where remaining fees >= 0

Total available fees = market_fee (taker) + (market_fee - (market_fee * maker_rebate_percent_of_fee))

Remaining fees = total_available_fees - referral_fees goes back to the issuer.

High volume market maker

Parameters:
hv_market_makers - a list of high volume market maker to be voted in by the committee

hv_market_maker_rebate_percent_of_fee - gets rebate for x (maximum 100%) from the fee pool. total_rebate = maker_rebate_percent_of_fee + hv_market_maker_rebate_percent_of_fee

Flow of Fees

[ Taker ] ---> pays ---> [ Fee Pool A]

[ Maker ] ---> discounted (up to 100%) ---pays ---> [ Fee Pool B]

Pay Rebates

[ Fee pool A ] --> pays rebate (over 100%) --> [ Maker ]

[ Fee pool A ] --> pays rebate --> [ Referrer ]

Testing

./chain_test -t fee_tests/asset_claim_fees_test

Motivation

The cryptomarket is full of risk taker which really blurs the line between traders/gamblers. Even for derivatives, the CEO of Bitmex has repeatedly say that it caters to gamblers and retail traders. We dived into the gambling scene to discover tons of gambling talks to bitcointalk. It ranges from dice, sports, to full on casino. We find that the dice game is simple, addictive, and target the right demographic for our traders. The dice is discrete game that the user can control their own risk vs reward. So if the user chooses a dice (from 1-100) for a number under 5, then his chance of winning is 1 / 0.05 = 20. The house take say 1% of that. In this proposal, we propose a "roll_dice" operation on the blockchain.

Scope

This would be created as standalone blockchain operation without any coin.

Design

We're going to design a roll_dice with the following parameters.

roll_dice <user> <coin> <risk> <bet>

Parameters:
user: The user rolling
coin: The coin user is taking
risk: The amount of coin the user is risking
bet: a string that an OR of traditional | numbers | odd_or_even
traditional - can be less than or greater than "<5" or ">95"
numbers - can be a series of numbers, say "5,8,9,10"
odd_even - can be "odd" or "even"

Only one type of bet can be placed. The reward is calculated for each case.

Calculate fees

System

The fees are calculated then sent to a special pool (TBD) and the loss are also sent to a special pool (TBD). Winnings are taken out from the loss pool.

Randomness function / fairness

We want to produce an unpredictable randomness that is tamper proof even for block producer. Leveraging from (1), we can provide a randomness function

n = sha3(prev, seed=current_bet)

References

1. https://cryptogambling.org/whitepapers/provably-fair-algorithms.pdf
2. https://bitcointalk.org/index.php?board=56.0
3. primedice.com
4. https://github.com/yahoo/coname/blob/master/vrf/vrf.go
5. https://gist.github.com/alexvandesande/259b4ffb581493ec0a1c

I followed the directions for switching to mainnet at gitbook (and additionally commented out the trusted-node), but the Chain ID remains that of the testnet.

Dear Quanta community, I want to propose my services as a Quanta Block Producer

Please vote for : galaxyfoundationbp