A bit more on the economics of Bitcoin

I'm still trying to understand the details of how cryptocurrencies like Bitcoin work. But the general principles involved seem clear enough, so let me start by explaining (what I think) these are. I'll let the experts out there fill in the gaps (and correct any errors I may have made). So what follows is basically an introductory lecture I would deliver to a class on the subject.

This is about the payment system: the way we pay and get paid for things. Any payment system has to solve the following two problems:

    [1] How to transfer credits across accounts in an honest, secure, and reliable manner;
     and
    [2] How to manage the total supply of credits over time.

The earliest (and arguably still most important) payment system relies on informal communal record-keeping. In small communities (villages, networks consisting of close friends, or work colleagues, clubs, etc.) a lot of what gets produced and consumed relies on what one might call "social credit" designed to exploit multilateral gains to trade (even when bilateral gains to trade are absent). In small groups, it is relatively easy for many members of the community to keep track of individual contributions to, and individual withdrawals from, the collective good. I may sometimes ask a favor of a team member even if we both know I have no direct way to return the favor personally. At the same time, I may be asked to deliver a favor to a team member even if we both know he/she has no direct way to return the favor personally. We just do these things because it is in our collective self-interest. In such reciprocal "gift-giving" economies, the currency that facilitates exchange consists of individual reputations (credit histories). If credit histories are easily observed by members of the community, then its difficult to misrepresent or distort your credits, or steal credits from others. If you try to do so, and if you are caught, you may be ostracized from the community, or worse. (

I mention this idea of "communal monitoring" because some form of it seems to play a critical role in the practical application of the Bitcoin protocol.

As a practical matter, the "social credit" system described above seems to work well for small groups, but not so well for larger communities. It's tough to keep track of the individual credit histories of thousands or millions of people, let alone ensure that such records remain a true representation of history. In large communities, many individuals become "anonymous" to one another. Anonymity here means that anything they do in a transient bilateral meeting will not be observed and recorded by the community. That's too bad because efficiency may have dictated that a gift be made in such a meeting. The gift might have been made if the gift-giver received (a social) credit for his/her sacrifice. But if no social credit is forthcoming (because nobody can see it), then the trade does not take place, even though it should have (in an ideal world).

One solution to this problem is monetary exchange. That is, imagine that there exists a set of durable, divisible, portable, recognizable physical object that is hard to steal/counterfeit (the way that reputations need to be hard to steal or counterfeit). Then contributors (workers) could build up credit by accumulating this object, and recipients (consumers) could draw down their credit by spending this object. As it circulates in this manner, this object becomes money. According to this interpretation, money is nothing more than a substitute for the missing (excessively costly) communal record-keeping technology (see Ostory 1973, Townsend 1987, and Kocherlakota 1998).

In a monetary economy, there is no explicit communal monitoring going on. If money is difficult to steal/counterfeit, then the only way I could have acquired it is by working for it (or by having someone else who worked for it bequeath it to me as a gift). When I show up at my local Starbucks and ask for a triple grande latte, they won't hand over my drink until I show evidence my contributions to society. The evidence is in the form of the money that I earned from work. As I hand over my money, I debit my wallet and credit the Starbucks wallet. This transfer of credits involves no intermediary--it is a "self-serve" accounting mechanism.

Of course, many exchanges do take place via intermediaries like banks and clearinghouses. A check drawn on my bank account is an instruction to debit my account and credit another account. The accounts sit on the books of a third party--the intermediary. The money in this case need not even take a physical form -- it can exist simply as a book-entry object. Today, these book-entry objects take the form of electronic digits, and these digits are debited and credited across accounts managed by banks with instructions from debit card technology.

O.K., well suppose that you do not trust the government (or central bank) and their paper money. Suppose you want the convenience of electronic money (so no commodity money). And moreover, suppose you do not want to rely on a third party like a bank. Maybe you don't trust them, or you do not like their fees, or the records of your purchases they keep, or the fact that your identity is associated with your account. What is the alternative?

What we want is some way to replicate the cash experience using electronic digits instead of physical currency. Recall that in bilateral cash transactions, the accounting is done on a self-service basis without the help of the community or some other third party. When it comes to digital money transferred over the internet across a large network of users, self-serve accounting is not likely to be practical. The self-serve part will have to be replaced by some communal monitoring service (obviously not a delegated third party, since this is what we are trying to avoid). I'll try to explain why in a moment, but first let me considered an idealized world where the relevant information is costlessly accessible to all members of the community.

Digital cash with communal record-keeping and communal monetary policy

Digital cash consists of information encoded electronically as bits. For concreteness, let's call digital cash "e-coins" and assume that an e-coin takes the form of a unique N-digit serial number.

[A1] Assume that the serial numbers of every e-coin created are recorded in a public data bank for all to see.

There is an initial money supply (50 bitcoins in the case of the Bitcoin protocol) and a publicly known protocol that governs money creation. In a nutshell, money growth can only occur by "communal consent." In the present context, you can think of monetary policy as a rule for money creation (and distribution), where the rule can only be changed by communal consent.

Members of the community possess "computer wallets" where e-coins are stored in an encrypted file and managed by a computer app (you can download these programs for free). Computer wallets have a public address, like a P.O. box (the identity of the wallet is not known, and a person may own several wallets). So people can send money to your wallet, but only you can extract money from your wallet (only you possess a private digital key for this purpose).

[A2] The e-coin content of every wallet is part of the public database.

So here's how things might work. Suppose a buyer wants to send an e-coin to a seller. Essentially, the buyer sends a message to the community: I wish to send e-coin SN01234 to [seller's wallet address]. A digital signature ensures that this message could only have originated from the buyer's wallet.

[A3] All messages are publicly observable.

 (The italicized sentences above emphasize the assumed information structure. For Bitcoin, there is even more information than this: the entire transaction history of every wallet is part of the public database.)

Now, if every member can costlessly scan and verify every element of the public database, the transaction process should be straightforward. First, the seller can see that the buyer does indeed own e-coin SN01234. Second, by comparing SN01234 to the public database of serial numbers outstanding, the seller can see that SN01234 is unique and was not counterfeited by the buyer. Third, the seller can see that the buyer is not trying to "double spend" SN01234 (e.g., by simultaneously offering it to another merchant's wallet).

The practical problem with this protocol is not that information assumptions [A1]-[A3] are violated. The information is available. There's just so much of it that not everyone can be expected to absorb it all instantaneously. It is time lag that opens the door for scammers. The task of legitimizing, recording, and updating the database has to be delegated in some manner. In the Bitcoin protocol, the task is not delegated to any single third party, rather it is delegated to members of the community who wish to "volunteer" their monitoring services.

Now, the precise details of how this public monitoring and record-keeping is done presently escapes me. The basic idea is that the monitoring activity must be made costly, because otherwise there is an incentive for scammers to announce that their scam deals (e.g., attempts to double spend) are legitimate. In Bitcoin, the monitors (miners) are required to solve a complicated mathematical problem (consumes energy and CPU time), the answer to which is easily verifiable. I think that (somehow) the verification of this answer also verifies the legitimacy of the transaction (someone help me out here).

But if it is costly for miners to verify transactions, what motivates them to do it? There is a reward, of course. In Bitcoin, the reward comes in two forms: newly minted bitcoin and/or service fees. So in the Bitcoin protocol, the verification costs are partly financed via seigniorage. I do not understand the exact mechanics of this process, in particular, the cryptographic techniques involved, and how the parameters are varied over time (for example, to ensure that the supply of bitcoins never exceeds 21 million). Maybe some smart person can explain it to me in plain language. (Here is a good attempt).

Before I leave this part of the discussion, I want to make a remark about the "mining" activity in Bitcoin. A lot of people, including Paul Krugman, appear confused about it. I initially shared in this confusion. Mining actual gold for the purpose of increasing the money supply is indeed socially wasteful. That's because an existing supply of gold can be stretched into an arbitrarily large supply of real money balances via an appropriate deflation. But the mining activity in Bitcoin is not a social waste--it is the cost associated with operating a payment system of this particular form when people have an incentive to cheat. The analog here is the cost associated with opening and maintaining your checking account at a bank.

Is Bitcoin a good money?

One could argue that the USD is at least partially backed by its ability to discharge real tax obligations. But bitcoins truly are purely fiat in nature (they have no intrinsic use in either consumption or production). Does this mean that the value of bitcoins must eventually crash to zero (their fundamental value)? No.

Bitcoins are information -- record-keeping devices. You can't eat my credit history either, but some companies would value (and pay for) this information nevertheless. So as long as Bitcoin conveys accurate information, its value can persist indefinitely. (There is, of course, the threat of entry, though Bitcoin appears to have a substantial early-mover advantage.)

One problem with Bitcoin as a currency is that its purchasing power sometimes fluctuates violently and at high frequency. As I have argued before, a desirable property of a monetary instrument is that it possess a relatively stable short-run rate of return. (A stable long-run rate of return is nice, but not essential, since other assets than money can be utilized as long-term stores of wealth.). Let's take a look at the USD price of bitcoin:


Holy cow. (Wish I had bought in at 5 cents!)

What accounts for this price volatility? (By comparison, the real rate of return on USD over the same period of time was a relatively stable -1% p.a.). Well, it might have something to do with the thinness of the USD/BTC market (can anyone point me to some evidence?). Or it might have something to do with the fact that bitcoin is not a unit of account (even if it is a medium of exchange, prices are usually denominated in USD). Both of these problems might diminish over time as the popularity of the instrument grows.

But my own take on this is that the price volatility reflects the perception that the supply of bitcoins is (relatively) fixed. This, combined with large fluctuations in the demand for bitcoin, naturally results in huge rate of return volatility. We saw the same thing under gold standard monetary regimes (where gold was a unit of account). In principle, an "elastic" supply of currency (even the credible threat of an elastic supply) can be used to offset sudden changes in demand to keep the rate of return (inflation rate) on money relatively stable.

Trust

My colleague, Francois Velde of the Chicago Fed, has a nice primer on Bitcoin. (It delves into the mechanics of the cryptography involved, but I still find many parts of his discussion a little vague.) But in terms of what sort of trust is involved in Bitcoin and similar endeavors, I like what he has to say here:
[B]itcoin protocol is based on open-source software. Bitcoin is what bitcoin users use. The general principles of bitcoin and its early versions are attributed to an otherwise unknown Satoshi Nakamoto; improvements, bug fixes, and repairs have since been carried out by the community of bitcoin users, dominated by a small set of programmers.

Although some of the enthusiasm for bitcoin is driven by a distrust of state-issued currency, it is hard to imagine a world where the main currency is based on an extremely complex code understood by only a few and controlled by even fewer, without accountability, arbitration, or recourse.
 Yes, it's hard to imagine. But maybe it's because we lack imagination? Only time will tell.

GIT: How to have 2 local branch pushing to 2 different remote repositories so that you can merge code

This tutorial will explain how to create 2 local branches with the same code base, each linked to different repository. The purpose is that you can share code between repositories. For example in a multi-module project, it's possible that 1 project will have different implementation depending on the client.

Assumptions:
1.) You have a github account.
2.) You already have 1 project pushed in your account.
3.) You have another empty github project.

