Build a mining market.  People deposit USD and can submit "buy orders" for mining.  A buy order is a merkleroot (or large collection of them), a target, and a price.  The semantics are that you are buying a nonce that makes that blockheader hash below target.

Let miners query the market, find the order with highest price per 1/target, and go to work.  Whoever finds the hash first gets paid out.

I am NOT a lawyer, but this should also skirt many problems bitcoin exchanges face and maybe even be doable in the US.  In particular, there is no way to launder money in this exchange.


This is also appealing to miners who just want instant cash, since they'd be paid in USD.

[The question]

Upon reading about merged mining, I was surprised to see it basically assumed that miners and verifiers were one and the same.  That need not be the case, and actually distinguishing the two can lead to interesting designs that avoid the need for miners to update software, or even know anything at all about what they're mining.

The goal is to somehow do merged mining completely obliviously to the miners.  Note this could potentially mean we need not even pay them for "mining" our alternative currencies (I am interested in this purely from a technical standpoint; the question of if this is ethical is totally orthogonal and so not in scope of this topic), which would be amazing if feasible from a technical standpoint.  Curiously though, I can't see a way to get away with being so cheap: this post will describe a basic idea, the problems, and how payment gives a solution.

The obvious strategy is to include the merkleroot as data in a normal transaction, rather than the coinbase, along with some tag saying "i'm really a merkleroot for a namecoin header".

The problem, of course, is what happens when two such transactions appear in a block?

One solution is just take the first in order of appearance arbitrarily.

Another better one is an auction: the tx with largest fee "wins" and is the valid namecoin header.  Now consensus in the alternative chain could be achieved by passing around a giant bitcoin transaction with NO outputs, paying everything as a TX fee.  

Alas, there is a more fundamental problem.  Suppose there are 2 "im a namecoin header" txs in a single block.  Suppose further the "winning" transaction is one that noone has any info about: the person who made it chose to keep the block to himself, not giving the data to anyone.  So all we have is a merkleroot and no idea what it points to.  Maybe the person who made it got disconnected or his computer crashed.

"OK, fine, we'll just use the other one if we don't have the data for the first one then!"  We do that, and next block, curiously enough, the same thing happens, we see a mystery merkleroot and have no idea what's inside.

The point is at some point, the person reveals all those historic blocks, and had work done for all of them, so now they instantly become "correct".

The fundamental problem is that a single bitcoin block must only provide proof-of-work for a single namecoin block (this is obvious when namecoin root is in coinbase, but not obvious if its elsewhere).  Further, if multiple namecoin roots are provided, it must be clear how to pick a winner, and people must not deviate from that even if the data for the winner is unavailable.

One solution to this problem, in the auction scheme, is if the data is unavailable, then the "honest" network agrees to raise the TX fee they pay for their fake TX, and hopefully outbid whoever is holding block data.  So now instead of needing 50% of hashing power, the honest network needs to be able to collectively outbid those colluding/holding blocks for the "highest TX fee namecoin merkleroot".

The question
Is there some way to do this without even paying the miners?  Or perhaps less expensively, paying them less?

Yet more reason for replacements/nLockTime to be turned on, you would never need an "account" on mtgox that you had to deposit more than you were going to immediately use into.

In general long-term business relationships can agree to just "settle it in the blockchain later", but still do it in a way that neither can screw the other.
 
1) Do the "standard escrow setup":
    a) Write Tx A w/ output spendable by sig from you AND mtgox, don't sign it yet.
    b) Write Tx B spending Tx A back to you with nLockTime some time in the future and seq number 0.
    c) Hand mtgox both these *unsigned* (don't sign TxA until he has signed TxB), demand he sign them, get them back and sign them, broadcast them.

2) For quick withdraw, mtgox can do the same thing in reverse with you.

3) To start off, Tx B has seq 0 and gives all coins in TxA back to you.  When you need to give mtgox money, you send him a signed replacement of
TxB that is final, and sends some of TxA to him and the rest back to you.  These are all offline, not sent to network.

4) As you need to give more money, you send new replacements for TxB giving more to mtgox and less to yourself.  Again these are all offline.

5) Finally, sometime before the original TxB expires, mtgox should broadcast the last signed replacement you gave him (the one that gives him the most money).
 

In this scheme, money is tied up, but still cannot be spent by the other party without authorization from you.  On the other hand, you can provide that authorization to them instantly offline of the blockchain.

I couldn't find this with a search.  This seems like the most natural payout to me and is also totally transparent:

Pool is basically a giant scoreboard of N lowest hashes for submitted shares.  When a block is found, reward is split equally between N people on the scoreboard at the time block is solved.

In a sense this is just a generalization of bitcoin's own payout system (i.e., N=1 is solo mining).  N would be set as large as reasonably possible to still make it not totally trivial to get on the scoreboard, but still guaranteed with a GPU.  (Say, N=10000 should do the trick).

[Summary]

Since the other thread got locked and some of the ideas below may not be obvious to all, I'll write them out here.
I've spent a bit of time thinking out how to design a currency like bitcoin that would fix some problems, namely
 
- price instability
- the ponzi-scheme like result of the current way difficulty does not affect generation

My schemes fall into two categories.  The first are unbacked, fiat like bitcoin is now.  The others would be backed by something like
CPU shares in a big grid,  or space in a massively replicated filesystem.  This post will purely discuss the former.  I am a computer scientist, not an economist and recognize it's debatable which is superior.  It does seem clear though that the power to arbitrarily control interest rates and inflation is a very good one when used responsibly.  So here is how that can be done democratically.

