The part of my post that you elided describes exactly why you do not need to hold dollars to buy oil, and why you don't have to end up holding dollars if you sell oil.

Nonsense.  Oil has nothing to do with it.  It takes about a second to convert from any currency to any other currency using FOREX.  Even if the transaction itself takes place in dollars, that doesn't mean that the buyer had dollars the minute before the sale, or that the seller is still holding dollars a minute after the sale.

Gold would add a new wrinkle, but only if physical gold was changing hands at the same time that the physical oil was being (un)loaded.  But most of the "gold" in the world is electronic, in the form of Comex contracts, which are likewise nearly instantly convertible to/from other currencies.

The value of the dollar comes because people want to hold dollars.

Huh?  Lose money?  What?

I don't think you understand how this works.

Do you see the difference in scales?

57,896,044,618,658,097,711,785,492,504,343,953,926,634,992,332,820,282,019,728,792 5,000,000,000,000

If old coins are ever recovered, it will be because of amazing breakthroughs in cryptography, not through better calculating machines.

People have a hard time understanding just how big 2^256 is.

Say that bitcoin was totally distributed down to the satoshi level.  That is, all 21 million coins exist and have been spread around so that each 0.000 000 01 BTC was stored by a different keypair.  Got that?  2.1 * 10¹⁵ different key pairs.  Your job is to find one of them.

On average, how many random numbers do you have to try before you find one?

57896044618658097711785492504343953926634992332820282019728792

You are better off mining.

When you spend bitcoins, you redeem transactions that were previously sent to you.  To redeem a transaction, you have to redeem the whole transaction.  So, the client looks through the database and finds a set of available transactions that add up to more than your spend attempt.  It then creates a new transaction that redeems all of the selected subset and transfers the balance to the destination address.  Unless the spend amount happens somehow to be exactly the total of the redeemed transactions, there will be change due.  This change is sent to a new address pulled from your wallet's spare key pool.

Just to clear up a few things.

The 21 million coin limit isn't in the source code anywhere.  What is in the code is a subsidy that is cut in half every 210,000 blocks.  Actually, it is an integer right-shift instead of a division, so some of the shifts take slightly more than half of the subsidy away.  The sum of the sequence as the subsidy shifts to zero is what gives the limit just under 21 million coins.  So, changing the coin generation system would require more than just commenting out the subsidy calculation.

And a few miners can't just decide to keep cranking out 50 BTC blocks and expect the rest of the network to just accept them.  Not at 51% of the hashing power, not at 70%, and not at 100%.  They would need to create a whole new network of nodes that accept them as valid.  The miners have a lot of power, but they can't force the network to accept invalid blocks as valid.

Also, we aren't approaching the end of the Mayan calendar any more than we were approaching the end of the Julian calendar in 999 AD.  They just didn't bother adding another digit on to their system, and didn't survive long enough to need to.

I suggested a second logfile for security matters so that tools like fail2ban could monitor something with less volume than debug.log.  Adding a second logfile seems much easier than implementing the lockout yourself.

So, your objection is to OP_PUSHDATA?  I only bring it up because BIP17 does that implicitly.  It bangs both parts together and executes them as one.  Go dig for Gavin's objections to BIP17 where he explains that bitcoin used to work this way, and why it does not today.

In the current setup, scriptPubKey is the code, and scriptSig is the data.  If BIP17 isn't executing code by virtue of reclassifying scriptSig into "code", then none of the others are either.

In my view, the script in the transaction output is "code", and whatever is needed to redeem it is "data".  By that definition, all three are executing data.  If you prefer to think of things that are executed as code wherever they may be, then none of them execute data, but that is pretty silly, since it would reduce your credo against executing code into "be careful that you don't execute things that you don't execute".

Sigh.  They all hash code and they all execute data.  The hash is used to verify that the data executed was the data intended to be executed.

You do know that it is trivial to scan all 65535 ports to find the bitcoin RPC interface, right?  And now that you've posted this, I'd be willing to bet that whoever wrote the brute force tool is modifying it to portscan right now.

CHV (BIP17) also executes data, as does OP_EVAL (BIP12).  The debate is over how to execute the data, not whether to execute it.

Hey Tycho, as long as you are here, I see that one of your objections to BIP16 is the magic transaction pattern.  Would you be more comfortable if there was an opcode that triggered the BIP16 mechanism?

I've seen that same objection from a few people, and I have to admit that I have quite a bit of sympathy for that view.

I suggested that we reuse one of the OP_NOPx opcodes as OP_P2SH.  It would remain very much like a NOP in that it did nothing direct, but it set a flag in the interpreter to tell it to invoke the P2SH mechanism if the rest of the script was valid.  Gavin wasn't a big fan, but I think he saw it as pointless rather than harmful.  If the target date slips by without support (and it looks like it will), then it might become more useful.

Well, it isn't really a deadline.  More like a target.  And since we are already into the 7 day window and support has been underwhelming, I think it safe to say that the target will be missed.  So the debate will rage on while support starts creeping in.

I totally sympathize with Gavin though.  I've spent a lot of time on various committees, so I've seen firsthand that no group ever takes a task seriously until the last minute.

There is brute-force tool that targets bitcoin RPC active in the wild.  See this thread.

Can we get an optional low volume log file to be used to report things like failed RPC requests?  Ideally the format should be simple and contain the IP address, so that it can be parsed by fail2ban or other tools.  I think that these failures are already logged, but I don't think that I'd want to point fail2ban at the firehose that is debug.log.

Having RPC throttling built in would probably be safer for most people, but adding a second log file seems easier.

Every node on the network knows the IP addresses of every other node.  More or less.  And the port is well known.

Gavin, do you know what he objects to in P2SH and/or CHV?

If this was just pruning, then I'd agree with you that he had more important things to do.  But this is way beyond mere pruning.  This effectively moves all of the state and all of the history of the entire system into the current block.

No.  Mining isn't like that.