It was already demonstrated that technology works, both on Bitcoin testnet and mainnet.

We now want people to try using it by trading something of value. It just not interesting to play with worthless tokens.

(Of course, I wouldn't recommend to try it on something very valuable because technology is not well tested yet and loss is possible.)

The basic idea is same as with smart property: ownership of a certain transaction output ("a coin") is associated with ownership of some property, physical of digital.

Ownership is transferable, i.e. if you send this output to a different address, owner of that address will now own property.

Ownership of an external object is a matter of convention, but this convention can be implemented in software.

Colored coins are a bit more complex, as special rules govern "which goes where" in a transaction which involves multiple inputs and outputs. Generally, it is about a rule of conservation: if 100 red coins go in, 100 red coins should go out, maybe to a different address.

Colored coins can encode quantity of property in transaction output value. Say, issuer declares that 1 satoshi is one share. Then transaction output with 123 satoshi is 123 shares.

In the end, it can look just like stock exchange in terms of user interface (e.g. like http://litecoinglobal.com), but use blockchain for accounting. Also there is a useful property that one can buy colored coin or smart property safely... So market can be decentralized, no need to trust anybody except issuer.

If issuer sells 1000 shares of a company and then simply runs away with money, it can't be helped.

No. ArmoryX is a separate colored-coin-enabled wallet, but it needs access to Satoshi client, i.e. Bitcoin-Qt or bitcoind running on same machine.

Or terracoin-qt/terracoind in case of Terracoin.

At least it worked fine with stock Bitcoin clients...

Motivation. Please understand me correctly, colored coins work fine on Bitcoin, and that's our target. However, the only functional implementation we have now is ArmoryX, it has performance issues. Basically, it requires running bitcoind or Bitcoin-Qt (which means multi-hour blockchain download process and ~10 GB on disk), also it eats about 1.5 GB of RAM... I can't run it on my own laptop!

We'll have a lightweight implementation in about a month, but there is some desire to play with it earlier.

So what I want is to port ArmoryX to Terracoin. It would allow people to play with colored coins without PITA. (testnet doesn't count because testcoins are worthless).

Why Terracoin.

1. Its blockchain size is currently small.
2. Current version is based on Bitcoin 0.8, which means that sync time is fast.
3. Also confirmations are fast, which is nice.

Benefits for Terracoin. Basically you get something like a stock exchange... With free listing. I believe the reason why 'real sector of economy' companies have registered on LTC-GLOBAL is that fee was relatively small.

Possible negative effects. Some people say it might generate lots of transactions and pollute blockchain... But, in any case, there will be approximately zero activity in near future (lots of activity is a nice problem to have), also colored coin transactions are not different from normal trade transactions w.r.t. blockchain usage.

What's required. ArmoryX needs to be updated to work with 0.8 blockchain format. Also it needs to be patched to work with Terracoin. I think it just needs to be pointed to a different genesis block and default ports need to be changed, that's all.

I can do this myself, but I'm too lazy for that. I have some budget to update ArmoryX to a new version (backport changes from newer Armory version), so I can pay somebody to do this.

I estimate that it (updating to 0.8 format) shouldn't take more than a day of coding for an experienced C++ and Python programmer.

Whoever wants to grab this task/bounty please post here or PM me and mention how much money you want for this (separate for 0.8 update and for terracoin support, I need it for accounting reasons).

Actually keeping historic blockchain data isn't even necessary in practice.

Let's assume that UTXO set is referenced from blocks in such a way that block which refers to wrong UTXO set is invalid. This means that it costs a lot of money to make a block with fake UTXO set, basically...

For all practical intents and purposes it is enough to have N latest blocks + UTXO set.

A new node which joins the network can grab UTXO set from a year old block and see if subsequent blocks agree with it.

In a hypothetical scenario where UTXO set is fake, forged by an attacker, attacker is so powerful that he can create 1 year worth of blocks... He clearly dominates the Bitcoin network. He could as well re-create all blocks from start, so it doesn't matter whether we have 1 year worth of full data or full blockchain.

But if such attack is under way, that would mean that Bitcoin is worthless. Thus if it is not worthless, there is no attack, and so it is safe to grab UTXO set and work from there.


It offers practically no advantages at this point, but is considerably harder to implement.

It is like a certificate of authenticity, it is needed only when one sends a transaction. Basically he sends a message: "Here's my transaction: xxx, and here are certificates for all coins involved: yyy".

Person you're sending coins to will need these "certificates" so he can prove authenticity of coins he got too.

And miners need them to decide whether to include it into a block. They will then repackage and optimize "certificates" of each coins involved into a certificate for a block. so other miners can just check whole block without asking anything from the person who send transaction.

There is one caveat, though: people need to update their certificates periodically, otherwise they become stale... In that case one might need a help of a third party to update it. Or DHT with historic data.

In any case, I'm not saying that this protocol is actually worth implementing. But the mere fact that it can exist shows that there is no good reason to limit UTXO set growth.

Also, nothing I mentioned requires state-of-the-art tech... It is literally something a mildly talented undergrad CS student could implement.

Difference, of course, depends on what time frame you consider. Suppose we have currency X and Y which are identical except X block yield 50 coins forever while Y has block reward halving each 4 years.

Let's total amount of X coins divided by total amount of Y coins over time:

after 4 years:    1
after 8 years:    1.33
after 12 years:  1.71
after 16 years:  2.13
after 20 years:  2.58
...
after 100 years:12.5

So what I get from it is that difference isn't that large in first 20 years.

Let's say that you heavily invested in both cryptocurrencies and managed to buy 10% of the monetary base available at 4 year point. (That's like 1 million bitcoins now.)

With currency Y your holding will be diluted to 5.1% of monetary base at 20 year point, which is still pretty respectable.

With currency X you have only 2% of monetary base.

But suppose that currency became widely successful and large portion of world's economy uses it... Both 5.1% and 2% make you filthy rich.

E.g. your net worth might be 1 billion dollars equivalent in one case and 387 million dollars in another... Does it matter?

I'd say the only thing which matters is how successful the currency will become.

Yes, that's where I'm leading to;
but in this post I've simply outlined a protocol which would allow one to take bandwidth/storage trade-off without sacrificing latency too much.

It doesn't require a distributed UTXO/blockchain dataset, I've simply implied existence of such dataset for better introduction.

It's just a protocol which requires users to keep all data required to verify their transactions.

Well, that's just 2^19 records per one of 2^32 humans using Bitcoin... I mean, we are talking about future, right?

Basically, if you own some coins (UTXOs), it is in your interest to keep index records which point to them in your wallet. Then you aren't at mercy of a DHT, you can always prove that you own coins without any external help.

This way all storage costs can be shifted onto users... It's their money, after all.

Haha, sorry, I didn't mean to offend anyone, I'm just somewhat disappointed that people consider only the simplest solutions and do not want to see a bigger picture.

Let's start with an example... Suppose I am a miner who is in kinda exotic situation: I have unlimited computational and networking resources, and enough temporary storage (RAM) to verify blockchain, but local permanent storage is incredibly scarce. But if I want to store something, I can store it externally over network. Say, in a DHT like Freenet, Tahoe-LAFS or something like that.

So I want to download and scan blockchain up to block N just once, then I need to be able to verify validity of any transaction. Is it possible?

Of course. As I go through blockchain I will build an index and will store it in an external DHT. I only need to keep hash of the latest block locally, 32 bytes that is.

Having this hash, I can retrieve things from DHT until I find transaction outputs I need to verify in index I've built. (I do not care whether DHT is secure: if something was tampered with, hashes won't match.)

This is kinda obvious: if secure distributed file systems can exist, then I can simply store data in such file systems instead of a local file system.

But... how much would it cost me to verify a transaction? Well, tree-like datastructures generally have look-up costs on scale of log2 N where N is a number of elements. In the worst case each individual satoshi is an individual UTXO, so we have 21000000*100000000 = 2100000000000000 ~= 2^51 UTXOs. Thus I need something like 51 lookups to find an UTXO in a binary search tree. Or just 9 lookups if I have a 64-ary tree.

But people can argue that 9 lookups per UTXO is a lot... Network latency yada yada. How about zero?

That's possible. Suppose that person which sends transaction knows how I store index in DHT, it isn't secret. To make sure that I'll include his transaction into block, he will fetch all the data I need from DHT himself, and will send me a message with his transaction and all information I need.

I don't need to look up anything in a DHT myself, I only need data which was stored in the message. And this is secure: if data was tampered with, hash won't match.
 
So, basically, number of transactions I can include into a block is limited by my computational and network abilities, but storage capability/cost is irrelephant.

But what's about blocks mined by others? Oh...

Well, it is possible to do 9 DHT lookups per UTXO mentioned in block. Number of outputs is limited, I can do lookups in parallel, so it isn't such a big problem. But still...

You know, miners are friendly guys, how about they all use same DHT, and then include confirmation information together with the block they have just mined?

So I receive a new block and supplementary information which is all what is needed to confirm that block is valid.

In the end, it is possible to do all mining having only 32 bytes of permanent secure storage. It requires somewhat more bandwidth, though. But extra bandwidth costs are approximately proportional to block size. So maybe not a big problem...

E.g. I either need 128 GB of RAM, array of hard drives and 100 MBit/sec pipe. Or I need 1 GB of RAM, no hard drives at all and 1 GBit/sec pipe. Which is cheaper?

So what I'm talking about storage/bandwidth trade-off. Using less storage might increase latency, but possible in such a way that it won't be critical.

Next time I will teach you how to implement a blockchain-based cryptocurrency in such a way that new miners can start mining right away without downloading whole blockchain, stay tuned...

Fast... But where?

Well, suppose we have funding for that, what's the best way to proceed?

Can you point me to a description of the new algo? I don't want to dig through all the source code just to see what's improved.

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

Nope. Suppose I'm a merchant. I'm pain in BTC, but I need to pay supplier in USD. So I need to be size to be fixed in USD, obviously.

Let's consider a concrete example: 1 BTC is 10 USD (current futures price). I'm being paid 11 BTC and I need to pay $100 USD to supplier.

So I sell $100 USD worth of futures.

I'm too lazy to do the math, but if futures work correctly my profit should be 1 BTC no matter what. Alternatively I can make my profit fixed in USD ($10 USD that is.)

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