A couple of approaches or workarounds...

One is in use by GMC (General Mining Corp) and GRF (General Retirement Funds). As their value and/or price is not specifically tied to or pegged to BTC, they exerience potentially greater flexibility in this kind of application. (If their investments/loans fail, their value in terms of other currencies (such as, for example, BTC) might well fall.) Both GMC and GRF provide secured loans featuring associated repossession agencies.

Another is mortgaging your BTC. That is, put BTC up as collateral for loans denominated in things other than BTC itself. This approach can be used for such things as borrowing fiat to buy BTC which in turn can become more collateral to borrow yet more fiat to buy yet more BTC and so on. (Careful of margin calls in doing that, of course. )

-MarkM-

Well maybe being a little clearer as to which country you meant could be helpful.

I jumped in thinking it might be yet another Freeciv Galactic Milieu nation that only trades with other bitcoin-type currencies not with fiat at all.

-MarkM-

Brute force? What kind of brute force? GPU-amenable brute force?

-MarkM-

Then don't offer such a service.

Keep it as an in-house capability useable only by employees and maybe shareholders of the GLBSE-listed concern that owns the license.

-MarkM- (P.S. no maybe about it, shareholders are owners so it is theirs to use...)

P.P.S. No, wait, maybe current owner doesn't want to donate/sell it to the concern. Can employees use their copy at work?

Actually it is 2043 for the computer crash isn't it?

Bitcoin was going to crash in 2063 due to being assimilated by the Borg, but Jean Luc took care of that for us so we're ok through 2400+ now.

-MarkM-

I have received the 5 BTC, thank you.

The specific DB exception problem seemed to be that neither of the two machines I was running it on had been able to download a blockchain from the other.

Both expected to initially download the blockchain but neither actually had any blocks to offer as both had only the genesis block.

I hoped this problem would solve itself once at least one block had been generated by one or the other of the two machines.

However I have now found that not only did that not happen but in fact once a block had been generated stopping and trying to restart resulted in a core dump instead of the DB exception thing.

If each client makes up a new address to generate coins to, presumably that means each client is trying to generate invalid blocks until such time as they arrange to have that address added to the database of valid miner's addresses?

I doubt I can merge your version with the version I have been deriving from the original bitcoin-qt, for example doing a diff of your db.cpp and the db.cpp currently in bitcoin-qt there is much much more change than just your vchGenerateKey stuff.

-MarkM-

Finally! Thanks! (Merchants getting paid in the currency of their choice regardless of whether customer uses BTC or whatever else.)

-MarkM-

We don't imbed the IRC client inside the bitcoin client because if each and every application did that it would a vast waste.

Do you imbed firefox or internet explorer into every application whose user might like to look at a web page?

I would hope not.

But maybe you are a Windows user and actually would prefer every application to be as big as the collection of all applications due to all having all the others inside itself?

On the other hand would you really notice the difference if we made the bitcoin package install depend on (and cause if its not been done yet) the install of an IRC client, and then fire up an IRC client for you any time you would like to do some trading with other users?

Ah heck, why even bother, we can fire up internet explorer for you, sending it to freenode's webchat interface targetting #bitcoin-otc

Would that truly be so horrible that you'd rather we put a whole extra copy of internet explorer inside the bitcoin client itself?

Should we also include a whole duplicate of each voicechat system you might find some other users of bitcoin on so you won't have to type but can simply talk to them? But wait, does Skype even give out its source code so that we could imbed it into bitcoin?

-MarkM-

I came up with the idea of using an intermediary currency to interface with chargeback-prone currencies.

Maybe call it PalCoin or something like that.

We keep track of how much of what has been spent on it has been charged back, and use that to set exchange rates for it.