Steps:
1.) Add the empty remote repository, name it clone.
2.) Create a local branch name clone -> select checkout new branch.
3.) Push to upstream so that the local branch will be added to the original repository.
4.) Configure clone branch set remote=clone.
5.) Double click clone local branch.
6.) Push to upstream to commit the changes to the empty repository. Go to github and check if the project is properly pushed.
7.) You can now switch between local branch and push to the necessary remote branch.
*Note: The 2 local branch can now be merge

What if you want to delete the remote repository and the clone branch in your original project?
1.) Delete local clone branch, first you mush double click the master branch so the clone branch is not active.
2.) In command prompt go to the first repository's directory and execute: git push origin --delete clone
3.) Delete remote branch

De utrolige pengemaskinene

Vi må ikke la fakta og fornuft ødelegge troen på offentlig eierskap i kraftbransjen. 

Vannkraft er en fantastisk pengemaskin. Det sier seg selv at kraftstasjoner som generer klingende mynt i kassa fra fosser og stryk nesten uten kostnad, må være ekstremt lønnsomt. Marginene innen vannkraft er så rå at det vil være ren idioti å tillate kommuner og fylkeskommuner å selge seg ut av denne eventyrindustrien.

Nå er det jo slik at retten til å hente ut disse marginene har en verdi. Finansmarkedet vil normalt verdsette verdiene slik at avkastningen på vannkraft ikke skiller seg nevneverdig fra andre investeringer.

