Creating MSC/BTC options via DEx fees to the seller

[dexX7]

Sorry for the sort of redundancy with #166 and similar suggestions which touch the way DEx fees are handled. It was proposed to send the DEx fee to the foundation or charities and also to send the fee to the seller and credit the buyer a partial amount proportional to the amount sent as fee, but this is yet another mechanism.

The idea here is to allow to send the fee directly to the seller, but without granting any partial amount. If this would be possible, Mastercoin options could be sold!

Assuming the current price of MSC is 0.16 BTC. User A wants to sell 200 MSC call options at a premium of 0.02 BTC and an exercise price of 0.18 BTC with an expiration timeframe of two weeks.

User B has a very good feeling about MSC, but only 4 BTC which would allow him to buy 25 MSC at the current price level. But B wants to leverage and he could do so by purchasing user A's options. Instead of buying 25 MSC right now, he buys the right to buy 200 MSC at any time within the next two weeks. Since he expects the price to rise significantly and way above 0.2 BTC/MSC, such a trade would be in his favor.

---

How could this be done?

User A creates a 20: Sell Mastercoins for Bitcoins transaction with the following parameters:

200 MSC for sale at a total of 36 BTC (0.18 BTC/MSC) with a payment timeframe of 2016 blocks (about two weeks) and a minimum fee to the seller of 4 BTC* (0.02 BTC/MSC).

User B accepts the offer via 22: Purchase Mastercoins with Bitcoins and attaches an output of 4 BTC to the seller. The deal is now sealed and once he likes to call his options, he pays the outstanding amount. If it doesn't work out as intended, he lets the offer expire.

*Buying only 100 MSC options would technically also require a payment of 4 BTC fees, but I feel like this is another topic.

[Bitoy]

By sending the fee to the seller, Mastercoin (or any msc derived coins) Options is now available. (Great call Dexx ;)

[dacoinminster]

This only works for MSC, since other coins don't have this style of 2-stage
commit. Also, I think sending the fee to the seller could introduce some
perverse incentives for sellers to set the fees too high and thereby lower
trading volume.

I'd prefer to just add options as an explicit feature :)

On Mon, Jun 2, 2014 at 6:18 PM, Bitoy notifications@github.com wrote:

By sending the fee to the seller, Mastercoin (or any msc derived coins)
Options is now available. (Great call Dexx ;)

—
Reply to this email directly or view it on GitHub
#184 (comment).

[dexX7]

Oh looky:

https://bitcointalk.org/index.php?topic=395761.msg7208526#msg7208526

[Bitoy]

I don't understand how Xcp options work. @dexX7 msc option is easier to understand (maybe I'm biased :) I hope it gets implemented as tx 20 v1.

@dacoinminster if the objective of the seller is to sell ASAP his msc for btc only, he will set the seller fee and time limit to a low value. If his objective is use it for option. The fee and time limit will be a high value.

Sending the fee to the seller is like hitting 2 birds with 1 stone. Dex will still work as is with an option to become an option :)

[dexX7]

I posted the XCP link, because the user proposed "a simple way to offer options by sending the fee to the seller". ;)

I think three mechanisms are possible:

1. Fee is sent to miners, the buyer receives nothing and simply accepts a sale. This is the secure and unexploitable way as we do right now.
2. Fee is sent to the seller and the buyer receives the partial or full amount of tokens proportional to the amount he paid. Let's call this "buy instant".
3. Fee is sent to the seller, but the buyer does not receive any tokens for his partial payment, timeframe is very long. This is the "options" route. He pays the fee/premium for the right to buy the tokens at some point later.

It's very important that the choice between 1. and 2. is made by the buyer. Otherwise sellers could try to exploit users by using very low prices to collect fees of multiple buyers. But because the seller doesn't know what a buyer might do, it's fine. And it's also reasonable in some situations (of lower volume) to do an instant buy, especially if the seller has a huge stack and the buyer wants only a few MSC.

But it's also very important that there is a destinction between those two and 3. due to the very different nature of this type of order.

As hinted in the first post, it may make sense, if the buyer pays a partial amount of fees, if he doesn't intend to buy the full amount which is listed for sale.

Edit: It would also be nice to have something similar for token to token trades.

[dacoinminster]

Letting the fee go to the seller might also create more usage of the dEX as
a side effect. We'd have to give up our dream of collecting these fees for
the Mastercoin Foundation though.

On Tue, Jun 10, 2014 at 7:50 AM, dexX7 notifications@github.com wrote:

I posted the XCP link, because the user proposed "a simple way to offer
options by sending the fee to the seller". ;)

I think three mechanisms are possible:

