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 - Publish Contract Atomic Tx #374

Closed
patrickdugan opened this Issue May 11, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@patrickdugan
Copy link

patrickdugan commented May 11, 2016

A variant on the Managed Smart Property creation, this transaction creates two new smart properties that are to be part of a series, and carry a special categorization as being Futures Contracts

Parameters:

Blocks between Expiration - from the block the new contract series if published, the first contract will expire N blocks later, and the second contract will expire 2N blocks later. At Block N, a new contract comes into existence which expires 3N blocks after this transaction was published, and so on ad infinitum.

Note the smart property IDs for a contract series needs to follow a numeration where 1000s of contracts can come in and out of existence over time without collisions. So futures contract series should occupy a large header number, such as 410000, so that if a contract expires every day, after ten years all the contracts in that series still occupy 41xxxx numeration.

There should be a minimum time between contract expirations, perhaps 50 blocks (~6hr contract) or perhaps 150 (~24hrs).

Collateral Currency - a smart property ID # for the smart property used to both back and settle the contracts. Eg. #1 for OMNI backed contracts that pay some amount of OMNI to winners.

Collateral amount - the # of units of a reserve currency locked up per absolute value number of contracts held long or short. Eg. 10 OMNI per contract means if you have -10 contracts or 10, then your address must have had 100 OMNI to enter the positions. The amount is reserved until settlement for any amounts that are net profits or loss. The amounts can be freed up by reducing the absolute value of one's contract positions, less any losses, which remain reserved until settlement.

Quote Currency - a smart property ID # used to calculate settlement value. Eg. Tether; if the collateral currency were OMNI and the quote currency were Tether on a OMNI/USDT contract, then the OMNI value of a contract would become larger as the price declined, with the USDT value fixed, providing a perfect hedge. Or conversely, imagine an OMNI/BTC contract that is collateralized and quoted in OMNI, it would be a quanto contract that provides convex gains and losses to those who are long/short is respectively, because the losses for the short-side would be fixed in OMNI as the value of OMNI rises. Hence 10% rise means 11% loss.

Notional Value - the value of each contract in the quote currency. Eg. 1 contract is worth 10 OMNI or 1 contract is worth $100 worth of OMNI.

Settlement Reference - either an array containing two smart property IDs or a bitcoin address where a data feed is regularly published by some party. The prior option has settlement logic that looks for the Merkle branches of the two properties, tallies all the spot Dex trades between them in the preceeding N blocks, and uses the ratios to devise a price. The latter option has nodes looking at the Op_return data of transactions broadcast from the data feed address, with some contingency logic for a non-timely publication of a settlement price, that looks at preceeding prices and averages them, and includes a grace period of 2-5 blocks before doing so in case the publisher is a bit late on the update. Perhaps that grace period and the number of preceeding data feed points to average could be parameters in this transaction, perhaps we simply go with 6 and 6 as hardcoded. The benefit of that latter approach is, traders can see if a feed is not being kept up consistently or has been overtly manipulated and know what they are getting into (we can have such statistics included in UI designs for Omniwallet/OmniJ), and it balances with the publisher's profit motive and professional reputation to provide an imperfect but recoverable dynamic.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented May 26, 2016

Hey Patrick,

I was chatting to @CraigSellars about these features and I definitely agree the first step is to get a workable spec. Paging @marv-engine whom I believe is going to help you with this.

From what I can gather so far there is quite some complexity to what's being requested, so it's going to be a fairly lengthy development effort I think as all of it requires extra ways of storing and processing data etc in the reference client (it's not a simple A+B consensus rule change) - though we can estimate time required better once we have a workable spec (again @marv-engine is your man here and the sooner we get to a workable spec the sooner we can start prototyping :) ).

Thanks for all you're doing & for the ideas
Z

@marvgmail

This comment has been minimized.

Copy link

marvgmail commented May 26, 2016

@patrickdugan I need some help understanding this. Assume that I know virtually nothing about what business transaction you're trying to specify. Can you describe the transaction(s) in layman's terms and/or point me toward an existing description?

When writing a spec, I prefer to start with objective and quantifiable functional requirements. If nothing else, that provides a framework for testing. Design and then implementation come only after all the stakeholders understand and agree on the reqs.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented May 26, 2016

Thanks @marv-engine - really appreciate your help on this :)

@patrickdugan

This comment has been minimized.

Copy link
Author

patrickdugan commented May 26, 2016

You bet on changes in price using a fraction of the value of the bet. At a fixed time the bet will pay based on a reference price. So I put up 10 OMNI to take a bet on something that is worth 50 OMNI, and you have the same amount, and when the price changes and I trade off my contract to someone else or wait for expiration, if the price went up and I'm long, I pay you, and if the price went down and you were short, you pay me.

@marvgmail

This comment has been minimized.

Copy link

marvgmail commented Jun 1, 2016

@patrickdugan, @zathras-crypto, @dexX7 - just a thought about one detail (which may be too early in the process):

If I understand how a contract series will work, we can consider using (or extending) the Property Type and Previous Property ID fields to indicate the sequence of SP id's - effectively, generating a linked list. That would eliminate the need(?) to reserve a block of SP id's.

It's TBD if append or replace or something new is the correct Property Type description of the relationship between the new and old contracts' SP id's.

Update - I realized that a new contract in the series would be generated by Omni Layer itself when the previous one expires, not by subsequently submitted transactions, so the it may be that a linked list is the way to go, but not as the result of a submitted tx.

@stebansaa

This comment has been minimized.

Copy link

stebansaa commented Jun 2, 2016

some basics for the newbies like myself following this:
https://www.youtube.com/watch?v=nwR5b6E0Xo4
https://www.youtube.com/watch?v=Yqkq-w4Jl3c

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jun 2, 2016

Thanks @stebansaa!

@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
@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.