Bitcoin Forum

Ex. I mine a Contingent Block today. The Coins in the Contingent Block become a bitcoin Block on August 1st 0:00 UTC or Block xxxx if difficulty is less than X, and disappear otherwise. In the meantime, I can trade the contingent coins on an electronic exchange similar to bitparking. 

Now note that (barring changes to mining tech) difficulty on August 1st [or block xxxx] proxies for the USD/BTC exchange rate on August 1st. The difficulty price relationship will only become stronger over time, once the mining business is more mature. Thus if I trade some bitcoin for some contingent coins, I could remove a considerable fraction (probably the majority) of the variance in the USD value of my BTC holdings as of August 1st. The insurance relies on a p2p system with block chain integrity as the only counterparty. It would be much, much cheaper to use this system for insurance rather than a traditional market which exposes users to counterparty risk.

Difficulty of regular and contingent Blocks can be pegged so that the total number of coins and contingent coins generated at block time t is fixed in all future states of the world. Fixing the generation rate would make contingent claims a scarce resource, i.e. contingent claims would not affect long-term money supply trends. Relative difficulty for each coin type would be adjusted according to a system of linear equations that related past difficulty levels to current difficulty and which incorporated the constraint that expected total supply generation remained constant (i.e. solution of a system of linear equations)

Alternatively, a p2p contracting system could be implemented which allows bitcoins to be held in escrow by a blockchain and then distributes bitcoins at expiration according to difficulty information in the bitcoin block chain. The block chain would need to be secured using a proof of work system that rewarded individuals performing the work with contract fees. Contracts would need to be standardized (for example you can only contract on ln difficulty >= 0, 0.1, 0.2, .... and only on realization on the first day of each month or week). It is important that each side of the contract could be freely traded to other peers, so that holdings in these contracts would remain liquid.

I am not a programmer, so I don't know which type of system would be easier to implement. Combining everything in one blockchain seems more secure.

Either of these systems would make it much easier for merchants to adopt bitcoin without subjecting themselves to large risks or the considerable expense of exchanging BTC for USD after every transaction. The value of bitcoin is inversely proportional to its velocity. If merchants are constantly exchanging BTC for USD after every transaction, the velocity will be high and BTC value will be low. Instead Merchants could hold BTC and a bundle of BTC contingent claims aka BTC derivatives. If unwilling to bear the residual risks, they could purchase supplementary USD-denominated insurance on futures markets. The value of BTC would still be higher because much of the insurance market could be denominated in BTC.

"Bitcoin is technically sophisticated. As a monetary system, it looks primitive." - The Economist
I think this is a correct assessment. If bitcoin doesn't eventually introduce more sophisticated p2p monetary instruments, some other digital currency will. This currency will be much easier for merchants to adopt. If bitcoin hasn't achieved world domination before this happens, bitcoin will disappear and the new currency will take over.

For a simpler proposal for more basic monetary instruments (bonds), see my post here:
http://forum.bitcoin.org/index.php?topic=18288.0

I didn't read the entirety of what you are proposing - I apologize, I will read the whole thing - but just to get some conversation started:

Did you consider the added difficulty of verifying transactions that will result from your proposal?  If your proposal results in transactions that must be followed back to some origin block in order to validate, and that possibly splits along the way, then it will quickly become impossible for bitcoin peers to validate the transaction chain, and the whole system will break down.

Anyone who is proposing any new transaction type in bitcoin needs to understand this factor.  I am not saying that your proposal falls on the wrong side of it, because I have only skimmed it thus far; but after skimming I am inclined to believe that this proposal would result in an unworkable system as the amount of data and operations necessary to validate transactions would be unworkable.

I don't think bitcoin itself will ever intrinsically allow the financial instruments you are talking about.  I also don't think that it is possible to build a sustainable currency system with the properties of bitcoin (pseudo-anonymity of parties engaged in transactions, and distributed authority) that also includes the financial instruments you are talking about, because the cost of incorporating those instruments into the system would mean a greater cost to be paid by the 'miners' in that system that validate transactions.  It is possible that such a system could become self-sustaining but if it did, the cost of every transaction would include the cost of the instruments that you mentioned (because the miners would expect a return that gave them a profit even after paying the cost of verifying those complex instruments, which would require either inflation (always fabricating bitcoins to pay miners) or higher transaction fees.

I guess what I'm saying is, you're talking about a system that has higher transaction fees because it includes these instruments.  Actually now that I've thought through this line of reasoning I realize that maybe your system would work - *if* it were possible for miners to attribute the extra cost of the instruments to the transactions that cause them to incur that cost, and *if* the cost wasn't also passed on to future miners who had to do more work to verify those past transactions without getting any benefit of the original transaction fees.

I'm not a programmer, but I think a few things are relevant. I am thinking of the p2p escrow system rather than the mining system, but the comments are relevant to both.

1) Informational content can be greatly reduced by offering a limited number of standardized contracts. The set could be expanded once information technology improves.
2) If the contracts are tradeable, limited contract variety is not a big deal. (e.g. difficulty drops to a low level on August 1st, the price of a contingent claim paying off on low difficulty Jan 1st will go way up.) So you don't need a large number of maturity dates. Even one contract maturity per year even will accomplish much of the job.
2) Insurance will cost money in this system just like regular insurance. People willing to pay money for insurance will be limited to those dealing in large values of BTC.
Everyone else will prefer to self-insure. This means that the number of transactions will be orders of magnitude smaller than those occurring in the regular bitcoin user base.
3) Because of the different use of these contracts, charging much larger fees for higher data requirements shouldn't be a problem for users.
4) Once contingent claims are transformed into bitcoin the data contained is no longer useful.  I think only outstanding claims would need to be recorded in a block chain. Once these claims were realized (becoming either bitcoin or nothing), data associated with them could be deleted. The ledger would need to contain consistent information on all outstanding claims, but not on claims that had been transformed into bitcoin.

