Quote from: TierNolan on July 04, 2011, 10:09:05 AM

Quote from: cunicula on June 29, 2011, 02:46:45 AM

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.

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(,Hash( | bond hash))) is less than

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() < difficulty
Hash(,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 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 would be other people's claims.

The miners on the alternative chain should refuse to incorporate invalid pairs. At with the main chain, everyone is sharing the processing power of the network.

One disadvantage is that 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.