And now we are back to "You ask more than one, maybe even one you pay for the service".  If you ask two nodes at random, you have a pretty good chance of getting an honest answer from at least one of them.  To be extra careful, which is entirely reasonable if you are hoping to validate an incoming transaction, you could wait until after you get the transaction, then replace all of your connections with new random ones, and ask all of them.

Also, a balance block wouldn't help in this case at all, unless you want the lightweight client to consider every incoming transaction as unverified until the next balance block.

Use the setgenerate true command to enable mining, if for some reason you really want to (but you probably don't).  You can also add an optional third parameter for the number of CPUs to use.

By the way, impressive thread necromancy.  Don't see a lot of that on these forums, most people just post new threads, but you actually used the search function.  Almost warms my heart.

I think that they will become less practical.  Currently there are a small number of miners that are mostly in it for the reward.  In the future, I think there will be a large number of miners that are mostly in it for the security.  Dedicated hardware will make it even more so.

Exponential difficulty increase summary:

Consider the longest honest blockchain fork that is likely to happen innocently, now pick a smallish number, still somewhat greater than that, call it X.  6 is probably a suitable number for X.

A node gets a new block in, that extends a side chain instead of the main chain.  For the new chain to replace the main chain, the node must replace a number of blocks, call this Y.  I don't think that Y has been greater than 2 yet.  By my estimation, it should happen every 27 million blocks or so.  But my estimate is based on a tiny data set, there could have been a 3 or 4 block reversal in the early days that I don't know about.

Now if Y is less than X, the chain with the highest difficulty wins (this pretty much always means the longer chain).

However, if Y is equal to or greater than X, it calculates: current_difficulty*2^(Y-X).  If the difference in difficulty between the current chain and the proposed chain is greater than this amount, the proposed chain is accepted.  If it is less than that amount, the proposed chain is still ignored, but kept on hand in case it continues to grow.  Notice that 2^(Y-X) grows rapidly, quickly exceeding even unimaginable hashing power.

The side effect is that it can cause a fork in the chain to become permanent, at least until humans intervene.  But this side effect is unlikely, and the more nodes that would need to be fixed by hand, the less likely it is.  If the earth was literally chopped in half, and all radio communication was prevented between the halves, we would have a hell of a mess to sort out.  You know, after we defeat the aliens that cut the planet in half, and glue the two halves back together.

I think you are very, very wrong about the bolded part.  You know my opinion of the unstable comment, so I won't bother repeating it.

Because we finally have a system where what is mine will always remain mine (even after I die) unless I fuck it up myself.

You have the option to run your own full node too.  Presumably it wouldn't try to deceive your own lightweight clients.

Oh, and if you keep track of your own spending, which would make sense, you don't have to worry about a node forgetting to tell you about it.  Plus, the client could check them all, either from time to time, or any time a new key is imported.  We could even attach a record to the key in the database indicating the current block number when the key was created, so that only blocks after that need to be checked.  Etc, etc.  The amount of work saved by having balance blocks is pretty low compared to the crapton of data that would necessarily need to be in them for them to be useful.

Meh.  Took me like 5 minutes to modify the work_data table, add new history tables, write a cron job to rotate the records out, and post my scripts.  Bonus: I didn't even have to think of any clever SQL tricks.

If chain reversal required an exponential increase in demonstrated difficulty, rather than merely an improvement over equality, a transaction could be made absolutely safe after some number of blocks have passed, instead of merely statistically safe.  The effort would be minimal, and my estimate of the side effects are likewise minimal, but there is no desire to do even that, because block chain attacks are horribly impractical, even today, and they get less practical by 40 or 50% every couple of weeks.

Do you know about every fiat currency ever tried over the last 4 thousand years or so?

The point is:  what do you do if it was today and, due to the public's general fear that 10 trillion or 100 trillion dollars could be dumped on the market over the next year or two, people, in general, when receiving payment in it, immediately cash it out for something else, driving its value down even further?

To answer your questions, I would not "put my wealth" in it, not for your reasons, but because I never do that; I know the difference between money and wealth, it involves using one to buy the other, but I'll let you sort out the details on your own.  And yes,  I would still be pretty confident, for reasons already explained, by me and several other people, in several unique and colorful ways, all of which you have ignored.  And finally, no, I still prefer a system that is capable of neither destroying nor redistributing bitcoins.

Perhaps in the year 3535, people will rue the day we rejected your idea, but I'll leave that to them.

It is much harder to reverse a transaction that is buried in the chain than one in the most recent block.  If the recipient waits 5 blocks, even an attacker with half of the hashing power in the world has about a 1.5% chance of reversing it.  And that is assuming they start now and work until the end of time.  What fee would be large enough to make it worth a miner's time and effort, but small enough that the recipient won't wait for it to get buried?

You ask more than one.  Maybe even one that you pay for reliable information.

Check out the join that creates the status display.

If history is any guide, they have every incentive to do this, just not all in the one day.  The value of each and every fiat currency not currently in use ended up at zero.  Actually, a lot of metal currencies ended up turning into fiat currencies through debasement, and then end up at zero.

Did you see the image I posted?  It wasn't caused by some unknown entity, it was caused by the entity in control of that currency.  And it wasn't for unknown motivations, it was caused by a desire to spend money that the entity did not have, a motivation common to everyone.

For further amusement, I chuckle that you find the system-preservation motive sufficient when applied to a type of entity with a 100% track record for destroying currencies, but reject (or at least ignore) the same motive when applied to an entity with enough coins to ensure that he and his family live like kings for all eternity so long as they don't destroy the system that is willing to give them goods and services, essentially for free.

It should be trivial to calculate how many blocks to wait before accepting a payment as valid, based on an estimate of the fraction of the world's hashing power under the control of the single largest corrupt mining organization.

Looks like we hit our 1,000th block during the chaos!

Thanks again for all of your work on this.

The ratio for dollars is zero right now.

I really wish that more people would try to read Keynes.  His book (the famous one) is incomprehensible gibberish.  Ozzy Osbourne makes more sense.

If more people had that sort of personal exposure to his writings, there would be fewer of these threads defending his ideas as sacred.

You can actually stop here, and you don't need a balance block at all.  A lightweight client only needs to verify all of the headers, and then have a way to fetch full blocks as needed.  All that is really needed is a new message type in the network protocol that will allow a client to ask a node for all blocks that have transaction going to a given address.

I think I'm missing an implied step in there.  How is the hash useful as security to them?  Couldn't you just fail to broadcast the send after you get the reclaim?

But we could just skip that step entirely and end up in the same place.  They give you the reclamation transaction first, and then invalidate it (as described earlier) if you fail to send.

Is it really difficult to understand why debt is a bad thing?