Side note: In the current system, perhaps the txn fee should be indexed so it is inversely proportional to current difficulty rather than adjusted ad hoc.

I wanted to pointed out that the contingent claims market would allow large businesses adopting bitcoins to capture some of the benefits from entry into the economy.
These business would know that announcement of their try would lead to an increase in the future difficulty level. Therefore they would want to place bets on future difficulty increases before announcing their entry.
Existing business would take the other side of these bet to insure themselves against loss.

I don't understand what motivation the existing businesses would have to take the other side of the bet.
Could you please explain?

You need to define what sort of transactions contribute to velocity. For instance, if I take money out of my safe and put it on the table and then put it back in the safe, even if I do this millions of times a second I'm not decreasing its value. I think you'll find that currency conversions also don't contribute.

Could you also please explain what you're trying to achieve with contingent blocks? It looks like an option based on difficulty. What does it enable?

ByteCoin

Thanks for responding. Yeah it is just like options. I'm from an economics rather than a finance background so I use different jargon. Centralized option markets aren't likely to emerge until bitcoin grows big. Volumes in markets you see are likely to small to have much use. Options have a huge payoff variance and there is a big risk that people taking the other side of bets will fail to pay your bets (counterparty risk, remember the financial crisis?). A p2p system could get rid of counterparty risk entirely [except for the integrity of the block chain]. Mining for the contingent claims/options would allow a deep markets to be created despite the small size of the economy. Essentially miners would have to hold them or sell them to someone. No one could fail to pay in bitcoin, even though some people might go belly up in USD.
 
Not sure which side of the trade you are asking about.
1) Going Long
Suppose that you are Amazon and you need to decide to accept bitcoin. Accepting bitcoin means either a) bearing risk by holding bitcoin inventories or b) paying a lot of exchange fees. Either of these options is costly, and I doubt that Amazon's savings on credit card processing fees and chargebacks would be large enough to recoup these costs.

Thus, Amazon needs an alternative way of profiting from bitcoin. Imagine there are two possible future states of the world: State 1) bitcoin value and difficulty increase dramatically, State 2) bitcoin value (and difficulty) do not increase dramatically.   

Amazon could just buy up a whole bunch of vanilla bitcoin before announcing its decision and profiting by reselling the bitcoin later at a higher price. However, this is inefficient. By purchasing standard bitcoin, Amazon is acquiring claims to both future states of the world. Since Amazon's choices can dramatically increase the probability of state 1 occuring, Amazon would earn much more by purchasing claims on state 1 than it would by buying up vanilla bitcoin.

2) Hedging Risks/Going Short
Suppose you are an online casino. Accepting bitcoin means that you Americans will start flooding your site with coins. You need to convert their currency into Euros so they can play with other people on your site.
You will also need to pay them out in bitcoins. This means either a) holding a large bitcoin inventory or b) paying a lot of exchange fees. Holding bitcoin inventories puts you at risk of a large loss if bitcoin drops in value. Thus you would likely to want to exchange claims in State 1 for claims on State 2. If bitcoin goes dramatically up in value, you don't enjoy the rewards. In exchange, you shield yourself from some risk.
 



Standard equation in monetary economics: http://en.wikipedia.org/wiki/Velocity_of_money
Money Supply * Velocity = Currency Price * Real Value of Transactions Per Unit Time

As you can see, velocity is directly proportional to price. Velocity is the rate at which transactions occur per unit time.  Velocity will be high if businesses sell bitcoin as soon as they get it. If businesses are willing to hold bitcoin inventories, some bitcoin is being held of the market and it costs more to acquire bitcoin for exchange purposes.

Hmmm, maybe you need to look into Open Transactions and the financial crypto library that provides for contracts. It can accomodate p2p currencies like bitcoin as a basis.

https://github.com/FellowTraveler/Open-Transactions

