Sure.  All you need to do is prevent that node from connecting to any honest nodes, and feed it a few blocks at the current difficulty.

I get nervous with deterministic wallets.  I very much prefer to generate really random keys for each transaction so that they are totally unrelated.

But, that is silly.  Done right, like the way Armory does it, the wallet sequence is at least as secure as everything else in bitcoin.

You might want to actually read some of his papers or books, particularly the ones on this topic.  Or, you could just watch videos of his lectures.

Please note that I said "a fixed or declining hard money supply", which automatically precludes inflation, whether by fractional reserve or other means.

Since no one else has mentioned it yet, I'll just note that Steve Keen has demonstrated pretty conclusively that interest is totally compatible with a fixed or declining hard money supply.

Typically, these questions come from people that confuse money with wealth, and/or disregard the passage of time.

Money is a tool to facilitate exchanges of wealth.  A loan is, disregarding the bookkeeping done in money terms, an exchange of X wealth today in return for X+Y wealth in the future.  The ratio of money to wealth at various points during the loan are not really important to the loan itself, they are only a factor in the decision to borrow or lend or not, and the terms.

You are setting yourself up for trouble.  Bitcoin contains no concept of a "sender".

You are assuming that the investment must be repaid in terms that you understand.  Maybe someone is rich and just wants to mess with the network.  It seems unwise to make ourselves vulnerable to that sort of thing merely because we wouldn't take advantage of it ourselves.

The problem is that it isn't up to us.  There is no "we".  No one on the entire planet has the ability to prevent miners from picking transactions according to their own criteria.  If anyone is making assumptions about transactions that are not backed by actual, verifiable work, they are doing it wrong, and it is only through good fortune that they haven't been burned yet, assuming that they haven't been burned already.

Not safe compared to how safe people think they are, of course.

One of the central assumptions of bitcoin is that a large fraction of available hashing power is active on the network at all times.  If that stops being true, the system doesn't work.  Fortunately, there doesn't appear to be any danger of that happening.

This has been happening to scamcoins since forever.  If a system is pointless, it will never attract enough work to protect it against a bored bitcoin miner with enough power to divert for amusement purposes.

FYI, the potential "fixes" to the problem actually make the situation worse, as ArtForz showed a long, long time ago.

I'm pretty sure this would lead to more forks, not less.  The time between sub-blocks is short relative to network latency, so the sub-chain would be wildly more divergent than the current blockchain.  Essentially, pockets of miners would be working on their own sub-chains, with no way to reconcile with the broad network until a real block hit.  At best, it would be pointless, at worst, it would lead to chaos.

Better rule changes have been proposed for better reasons, all rejected.  Chain validation is very nearly stateless for a reason.

I'm going to take the pro-SHA/pro-ASIC stance.

Having a single simple hashing algorithm is better than having a difficult one, or having a pool of them chosen randomly.  The reason is that it keeps the barrier to entry lowish for new ASIC producers.

You simply cannot make an algorithm that is, in general, resistant to ASICs.  If a general purpose CPU can do it, then a purpose-built CPU can do it faster.  The best you can do is make it expensive for someone to develop an effective ASIC.  Also, time is money, so if you use a random pool of algorithms, then the only people that will have ASICs are those that can afford to develop them quickly.

Building an ASIC for SHA-256 is pretty simple.  At least 3 different groups have already done it, on shoestring budgets and somewhat quickly.  Increase that to maybe dozens if you include the not-suitable-for-bitcoin streaming hasher chips that are commercially available.  If (heh) they abuse their position as first movers, the barrier to their competition is very, very low, on the order of tens of thousands of dollars and several months to get started.

Making ASIC development more difficult will keep out the people that we want to include, and do nothing whatsoever to exclude the people that some would like excluded.

The script system should be able to handle nearly arbitrary complexity in signing schemes.

Right now, the bulk of the network only supports a few simple script types, so the best you can do is M-of-N.

The good news is that M-of-N can, with a little cleverness, emulate just about any more complex scheme.

Deleting a transaction from your wallet does not remove it from the rest of the network.  If it is still floating around out there, your node will get it back from the network and put it back in your wallet.

For best results, you need to unplug your network cable before starting bitcoin after deleting the transaction.  Then you can create a new transaction.  Be absolutely sure that the new transaction uses at least one input used by the old transaction, or you'll end up paying double.

Actually, leaving it alone is the option that changes the rules the least.  Putting a lifetime on coins is a huge change, regardless of what happens when they expire.

I use a wasp scanner.  It emulates a keyboard over USB and can read barcodes and QR codes.

My paper wallets include QR codes, barcodes and OCR-A text versions of everything.  A WIF in barcode form is too long for my reader to take in a single shot, so I break that into pieces to be scanned sequentially.

I like having the client import a variety of text formats, but I don't see the conversion from printed form to text as a good thing to include.

If only there were third parties that were willing to handle these transactions for us...  Perhaps they could collect a fee for assuming the risk inherent in retail.

How about this?  The customer walks in, picks stuff out, goes to checkout.  They swipe a small magnetic card through a sensor to authenticate.  The POS terminal then checks online to see if a third party is willing to take on the risk based on that customer and the purchase amount.  The purchase amount is then either deducted to the customer's pre-paid balance with that third party, or added to a debt owed to that third party by the customer.

Any of this sounding familiar?

edit: added the word "retail" in the first paragraph.  Damn tablet browser.

I'm sorry, but you have this backwards.

The fundamental unit in bitcoin is 1 BTC, not 0.00000001 BTC.  Right now, the protocol operates in integer units of 0.00000001 BTC, but that is an accident of history (that is, the scaling factor in the first release was 100000000, and we haven't changed it yet).

Changing the scaling factor in the client would be no big deal, because 1 BTC before would still be 1 BTC after.  Renormalizing in the other direction, so that 1 satoshi before = 1 satoshi after, but 1 BTC before = 0.001 BTC after would be a disaster (and thus never gain any support).

You might want to buy an entropykey.

Or, a newish Intel CPU with the RDRAND instruction, but that won't feed the entropy pool in linux directly, so you'd need an offline key generator that was written to use it.

It has been well over a decade since I read Wealth of Nations, but I don't recall him spending much time trying to puzzle out daily moves in speculative markets.

Also, you totally misunderstood me.  Fear and greed are boogeymen just as much as DDOS and government intervention are.  Why? is not a question that has a meaningful answer.  I will repeat my main point: bitcoin is small.  You'd gain more insight by asking why does this fleck of dust rise and fall as it floats in a still room?