Bitcoin Forum
May 08, 2024, 06:29:10 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: BTC transaction insurance  (Read 976 times)
indio007 (OP)
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
August 07, 2011, 07:57:08 AM
 #1

I set up a sample spreadsheet of a insurance association pool. This will be a cooperative. If there isn't enough money in the pool to cover the highest possible single  claim you can't do that transaction...... unless you get sureties or yourself to make up the difference into an excess risk account. That basically means the more risk you put on the pool the more risk you also assume on yourself.


Naturally to start there is going to have to be a one time membership entrance fee to build the pool.

I have a single goal. To create certainy for the bitcoin sender that he/she won't get stiffed.

Anyway this is just random numbers entered . It is editable.


https://spreadsheets.google.com/spreadsheet/ccc?key=0AlwtyXDQr0s-dEFTbElqeVhfZ01mM0tsd3pzRnp0Z0E&hl=en_US
1715149750
Hero Member
*
Offline Offline

Posts: 1715149750

View Profile Personal Message (Offline)

Ignore
1715149750
Reply with quote  #2

1715149750
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715149750
Hero Member
*
Offline Offline

Posts: 1715149750

View Profile Personal Message (Offline)

Ignore
1715149750
Reply with quote  #2

1715149750
Report to moderator
1715149750
Hero Member
*
Offline Offline

Posts: 1715149750

View Profile Personal Message (Offline)

Ignore
1715149750
Reply with quote  #2

1715149750
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1025



View Profile
August 07, 2011, 08:26:43 AM
 #2

I set up a sample spreadsheet of a insurance association pool. This will be a cooperative. If there isn't enough money in the pool to cover the highest possible single claim you can't do that transaction...... unless you get sureties or yourself to make up the difference into an excess risk account. That basically means the more risk you put on the pool the more risk you also assume on yourself.

Problem number 1 is highlighted.

Problem number 2 is that this will enable bigger scams, for the low, low price of whatever your joining fee is.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
indio007 (OP)
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
August 07, 2011, 09:36:44 AM
Last edit: August 07, 2011, 09:46:54 AM by indio007
 #3

Of course there is going to need to be a bigger buffer. This is just rough math. I placed random numbers in there to see if without fraud the numbers would balance. They do with a 10% buffer. If there is a large period without fraud the pool will grow hopefully making an individual fraud trivial. There is still the problem of creating multiple identities and just keep committing frauds albiet only 90%. of the negotiated price.

The fact is something needs to be worked on to mitigate the risk to the seller of bitcoin.

Also it ain't my fee. The fee goes to the claim pool to create a large enough buffer. I like to think of it as a cooperative.  There would also be quarterly dividends out of the association fee prorated against share of total sales in the event there is 150% left over claims. In the event of catastrophe the association fee can be added to the pool.

All incentives are to be honest. The more honest the group the higher dividend.

Anyhow the numbers can be played with tell they work.

No matter what the person sending bitcoins will not be unjustly enriched. We need to concentrate on the otherside. They need skin in the game.

This is meant for big boys. Not broke bitches that can't put up 16.50BTC for a week while selling a 150 BTC product
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 07, 2011, 10:05:25 AM
Last edit: August 07, 2011, 10:37:25 AM by JoelKatz
 #4

This won't work, at least, not easily. The problem is that the pool will consist of a mix of generally honest people who avoid suspicious deals and people who know that since they have insurance, they can deal with anyone without fear. So even without fraud on the part of pool members, the insurance rate will keep rising as more and more careful dealers leave the pool (because the rates are so high) and more and more careless dealers enter it (because it's worth it to them to pay the higher rate).

It may be possible to make this work, but it won't be easy.

One thing that will help is to only partially insure the transaction and to vet transactions to ensure they are basically a fair deal. (One-sided deals tend to involve scammers on the losing side and people on the winning side who will be happy even with only a partial payout. You don't want that.)

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
indio007 (OP)
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
August 07, 2011, 06:00:33 PM
 #5

Thx for you input. The partial insurance has merit. Maybe the 2 parties pay a higher pool premium if they want more insurance

I slept on what you said. 
Here's a couple ways you can possible mitigate the scenarios you laid out.
1. A risk rating based on completed transactions. Pool premium for an individual transaction is computed based on risk.
2. There is a way to tell if it's the same person creating an account. I can't say what it easy because it can be easily defeated if people knew what the data used for detection is.
3. A higher reserve requirement.



This isn't going to be like escrow. It's going to be more like a portal. The correspondence (and other required evidence over the deal) will happen in the portal . No names of course.

The bottom line is you have to incentivize due diligence on the bitcoin sender side and you have to impute real loss on the bitcoin receiver side in the event of fraud.

There is also the dilemma of collusion between two parties to defraud the insurance. I havn't figured that one out yet.

As I said it's a work in progress. I don't care about making money. I'm a true believer. There has to be a way that eliminates the risk that is transparent, easy to use, timely and fair.

Insurance companies make money hand over fist. I can't imagine we can't do the same with the goal of just paying administration costs.

JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 08, 2011, 02:52:41 AM
 #6

There is also the dilemma of collusion between two parties to defraud the insurance. I havn't figured that one out yet.
That's the biggest problem. I think it's an excellent idea, but it may turn out to be so hard to get it right that it's just not practical.

Quote
There has to be a way that eliminates the risk that is transparent, easy to use, timely and fair.
Insurance companies make money hand over fist. I can't imagine we can't do the same with the goal of just paying administration costs.
Full traceability is their trick. They know everyone's identity and have the ability and willingness to sue people for fraud if needed. That may be part of your solution, but that won't do it completely for you.

I think your biggest problem will be avoiding the rate/risk spiral and keeping the rates low enough that honest people with low-risk transactions are willing to use it. The more the rates go up, the higher the risk that will be needed to justify buying the insirance, which will lead to the rates going up again as all the insured transactions are high risk.

You need to find a way to force diligence on the part of at least one party.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Pages: [1]
  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!