I can't tell if you are trolling me or not.

We really do get forks every few days.  Here is a list of roughly half of them over the last few months.  http://blockexplorer.com/q/reorglog.

And the problem isn't that free transactions aren't being included in blocks, the problems is that no transactions are being included in blocks.

We get network splits all the time.  And good miners would have an incentive to build off of the blocks other good miners, so the forks would rarely be anything near 50/50.

And most importantly, this gives the antisocial miners powerful incentives to become good miners, without waiting for however many years it takes for fees and subsidies to do that automatically.

You've added a number of assumptions.  The biggest one is that you assume that block rejection is permanent.

Taking out just that one added assumption, and the system works again.  If my node has block X, and another block comes in (call it Y) that has the hash of block X-1 in it, that new block is rejected.  Unless when block Y+1 comes in and has the hash of block Y in it instead of X.  When that happens, block X is tossed out, and block Y gets unrejected.

In this case, if block Y+1 meets the acceptance criteria, block Y becomes valid, even though I didn't like it when I first saw it.  However, if block Y+1 is also an antisocial block, they both remain on the lonely pile until a good miner builds on top of it, or until the X chain grows longer than the Y chain, making the issue moot.

There may be holes in my idea, but I don't believe that this is one.

16 or 20 years from now, when the subsidy has dropped and hopefully the fees have increased, this may be a non-issue.  But today, it is a real issue.  We are paying full price for these blocks, but only getting part of the value.

For the record, I have no problem with botnets contributing to bitcoin, as far as bitcoin is concerned (i.e. ignoring the moral issues of theft of service or whatever you want to call it), as long as they are contributing to the security of both past and present transactions.

Yes.  Because that is exactly how it worked when the spam fighters had the exact same idea.   

The people that need to update to make the change stick network-wide are already aware of this, and have committed to updating their nodes.  See the second post.

The way this has been handled is appropriate for the problem at hand and the network of today.  When either of those are different, different methods will be (have been) used to update things.

Getting more than half of the hashing power onboard is all that is needed for this fix, and that is already done.  The fix does open a tiny sliver of a window of vulnerability where people who are doing things that they know they should not be doing might be at a slight risk if an attacker expends great effort for no gain.

The people that want to eliminate that tiny risk and keep being irresponsible have the option to upgrade.

Also, from your other (crazier) post, github has a copy of the bitcoin source, but the developers collectively have the bitcoin source.

The idea has floated several times to reject blocks that don't contain at least some portion of the transactions that you node is aware of.  Might be time to reconsider it

Of course, it wouldn't be anything as simple as "reject empty blocks" or "reject blocks with less than X transactions".  Those won't work.

It will need to be more like "I see 100 pending transactions that are valid and should be included in the next block.  This block I just got from the network contains less than 25% of them, so I will reject it."  There will probably need to be a threshold too, like "I only see 10 pending transactions, and that isn't enough to enforce a minimum number on this incoming block, so I will accept it, even though it has none".

As a first guess, I would say that a threshold of 10 or 20 and a fraction of 1/4 to 1/2 would work well. 

It has been known for quite a while that a new coinbase with the same hash as an old coinbase was possible and not handled at all.  But since they are referenced by their (identical) hashes, there was no way to specify which one you meant to redeem, so redeeming one would redeem all of them.  This is not in any way a security problem, and can only be used to lose money.  There are faster and easier ways to lose money.

What was only recently discovered was that if you spend a coinbase, and then generate another identical one, you can then spend the second one too.  Spending a transaction doesn't mark that hash invalid for all time, it just removes it from the list of unspent transactions.  Another one can show up and be accepted.  This is, again, not a security problem, and doesn't, by itself, make it possible for people to lose coins unintentionally.

The list of all used transactions isn't readily available, and once pruning shows up, it might not even exist at all.  So, it only makes sense to compare the new coinbase to the list of transaction hashes that are unspent at the time, which aren't subject to pruning.  This also preserves the old behavior of being able to generate and spend multiple identical coinbases, so long as they are spent before the next one shows up.  And finally, it gives us a really short and simple patch, that anyone can read and understand without having to worry that a new side effect has snuck in.

Training?  Psych tests?  LOL.

Section 4.3 of the Xavier paper makes me wonder if they've read any of my many posts about setting an exponential difficulty function for reorgs.

But that isn't the normal use case.  That is merely a normal use case.  Doubling fees with every replacement would certainly turn it into the only possible normal use case.

The URL format was changed.  It was in this thread a couple of times, but tends to get lost in the flow.

Try this:  http://forre.st:9332/patron_sendmany/1/0.001

Got it.  This thread.  It appears to be correct in rc2, but if there is another delay (unlikely), we'll need to adjust again.

rc2 works so far.

Hmm.  I think I need to sit down and read everything again when I have time to be more thorough.  I'm not doing a very good job of keeping "is" distinct from "should be" as I walk through these scenarios.  Also on my todo list, look into how the lock timer really works.  There is a world of difference between absolute time and relative time.

I keep thinking that the network would see transaction # 2 as a double spend and reject it.  But we can't prevent the source from passing it directly to a friendly miner that could include it in a block, which would make it the real version regardless of how the rest of the network felt about things.

I'm not a big fan of mandatory fees, even trivially small ones.  But it does seem to work here, at first glance.

So, every single one of my rc1 nodes is stuck on block 170,059 and refuse to move forward.  While I'm compiling rc2, does anyone know if this is a known problem?

Very unlikely.  Someone would need to plan the attack very carefully, have huge amounts of hashing power hiding offline, and gain essentially nothing from it.

Do the current block validation rules not reject blocks that include transactions with unexpired lock times?

Do we have an ETA on the patch getting merged and included in rc3 or whatever?

Since there are no laws on your island, I could just show up with a bunch of guys with guns and make it my island.  Right?