Moneychanger could be just what you after.

https://github.com/FellowTraveler/Moneychanger

So which is it? Of course it's neither proportional nor inversely proportional, at best it's loosely correlated.

But your main proposal seems to have merit. Simply said, there would be several "built in" derivatives, denominated in Bitcoin, which could be traded at different prices.

I just believe the complexity could put people off, as it makes Bitcoin even more difficult to understand. Why buy a financial system, if you want a currency? After all the things gone wrong in the traditional financial system, it would increase suspicions.
Also keeping the money supply predictable will be difficult: If an option might expire worthless based on a future difficulty, will it count towards the final 21 million or not?

@noone

Still learning about OpenTransactions (looks cool), but I don't think it is really the same thing. Seems to require banking institutions to make markets for claims. Not sure if OT solves the counterparty risk issue, which is major. Think it would be better to build the financial system in lock step within the currency, rather than waiting for entrepreneur's to build a financial system alongside. If you wait for banking institutions to make deep markets for bitcoin options, you might be waiting for a very long time.


Thanks iya. You are right, my proposal is just the creation of several "built in" derivatives. A few comments:

1) no need to increase complexity for the vast majority of end users. They can just use vanilla bitcoin and forget about the financial system, just like they can forget about the mining system. People who are interested in dealing in contigent claims could download a special GUI.

2) keeping money supply growth constant is not difficult. One simple option is as follows:
          a) issue 1/3 vanilla bitcoin [2 vanilla bitcoin bond blocks per hour]
          b) mine 1/3 as bitcoin bonds which become vanilla bitcoin on June 1st of each year.  [2 June 1st bitcoin bond blocks per hour]
                           (allow these bonds to be broken up into several types of mutually exclusive  contingent claims)
          c) mine 1/3 as bitcoin bonds which become vanilla bitcoin on Jan 1st of each year.   [2 Jan 1st bitcoin bond blocks per hour]
                (these can also be broken up into contingent claims)
Growth of the aggregate money supply is the same as before: 6 blocks per hour. it is just divided among more types of monetary instruments.

3) Derivatives might put average people off. Obviously, I don't agree with this. I think it could be overcome through clever marketing and interface design.

As far as your critique of the velocity equation, you are basically correct. I don't want the discussion to go there because that topic leads to flame wars.

Realizing I screwed up the whole velocity thing. Sorry, please ignore that part; not important to argument.

This is a really neat idea. Bitcoin already has transaction scripting built-in, in fact the regular transactions we know and love are just a special case of this scripting. The thing is, this scripting cannot take the amount of the transaction or things like the difficulty into account. It could, it's just not in the current scripting code. I think adding in some more scripting operations would be all that's needed to make this kind of thing possible. Not hard to code, but a big expansion of how bitcoin works, and that's kind of scary. Again, this could be a variant of bitcoin, like namecoin.

Thanks ben-abuya. I would be so happy to see someone work on this. :D I have a small bounty (25 BTC) to share amongst people who make this alternate chain a reality.

I think it is fairly important that miners can choose which maturity of coins to mine for, and accordingly that each maturity has its own difficulty level. Can this be accomplished with scripting?

cunicula, I like the work you're doing here, although I haven't grasped all the details yet. Are you sure you need miners to selectively mine different maturities and for them to have different difficulties? That would really complicate the system.

I have a proposal for a more generalized prediction market based on the bitcoin concept:

http://forum.bitcoin.org/index.php?topic=10011.0

I am not so sure that this is true.  It assumes that cost per hash is constant.  Event without improvements like CPU to GPU hashing, you are going to face the effects of Moore's law.

@TierNolan

Of course you are completely right. To the extent that Moore's law is perfectly predictable this is not a problem at all. Market participants would factor future difficulty increases when trading.
If there is an unanticipated technological shock (say cheap hashing ASICs appear), then yes it would cause the short-term price-difficulty relationship to change dramatically. On the one hand, the possibility of tech shocks is a downside because they weaken the usefulness of bets on long-run difficulty as insurance against price changes. On the other hand, the development of this market would strengthen incentives for entrepreneurs to build ASICs (see the argument about Amazon). 

@ben-abuya
A fully-backed options/prediction market imposes an implicit tax on transactions in contingent claims. This happens because speculators have to tie up the use of their bitcoin to participate in the market. Accordingly, they have to forgo interest until the predictions are realized. I'll explain in more detail later.

Okay, here is some more detail. The prediction market is still a wonderful idea, but is not anywhere near as efficient as a system for mining bonds.

Suppose I want to make a 100 bitcoin bet on a prediction realized in one year. To back my bet in the prediction/options market, I would need 100 bitcoin bonds with a one year maturity. In the current system, the bitcoin monetary authority doesn't issue bitcoin bonds. Participants are forced to use bitcoin as a substitute for bonds, but using bitcoins to secure a one year bet requires forgoing one year of interest.