Summary
Build a new currency, call it hashcoins that are exactly like bitcoins except for one fundamental difference:
The number of coins issued per block is not fixed at 50 and on a decreasing timescale, but rather completely determined by vote.
Votes are determined by current CPU share.   Every N blocks (perhaps 2016), there would be a meta-block where miners would
indicate their vote on the coins-issued-per-block by including it in the meta-block header and hashing on it.  The coins-issued-per-block for the next N block epoch is then fixed to be the median over votes from the 10,000 vote-shares submitted with smallest SHA2 hash.

edit note: better scheme than voting proposed in post #10

Discussion

1)  But wait!! Then there could be infinitely many coins! they will be worthless due to inflation!.  Wrong, they cost money to produce.  If there are 1 million coins that each cost $1 to produce, and I generate a new coin at a cost of $1, that is not inflation, but rather a transfer of $1 from the USD economy to the coin economy.

Look at a corporation raising capital, say they get a pre-money valuation of $4 million from a VC for their 1M shares, so each share is worth $4.   The VC wants to buy 500k shares.  The corporation issues 500k brand new shares out of thin air and sells them to the VC for $2M, which then become the assets of the corporation.  So the corporation now has 1.5M shares.  OMG INFLATION right? No.  The corporation just got $2M in assets, and so has a post-money valuation of $6M, so it is still worth $4/share.  That is not inflation.

2) For stable prices, and elimination of the "ponzi-scheme" feeling, coins should cost the same to produce.  As it is now, the reward for a block is the same 50BTC it was in 2009, but requires 1M times as much work.  This is the fundamental reason for gross price instability, and the reason bitcoin is perceived as a ponzi scheme.  In other words, it's obvious that prices are instable now, because different coins cost different amounts of money to produce.  So it's easy to stabilize prices: make all coins cost the same to produce.   Say what you want about early adopters deserving it.  The fact is most people, when they hear this, will immediately think ponzi/pyramid scheme and want no part in it.  In fact, every time I've discussed bitcoin with others, the fact that coins made now require 1M times as much work as coins made in 2009 is the single fact that made them dismiss bitcoin entirely.

3) There is a problem with a fixed "50 BTC per difficulty" rule due to Moore's law: the same computational work a year from now will cost about 0.7 of what it does now.  Thus if coins truly represented a fixed difficulty, they would depreciate in value rather quickly.  The purpose of the voting is to allow for this to be accounted for in a fair and reasonable way, to protect against depreciation but not to grossly enrich early adopters.  A reasonable rate would be say, enough to counteract Moore's law plus perhaps a 5 or 10% appreciation for early adopters, but NOT a ridiculous 10,000% increase in 2 years; the current market participants would decide the exact rate.  Ofcourse, they could vote for a 10,000% increase and get it if they want.  The hope is that enough people will realize that is an extremely stupid idea and be detrimental to widespread adoption, and instead carefully vote in a way that gives them some kind of appreciation, but not so much to scare away future newcomers.  

edit: meant to post this in main forum, mods plz delete.  (why no delete function in edit post??)

[counted across blocks]

Where can I find a list of them?  I am going to write a pool server as an exercise to writing a full bitcoin client.

The first scheme that came to mind is the following: when the pool gets a block, pay it out to the N workitems submitted with least hash value (so, the guy that solved the block and the N-1 next biggest hash values), where N is big enough. 

I read some "pay-per-share" model where pay is distributed for each "share" where a share is a solution below an easier target, and these shares
are counted across blocks.  This doesn't make sense to me.   In bitcoin's economic model, a share for a block with larger difficulty should be worth less than a share for a block with less difficulty. (I.e., imagine if one had a "share" from when difficulty is 1.  In the bitcoin model that would be worth much more than a share now).

(also, PLEASE whitelist me)

[edit note, this stuff can be done without time-conditional scripts using nlocktime as explained in later posts. still leaving this post so you can see protocol for untrusted exchange]

edit note, this stuff can be done without time-conditional scripts using nlocktime as explained in later posts.  still leaving this post so you can see protocol for untrusted exchange
Basically add an "if time < DEADLINE X else Y" condition to the transaction script format.  With this it will be possible to do untrusted transactions between other crypto-currenies as follows:

A and B want to trade bitcoin for blahcoin.

A and B pick keys, send them to each other, and also pick secrets secretA, secretB.   They send each other hashA = hash(secretA), hashB = hash(secretB)

A writes the following TX:

If time < DEADLINE1, spendable by providing:
   string sa s.t. hash(sa) = hashA
   string sb s.t. hash(sb) = hashB
   signature from pubkeyB

else:
   signature from pubkeyA

B writes the same TX to the blockchain for the other thing, with a deadline a few blocks later (so A has more time to spend it).

Now A tells B his secretA.  B can now be nice and tell A his secretB or be a dick and keep secretB to himself.  Infact, let's just say standard protocol is for B to keep secretB to himself.  The point is, B must reveal secretB to spend the coin, thus revealing it to A and letting him spend the other coin.

Once we get this, I can design all sorts of other untrusted trade schemes, but they all need a time condition.  (Unless I'm missing a way to do it now.. if you're smarter than me and see how to do it please let me know!)