I have an interesting discussion going on with another thread that brings up a technical question regarding Bitcoins itself:
https://bitcointalksearch.org/topic/setting-up-a-stock-exchange-2001There was also another discussion started that suggested some alternate ideas about how to use Bitcoins and a bitcoin-like generator for other purposes:
https://bitcointalksearch.org/topic/bitdns-and-generalizing-bitcoin-1790I'm sure that other discussions of a similar vein have been started too, but in these discussions I've considered the problem of how to transfer Bitcoins to potential miners in this situation.
For instance, I would like to set up some algorithm where you could "set aside" some Bitcoins for somebody who can perform a publicly recognized and "certified" form of work. The exact criteria could be defined in some other manner, but what would happen is that the coins would be put perhaps in some sort of escrow until that algorithm releases those coins to a designated Bitcoin address when the work is completed.
Explicitly what I'm trying to do is find a way to have miners of a secondary chain be able to collect bitcoins for their "proof of work" hashes on those secondary chains. The issue really is more of a synchronization issue where there is an agreement to have transaction fees on the secondary chain get put into the primary Bitcoin blocks as Bitcoin transfers between users of defined addresses.
Specifically, the algorithm I'm thinking of using here in regards to the stock exchange block is one where the share transactions are collected by "miners" for the stock exchange chain and all Bitcoin transfers are in turn relayed to the Bitcoin network as ordinary Bitcoin fee transfers. Since there is the potential for competing nodes and competing chains (based upon similar principles to Bitcoins) the actual transfer of Bitcoins for the miner shouldn't happen until after the block is clearly accepted into the chain, for example when the block is 10-15 blocks deep into the chain. At that point this particular "hash miner" will receive the coins for its part in preparing and processing the transaction of the secondary chain and the "escrow" will be released.
I can see this being done with other kinds of escrow services where perhaps some sort of double hash or certification algorithm would be set up with the escrow service then releasing funds when agreed to by both parties. Perhaps this is the same thing, but then again it might be a different problem domain altogether.
The real trick here is that it involves a third party in the form of a miner who is receiving funds from at least one of the parties in a transfer "with consideration of other things", and then on top of that this third party isn't defined until after they have performed the work to build the block and get it accepted into the chain. We do this with miners of the main Bitcoin chain, but since they are processing the transactions themselves they also can be selfish and keep "leftover" bitcoins in the form of transaction fees. It gets even more complicated here because a fourth party, the main Bitcoin miner, is also involved in trying to process the fees in question. It is one person sending money to three different people (potentially) where only one of those people is known ahead of time and the other two people must show some kind of "work" to "earn" the money set aside for that work.
Perhaps this is impossible, but on the other hand I think it could be resolved in a number of different ways too. Perhaps all of this must be incorporated into the main BTC mining chain as an "extended service" where miners could earn some extra coins (at their option). Perhaps it simply can't be done at all. I'm willing to think "beyond the box" here and realize this isn't an easy problem to find an elegant solution. My preference would be to find a peer to peer network solution, but if it can only be done with a central server doing transactions, so be it too.
Please keep this to the technical discussion of this particular problem and not get into the stock market philosophies... which should stay on the other thread.