Forgone interest can be assessed using the risk free interest rate. The risk free interest rate can be proxied using the yield on US treasury inflation-protected securities (TIPS), currently around ~0.75% per annum for TIPS maturing in 2 or 3 years http://www.treasurydirect.gov/RI/OFNtebnd]. Using this interest rate, I am giving up ~ 0.75 bitcoin for every 100 bitcoin I invest in backing one-year predictions (a 0.75% tax). Because of this tax, the volumes traded on a prediction market fully backed by bitcoin will be much smaller than they would be on a prediction market fully backed by bitcoin bonds.

Given that current exchange fees on bitparking are around 0.4% (counting both sides of the trade), the size of the forgone interest effect on trading volume might be similar to tripling exchange commissions.

Yeah that's true. I still don't totally get the contingent claims stuff, and I can't think of any other way to guarantee a bet. I think this is mitigated by a potentially short term of contract and especially because bitcoin is deflationary. Maybe interest isn't as in important when your coin is deflationary instead of inflationary. How much interest do you expect to get on your savings now? What's the devaluation spread between an inflationary dollar and a deflationary bitcoin? Seems like the remaining interest you'd forego, if any, could be worth the utility of the prediction hedging.

I agree, people will still participate in a prediction market. Even under an implicit tax it is still a good idea. Also I agree that if people expected bitcoin to deflate at the risk-free interest rate + a risk premium, then you would not forgo any interest by holding bitcoin. Remember, however, that inflation/deflation depends on changes in the ratio of volume of bitcoin transactions to the bitcoin money supply. For bitcoin, the serious inflationary risk is a change in transaction volumes/expectations about future transaction volumes, not expansion of the money supply.

BUMP for more comments.

I think it's a great idea.  Seems like an efficient formalization of options/futures rolled into the blockchain itself.  It should help to stabilize price and, as you said, encourage adoption.

EDIT: IIAP and think the contingent block mining would be easier to implement (and it's conceptually simpler).  However, as others have mentioned 'OpenTransactions' already seems to be approaching 'p2p contracts' and that may be objectively better if one is particularly attached to the current blockchain.  IMO, CBM is a bit more elegant (and it allows the miners to get directly involved in predictions and doesn't preclude the additional options/contracts markets from developing around it either).  There is something to be said for leaving a working system alone though and building onto it.

Have you considered what would happen if a significant number of miners enter the contingent market exclusively and guess wrong?  All that hashing power would be lost and the original network would be less secure as a result.  Or are there enough competing interests to balance this out?

One problem with using the existing block chain is that it ties up BTC in escrow. Suppose we want to wager 1 BTC on bitcoin difficulty 1 year in the future. To do this, we would need to hold 1 BTC in escrow for the next year. If on the other hand we loaned out the BTC at a hypothetical risk-free interest rate of 1%, we could earn around 0.01 BTC in interest during this year. Thus, there is something like a 1% annual tax on speculative transactions that use regular bitcoin.

On the other hand, if we a mine a bond that matures in one year, we don't need to forgo any interest to place bets on difficulty when it matures.

A intermediate solution, perhaps the best, is to allow the mining of bonds and then handle the rest using something like open transactions.


I also worry that the system could become unstable (currency generation could balloon or collapse) if everyone made bad guesses. An arrangement that doesn't allow this to happen is described here:


Basically it involves having three difficulty levels, first mining the bonds and then allowing the miners (or anyone else who buys them ) to break them up into contingent claims.
Open Transactions could handle splitting the bonds into contingent claims.

But, different brokers will have different margin requirements.  Surely those won't always be 1:1.

If you allow margin trades, then you reintroduce counterparty risk. My main goal here was to find a trading system
which eliminated counterparty risk and the need for legal or reputational enforcement.

Anyways, there is still a tax on margin requirements because you can't use bonds to back your trade.
As you point out, however, allowing margin trading does reduce the tax.

I see.  That does sound like a better system indeed (especially with the borderless nature of bitcoin).


I'm a bit confused about how your system handles both bonds and 'contingent blocks [aka options/futures]' and the relation between the two (if any).

Great question. There is a very close relationship. First off, I am thinking in terms of zero-coupon bonds (bonds which pay all of their interest at maturity rather than gradually over time).
The most common type of bond pays interest periodically and pays back the principal on maturity. This may be throwing you off.

