Topic: Securing contingent claims (Read 7293 times)

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.

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 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.

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.

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.

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.

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

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?

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.

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?

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.

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)?

b