• 1. Fee is sent to miners, the buyer receives nothing and simply
     accepts a sell. This is the secure and unexploitable way we do it now.
• 1. Fee is sent to the seller and the buyer receives the partial or
     full amount of tokens Let's call this "buy instant".
• 1. Fee is sent to the seller, but the buyer does not receive any
     tokens for his partial payment, timeframe is very long. This is the
     "options" route. He pays the fee/premium for the right to buy the tokens at
     some point later.

It's very important that the choice between 1. and 2. is made by the
buyer. Otherwise sellers could try to exploit users by using very low
prices to collect fees of multiple buyers. But because the seller doesn't
know what a buyer might do, it's fine. And it's also reasonable in some
situations (of lower volume) to do an instant buy, especially if the seller
has a huge stack and the buyer wants only a few MSC.

But it's also very important that there is a destinction between those two
and 3. due to the very different nature of this type of order.

As hinted in the first post, it may make sense, if the buyer pays a
partial amount of fees, if he doesn't intend to buy the full amount which
is listed for sale.

—
Reply to this email directly or view it on GitHub
#184 (comment).

[dexX7]

Well it depends. Looking back at one post earlier I outlined three different routes which would offer the highest amount of possible use-cases whereby the seperation of those seems necessary, might be wrong though. - But we don't want to send all the fees to the seller in all cases, because this may result in the situation where sellers try to exploit users by selling dirt cheap, but only to collect fees and so on.

I absolutely don't see why this conflicts with "fees to the foundation". This would be in the same category as "fees to the miners". And I'd allow to let the user choose, whereby "official" clients of course have a preference. ;)

[dacoinminster]

For options to work though, the person publishing an option for sale has to
require the fee to go to them - the user can't be allowed to choose the fee
to go someplace else, otherwise it's not an option anymore. If the issuer
can tick a box that says "fee goes to me", everybody will tick that box.

Maybe "fee goes to me" is only available for really long timeframes?

On Fri, Jun 13, 2014 at 1:13 PM, dexX7 notifications@github.com wrote:

Well it depends. Looking back at one post earlier I outlined three
different routes which would offer the highest amount of possible use-cases
whereby the seperation of those seems necessary, might be wrong though. -
But we don't want to send all the fees to the seller in all cases, because
this may result in the situation where sellers try to exploit users by
selling dirt cheap, but only to collect fees and so on.

I absolutely don't see why this conflicts with "fees to the foundation".
This would be in the same category as "fees to the miners". And I'd allow
to let the user choose, whereby "official" clients of course have a
preference. ;)

—
Reply to this email directly or view it on GitHub
#184 (comment).

[dexX7]

Ahh, now I see what you were referring to. There is another difference between options and direct DEx trades: in the case of options the fee goes to the sender, but should not credit the buyer with a partial amount of tokens. This is rather a soft-requirement and option-like transactions would still be possible, but usually the buyer would pay a premium for the right to buy MSC at some point later without receiving a partial amount right at the start. Drawing a clean line here seems reasonable to avoid what you outlined.

To bring it all together:

• Case A: the seller initiates a sell via "tx 20: sell mastercoins for bitcoins" and defines a fee. All payments to the seller are credited to the user (partial or full). A buyer has the choice to explicitly commit to the trade by using "tx 22: purchase mastercoins with bitcoins" which reserves the amount of MSC desired, if available. Or, if he prefers, he simply goes ahead and sends the full payment with the risk of overpaying in times of high trading volume. The fee requirement is in place nevertheless, but the amount counted as fee can either be derived from a send to the seller, to the foundation or miners. The buyer has the full choice and the seller does not know which route the user goes, thus it's not exploitable.
• Case B: the seller explicitly requires that the fee is send to the seller - but no partial payment is credited. There is no inceive to do so, unless the seller wants to create options.

It might be the best to seperate DEx trades and options due to the different nature. I also noticed currently one byte is used to define the payment timeframe, so at most 255 blocks in the future can be chosen. That's less than two days and therefore not really useful for options.

How this could be done:

1. Update the logic such that the fee required by tx 20 (sell ...) is calculated based on the amount send to the miners, the foundation and the seller.
2. Update the logic such that all incoming BTC payments to the seller grant a partial or full amount of MSC to the buyer in proportion to the amount sent, even without reservation (tx 22). A reservation via tx 22 nervertheless does what it's intended to: it reserves some MSC for the buyer.
3. Introduce a new transaction type which is used to sell options. It's almost the same as tx 20, but with the difference that no partial payments are granted and a reservation via tx 22 is required. The fee now is rather the option's premium and only counted, if it's sent to the seller (and not to the miners, foundation). The payment timeframe field has no longer a size of only one byte, but should allow to define (much) longer timeframes.