a BTC Bond - a security which becomes a bitcoin upon reaching its maturity date. (The price of a BTC Bond in BTC will always be less than the bond's face value at maturity. The price discrepancy is interest.)
Contingent Claim - a claim on ownership to a bond which is only valid if difficulty falls within a certain range when the bond matures

A BTC bond can be divided into several contingent claims held by several different owners.
A BTC bond can be recreated from contingent claims by buying up claims to ownership over the entire possible range of difficulties at maturity [1, infinity].

Maybe an example will help.

Say I hold 1 bitcoin and 1 BTC bond with a maturity date of Jan 1, 2012.
Right now my wallet reads:
BTC                                       : 1
BTC Bond (maturity Jan 1, 2012) : 1

After Jan 1, 2012, the bond will mature and my wallet will read.
BTC                                      : 2

Let's consider dividing this bond up into two contingent claims. Frank starts with 1 BTC. He sends me 0.3 BTC and I send him a contingent claim on my BTC bond. If difficulty is greater than 5,000,000 Jan, 2012, he gets ownership of the bond; otherwise I get ownership.

My wallet now reads:
BTC                                                                          : 1.3
BTC Bond (maturity Jan 1, 2012; difficulty <= 5 million)      : 1
BTC Bond (maturity Jan 1, 2012; difficulty > 5 million)        : 0

Frank's wallet now reads:

BTC                                                                          : 0.7
BTC Bond (maturity Jan 1, 2012; difficulty <= 5 million)      : 0
BTC Bond (maturity Jan 1, 2012; difficulty > 5 million)        : 1

If on Jan 1, 2012 difficulty > 5 million

my wallet:

BTC : 1.3

Frank's Wallet

BTC : 1.7

If on Jan 1, 2012 difficulty < 5 million

my wallet:

BTC: 2.3

Frank's Wallet:

BTC: 0.7

Yes that was essentially it.  I didn't remember seeing the bond idea in the original post but now I see that it is the underlying instrument for the 'contingent claims'.


Perfect.  Now a few more questions:
How do you propose that pricing be done for the derivative market?  Can the pricing be standardized (i.e., efficient) without the intervention and facilitation of market makers (i.e., isn't pricing in a constant state of flux depending on current bets [supply/demand thereof] and market [or network in this case] conditions)?  Is it possible to back both bonds and contingent claims with the security of the blockchain or will it require p2p contracts?

Maybe I'm getting lost within the concreteness of the ad hoc contract in your example (and so you may have covered this earlier).  If that's the case, my apologies.

EDIT:  Found the answer here:

In this case, I think there needs to be some hard design put into exactly how this system of linear equations is built and adjusted over time.  :-)

Yeah, that last explanation made it all a lot clearer for me. I still have only a partial understanding, and a couple of questions:

1. Mining bitcoins is just a way for the system to get the 21 million bitcoins out into the world. What happens to the bonds and contingent claims when mining rewards go down to 25 and ultimately to 0?

2. I'm still not sure about the ultimate utility of bitcoin bonds vs bets on bitcoin's future value. The drawback of bets is that you have to put up full escrow at the start. But how do bitcoin bonds get around that? Somebody has to guarantee me that if I win the bet I get my full value in bitcoins. You can escrow me a bond worth that value and I'll be guaranteed to get it, but who's guaranteeing that the bond will increase to its face value? If it's built into the bitcoin system, it seems to me that would break the system, because there's no way we can know what a future bitcoin will be worth in current bitcoins, and if we program it in wrong, the system no longer represents reality.

This is the simplest system I can think of. Miners mine only one type of block. Coins in the blocks are evenly divided among 4 coin types. So a miner would get a block of 12.5 current coins, 12.5 maturity date 1 bonds (nearer in future), 12.5 maturity date 2 bonds, 12. 5 maturity date 3 bonds (farther in future). When maturity date 1 arrives, a new maturity date is introduced.

To make this last after mining stops, the txn fee system would need to be changes as well. For example, 1 current coin paid as a txn fee is converted into 0.25 current coins, 0.25 maturity date 1 bonds, 0.25 maturity date 2 bonds, 0.25 maturity date 3 bonds. Since current coins are more valuable, you would need to force this conversion on transaction processors. In this system, current coins would constantly be withdrawn from the system to issue bonds, the current coins would be reintroduced when the bonds mature.




The bitcoin vis bitcoin bond would not have a pegged exchange rate. You would just handle exchange using a system like bit-parking, the exchange rate is just a market price. I don't know what they will be worth either. The market has to figure it out.

Wouldn't the system of linear equations play a big role in regulating the exchange rate between these two (as well as other factors)?  And, do you have a hard design for these and their adjustment over time (they are the most critical component of this idea and it would be good to get those out there so we can do verification).

If you use a simple system in which you just mine for one type of block and the proportions of currencies/bonds in each block are constant, then you only need one difficulty. You can set this difficulty using the current algorithm. No modifications necessary. I could make a hard design which allows multiple mining choices and would need a new algorithm.  I don't think benefits associated with a new algorithm are sufficient to justify added complexity.

In that case, you have to make sure to set the proportions and the maturity dates appropriately.  It would be interesting to run some simulations and see if this is stable (i.e., reaches equilibrium).

b

Okay, so this is back into the realm of 'let the market sort it out'.  I thought you were trying to roll such things into the blockchain by use of some system of linear equations (which adjust prices per difficulty dynamically).  So you may have gotten rid of some inefficiency [or 'tax' as you put it] in the first order, but second, third and higher orders (or degrees) would still be traditional markets (with all their pricing inefficiencies)?

The important thing to me is creating bonds and allowing them to be traded for contingent claims. Inefficiencies associated with letting exchange markets sort out bond pricing (i.e. interest rates) and contingent claim pricing (essentially guesses on the probability of future difficulty states) are not obvious to me. (please point them out so we can discuss)

My sense is that you would prefer mining markets to sort out pricing. To do this you need one difficulty level for each asset type. You can keep each asset's currency generation rate approximately constant by adjusting each asset's difficulty upwards and downwards independently. This is just an independent linear equation for each asset.

(e.g.)
D_i(t)=D_i(t-1)*A_i(t-1)/H_i(t-1) , where:

A_i(t-1) is the generation rate of asset type i during period t-1
H_i(t-1) is the target generation rate of asset type i during period t-1
D_i(t-1) is the difficulty of generating asset type i during period t-1
D_i(t) is the updated difficulty of generating asset type i during period t

An issue is that difficulty doesn't adjust instantaneously. If there is some big market shock, people will switch assets. If you have a large
number of assets, switching could cause wild swings in difficulty rates across adjustment periods. To avoid this, you would need to put in circuit breakers that prevented each asset's difficulty from going up and down too quickly

(e.g. rules like)

D_i(t)=D_i(t-1)*A_i(t-1)/H_i(t-1) if 2*D_i(t-1) > D_i(t-1)*A_i(t-1)/H_i(t-1) > 0.5*D_i(t-1)
        =2*D_i(t-1)                    if  2*D_i(t-1) <= D_i(t-1)*A_i(t-1)/H_i(t-1)
        =0.5*D_i(t-1)                    if  0.5*D_i(t-1) >= D_i(t-1)*A_i(t-1)/H_i(t-1)

I think a system like this would work. The system could allow for the mining of just bonds (small number of assets), or mining directly for contingent claims (large number of assets). However, I also think that allowing exchange markets to sort out pricing would work. Allowing exchanges to do the pricing work would be much simpler to implement. To me, it makes the most sense to start with a simple system which is easy to implement. If that works stick with it. If it has serious problems, then add complexity later.

I'm just throwing something out here. This is based on cunicula's responses, but I think it's framed a little differently.

Assume you create two new block chains. One is identical to bitcoin except that it can be converted back and forth with matured bitcoin bonds. The other block chain is also the same as bitcoin except that once the coins reach their maturation date, but not before, they can be converted to the other block chain. Conversion means that the coins disappear from one block chain, and appear out of nothing in the second.

Assume that the bonds mature in one year. The difficulty of the first block chain is computed the same as in vanilla bitcoin. The difficulty of the bond chain is computed so that the number of coins in the bond chain is the same as the number of coins in the regular chain one year later, and doing the same difficulty calculations as regular bitcoin. One way of doing this is starting the bond chain one year before the regular chain is started.

After the first day of the new regular chain, there will be about 7,200 matured bond coins from the first day of the bond chain. There will also be about 7,200 vanilla coins from the previous day's mining. These coins will be tradable on an exchange, but there's no need because you can convert them 1:1 yourself with your modified bitcoin client. This will have an anchoring effect on the relative prices. Because the new block chain is equivalent in every way to original bitcoins except for the start date, the added functionality, and the number of miners working on the chain, it's reasonable to expect its coins to trade at some constant to original bitcoins. This anchors the new regular chain's price to bitcoin. The part the market will determine is the price that unmatured bond coins will trade at against new regular bitcoins, and therefore against bitcoins.

Admittedly, I haven't thought this through much, but I think it might shed some light on the subject. This scheme simplifies the mechanisms for me (assuming it's not totally flawed), but it still has the problem that it's dependent on mining for new bonds, and that will go away. I can't think of a way to get around that, while keeping the number of coins the same. I guess that miners could get paid transaction fees in new unmatured bonds, but that would make all the calculations a lot more complicated. Miners would become long term speculators, and this would greatly affect difficulty rates. Maybe it all works out to create a useful instrument, I'm not convinced yet.

