Author Topic: Vitalik on stable currencies and POS  (Read 28353 times)

0 Members and 1 Guest are viewing this topic.

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Quote
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.

So, there are two reasons to have multiple blockchains. One is that groups will always disagree, and even within the bounds of turing-completeness there are disagreements. For example, Dan just expressed his interest in having the underlying DB be a graph database instead of a key/value store, as well as having markets be a first-class structure; I think that's silly, and would prefer heaps/treaps/some kind of trees as a first-class structure and nothing else, as markets can be made out of heaps pretty easily and graph DBs can be replicated by key/value stores. Now the legitimate reason to try to make those modifications is, as Dan points out, because there's a choice of what to put at the compiled level and what to put at the interpreted level.

The second reason is scalability/fees. Users looking for a blockchain have three factors to keep in mind when choosing a chain: (i) network effect factors, (ii) security, (iii) costs. Larger chains have higher security and higher network effect factors, but higher costs because more nodes have to process every transaction. Hence, applications which benefit from security and network effects strongly should be on one chain, but apps that are lower-value and independent really should be off by themselves.

Now, our recent research has led us to conclude that scalable multichain/sharding mechanisms exist that allow all blockchains to share security to a high degree (at least for full clients; light client security is a bit more complicated) with a high degree of interop, so the only tradeoff that remains is between network effect and fees. Additionally, note that many kinds of blockchain applications are vulnerable to 51% attacks in ways other than consensus (eg. schellingcoin), so in those cases having any higher degree of shared security is superfluous. I think we'll end up seeing a highly complicated multichain setup where chains follow a power law distribution in size, with dapps that need to talk to each other a lot congregating on a few chains, and things that are mostly standalone being separate, but with inter-chain linkages for communication/trade when needed.

(As another point, at ethereum we generally don't see blockchains as being financial tools exclusively; they're more like decentralized computers that people run services on, and those services probably use tokens in a lot of places but that should not necessarily be an assumption everywhere; hence, "liquidity" is only one kind of network effect, and IMO even one of the less important ones).

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Quote
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.

Offline 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.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Quote
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).

Quote
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.

Quote
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 :)

Quote
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.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: 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.
« Last Edit: December 29, 2014, 02:55:05 am by arhag »

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
...
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.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline speedy

  • Hero Member
  • *****
  • Posts: 1160
    • View Profile
  • BitShares: 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?

Offline arubi

  • Sr. Member
  • ****
  • Posts: 209
    • View Profile
...
1) We assume a trusted price feed exists
...

This is the elephant in the room.

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

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
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.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
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.

Offline 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.   
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
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?

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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.

Quote
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.

Quote
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.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.