Vi bør imidlertid ikke godta dette faktumet uten videre. Utgangspunktet er jo at det offentlige bør ha kontroll over alle vannkraftressurser i landet. Da passer det dårlig at vannkraft verken er mer eller mindre lønnsomt enn andre investeringer. I så fall ville det jo gitt langt mer forutsigbare utbytter om kommunene bare solgt vannkraften og satt pengene i mindre risikable indeksfond.

For å få terrenget til å stemme litt bedre med kartet, har jeg derfor tatt med kursutviklingen til de to kraftselskapene som er notert på Oslo Børs.

I figuren ser vi at Arendals Fossekompani har slått børsen! Vi ser også at pengemaskinen Hafslund har tapt i forhold til børsen siden 2003. Her skulle jeg gjerne innvendt at Hafslundkursen ikke er utbyttejustert, men det er den dessverre. Slik sett var det kanskje litt dumt at jeg tok med Hafslund her.





Siden Hafslund-eksemplet avviser teorien om evig pengemaskin, foreslår jeg at vi fokuserer på Arendals Fossekompani. Det som er spesielt med dette selskapet er at det er noe så uvanlig som et privat kraftselskap. Arendals kjøpte fallrettigheter før konsesjonsloven. “Forbudet” mot privat eierskap gjelder derfor ikke for disse kraftstasjonene.

Vi ser at Arendals har slått indeksen, men forskjellen er ikke stor nok til å fastslå om det skyldes tilfeldigheter. Det viktigste er imidlertid at denne observasjonen bekrefter konklusjonen vi ønsker.

Det finnes imidlertid også en del andre plagsomme eksempler på at kraftselskap ikke er pengemaskiner. Lyse Energi har tapt mye på Altibox og oljeinvesteringer. For Nordkraft har urealistiske planer om småkraftutbygging ført til store nedskrivninger. Troms Kraft tapte over 1,5 milliarder på Kraft og Kultur og har ellers vist en imponerende evne til å plukke tapsprosjekter. Hafslund har også tapt store beløp i det siste, blant annet på avfallshåndtering og solenergi.

For at vi ikke helt skal miste fokus på at kraftinvesteringer alltid er lønnsomme vil jeg her påberope irrelevans-argumentet. Disse eksemplene gjelder jo i mange tilfeller offentlig eide kraftselskaper hvor eierne ikke har vært i stand til å utøve godt eierskap. De har derfor overlatt for mye til administratorer som har vært mer opptatt av å bygge imperier enn å utvikle vannkraften.

Dette er jo noe helt annet enn offentlige eide kraftselskaper der driften over tid utvikler seg til en uendelig pengemaskin. Det er jo pengemaskiner vi ønsker, ikke tapssluk. For at konklusjonen vår skal stemme foreslår jeg derfor at vi overser alle disse eksemplene.