I think the main reason I'm skeptical about all this, is that I think debt and credit become much less important in a deflationary world. Maybe they're just essential features in a highly inflationary context. I think the inflationary spread between today's dollar and a stable bitcoin could be as high as 10%, meaning that holding that bitcoin would give you a 10% return on your dollar investment. In a world like that, who needs to buy bonds?

Ben-abuya, it is much too early to be making this point. If the globe permanently adopts bitcoin as its sole currency, from that point on bitcoin would appreciate (deflate) at an annual rate ~equal to the world GDP growth rate. This would also be ~equal to the risk free interest rate. In this world a bitcoin bond would sell at approximately face value (e.g. interest rate = 0.0000000001%). In this world, bonds are useless and you are right.

This is a pretend world. For the forseeable future, bitcoin's value has everything to do with the current value and anticipated future value of transactions conducted in bitcoin. This can go up and down a lot.

To provide some evidence for this (admittedly weak), I created a poll:
http://forum.bitcoin.org/index.php?topic=25705.0

If the interest rate is near 0%, then everyone will answer 0.99 - 1 BTC. I answered 0.95-0.96 BTC [4-5% annual interest]. So far, everyone else demands a lot more interest than I do.

Hmm, I think the poll would have been more interesting if you had asked the opposite: If I loan you 1 BTC now, how many BTC will you be willing to pay me back in a year? I suspect that the values would be quite low. Assume the market interest rate is in fact, 0%. It's possible that that's because nobody is willing to take a loan at any interest rate because they realize they wouldn't be able to pay it back, yet nobody would be willing to provide a loan at 2% since those 2% don't properly reimburse the lender for the lockup of the funds. In essence, there's simply no market for bitcoin loans, just as there's no market for platinum bicycles. Or maybe there is a market, but only for specific uses and not something the general public would be interested in.

