Topic: [ANN] BitContracts.org (Read 5859 times)

Ok, now i see the light ! )

Ok, i'll rethink what we produced here.

I agree that my super-bot idea is VERY
 hard to implement.
But, maybe still there are some crazy ways to do so with good result)

Sorry for derailing this thread towards
 PM station.
--------------
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 ?

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

1) Linked of course !
I just don't wishing to trust operators,
during the time while bet "trades"
 on the PM.
Risk linked to betting itself is completely fine and OK.

2) I rather trust bot for decision making, than human.
-----
Yes, i want tradeability so badly ...
Worse than Cartmann.
LoL

Can you elaborate more on the rules for such cryptocoin ?

Maybe, if abuse can be made prohibitevly
expensive <-- this will be enough.

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

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.


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.


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.

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.


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.


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.


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


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.

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.


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


Yes, why not.


Perhaps word "consortium" is too heavy-weight

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.


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.

No. If consortium breaches the contract it loses reputation, and reputation = money in this system. Consortium will lose more than it can gain, so it will breach contract only if it wants to hurt users and expense of hurting itself.


There is no supervisor. There is only a public log of all events.

There are two kinds of problems:

1. Consortium does not buy back bonds. This can be detected automatically, so it's rather boring.
2. Even outcome is NO, but consortium acts as if it was YES: it buys YES-bonds and unlocks funds. Of course, a program cannot automatically detect that consortium is lying.

However, it can detect that there is a problem:

1. Different consortia will claim different outcomes for same event, which is weird.
2. Angry users will start a "vote of no confidence" by sending messages to public log.
3. Some reputable external organization will signal an alert.

Finally, the last resort is to read about the problem on forum...

Anyway, user should check the facts himself and ban the consortium if it is misbehaving. So, basically, all sane users will ban this consortium.

Additionally some vote of no confidence can be put into logs so that future users won't trust this consortium either.


Well, even if this scheme works (I really doubt that), it won't be a prediction market, it will be a consensus market.

Event outcome which is more popular will win even if it is factually wrong.

You see, the problem is that users will vote for outcome they bet on since it's simply more profitable. There is no downside, they don't risk anything. Even if there is a stake, you cannot lose by voting for a more popular outcome.

Scheme I've outlined in previous message works because:

1. Consortium does not care about outcome, normally position of each member is balanced. They earn money from fees.
2. Even if consortium tries to cheat, it loses more than it can win due to punishment.

(I think this system is conceptually similar to proof-of-stake, and punishment is absolutely necessary with pure proof-of-stake.)

And if consortium actually tries to cheat, users will be interested to ban it just in case, they aren't interested in helping a cheating consortium.

Risk of getting caught is very high: cheater can win only if almost everybody agrees to support him, and it is a global conspiracy kind of scenario. But potential profit isn't high, so cheating is simply not worth it.

We get to this by isolating financial interest from control in a multi-layered fashion:

1. Users who bet on outcomes have financial interest, but they have no control.
2. Consortium normally has no interest in outcome, but they have some degree of control.
3. Users who can ban consortium and thus have ultimate control do not care about outcome anymore.

Perhaps distributed consensus can be used to make decision to ban a consortium, but it shouldn't affect financial outcome.


Can you please describe this app in more details: how will this bot-escrower work?
How will user interface look like?


Blockchain provides transparency, so checking reserves isn't a problem.

So, decentralized prediction market... Apparently it is possible to make reputation a tradeable commodity (see retep's fidelity bonds).

Entities which possess reputation can issue prediction market bonds in form of colored coins like I outlined here: http://wiki.bitcoinx.org/index.php/PredictionMarketImplementationStrategy

In order to make it more stable, several such entities can form a consortium and put their money into n-of-m escrow. For example, 10 entities might put it into 9-of-10 escrow.

Funds will be unblocked only when they will buy back bonds on market according to the contract. If they don't do that in a timely fashion, their reputation will be lost.

Of course, we need some registry to track exposure of these entities. If one puts 10 BTC into his reputation, he shouldn't be able to issue more than 10 BTC worth of bonds. So whenever entities refer to their reputation, they should sign and publish a message. (Ideally these messages should be collected into something like a blockchain.)

So before one buys prediction market bonds, he should check this registry: Is there any problem with this issuer? Does his reputation cover bonds he have issued?

Furthermore, other reputation systems (something like web of trust, maybe) can be used  to confirm that entity is reputable. Also it matters whether consortium consists of multiple independent entities; or it is just one entity performing a Sybil attack. (Sybil attack is costly in this case, of course, because reputation costs money; but there might be some obscure situation where possible gain exceeds reputation costs...) True consortium is more trustworthy because chances of collusion are lower.

Different issuer consortia can issue colored coins linked to same event (contract), and clients might use them interchangeably.

Similar mechanism can be used to implement something like non-deliverable forwards (which can be used as an replacement for futures).

Yes, otherwise it is called betting service or something like that.


It is possible to make a centralized prediction market service with tradeable contracts without colored coins.
Colored coins simply help (to some extent) with security, anonymity, availability etc.


Well, what do you mean by decentralized? This word has rather vague meaning, or there might be various degrees of decentralization.

Some forms of decentralization are attainable, other aren't. For example, I don't think it can work like p2p file sharing where user doesn't need to care about anything.


I'm not sure about that. We have both centralized and decentralized markets, what percent of users will prefer decentralized ones and why?


Yes.

Well, then it is a bet on a fixed set of outcomes. E.g. if outcome is YES Alice gets money, if outcome is NO Bob gets money.

It is possible to associate a hash with each outcome (e.g. YES-hash, NO-hash), it needs to be done by a service which you use as a data source, then these hashes will be embedded in script.

Eventually data source service will publish either YES-unlock-hash or NO-unlock-hash and this will let Alice or Bob to get their money.

I don't think that bets which cannot be reduced to simple bet on specific outcome can be done with Bitcoin scripts anyway...

I've outlined this hash-based betting process in more detail some time ago, if you're interested I can dig it up.


This isn't possible Bitcoin Script now (it can only verify signature for a transaction), but it is possible to do something like HMAC verification.

It is possible to make a cryptocurrency with a more expressive scripting language, but I still don't see why it would be an improvement: all you can do with it you can do now.

Hmm. What if the algorithm could be contained within the transaction's scriptsig? So, suppose I'm betting on.... who the next pope will be. The contracting parties decide on their authoritative news source (e.g. cnn.com). When the next pope is decided, cnn publishes a page stating "The new pope is Alice"  (yeah, revolution in the church, a female pope!) and they sign that statement with the bitcoin key which was presciently written in the original transaction. Now, since I was betting on Alice becoming pope, I simply download cnn's message and the signature, both of which match the transaction's requirements, construct a transaction with them, and redeem my winnings.

So, this would require the scriptsig to:
a) match the text "the new pope is Alice"
b) verify the signature from cnn

