Long+Short basket currencies

[markm]

I think I might finally have hit upon a method of implementing longs and shorts without risking bankrupting the exchange:

long+short basket currencies.

For example a long+short basket for bitcoins would consist of a basket of two currencies, one of which is long a bitcoin the other of which is short a bitcoin.

Obviously there has to be a backdrop, a background, a something against which the shortcoin will still total up to a positive value, otherwise no one would buy the shortcoins, they would be liabilities, not assets.

Since it is often perilous to allow fiat to insinuate itself into one's affairs, let us use for our example basket a backdrop/background of litecoin.

Let us suppose we are pretty darn confident that bitcoins will never be worth more than a thousand litecoins. That is a somewhat arbitrary number, we could use ten thousand, or a hundred thousand, or a million. What is important is that our shortcoins have a positive net value no matter how many of our backdrop/background units the currency we are wanting to do longs and shorts in ends up being worth, "within reason". By "within reason" I mean we really seriously do not expect the shorted unit to ever be worth more than the backdrop provided. If that means the backdrop needs to be a million litecoins, fine. If we can get away with only a hundred thousand, better, because the backdrop is basically a deadweight ballast making the trading of longs and shorts more awkward; it is in essence the collateral and it needs to be large enough that no margin calls will be called for.

Each unit of the long+short basket currency consists of a longcoin and a shortcoin, each of which consists of one ballast-size (a thousand? maybe ten thousand? the size we decide is needed to ensure it will never be worth less than a bitcoin) of litecoins plus or minus one bitcoin.

So if we do settle on 1000 as our required backdrop/ballast scale, one long+short basket would consist of one shortcoin worth 1000 litecoins minus a bitcoin, and one longcoin worth 1000 litecoins plus a bitcoin.

The server/exchange can thus issue this basket currency confident that each unit of the basket needs only 2000 litecoins to "back" it. The long a bitcoin and short a bitcoin cancel out.

Baskets can be broken up into their components, so a  person wishing to go long bitcoins buys the basket, retains the longcoin and sells the shortcoin. A person wishing to go short bitcoins buys the basket, retains the shortcoin and sells the longcoin.

Does this make sense to anyone or will it just boggle the minds of the potential customers?

-MarkM-

[1714034773]

1714034773

[1714034773]

1714034773

[1714034773]

1714034773

[1714034773]

1714034773

[Explodicle]

FWIW it makes perfect sense to me, but I've been playing with OT baskets. A little diagram of the baskets as issued, split up, etc would help if anyone gets confused.

[markm]

Well I guess there does not seem to be much interest, I had somehow gotten an impression some folks thought shorting was really important.

I wonder if there would be more interest in shorting something else, like maybe gold, silver, platinum?

-MarkM-

[markm]

Well one good thing about this method is the exchange doing it does not have to be able to handle the type of asset that is being shorted or longed at all, nor does it need to have any way of discovering any prices of them; in effect the prices of them are discovered by the prices the shorts and longs sell for. There is thus no dependence on some external ticker for a price against which to compare or to settle. People simply directly buy and sell the baskets, the shorts, and the longs.

Lets take CAD as an example. The  exchange could make BTCslCAD baskets available at a cost of 2 BTC per basket.

The basket would consist of one BTCsCAD unit worth one bitcoin minus one CAD, and one BTClCAD unit worth one bitcoin plus one CAD.

The plus one CAD and minus one CAD cancel out, so there is no need for any support for actual CAD; the exchange can persist in dealing only with non-fait currencies. These Short+Long baskets and their comprising shortcoins and longcoins are purely bitcoin-based wagering tokens. The server redeems completed baskets, for two bitcoins (plus maybe some slight profit for going to the trouble). The users choose how much, or even whether, to buy or sell the shortcoins or longcoins for. They are simply tokens that by convention represent either shorting CAD or going long CAD.

In effect you are borrowing a CAD worth of bitcoin if you buy a basket and sell the longcoin, retaining the shortcoin. The shortcoin is a bitcoin that is short by one CAD from being a full bitcoin. The longcoin is a bitcoin that is long by a CAD from being merely a single whole bitcoin.

(Whether it is by retaining the shortcoin or by retaining the longcoin that you in effect borrowed is confusing isn't it? By holding the shortcoin, you are basically out by the value of a CAD. So you can think of that as being in debt to that amount. You need the longcoin back to repay that shortage so you can turn in the completed basket for a full two bitcoins.)

-MarkM-

[Explodicle]

1 LG = 1000 LTC + 1 BTC
1 SH = 1000 LTC - 1 BTC

Issuer	Alice	Bob	Description
[1 LG + 1 SH]	2000 LTC	2000 LTC	Issuer creates a long + short basket
2000 LTC	[1 LG + 1 SH]	2000 LTC	Alice buys long + short basket from Issuer for 2000 LTC
2000 LTC	1 SH + 1285 LTC	1 LG + 715 LTC	Alice sells the longcoin to Bob for 1285 LTC
2000 LTC	1985 LTC	1 LG + 1 SH + 15 LTC	Later, Alice sells her shortcoin for 700 LTC. (BTC/LTC has gone up)
[1 LG + 1 SH]	1985 LTC	2015 LTC	Bob redeems the long + short basket from the Issuer.

[markm]

Okay, nice example. But does it lead to thinking yes this does seem a useful/workable idea, or to thinking heck all that for only 15 LTC, not worth the trouble?

-MarkM-

[nimda]

I like it. If I take out a loan denominated in BTC and sell the BTC, I want to be long to hedge against a price increase. Similarly, if I buy bitcoins just to invest them with PatrickHarnett, I want to be short to hedge against a price decrease. The idea is sound, except for the backdrop risk.

[markm]

Part of why I generated the pages at http://galaxies.mygamesonline.org/digitalisassets.html was to be able to eyeball the columns to get some idea of how stable various assets have been. Obviously some kind of calculations on the data would be better but I wanted to get an actual look first so that if I do code some actual calculations intended to tell me how stable they have been which is most stable and such I would have some basis to be able to guess whether the code was actually working or not. (I'd expect it to be telling me ones that look relatively stable to my eye rather than ones that I can see at a glance are highly unstable.)

I have actually been thinking of using Martian BotCoin (MBC) as backdrop/ballast for many simply because it is larger than most, though not as large as a bitcoin, and seems to have been quite a bit more stable than bitcoins.

-MarkM-

[nimda]

After some thinking, I like raw CFD's the best. There is the risk that the opposite party won't pay, but what's the point of having a shortcoin if it cost you 3 BTC?

[markm]

After some thinking, I like raw CFD's the best. There is the risk that the opposite party won't pay, but what's the point of having a shortcoin if it cost you 3 BTC?

Yes, contract for difference, especially leveraged, is doubtless the most appealing approach for sure, and bound to attract gamblers like crazy with its lure of cheap easy massive profit if you bet the right way.

I have two problems though with actually implementing it:

One, it requires a price/value oracle, some source from which to magically "know" what price/value is par compared to which higher or lower is to be determined to see whether those who bet it would be lower win or those who bet it would be higher win.

Two, the oracles I have seen used seem to me crazily volatile, which I expect is most of their appeal but creates a constant threat of changing too far too fast, leaving the service unable to balance its bettors' bets against each other, so that the service takes a loss. Which could be a pretty huge loss. This danger leads to having to charge high fees to even begin to be able to plan on covering against it.

Now possibly if one were allowed to use, say, a 48 hour volume-averaged price, or in some other such way use a price that isn't so likely to be able to skyrocket or drop to nothing in a matter of moments, the risk could be mitigated, but, so would the appeal to the gamblers, so you'd likely lose all your business anyway to some shop that is going to vanish with everyone's money when it finally does get unlucky.

There is though also the problem of who can influence the oracle. Some think that merely by having half a million coins to play with, Pirate could in theory have manipulated prices. So basically by using an oracle you are maybe just turning yourself into a pawn of some manipulator.

(Some have even suggested that bitcoinica helped manipulators by providing a bunch of trigger points where people would get margin calls forcing them out of the manipulator's way or something...)

So although I see how nice and efficient CFD could be if you truly had a reliable, stable way of determining an actual value of an asset instead of letting someone''s ability to starve or flood a specific venue manipulate "price" (potentially quite distinct from actual value), I have so far been forced to think really it is more a gambling thing than a serious investment/hedging thing...

-MarkM-

[nimda]

a serious investment/hedging thing...

Say you take out a 100 BTC loan when BTC is $10 (because nobody else will give you it in USD anyways...) and sell it for 1000 USD, because you can't buy XYZ with BTC. It makes sense to also get a 100 BTC CFD and take the long position:
BTC goes up by $3. You make $300 USD, it costs $1300 to get 100 BTC. You pay $1000.
BTC goes down by $3. you lose $300 USD, but it costs $700 to get 100 BTC. You pay $1000.
Hedge successful!

With baskets, you need more money to buy them. Having a basket is less useful than bridging finance between jobs. If a 1 BTC shortcoin is $30, how can this help you hedge at all?

There's also options; someone taking out a loan in BTC could buy a call option.

[markm]

Yes, I like futures (calls and puts) better than contract for difference. It is more obviously related to what you are doing, too. YOu want a hundred bitcoins in future for similar price you borrowed at, and someone agrees they will sell you them at that price.

It even lacks the gambling aspect more, as you aren't going to end up getting an even better price die to random fluctuations of some oracle.

It seems my main objection really is the oracle. It just seems too manipulable to me in bitcoin's case way too volatile.

Would some kind of smothing be acceptable for an oracle? I expect gamblers will want the most volatile oracle to be used, but for your serious purpose would a smoother one work? It kind of seems like really a call option would be best for your purpose?

-MarkM-

[nimda]

The thing is that a CFD locks in your "repay" price for free, while the call option locks in the maximum repay price at a cost. In this way, the CFD is less gamble-y.

[markm]

A CFD is free? Why does anyone offer them then? What is their business model?

-MarkM-

[nimda]

A CFD is free? Why does anyone off them then? What is their business model?

-MarkM-

CFD's can be done between two people with no middleman, and it's been done more than once on these forums.

[nimda]

It seems my main objection really is the oracle. It just seems to manipulable to me in bitcoin's case way too volatile.

Would some kind of smothing be acceptable for an oracle? I expect gamblers will want the most volatile oracle to be used, but for your serious purpose would a smoother one work? It kind of seems like really a call option would be best for your purpose?

I was thinking back to this thread the other day, and I came up with the solution for the oracle problem. When one party wants to exercise the CFD (or when the CFD expires), both parties try to agree on the price. If they can't, the parties must accept trades up to the value of the CFD for their quoted price (adjusted by some reasonable fraction for fees).

Consider this scenario:
1. Bob and Alice create a CFD for 1 Bitcoin, beginning at $5. Bob takes the short, Alice takes the long.
2. BTC-e trades at $6; MtGox trades at $7.
3. Alice wants to use the MtGox price (obviously). Bob doesn't have access to MtGox.
4. Bob buys 1 Bitcoin at $6 from BTC-e, and sells it for $7 (minus some reasonable percentage agreed upon in step 1) to Alice.
5. Alice accepts payment of $2 and sells Bob's coin at MtGox.

Because Bob profited $1 (minus some reasonable fee) from his arbitrage sale, his payment of $2 is really only a loss of $1. From his net loss, it's like the contract was concluded using BTC-e as the oracle.

Because Alice sold Bob's coin, her profit is still $2. From her net profit, it's like the contract was concluded using MtGox as the oracle.

[markm]

Oh that is very nice, yes, thank you for that.

But it is already a step toward letting the players discover prices themselves aka a step away from "the oracle". In fact there is not really "an" oracle anymore, and no reason to think there are only two places where alice and/or bob could discover yet more prices.

Thus, I still think the properly elegant solution I am looking for would be one in which no one other than maybe alice needs concern themselves about what alice uses as an oracle or even whether she uses one at all (aka uses her ass as in pulls numbers out of her ass) and same for bob; thus no oracles other than the players themselves in their oracular capacities (however limited those capacities might be).

Thus I still have not really come up with anything better yet than the thread-titular baskets, though I have been reading upon how MPEx works (and finding out their secret sauce seems to be secret).

I am wondering whether these baskets might become more palatable to people when used/viewed in conjunction with a capital-building "line of collateral-building credit" I have also been thinking about. Basically that idea involves a broker who holds (escrow basically; a margin account kind of thing) a collateral account against which you can borrow up to lets say about 50% of its assessed value. Since this type of margin account already forces you to have 50% of your collateral tied up, maybe the way that these baskets also tie up some funds will not seem so bad, or maybe even the two ideas (the collateral account you can borrow against to buy more collateral that you can borrow against to buy more collateral etc etc etc and the long+short basket currencies idea) can be brought closer together, maybe even somehow to some extent actually integrated...

-MarkM-

[nimda]

Oh that is very nice, yes, thank you for that.

But it is already a step toward letting the players discover prices themselves aka a step away from "the oracle". In fact there is not really "an" oracle anymore, and no reason to think there are only two places where alice and/or bob could discover yet more prices.

Thus, I still think the properly elegant solution I am looking for would be one in which no one other than maybe alice needs concern themselves about what alice uses as an orancle or even wjether she uses one at all (aka uses her ass as in pulls numbers out of her ass) and same for bob; thus no oracles other than the players themselves in their oracular capacities (however limited those capacities might be).

I still believe my solution works. Bob and Alice do not need to agree on the price at all; they must simply accept trades for the value of the CFD at that price. Consider the scenario in which Alice tries to scam Bob:

1. Bob and Alice create a CFD for 1 Bitcoin, beginning at $5. Bob takes the short, Alice takes the long.
2. BTC-e trades at $6; MtGox trades at $7. (Bob only has access to BTC-e)
3. Alice claims that tradeb1tco1ns.tk is trading at $10.
4. In order to exercise the CFD at $10, Alice must accept 1 BTC from Bob for $10. Bob then sends her $5 (the difference).
5. Do the math. Bob buys the 1 BTC for $6 and sells it for $10, but must send Alice the $5 difference. 10-6-5 = -1. He loses $1, which is the difference between $5 and $6.
Alice sends Bob $10 and receives 1 BTC (the sale) and $5 (the difference). She sells the 1 BTC at MtGox for $7. 5+7-10=2. She gains $2, which is the difference between $5 and $7.

The actual transactions (some of it cancels) are:
Bob  -> Alice 1 BTC
Alice -> Bob $5

Tee-hee! It all cancels! This method of a no-oracle CFD is simply a futures contract at spot price! A 1 BTC CFD starting at $5 is really just a 1 BTC future/forward.

Thus I still have not really come up with anything better yet than the thread-titular baskets, though I have been reading upon how MPEx works (and finding out their secret sauce seems to be secret).

I think MPEX options are just oracle-based options in which no USD is transacted. If you buy a 1 BTC call, and BTC rises $1.2, you get 1.2 USD * (BTC/USD).


[/quote]

[markm]

Hmm, okay, so the long person has to accept a coin at their choice of long price to exercies the contract.

Presumably meanwhile the short person has to provide a coin at their coince of short price in order to exercise the contract?

So if Bob, who took the short side, claims his oracle's price is $1, while Alice, who took long, claims her oracle's price is $10... What then?

If Bob is correct that short is the way it went, he has to send Alice a bitcoin for $1.

If Alice is correct that long is the way it went, she has to pay Bob $10 for a bitcoin.

So what is the net effect? Are they both right, so Bob sends a bitcoin and Alice sends him $9 change?

Or are they both right, so Bob sends one bitcoin for $1 and a second bitcoin for $10 and receives $11 from Alice for the pair of them?

Oh wait, the $5 comes into it somewhere too presumably...

EDIT: By the way, for my purposes fees to the platform/exchange are irrelevant, so only worry about whether Bob or Alice require a fee one from the other. Both are paying per API call for each and every thing they have the platform do for them, including telling them about each other's offers.

-MarkM-

[nimda]

Hmm, okay, so the long person has to accept a coin at their choice of long price to exercies the contract.

Presumably meanwhile the short person has to provide a coin at their coince of short price in order to exercise the contract?

So if Bob, who took the short side, claims his oracle's price is $1, while Alice, who took long, claims her oracle's price is $10... What then?

If Bob is correct that short is the way it went, he has to send Alice a bitcoin for $1.

If Alice is correct that long is the way it went, she has to pay Bob $10 for a bitcoin.

So what is the net effect? Are they both right, so Bob sends a bitcoin and Alice sends him $9 change?

Or are they both right, so Bob sends one bitcoin for $1 and a second bitcoin for $10 and receives $11 from Alice for the pair of them?

Oh wait, the $5 comes into it somewhere too presumably...

That won't work. If it's a no-oracle CFD (aka futures contract ), then they have to agree on the exercise price. Who is on which end of the trade would be specified in the contract. Possibilities include...
- CFD can be exercised at will; exerciser is forced to make the trade (forced to buy if they are long or sell if they are short)
- CFD is exercised at set date; the long person (or the short person, as specified in contract) is forced to make the trade

In both possibilities, the person forced to make the trade names the price.

EDIT: By the way, for my purposes fees to the platform/exchange are irrelevant, so only worry about whether Bob or Alice require a fee one from the other. Both are paying per API call for each and every thing they have the platform do for them, including telling them about each other's offers.

I think the most elegant way is to not specify any fees in the contract. If I can buy bitcoins for $1 each at an exchange which charges 1200% commission, is that really worth concluding a short CFD over?