Bitcoin Forum
April 26, 2024, 07:17:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Securing contingent claims  (Read 7245 times)
johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
June 29, 2011, 01:17:15 AM
Last edit: June 29, 2011, 01:32:56 AM by johanatan
 #21

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?

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
1714159049
Hero Member
*
Offline Offline

Posts: 1714159049

View Profile Personal Message (Offline)

Ignore
1714159049
Reply with quote  #2

1714159049
Report to moderator
1714159049
Hero Member
*
Offline Offline

Posts: 1714159049

View Profile Personal Message (Offline)

Ignore
1714159049
Reply with quote  #2

1714159049
Report to moderator
"In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714159049
Hero Member
*
Offline Offline

Posts: 1714159049

View Profile Personal Message (Offline)

Ignore
1714159049
Reply with quote  #2

1714159049
Report to moderator
1714159049
Hero Member
*
Offline Offline

Posts: 1714159049

View Profile Personal Message (Offline)

Ignore
1714159049
Reply with quote  #2

1714159049
Report to moderator
1714159049
Hero Member
*
Offline Offline

Posts: 1714159049

View Profile Personal Message (Offline)

Ignore
1714159049
Reply with quote  #2

1714159049
Report to moderator
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 29, 2011, 02:46:45 AM
Last edit: June 29, 2011, 03:16:57 AM by cunicula
 #22



  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.

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.


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?

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:

Quote from: cunicula

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.

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.
johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
June 29, 2011, 02:55:21 AM
 #23

 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.
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.
But, different brokers will have different margin requirements.  Surely those won't always be 1:1.

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 29, 2011, 03:27:55 AM
 #24


 
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.
johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
June 29, 2011, 06:09:21 AM
 #25


 
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.
I see.  That does sound like a better system indeed (especially with the borderless nature of bitcoin).

Quote
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'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).

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 29, 2011, 06:48:25 AM
 #26

 
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

johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
June 29, 2011, 07:44:09 PM
 #27

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

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

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:
Quote
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)

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

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
ben-abuya
Sr. Member
****
Offline Offline

Activity: 323
Merit: 250



View Profile WWW
June 29, 2011, 09:24:38 PM
 #28

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.

http://lamassubtc.com/
Lamassu Bitcoin Ventures
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
July 01, 2011, 06:07:18 PM
 #29

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?

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.



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.

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.
johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
July 01, 2011, 06:34:33 PM
 #30

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

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
July 01, 2011, 06:53:41 PM
 #31

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.
johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
July 01, 2011, 07:06:37 PM
 #32

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

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
July 02, 2011, 12:51:47 AM
 #33

Quote from: cunicula link=topic=19130.amsg312094#msg312094 date=1309546421



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

Stability is not an issue. As in the current system, supply per unit time is fixed. Bonds at all maturity dates will sell for a non-zero price. The farther out the maturity date the lower the price. I'm 100% sure of this.

I can only guess about the actual prices. Assuming an interest rate of around 2.5% , then...
0.976 bitcoins for a bond with a face value of 1 bitcoin that matures in one year,  maturing one-year in the future,
0.952 bitcoins for a bond with a face value of 1 bitcoins that matures in two years,
0.48 bitcoins for a bond with a face value of 1 bitcoin that matures in 30 years. 

Approximately (ignoring risk aversion), the price of contingent claims will be the perceived probability of the difficulty level in the range specified by the bond multiplied by the price of the bond.  For example, suppose that the market expects that probability that difficulty falls between 3 and 5 million one year from now is 0.5. Then (using the bond prices above), the price of the associated contingent claim  will be
0.5 * 0.976 = 0.488.




cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
July 02, 2011, 01:21:41 AM
 #34

b
 

How do you propose that pricing be done for the derivative market?  

I think it might be helpful to explain how an electronic market selling bonds and contingent claims would work.
Just like in a regular market, pricing is determined by bids and asks of market participants.

Say the market is for bonds and contingent claims with 1 year maturity. Suppose the bitcoin software is setup to allow four kinds of contingent claims (in reality you would a wider range of possibilities).
The following are some hypothetical highest bids on the market:

Bids
Bond (all difficulty states): 0.975 BTC
Contingent Claim (diffculty <= 1000) : 0.01 BTC
Contingent Claim (100000>=difficulty > 1000) : 0.3 BTC
Contingent Claim (5000000>= difficulty>100000 ) : 0.68 BTC
Contingent Claim (difficulty>5000000 ) :  No existing bids

A bond seller arrives and declares a minimum asking price of 0.97 BTC, what determines the selling price of this bond? Is it broken up into contingent claims or sold in its entirety?

Algortithm compares two possible sales:
1) [divide the bond into contingent claims]
               a) Add up non-zero bids at the entire range of difficulty levels  (in this case 0.01+0.3+0.68=0.99)
               b) return revenue and any unsold contingent claims to the seller
                         (In this case the seller gets 0.99 BTC and a Contingent Claim for (difficulty>5000000 )
2) [sell the bond in one piece]
              a) sell the bond for the highest existing bid (in this case 0.975)
3) If (Revenue (2) > asking price) AND/OR (Revenue (1) >= asking price), then sell bond; otherwise no sale
     a) If Revenue (1) >= Revenue (2) [in this case it is, 0.99>0.975], then sell the bond through method (1)
     b) If Revenue (1) < Revenue (2), then sell the bond through method (2)           
               
In this case the seller earns more from selling the bond as contingent claims (0.99>0.975). Thus, the algorithm would match the seller to the contingent claims bids instead of to the bid for an entire bond.
johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
July 02, 2011, 06:27:37 AM
 #35

I think it might be helpful to explain how an electronic market selling bonds and contingent claims would work.
Just like in a regular market, pricing is determined by bids and asks of market participants.

Say the market is for bonds and contingent claims with 1 year maturity. Suppose the bitcoin software is setup to allow four kinds of contingent claims (in reality you would a wider range of possibilities).
The following are some hypothetical highest bids on the market:

Bids
Bond (all difficulty states): 0.975 BTC
Contingent Claim (diffculty <= 1000) : 0.01 BTC
Contingent Claim (100000>=difficulty > 1000) : 0.3 BTC
Contingent Claim (5000000>= difficulty>100000 ) : 0.68 BTC
Contingent Claim (difficulty>5000000 ) :  No existing bids

A bond seller arrives and declares a minimum asking price of 0.97 BTC, what determines the selling price of this bond? Is it broken up into contingent claims or sold in its entirety?

Algortithm compares two possible sales:
1) [divide the bond into contingent claims]
               a) Add up non-zero bids at the entire range of difficulty levels  (in this case 0.01+0.3+0.68=0.99)
               b) return revenue and any unsold contingent claims to the seller
                         (In this case the seller gets 0.99 BTC and a Contingent Claim for (difficulty>5000000 )
2) [sell the bond in one piece]
              a) sell the bond for the highest existing bid (in this case 0.975)
3) If (Revenue (2) > asking price) AND/OR (Revenue (1) >= asking price), then sell bond; otherwise no sale
     a) If Revenue (1) >= Revenue (2) [in this case it is, 0.99>0.975], then sell the bond through method (1)
     b) If Revenue (1) < Revenue (2), then sell the bond through method (2)           
               
In this case the seller earns more from selling the bond as contingent claims (0.99>0.975). Thus, the algorithm would match the seller to the contingent claims bids instead of to the bid for an entire bond.

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

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
July 02, 2011, 09:17:43 AM
 #36




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.
ben-abuya
Sr. Member
****
Offline Offline

Activity: 323
Merit: 250



View Profile WWW
July 02, 2011, 03:37:47 PM
 #37

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?


http://lamassubtc.com/
Lamassu Bitcoin Ventures
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
July 03, 2011, 08:25:56 PM
 #38


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.
ben-abuya
Sr. Member
****
Offline Offline

Activity: 323
Merit: 250



View Profile WWW
July 03, 2011, 09:45:36 PM
 #39

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

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?


http://lamassubtc.com/
Lamassu Bitcoin Ventures
cunicula (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
July 04, 2011, 04:53:24 AM
 #40

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

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.


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

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.


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




Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!