There are two things for consideration:

• The fee requirement might be adaptive in proportion the amount reserved and the seller defines the fee for the whole amount up for sale instead of "per buy". Say a seller wants to sell 2000 MSC (direct or as option) and wants to make sure the proof-of-commitment is at least 0.0005 BTC for each MSC. He would use a (total) fee of 1 BTC in this case. This would solve the issue where a) it's only possible to buy the whole amount of available options and b) might be considered as more fair by users who want to buy smaller amounts of MSC. This becomes more and more an issue, the lower the Bitcoin transaction fees become. If the user wants to purchase only 0.1 MSC for some first experiments, it would be a shame, if he'd still need to pay the full 0.0005 BTC fee. Bitcoin Core v0.9.2~ (current master, not sure if earlier) already uses adoptive fees and the client suggests to use only 0.0000226 BTC for a standard send (more than 4x cheaper (!)). My test transactions with those dirt cheap fees took a bit longer to confirm, but were accepted by the network and were mined in (I think) 1-2 hours.
• For options: it's probably useful, if the payment timeframe is not defined as "number of blocks in the future, starting with the accept transaction", but as fixed point in time (or block height), e.g. "the option expires on the first friday next month".

Additional note: put-options are very likely also possible, given the adoptions of options in general and another feature that's currently planed (to my knowledge).

[dacoinminster]

Once we've reached this level of complexity, why not just do options as
it's own feature? Not sure we gain much by overloading dEX when it gets
this complex.

Also, I expect many people will do trades a lot like options using the
betting feature (an option is, at the root, a tiny bet that an unlikely
outcome will happen, or on the other side, a huge bet that an unlikely
outcome won't happen).

Incidentally, this is a bit off topic, but I've seen evidence posted (by
people who analyze such things) that over time being the "other side"
(essentially writing insurance policies against unlikely things happening)
is HUGELY profitable in aggregate. It only works if you have deep pockets
though. There are a lot of big losses on the way. People call it "picking
up nickels in front of a steamroller" :)

This also means that the guys making the little bets to buy insurance for
hedging (or speculating to collect huge profits) are getting screwed (on
average). It blew my mind when somebody showed how skewed the relationship
is. It's probably the single most profitable thing you can do with a big
chunk of money.

On Fri, Jun 13, 2014 at 5:32 PM, dexX7 notifications@github.com wrote:

Ahh, now I see what you were referring to. There is another difference
between options and direct DEx trades: in the case of options the fee goes
to the sender, but should not credit the buyer with a partial amount of
tokens. This is rather a soft-requirement and option-like transactions
would still be possible, but usually the buyer would pay a premium for the
right to buy MSC at some point later without receiving a partial amount
right at the start. Drawing a clean line here seems reasonable to avoid
what you outlined.

To bring it all together:

Case A: the seller initiates a sell via "tx 20: sell mastercoins for
bitcoins" and defines a fee. All payments to the seller are credited to the
user (partial or full). A buyer has the choice to explicitly commit to the
trade by using "tx 22: purchase mastercoins with bitcoins" which reserves
the amount of MSC desired, if available. Or, if he prefers, he simply goes
ahead and sends the full payment with the risk of overpaying in times of
high trading volume. The fee requirement is in place nevertheless, but the
amount counted as fee can either be derived from a send to the seller, to
the foundation or miners. The buyer has the full choice and the seller does
not know which route the user goes, thus it's not exploitable.
-

Case B: the seller explicitly requires that the fee is send to the
seller - but no partial payment is credited. There is no inceive to do so,
unless the seller wants to create options.

It might be the best to seperate DEx trades and options due to the
different nature. I also noticed currently one byte is used to define the
payment timeframe, so at most 255 blocks in the future can be chosen.
That's less than two days and therefore not really useful for options.

How this could be done:

Update the logic such that the fee required by tx 20 (sell ...) is
calculated based on the amount send to the miners, the foundation and the
seller.
2.

Update the logic such that all incoming BTC payments to the seller
grant a partial or full amount of MSC to the buyer in proportion to the
amount sent, even without reservation (tx 22). A reservation via tx 22
nervertheless does what it's intended to: it reserves some MSC for the
buyer.
3.

Introduce a new transaction type which is used to sell options. It's
almost the same as tx 20, but with the difference that no partial payments
are granted and a reservation via tx 22 is required. The fee now is rather
the option's premium and only counted, if it's sent to the seller (and not
to the miners, foundation). The payment timeframe field has no longer a
size of only one byte, but should allow to define (much) longer timeframes.

There are two things for consideration:

The fee requirement might be adaptive in proportion the amount
reserved and the seller defines the fee for the whole amount up for sale
instead of "per buy". Say a seller wants to sell 2000 MSC (direct or as
option) and wants to make sure the proof-of-commitment is at least 0.0005
BTC for each MSC. He would use a (total) fee of 1 BTC in this case. This
would solve the issue where a) it's only possible to buy the whole amount
of available options and b) might be considered as more fair by users who
want to buy smaller amounts of MSC. This becomes more and more an issue,
the lower the Bitcoin transaction fees become. If the user wants to
purchase only 0.1 MSC for some first experiments, it would be a shame, if
he'd still need to pay the full 0.0005 BTC fee. Bitcoin Core v0.9.2~
(current master, not sure if earlier) already uses adoptive fees and the
client suggests to use only 0.0000226 BTC for a standard send (more than 4x
cheaper (!)). My test transactions with those dirt cheap fees took a
bit longer to confirm, but were accepted by the network and were mined in
(I think) 1-2 hours. http://i.imgur.com/EjRSBPw.png
-

For options: it's probably useful, if the payment timeframe is not
defined as "number of blocks in the future, starting with the accept
transaction", but as fixed point in time (or block height), e.g. "the
option expires on the first friday next month".

Additional note: put-options are very likely also possible, given the
adoptions of options in general and another feature that's currently planed
(to my knowledge).

—
Reply to this email directly or view it on GitHub
#184 (comment).

[dacoinminster]

Sorry, I can't resist posting this:

Is 40% Per Month Shorting Index Puts a Fair Return?
September 10, 2007 • Posted in Equity Options
Selling put options, with limited upside and potentially very large downside, seems very risky. Are actual returns from selling puts commensurate with the risk? In the May 2004 version of his paper entitled “Why are Put Options So Expensive?”, Oleg Bondarenko confirms large returns for shorting puts options on futures for a broad market index and investigates whether these large returns: (1) represent normal risk premiums; (2) are reasonably priced protection against market crashes; or, (3) indicate incorrect investor beliefs about the probability of negative market returns (crashes). Using a flexible testing methodology and daily price data for put options on S&P 500 index futures during 8/87-12/00, he concludes that:

• Selling put options makes a small profit most of the time (when markets are steady or rising), but takes a big loss once in a while (when markets crash).
• Systematically selling one-month-to-expiration, unhedged index puts generates extraordinary profits: 39% (95%) per month for at-the-money (deep out-of-the-money) puts.
• The Jensen’s alpha for selling at-the-money index puts is a highly significant 23% per month. Other widely used methods of risk adjustment also indicate that put prices are very high.
• Buyers of S&P 500 index futures put options transferred $18 billion of wealth to sellers over the studied period.
• For buyers of at-the-money puts to break even, October 1987-like crashes would have to occur 1.3 times per year.
• No reasonable range of parameters supports any of the alternate explanations for the large return for shorting index put options.

Source: http://www.cxoadvisory.com/1415/equity-options/is-40-per-month-shorting-index-puts-a-fair-return/

Sorry to derail the thread. This just blows my mind . . . so . . . much

[dexX7]

Interesting article! The choice of timeframe was clever. "Small profits when markets are steady or rising, big losses when the markets crash" + SP500 chart -- 1987-2000 looks like a huge uptrend (95 % of the time?) except at the end.

Only one note to not get too deep into off topic: we provide tools which can be used with good or bad intentions and the cases where users created DEx sales with a very short block payment timeframe are a good example for this. Nevertheless those tools are no weapons per se and I'm very sure everyone acts in good faith and the protocol (and related) is designed in a way to minimize those situations where users can get screwed.

Once we've reached this level of complexity, why not just do options as it's own feature? Not sure we gain much by overloading dEX when it gets this complex.

Actually yes, this makes sense. I guess all this seems complex, because I listed several things together:

• Fees to the foundation (optional, nice to have)
• Fees to the seller (required for instant buys, options)
• Credit for partial payments (required for instant buys)
• An option to disallow partial payments (nice to have for options)
• Longer payment timeframes (nice to have for options)
• Required fees based on purchased amount (optional, nice to have)

The combination of (some of) those features enable:

• Instant buys on the DEx
• Call-options
• Lower costs for small DEx purchases with similar security (or abuse potential)

Also, I expect many people will do trades a lot like options using the betting feature ...

True, but probably a different story. This touches MSC/BTC directly which seems very important to me, since MSC is the only gateway to and from BTC. And more important: call-options are only one application, the mechanisms on which options are based allow much more. I hesitated to outline other benefits and applications to reduce the amount of information.

[marv-engine]

@m21 This issue doesn't prevent us from merging PR #165 tx21.