Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Futures - Trade Contract Atomic Tx #378

Closed
patrickdugan opened this Issue May 24, 2016 · 4 comments

Comments

Projects
None yet
4 participants
@patrickdugan
Copy link

patrickdugan commented May 24, 2016

The trade contract tx type differs from the Dex transaction types in three key respects:

  1. the transaction involves only changing the balance of a single smart property type (the contract in question) and is thus simpler so the 4 trade types aren't required.

  2. instead of pushing reserved balances between addresses when orders match, the collateral property that backs the contract is pushed into reserve status or taken out of reserve status when the absolute value of the contract balance goes up or down.

  3. Reserve balances are only pushed at settlement time, not when trades clear. Instead reserve balances that are lost due to negative contract trade price differentials (i.e buying high and then selling low) are removed from the total balance calculation used to show to users their available totals, and only removed from the address when the contract expires and the differences are pushed out to the addresses of those with a net win.

When a Trade Contract tx is formed for broadcast, in order be valid the number of contracts traded times the collateral requirement for the reserve smart property must be greater than the available balance of reserve asset (#contract * collateral per contract >= balance of collateral) e.g the OMNI/USDT contract requires 5 OMNI per contract, the trade is for 10 contracts, but the OMNI balance is 40 contracts, the trade is invalid.

If a transaction is accepted, all the units required to margin the order are held in reserve.

If a transaction matches to another trade, then the trade executes, the balance of the contract is raised or reduced by 1 for a buy/sell, with the supply of contracts changing depending on the situation. There are 3 possible trades:

  1. Both parties are opening contracts, new contracts come into existence and at settlement the reserve balances of the losing side will push to the address of the winning side.

  2. Both parties are closing contracts, the number of existing contracts reduces and as above the reserve balance of the losing side will push to the address of the winning side at settlement.

  3. One party is reducing the absolute value of their contract balance while another increases theirs. This would be effectively like someone trading off existing supply of contracts to someone else. However the atomic transaction is still considered unique so that at settlement the net transfers are calculated.

Each trade encodes the trade price into its transaction meta-data for reference during settlement. Optionally, we can create an id number that has a unix-style timestamp included to index all trades in a chronology.

When someone reduces the absolute value of their contract balance, the trade price for the contract(s) used to do that is immediately taken and subtracted from the trade price of the contracts that opened those trades. The contracts with the prices that are closest to the market are taken into consideration first when calculating. The difference, is resulting in a loss, locks up collateral until expiration and removes it from both reserve and available balances for UI purposes.

@marvgmail

This comment has been minimized.

Copy link

marvgmail commented May 31, 2016

@patrickdugan this looks pretty complex, with (implied) side effects. Can you dumb it down for those of us who aren't experts in the domain, but are able to follow - and code - logic flows? Simple, concise examples always help me. I think we also need a glossary so there's no misinterpretation of the terms you're using. Thanks.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jun 1, 2016

I've suggested some flow charts showing what actions would be taken in what circumstances could help us to start translating this into something workable spec-wise.

Alternatively/additionally psuedo-code might work.

Once we can get that 'clear picture' I think we'll be able to start hammering out the technicalities.

@dexX7 dexX7 added the CFDs label Jul 30, 2016

dexX7 pushed a commit that referenced this issue Jan 23, 2017

Squashed 'src/secp256k1/' changes from 6c527ec..8225239
8225239 Merge #433: Make the libcrypto detection fail the newer API.
12de863 Make the libcrypto detection fail the newer API.
2928420 Merge #427: Remove Schnorr from travis as well
8eecc4a Remove Schnorr from travis as well
a8abae7 Merge #310: Add exhaustive test for group functions on a low-order subgroup
b4ceedf Add exhaustive test for verification
83836a9 Add exhaustive tests for group arithmetic, signing, and ecmult on a small group
20b8877 Add exhaustive test for group functions on a low-order subgroup
80773a6 Merge #425: Remove Schnorr experiment
e06e878 Remove Schnorr experiment
04c8ef3 Merge #407: Modify parameter order of internal functions to match API parameter order
6e06696 Merge #411: Remove guarantees about memcmp-ability
40c8d7e Merge #421: Update scalar_4x64_impl.h
a922365 Merge #422: Restructure nonce clearing
3769783 Restructure nonce clearing
0f9e69d Restructure nonce clearing
9d67afa Update scalar_4x64_impl.h
7d15cd7 Merge #413: fix auto-enabled static precompuatation
00c5d2e fix auto-enabled static precompuatation
91219a1 Remove guarantees about memcmp-ability
7a49cac Merge #410: Add string.h include to ecmult_impl
0bbd5d4 Add string.h include to ecmult_impl
353c1bf Fix secp256k1_ge_set_table_gej_var parameter order
541b783 Fix secp256k1_ge_set_all_gej_var parameter order
7d893f4 Fix secp256k1_fe_inv_all_var parameter order
c5b32e1 Merge #405: Make secp256k1_fe_sqrt constant time
926836a Make secp256k1_fe_sqrt constant time
e2a8e92 Merge #404: Replace 3M + 4S doubling formula with 2M + 5S one
8ec49d8 Add note about 2M + 5S doubling formula
5a91bd7 Merge #400: A couple minor cleanups
ac01378 build: add -DSECP256K1_BUILD to benchmark_internal build flags
a6c6f99 Remove a bunch of unused stdlib #includes
65285a6 Merge #403: configure: add flag to disable OpenSSL tests
a9b2a5d configure: add flag to disable OpenSSL tests
b340123 Merge #402: Add support for testing quadratic residues
e6e9805 Add function for testing quadratic residue field/group elements.
efd953a Add Jacobi symbol test via GMP
fa36a0d Merge #401: ecmult_const: unify endomorphism and non-endomorphism skew cases
c6191fd ecmult_const: unify endomorphism and non-endomorphism skew cases
0b3e618 Merge #378: .gitignore build-aux cleanup
6042217 Merge #384: JNI: align shared files copyright/comments to bitcoinj's
24ad20f Merge #399: build: verify that the native compiler works for static precomp
b3be852 Merge #398: Test whether ECDH and Schnorr are enabled for JNI
aa0b1fd build: verify that the native compiler works for static precomp
eee808d Test whether ECDH and Schnorr are enabled for JNI
7b0fb18 Merge #366: ARM assembly implementation of field_10x26 inner (rebase of #173)
001f176 ARM assembly implementation of field_10x26 inner
0172be9 Merge #397: Small fixes for sha256
3f8b78e Fix undefs in hash_impl.h
2ab4695 Fix state size in sha256 struct
6875b01 Merge #386: Add some missing `VERIFY_CHECK(ctx != NULL)`
2c52b5d Merge #389: Cast pointers through uintptr_t under JNI
43097a4 Merge #390: Update bitcoin-core GitHub links
31c9c12 Merge #391: JNI: Only call ecdsa_verify if its inputs parsed correctly
1cb2302 Merge #392: Add testcase which hits additional branch in secp256k1_scalar_sqr
d2ee340 Merge #388: bench_ecdh: fix call to secp256k1_context_create
093a497 Add testcase which hits additional branch in secp256k1_scalar_sqr
a40c701 JNI: Only call ecdsa_verify if its inputs parsed correctly
faa2a11 Update bitcoin-core GitHub links
47b9e78 Cast pointers through uintptr_t under JNI
f36f9c6 bench_ecdh: fix call to secp256k1_context_create
bcc4881 Add some missing `VERIFY_CHECK(ctx != NULL)` for functions that use `ARG_CHECK`
6ceea2c align shared files copyright/comments to bitcoinj's
70141a8 Update .gitignore
7b549b1 Merge #373: build: fix x86_64 asm detection for some compilers
bc7c93c Merge #374: Add note about y=0 being possible on one of the sextic twists
e457018 Merge #364: JNI rebased
86e2d07 JNI library: cleanup, removed unimplemented code
3093576 JNI library
bd2895f Merge pull request #371
e72e93a Add note about y=0 being possible on one of the sextic twists
3f8fdfb build: fix x86_64 asm detection for some compilers
e5a9047 [Trivial] Remove double semicolons
c18b869 Merge pull request #360
3026daa Merge pull request #302
03d4611 Add sage verification script for the group laws
a965937 Merge pull request #361
83221ec Add experimental features to configure
5d4c5a3 Prevent damage_array in the signature test from going out of bounds.
419bf7f Merge pull request #356
03d84a4 Benchmark against OpenSSL verification

git-subtree-dir: src/secp256k1
git-subtree-split: 8225239
@patrickdugan

This comment has been minimized.

Copy link
Author

patrickdugan commented Jul 15, 2017

  1. Reserve balances are only pushed at settlement time, not when trades clear. Instead reserve balances that are lost due to negative contract trade price differentials (i.e buying high and then selling low) are removed from the total balance calculation used to show to users their available totals, and only removed from the address when the contract expires and the differences are pushed out to the addresses of those with a net win

I want to update this earlier notion - a cache of funds that have been lost to closed-out negative trades should be kept in its own pocked dimension like the OmniDex fee cache. Funds would then be deducted from the cache to credit winning trades as they are closed out, on a first-come-first-serve queue basis.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Mar 19, 2018

I think it's better to keep track of the specification or feature proposals in the spec repository:

https://github.com/OmniLayer/spec

Please feel free to open a new issue over there.

@dexX7 dexX7 closed this Mar 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.