Bitoy
commented
10 years ago By sending the fee to the seller, Mastercoin (or any msc derived coins) Options is now available. (Great call Dexx ;)
Open dexX7 opened 10 years ago
Bitoy
commented
10 years ago By sending the fee to the seller, Mastercoin (or any msc derived coins) Options is now available. (Great call Dexx ;)
dacoinminster
commented
10 years ago 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 https://github.com/mastercoin-MSC/spec/issues/184#issuecomment-44910198.
dexX7
commented
10 years ago Bitoy
commented
10 years ago 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
commented
10 years ago 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:
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
commented
10 years ago 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:
-
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.
Fee is sent to the seller and the buyer receives the partial or full amount of tokens Let's call this "buy instant".
- 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 https://github.com/mastercoin-MSC/spec/issues/184#issuecomment-45623573.
dexX7
commented
10 years ago 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
commented
10 years ago 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 https://github.com/mastercoin-MSC/spec/issues/184#issuecomment-46055057.
dexX7
commented
10 years ago 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:
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:
There are two things for consideration:
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
commented
10 years ago 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:
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. 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 https://github.com/mastercoin-MSC/spec/issues/184#issuecomment-46073303.
dacoinminster
commented
10 years ago 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:
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
commented
10 years ago 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:
The combination of (some of) those features enable:
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
commented
10 years ago @m21 This issue doesn't prevent us from merging PR #165 tx21.
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.