What's the hold-up on the assets? Does anyone have any info, or is everyone in the dark?

The site is currently not running. If there is any serious interest, I will fire it up so those interested can play with it.


I consider your generosity flattering, but I politely decline your offer.

killerstorm,

I imagine you could be watching, so let me ask a question about an aspect your algorithm/code/example in color.js that I am having some difficulty with regarding transactions with several inputs of the same color: during "traversing the tree of ownership" to determine owners of the colored coins, at some point you may see a transaction where two inputs have the same color, but you are only aware that one of the inputs are colored (while following the input that lead first lead you to hit the node).

During a traversal, how can you be sure that you have the (same-)color information for all the inputs? I was thinking "well, just process in order of appearance", but if the transaction with two inputs of the same color occurs in the same block as the transaction that adds color to one of the inputs, we again have a problem.

Any ideas?

PS: It would be fun if you have any test-cases that are available in the blockchain that could be checked, to verify that our interpretations on how color is transferred from inputs to outputs coincide...

I wrote the software for running a bitcoin-based betting exchange, similar to Betfair of Betdaq, only leveraging the strengths of bitcoin. Sort of like a mediated P2P betting exchange where the site operator acts as the escrow (and naturally makes his commission from the winnings). In the hands of the right person, I believe it could turn a handsome profit - and that's why I created it. Operator takes no risk, only matches bets from the users with each other and decides the outcome of the event when it has been determined.

However, after some consideration, I have decided to sell it instead of running it myself, both because of potential future legal issues and because I don't have the time for it.

It is written to have extremely low barriers to participating, inspired by the SatoshiDice-style, where you just send bitcoin to a given address to place your bet. The user navigates the site, finds the odds that correspond to backing/laying a given selection in a given event and simply sends bitcoin to the corresponding address. A daemon running in the background picks up the transaction from the bitcoin network and enters the bet into the books or matches it with other bets that have come in earlier.

It was opened for live testing in onionland for half a week in September and experienced no problems.

Features:

• Lightweight - written in Python (web.py/lighttp)
• Twitter Bootstrap HTML+CSS
• Postgresql backend
• Daemon that listens for and registers incoming payments immediately
• Tested in .onion

It is in a simple and crude form, and would require some technical knowledge to operate.

Accepting offers either in this thread or by PM, please specify the terms of your offer. Let me know if you have any questions!

PS: For those asking "how is this different from betsofbitcoin": it allows players to choose their own odds, guarantees those odds when they are matched (not like betsofbitcoin which has some strange time-discounting), and it allows trading and arbitrage with sites such as betfair and betdaq. Anything I forgot?

Thanks, I'll certainly take a close look at this! The order-based method of coloring certainly makes a lot of sense.

Indeed, there is no built-in design for exchanging, the design simply does the easy part - issuing/tracking ownership of colored coins. (It can also pay dividends to the owners, but that is not really conceptually different.)

The question of decentralized exchange is a somewhat separate (but related) issue. I had some thoughts on it while I was trying to sleep last night, I might try a simple prototype of that too when I'm relatively satisfied that this script does what I want it to.

What I had in mind was not necessarily decentralized, but more of a protocol that would be agnostic to the transport layer. But imagine that you have a client and a server (in a p2p design, each node could be both). The protocol would be relatively simple:
1) CLIENT connects to SERVER
2) CLIENT requests order book from SERVER
Then either:
3a) CLIENT wants to enter a new order in the book: e.g. BID: ASSET1@400BTC, and signs it with address(es) that controls at least 400BTC, sends to SERVER
4a) SERVER verifies signature, enters into order book
5a) SERVER broadcasts order to all CLIENTS
or:
3b) CLIENT wants to hit an order from the book: constructs a transaction with the inputs taken from own wallet and inputs specified in the order, signs his inputs and sends to SERVER
4b) SERVER broadcasts to incomplete transaction to all CLIENTS
5b) The CLIENT that originally made the offer signs the last inputs, and broadcasts the complete transaction on the bitcoin network.


All nodes will also need to monitor the blockchain, so that if any of the inputs are spent that are part of an unfilled order, that order is immediately removed from the books.

There's not really that much needed to make it work. I'm sure a lot of people have had the same (probably much more clever) idea(s). Decentralized or centralized, following such a protocol would at least not leave you with a single point of failure - asset ownership would be public and undisputable at all times, the blockchain would contain a complete price history, and you essentially wouldn't have to trust any third party. The worst thing that could happen is that the counterparty does not sign the transaction when you want to hit an order from the book, but in that case you keep your BTC anyway.

Anyway - sorry, offtopic

PS: Making the transaction fees "information-bearing" doesn't sound very good to me. Imagine if you can afford the transaction, but you can't afford to make the transaction with the message you want?

Correct: what your shareholders need to know is that 630bcca... is the ancestor/root/genesis, and after that the script figures out all the shareholders by traversing the list of "well-formed" transactions from there onwards.

IF someone was adventurous enough (i.e. moreso than Indiana Jones or Ranulph Fiennes) to want to use this script at the moment, then I would recommend every shareholder to generate an "asset holding" address with this script. Thereafter, the asset issuer would make transfers to that address. Every shareholder would also have to be told the transaction ID of the genesis transaction (and the output number), which each one would then have to add to their client.

Those concerned about security could also write their private key down on a piece of paper (it is stored in plaintext in the configuration file) and remove it from the configuration file. However, when making transfers, they would have to re-enter the private key in the config file...

That might solve the problem if you could agree all client developers (Satoshi+MultiBit+Armory+Electrum+++) to agree that transactions with a fee of that specific value are pariah, which might be hard.

Until then, I found it easier to simply store the keys for the addresses that hold colored coin separately from the normal wallet.dat. Cumbersome and ugly, some may argue, but I feel it certainly mitigates the problem.

You prove that you own colored coins by holding the private key of the address they held at (same way as you prove that you own any bitcoin, in fact). For my script, the private keys of the addresses you generate with the client for holding colored coins are held in a configuration file. The file is relatively small and in plaintext, and can easily be backed up, sent by e-mail, stored offsite, etc.

Better to show by example, perhaps:
--------
1. An "asset issuer" essentially says something like: "I will use the output number 2 from transaction 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b to represent 100% of the shares in my company, whoever holds the descendants of this output holds a proportional share of the company."

Output number 2 from that transaction belongs to 1AEn3U5MhedXYRbpxLKmkL4r5Kz1XkdZA, as can be seen by the whole world at http://blockchain.info/tx/630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b, and can also be verified in their own local blockchain.

2. The "asset issuer" can now transfer those bitcoins or portions of those bitcoins to other addresses. The transfer will be stored in the public ledger/blockchain - everyone can verify that output number 2 from transaction 630bcc... was assigned to three new addresses in transaction d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d, http://blockchain.info/tx/d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d. 60% of the value was transferred to 1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9, 30% to 1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21 and 10% to 1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC.

The holders of these three addresses are now the new owners of the company, since they hold coins that descend from the "ancestor" transaction output. The evidence is in the public ledger for all to see.

3. The holders of these three addresses can again make transfers to other addresses, each time the public ledger/bitcoin blockchain will hold a record of the transaction, such that the genealogy can be traced back to the original ancestor that represented 100% of the company.
--------

The script I have written essentially just makes sure that the transactions are "nicely" formed, in such a way that descendants of the ancestor are recorded in a very obvious manner in the bitcoin blockchain, and contains a mechanism to track the descendants.

Did that make it clearer, or just mix it up even more (if so, sorry about that!)?

I'd like to thank the big brains for weighing in here in this thread.

With the script now working "as I originally had in mind", I am now very keen on making improving the script and making it compatible with the approaches discussed by the venerable mr. killerstorm and sir jgarzik. However, there are so many long threads at this point that I don't have time to dig through the coal to find the diamonds, so if anyone can point to a whitepaper, a spec, a particularly enlightening post, preferably showing examples of transactions and how the color should be interpreted in the input/output for various approaches, then I would be very grateful. A deconstructed example of for instance 2 colored+2 uncolored inputs should be pretty comprehensive - anyone seen such a thing?

But first, I would like to invite matthewh3 - as the only "asset issuer" that has weighed in so far - to describe a little more in detail what features he is looking for.

Update: I've been reading up on the discussion ,and it seems that the consensus is something like this: https://bitcointalk.org/index.php?topic=106449.msg1203918#msg1203918, so I intend to try following those rules (until problems start surfacing).

Update

A new version of the script has been posted, and OP has been updated with a usage example that showcases the current capabilities of the program.

The main new feature is the possibility to pay dividends from your wallet to the holders of colored coins.

Enjoy!

