Yes 'having to cover' is a disadvantage, and something I wanted to remove from the system.  That's why I am advocating no user-generated forced-settlements and only automatically forcing under-collateralized positions.  That would make the market symmetric. 

merivercap, I understand your desire, most traders just want to trade without being forced out of anything unless they fail to maintain collateral. Unfortunately somebody must offer settlement in some form, either continuously or at an expiry, at a price near or at fair value, in order for any derivative to offer exposure matched to the underlying asset (a pegged asset is simply a form of derivative). All traditional derivatives have settlement, and there is no historical precedent for anything otherwise that I am aware of. I am not sure you accept this, and am happy to discuss my opinion further, perhaps outside this thread to not distract this discussion too far.

But assuming this is true, I think the desire you are expressing is:
i) for longs and shorts to simply be able to hold positions for as long as they like (i.e. no expiries), and
ii) be able to settle that against an intermediary rather than parties forcing the hand of opposing parties.

This is effectively what a CFD manager does when they offer a spread around fair value. To be able to do this, the CFD manager needs to absorb the difference between longs and shorts, and hedge their book of exposures in the external market. We could create something like this in bitShares. We would need a pool of users to act as a decentralised CFD manager and offer a spread around an external fair value, and be willing to hedge the long and short positions in the external market, using futures, ETFs or other available instruments. The pool would take income in the form of a market spread as we all as possibly a fee charged on the collateral of both longs and shorts. I would be interested to explore this concept further.

In the end I think bitShares could have many different classes of markets (currency, bonds, CFDs, ETFs, futures, options, shares, credit,...), each serving a different role for users, and each privatised. There is no need to think of all these things as competing ideas. They are complementary. There is simply no perfect solution that will meet all needs.

I've opened the possibility of an equivalent to ETFs in another thread, ideal for use as an investment vehicle. CFDs as above are ideal for leveraged trading, at a cost. Futures and options are ideal for managing exposures over a defined period.

We have all been so obsessed by trying to find the perfect solution to currency, that we are missing the fact we need customised solutions for different needs. We are banging our heads against each other in vain. Everyone's needs can be met, but not through the same vehicle.

As the OP infers without saying so, speculative traders should not be the party offering fungible non-expiring assets. This should be offered by parties willing to earn an income from making and supporting those markets. Speculators can have many other avenues to ply their trade as we develop them.

This is Bitfinex's response:

Bitfinex and BitGo Partner to Create World’s First Real-Time Proof of Reserve Bitcoin Exchange
Posted: about 4 hours ago

We are very excited to unveil our new Bitcoin settlement system and security architecture that for the first time ever offers complete segregation of all customer bitcoins. Based on BitGo’s revolutionary multi-signature technology, we are now able to provide individual multi-signature wallets for each customer, allowing traders to verify funds on the Blockchain for complete transparency while retaining institutional-level security.

Starting today we will begin using unique sets of keys for each user, and will separate each user’s funds on the public blockchain. This powerful combination of BitGo’s multi-sig technology with our exchange mitigates most of the shared pool security risks while simultaneously enabling users to verify their individual holdings on the blockchain.

We will start migrating users' accounts to the BitGo system over the next couple days. We hope to have the full migration completed in less than a week.

How would the 2 way arbitrage work without compromising decentralization?  From what I understand, you would need to be able to transfer an external asset into the internal exchange for the arb channel to be completed both ways.

As for existing bitAssets, the collateral pool never holds the real asset, just obligations linked to the real asset and backed by collateral tokens. So the arbitrage is facilitated by conversions, at a "fair price", between collateral tokens (BTS) and the tracker tokens (e.g. bitOIL), in a similar (though not equal) manner to how 1-way settlement is intended to operate under BTA 2.0.

This article really summarizes how an ETF works, and is a good model for how BTA could work:
http://www.investopedia.com/articles/mutualfund/05/062705.asp

Thanks maqifrnswa. I have already built such mechanisms into the basic design concept, its just a matter of getting some interest in this style of product. What I'd really like to do is find a small team of people willing to work together to peer review, test feasibility, and help refine the processes. But I was looking for some show of support first.

Quote from: Helikopterben on June 03, 2015, 10:03:18 pm

How would the 2 way arbitrage work without compromising decentralization?  From what I understand, you would need to be able to transfer an external asset into the internal exchange for the arb channel to be completed both ways.

that's the problem :-( you can force close but you can't force short... i haven't been able to figure out a way to solve it unless holding BTS is seen as a profitable investment (BTS, as a DAC, generates more values than it spends on infrastructure and development), so people will short to gain leverage.

I believe this is possible as long as you have short orders in a queue, and you should always have short orders in a queue at some level of funding rate, because unlike bitAsset 1.0, it can be as low as they desire.

