You could provide the hash preimages in the scriptSig to the covenant.

I think you're misunderstanding the problem as this isn't about transaction selection. The issue is, should someone who is mining a more difficult block (say, 2x the normal difficulty) continue mining against an older block even after hearing about a 1x new block? To a naïve first-order approximation, they stand to benefit from doing so because a 2x block would beat out the 1x block and the would be able to steal the fees of the transactions in the 1x block. Of course there are a lot of assumptions wrapped up in that naïve assessment, nor is it clear that it is a reflectively stable outcome (if the 1x miners knew you would do this, how would that change their strategy? how would that change of strategy affect the profitability of this attack? etc.)

Yes, but it is not immediately obvious what effect that has on mining incentives. Someone needs to actually work out the possible mining strategies here.

Work calculations would need to follow the declared work of the block -- e.g. a 3x block is valued at 3x the work.

It's a problem today in contexts such as sidechains where there is no block subsidy. That's why we were looking at this exact proposal internally at Blockstream (alas, I can find no public descriptions of the idea, so we've been scooped!). I share gmaxwell's concern that there seem to be an infinite number of possible curves to use, and it is not even obvious what metric should be used to rate them. It would be ideal to show that for various distributions of priority/fee-per-kb in the mempool that there exist Nash equilibrium mining strategies which result in a stable block size. The block size adjustment algorithm must also do something to mitigate centralization pressures of larger block sizes -- larger blocks make better connected miners have larger apparent hash rates than they actually do, due to differences in propagation time. Neither of these are well formalized yet, and there may be other requirements remaining to be discovered.

A few minor notes: since the difficulty is specified in the block header, it is possible for the miner to choose a block size which is possibly greater than the actual block size by adjusting their reported difficulty (the bits field of the PoW). Additionally, for bitcoin you have the question of whether or not to adjust the subsidy by the same factor. Arguments for and against adjusting the subsidy have to do with whether you want there to be a near-term cost to adjusting the block height.

You can do atomic trade with regular old bitcoin script. Would that qualify for this bounty?

There will be an update coming soon. Although we were unable to secure funding from the community, Jorge and I are working together with others on a currently stealth-mode project that includes aspects of Freimarkets. We are also working on an update to the whitepaper to include all the advances that have come in the last year. Our mental model of how Freimarkets would be implemented has diverged a bit for the better from what we wrote down a year ago.

Guys this is pretty despicable. ALS is a real disease that afflicts hundreds of thousands of people worldwide, and affects the lives of millions of people connected to those with the disease. This challenge -- whatever you may think of the specifics -- has helped raise $100m for research. That is phenomenal! I don't know how any one with a good heart can criticize that.

And yes, we all know someone that was afflicted by this disease. This community owes a huge debt to Hal Finney and I would suggest anyone who cares about bitcoin to take the challenge or make a donation of any size in honor of that man and our debt.

Expired credit card on the auto-renew. Sadly, the junk registrar I used auto-switched to a spam parking host with a very high TTL. A few days out and the DNS caches still haven't cleared out...

ex0du5, the point is that the bitcoin validators can do full validation of the side chain via a constant-time SNARK validation, even one whose rules they don't know.

No, a side chain is simply any chain with an asset that supports some form of 2-way pegging against BTC. There is no reason that side chains have to use the SPV proof mechanism for accomplishing this peg, or merged mining for validation. These are simply aspects of one example implementation pathway that was presented as a proof of concept of how a side chain could be implemented. The design space is actually quite large, however.

Jorge is correct: miners have to know they are building on top of a valid chain, and to do that they need to validate the entire block chain history. The post you linked to endorsed a statement which included this caveat, which your most recent explanation does not.

No, they won't. They'd have no economic incentive to. If a cartel of a few individuals can change bitcoin at will, then bitcoin loses its only redeeming feature and becomes a very expensive, less usable version of paypal. There is absolutely no way that any central party can mandate controversial hard-fork changes to the bitcoin protocol, no matter their hashrate.

One of the posters in this very thread was responsible for funding much of my development time over the last 18 months (not sure if he wants public credit, so I'm not naming him). It's a model that can work... but alas altruists are the minority. It seems, sadly, that most people would rather have someone else pay for the code. Tragedy of the commons and all that.

It is vitally important that we come up with alternative mechanisms for pooling resources to get the necessary projects done, because what we are doing is not working. I have high hopes for Hearn's Lighthouse application, but even more innovation than that may be needed...

Read the first page of this thread. There's a solution involving blinded outputs.

So it's trivially identifiable whose outputs are whose based on the observed offers?

I'm not sure what you're asking for re: timeline. Freicoin was released in Dec 2012, and so it's been live for about 18 months now. You can download the latest official version from the website:

http://freico.in/

There isn't a whitepaper because the concept is quite simple. You can read about it in the OP or the official website. There is a whitepaper describing future additions that will hopefully be included within a year:

http://freico.in/docs/freimarkets.pdf

I don't know of anyone besides me who is still working on UTXO commitments. It is developer time limited right now since for about six months I've been split between multiple projects trying to make ends meet. I posted a summary of the current state earlier in this thread, and any bitcoins or bitcoind developers would be appreciated in speeding the process along.

That appears to be a correct description of SPV+ mode.

I explained myself, twice: