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-

[1715398404]

1715398404

[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?

[markm]

Well presumably the price they name must at least be on the correct side of the strike?

So long person must name at least strike, and short person must name at most strike?

Maybe you can run through your example again but this time with it being the case that the prices they can get out in the world are below their strike price not above it?

-MarkM-

[nimda]

Well presumably the price they name must at least be on the correct side of the strike?

So long person must name at least strike, and short person must name at most strike?

Maybe you can run through your example again but this time with it being the case that the prices they can get out in the world are below their strike price not above it?

-MarkM-

If I understand you correctly, you mean something like this (let's just use MtGox now; I think the arbitrage scenario has been established):

1. Bob and Alice create a CFD for 1 Bitcoin, beginning at $5. Bob takes the short, Alice takes the long.
2. Bitcoin drops to $4. Alice wants to cheat Bob; she claims it's at $6
3. Bob says "sure, it's at $6." He pays her $1 (the difference).
4. Since Alice named the price, she must accept the trade. Bob buys 1 BTC for $4 and sells it to her for $6. She sells it back to the exchange for $4.
5. Math. Bob sends MtGox $4, Alice 1 BTC, and Alice $1; he receives $6 and 1 BTC from Alice. This is a profit of $1, which makes sense because he "won" his short.
Alice sends MtGox 1 BTC and Bob $6; she receives 1 BTC from Bob, $1 from Bob, and $4 from MtGox. This is a loss of $1, which makes sense because in truth, the exchange rate fell, so her long position should be losing.

Really, the party can name any price for exercise (even a negative price ) and it will still work out properly.

In the case that there really are two different prices (say 2 different local markets or something), then it's possible for both parties to profit; this profit comes from the arbitrage.

[markm]

Awesome, so the site mediating this has no skin in the game, it can just charge its standard per-API-call usage tokens fee for use of its functionality and not care how much value Bob and Alice are wagering and exchanging.

Unfortunately I don't see how to call this thing an asset and put it on a market in my server though.

Unlike the basket currency concept it does not seem amenable to being a token that people can buy and sell.

-MarkM-

[nimda]

It could be implemented this way:
- Alice advertises a CFD at X price (spot)
- Bob agrees to the contract. He takes the short.
- It is Alice's CFD, so she will be naming the price. This is specified in the contract. (Obviously, this could be the other way around)
- At contractually-specified intervals, (this part can be done by a bot) Alice publishes a price to the server.
- Bob sells 1 BTC to Alice at that price. The "losing" party sends the "winning" party the difference. These two transactions are designed to cancel out, so Alice's published price is always above X.

But what is really happening (cancel out the dollars) is:
- At intervals, Bob sells 1 BTC to Alice for X (spot at time of contract)

And really, the whole appeal of CFD's is that they can be done on margin, and for that, one needs an oracle. Therefore, it's probably best for the sale to be done as a means of dispute resolution; it's better for the parties to agree on the price. Still, even one dispute would require a trade at the full value of the contract... and as that's probably not feasible, we're back to our problems:
- Baskets: "backdrop" problem means that if the price changes too much, coins can be less than worthless yet discarded for 0.
The backdrop also means it's not done on any kind of margin/leverage; in fact it's quite the opposite. The backdrop must be several times the value of the asset being traded, so to make a little profit from your longcoin or shortcoin, you need a lot of money.
- CFD's (traditional): relies on an oracle
- CFD's (with dispute resolution): again takes a lot of money to make a little profit
- CFD's (repetitive futures contract): again, lots of money, little profit
- Futures contract: Aha! we might be getting somewhere... it can't be done on margin (an account in the red will just be thrown away), but it could work...

I'm not very familiar with Open Transactions. Can it hold money in escrow? Can it hold fiat? If so, we could use trade-able "futurecoins":
- A futurecoin pair is created at $10 by a user. In order to hold a long or short position (an unbalanced coin), a user's account must have enough money to fulfill the contract. Thus, the user deposits 1 BTC.
- The user sells the longcoin to someone with $10 in their account.
- Several things can now happen. Both people can hold their coins, and a sale at $10 will be executed when the contract ends. The first user could buy the longcoin back on the open market, and when the contract ends, no transaction will take place. Buying the balancing coin would also allow the user to withdraw his money. So would selling the unbalanced coin, so perhaps this would encourage liquidity

I'm not sure futures were meant to be an asset

Of course, there are also options, but without an oracle (MPEX relies on an oracle), all options sold must be covered. If you are selling a PUT option, you must have fiat*put price*quantity on the exchange, and if you are selling a CALL option, you must have BTC*quantity on the exchange. However, only the original seller must have sold it covered; if I buy a PUT option from you and sell it to someone else, you still hold the obligation. I can use bananacoins to short BTC, without having BTC or fiat on the exchange this way: I buy the PUT from you with bananacoins and wait for it to appreciate.

The long+short basket currencies does have one major strongpoint: there's only one of it. Futures, CFD's, and options all have a strike price or something like it, so in a low-liquidity market, they're hard to trade. The baskets, however, are only two things: a longcoin and a shortcoin, and these can be valued by the market.

That does beg the question, however: "Who backs the long- and short-coins?" Why is a litecoin-longcoin worth 15 LTC + 1 BTC? If they can only be redeemed from the issuer as pairs, the 15 and -15 LTC don't really exist except in the minds of the traders. There is no real reason to value a longcoin more than a shortcoin except the concept; it's like a piece of paper which SAYS it's worth 1 BTC + 15 LTC, but it's only worth what others will pay. Bitcoin is worth only what others will pay, but it doesn't state in the transaction "this is worth 3 bales of hay" or whatever. It seems to me that the issuer must also buy-back individual long- and short-coins, or else the system is indistinguishable from two halves of a key which must be put together to open a lock: why should one half be worth more than the other?

[markm]

In people's minds one half should be worth more than the other, but getting them to agree that their half is worth less than the other guy's half could be a problem.

Leverage is not something we can do without securely escrowed or held collateral unless we have soldiers and/or police and/or lawyers in place on the planet where the collateral is located that can and will go get us that collateral in the event of a default.

In the game we can in fact have units of army and navy, and even nuclear missiles and so on, so in game contexts we can maybe allow collateral to be something we do not have in our vault. But in "real life" if it ain't in our vault we should assume Tom WIlliams and/or Pirateat40 has it.

All this really means is leverage is for the relatively rich.

The leverage I am thinking might be realistic to provide is the collateral/leverage account setup, whereby your broker maintains for you a nym that holds stuff of yours that the broker is willing to accept as collateral and the broker loans you stuff up to a value of some fraction (maybe half) of the value they think your collateral they have custody of is worth.

So compared to that, the basket long+short coins didn't look that bad really.

This matter of how to actually cause markets to value the longcoins and shortcoins appropriately is interesting though, Hmm...

-MarkM-

[nimda]

Obviously trading on margin / leverage isn't really feasible for the markets we're talking about. The best we can strive for, then, is 1:1 trading. A long/short basket does much worse than this, and so do the various CFD ideas. The futurecoins and options work 1:1, which is good. Additionally, both futurecoins and options can be traded as assets, but again, they don't work so well in an illiquid market.

This matter of how to actually cause markets to value the longcoins and shortcoins appropriately is interesting though, Hmm...

I think the only way to do it is to have the issuer (or some market-maker) accept longcoins and shortcoins separately.

[markm]

This matter of how to actually cause markets to value the longcoins and shortcoins appropriately is interesting though, Hmm...

I think the only way to do it is to have the issuer (or some market-maker) accept longcoins and shortcoins separately.

Maybe the platform could afford to do that on an alternating-type basis.

That is, it accepts them one at a time, and each time only of the type it didn't accept the previous time.

This could be smoothed out somewhat by having users offer the coins for sale, the marketbot then being able to look at both markets to check it can make a pair, and if doing so is within what it thinks (oops, maybe needing an oracle to do its thinking for it) is a worthwhile price it buys a pair.

Thus its buying activity basically broadcasts to the markets what its oracle is telling it is worth buying, which again brings us back to oracles.

It seems possible that if the interest on leverage loans is high enough, and such loans are popular enough, a brokerage doing the collateral/leverage accounts could build up enough collateral of its own that it might be able to provide larger leverage ratios to smaller borrowers, maybe even eventually to the point that small enough loans requested by frequent enough customers could even reach 1:1

For example if a specific customer has borrowed 100 of something at 1% per such loan 100 times, then the brokerage has already received 100 from them in fees, thus might be willing to risk some of that by offering an increase in leverage on loans that small or smaller.

Futurecoins maybe could be done as baskets the way assassination markets and such work. Basically someone interested in betting on a true/false proposition buys a basket of two coins, an itwasfalsecoin and an itwastruecoin. They then sell either of those to someone wanting the one they themselves do not want. When history reveals whether "it" was true or false, the house buys back either the true or the false but not both, the other becoming worthless.

Presumably the coins would then be retired while new but similar baskets are issued offering much the same bet but covering a new span of time.

Unfortunately this again needs an oracle, and oracles introduce liability as to whether the oracle might from time to time, ever, or always lie.

(LIARbility, hee hee.)

-MarkM-

[nimda]

This matter of how to actually cause markets to value the longcoins and shortcoins appropriately is interesting though, Hmm...

I think the only way to do it is to have the issuer (or some market-maker) accept longcoins and shortcoins separately.

Maybe the platform could afford to do that on an alternating-type basis.

That is, it accepts them one at a time, and each time only of the type it didn't accept the previous time.

This could be smoothed out somewhat by having users offer the coins for sale, the marketbot then being able to look at both markets to check it can make a pair, and if doing so is within what it thinks (oops, maybe needing an oracle to do its thinking for it) is a worthwhile price it buys a pair.

Thus its buying activity basically broadcasts to the markets what its oracle is telling it is worth buying, which again brings us back to oracles.

What if the longcoin could be split further? I.e. the issuer/house/platform will pay for the longcoin in backdrop + asset?
Then each basket is:
(((1 BTC) + (15 LTC)) + (1 BTC - 15 LTC))
Now the market has to value the longcoin more than the shortcoin. I see no way to "game" this system, but do you?

It seems possible that if the interest on leverage loans is high enough, and such loans are popular enough, a brokerage doing the collateral/leverage accounts could build up enough collateral of its own that it might be able to provide larger leverage ratios to smaller borrowers, maybe even eventually to the point that small enough loans requested by frequent enough customers could even reach 1:1

For example if a specific customer has borrowed 100 of something at 1% per such loan 100 times, then the brokerage has already received 100 from them in fees, thus might be willing to risk some of that by offering an increase in leverage on loans that small or smaller.

Unfortunately, in a market with anonymous consumers, anyone could seek to recoup their fees by scamming the lenders.

Futurecoins maybe could be done as baskets the way assassination markets and such work. Basically someone interested in betting on a true/false proposition buys a basket of two coins, an itwasfalsecoin and an itwastruecoin. They then sell either of those to someone wanting the one they themselves do not want. When history reveals whether "it" was true or false, the house buys back either the true or the false but not both, the other becoming worthless.

Presumably the coins would then be retired while new but similar baskets are issued offering much the same bet but covering a new span of time.

Unfortunately this again needs an oracle, and oracles introduce liability as to whether the oracle might from time to time, ever, or always lie.

Again, the oracle problem comes into play. I prefer my futurecoin idea above. Options don't need an oracle either.

(LIARbility, hee hee.)

hee hee

[markm]

What if the longcoin could be split further? I.e. the issuer/house/platform will pay for the longcoin in backdrop + asset?
Then each basket is:
(((1 BTC) + (15 LTC)) + (1 BTC - 15 LTC))
Now the market has to value the longcoin more than the shortcoin. I see no way to "game" this system, but do you?

I hadn't planned to implement the long and short coins as baskets themselves but simply to buy back pairs aka completed baskets for the value of the backdrop, since the actual long and short parts cancel each other.

Maybe though people holding shortcoins might have an incentive to simply not offer them for sale until some mythical pie in the sky time when they will be worth the full amount of the backdrop, the stuff it is short on having vanished away to zero value.

So I can see how having a time limit by which they have to be redeemed in order for the entire shortcoin to not become worthless could be useful.

But if having to tie up capital in the form of backdrop is as big a problem as you seemed to have earlier thought maybe tying it up indefinitely in the hope the thing you shorted will become worthless, or even just in the hope it will some year or decade become worth less than it was when you bought the basket or the shortcoin, is unlikely?

I wonder how much of a problem it would actually be to have a few scrooges who keep hoarding shortcoins, more and more and more shortcoins, and "never" selling them?

Since the longcoin can never go down in value to less than the value of its backdrop, the house/platform presumably should always be able to buy the longcoins back for that amount if no one else is willing to offer more.

Again, the oracle problem comes into play. I prefer my futurecoin idea above. Options don't need an oracle either.

Yes but options maybe require some special programming, if only in the form of smart contracts that take any needed collateral into the custody of the contract itself (which Open Transactions smart contracts can do); they might not be amenable to being implemented simply as tokens people can trade on the markets like any other tokens?

(This idea of trading like any other token is also part of why I prefer not to have to resort to having expiry dates on tokens.)

-MarkM-

[nimda]

What if the longcoin could be split further? I.e. the issuer/house/platform will pay for the longcoin in backdrop + asset?
Then each basket is:
(((1 BTC) + (15 LTC)) + (1 BTC - 15 LTC))
Now the market has to value the longcoin more than the shortcoin. I see no way to "game" this system, but do you?

I hadn't planned to implement the long and short coins as baskets themselves but simply to buy back pairs aka completed baskets for the value of the backdrop, since the actual long and short parts cancel each other.

I know, but this method makes the market actually value them properly. The longcoin can be redeemed for its parts, the shortcoin can be redeemed for its backdrop by paying the short part, and the two can be redeemed together for the backdrops.

Maybe though people holding shortcoins might have an incentive to simply not offer them for sale until some mythical pie in the sky time when they will be worth the full amount of the backdrop, the stuff it is short on having vanished away to zero value.

That'd be a silly thing for them to do, but it's no loss to the issuer.

So I can see how having a time limit by which they have to be redeemed in order for the entire shortcoin to not become worthless could be useful.

This is the most fundamental flaw of the basket. The shortcoin can become a liability and simply be discarded.

But if having to tie up capital in the form of backdrop is as big a problem as you seemed to have earlier thought

It's actually 2 separate problems:
- The shortcoin can have a negative value
- It's not economical to be long 15 LTC by tying up 1 BTC; instead, why not just buy the 15 LTC? This is the "worse than 1:1 leverage" part.

maybe tying it up indefinitely in the hope the thing you shorted will become worthless, or even just in the hope it will some year or decade become worth less than it was when you bought the basket or the shortcoin, is unlikely?

It's still no loss to the issuer.

I wonder how much of a problem it would actually be to have a few scrooges who keep hoarding shortcoins, more and more and more shortcoins, and "never" selling them?

It wouldn't be a problem if the longcoin and shortcoin were themselves baskets, as I said above:
(((1 BTC) + (15 LTC)) + (1 BTC - 15 LTC))

Since the longcoin can never go down in value to less than the value of its backdrop, the house/platform presumably should always be able to buy the longcoins back for that amount if no one else is willing to offer more.

The house should offer the backdrop + asset for longcoins, and the house should sell the backdrop for (shortcoin + asset).

Again, the oracle problem comes into play. I prefer my futurecoin idea above. Options don't need an oracle either.

Yes but options maybe require some special programming, if only in the form of smart contracts that take any needed collateral into the custody of the contract itself (which Open Transactions smart contracts can do); they might not be amenable to being implemented simply as tokens people can trade on the markets like any other tokens?

(This idea of trading like any other token is also part of why I prefer not to have to resort to having expiry dates on tokens.)

-MarkM-

- Alice creates 5 CALL tokens: buy 1 LTC for 0.003 BTC. The platform holds 5 LTC.
- Alice sells the 5 tokens to Bob. He sells 3 to Chris.
- Note that the platform didn't require any collateral from Bob.
- LTC price rises to 0.006. Bob exercises his 2 tokens. His tokens are removed from existence, 0.006 BTC is sent to Alice, and 2 LTC are sent to Bob.
- Afraid of a further rise in price, Alice buys 1 of her tokens and exercises it. She buys the LTC from herself, removing the token from existence.
- Alternatively, if her own tokens are unavailable, she buys an identical token (9.12.LTC.0.003) and holds it. The platform allows her to "link" it to one of her issued tokens.
-- Thus when Chris exercises one of her tokens, Alice's account takes the BTC sent to it by Chris and uses it to exercise the one she bought; both are removed.
- LTC crashes and the last token Alice issued (held by George) expires.

It seems to me that it would work.

[markm]

- Alice creates 5 CALL tokens: buy 1 LTC for 0.003 BTC. The platform holds 5 LTC.

Lets try to avoid individualised smart contracts if we can. For example, litecalls tokens could cost one litecoin each, bought from the house. She still gets five tokens for five litecoins, but there is no need for an entire smartcontract per token with an internal variable storing a litecoin.

The weakness here would be either a proliferation of hundreds or thousands of different types of token, one per strike price alice might propose, OR it being entirely up to alice how much she chooses to tell bob she is willing to honour the proposal at.

Yuck. I still think this cannot really be done as simple permanent tokens people can obtain from the house and eventually sell back to the house.

Instead we are faced with an entire smart-contract per each individual call, whether in this case that will be one call good for five litecoins or five calls good for one litecoin each.

- Alice sells the 5 tokens to Bob. He sells 3 to Chris.
- Note that the platform didn't require any collateral from Bob.
- LTC price rises to 0.006. Bob exercises his 2 tokens. His tokens are removed from existence, 0.006 BTC is sent to Alice, and 2 LTC are sent to Bob.
- Afraid of a further rise in price, Alice buys 1 of her tokens and exercises it. She buys the LTC from herself, removing the token from existence.
- Alternatively, if her own tokens are unavailable, she buys an identical token (9.12.LTC.0.003) and holds it. The platform allows her to "link" it to one of her issued tokens.
-- Thus when Chris exercises one of her tokens, Alice's account takes the BTC sent to it by Chris and uses it to exercise the one she bought; both are removed.
- LTC crashes and the last token Alice issued (held by George) expires.

It seems to me that it would work.

All that automatic sending of stuff back and forth and vanishing of tokens is basically smart contract stuff not tokens.

Each "exercise" would be the causing of a script built into a contract to be run, with the money to be transfered to or from whoever possibly having to be stored in the contract all along. Or it would be multiple scripts, such as bob "buying" the contract being bob storing assets into it as collateral ready to be sent on to alice if he exercises the contract.

It might well make sense to create some kind of special-purpose platform in which abstractions tailored specifically to this type of thing exist than to go through all the overhead of a smart-contract per coin, which could get really heavy load if someone decided to exercise many thousands at once,

To be able to put such things on the markets, meaning, to be able to offer to sell them for any asset, their price cannot be built into them it must be something the market decides. Having to have a market for each possible strike price proliferates the number of markets massively, since any asset can be paired with any asset to form a market at any power of ten scale.

So you'd end up with markets like "strike price 0.003 litecoin calls offered for sale for 0.002 Ixcoin calls in lots of one",  "strike price 0.003 litecoin calls offered for sale for 0.002 Ixcoin calls in lots of ten", "strike price 0.003 litecoin calls offered for sale for 0.002 Ixcoin calls in lots of a hundred" and so on for all possible pairs of assets, which would include all possible strike prices of all altcoins' calls and all shares' calls and so on and so on.

Take a look at the number of markets we already have just in having ten or twenty coin and share assets each of which can be traded at any integer scale of ten against each of the others...

By contrast, sure if any alice and any bob can get together somewhere and negotiate some specific deal they can figure out how to code into a smart contract they can do so. It is just kind of awkward to expect any specific deal they come up with to be a mass-sellable item tons of other people will be interested in bidding on (since at the very least they might well prefer a tiny difference in the strike price, which makes the entire thing a totally different product...)

-MarkM-

[nimda]

- Does not require an oracle
- Is not too specific
- Makes sense to actually buy -- offers up to 1:1 leverage

Pick two

[markm]

How about Bob and Alice each incorporate and do IPOs, Alice running her Litecoin Shorting Corp and Bob running his Litecoin Longness Corp, and sell shares? People betting litecoin will go long will buy Bobcorp, people betting it will go short will buy Alicecorp, and part of the fiduciary responsibility that Alice and Bob take on is minimising loss / maximising profit for their shareholders?

Shares can trade on any markets, and Bobcorp and Alicecorp can even work out any kinds of leverage either between them or with various other corps, or issue bonds to obtain leverage, or whatever they in their fiduciary capacities and vast wisdom and experience determine to be the most effective means of profiting from the fall of litecoin in the one case or the rise of litecoin in the other?

-MarkM-

[nimda]

How would AliceCorp go about shorting litecoin?

[markm]

Borrow it from Bobcorp and sell it, maybe?

Bobcorp should be eager to earn more Litecoin by loaning it at interest?

Maybe at some arms length if Bobcorp prefers to think itself to be investing in litecoin based corps rather than to be helping Alicecorp short Litecoins.

But heck Bobcorp likely doesn't hold all the litecoins, right? So maybe borrow from someone else.

Actually General Credit Corp is kind of hoping to be able to fill the role of loaner of a wide variety of assets...

-MarkM-

[nimda]

But unlike all of the other vehicles we've been discussing, that method opens up the risk of default. What if Litecoin goes up by 10X? The BobCoin litecoin bulls could lose money.

[markm]

Bulls profit if it goes up, It should be it going down that would be bad for Bobcorp.

But defaults seem to me to simply emphasise the need for collateral.

Tying up a bunch of your capital might be real bad if you are small, but maybe at some "too big to fail" kind of scale having at least half one's capital tied up as secure collateral might actually make sense, at least better sense than being leveraged so that the tipping point / butterfly's wing needed to bring your entire edifice and maybe much of the nation / society is operates in down is small/sensitive?

-MarkM-

[nimda]

Bulls profit if it goes up, It should be it going down that would be bad for Bobcorp.

Not if Alicecorp can't fulfill its obligations on the loan.

But defaults seem to me to simply emphasise the need for collateral.

Where would this collateral come from? Shareholders' homes?

If Alicecorp's shares are sold in BTC, and Alicecorp borrows LTC from Bobcorp, but LTC price rises 1000x, there's no way Alicecorp can pay back the loan; the BTC won't cover it.

[markm]

In that case the platform/house certainly should not cover it, and maybe should warn Bob against taking so much risk.

Maybe there is some middle ground between hedging versus loss thus not losing or gaining, and gambling.

-MarkM-

[fellowtraveler]

I'm not very familiar with Open Transactions. Can it hold money in escrow?

Yes.

[markm]

So I can see how having a time limit by which they have to be redeemed in order for the entire shortcoin to not become worthless could be useful.

This is the most fundamental flaw of the basket. The shortcoin can become a liability and simply be discarded.

There are probably some pairs though where that is ridiculously unlikely. For example GRouPcoin generates 50 coins per block forever whereas BiTCoin generates less coins per block over time, so the idea that a GRouPcoin would ever "really" be worth more than a BiTCoin seems a bit of a stretch. Basically though all this problem does is provide a floor under losses from shortness.

But if having to tie up capital in the form of backdrop is as big a problem as you seemed to have earlier thought

It's actually 2 separate problems:
- The shortcoin can have a negative value
- It's not economical to be long 15 LTC by tying up 1 BTC; instead, why not just buy the 15 LTC? This is the "worse than 1:1 leverage" part.

The "why" here, I suspect, is that you are not merely going long, you are going long while someone else goes short. So what you are really buying, over and above what you'd get by simply buying the litecoins, is someone else going short by the amount you go long. A different kind of short than a person achieves merely by selling you litecoins, as they are basically trying to sell you litecoins they do not have. (Is that "naked" shorting, maybe?)

I do not know how useful it is to have someone else go nakedly short in something you are bullish on. But maybe it is better than having someone go non-nakedly short on it as they would by selling you the thing? Since basically you are trying to create debt denominated in the thing you are bullish on, which in turn if the debt is not defaulted on ought to end up becoming, at some future time, a demand for the thing? (Since the debtor will eventually hopefully be looking to pay back their debt.)

I wonder how much of a problem it would actually be to have a few scrooges who keep hoarding shortcoins, more and more and more shortcoins, and "never" selling them?

It wouldn't be a problem if the longcoin and shortcoin were themselves baskets, as I said above:
(((1 BTC) + (15 LTC)) + (1 BTC - 15 LTC))

The problem I see with that basket is, what the heck is a negative fifteen litecoin? Some kind of debt instrument?

Since the longcoin can never go down in value to less than the value of its backdrop, the house/platform presumably should always be able to buy the longcoins back for that amount if no one else is willing to offer more.

The house should offer the backdrop + asset for longcoins, and the house should sell the backdrop for (shortcoin + asset).

Hmm maybe. I suppose one way to implement that would be to have another basket currency made of (shortcoin & asset) that the house can buy on markets, and to either create yet another basket currrency made of (backdrop & asset) that the house can offer for longcoins or to compute from the exchange rates of the backdrop and the asset against other things a price in any actually existing asset at which the house will buy longcoins.

Hmm.

Maybe the mutually exercise-able option concept might work better?

Basically we both agree on a strike price and volume and expiry date and up until the expiry date either of us can exercise the option. Basically we would be trading calls for puts.

Such an approach might need some kind of bot or something though as when it was discussed before someone seemed to imagine only the person "in the money" would exercise it, whereas upon reflection it seems to me that the party who is headed out of the money might also wish to exercise it to stop their loss, resulting in the in the money party needing to set up another similar deal again as soon as possible to continue/extend their gain.

-MarkM-


EDIT:

Code:

<knotwork> I suppose you could make it use granular time.
<knotwork> so as well as an expiry like maybe 30 days or whatever, also when you say to exercise it it does not actually execute until the next midnight
<knotwork> or dawn or whatever
<knotwork> so if you flinch at the first satoshi out of trhe money five seconds after making the deal, you may find when the full 24 hours of granularity of time is up that you flinched too soon

(Yes, "knotwork" on Freenode IRC is me.)

[nimda]

I wonder how much of a problem it would actually be to have a few scrooges who keep hoarding shortcoins, more and more and more shortcoins, and "never" selling them?

It wouldn't be a problem if the longcoin and shortcoin were themselves baskets, as I said above:
(((1 BTC) + (15 LTC)) + (1 BTC - 15 LTC))

The problem I see with that basket is, what the heck is a negative fifteen litecoin? Some kind of debt instrument?

The parenthesis are very meaningful. There is no negative fifteen litecoin. Here are the baskets:

Code:

Longcoin
    1 BTC
    15 LTC
Shortcoin
    1 BTC - 15 LTC

The longcoin can be split; the shortcoin can't.