The problem is that if you have a drop-off of 50%, that's 50% of the potential computing power of the network that is now disillusioned with mining. And in fact, once you cross that 50% threshold it becomes *more* profitable for such miners to collaborate on forking the bitcoin (in terms of BTC, ignoring for the moment what effect this would have on the exchanges).

In reality people come and go for their own reasons, and you're never going to get 100% buy-in to cheat the system from miners who left. But it becomes a possibility once you cross that 50% threshold, so a conservative approach would be to never let that happen.

Which is why most base-58 codes use only 'L'. Satoshi, for whatever reason, decided to roll his own. Regardless, case *matters* for bitcoin addresses, so it is highly unlikely that someone would type 'l' for 'L', but type everything else correctly...

There's no reason to tell the user they're an idiot and can't read properly

Thanks for the pull, Luke. That was on my list to fix as well.

Yeah, that would never work.

The bitcoin protocol actually has two proof-of-work-functions: one to generate a block (securing the network), and one to generate new coins (setting monetary policy). The 'a-ha!' moment was when we realized these need not necessarily be the same, as they are with bitcoin. With merge-mining the block generating function can be shared across all blockchains, and each chain is then free to set its own coin generating function and policies.

There's some interesting things you can do with this setup; these BOINC-based coins is just a proof of concept for something much grander.

Cute, but missing the point. I don't think anyone is trying to replace bitcoin with @homecoin. We certainly aren't, and I didn't interpret that to be the OP's intention. This is just another practical application of bitcoin technology, like namecoin is.

Transaction fees? It will be merge-mined anyway, so the miners would be collecting coins in other currencies as well.
 The F@H team will effectively have the ability to print money. I've said that earlier--each BOINC (@home) project would have complete control over the crypto-token currency tracking their project. They could chose to rig the system and profit until the deception is discovered (assuming people ever trusted them enough to open an exchange in the first place). Or they could choose the play by the rules and benefit from an expanded userbase.

I work with scientists who run these sorts of projects--none of them are in it for the money. Yes, anyone has a price, but I seriously doubt these blockchains would ever trade for significant real-world dollars, and the science return and community reputation they'd get from having a strong currency tracking their project would far outweigh (in their minds) any short-term profit from cheating their users.

Is that naïve? I'll let you decide, but we *are* talking about small change here, assuming anyone ever opens an exchange in the first place.

 The currency would continue, but I expect that it would quickly lose value as the project is wound down.

 There's a separate blockchain for each project (there's over 60 active BOINC projects out there, last time I checked). Part of our “secret sauce” is a trick that lets us integrate with BOINC projects without any commitment or involvement from them--it will work out of the box with every project out there.

 I think you're completely missing the point of this project, and are far too serious . This is people collecting bottle caps and baseball cards; it's crypto-token monopoly money--one-off blockchains that exist only for a short duration. Each currency is transitory by its very nature, lasting only as long as the associated project, before it dies off because no one cares.

If you participate in an @home project, you are already assigned “credit” (points) based on how much work you complete. All I'm saying is why not let people trade and exchange that credit? Just for shits and giggles.

All in due time

I'll warrant that the F@H people can cheat the system (destroying all value) if they wanted to. But 1) why would they want to do that? and 2) that's the price of doing business--there's no practical way around centralization of work distribution and verification in this context.

You can do both calculations and accept either-or during a transitionary period (and obviously do the old calculation for validation of blocks prior to the transition).

As I said, we've confined just the coin generation transactions to rely upon the F@H servers, and made generating transactions more like regular transactions (so you can have more than one per block, or none at all). So if F@H servers go down, new generating transactions can't be verified. But the network as a whole continues, unaffected.

It's not, but that's the price of aiding and abetting a centralized project. You *can* confine the ramifications of that to coin generation only, however. We have something in the works for BOINC-based projects (the @home stuff).

Stay tuned... 

What fee it calculates depends on what transaction outputs it decides to use to fund the new transaction, and (I could be wrong with this point) I don't believe it does so deterministically. So there certainly isn't a way to do it without all the information in wallet.dat, and that might not even be enough.

This is way off-topic from the OP... but Gavin, why couldn't ArtForz's patch be applied to core? Bumping the interval of consideration up from 2015 to 2016 will have no effect unless nodes are acting dishonestly. And this isn't far-fetched--as ArtForz points out the current situation gives miners significant incentive to collaborate and cheat.

Under the “bitcoin as planned” alternative there is no incentive either way, so fix the off-by-1 and make sure adjustments are +/- the same maximum ("symmetric" by everyone but kjj's definition) and we're done, right? In other words, you need the off-by-1 or asymmetry for this to be exploitable, right?

Also, once new coins are not being generated, the issue goes away as well, right? It doesn't matter how many blocks you generate if the entire subsidy is coming from transaction fees (a blocknumber based demurrage would still suffer the same problem, however).

Other clients won't accept the new blockchain unless it represents more work, which at no point it does... unless you side network has 51% the hash power of the main network, which would make this just a fancy 51% attack (50% in this example), and is not exploitable otherwise, no?

From the OP: “It would (as I said) be an up or down adjustment test, not just for downward adjustments.”

Maybe I'm misunderstanding what you mean by asymmetric?

EDIT: Regarding ArtForz's attack (the one you linked to), it was against against an off-by-one error in the implementation of bitcoin. That sort of thing is really orthogonal to the discussion here. Unless there is another attack he published that I'm not aware of?

Unless I'm seriously misunderstanding, no one is discussing asymmetric adjustments here..

What about ordering blocks with respect to time (just for the purposes of this calculation)?

If you can provide code or pseudo-code of or even just MATLAB code for this, I can bring it into an altchain for testing. I didn't pay attention enough in controls class to follow the discussion here :\

Well, when we release our blockchains and API in a few months, that will be a chance to play with eval().

That is essentially what we are doing for our first release, although it is like swatting a fly with a bazooka. It lets you still do what's been described in this thread so far, but removes nearly all of the other cool things eval() would allow. We've also added strong typing as well, which will let us in time replace the IsStandard() whitelist with a ProvablyDoesNotDoAnythingEvil() blacklist.

casascius, it would be nice if you would custom make them to a specified denomination (while keeping the write-in field in case more coins are added), or at least get rid of the zero value. That way someone won't mistake it as a novelty item.