This would remove any subjectivity in the decision - you'd still have to trust your news source, but in any case, the outcome of the contract is defined. The news source *could* be corrupt and publish false news in order to profit.

A nested investment is simple. Let's say you have an 9-of-10 transaction. Within that transaction you could use some of the same keys with a 3-of-4 transaction overlapping. Giving the private key from the smaller transaction to a party with investments in the larger transaction would raise their key holdings in the larger transaction.

Have you seen this: http://wiki.bitcoinx.org/index.php/PredictionMarketImplementationStrategy ?


To be honest I don't even understand a concept of "nested investments"

This post explains why I want to do this and possible use cases: http://www.reddit.com/r/Bitcoin/comments/1a6ewu/ive_been_waiting_for_a_usable_blockchain_escrow/c8ui49g

This post explains how I might do it: https://bitcointalksearch.org/topic/m.1507716 (whole thread might be relevant, by the way).

Possible overlap between colored coins and "escrow": http://wiki.bitcoinx.org/index.php/PredictionMarketImplementationStrategy

I am exploring the possibilities of nesting m-of-n transactions using colored coins as trust levels for rehypothecating funds. I'm not certain about the usefulness of nLockTime other than mitigating trust levels of investment managers. If nLockTime is integral to each investment in an m-of-n transaction, then it could be used to even eliminate the need for trust altogether, leaving investors to classify their nested investments by worth. This concept makes my head explode.

Yes. But on the tech side it might also involve some "smart contracts" features: transaction replacement (emulation), nLockTime etc.


It is more aligned with what BitcoinX does, as smart property can be implemented using colored coin software. But, yes, I want to experiment with this one way or another.


I don't think it is a good model. Outcome can indeed be controlled by algorithms, but it all depends on who will run such algorithms, i.e. you need to trust the service which does this.

I think at this point it is better to run derivative/prediction markets as a service, where service operator will determine which contracts are in demand, will standardize such contracts and will control settlements. BitContracts.org might create software for such prediction market operators, but it won't run anything itself, since running such exchanges involves a lot of risks.

As for flexible custom contracts, that's certainly interesting, but I doubt there is a lot of demand for that, compared to demand for, say, standardized BTC/USD forwards.

But certainly such flexible contracts might align well with business model of a prediction market operator, so there is certainly a possibility that it will be implemented in future.


Oh, I can answer this question . I'm a fan of Lisp family of programming languages, and it is really easy to implement a restricted version of Lisp which will be safe and deterministic (but not Turing-complete). Of course, some things need to be provided as fixed functionality, for example, access to MtGox prices. Letting algorithm to do networking on its own isn't a good idea


Yes, but people already use BTC/USD CFDs and futures.

I presume what you're trying to do is implement a user-friendly interface for implementing M of N transactions (which, I think, is not a trivial task). Are you thinking of going further and investigating an implementation of smart property (http://en.bitcoin.it/wiki/Smart_Property), or at least an interface where smart property contracts can be registered and an API the smart property itself can interact with?

The outcome of some M of N contracts could be actually reduced to algorithms (e.g. betting on the value of MtGox_7day_USD which, I suppose, can be obtained programatically) - would you implement an interface where the writer of the contract can specify the algorithm which decided the outcome? I wonder which type of language that would use. I'd be interested in such a project, but I think it will be quite some time before there would be any real world example of it being necessary. I mean, bitcoin would have to take off before these complex features of bitcoins will be required, I think.

Is it different from 2-of-3 bitcoin script? Is there any front-end (i.e. user interface) to it?


Could you elaborate on this, what C functions?

I was planning to do something along these lines: https://bitcointalksearch.org/topic/m.1507716

Kinda... Reference to vaporware is simply a self-depreciating humor on my side.

Whether it will be vaporware or an actual product depends on many factors, including interest from bitcoin community.