Coloured coins and SIGHASH types
allow the main chain to be used for trading fiat "tokens" and bitcoins in an atomic way.
Each coloured coin would represent a certain amount of fiat. For dollars, 1 satoshi might equal 1 cent.
The problem is that you can't do orders. You can publish a binding offer (assuming it makes it into the main chain) of the form "I will pay $100 for 1BTC". However, you can't publish an offer of "I will pay up to $100 for 1 BTC, or current market price if lower". The second option is needed to allow support for order books.
It looks like a lot of the script ops that would help with this are disabled. Presumably, that means a hard fork to enable them? What happens if a miner produces a block contain OP_AND? Can you convert a byte array to an integer to do difficulty comparisons? You could do it bitwise, use OP_AND to make out all the LSBs and then compare to an array of all zeros. That requires power of 2 difficulties though.
What would be useful would be an OP_PARTIAL_MERKLE_ROOT code that computes the merke root from a partial merkle tree. This could be created for fixed length
The input would be something like
<byte array: child> <int:left/right/end> <byte array:partial 1> <int:left/right/end> <byte array:partial 2> .... etc.
You give it the item you want to hash and the rest of the branches to the root.
So, basically, in the script you would require verification that the transaction's random id was includes in the alt chain. The requirement would specify the hash of the previous block header, a random id for this transaction and the number of additional blocks that must be placed on this block for the unlock to count. Also, you would specify the difficulty target.
To unlock the transaction, the seller would provide partial merkle nodes as byte arrays and the headers for the next blocks in the alt chain. The script would check that all the headers meet the difficulty target. The current block header would need to be built up, so things like concatenation would seem to be required.
The alt chain's headers should be as bare bones as possible.
When the alt-chain changes difficulty, it would need to take the harder of the old and new difficulty for a while. If the difficulty drops on the transition, then it would prevent the new headers being used as part of the proof. The first 100 blocks after the transition, if the target increases would still use the old target.
The alt-chain could then only include the release id, if the buyer created a transaction that paid the seller back the difference between market price.
This needs an op code which is basically "hash this transaction". That could be included in coin spend requirements. The 2 lowest children would be the random id and the hash of the entire transaction. This means the unlock only works for the specific transaction in question.
A problem is that the seller could just spend the input while the confirmations are pending. Also, the value of each transaction would have to be kept lower than the cost of actually doing the proof of work hashes.