Konklusjonen blir dermed som bestilt; vannkraften bør eies og drives av det offentlige. Staten bør fortsatt forby privat eierskap gjennom konsesjonslovgivningen. På den måten sikrer en at tapene finansieres av de velfylte kommunekassene. Det er jo også godt kjent at disse har både evne og vilje til å bære den betydelige finansielle risikoen det er å eie store aksjeposter i enkeltselskap.

How to send and receive STOMP message in JBoss 7.2

The following code is an example of how we can send and receive a stomp message with JBoss 7.2.

package org.meveo.util;

import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;
import java.util.Properties;

import javax.naming.InitialContext;

/**
* @author Edward P. Legaspi
* @since Nov 4, 2013
**/
public class StompUtil {

private static final String END_OF_FRAME = "\u0000";
private static final String USERNAME = "guest";
private static final String PASSWORD = "guest";
private static String HOST = "localhost";
private static String STOMP_VERSION = "1.1";

public static void sendMessage(String destinationQueue, String message)
throws Exception {
sendMessage(STOMP_VERSION, HOST, destinationQueue, USERNAME, PASSWORD,
message);
}

public static void sendMessage(String destinationQueue, String username,
String password, String message) throws Exception {
sendMessage(STOMP_VERSION, HOST, destinationQueue, username, password,
message);
}

public static void sendMessage(String stompVersion, String url,
String destinationQueue, String username, String password,
String message) throws Exception {
if (url != null && !url.isEmpty()) {
HOST = url;
}
// Step 1. Create a TCP socket to connect to the Stomp port
Socket socket = new Socket("localhost", 61613);

// Step 2. Send a CONNECT frame to connect to the server
String connectFrame = "CONNECT\n" + "accept-version:" + stompVersion
+ "\n" + "host:" + HOST + "\n" + "login:" + username + "\n"
+ "passcode:" + password + "\n" + "request-id:1\n" + "\n"
+ END_OF_FRAME;
System.out.println("sending message to queue=" + destinationQueue);
sendFrame(socket, connectFrame);

String response = receiveFrame(socket);
System.out.println("response: " + response);

// Step 3. Send a SEND frame (a Stomp message) to the
// jms.queue.exampleQueue address with a text body
String queueMessage = "SEND\n" + "destination:" + destinationQueue
+ "\n" + "\n" + message + END_OF_FRAME;
sendFrame(socket, queueMessage);
System.out.println("Sent Stomp message: " + message);

// Step 4. Send a DISCONNECT frame to disconnect from the server
String disconnectFrame = "DISCONNECT\n" + "\n" + END_OF_FRAME;
sendFrame(socket, disconnectFrame);

// Step 5. Slose the TCP socket
socket.close();
}

private static void sendFrame(Socket socket, String data) throws Exception {
byte[] bytes = data.getBytes("UTF-8");
OutputStream outputStream = socket.getOutputStream();
for (int i = 0; i < bytes.length; i++) {
outputStream.write(bytes[i]);
}
outputStream.flush();
}

private static String receiveFrame(Socket socket) throws Exception {
InputStream inputStream = socket.getInputStream();
byte[] buffer = new byte[1024];
int size = inputStream.read(buffer);

byte[] data = new byte[size];
System.arraycopy(buffer, 0, data, 0, size);

String frame = new String(data, "UTF-8");
return frame;
}

}
And below is how you would call the utility:
StompUtil.sendMessage("jms.queue.test", "hello world!");
To receive the message
@Inject
@TestQueue
private Queue testQueue;

@Inject
private Connection connection;
//......
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer consumer = session.createConsumer(testQueue);

connection.start();