That looks like the field that used to say "dividends paid". I must admin, I like Gifted Coins - sounds much more altruistic.

Looks like a move to avoid using the language of Wall Street, and reinforce the fact Nasty that this is more like a partnership or a cooperative so it hopefully doesn't get blasted by the SEC.

I'm not quite up-to-date on the main colored coins thread, so I'm afraid I can't explain it at the moment. Will read up on it, though, and see if our thoughts are compatible.

In other news, a newer version is currently being tested, which allows paying of dividends/coupons/etc from your wallet to the addresses that hold the colored coins. However, progress has been stumped by a bug in blockchain.info (https://bitcointalk.org/index.php?topic=40264.msg1265405#msg1265405). Either they will fix the bug in reasonable time, or I guess I will need to work around it (which would be tedious).

Stay tuned!

Dear Blockchain.info,

The API call to get unspent outputs for an address, http://blockchain.info/unspent?address=$hash_160&address=$hash_160, appears to give WRONG transaction IDs.

For instance http://blockchain.info/unspent?address=1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9 shows unspent outputs are from transactions:

cf707398596a9f8bf45e22e3f736b819f27ba6d10cb9c12f1ca23a9daf0c6f1d
7dd1bb29c39d4b44b4c9434a9f2a9ccb1f4af22dbd8c9ff252b5e19b79dce8d8

when in fact they should be from transactions:

1d6f0caf9d3aa21c2fc1b90cd1a67bf219b836f7e3225ef48b9f6a59987370cf
d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d

as can be seen on http://blockchain.info/address/1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9.

Please fix!

Thanks,
bitfair

It's starting to push the limit for what can go into a single file - I will be considering putting it on github when it becomes necessary to split it into several files. (Probably pretty soon!)

I agree in principle, although I believe bloat from piggybacking on the main chain would be negligible in the bigger picture. In addition, a separate chain for smart property would also require separate mining, and mining requires some kind of compensation paid to the miners - and I haven't been able to think of any sensible "compensation scheme" that would make it worth their while. [But, by all means, don't let the discussion stop at my lack of imagination!]

Edit: Currently testing dividend/coupon-payment function using the 1 BTC that was donated (thanks!), script will be updated when it appears to be working. And shortly after that, expect a "howto"/annotated example.

There is no "colored blockchain", it uses only the standard bitcoin blockchain and tracks all the transactions in a chain starting at a particular given transaction. That a coin is "colored" only means that it can be traced (through the blockchain) to belong to a very specific transaction, chosen and named by yourself.

And it simply makes sure that the transactions built by the script are formed in such a way that allows them to be tracked by the script.

Excellent questions, sir! It's a very crude script at the moment, following one of the pillars of "open source": release early, release often. (I guess the reason is that it gives others the chance to make and suggest improvements!)

Complexity (answers pulled out of my hat without terribly much thinking, I might need to correct it later):
a) Time: standard tree traversal time, O(n) where n is the number of nodes. In this case that means the number of transactions of the security that have been made since the root/ancestor transaction. In this implementation, the latency from accessing blockchain.info on the web will dominate (which it does to find out which transaction the coin was spent in next) - executed O(n) times.
b) Storage: While traversing the blockchain, a stack depth of O(log(n)) will be kept in memory (many assumptions in this). After traversal, the leaf nodes are stored in the config file, so it is proportional to the amount of "owners" of the colored coins.

And yes, you are quite right: in the spirit of simplicity and transparency over rigid correctness, all information is currently stored in the configuration file. (You may now commence your complaining:)

I am planning to implement it such that dividends/coupons/whatever can be paid to the owners (proportional to their share, of course) from the wallet. It will be paid to the same address which is registered as the owner of the colored coins - but the receiver will need to be careful when spending the dividends, so it doesn't accidentally spend the transaction that represents the share. For that reason, I also need to implement routines to safely transfer the dividends from the address holding the colored coins and to another address.

Thanks for considering using it. It's more fun when someone finds it useful. But beware that it should be considered experimental at this stage (although as long as no private keys are lost, it shouldn't really be "dangerous" to try it).

Also considering a simple GUI, that might lower the barriers to using it.

Not yet, but it will be relatively trivial to implement. The script already produces a list of "shareholders" (as represented by their bitcoin addresses) and the share that they own.

From that, it's just a question of massaging the data to the right format and feeding it to the bitcoin json API.

I will see if I have the time to implement it this week, and pastebin a newer version.