[ANN] BitContracts.org

[killerstorm]

BitContracts.org  is a vaporware organization which develops technologies based to advanced features of Bitcoin. Particularly, BitContracts.org is going to utilize multi-signature transactions and basic forms of smart contracts to develop solutions for

• dispute mediation
• instant secure payments
• secure handling of users' funds

and other facilities which fall in a broad category of “escrow”.

Organization will develop open source software and standards, offer consultancy and host services.

In future BitContracts.org might expand its developments into adjacent areas.

Q&A:

How exactly are you going to do that? Plug-ins/add-ons for Bitcoin software (or modified versions), a web service used to communicate... Bitcoin protocol already supports everything, we just need some GUI and a little bit of code for communications and logic.

Is it related to colored coins and smart property? No. There might be some interactions with colored coin technology (e.g. for things which involve both escrow and colored coins), but colored coin software is being developed by BitcoinX.org community, which is completely independent. Some people can work on both projects, of course, but it doesn't mean that projects are same.

What is the source of funding? Currently it is uncertain. Crowdfunding is being considered. Consultancy and service fees might bring in some revenue.

What's about other initiatives and standards for signed invoices, payment protocols etc.? We'll take a pragmatic approach: we will not wait for a standard to be developed, we will aim to offer a complete solution as soon as possible. However, if standard already exist we will use it or interoperate with it. There is always a risk that BitContracts.org's solutions will be considered a ghetto of sorts, in that case we'll try to offer migration.

At this point I just want to see if there is interest. If you think your business/project might use something which is offered by BitContracts.org please comment here or send me PM.

Users are also welcome to comment on this. Do you want deposit solutions which will be actually secure? I.e. so that business won't be able to simply ran away with your money, even if it is hacked? If answer is yes, please post here, ask businesses you interact with to consider this etc.

EDIT: 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://bitcointalk.org/index.php?topic=141536.msg1507716#msg1507716 (whole thread might be relevant, by the way).

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

[1715544862]

1715544862

[fellowtraveler]

FYI, OT is already capable of instant secure payments, and dispute mediation (see escrow smart contract.)

What OT is missing, is "secure handling of users' funds." That is, you would still have to trust the OT issuer who is holding your physical BTC.

The solution for this is to store the BTC in a voting pool (M-of-N) on the blockchain itself.

As you proceed with BitContracts.org, may I ask that your first action be the implementation of a couple of simple C functions for M-of-N blockchain transactions. I know that my own project will start using it right away.

[Spekulatius]

BitContracts.org  is a vaporware organization

?

[markm]

BitContracts.org  is a vaporware organization

?

Whats the problem? Its a vapourware organisation, FT mentioned a specific item of vapourware it'd be nice to have, all good so far...

-MarkM-

[killerstorm]

BitContracts.org  is a vaporware organization

?

That's just my way of saying that I promise nothing at this point and  simply am looking for whether there is an interest. If there is, I'll look into how to organize development process.

Imagine BitContracts.org actually exist and delivers things as advertised. How would you want to interact with it?

[Este Nuno]

BitContracts.org  is a vaporware organization

?

Whats the problem? Its a vapourware organisation, FT mentioned a specific item of vapourware it'd be nice to have, all good so far...

-MarkM-

First three sentences on Wikipedia: "Vaporware is a term in the computer industry that describes a product, typically computer hardware or software, that is announced to the general public but is never actually released nor officially cancelled. Vaporware is also a term sometimes used to describe events that are announced or predicted, never officially cancelled, but never intended to happen. The term also generally applies to a product that is announced months or years before its release, and for which public development details are lacking."

I assume he is using the term in reference to the bolded part of the definition?

[Este Nuno]

Regarding the subject of the post: it's about time something like this gets started. I hope this gets off the ground.

[killerstorm]

I assume he is using the term in reference to the bolded part of the definition?

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.

[killerstorm]

FYI, OT is already capable of instant secure payments, and dispute mediation (see escrow smart contract.)

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

As you proceed with BitContracts.org, may I ask that your first action be the implementation of a couple of simple C functions for M-of-N blockchain transactions. I know that my own project will start using it right away.

Could you elaborate on this, what C functions?

I was planning to do something along these lines: https://bitcointalk.org/index.php?topic=141536.msg1507716#msg1507716

[fergalish]

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.

[killerstorm]

I presume what you're trying to do is implement a user-friendly interface for implementing M of N transactions

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

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?

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.

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

I wonder which type of language that would use.

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

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.

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

[cbeast]

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.

[killerstorm]

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://bitcointalk.org/index.php?topic=141536.msg1507716#msg1507716 (whole thread might be relevant, by the way).

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

[killerstorm]

I am exploring the possibilities of nesting m-of-n transactions using colored coins as trust levels for rehypothecating funds.

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

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.

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

[cbeast]

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

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.

[fergalish]

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

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.

[killerstorm]

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.

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.

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

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.

[killerstorm]

But real prediction market should
 implement tradeable contracts, no !?

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

I know it could be done with CC,
but in a centralised manner.

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.

Can BitContracts help to build
 decentralised prediction  market ?

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.

AFAIK there IS some demand for
 this type of service )

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

Tradeable bets can provide more
 liquidity for prediction market.

Yes.

[killerstorm]

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

[killerstorm]

But we still need to trust the consortium

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.

that entity, which will supervise it.

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.

Though, i thought of escrow in which
 escrow operator is not a human,
but distributed bot ( one part of the bot per client's betting app ).

Bot must be in "consensus" with
 all it's "parts" ( say through PBFT (a la "aardvark" ?) ).

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.

I am not sure : what is easier :
 to build such app( with embedded PBFT bot-escrower )

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

or to convince alleged PM operators
 to have 100% reserves + to prevent corruption and/or collusion in the consortium.

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