TextMessage messageReceived = (TextMessage) consumer.receive(5000);
System.out.println("Received JMS message: " + messageReceived.getText());
The producer class
public class Resources {

@Resource(mappedName = "java:/ConnectionFactory")
private ConnectionFactory connectionFactory;

@Resource(mappedName = "queue/test")
@TestQueue
private Queue testQueue;

@Produces
public Connection createConnection() throws JMSException {
return connectionFactory.createConnection();
}

public void closeConnection(@Disposes Connection conn) throws JMSException {
conn.close();
}

@Produces
@TestQueue
public Queue getTestQueue() {
return testQueue;
}

}

Selg Statoil

Professor Øystein Noreng argumenterer i DN onsdag at regjeringen ikke bør selge seg ned i Statoil fordi de vil miste kontroll med selskapet og at hovedkontoret kan bli flyttet.

Med 33 % minoritetsaksjonærer er det ingen politisk kontroll. Selskapet styres ved stemmegivning på generalforsamling. Statoil kan ikke gi særfordeler til staten. Virksomheten skal drives ut fra bedriftsøkonomiske hensyn.

Staten har derfor ikke reel politisk innflytelse. Når overstyrte staten sist ledelsen? Statoil skal drive kommersiell virksomhet, og statens viktigste bidrag er å velge et kompetent styre til å utføre denne jobben.

Det profesjonelle eierskapet har vært lønnsomt for aksjonærene. Mulighetene til politisk styring har imidlertid forsvunnet. Det er ingen kontroll å miste. Noreng har kanskje rett i at “Formålet med selskapet har vært å utvikle norsk sokkel fremfor å tjene penger”, men den tiden er forbi for lenge siden.

I Statoils norske virksomhet finnes det åpenbart mye verdifull kompetanse som ikke kan flyttes. Det er imidlertid liten grunn til våkenetter over at noen få direktører og stabsmedarbeidere kanskje kan få adresse London eller New York. Selskapet vil bli drevet ut fra bedriftsøkonomiske prinsipper uansett.

Forskningen viser at internasjonalt eierskap øker kunnskapsoverførsel og innovasjon, og bidrar til økt verdiskapning. Frykten for utlendinger er forståelig men ubegrunnet. Statoil hadde sett ganske annerledes ut i dag om alle land tenkte på denne måten. Staten tar en enorm risiko ved å eie Statoil. BP-aksjen ble mer enn halvert etter gulfkatastrofen. Selg Statoil og sett pengene i oljefondet.

U.S. Inflation Expectations: Low, But Rising

There's been a lot of talk lately about the threat of global deflation. According to Christine Lagarde, Managing Director of the IMF:
“With inflation running below many central banks’ targets, we see rising risks of deflation, which could prove disastrous for the recovery.”
And closer to home:
Ms Lagarde’s comments were echoed by Charles Evans, president of the Chicago Fed. “The recent news on inflation has not been good,” he said in a speech on Wednesday. “Inflation is too low and is running well below the FOMC’s 2 per cent target.”
Inflation in the U.S. is indeed running below target, but what about inflation expectations? Here are some market-based measures of U.S. inflation expectations (based on TIPS spreads) for two, five, and ten years out:


According to this data, inflation expectations in the second quarter of 2013 declined significantly at all horizons. The sudden jump down in expectations in the summer corresponds with the sudden rise in Treasury yields associated with the so-called "taper tantrum" following the June 19 FOMC meeting.

But it is interesting to note that immediately after the taper tantrum, inflation expectations recovered and stabilized, albeit at low levels (especially at the two and five year horizons). At the same time, nominal yields rose and remain elevated (with the 10 year hovering at or just below 3%).

What is even more interesting the reaction of inflation expectations after the December 2013 FOMC meeting, where the taper was actually implemented (the timing of which came as a surprise to most market participants). Short-run inflation expectations, in particular, appear to be on an upward trajectory. The effect is less evident at longer horizons.

