Bitcoin Forum
November 16, 2024, 08:51:17 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: [ANN] BitContracts.org  (Read 5887 times)
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
March 14, 2013, 11:44:35 AM
 #21

In some countries ( USA and China for ex. )
 online gambling is illegal.
It will be hard to establish consortium
in such country and even harder for consortium to work with bettors from
 such country.

System is entirely pseudonymous, pseudonyms do not need to be tied to any real world identity.

I'll change terminology a bit... Let's call a person who wants to make money on fees a dealer. To become a dealer, you need to:

1. buy reputation (fidelity bond)
2. in a prediction market app, select events you want to deal on, or create your own clients
3. pledge collateral for dealing on these events
4. app will automatically assemble a group of like-minded dealers who will put their collateral together into n-of-m escrow
5. now they can issue colored coins linked to this event and trade them according to certain rules
6. in the end you need to do a buyback according to rules
7. when buyback is complete a group can unblock their collateral

At no point identification is necessary...

Likewise it isn't for investors who want to bet on events: they are as anonymous as bitcoin allows.

Authorities there will try to destroy
 and/or corrupt consortium ( weakest link in the scheme ), not for sake of profit, but just because they must to do so.

Yes, this is why ideally dealers should assemble into groups not randomly but according to some other reputation system, e.g. bitcoin-otc WoT.

So , in the end we must have SEVERAL
 competing consortiums, or we have not guaranty of its' good behavior.

Yes, why not.

Sounds too complicate for me.

Perhaps word "consortium" is too heavy-weight Smiley

What's about "pledge collateral together with some dudes you might or might not know"? This is essentially what it is about.

Basically if dudes were legit, you earn money from fees. If they are government agents who want to destroy the system at their own expense, you might lose your collateral.

The sole thing, which i wish to solve is
this : "how to handle bettors money
 with minimal risk ( risk -> 0% )
 of improper use of the funds.

You're trying to solve the wrong thing. Prediction makes sense only if payout is linked to outcome.

It is possible to "handle bettors money with minimal risk", but you still need to trust somebody to be an authority on which outcome wins.

If you do not care about tradeability of bets, then it is relatively easy to allow 3rd party to control who gets paid without being able to steal or sabotage the deal.

It is also possible to give control to a group of people. (E.g. m-of-n signatures required to unblock payout according to a certain outcome.)

Problem arises only when we want tradeability, i.e. a proper market... I don't think it is possible to make it 100% safe with Bitcoin, it is only possible to discourage bad behaviour monetarily.

So you'd need a special cryptocurrency with rules designed specifically to make prediction market safe. But in the end you get exactly same problem: cryptocurrencies do not prevent abuse completely, they only make it expensive.

Chromia: a better dapp platform
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
March 14, 2013, 03:40:25 PM
 #22

Oh, no.
the users don't vote for the events
 outcome , but the part of the distributed bot built-in into the
betting app checks news source,
 mentioned in the betting contract.

1. Well, you cannot expect that everybody will run a honest version of software. More likely than not there will be mods which allow user to tweak the outcome however they want.
2. Then news source is in control of payout. And don't forget that news source might bet on unlikely outcome and then rig the payout to profit from it.
3. Thus users will want to be able to override the decision of news source.

Thus either it is equivalent of user voting
OR
you're postulating that users are so honest that they will not try to tweak their clients, and you want to trust news sources.

Coins distribute between players, based on the consensus.

Well if you assume that bots work as advertised, you can simply make a transaction output which requires, says, 66-of-100 signatures and 100 players will put their money into it.

Of course, bot must be isolated ( cryptographically ?) from malicious users vivisecting betting app in order to cheat and steal coins gambled away.

Person who controls hardware program runs on will always be able to influence outputs of such program.

So, basically, you need to run it on a tamper-proof chip, and even then you need to be careful with inputs... and still it all depends on quality of input (i.e. news source), so I don't see the point.

My point was that that the consortium
 will hesitate to have 100% money
reserved (expansive).
They will argue : "Why 100% ?
We a hohest ! Can we have 50% reserve requirements ? Or maybe 20% ?"

This is unlikely to be a problem because competitors can offer 100% reserves and win all the fees.

