Difficulty Increase Insurance

[crescendo]

At today time, the insurance of every person is must because this will give the feeling of safe for you and your family. So Insurance is the big point to be noted by the every person, and he must insured himself for him and his family. Insurance risks have great importance.

[1715274585]

1715274585

[1715274585]

1715274585

[alp]

The idea is no one really knows what the difficulty will be in December. 

So you have various levels of X, and they require different contribution shares from each party. 

To define those levels you gave in the example you would need to know the probabilities to start out with. But as you say no one knows those probabilities. And the different contracts would become (un)interesting as new information becomes available and so the community estimate goes up or down. The icbit Dec contract started out at 300M and it last trade was at 484M. This free trading of these future contracts allows the community to bet on the future difficulty without anyone having to guess the probability upfront. It allows the price to reflect news as they become available from the ASIC vendors. And if enough people participate, the efficient market hypothesis predicts that the market value should be a good estimate for the December price. In that case it would not only help miners to hedge but also give them this good estimate as free information. Right now the estimate is probably not very accurate because the volume is low. On the upside, this gives a good opportunity to anyone interested to bet on the difficulty and who think the difficulty will be lower or higher than currently traded.

The market can define those probabilities just like the icbit contract. . . etc.

Intrade anyone?

Intrade is long gone, and would be something Bitcoin could easily be used to replace it.  RIP Intrade.

[Nagle]

I agree, and I have a solution for that issue.  It basically requires the capital to be locked up.  And I can do with a transaction that gets put on the block chain that can only be unlocked by the "winning" party once the difficulty adjusts.  It can proportionally pay out with a little bit of logic different (or even some other calculation other than linear), but right now I'm focusing on all-or-nothing.

Forget "difficulty insurance" and pursue the lockup idea. You're on to something important. Come up with a way to do distributed escrow as a two-phase cryptographic protocol. Something that works like this:

- A sends N locked bitcoins to B to buy something.  A cannot spend those Bitcoins again, but B can't spend them yet.
- A gets whatever B was supposed to send them.
- A unlocks the N locked Bitcoins. B can now spend them.

That's enough for little transactions, up to maybe $10 or so. This is better than "escrow services"; there's no escrow service which can run off with the money. (It happens. Big problem on eBay.) Both sides can lose, with un-spendable Bitcoins in limbo. Since neither side has the money, both sides will probably  try to come to some agreement. Make that work and hook it into some popular shopping cart program.

There's a fancier version, with an arbitrator.

- A sends N locked Bitcoins to B, with an arbitration service listed in the transaction.
- A doesn't get whatever B was supposed to send them.
- A sends a token to the arbitration service requesting arbitration.
- Cases:
   - B sends their token, accepting arbitration.
     - A wins. The arbitration service unlocks the Bitcoins in favor of A.
     - B wins. The arbitration service unlocks the Bitcoins in favor of B.
   - B does nothing, and after some period of time, loses by default.
 
- or
- A fails to unlock the locked Bitcoins they owe to B
- B sends a token to the arbitration service requesting arbitration.
  - cases as above.

A solution has to have the following properties:
- The transaction is anonymous unless submitted to arbitration.
- The unlocking operation is a 2 out of 3 cryptographic protocol.
   A and B can unlock, or A and the arbitrator can unlock, or
   B and the arbitrator can unlock.
- Operations involving an arbitrator have a delay (days to weeks)

That may be overkill, but it would be useful to have it available for larger transactions.  (Like "pre-orders" from Butterfly Labs, perhaps.)

This would make Bitcoin ripoffs much harder, and make the sale of goods using Bitcoins much safer. 

[alp]

I agree, and I have a solution for that issue.  It basically requires the capital to be locked up.  And I can do with a transaction that gets put on the block chain that can only be unlocked by the "winning" party once the difficulty adjusts.  It can proportionally pay out with a little bit of logic different (or even some other calculation other than linear), but right now I'm focusing on all-or-nothing.

Forget "difficulty insurance" and pursue the lockup idea. You're on to something important. Come up with a way to do distributed escrow as a two-phase cryptographic protocol. Something that works like this:

- A sends N locked bitcoins to B to buy something.  A cannot spend those Bitcoins again, but B can't spend them yet.
- A gets whatever B was supposed to send them.
- A unlocks the N locked Bitcoins. B can now spend them.

That's enough for little transactions, up to maybe $10 or so. This is better than "escrow services"; there's no escrow service which can run off with the money. (It happens. Big problem on eBay.) Both sides can lose, with un-spendable Bitcoins in limbo. Since neither side has the money, both sides will probably  try to come to some agreement. Make that work and hook it into some popular shopping cart program.

There's a fancier version, with an arbitrator.

- A sends N locked Bitcoins to B, with an arbitration service listed in the transaction.
- A doesn't get whatever B was supposed to send them.
- A sends a token to the arbitration service requesting arbitration.
- Cases:
   - B sends their token, accepting arbitration.
     - A wins. The arbitration service unlocks the Bitcoins in favor of A.
     - B wins. The arbitration service unlocks the Bitcoins in favor of B.
   - B does nothing, and after some period of time, loses by default.
 
- or
- A fails to unlock the locked Bitcoins they owe to B
- B sends a token to the arbitration service requesting arbitration.
  - cases as above.

A solution has to have the following properties:
- The transaction is anonymous unless submitted to arbitration.
- The unlocking operation is a 2 out of 3 cryptographic protocol.
   A and B can unlock, or A and the arbitrator can unlock, or
   B and the arbitrator can unlock.
- Operations involving an arbitrator have a delay (days to weeks)

That may be overkill, but it would be useful to have it available for larger transactions.  (Like "pre-orders" from Butterfly Labs, perhaps.)

This would make Bitcoin ripoffs much harder, and make the sale of goods using Bitcoins much safer. 

The lockup idea is actually fairly trivially from a technical perspective.  The hard part is the arbitration service actually being able to be trusted and unlocking things.  They need a way to be able to judge.  This likely isn't straightforward, and it's hard to know if that entity can be trusted.  That entity may conspire with the parties to hijack the coins, etc...  Judging these things is also going to be expensive.

That being said, I certainly wouldn't be opposed to doing this.  In the end, it's something I'd like to get more into, and it's a bit more general purpose than I envisioned (I wanted to stick to arbitrating things that are easy to judge, such as difficulty), but it's not impossible.

You may want to see my external state posts for more information on this.  Escrow is one key thing that it can be used for.  I've already gotten the lock-up functionality to work on testnet, so it's just a matter of building it.