0 Members and 1 Guest are viewing this topic.
Why should the MoE and the UoA be screwed (what does "screwed" mean here?) in case of a recession. I assume by recession you mean that the productivity goes down and everyone tries to get hold of the SoV (SoV as Dan described it). Do you mean that the deflation would change prices too much so that the SoV would not fulfill its function as a MoE and a UoA anymore?
The basic macroeconomic reason not to have a fixed-supply asset simultaneously be an store-of-value, medium-of-exchange and unit-of-account is so that if a recession hits and the SoV becomes a safe haven asset you don't have the MoE and UoA getting screwed up as well.
With debt based money price deflation often means the collateral behind the debt is falling in value and that the borrowers will have a harder time earning the money required to pay off the debt.
If you make the currency a “constant purchasing power” then the average man ends up having to make investment decisions he is not qualified to make.
Quote from: vbuterin on January 02, 2015, 01:20:32 pmQuoteThey exclude entire asset classes that have experienced the greatest inflation (stock market)Well, the CPI is supposed to exclude the stock market, that makes sense. The point is to estimate cost of living. Stocks are not a living expense, they are an investment. To put it another way, imagine two parallel universes where in universe A dividends didn't exist and buybacks are used and in B buybacks don't exist and dividends are used. Both universes are libertarian utopias so no tax considerations exist. A and B are economically equivalent as Dan has pointed out many times, but A will have higher stock market rate growth than B, so the stock-market-included CPIs of the two would be different, which makes no sense.I recently reflected on the topic whether asset inflation should be a component of price inflation indexes, and I believe there is a strong case for inclusion. When buying into an ever rising (and substantially rising) stock market the expected long-term investment returns deteorate significantly, compared with a range-bound or slowly rising stock market. This implies that the cost of ensuring decent pension income is rising dramatically for the younger population, who started to invest comparably late. Pension income is going to be high for older folks, who will sooner tend to spend it, therefore creating some upward pressure on consumer prices. Younger folks have to withdraw consumption now, in order to save enough in a low expected return environment, but for them pension savings are definitely a part of their "living expenditures". So, on both fronts - in terms of leading to future upward consumer price pressures, and in terms of representing the current cost of living, asset prices should not be ignored!
QuoteThey exclude entire asset classes that have experienced the greatest inflation (stock market)Well, the CPI is supposed to exclude the stock market, that makes sense. The point is to estimate cost of living. Stocks are not a living expense, they are an investment. To put it another way, imagine two parallel universes where in universe A dividends didn't exist and buybacks are used and in B buybacks don't exist and dividends are used. Both universes are libertarian utopias so no tax considerations exist. A and B are economically equivalent as Dan has pointed out many times, but A will have higher stock market rate growth than B, so the stock-market-included CPIs of the two would be different, which makes no sense.
They exclude entire asset classes that have experienced the greatest inflation (stock market)
They fail to account for economic growth that would normally lead to falling prices
They are fully centralized and lack a consensus process.
t is undesirable because we want the average individual to be able to “invest in the economy” simply by saving the money of the economy without having to take any risks.
http://bytemaster.bitshares.org/article/2015/01/01/How-to-create-a-stable-decentralized-crypto-currency/QuoteBased upon this analysis the goal of BitShares is for BTS to become a global currency in its own right and for the dilution that we experience today to fund development to taper off until we have a fixed supplyrip BTSXThis is no longer a currency, it's shares. Isn't it up to shareholders to decide whether to dilute BTS?
Based upon this analysis the goal of BitShares is for BTS to become a global currency in its own right and for the dilution that we experience today to fund development to taper off until we have a fixed supply
Double negative. Should be, "isn't centralized or stable."
Quote from: fluxer555 on December 31, 2014, 04:24:31 pm2nd Paragraph:"For all practical purposes a the dollar is ..."3rd Paragraph, last sentence:"and can be sold and the market price within 30 days."Also sited -> cited.Pull requested.EDIT: Liked the post, btw.
2nd Paragraph:"For all practical purposes a the dollar is ..."3rd Paragraph, last sentence:"and can be sold and the market price within 30 days."
pegging to a fiat currency isn’t decentralized nor stable.
Quote from: bytemaster on December 31, 2014, 04:12:31 pmhttp://bytemaster.bitshares.org/article/2015/01/01/How-to-create-a-stable-decentralized-crypto-currency/Amazing. This article is from the future.
http://bytemaster.bitshares.org/article/2015/01/01/How-to-create-a-stable-decentralized-crypto-currency/
http://bytemaster.bitshares.org/article/2014/12/31/Stable-Crypto-Currencies-are-Impossible/
Quote from: Pheonike on December 30, 2014, 07:33:54 pmTypo"wealth transfer to miners which waist most of it in the mining process"This reminds us "proof of waist" lol
Typo"wealth transfer to miners which waist most of it in the mining process"
It is also widely accepted among many crypto-currency fans that the FED has failed at their mandate because of persistent rise in prices resulting in the dollar losing 99% of its purchasing power since the FED was founded in 1913
The goal of price stability at its heart is the same as Price Fixing and this is a well known economic fallacy that crypto-currencies should avoid.
Governments around the world are constantly changing how they calculate the basket and what items are included. They will do things like exclude food and energy along with stocks and real estate. John Williams maintains a website called “Shadow Government Statistics”
The idea that any currency could exist and maintain stable purchasing power through a nuclear war is insane.
From the perspective of someone holding a coin, positive and negative interest rate changes are identical to price volatility.
Any approach that provides unlimited liquidity at a fixed price is vulnerable to market manipulation attacks.
Predictable vs Stable... It seems to me that what people really want from a “stable” crypto-currency is reduced volatility.
If we think about the “ideal money” it would be widely accepted with 0% growth in supply.
In my opinion, gold and silver, should be physical money and a crypto-currency should attempt to peg to gold and silver. In this way we can free all of society from the centralized control of fiat currency issuers and keep inflation limited to what gold and silver miners can produce.
First we wait until ethereum is actually out and working. Then copy it if it seems valuable. Then hire their team and reward their shareholders if we feel confident in its future value.
Quote from: Rune on December 30, 2014, 02:01:16 pmQuoteA marketing solution: Ethereum has received major media coverage. It is a more developed brand name than "BitShares". So -- the hypothetical merged system would be called "Ethereum". I could live with this. Ethereum doesn't really make sense as the name of a protocol, but it works great as the name for the overall ecosystem. It's actually an issue I've been thinking about because I think it's so significant that all of bitshares put together forms a single "thing", but this "thing" doesn't really have a name. Usually it's described as "the bitshares ecosystem" or "the bitshares community", but those are not actual names, they just describe it. Bitshares and the blockchain itself is going to become such a huge part of the future that it deserves a proper name like a country or a planet. I was thinking Omega, for the lesswrongesque superintelligence. Ethereum is a nice name too.Yup, let's do this. Where do we start?
QuoteA marketing solution: Ethereum has received major media coverage. It is a more developed brand name than "BitShares". So -- the hypothetical merged system would be called "Ethereum". I could live with this. Ethereum doesn't really make sense as the name of a protocol, but it works great as the name for the overall ecosystem. It's actually an issue I've been thinking about because I think it's so significant that all of bitshares put together forms a single "thing", but this "thing" doesn't really have a name. Usually it's described as "the bitshares ecosystem" or "the bitshares community", but those are not actual names, they just describe it. Bitshares and the blockchain itself is going to become such a huge part of the future that it deserves a proper name like a country or a planet. I was thinking Omega, for the lesswrongesque superintelligence. Ethereum is a nice name too.
A marketing solution: Ethereum has received major media coverage. It is a more developed brand name than "BitShares". So -- the hypothetical merged system would be called "Ethereum".
this summer
BIT-HERIUM or ETH-SHARES?
All cars are basically the same: Mostly they have four wheels, an engine, a steering wheel, brakes, etc. However no one would argue, rationally, that all automotive companies should merge. The diversity of needs and desires of the market supports different approaches to the same problem.The crypto space needs to be the same to avoid dieing to group think. While I don't support the open hostility common between competing crypto technologies the competition for market share is good for everyone.
Quote from: bytemaster on December 29, 2014, 06:52:49 pmQuote from: vbuterin on December 29, 2014, 06:50:24 pmQuote from: bytemaster on December 29, 2014, 06:44:55 pmQuote from: vbuterin on December 29, 2014, 06:41:37 pmQuote from: Rune on December 29, 2014, 04:00:50 pmIf the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchainSo, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/My side change approach has exactly 101 delegates that handle ALL chains. You only have one set of trusted individuals that come to a common consensus. The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other. Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".It wouldn't all have to run on one machine. The technology can scale. The time to sync-up is a "ONE TIME COST". Users don't ever have to download the full chain. My concern with this is that it means that even if it can scale architecturally, you're exposing yourself to a lot of political centralization. Particularly, I predict that if delegates get anywhere near as large as you are suggesting, you'll see the equivalent of "delegate pools": 3-5 large entities that actually maintain and update the state, and then individual delegates that simply point to those entities and that are there basically only as a way of voting on who the revenue should go to. It's possible to set up such a delegate pool that is anonymous to connect to, so delegates would have the incentive to secretly repoint themselves to that pool as they can easily avoid being caught. And if you manage to stop this from happening, then you're creating a large barrier to entry to the delegate industry, to the point where they're not much more decentralized than modern corporations.
Quote from: vbuterin on December 29, 2014, 06:50:24 pmQuote from: bytemaster on December 29, 2014, 06:44:55 pmQuote from: vbuterin on December 29, 2014, 06:41:37 pmQuote from: Rune on December 29, 2014, 04:00:50 pmIf the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchainSo, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/My side change approach has exactly 101 delegates that handle ALL chains. You only have one set of trusted individuals that come to a common consensus. The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other. Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".It wouldn't all have to run on one machine. The technology can scale. The time to sync-up is a "ONE TIME COST". Users don't ever have to download the full chain.
Quote from: bytemaster on December 29, 2014, 06:44:55 pmQuote from: vbuterin on December 29, 2014, 06:41:37 pmQuote from: Rune on December 29, 2014, 04:00:50 pmIf the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchainSo, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/My side change approach has exactly 101 delegates that handle ALL chains. You only have one set of trusted individuals that come to a common consensus. The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other. Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".
Quote from: vbuterin on December 29, 2014, 06:41:37 pmQuote from: Rune on December 29, 2014, 04:00:50 pmIf the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchainSo, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/My side change approach has exactly 101 delegates that handle ALL chains. You only have one set of trusted individuals that come to a common consensus. The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other.
Quote from: Rune on December 29, 2014, 04:00:50 pmIf the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchainSo, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/
If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain
Quote from: onceuponatime on December 29, 2014, 08:00:14 pmQuote from: Rune on December 29, 2014, 07:39:04 pmQuote from: fluxer555 on December 29, 2014, 07:17:39 pmSounds like bytemaster and Vitalaik should duke it out on the next Mumble session Ethereum should just merge with us already Give their community 10-20 100% delegates to pay their developer salary and inflate out stake that they can sharedrop to their ICO investors over time according to some social consensus (since they are a group of stakeholders we definitely want on board!). Then they can help develop whichever multi-blockchain system is best and then make ethereum the BTS blockchain for scripted smart contracts. Everyone wins and every group of stakeholders gain immediate returns from the massive spotlight that will shine on the BTS-Ethereum behemoth (that the ethereum investors can instantly begin to gain liquid shares in from the moment of the announcement).You are not taking into account human egos. Just because something would be more profitable/more efficient doesn't mean that everyone will be able to overcome their needs to be the "winners". Neither Vitalik nor Dan are in sole charge of their projects and so, despite their ability to act rationally, the entire projects may not be able to do so. A marketing solution: Ethereum has received major media coverage. It is a more developed brand name than "BitShares". So -- the hypothetical merged system would be called "Ethereum".
Quote from: Rune on December 29, 2014, 07:39:04 pmQuote from: fluxer555 on December 29, 2014, 07:17:39 pmSounds like bytemaster and Vitalaik should duke it out on the next Mumble session Ethereum should just merge with us already Give their community 10-20 100% delegates to pay their developer salary and inflate out stake that they can sharedrop to their ICO investors over time according to some social consensus (since they are a group of stakeholders we definitely want on board!). Then they can help develop whichever multi-blockchain system is best and then make ethereum the BTS blockchain for scripted smart contracts. Everyone wins and every group of stakeholders gain immediate returns from the massive spotlight that will shine on the BTS-Ethereum behemoth (that the ethereum investors can instantly begin to gain liquid shares in from the moment of the announcement).You are not taking into account human egos. Just because something would be more profitable/more efficient doesn't mean that everyone will be able to overcome their needs to be the "winners". Neither Vitalik nor Dan are in sole charge of their projects and so, despite their ability to act rationally, the entire projects may not be able to do so.
Quote from: fluxer555 on December 29, 2014, 07:17:39 pmSounds like bytemaster and Vitalaik should duke it out on the next Mumble session Ethereum should just merge with us already Give their community 10-20 100% delegates to pay their developer salary and inflate out stake that they can sharedrop to their ICO investors over time according to some social consensus (since they are a group of stakeholders we definitely want on board!). Then they can help develop whichever multi-blockchain system is best and then make ethereum the BTS blockchain for scripted smart contracts. Everyone wins and every group of stakeholders gain immediate returns from the massive spotlight that will shine on the BTS-Ethereum behemoth (that the ethereum investors can instantly begin to gain liquid shares in from the moment of the announcement).
Sounds like bytemaster and Vitalaik should duke it out on the next Mumble session
Quote from: vbuterin on December 29, 2014, 07:11:03 pmQuote from: bytemaster on December 29, 2014, 06:52:49 pmQuote from: vbuterin on December 29, 2014, 06:50:24 pmQuote from: bytemaster on December 29, 2014, 06:44:55 pmQuote from: vbuterin on December 29, 2014, 06:41:37 pmQuote from: Rune on December 29, 2014, 04:00:50 pmIf the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchainSo, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/My side change approach has exactly 101 delegates that handle ALL chains. You only have one set of trusted individuals that come to a common consensus. The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other. Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".It wouldn't all have to run on one machine. The technology can scale. The time to sync-up is a "ONE TIME COST". Users don't ever have to download the full chain. My concern with this is that it means that even if it can scale architecturally, you're exposing yourself to a lot of political centralization. Particularly, I predict that if delegates get anywhere near as large as you are suggesting, you'll see the equivalent of "delegate pools": 3-5 large entities that actually maintain and update the state, and then individual delegates that simply point to those entities and that are there basically only as a way of voting on who the revenue should go to. It's possible to set up such a delegate pool that is anonymous to connect to, so delegates would have the incentive to secretly repoint themselves to that pool as they can easily avoid being caught. And if you manage to stop this from happening, then you're creating a large barrier to entry to the delegate industry, to the point where they're not much more decentralized than modern corporations.Unlike with PoW, stakeholders can actually prevent pools from forming. One of the clearest trends you'll see at the moment is that everyone are very careful with supporting only delegates that are clearly individual people and hosting their delegates seperately (with riverhead I think being the only exception). There will always be more than enough money ready to compensate a delegate whatever amount they need to cover their hosting costs and then some. It's not supposed to become an industry like mining, it's more like the top nodes in a big web of trust. You only ever need to replace delegates if they lose their reputation in the web of trust (which for instance could be by doing something stupid that centralises the network).
Name registries for one. Tracking ownership of smart property devices as well.
You should read up on my research on endogenous estimators here: https://blog.ethereum.org/2014/11/11/search-stable-cryptocurrency/It's actually quite a fun topic.
Sidechains also solve higher fees. You can have more centralized and highly liquid sidechains with low fees, and highly decentralized chains with high fees. This can still all be done with the same basic token.
Why would someone run a non-financial service on a decentralized computer? Seems highly inefficient for everything that doesn't require absolute security and trust.
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.
(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).
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.
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"
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.
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.
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 from: bytemaster on December 23, 2014, 05:56:38 am...1) We assume a trusted price feed exists ...This is the elephant in the room.(It's Oracles all the way down...)
...1) We assume a trusted price feed exists ...
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.
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.
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.
Does he mean that all balances are freely tradeable against each other?
Quote from: arubi on December 28, 2014, 06:36:24 pmQuote from: bytemaster on December 23, 2014, 05:56:38 am...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.
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 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?
[ [short_party, long_party, strike_price, short_margin, long_margin, amount, expiry], [short_party, long_party, strike_price, short_margin, long_margin, amount, expiry],...]
[ [bts holdings, usd holdings (+ or -)], [bts holdings, usd holdings (+ or -)],...]
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?
in schellingdollar, CFDs do not have an explicit counterparty
Quote from: bytemaster on December 23, 2014, 05:56:38 amQuote from: vbuterin on December 23, 2014, 05:19:32 amQuote from: delulo on December 22, 2014, 09:21:06 pmQuote from: vbuterin on December 22, 2014, 09:07:56 pmSo 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 BitUSD4) 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 BitUSDQuestion: 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?
Quote from: vbuterin on December 23, 2014, 05:19:32 amQuote from: delulo on December 22, 2014, 09:21:06 pmQuote from: vbuterin on December 22, 2014, 09:07:56 pmSo 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 BitUSD4) 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.
Quote from: delulo on December 22, 2014, 09:21:06 pmQuote from: vbuterin on December 22, 2014, 09:07:56 pmSo 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/ ?
Quote from: vbuterin on December 22, 2014, 09:07:56 pmSo 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.
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.
Quote from: Shentist on December 22, 2014, 06:53:09 amsounds like Nubits.in this case, i like our approach more.with the difference that Nubits are not bought back/destroyed when in oversupply. They are just hidden
sounds like Nubits.in this case, i like our approach more.
I hope BM keeps up sessions with him, Vitalik is awesome