Also, any comments on the block chain scheme?

The system you are suggesting is similar to what I have in mind. I was visualizing something like "merging the two blockchains" and disappearence of the maturing chain.  One comment:
It is much better to have just Jan 1st (and maybe June 1st) maturity, rather than maturity one year from the mining date. Making sure that only a few uniform types of bonds are available would bonds much easier to trade.



For the creation of bitcoin bonds, I think the question I asked is the more appropriate one. The bitcoin currency generation process would issue the bonds. The relevant question is how much people would be willing to pay for these bonds. The poll strongly suggests that bitcoin bonds would sell at a significant discount vis-a-vis regular bitcoin. I don't care as much whether people would be willing to issue bonds privately as well. You are suggesting the people aren't willing to issue bonds because of exchange rate risk (I think). Actually, this problem is an important reason for having the currency generation process create the bonds instead. Bonds make it easier to manage repayment of future BTC liabilities. If I am afraid BTC will appreciate, and I need to pay back a debt in one year, then I can start accumulating BTC bonds with a one year maturity. If BTC bonds sell at a discount vis-a-vis regular BTC, then I will save money by doing this. If private individuals cannot bear the risk of issuing ibonds, then the currency issuing authority should (that is the blockchain).




Aside, there already have been private bond issues:
http://forum.bitcoin.org/index.php?topic=18203.msg230632#msg230632
http://forum.bitcoin.org/index.php?topic=5214.40

One possibility would be to have miners able to generate lots of coin fractions as long as all future states are only counted once and then allow those "coins" to be traded.

With a secondary chain, transaction fees could be added as part of the system to create an incentive for miners to mine the chain.

There could be a field in the header that matches a block in the main chain.  This would allow the 2 chains to be kept in sync.

The script could be used to do some kind of verification, but I am not sure how well it could be hardened.

You could make it so that to unlock the coin (in the main chain), you need a sequence of hashes.