The key is to consider the wider motives of shorts, which as I've raised before (see https://bitsharestalk.org/index.php/topic,16427.msg210020.html#msg210020), should not be restricted to leveraging BTS to take advantage of bull markets. For example, a BTS holder can self-create a short in order to earn income from making a market in the tracker token, by switching between long the token and long the real asset, at discounts and premiums. If the funding rate is a lot lower than they would need to obtain this capital from external sources, their preference will be to obtain the funds by internal self-creation, and possibly even get paid for it. Other users may self-create shorts, sell the long token, and invest the proceeds in whatever manner they see fit. This is equivalent to a borrowing in the asset against their existing BTS collateral. There will always be some level at which they will want to do this if the funds can be obtained more cheaply than by borrowing externally by other means. Or other users may want to take a short in the asset against USD, by self-creating, selling the long token, and keeping the proceeds in USD. Again they will weigh up the cost of doing so against the cost of other types of shorts available in external markets. Note that in each of these examples, the shorts are not motivated to take additional exposure to BTS, and they do not do so.

Its possible short orders do not exist if there is a shortage of collateral units available to create more shorts, but I have a mechanism to restore parity in that rare circumstance also (or any circumstance where there happens to be an absence of short orders), that does not rely on arbitrage.

I'm happy to answer some more questions, but I'm really still looking for people to say they want this. Personally, I think its a no-brainer if we can do it.

I'm interested again in the answer to this. But there might be an easier way. In short form:

Suppose there is a DEPOSIT token that represents a certain amount of USD, where that conversion amount varies over time with internal interest. I'm exploring how such a token could be used to facilitate transfers in the underlying USD, much like a checking facility or bank transfer does today.

Party A has DEPOSIT tokens, and now wants to send Party B a certain quantity of USD. To do this he needs to send a specific number of DEPOSIT tokens, but I assume he doesn't know precisely how many until the end of the block when the transfer is effectively received by Party B. If exact precision were not a concern, his client could automatically calculate the amount from the conversion rate at the last block, when sending the transfer. This might leave Party B ever so slightly long or short depending on whether interest is positive or negative (10 seconds worth of interest, assuming a 1 block confirmation). So would anybody ever care for higher precision than this?

If we did care for perfect precision, how could this most simply be done? I was imagining something like a simplified version of a check specified in USD, with the block-chain then determining the quantity of DEPOSIT tokens to transfer. Not sure if this is possible though.

bytemaster and others interested,

*** The Short Version ***

I'm proposing an approach to bitAssets, for assets not intended as currencies, that is more like a traditional exchange-traded fund (ETF). This would be like holding the real asset, but where the underlying number of units changes gradually over time according to a market-determined funding rate, that could be positive or negative. Due to 2-way arbitrage, the tracking token would tend to centre around fair value, while still having some spread for liquidity.

I'm looking for interest in the concept, as a possible alternative to BTA 2.0 for these types of assets, with a view to writing up a full design concept for further review.

**** Longer Version ***

It seems to me that there are different goals for tokens to be used as currency in goods and services transactions (bitUSD, bitCNY etc) versus tokens that are intended to simply behave like holding and storing an asset (e.g. oil or other commodities, stocks and stock indices, etc). This suggests that the optimal structure for each class may also be different.

bytemaster, you seem to be taking the bitAsset 2.0 design along the path of having a continuous premium to parity to accommodate a cut to payment facilitators when currencies are used with merchants. As you know, I am not sold on this yet, but we can take this up in the other thread. In any case, I believe this line of reasoning has no relevance to the second class of tokens above, which will never be used for goods and services.

I believe that the most useful design in these cases is something similar to the way that exchange-traded funds (ETFs) behave. An ETF allows investors to receive the performance of the underlying assets held in the fund. That includes any earnings or costs associated with the holding of those assets. To the extent those earnings are reinvested, or expenses paid from the assets of the fund, the effective number of units of the underlying asset per share in the ETF varies over time. But that does not matter to the investor. What matters to them is that the returns on the fund are a near perfect proxy for having held the assets themselves.

I've designed a concept that constructs a bitAsset to behave in this manner, although of course its construction is by necessity different to an ETF, representing decentralised trades between parties rather than a security on a fund. The structure could even be used for currencies, as long as investors are buying as an investment exposure rather than for use in transactions. That's because there is a market-determined funding rate that adjusts the number of notional asset units of exposure per token over time, whether positive or negative. That is, its not a fixed exposure to the asset. The funding rate is determined by supply and demand, but these in turn will have at least some regard to external funding rates (or interest rates on currencies), providing an external linkage.

For non-transactional holdings, I think this structure is favourable to bitAsset 2.0 because it centres around the fair value of the underlying asset instead of at a premium, and arbitrage mechanisms act as a compressing force around the peg. This will give investors and traders exactly what they are looking for. [Edit: It also may pay a reinvested yield, just like the underlying asset, where net yields are positive in the external market].