So, this is a second reason to have
 several consortiums. <- not good,
 cuz of liquidity will divide between
 them.

Client software can treat colored coins issued by different consortia being the same, so liquidity won't be a problem.

This should be a rule for client software: if two consortia issue coins related to same even and both are reputable, then colored coins issued by them are interchangeable. So when you buy YES-bonds client software will look at two orderbooks and pick best offer. End result is exactly the same as if we had one kind of coin and one orderbook.

Chromia: a better dapp platform
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
March 14, 2013, 04:29:27 PM
Last edit: March 14, 2013, 04:43:43 PM by killerstorm
 #23

Ok.
So, consortiums is not entities "in law"
 and there might be situations, when participation in them is risky for
"dudes".
As a potential "dude" i'am scared Wink

If this is a problem, there is a way to remove risk for dealers: make nLockTime'd transaction which releases funds back after some time. Also track buybacks for each dealer personally.

Suppose there is a group of three dealers, say, A, B and C, each dealer puts 10 BTC of collateral into 3-of-3 transaction, with auto-release in a year. A and B are honest and buyback issued coins correctly, but C is a dick who just keeps money. A and B will get their money back, perhaps with some delay, so it causes inconvenience, but no monetary loss. C wins 10 BTC at expense of bettors, but suffers loss of reputation, so it is net loss for him.

Delay means that we isolate potential troublemakers from the market.

2) I rather trust bot for decision making, than human.

Bots are pieces of software designed by humans, which run on hardware maintained by humans, and they consume data which is affected by humans.

So in the end it is safer to assume that there is no bot but user who runs bot algo controls answers it produces.

Can you elaborate more on the rules for such cryptocoin ?

Likely there are many ways to do that, perhaps the simplest one is to follow the scheme with colored coins.

This cryptocurrency should support colored coins natively (such design is sometimes called 'ripplecoin'). Besides normal Bitcoin-like transaction, it needs several additional commands (which can be implemented as Bitcoin-like transactions with commands embedded into output script):

1. register_event(event_hash, yes_bond_color, no_bond_color, ...): register bettable event, assigning colors to yes-bond and no-bond.
2. issue(event_hash): user puts x coins into "escrow" and gets x YES-bond and x NO-bond of colors associated with that event.
3. retire: combining x YES-bonds and x NO-bonds, users can get x coins back from escrow.
4. vote(event_hash, yes/no): opinion on outcome of event.

So user can create a pair of bonds and sell bond he believes isn't true. (E.g. if you think that outcome is YES, sell NO bond.) Then he can either exit early by buying missing bonds on market and retiring them.

Or he can wait until settlement. In that case he needs to submit his vote.

If YES outcome wins the popular vote, YES-bonds can be retired back into coins without requiring NO-bonds.

Now the only problem is that outcome is decided by popular vote, but perhaps there is a way around it, like a reputation system, only users with enough reputation can issue outcome-bonds, reputation can be lost through vote of no confidence etc.

It can't be perfect, of course, but some sort of "checks and balances" might make it good enough. For example, suppose currency itself is proof-of-stake system. Suppose vote over particular event outcome requires supermajority, e.g. 66% of votes. If bond issuers are dicks and vote for a wrong outcome, stakeholders overlords can override their decision. If proof-of-stake overlords are themselves dicks and they have overriden the correct decision, users of cryptocurrency can revolt and choose other stakeholders.

1. Bond issuers' decisions affect betting users.
2. Stakeholders' decision affect bond issuers.
3. Users decisions affect stakeholders.

So in the end this fails only if everybody is acting crazy.


Chromia: a better dapp platform
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
March 14, 2013, 05:28:14 PM
 #24

Speaking of Lisp interpreter embedded
 in (what ?) BitContracts ?
Does this mean you wish to reimplement
cryptocoin in Lisp + some other "external" language from the ground ?
Or i'm delusional here ?

No, I'm talking about a language which can be used for a formal description of contracts.

Programs in this language (i.e. contracts) will be executed by a betting service operator, so there is no need to another cryptocoin.

Trust in this betting service operator is required, of course.

See here: https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state

Chromia: a better dapp platform
Pages: « 1 [2]  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!