I'm not going to offer any interpretation of what economic forces are at play here (I'll leave it up to you to offer your take on things in the comments section). One thing I can say though is that this data will provide at least a small measure of comfort to Fed policy makers concerned about the threat of deflation.

How to create an xsd and xml data from model entity in java

The following code will show how to generate a xsd base on a given model and a sample xml with data.

Let's assume you have a CustomerList model, which is an array of Customer.

JAXBContext context;
try {
context = JAXBContext.newInstance(CustomerList.class);
context.generateSchema(new SchemaOutputResolver() {
@Override
public Result createOutput(String namespaceURI,
String suggestedFileName) throws IOException {
File file = new File("c://temp//customer.xsd");
StreamResult result = new StreamResult(file);
result.setSystemId(file.toURI().toURL().toString());
return result;
}
});
Marshaller m = context.createMarshaller();
m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
m.marshal(listToExport, new FileOutputStream(
"c://temp//customers.xml"));
} catch (JAXBException e) {
e.printStackTrace();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}

Next is how are we going to read a java object from xml file. Let the code explain :-)
JAXBContext jaxbContext = JAXBContext.newInstance(CustomerList.class);
InputStream is = getClass().getClassLoader().getResourceAsStream(
"customer.xml");
Unmarshaller jaxbUnmarshaller = jaxbContext.createUnmarshaller();
CustomerListmessages = (CustomerList) jaxbUnmarshaller.unmarshal(is);

Useful tool in transforming an xml to xsd:
http://www.freeformatter.com/xsd-generator.html#ad-output

How to create size-rotating-file handler in JBoss 7.2 using CLI

There are times when we require a size-rotating-file handler over the default periodic-rotating-file handler. Simply changing the properties in standalone.xml won't do because it will cause synch problem with logging.properties. So to do so we need to execute a series of JBoss cli commands.

First you need to run: jboss_home/standalone/bin/jboss-cli.sh and connect.


//remove the default file handler
/subsystem=logging/periodic-rotating-file-handler=FILE:remove

//create the new file handler
/subsystem=logging/size-rotating-file-handler=FILE:add(file={"path"=>"server.log", "relative-to"=>"jboss.server.log.dir"})
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="autoflush", value="true")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="level", value="WARN")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="append", value="true")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="max-backup-index", value="10")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="rotate-size", value="5000k")

References:
https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Configure_a_Periodic_Log_Handler_in_the_CLI1.html
https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Sample_XML_Configuration_for_a_Size_Log_Handler.html

What is the OLG model of money good for?

I want to say a few things in response to Brad DeLong's post concerning the usefulness of overlapping generations (OLG) models of money (and on the value of "microfoundations" in general). Let's start with this:
As I say over and over again, forcing your model to have microfoundations when they are the wrong microfoundations is not a progressive but rather a degenerative research program.
Why is he saying this "over and over again" and to whom is he saying it? What if I had said "As I say over and over again, forcing your model to have hand-waving foundations when they are the wrong hand-waving foundations is not a progressive but rather degenerative research program."? That would be silly. And the quoted passage above is just as silly.

A theory usually take the following form: given X, let me explain to you why Y is likely to happen. The "explanation" is something that links X (exogenous variables) to Y (endogenous variables). This link can be represented abstractly as a mapping Y = f(X).

There are many different ways to construct the mapping f. One way is empirical: maybe you have data on X and Y, and you want to estimate f. Another way is to just "wave your hands" and talk informally about the origins and properties of f. Alternatively, you might want to derive f based on a set of assumed behavioral relations. Or, you may want to deduce the properties of f based on a particular algorithm (individual optimization and some equilibrium concept -- the current notion of "microfoundations"). Some brave souls, like my colleague Arthur Robson, try to go even deeper--seeking the biological foundations for preferences, for example.