Hash(.....Hash(Hash(<some-value>,Hash(<some-value,HASH(<my-address> | bond hash))) is less than <difficulty target>

The script could be setup so that it pays out if that condition is met.

The more hashes, the longer before claims are paid out after maturity, but the harder it is to brute force the system.  Also, if you require all sub-hashes to meet difficulty then it gets even harder to crack (which is what the main chain does).  This hardens the p2p security and can again be done with script.

Hash(<some-value,HASH(<my-address | bond hash>) < difficulty
Hash(<some-value>,Hash(<some-value,HASH(<my-address | bond hash>)) < difficulty
...
...

However, this should not be done for the first few hashes in the unlock code.  This would allow Merkle chains to be formed.

You would submit <my-address | bond hash> to the alternative chain (assuming you were the winner) and it would calculate the unlock code (after a while), while also calculating everyone else's code at the same time.  The <some-values> would be other people's claims.

The miners on the alternative chain should refuse to incorporate invalid <my-address | bond hash> pairs.  At with the main chain, everyone is sharing the processing power of the network.

One disadvantage is that <difficulty target> would need to be selected in advance, when creating the contract, since it has to be hard coded into the unlock script in for the linked transaction in the main chain.  This means that care needs to be taken before adjusting difficulty downwards, since that will mean that chain fails to unlock some of the transactions.

However, if the main chain is anything to go by, a rule that prohibits downward difficulty adjustments shouldn't be an issue.

This sounds great to me. However, I am not a programmer, so it would be great if people with the relevant expertise could weigh in. I can't do much to lead the creation of an alternative blockchain, though I am happy to provide input on the system's design. I am hoping that more people with an interest in this project will come forward.

Interestingly, my poll suggests that the market would demand annual interest rates in excess of 5% for bitcoin bonds with one year maturity.
http://forum.bitcoin.org/index.php?topic=25705.0

The inefficiency associated with the lack of bonds is directly related to the supply curve for credit. If people are willing to supply credit at an interest rate of near 0%, there will be no inefficiency. The higher the interest rate, the larger the inefficiency. The poll suggests that introducing bond (or contingent claim) mining would make bitcoin much more efficient as a financial system.

I didn't read all the post in your article so I might have missed something but my present MultiCoin does support P2P multisign escrow.  but at this time I can't get the Bitcoin group to be a part of it.  I am already testing it in the weeds proto test chain and will fully implement escrow in beertokens when we have decided on a security model of the new block chain.  I think that is what would be needed to start using your dirivitive escrow contract as I might now call it.  You can see more details about my escrow features in my article at: http://forum.bitcoin.org/index.php?topic=24209.0  and as I see you are also looking at models of new possible currency control method what better way than to control your own in a smaller group of more trusted friends or group you have more faith in than a government.  I see the future of a fractionating currency flood that will have to be controled by a group of people not by algorithms in a program that we can't predict the outcome of.  contracts with asset backing will also help to stablelize as long as the assets are in place to support the outcome.

I don't share your views on attempting to manage the coin-beer exchange rate or the use of mining lisences. I would prefer a free float and free entry. Nevertheless, I applaud your initiative in experimenting with alternatives. Experimentation eventually leads to interesting things. I also thing that p2p multisign escrow is a great feature.

I'll summarize an important point that you may have missed.

For long-term p2p escrow to be efficient, tradeable bondcoins are necessary. These are mined securities that are accounted for separately until they reach a specified maturity date. Once the bondcoins mature, they become indistinguishable from regular coins. Bondcoins can be used to back long-term p2p contracts. When long-term p2p contracts are backed with regular coins, contracting parties incur an implicit tax because regular coins do not pay interest while in escrow. Bondcoins, on the other hand continue to pay interest while in escrow. The survey I posted here suggests that the market discounts future payments in bitcoin heavily, and accordingly that the implicit tax associated with forgone interest is substantial (see http://forum.bitcoin.org/index.php?topic=25705.0).

In short, if you introduce p2p escrow it would be extremely useful to introduce tradeable bondcoins as well. The two features complement each other.

Hello, my initial comments in this thread went unresponded to.  So here I am again weeks later to bring the point up again.

I tried to read all of the comments in this thread but I am not an economist and so it would take considerable effort for me to understand all of it, and I don't have the time or inclination for that at the moment.

But I am a programmer and I do understand the technical makeup of the bitcoin protocol reasonably well.

What I want to understand is, what do bitcoin peers (either miners or end-users, they both will need to do this) need to do to validate the transactions that result from your proposal?

Bitcoin transactions reference the outputs of prior transactions and then provide evidence (in the form of script) to prove that the transaction author is allowed to redirect the value of the referenced transaction output to new transaction outputs.  Those new transaction outputs can then be claimed by the next transaction author with the ability to provide evidence (script) to redirect them, and so on.

This means that a peer that wants to validate a transaction simply has to find the referenced prior transaction output in a validated block in the block chain, and check that the value being claimed does not exceed that of the prior transaction's output, and also check that the script of the claiming transaction does prove authorization for redirecting the prior transaction's outputs to new outputs.

Now in your system, what would a transaction that wants to spend bitcoins produced by a contingent claim reference?  What would the rules be for deciding whether the contingent claim produced bitcoins?  Would it be as simple as checking the current time and then checking to see if the difficulty of the current block satisfies the criterion set forth in the contingent claim transaction, and the rejecting the transaction if it's trying to claim bitcoins from a contingent claim transaction that cannot be established as being one that pays out (either due to the contingent claim not having matured yet (i.e. the claiming transaction was written too soon), or due to the contingency not having been satisified (i.e. the contingent claim matured but the difficulty didn't match what was required)?

Also - does your proposal hinge upon the block difficulty being a proxy for bitcoin's value?  If so, what effect does the fact that block difficulty stays artificially fixed for 2 weeks at a time have on your proposal, if any?   And, isn't it likely that block difficulty will eventually track the size of the bitcoin economy rather than the value of individual bitcoins, once bitcoins are no longer generated and miners will mine for transaction fees rather than generated bitcoins?  In that eventuality, miners will make more if there are more transactions (and thus more transaction fees), and so miners will be incented to mine more or less depending upon the total number of transactions occurring, thus the difficulty, which is a function of how much effort is being put into mining, will track the total transaction volume in conjunction with the value of bitcoins.  Will your contingent claims system work when the difficulty is a function of transaction volume combined with bitcoin value?

I think you would always want the transaction to expire to some kind of payment.  The question would be which of the potential owners would get the money.


I think the plan would be for the prediction to be months into the future rather than on a week to week basis.


That won't be true for a while at least, but is a potential issue long term.  It isn't clear how best to generate a reference to real effort.