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

Great!!
Does it support mutliple trades (Ripple)?
For example...

(A) 100 btc -> (B) 1 satoshiB -> (C) 1 satoshiC -> (D)

or circular trades...

(A) 100 btc -> (B) 1 satoshiB -> (C) 1 satoshiC -> (D) 1 satoshiD -> (A)

That would be a decentralized Ripple implementation.

Can the dividends automatically be forwarded to a separate wallet address and if it had a list of dividend wallet address built in would you be able to edit it for when shares are sold.  Also could your script work with Electrum or even possibly blockchain.info/wallet    Sorry if that sounds stupid  

Edit:  Having to download the full blockchain to verify your coloured coins will hinder its adoption.  Many people are now using thin-clients rather than full blown desktop PC's now.  Having an Electrum version or even a hack of blockchain.info/wallet would be good.

According to my understanding of killerstorm's approach(es), there is no reason to believe that the approach in this script should be incompatible.

But it is difficult to be sure until there are actual implementations (or detailed specs), so in the end the script might require modifications to be compatible.

Update

The source code has been updated in OP - the new version includes the functions to include a transaction fee from an (uncolored!) address in your standard/satoshi-client wallet when transferring assets so that the transaction is more likely to confirm more quickly (command-line option -w , where is the fee you want to pay in BTC, e.g. -w 0.005 for half a bitcent).

Also, the tracking of colored coins is now also believed to be compatible with other approaches for "order-based" tracking, such as the one used in killerstorm's modified Satoshi client (however, I still want to build up a bunch of test-cases to see if the clients interpret all the cases in the same way).

Next, I think it is time to create ample test-cases, and tidy up the code - it has turned into a bit of a spaghetti-ball.

Maybe one of you should start a bounty wallet on this site - https://booster.io/ - so its easier for other people to add small bits too.

Edit:

Well, yes, that's a problem.

Here's one of possible solutions outlined: https://bitcointalksearch.org/topic/m.1269200


You shouldn't color them when you're traversing, instead you can collect topo-sorted list and them color them one by one.


Yep that would be cool, but I don't have any non-trivial examples in blockchain.

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

Taking your 2, and adding another 20 BTC donation
and adding link to a public document that started the documentation :
https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit

Anyone who wants editing rights, simply send me your email in a private message

The method of exchange you've explained is the only possible way in the current design and that is exactly what I am trying to stay away from. We still need a decentralized exchange mechanism, why?

• Cause trust should be imbedded within the mechanism itself instead of person to person exchange
• Also we need a decentralized mechanism to broadcast ask/bid orders instead of relaying on a "centralized" third party client/server mechanism
• Remember that the main reason we end up being here is strongly related to "TRUST", we need a simple user friendly application that we can trust more than any other centralized solution

Once a there is an ability to color coins, there is a built in mechanism of exchanging any colored BTC to any colored BTC (regular BTC can simply considered white BTC). For example, lets assume I start a color called BTX , coloring is simply accepting some initial genesis input as those colored coins, I can now exchange with you 1 BTX for 2 BTC, we need to trust each other and agree on a price offcourse, there are mechanism in bitcoin to act as escrow for this transaction, but those are 3rd parties.
So at anytime you can look at the blockchain and see all BTX/BTC transactions, since colors are public, and you can show last price and historical prices, you can simply agree on the last price, or last price + x.
When you mentioned bid/ask, that is simply a matching engine, that might require another 3rd party, but is not necessary for the basic use of an exchange, as a bid/ask book is actually centralized for of exchange.
Take for example currency trading, there is no ask/bid centralized anywhere, yet it is the most sophisticated and liquid market in the world, possibly because of its OTC and decentralized model.

What would be more interesting is instead of sending the message in the transaction fee, is to send the message as a small BTC amount to the issuer's BTC address as a second recipient in sendmany(). This way all messages related to that particular asset can be tracked through the issuer's BTC address. The issuer can then benefit from the messaging mechanism instead of wasting BTC in the transaction fee.

What do you mean by "affording a transaction but can't afford the transaction message you want" can you give an example?

If you just make use of the last 2 digits in the transaction fee: 0.000000## this can give 100 different variation = 100 different events/messages

I don't think that you would need more than 100 different messages, knowing that currently your design is based on a single message: colored coins moving from one address to another. Imagine if you can have 100 different events/messages going in/out of a BTC address. In this case you wouldn't even need to move the colored coins! the colored coin term wouldn't even apply here. Cause by then you would be applying a virtual messaging protocol on top of the block chain, where nodes = BTC addresses, messages/events = transaction fees, message/event payload = the value being transfered. Only then the variations that such design can give would allow a decentralized exchange mechanism to take place: You want to sell 10 shares @ 0.1? send a transaction to the BTC address you want to receive payment to with the value you want to accept per share and a transaction fee with last digits = to the "ask order" message/event. The same senario can be used in buying the shares. Does that make any sense?

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?

I am looking forward for your exchange mechanism solution. Where can I follow that?

What do you think about using transaction fees values as messaging protocol events for a colored coins application? Do you know of any implementation that applies that?

This thread has links to everything: rules, examples, code, interactive demo: https://bitcointalksearch.org/topic/order-based-coin-coloring-114571

However this version of code might be easier to read: https://github.com/killerstorm/colored-coin-tools/blob/master/color.js

Only compute_colors() function is necessary, the rest is just validation/sanity check.

I definitely plan to implement an exchange mechanism in client software I'm working on. However I think ask/bid orders should be broadcast on a separate network, doing it via blockchain would be kind of a waste of resources.

(However it isn't totally out of questions, there are alt-chain designs which are more scalable than bitcoin and they will be able to handle bid/ask traffic in blockchain.)

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

As far as I understand your design doesn't have a mechanism for exchanging "shares/colored coins <-> BTC". I am still new to the term "colored coins", I came across it when I was trying to find any decentralized solution for exchanging Assets <-> BTC. Your design seems idle for issuing/tracking colored coins ownership. I am thinking to start using your implementation soon for my asset "Bitnodes". Please correct me if am wrong; there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.