I don't think we (as a profession) should be religiously wedded to any one methodological approach. Which way to go often depends on the question being asked. Or perhaps a particular method is "forced" because we want to see how far it can be pushed (the outcome is uncertain -- this is the nature of research, after all). And I'm not sure what it means to have the "wrong" microfoundations. (Is it OK to have the wrong "macrofoundations?") Any explanation, whether expressed verbally or mathematically, is based on assumption and abstraction. Something "wrong" can always be found in any approach -- but this is hardly worth saying--let alone saying "over and over again."

Now on to the OLG model of money. Here is DeLong again:
Yes, it seemed to me that handwaving was not good. But saying something precise and false–that we held money because it was the only store of value in a life-cycle context, and intergenerational trade was really important–seemed to me to be vastly inferior to saying something handwavey but true–that holding money allows us to transact not just with those we trust to make good on their vowels but with those whom we do not so trust, and that as a result we can have a very fine-grained and hence very productive division of labor.
Not many people know this, but the OLG model (invented first by Allais, not Samuelson) is just an infinite-horizon version of Wicksell's triangle. The following diagram depicts a dynamic version of the triangle. Adam wants to eat in the morning, but can only produce food at night. Betty wants to eat in the afternoon, but can only produce food in the morning. Charlie wants to eat at night, but can only produce food in the afternoon (assume food is nonstorable).


In the model economy above, there are no bilateral gains to trade (if we were to pair any two individuals, they would not trade). Sometimes this is called a "complete lack of coincidence of wants." There are, however, multilateral gains to trade: everyone would be made better off by producing when they can, and eating when they want to (from each according to their ability, to each according to their need).

Consider an N-period version of the triangle above. Adam still wants bread in period 1, but can only produce bread in period N. Now send N to infinity and interpret Adam as the "initial old" generation (they can only produce bread off into the infinite future). Interpret Betty as the initial young generation (they produce output in period 1, but want to consume in period 2), and so on. Voila: we have the OLG model.

I've always considered Wicksell's triangle a useful starting point for thinking about what might motivate monetary trade (sequential spot market trade involving a swap of goods for an object that circulates widely as an exchange medium). In particular, while there is an absence of coincidence of wants, we can plainly see how this does not matter if people trust each other (a point that DeLong alludes to in the quoted passage above). If trust is lacking--assume, for example, that only Adam is trustworthy--then Adam's IOU (a claim against period N output) can serve as a monetary instrument, permitting intertemporal trade even when trust is in short supply.

An exchange medium is valued in an OLG model for precisely the same reason it is in the Wicksell model or, for that matter, any other model that features a limited commitment friction. So if anyone tries to tell you that the OLG model of money relies on money being the only store of value to facilitate intergenerational trade, you now know they are wrong. The overlapping generation language is metaphorical.

In any case, as it turns out, the foundation of monetary exchange relies on something more than just a lack of trust. A lack of trust is necessary, but not sufficient. As Narayana Kocherlakota has shown (building on the work of Joe Ostroy and Robert Townsend) a lack of record-keeping is also necessary to motivate monetary exchange (since otherwise, credit histories with the threat of punishment for default can support credit exchange even when people do not trust each other).

Also, as I explain here, a lack of coincidence of wants seems neither necessary or sufficient to explain monetary exchange. (Yes, I construct a model where money is necessary even when there are bilateral gains to trade.)

Are any of these results interesting or useful? Well, I find them interesting. And I think the foundations upon which these results are based may prove useful in a variety of contexts. We very often find that policy prescriptions depend on the details. On the other hand, I have nothing against models that simply assume a demand for money. These are models that are designed to address a different set of questions. Sometimes the answers to these questions are sensitive to the assumed microstructure and sometimes they are not. We can't really know beforehand. That's why it's called research.

Finally, is a "rigorous microfoundation" like an OLG (Wicksell) model really necessary to deduce and understand the points made above? I suppose that the answer is no. But then, it's also true that motor vehicles are not necessary for transport. It's just that using them let's you get there a lot faster and more reliably.