Topic: Blockchain security tracking/colored coins/smart contracts - short python script - page 3. (Read 8818 times)

Is there anyway this idea could be used to hold motions/voting weighted off coloured coins ownership?

As long as the shareholders don't massively disagree I'm going to offer out a 0.5% ownership of the former GLBSE mining stock/asset RSM - (https://bitcointalksearch.org/topic/796com-redstarminingcom-the-oldest-public-mining-security-150ths-63257) - That works out currently as ownership of 0.9(GH/s) of BFL-SC-Singles although we will be saving 50% of profits towards buying more ASIC's to increase the (MH/s) per share ratio.  For you to implement this idea and maintain it.  You wont receive the coloured coins relating to that 0.5% that will be held in a separate account managed by me but you will receive all profits made from 0.5% ownership as long as you maintain the code.  I've also offered this bounty to this coloured coins project too - (https://bitcointalksearch.org/topic/chromawallet-colored-coins-issue-and-trade-private-currenciesstocksbonds-106373) - so the first/best implementation will win the bounty.  We don't need to use the coloured coins for about another month yet when we receive our first BFL-SC-Single.

A relatively easy approach to handle multiple inputs, and particularly a mix of colored and uncolored inputs, in setting like one used in this script is:

• Get a list of "potentially colored transactions".
• Sort it in such a way that dependencies never appear after dependent transactions. (This is known as 'toposort'.)
• Go through this list of transactions in order and identify all colored outputs. (When we scan transaction we already know which of its inputs are colored and thus it is easy to identify colored outputs.)

This script already has a recursive traversal function (called rec), with some modifications it can be used to identify 'potentially colored transactions'. Moreover, if it produces such list via "reverse postordering", list will be dependency-sorted, see here: http://en.wikipedia.org/wiki/Depth-first_search#Vertex_orderings ("Reverse postordering produces a topological sorting of any directed acyclic graph.")

Then for each transaction, we can count sum of values of colored inputs and use it color an appropriate number of outputs. Additional check should be made to make sure that all colored inputs go before all uncolored.

However, there is a problem: a list of potentially colored transactions might be huge. Especially if you include uncolored outputs.

To solve this performance problem one might limit depth of DFS by block number: i.e. do this coloring process in batches, block by block or something like that. Whenever you see a transaction in a block too far ahead, simple ignore it, it will be considered later. This works because transactions in later blocks cannot affect transactions in earlier blocks.

Could you suggest the code changes for this script to support order based ?

Well, it is compatible with order-based coloring: if we have one input, it is always in correct order

But I don't think that having two versions (let's call them simple and complex) is a good idea: that would mean that if somebody makes a 'complex' transaction, those coins won't be visible in 'simple' version anymore. Forever: there is no way to repair it for 'simple' version.

Also I think simple version should support at least 1 color + uncolored scheme. This would allow payment of transaction fees, buy/sell atomic transactions etc. There is no need to support more than one color in one transaction, but colored + uncolored is sort of necessary.

So can both coloring schemes be merged into one standard, can we define that standard ? Anything worth updating here ? ( no need to allow multi colors in one transaction in all scripts, simply means they can read only "pure colors").

I guess the main difference is that we were focusing on allowing to have coins of multiple colors in same transaction, while this version doesn't allow it, comment in code:


More fine-grained color tracking is needed to implement secure exchange: coins of different colors will be exchanged in one atomic transaction.

Otherwise this script seems to be roughly equivalent to the prototype I've implemented about a month ago, in terms of coloring.

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://bitcointalksearch.org/topic/m.1265405). 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!

This is really great ! Can you explain the diff between your implementation and the main colored coins thread ? Would be great to merge coloring so there will be one standard.

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

Post on github.com

Since coins can now be tracked, and thus need no longer be and maybe will no longer be fungible, we can devalue coins mined into the coinbase transactions of blocks where list of merged mined chains codes does not include our chain.

Maybe only people who try to buy securities will care, if no other chains also devalue those specific coins and their descendants, of course.

But would the actual coins of a securities chain actually be worthless when uncoloured? Or would folk looking to colour them consider them worth buying?

How many securitysatoshis would be mined per block in such a chain?

When bitcoin catches on, how fabulously expensive is it going to be to have to pay for an actual bitcoin chain transaction every time you want to change which family-member controls the garage door opener or other smart-property? Might using one of the many commonly merged chains be more cost-effective when dealing with smart property smaller than, say, a small house or fancy vehicle?

Would this use of the bitcoin chain be a better way of implementing domains, aliases, pseudonymous identities, keyrings and such than the ostensibly designed for the purpose namecoin? (Maybe namecoin was a silly clumsy ill thought out idea that overlooked this much more natural, elegant, effective approach?)

-MarkM-

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.

True, however:  a chain specifically for smart property could potentially keep bloat out of the main chain.

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

Well we will probably wait until it is a bit more mature but I will put forward the idea that you get a donation from our shareholders.

Another question is does the whole blockchain need to be saved and how can I distribute more than one copy of this new coloured blockchain.

Any idea what the asymptotic complexity is of this implementation? I'd be interested in the a) time, b) storage space, and c) transfer requirements, in terms of quantities such as 1) the number of tracked coins, 2) the number of transactions for each coin.

Also, it looks like your config file is not just a config file, but also is a stateful database that stores the current owner of each coin.

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.

Cool, if you do I may use it for my asset.  I'll see if I can organise you a donation for your work from shareholders if we use your client.