Vitalik on stable currencies and POS

[vbuterin]

So, step 0: there exists a CFD with A at +$100 USD and B at -$100 USD

> B needs to find a BitUSD seller (on the internal exchange) so B can buy BitUSD from that BitUSD seller

Okay, now we have two contracts:

A at +$100 USD, B at -$100 USD
B at +$100 USD, C at -$100 USD

I can see here that B is neutral USD again. However, B is not fully neutral: the margins for the two CFDs are different, and so it's entirely possible for the first contract to margin-call, leaving B long.

> and then exchange the BitUSD again for the collateral (BTS) at the exchange rate of BTS/BitUSD at which B entered the CFD

Wait, what? Doesn't that mean that B is back to being short bitusd again?

[toast]

I don't follow.

B buys $100 and covers his short. Now he's only long BTS instead of superlong BTS.  A is still long USD, C is short USD / superlong BTS. All B did was buy USD from C and use it to pay off his debt for his short, not interacting the bitUSD originally created by that short.

Then, B decides that he does not want to be ultralong BTSX anymore and leaves the CFD. Is A stuck with volatility until her client can manually find a new partner?

B can't leave the CFD unless he obtains 100 bitUSD somehow - either buys it out of a different short or lets his short expire and create a buy wall following the price feed.

in schellingdollar, CFDs do not have an explicit counterparty

the bitUSD holder doesn't have a specific counterparty either - the short which creates the USD is not any different from all the others.

[vbuterin]

So I'll be more specific. How are shorts and longs stored in the blockchain state database?

The model that I thought it was, is that CFDs are a list of the form (assuming only bts and bitusd):

Code: [Select]

[
    [short_party, long_party, strike_price, short_margin, long_margin, amount, expiry],
    [short_party, long_party, strike_price, short_margin, long_margin, amount, expiry],
...
]

The model you seem to be suggesting is that accounts are stored in the form:

Code: [Select]

[
    [bts holdings, usd holdings (+ or -)],
    [bts holdings, usd holdings (+ or -)],
...
]

Which is how SchellingDollar works. What is the bitassets approach exactly?

[bytemaster]

Bit usd is just a balance like bts. 
Short bit usd is stored as a market order at the call price with interest rate and expiration.  It is non transferable.   

[Rune]

This thread is a good example of why all developers should work together under a single block chain. Ethereum and bitshares has had to completely duplicate their work on inventing a stable crypto token. If ethereum and bitshares had been a single project then developers could have worked in parallel and blockchain tech would be twice as far today.

It'll come soon. Once 1.0 and the marketing push begins, bitshares will gain network effect and all crypto development will begin to integrate as delegates to leverage their value onto the bitshares community and avoid duplicating (and thus wasting) work.

[toast]

So I'll be more specific. How are shorts and longs stored in the blockchain state database?

The model that I thought it was, is that CFDs are a list of the form (assuming only bts and bitusd):

Code: [Select]

[
    [short_party, long_party, strike_price, short_margin, long_margin, amount, expiry],
    [short_party, long_party, strike_price, short_margin, long_margin, amount, expiry],
...
]

The model you seem to be suggesting is that accounts are stored in the form:

Code: [Select]

[
    [bts holdings, usd holdings (+ or -)],
    [bts holdings, usd holdings (+ or -)],
...
]

Which is how SchellingDollar works. What is the bitassets approach exactly?

You have normal USD and BTS balances, and you have open margin orders which are a negative USD balance and a positive BTS balance in collateral. So like your latter case but usd and bts balances are not explicitly associated in pairs except for margin orders.

[vbuterin]

What do you mean usd and bts balances are not explicitly associated in pairs? All I was describing with my second case is that everyone has an account, and the data record for each account stores a quantity of bts and a quantity of usd, which can be positive or negative, but with margin limits.

[arubi]

...
1) We assume a trusted price feed exists
...

This is the elephant in the room.

(It's Oracles all the way down...)

[speedy]

What do you mean usd and bts balances are not explicitly associated in pairs? All I was describing with my second case is that everyone has an account, and the data record for each account stores a quantity of bts and a quantity of usd, which can be positive or negative, but with margin limits.

Does he mean that all balances are freely tradeable against each other?

[toast]

What do you mean usd and bts balances are not explicitly associated in pairs? All I was describing with my second case is that everyone has an account, and the data record for each account stores a quantity of bts and a quantity of usd, which can be positive or negative, but with margin limits.

Sure, if "accounts" are an off-chain organizational concept and not an on-chain data structure. Typically balances have distinct keys, but even two balances with the same owner keys but different assets get different balance IDs.

[Rune]

...
1) We assume a trusted price feed exists
...

This is the elephant in the room.

(It's Oracles all the way down...)

You already trust the core developers and core community members when you download the client on the internet. These are the same kind of people who run the delegates. It requires much more trust in a community to give your private keys to software they signed off on, than to give their stakeholders control over the price feeds. It results in no net risk increase from bitcoin IMO.

[arhag]

...
1) We assume a trusted price feed exists
...

This is the elephant in the room.