I would like to know whether you would like to collaborate further on this concept if you see it fitting into the core BitShares protocols, and how to take forward. It still requires peer review, and no doubt some refinement. Interested in your view and that of anybody else interested in this approach.

Quote from: valzav on June 02, 2015, 07:52:37 pm

So what do you think about "platform"? In a lot of cases it's used as synonym to OS.

Platform works. That's what ethereum is calling themselves and I just wanted to differentiate bitshares a little. I would suggest sticking to finance though. I see no point in trying to be a better version of ethereum. The trick seems to be specializing to get initial market share. In the 80s, Microsoft focused on businesses while Apple focused on the individual consumer. Microsoft destroyed Apple because the end user wasn't ready for personal computing (sound familiar?). Businesses were eating up Microsoft's tech because it saved money and gave them a competitive edge.

In our case, Bitshares can be the Microsoft of blockchains and laser focus on solving the financial sector's problems. Let Etherium [try to] appeal to the common user. They will fail until much later, when this tech is maturure and people are actually ready to use it on their own. Until then, solving the financial industry's problems will take us to where we need to be. We can appeal to "everybody" when the time is appropriate.

Edit: Same dynamic was true for Blackberry. They went straight for businesses and became massively popular in their day. Only problem with both Blackberry and Microsoft is they failed (are failing) at appealing to average users when the time came.

I find this a persuasive argument for initial specialisation, although that could be for business or retail. To integrate with business, we may need the bitShares "business" to be regulated in some form to have any credibility with big players. As long as we have the ability to change (or remove) jurisdiction at some later point.

Quote from: starspirit on May 29, 2015, 11:55:47 pm

Quote from: starspirit on May 27, 2015, 11:34:42 pm

bytemaster,

What about this solution to please everyone?

1. Have bitUSD centred on parity (there is a liquidity spread around parity)

2. Create a couponUSD for merchant use that is convertible both ways by the block-chain at 1.06 bitUSD

If users want to use bitUSD with external merchants, they convert bitUSD to couponUSD at a 6% premium and spend it. The payment processor then converts the couponUSD back to bitUSD, sells bitUSD for USD near parity, pays the merchant and keeps the extra 6%+/-.

The advantages of this approach are:

i) We still have a parity centred bitUSD that has greater utility in a broad swathe of applications
ii) Payment processors facilitating trade with merchants are satisfied they get their cut
iii) The free market can determine what relative demand there is for both bitUSD and couponUSD
iv) It makes more sense to the market that bitUSD tracks a dollar, and there is a separate coupon program for dealing with merchants

The liquidity spread is no greater than the liquidity spread that would be experienced if we tried to create a bitUSD that trades around a 6% premium, because the same liquidity issues you raise exist whether we choose to centre trading around $1.00, $1.06 or any other level. So payment processors experience profit risk in the size of their cut that is also no greater than would be the case by using a bitUSD centred on $1.06.

[As an aside, for those arguing that a bitUSD should trade at a premium to $1 because it is a premium means of payment, it should be clear from the above that this is a bogus argument. A bitUSD retains all the same benefits whether it is centred around $1 or $1.06. In the approach above, the coupon instrument is not better than a bitUSD, it is simply an instrument to ensure payment facilitators get their cut.]

bytemaster, any thoughts on this? Might this be a way to meet both needs without compromise?

I think it would get gamed, it is an extra step to pay a fee that would be easier for merchants to just add a 6% fee to their bill.

Unsure exactly what you mean.
Isn't the extra step just an instantaneous block-chain conversion? If so this could even be done automatically on receipt by the merchant payment processor (i.e. coupon USD is one-time-use).
How would this get gamed? i.e. who potentially loses?

Quote from: bytemaster on May 28, 2015, 12:46:18 am

What are your concerns about using feed to adjust premium over the peg?

I don't understand how you intend for it to work. My impression, please correct if its wrong, is that as the premium grows, you drop the price feed below its "fair" price (like a fee on settlements) and as the premium contracts, you lift it back toward the "fair" price (lower the "settlement fee"). Is that correct?

If it is, then I have a concern with it. For any static settlement fee, I agree the average trading price would equilibrate at a different level. The possible problem is that when it is dynamic the market may not price it in because it never comes into force, as here:

Quote from: starspirit on May 23, 2015, 01:00:32 am

...I can't see why the market would price this in. If the market is at a premium, then the settlement mechanism is not needed. By the time the settlement mechanism is needed and used, the price must be at a discount where there is no longer a settlement fee. So there is no need for any settlement fee to ever be paid, nor any buyer to price in the risk of a higher fee, no matter how high the premium. So how would this affect supply or demand?

Reminder to bytemaster- awaiting answer on this.