Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 17.3K All Categories
- 9.5K Mining
- 573 Pool Discussion
- 374 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 810 Protocol and Client discussion
- 169 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 470 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 225 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 184 Russian
- 230 Spanish
- 47 Turkish
- 125 Watercooler
Let's Automate the Central Bank with Contracts
sl0anage
Member Posts: 13 ✭
Okay so we all can agree in some way, shape, or form that central banks aren't ideal. They are subject to political pressure and a lot of the times are at the whim of the governments that bank with them.
So, Scott Sumner has proposed a way to essentially automate the monetary policy of a central bank through nGDP targeting tied to futures contracts. See http://www.nationalaffairs.com/publications/detail/re-targeting-the-fed
I am not here to argue the ideal monetary policy, more to pose a question to the community of how it could be done with contracts. Let's take nGPD targeting as Sumner suggests as the ideal monetary policy and go from there - economists can argue the rest.
What would this require to be automated:
1) Trustless datafeed of nGPD data. How to do this? Maybe multiple independent collectors of index data, reporting to a contract that fires when 51% of the collectors submitted data are within a threshold of closeness.
2) A way to create these contracts that are bet-able in a sense of accepting a cryptocurrency like Bitcoin and holding them until the datafeed is agreed upon. Once done, the contract is owned by the correct winner who can then offer the contract for sale again.
This requirement is what I'm struggling with right now; if it's thought about in the way of the old classical international gold standard, the central banks could would buy and sell gold at a fixed rate, say $20/oz. These contracts would serve as new gold, and the markets would buy these contracts from the government if they're under-valued and sell them if they're over-valued, keeping the contract prices stable.
In this way, these contracts of nGDP would be valued to grow at 5% per year instead of, in the gold version, be valued as a constant. The "government" would be Distributed Autonomous Organization programmed to buy and sell contracts at a constant 5% growth rate valuation.
3) So much more and I know it. Let's get some discussion going and see if this is even possible!
So, Scott Sumner has proposed a way to essentially automate the monetary policy of a central bank through nGDP targeting tied to futures contracts. See http://www.nationalaffairs.com/publications/detail/re-targeting-the-fed
I am not here to argue the ideal monetary policy, more to pose a question to the community of how it could be done with contracts. Let's take nGPD targeting as Sumner suggests as the ideal monetary policy and go from there - economists can argue the rest.
What would this require to be automated:
1) Trustless datafeed of nGPD data. How to do this? Maybe multiple independent collectors of index data, reporting to a contract that fires when 51% of the collectors submitted data are within a threshold of closeness.
2) A way to create these contracts that are bet-able in a sense of accepting a cryptocurrency like Bitcoin and holding them until the datafeed is agreed upon. Once done, the contract is owned by the correct winner who can then offer the contract for sale again.
This requirement is what I'm struggling with right now; if it's thought about in the way of the old classical international gold standard, the central banks could would buy and sell gold at a fixed rate, say $20/oz. These contracts would serve as new gold, and the markets would buy these contracts from the government if they're under-valued and sell them if they're over-valued, keeping the contract prices stable.
In this way, these contracts of nGDP would be valued to grow at 5% per year instead of, in the gold version, be valued as a constant. The "government" would be Distributed Autonomous Organization programmed to buy and sell contracts at a constant 5% growth rate valuation.
3) So much more and I know it. Let's get some discussion going and see if this is even possible!
Comments
The trustless datafeed is a huge barrier here. How would the contract maintain value if those betting couldn't trust the results of their betting?
Who would back this up? You would have to get a government to agree to buy and sell these lucrative first-of-their-kind contracts at a price that has to be determined.
@sl0anage's idea seems to be similar to what @vitalik talks about in the latest blog posting: http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/
Another possibility is using several independent parties who will commit to publishing a feed. Ideally as many parties as possible, and as independent in their concerns and incentives as possible so that they are less likely to collude. You have a contract that queries as many of these feeds as possible, and will decide that an agreement of a certain # of feeds within some threshold means you are confident about the true nGDP. You also have to consider what your contract will do when it gets no agreement.
Currently the "official" GDP (in the USA) is issued by the Department of Commerce. A more ideal alternative is a system where several expert econometrics organisations with vast measurement capabilities each provide their view of what the nGDP is, and your contract can act upon some derivitive (median, mode, moving average, etc) of those values.
I also want to point out that I believe there are two different definitions of "contract" at play in this thread. Ethereum contracts are bits of code in the blockchain that run when they receive transactions. We're also talking about "futures contracts" which are bets on a future value. We must be careful not to get confused between the two. The only way I can think to buy & sell an ethereum contract would be if the code gave special privileges to some address and there was a mechanism to change that address, then you could buy & sell those privileges.
You can write a contract that maintains a ledger of the bets and then pays them out at settlement time. If you want you can allow the buying and selling of the already registered bets through the registration of the trades through the contract, much like sub-currencies work.
www.frbsf.org/economic-research/files/91-3_3-17.pdf
Basically, it suggests utilizing feedback from velocity of base money and variation from the targeted nGDP to adjust the growth rate of the base money supply.
If we built a coin that grew at a constant rate of 5% and utilized the datafeed with Schellingcoin proposal we could create a base money supply that is growing steadily but will adjust according to nGDP measures.
is that velocity of money is an ideal variable to calculate b/c it's directly determinable from the blockchain.
However, with a zero-fee transaction system this would lead to velocity bloat from market actors sending transactions from personal wallet to personal wallet at no cost.
With a proper fee system, this might successfully allow us to measure velocity since the fees would prevent actors from bogus transactions.
1. I enter into a CFD on the currency at 100x leverage
2. I start sending transactions to myself over and over again, thereby increasing the transaction volume massively. This can theoretically be obfuscated, or I can be maximally open about it while taking care to evade the checks of the algorithm
3. The currency algorithm adjusts supply in some direction as a result. I profit.
That's the big reason why I've been hesitant to use transaction velocity. You can't really set a minimum fee that would deal with the problem, because you can have financial markets with arbitrarily high leverage. Now if we're talking about business cycles then a coin-days-destroyed model could maybe solve the problem, since it can measure short-term deviations but attacks would lose their value after the first time the coins are moved around, but it's still shaky. I would recommend a central bank trying different rules and then phasing out its own control over about thirty years and at least one recession.
The "if we're talking about business cycles" comment was there to separate two types of changes in usage level: changes due to economic factors (such as business cycles) and changes due to the popularity of the currency system relative to other systems (a much larger issue for cryptocurrencies at least in the near term). CDD works well for the former, but poorly for the latter because it stops working once increased volume is sustained for the long term.
If the US federal government was to initialize a new crypto-coin, USCoin, and mandate a free 1:1 exchange ratio of USD - USC then call USCoin the new legal tender, this would give USCoin almost overnight a huge acceptance and usage, eliminating the need to worry about your changes due to popularity concept, right?
http://dormantbitcoin.com/
Edit: forgot link http://bpp.mit.edu/
Considering that ROI here would be thousands of times higher, I suspect whatever anyone comes up with, it'd be mercilessly manipulated and exploited.
Real GDP per person that does not include the FIRE sector (Finance/Insurance/Real Estate) is a lot better, but still a substitute for not otherwise being able to define and measure "happiness per median person".