In six months or so any PayPal spent on it will hopefully be beyond the point where it could be charged back, but if only PayPal is ever spent on it (in other words if PayPal is all it has in its reserves to "back" it aka to "buy itself back" with) it would be potentially totally worthless for the first six months following its first purchase of PayPal money (aka PayPal money's first purchase of it).

So okay maybe it won't actually get to have PayPal as one of the currencies in its reserves, but that would be PayPal's fault not its own.

It would maybe be like back in the era when Bitcoin was dirt cheap. PalCoin would be almost worthless due to being backed by pathetic stuff like PayPal or Credit Card money. If it is so nearly worthless you ought to be able to pick it up cheap, right?

So maybe buy 10,000 PalCoin for one Bitcoin, then sell it to credit card users "hey guy why mess with Bitcoin, that will take days and it will cost you several dollars per coin! Buy PalCoin though and I can give it to you right here right now instantly, 100 PalCoins for a buck!"

-MarkM-

Okay, I think I have figured out that DB exception.

I have also created myself an account on github and forked bitcoin and groupcoin so I'll be ready to publish any changes ("pull requests" I guess they are called).

I have not actually published any changes yet though.

I cannot figure out how/where you are setting the actual value of the vchGenerationKey.

You seem to be storing them in the wallet, so you are presumably also loading them out of the wallet, but I do not see any place where an actual value is assigned that isn't simply another variable (where does 8that* variable get it from?)

So I do not see any example of how to put an actual string - a copy/paste of an actual address - into vchGenerateKey.

I can run the thing, generating blocks and thereby generating addresses that will have to be regarded as valid eventually since they are in the blockchain. I was going to paste the first one thus created into vchGenerateBlock so that I could have that same address continue to be used for subsequent blocks until such time as we get more addresses to plug in and some kind of database that can be used to validate the blockchain against the set of addresses that were valid at each point along the blockchain.

(You do realise, don't you, that if you want to invalidate an address from a certain block number forward you will need to record along with each address the first block at which it started being valid and the last block that it was valid?)

-MarkM-

A lot of quantum mechanics purported spookiness rests upon Bell's Theorem.

So before getting too carried away about what quantum stuff can do, it is probably worth checking out

http://front.math.ucdavis.edu/search?a=Joy+Christian&t=bell&q=&c=&n=25&s=Listings

-MarkM-

Re-read, with particular attention to "directly hooks into an exchange".

If you don't have an account at an exchange but you don't want to wait for your beer, open an account at an exchange before heading out to the pub (or while waiting for confirms on your first beer order). Any exchange that fails to join the exchange-to-exchange SWIFT - uh I mean fast - private network so their customers can get quick service at retailers using any exchange on that private network might just not be the favourite exchange, at least for retail purchasing applications, of most retail-shopper types.

-MarkM-

I now have the thing running initially, but after I exit the next time I try to run it a popup comes up complaining about blkindex.dat

At the commandline it output:

terminate called after throwing an instance of 'DbException'
  what():  DbEnv::close: Invalid argument
Aborted (core dumped)

I saw that you added code to plug in addresses for coins generated to be sent to, but, I didn't see you initialise that, where is it supposed to get those addresses from?

You seemed to be putting them into the wallet?

I don't see what if anything that would have to do with blkindex.dat though so i don't know what you did that might be messing up the block index.

Guess it is time to go through these same steps (firing it up on two machines, connecting them with -addnode, using -gen=1 to try to get them to mine) with the original bitcoin-qt just to make sure it is in fact something you or I did that is causing the problem...

-MarkM-

PP: even if I did prefer GRP to BTC, why would I prefer it to MBC, NKL, CDN or UKB?

Thanks, that .pro file might be the magic bullet.

Thanks denominated in BTC can be sent to the BTC address 1E5RcwrLGpKSSEELyg5ZbqzJaQ3XyqgULp

-MarkM

Do you literally want faster block generation than BTC's average of one block per ten minutes?

Ten minutes was chosen based on a planetary scale of operation: too fast to allow computers on Mars (maybe on Venus too) to partipate but slow enough that even old accoustic coupler modem connections might suffice if located on Earth, or something like that.

How fast do you want blocks?

How fast would allow even the slowest connections in town ample time to participate yet possibly effectively at least discourage distant towns, especially on distant continents, from participating?

I do not think trying to identify miners at their end is a good approach, I think better than trying to certify miners at the mining-software end is to simply have a set of approved addresses that minted (or even mined, meaning minted plus transaction fees) coins must go to in order for a block to be valid.

That way anyone can mine, even "angel GPU miners" (or angel ASIC miners etc etc etc), but either their only reward is the fees or their only reward is the warm fuzzies plus any gains they can get by trying to attack the network, unless they manage to log in to an approved pool.

Approved pools have means to cause the addresses all minted (or even all mined) coins go to to release funds. They can thus use these funds to reward pool participation.

Obviously we are talking alternate blockchain of course, since running at a high rate of block-creation will cause parts of Earth to experience problems similar to those experienced by all of Mars (maybe even Venus too) with the BTC network, depending on just how fast exactly you want your average rate of block creation to be.

-MarkM-

What happens if someone commits fraud / computer fraud / theft / computer theft / wire fraud / wire theft, in other words?

I think there might be some legal rulings or precedents already on the books in various jurisdictions about such activities.

Without getting into specifics, I can say that in general they do seem to me to tend to frown upon such activities.

Possibly the main problem would be ensuring that by the time you are able to convert whatever recompense you might be awarded by the courts back into bitcoin it does actually come out as about the amount it was intended by the court to amount to.

How anonymous, in reality, are people who control >50% of the hashing power, typically?

-MarkM-

If more than one blockchain-based currency exists, and they are compatible to the extent that using one or another of them is trivially simple, maybe something like having a default high security high transaction cost one and a default low security low transaction cost one potentially for each locale in the locales system there should be less worry about free riders in the high security high transaction fee blockchain(s) because they will have other chains to ride that offer them a greater chance of obtaining a free ride.

Exchanging back and forth between chains should be pretty simple, hopefully far simpler than trying to exchange back and forth with fiat currencies.

-MarkM-

For the various other blockchains that are building reserves of BTC with which to "support" their own coins' value, a declining price of BTC sounds good, as obtaining the "reserves" they want would become cheaper over time.

There are plenty of people who love seeing the price of BTC dip as it gives them yet another opportunity to pick up some more BTC at time-relatively "bargain" prices.

-MarkM-

What "should" be happening, if the various "nations" I have been developing "national currencies" for have any useful insight in the ways they plan to try to get their "national currencies" up and running, is...

1) Make sure to have a truly significant portion of the total number of coins so far made at some point in time.

2) Try to obtain a truly significant portion of the other currencies that people use to buy your type of coins.

3) Once you have truly significant "reserves" of "other currencies", start trying to "support" your type of coins by buying back, at less than you sold them for, any that anyone wants to sell.

This assumes the "nation" creating the currency actually plans to stick around and actually support its currency, instead of being just a fly by night nth-world micronation established mostly for the purpose of trying to 'con' other nations into accepting its ponz^H^H^H^Hcurrency long enough to raise a pile of loot to fade into the sunset with.

-MarkM-

Actual bitcoin-qt was not hard to compile, mostly I just had to tell it about ../deps/include and ../deps/lib so it could find the openssl I compiled with the parts bitcoin uses that Fedora prefers not to include in their distributions.

Maybe you could do whatever clever git thing it is that git users do to bring their branch up to date with the latest main branch or something, as yours seems rather nastily broken.

For example your Makefile wants there to be a .pro file but you have not provided that .pro file.

Also qmake-qt4 just works with the main branch, but in your branch it spews a whole bunch of help about things like having a -project mode and a -makefile mode, evidently it is confused as to which to use. Only by doing both a few times in various sequences did I get a Makefile that even attempted to compile, whereupon i am back at the unexplained Error 1 again.

Backburnered for now pending fixing of your branch I guess.

-MarkM-