(It's Oracles all the way down...)

You already trust the core developers and core community members when you download the client on the internet. These are the same kind of people who run the delegates. It requires much more trust in a community to give your private keys to software they signed off on, than to give their stakeholders control over the price feeds. It results in no net risk increase from bitcoin IMO.

I don't think that is a good comparison. One can audit the code they download and compile once.

The answer isn't trust. The real answer is that people can audit the price feeds submitted by the delegates. If a delegate is manipulating the price feeds, this is provable by examining the blockchain, and there will be consequences for that delegate (they will get fired).

This is similar game mechanics to a bunch of oracles submitting their answer (in a two stage process: commitment then reveal) along with a deposit which will be taken away if their answer diverges significantly from the consensus result (e.g. the median for a quantitative measurements, or the mode for a qualitative one) and a reward if their answer is close to the consensus answer. It just isn't done automatically by the blockchain and instead requires human stakeholders to react (although there is no reason we couldn't add this automatic blockchain reward/punishment system to our system as well). The one benefit of letting the human stakeholders react to the provided price feeds is that the system can correct itself even if the majority of the oracles (in this case the delegates) all collude together.

[vbuterin]

This thread is a good example of why all developers should work together under a single block chain. Ethereum and bitshares has had to completely duplicate their work on inventing a stable crypto token. If ethereum and bitshares had been a single project then developers could have worked in parallel and blockchain tech would be twice as far today.

So we're accepting that Bitcoin maximalism is nonviable but we're doing Bitshares maximalism now? Umm... how about no? I'm actually about to release a blog article describing why I think fragmentation and silos in cryptocurrency are an awesome thing, and the concept of one-x-to-rule-them-all in this space should go die forever. World is a lot more peaceful when you don't have everyone simultaneously trying to take all of it over. Though I do agree that there should be more collaboration on low-level components (eg. we've done a lot of work replicating a whole bunch of crypto functions like serialization, merkle trees, erasure coding and ECDSA in 5 languages that others should feel free to leverage) and high-level components (eg. I think that eventually Mist and Maelstrom and whatever you call the Bitshares client should all support every underlying crypto-platform, and so browsers and protocols should compete separately).

Sure, if "accounts" are an off-chain organizational concept and not an on-chain data structure. Typically balances have distinct keys, but even two balances with the same owner keys but different assets get different balance IDs.

So this means that you're storing balance pairs of <bts, bitasset> separately for each bitasset/user combination? It would not make sense to just store <bts>, <bitasset>, <bitasset>, because then if one of the bitasset balances goes negative you have an uncollateralized debt and the owner can just run away from it.

You already trust the core developers and core community members when you download the client on the internet. These are the same kind of people who run the delegates. It requires much more trust in a community to give your private keys to software they signed off on, than to give their stakeholders control over the price feeds. It results in no net risk increase from bitcoin IMO.

Software is a 1-of-n trust model. If there's a backdoor, it only takes one person to point it out. Delegate price feeds are n/2-of-n. Now, I would argue blockchains run on the principle that n/2-of-n is an okay trust model iff your set of n is actually decentralized, and at this point I haven't researched the topic enough to see whether DPOS delegates (i) currently are, (ii) could be expected to continue to be in the future less or more decentralized than ASIC farms. Of course, my intuition is that the decentralization level of ASIC farms is not exactly a high bar to meet

Does he mean that all balances are freely tradeable against each other?

All I'm basically asking for is a precise description of how exactly "CFDs" are kept track of in Bitshares. Is it the case that each individual CFD is kept track of separately? Looks like the answer is no, since I got an explicit answer that CFDs have no explicit counterparty. Is it just a set of accounts which hold balances, where the bitasset balance can be positive or negative? Looks like the answer is yes, except that you're maintaining a separate on-blockchain object for each bitasset. I suppose the simplest way to answer my question might even be to implement bitassets in Serpent a la https://github.com/ethereum/serpent/blob/poc7/examples/schellingcoin/schellingdollar.se.

[monsterer]

...
1) We assume a trusted price feed exists
...

This is the elephant in the room.

(It's Oracles all the way down...)

It is entirely possible that without a reference, trusted price feed, tracking the value of an external entity is unachieveable. The schelling point scheme described in the paper isn't workable without a way to judge whether the betters participating in the process are right or wrong, which implies there must be a reference price.

What is interesting to me is the idea of measuring hashing power in a POW scheme (or transaction fees in POS) and using that as an internal measure of the value of the coin, thereby allowing a coin to attain its own, self contained price stability. Looking into a post fiat world, this has the potential to be quite important.

Still, as BM points out both the above idea and with an infinite printing press driving the price stability system, market manipulation might be a big problem.

[Rune]

Though I do agree that there should be more collaboration on low-level components (eg. we've done a lot of work replicating a whole bunch of crypto functions like serialization, merkle trees, erasure coding and ECDSA in 5 languages that others should feel free to leverage) and high-level components (eg. I think that eventually Mist and Maelstrom and whatever you call the Bitshares client should all support every underlying crypto-platform, and so browsers and protocols should compete separately).

If we have several blockchains that all have the same clients (and thus UX) and are all turing complete, and all have funding to copy any new feature that's invented in the space by anyone, then the only real difference between blockchains would be their liquidity (and thus market cap/volatility of the underlying base token which serves as collateral). New capital entering the system will always choose whichever system has the most liquidity.

The reason why bitcoin maximalism doesn't make sense is because it isn't turing complete and cannot be upgraded to become it.