Is there an alt-chain that does useful work instead of plain hashes?

[pyra-proxy]

I'm don't quite understand why you're saying that you don't need a block chain-- you still need one to process the transactions (if you mean that you don't need one for the algoritm calculation part then you're right-- I think). 

I don't know much about the PoS  (do you mean proof-of-stake here?) generally, but I should look into it to think.  thanks.

Yes PoS == Proof of Stake in my post.  It is a more energy efficient alternative to Proof of Work but one with different attack vectors which some argue to be somewhat less secure than Proof of Work but Sunny would technically be the resident expert on the system to date....

You don't need a block chain, look up talks on the ledger system alternative to a block chain.  And at some point in the recent past I even suggested a hybrid ledger/block chain approach which IMHO gives you all the strengths of both systems.  The hybrid approach would create a "rolling genesis ledger" or "check point ledger" in which all previous block data could be purged and you would say have a ?1000? block, block chain from the "rolling genisis ledger" and every so many blocks you'd fold more recent history into the ledger and purge the chain that was stored into it.  The ?1000? block, block chain should be sufficient to have orphaned chains etc. all resolved and that history to be highly probable to never need changing.  Of course others have proposed a 100% pure ledger system which I don't see why that couldn't work for you as well.

[Deprived]

Any system which requires EVERY node to know every other node in the network is just not going to work.  Any deterministic way of pairing people off based on wallet addresses NEEDS either that - or a centralised authority.

No, every node doesn't need to know every other node.  Also, every miner doesn't need to know every other miner, in fact, it is better if none of the miners are aware who the other miners are to minimize collusion.

The determinism comes from the block-chain,  this is the only required infomation which must be common to all miners. It is trivial (I believe) to group the miners deterministically but effectively randomly using hashes based on a combination of the miners' own data such as a receiving address and the current state of the block chain and the alorgithms already run for the current block.  This is not much more of a burden than what happens already in bitcoin.

This doesn't make sense.

To deterministically pair all miners you have to KNOW who all miners are.  If you have some unique identifier for ALL miners then it's pretty simple to pair them off in a verifiable manner.  But then that information MUST be saved - or noone can ever verify that data produced from those pairings was valid - a pre-requisite for validating past blocks.  All information needed to verify a block MUST be in the block-chain or noone can ever load a block-chain with any confidence in its correctness.

That's why details of all miners connected would need to be saved for every block.  You say this would be done via the bonds (i.e. connected miners would be defined as those who had paid a bond/deposit for that block).  That's where block-chain bloat would occur - as no sensible miner is going to pay a bond up front for more than 1 block given their ability to lose it due to a load of factors.

At various points you talk about "the system" working things out.  But what is this system if it isn't the miners?  Either you mean some centralised authority or you mean the miners - if the latter than ALL miners have to have ALL information or they can't collectively reach any decision.  Whilst in Bitcoin it's not an issue if a miner hasn't, for example, received a transaction, in this coin it WOULD be an issue if a miner didn't have information on ALL work done by ALL miners - as that would lead to them rejecting a block because it didn't contain the fee for a deposit they believed should be forfeited or a deposit return they believe should not be returned.  That makes network traffic proportional to N^^2 where N is the number of miners - as every miner has to have information about every other miner.

Similarly, if deposits are returned or converted to fees based on work done then that work done MUST be stored in the block-chain.  Otherwise how can blocks be verified?  Noone can sign those deposit refunds/fee charges other than a miner - so how does someone who connects to the network verify whether the refunds/fees in a block are valid?  What stops a miner who finds a block taking as fees  deposits that should be returned - and returning deposits that should be forfeited to their own sock-puppets?  The ONLY way to stop that is for ALL miners to have ALL information - otherwise noone would ever agree that anyone else's block was valid as it would be based on a different subset of information.

The deposits are transactions.  Given those are necessary for someone to mine, what incentive is there for miners to include deposits from other miners into their blocks?  By excluding other miners' deposits (i.e. leaving the transaction out of blocks you process) you can deny other miners the right to mine.  This gives the ultimate attack vector - where if a pool can even briefly get a good portion of the mining power they can progressively shut other miners out.  And even if 100 times their mining power connects, that 100 times their power has no way to mine - as it's impossible for them to submit a valid block without a deposit having been processed for them: and whoever managed to gain control has a serious financial incentive not to include any deposits in blocks.

If someone managed to hit that point then not only can they prevent anyone else mining, but they can also double-spend like crazy - with the only way for someone to unseat them being to create a new chain of greater length from a point some significant time in the past.

With a small number of honest miners the system would work fine - but it could never scale to a large size due to either an enormous increase in bandwidth/block chain AND/OR a loss of consensus causing massive chain splits.

[bitcool]

However, despite all these objections, I hope you realise something:  you've gone past the point of denying the system works outright and into questioning specific details.  This is GREAT,  I appreciate your feedback very much cause it is making me think about the system more--  till now it has been just a general idea that I've had for a few years and never put that much thought into it.

I do think the idea of pairing and grouping miners to perform the work is feasible, it may not be easy, but definitely doable once those concerns are addressed.

Here is the list of distributed computing work  http://en.wikipedia.org/wiki/List_of_distributed_computing_projects . Instead of focusing on particular example (prime numbers), maybe we can generalize the challenge. (making it more difficult too)

The way I see it, there should be some kind of API that can be used by these organizations: mixing, obfuscating, formatting and publishing their data. The difficulty of their problems should be adjustable.

I don't have huge problem with (somewhat) centralized feeders, if I choose to run such a client, I am essentially volunteering my computing resource to these organizations, I'll have some trust in them, accepting certain level of risk associated with this trust. i.e. sacrificing some Bitcoin's elegance & and ideology in exchange for practicality.

On a side note, coblee's POA https://bitcointalk.org/index.php?topic=102355.0 may be helpful in such a situation, adding randomness to the picture.... may be a hybrid of POW & POA?