So I went through "A Note on Cryptocurrency Stabilisation: Seigniorage Shares".   There is a place for these kinds of papers for sure, but there is so much irrelevant information in the paper that it is hard to get a summary of the basic approach.

You can find a summary of the basic approach here: https://blog.ethereum.org/2014/11/11/search-stable-cryptocurrency/

As far as I can tell the paper is close to worthless on useful ideas for stabilizing prices.  And has inspired a new blog topic on the "fallacy of price stability"

Be careful here. A lot of Austrian economists (eg. Mises back when I was reading Human Action) like to make the point that the very concept of price stability is somehow philosophically invalid, which is an absolutely absurd position; even if you cannot use pure logical theory to determine that there is one particular price benchmark that is "correct" and all others are wrong, it is very clear that you can intuitively say that product prices in general go up and down much more when measured in some currencies than in others. But that's not the point you were planning to try to make, looking forward to hearing it.

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

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.

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?

Quote from: vbuterin on December 23, 2014, 05:19:32 am

Quote from: delulo on December 22, 2014, 09:21:06 pm

Quote from: vbuterin on December 22, 2014, 09:07:56 pm

So the price stabilization system that I described in the presentation, Robert Sams' seignorage shares, is a good system, but it's not the system that I personally prefer. The big problem that I see with it is the lack of a stable wind-down option, so if it becomes obvious that the system's influence is only going to decrease over time then the volcoin could easily hyperinflate leading to the stable coins losing all their value. I think that the SchellingDollar approach, which I've described and specified in several places now, ultimately has nicer wind-down properties, although at the cost of its volcoin having much lower crowdsale potential.

Could you give us a run down on how it works in particular in contrast to Bitshares' market pegged assets and where you see the advantages (and disadvantages) of your proposal? - Assuming that the objectives of both systems are (roughly) the same.

Actually, before I can compare schellingdollar to bitshares market pegged assets first I would like to know exactly how bitshares market pegged assets work

Nikolai was kind enough to forward me http://bytemaster.github.io/article/2014/12/18/What-are-BitShares-Market-Pegged-Assets/ but I need a while to digest it; can anyone perhaps make a 5-point summary similar to what I had at https://blog.ethereum.org/2014/11/11/search-stable-cryptocurrency/ ?

1) We assume a trusted price feed exists
2) We assume an asset with no counter party and sufficient market liquidity at a market established price (Bitcoin, BTS)
3) Two parties enter a "contract for difference" on the price feed, the short-side puts up 2x and the long side puts up 1x for a total of 3x held as collateral for issuance of BitUSD
4) The short may cover (burn BitUSD) at any time to gain access to the 3x collateral.
5) The short is forced to cover after 30 days by accepting any and all orders at or above the price feed.
6) The short is forced to cover if the price feed results in the value of collateral being equal to 2x or less the value of the BitUSD.
7) Shorts can only execute at the price feed (no selling BitUSD to 0)
Margin calls only happen at the price feed (no manipulating the internal market to cause a short squeeze)
9) Shorts are matched prioritized by interest rate they are willing to pay.

> Two parties enter a "contract for difference" on the price feed, the short-side puts up 2x and the long side puts up 1x for a total of 3x held as collateral for issuance of BitUSD

Question: suppose that A and B enter a CFD. 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?

If so, that's probably the main difference between your scheme and schellingdollar: in schellingdollar, CFDs do not have an explicit counterparty, and so A's stablecoin/volcoin balance is represented purely as a number pair without reference to anything else. Anyone can enter and leave a CFD against the system at any time. Of course, in this case it's entirely possible for the entire system to have a positive or negative balance of stablecoin, but an adjustable interest rate on stablecoin is used in these cases to encourage marginal holders to switch over so that the balance remains roughly zero.

> Weak subjectivity means relying on friends of core developers to provide checkpoints to avoid Long Range Nothing at Stake attacks.

Correction: that's friends or core developers (or blockchain.info for that matter)

So basically, implementing sidechains to have a shared cross-platform currency?

It's a rather sound idea in principle; sidechains are actually much easier and more scalable to do between two properly designed 2.0 networks than when one of the networks is Bitcoin.

Quote from: vikram on August 19, 2014, 09:09:07 pm

Quote from: tonyk on August 19, 2014, 07:56:41 pm

Quote from: AdamBLevine on August 19, 2014, 07:35:34 pm

I've complained many times about provocative thread titles that mislead people, specifically coming from Bytemaster, since forever. 

Quote from: toast on August 19, 2014, 07:41:03 pm

I agree with Adam here... Dan should know better.

For somebody that posts 75-100 post a day, I refused to post in this thread up to now.  Above is more or less the reason I did so.

http://www.reddit.com/r/ethereum/comments/2e0q0a/bitshares_guy_here_sorry_we_caused_such_a_stir_we/

Good mea culpa, although it seems Vitalik didn't agree quite as much as you thought, more that he was just very open (probably because they are actively seeking solutions and not tied into anything yet)

Or perhaps I just find it more productive to talk about differences, since there's no benefit in preaching to each other's choirs about what we already agree on When I say "my main concerns are", I mean "I'm 75% onboard, we already know about the 75% so here's the remaining 25%". We express our viewpoints, look for differences, expand on those differences, and see how our different approaches can benefit each other; it's a genetic algorithm approach to optimization.

We're both considerably more pro-PoS than the vast majority of the bitcoin community and I do think DPOS is one of the better approaches and does not have glaring incentive incompatibility holes like many of the other algos that are currently in use.