Hacker News new | past | comments | ask | show | jobs | submit login

You are forgetting about an important bit: it isn't an isolated system.

The reasoning you have used could be applied to bitcoins, after all it has no sense it is just people sending bits to each other and wasting computational resources.

Instead look at it this way. There is some people in the economy which want to pay for some services(DDOS) with currency, $. It just happens that those activities are illegal which the new crypto-currency helps to conceal(with respect to those who will punish you) and verify(regarding the contract parties), which is also important because the government won't enforce the contract if you are scammed. Or it brings some value added in other ways such as enhanced privacy, easier transactions... Even if the marginal improvement over existing options is small it serves as a way to bootstrap the value of the new currency.

After a value is reached the market will exchange $ for the new currency until it reaches a settlement price.

You focus was on the supply side, thinking that people won't perform DDOS for some bits in exchange. But there will be a market in which the people on the demand side will be willing to buy those bits which at the same time will give DDOSers a way to convert bits to $. After all nobody would hoard those bits and take them to the grave.

And I know that I still haven't explained how that value can be bootstraped. I will propose you a theory about the bootstrap value. For the first transaction I only need to assume that people are heterogeneous regarding risk aversion and that people can act according to expectations. The person that initially holds those tokens isn't necessarily the person that will use them first in exchange for a DDOS, those tokens can be sold.

A risk-taker client could, based on the total number of tokens and the aggregated value added of the currency(maybe only partially) over the rest of previous currencies, calculate a ratio of tokens to $ as an expectation of its future exchange rate. The estimation of the current value for the current exchange rate would take other factors into account such as liquidity, risk... that will tend to undervalue the new currency until there is more liquidity, certainty... The degree of undervaluation will be equivalent to a discount rate of other assets of similar risk and liquidity. This client would be willing to pay the amount of dollars equivalent to the value a standard service(SER) at the current exchange rate.

Then a risk-taker DDOSer estimating a similar current eschange rate will ask for for the amounts of tokens convertible to the amounts of dollars of a standard service(SER). In order to match those buyers and sellers it isn't necessary to have an exact price. The length bargaining range would be composed by the sum of the value added to the buyer(VA_b) and the value added to the seller(VA_s), and any price on that range will reach settlement.

This creates an interval of settlement prices [SER - VA_s, SER + VA_d] for which the transaction is profitable to both parties. This happens as long as the new currency helps to create value for these parties "VA_d + VA_s > 0"

The only remaining attack is arbitrage. What prevents anyone from forking the currency and creating/attributing bits for/to himself? Once anyone betrays the consensus ledger, the rest of the players will only accept the change and assume the new risk if the reward is greater than the current value of their share in the old branch plus some amount to compensate for the risk. This is clearly unprofitable for the usurper. And if he could make any profit, deceive some them or steal from a minority, what prevents a second round of usurpers from seizing again some value? This could be played to infinity, then the uncertainty would bring down the value of the currency until it crashes to 0.

With respect to other currencies like bitcoin this arbitrage argument could be solved if the new currency creates enough value to offset the risk and costs of switching.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: