Please read this post and then you can go back to your ad homs.

By reducing the blockchain to the current unspent txOuts, he was able to reduce the total size from ~1GB at the time to 75MB, the majority of which was taken up by the scripts. Without needing scripts for standard tx, that could probably be cut in half, and if unspent txOuts were reduced to account balances it could probably be cut down to 1/4 that. The biggest change that would entail is that txIn would take the full value of the account rather than the full value of each referenced txOut, which would no longer be required for txIns. You would still have to store a few weeks of blockchain on top of that, but that's still < 100MB easily.

As for the method by which addresses are created, I never said there weren't reasons for it, just that it could be done better. Hash of pubkey+checksum+version = 2 levels of abstraction. Pubkey + checksum + version = 1 level of abstraction. On the other hand, for what I have in mind it may not even require reducing the abstraction, just creating a second address type. The main reason for reducing the abstraction is so that both need not be included when signing a tx, which might reduce the raw blockchain size by a small amount, although any amount becomes significant at 100tx+ per second.

Miners running off of centralized pools are already "dumb", and that with the current blockchain bloat this tendency toward centralization is guaranteed to continue (I don't see droves of DeepBit members jumping on the P2Pool train) which would basically defeat the whole purpose of BTC as a decentralized anarcho-currency. AFAIK pruned merkle trees can only be used to verify your own balance, and not anyone else's. That is, you can't mine using only that, and you if you can't mine then you also can't verify a tx someone has sent to you.

I can see really two problems with the smart card proposal.

With a smartphone, you can have your home desktop computer act as a server for your phone's app and then it's easy to limit the liability of how much money you can lose if someone steals your phone.

With a smartcard you could do basically the same thing, store the private/public keypairs for some pre-made accounts that you want to spend from along with the reference txOuts, and some software for negotiating/signing tx.

However, in order to make this work, you have to have your own smartcard reader to load it with money, which may or may not be expensive for your average user (or maybe not?).

The other thing is the sneaky merchant problem. Most smart cards are designed to be used with a tap of your wallet, so a screen would basically defeat the point, and a button on the card would be too easy to accidentally activate (or too easy for a thief to use). The only way to completely circumvent that problem is to have something with basically the capabilities (and independent power source) like a smartphone, where the merchant has no direct control over what is sent. Or else a card with a screen, a pinpad, a cancel button and a "lock price" button, which wouldn't be so easy to use one way or the other and isn't available since most banks can just do a chargeback instead.

Well, I can see quite plainly that BTC is still around. However, that was what? 2-3 years from its beginnings? Every year more BTC users and miners are added to the overall pool. How long until the people not paying attention outnumber the people who do? What happens if some change requires a major update to clients as well as miners?

Moreover, if I'm not mistaken when the overflow bug was discovered, the devs issued an "emergency alert" similar to the "check for new updates" function present in basically all other modern software. This feature, while only a half-implementation of automatically detecting new updates, has since been disabled. I don't know that there's even a "correct" answer to that problem, with the complexities of alt clients added into the mix.


I have read most of the arguments, as well as a lot about the protocol itself on the wiki. That is how I know that many of the design choices were either economically or programatically unsound.

There definitely needs to be a connection between accounting and the security of that accounting, but there is no need for them to be inseparable, and ultimately the accounting is more important than documenting the security forever, not to mention potentially orders of magnitude more efficient spacewise.

There does not need to be any direct connection between standard tx and contracts with complicated scripts. Standard tx have no need for scripts, and of the few (like 2 at most) scripts that have an actual use, they could be simplified a great deal. Currently you can't even use the scripts that are useful, ie the minimal trust escrow feature.

Finally, the "solution" of pruning the merkle trees of previous tx doesn't help miners any, and furthermore excludes clients (ie anyone who doesn't own a giant server cluster) from verifying tx for themselves. Not only does that kill decentralization, but it also stops merchants from verifying tx, which means either they can't use BTC or else the customer has to stand around for an hour or so waiting for the first confirmation. I don't call that a solution at all.


Sound economically? Sound in terms of programatic and storage efficiency? Sound in terms of flexibility?

That's too vague to agree or disagree with. I still have yet to read the whitepaper, but I'll get around to it soon enough. ATM I couldn't tell you specifically what in terms of satoshi's theory I may agree or disagree with, only what I've seen in the actual implementation thereof.


Perhaps. That depends on what hooks are left in the original client for this and whether or not they are flexible enough to allow what needs to be done. It also depends on how standardized said hooks are, and whether there will be disagreements on how to extend the implementation. In terms of shifting decimals fluidly and the storage of the values and the standardization thereof there's a whole lot of room for compatibility to break. The longer implementing it in a standard way is put off, the worse the potential disconnect becomes.

I'll have to read the whitepaper to see if it says anything specific on the matter.

Like they did with the overflow bug? It may be true they can't now, but it could be necessary, and/or it will take a very long time to get everyone to upgrade. Assuming it doesn't get broken because people "upgrade" themselves to game the system.


When I say "stupid and unnecessary things", I mean the 2GB blockchain that's been generated in only three years and with provably less than 5-10 tx per minute! At VISA levels that's totally unsustainable. 90% of all "usages" of scripts and contracts are totally economically useless and will probably never be used by anyone for anything, whereas per file size scripts take up the vast majority of unspent txOuts that need to be tracked. The only thing BTC really is is a giant, overglorified balance ledger sheet, that needs only to track unspent account balances per account in order to be accurate. Instead it tracks unspent txOuts individually, which then all must be put into txIns individually in order to be spent, yet again multiplying the size requirement of the blockchain.

If the blockchain had been engineered to efficiently fill its primary purpose- simple yet secure monetary exchange, rather than a bunch of useless contracts by default, then the blockchain could be < 50MB rather than > 2GB. I consider it a product of Satoshi's economic ignorance, although beyond that I can't read his mind so I don't know what else he was thinking when he designed it to be such a complicated mess. The abstraction between public key and address hash is also extra without actually providing much benefit (unless you want to keep your SHA256 pubkey from being stolen by quantum computers.. which would make bitcoin useless in about 50 different other ways anyway).


21,000,000,000,000.00
The number of BTC that will ever be produced (est) with 1 satoshi = 1 cent per decimal places, and what you get is 21Tn, or about twice the M2 money supply of the United States, only divisible down to 1 cent.

A uint64 could potentially hold about 50 times as much (although that's questionable given that it was set up backwards it probably can't fully use the uint64). Comparatively, absorbing the world economy and still maintaining divisibility so that tx fees are still reasonable compared to exchange value would require maybe 20 times a uint64 at minimum, given the disparity between current economic status and potential economic output.

More importantly, the means for changing the decimal place rests solely in the hands of the programmers, as there is no user-defined setting for it. That means as prices shift and the currency appreciates, users and merchants will not have any means of shifting what is considered a "base unit", and no way of standardizing what they mean even if they implement that functionality privately. Having to complain to the devs about something basic like that in regards to the protocol really defeats the purpose of decentralization of the currency, or at the very least makes it cumbersome to use.

Yeah that was the impression I got, too.

On the topic of SSL, public keys could simply be attached to NC addresses for .bit, but that's another topic for another time .

Well, the general problem with using the usual SSL protocol is that it requires registering with a CA, ie the US Department of Internet Regulation. Using an off-the-grid SSL system through the blockchain avoids this.

However, I'm still not exactly sure what it is the OP is trying to accomplish with this. There may be a better solution for whatever specific issue you're trying to solve.

Basically what you're asking is impossible. The only way to protect yourself from arbitrary government confiscation is either
A: Keep records and cough up like a good little peon if/when they come breaking down your door.
B: Keep your servers behind Tor and don't advertise any payment addresses publicly, nor make any public connection between you and your service.
C: Keep a blacklist of traceable money that came from an exchange so that you only accept pre-laundered money. Seems kind of stupid imo.

You could possibly use a reverse escrow, but you're still talking about single handedly policing the entire BTC economy for money that you will accept and money that you won't. The whole point of BTC is that your money is your personal responsibility, and if it's stolen, too bad. The correct solution economically is to maintain some form of insurance (like a bank does to cover defaults) and to minimize the side channels by which your accounts can be compromised.

If running a gambling operation happens to be illegal where you live, your local government may throw you in jail anyway whether or not you're declared guilty of laundering.

Personally I agree with Eto's solution, which was basically the inspiration for my idea (along with a suggestion by David Schwartz). My idea is basically to have a separate key type for encrypting messages, which can be sent as part of a tx. The message format would be standardized, with the only unencrypted parts being the first and last digits of the receipt address. To find out if a message is for you, you simply decrypt any messages with a first/last digit matching those you own and see if any of them come out with the correct formatting. Any return addresses or text replies are encrypted and only available to the recipient, whose own address is only slightly revealed.

That way all funding details can be worked out privately before an account is funded without exposing you to side channels where your information could be stolen or used for illicit purposes without your prior consent. Since they can provide you with a signature pubkey for withdrawing funds, it doesn't matter whether they provide the return account immediately or later or if they change it since you can verify that it's the same person who opened the account.

That way, if you're paranoid, you don't have to publish a public funding address anywhere, even for donations. You can require people to pm you to get an address to donate to first, and/or keep a separate address for accepting anonymous donations (which would also be possible with my system). I've never heard of a BTC police sting occurring (yet), but it's not impossible. It's possible to minimize your risk of that happening to you, but that's really not a subject that belongs in the development forum IMO.

I thought of a way to do "secure SSL" messaging on the blockchain to avoid direct connections between payment and public addresses. I'm not sure if that would solve your problem or not, but canceling or refusing a tx would require sending your cancelation to all miners, and that they accept your cancelation rather than mining the original tx into a block. It's probably not practical to do it that way for several reasons, and it would definitely require a protocol change.

If your goal is to prevent people from using your business as a laundry service between the exchange and the network at large, I'm really not sure if there's anything you can do besides keeping records to cover yourself, which I assume you're trying to avoid.

Possible now because the network is small and tight knit and the developers can "Stop the World" whenever it's necessary to make major changes to the protocol. If/When BTC is as big as Visa, even minor tweaks may be completely impossible without breaking the clients for half the users on the network.

In particular, I'm not sure how BTC values are stored, except that Satoshi did a lot of stupid and unnecessary things. Even if shifting the currency to the left by one decimal doesn't break backwards compatibility with clients, it would at the very least cause a great deal of confusion. Moreover, it's something that won't even be remotely relevant until decades from now, when the market cap of BTC is either zero or unpredictably large.

Not counting coin losses, BTC is only capable of holding dollar influx equal to $21Tn before it is no longer divisible by units smaller than $.01 without absolutely increasing the division. Admittedly, that's not much of a problem since BTC and the blockchain don't scale properly to that sort of throughput anyway.

Here's another proposal (similar to the first link provided) for a "ledger". I think this guy actually went so far as to implement it, and it seemed to be very well thought out.
https://bitcointalk.org/index.php?topic=52859.0

I think a major point that's missed about BTC is that, for all intents and purposes the only thing it's really doing is keeping track of account balances. All of the fluff and noise on top of that makes up the rules of how they are managed, but most of the work being done is extremely superfluous. Granted, some of that is on purpose in order to allow for various kinds of "contracts", but for the average tx all of the extra features just end up bloating the blockchain to a soon-to-be-unacceptable size.

One thing I noticed after digging through the protocol details is that the "balance" on any BTC account you have, rather than being stored as a single, current balance, is instead made up of every tx that was ever sent to that address. So, just as an example, say I have a donation account, and 100 people send me 0.01 BTC each. So, my donation account has a balance of 1.00BTC, but in order to spend it, I have to make a tx with 100x 0.01 tx donations as the input. As fees and blockchain size are directly related to the number of txIns and txOuts, half of my donation fund might end up in fees and then everyone who has a copy of the blockchain now must include a block with 100 txIns for one of the tx, even though the total balance of my account was a single value of 1.00BTC. If standard tx were highly simplified, it would save a whole lot of disk space and a whole lot of trouble.

Another thing that could be done, is that for p2pooling, rather than storing the whole blockchain each miner could store the latest ~4032 blocks (28 days), plus a random 4032 block "period" from the last 13 periods of 28 days (ie 364 days of blockchain total). When the extra period a miner is holding expires, they simply replace it with the latest 28 day period that would otherwise be discarded. Along with the ledger system, that would allow miners to run on less than 1/4 the size of the current/total blockchain, and they could still seed it to any clients requesting it torrent style. Really only a year of blockchain is needed for security reasons. Older sections only have historical value for those wanting to prove that the initial block rewards really are what the wiki says they are. As per the link above, a client would only need to store ~2016 blocks and a ledger, which amounts to even less total size.

As for the "government attack", that can only be avoided by improvements to the protocol itself and tightening of the blockchain validity criteria. For example replacing BTC's highly subjective "network time" with an NTP, perhaps merging with NTPool should allow latency-adjusted network time to be kept accurate to within less than 1 second. With some heuristics to prevent attackers from inventing the current time easily along with block timestamp restrictions of maybe 10 seconds, timejacking and block hoarding attacks would be nearly impossible, and certainly impractical since the window for double spending would be only seconds.

Above and beyond timekeeping, Meni's Proof of Stake system allows for checkpointing to be done often such that blockchain reorgs have a maximum depth that can be kept to ~24h. It would probably be very difficult to implement from the current protocol, but it would make the whole network very "sticky" to the current most-accepted blockchain, giving even the most effective attacks a very limited ability to do damage. At most the network would be disorganized for the period of the attack, but older historical parts of the blockchain and their associated tx would remain firmly in place.

If some attacker were to spam a fake blockchain, on the other hand, it would only affect new users or machines where the BC had not been downloaded yet. Unless said attacker were prepared to completely blind said user to the internet at large, there would be some noticeable problems for the client in using the BTC network. For example, if the blockchain they downloaded was fake, and then they go to receive coins from a legit part of the network, the blockchain info they had would not match the transaction received to their account, and they would see it as invalid. Obviously, the only way around that sort of attack is to download the blockchain from an alternate source. Given the relative ease of supplying a reliable copy of the blockchain via various methods, and the difficulty of censoring all of them, the payoff vs resources required for such an attack would be mediocre at best regardless of the intent.

Lol I think this is more about counterfeit than it is about murder x.x

I'm not talking about a network DoS. I'm talking about DoSing the blockchain and its functioning.

http://bitcoin.stackexchange.com/questions/1099/string-along-is-this-possible-and-is-it-an-attack
http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html

Some combination of the above while only generating empty blocks, and virtually no tx will get to the blockchain anymore. If enough tx back up, it can become impossible for all the backed up tx to fit in a single block, and once that happens tx will be dropped more often than they succeed.

Well, I think this has gotten a bit off topic, but I agree. MtGox got what they deserved because they were fucking stupid and let themselves get social engineered and had all their passwords stolen. Not only that, but their recovery of people's legitimate accounts was piss poor, and AFAIK is still leaving some people stranded.

There are plenty of ways to avoid that sort of thing, and plenty more being developed (like BTC address signatures). If you're going to run a bank, exchange, or other business which deals with other people's money, you need to do better than that. If anything, MtGox should go out of business. Sure, the people who robbed them were douches, but it was ultimately MtGox's responsibility to safeguard their clients information, and they failed, and then tried to blame it on someone else.

I don't know that "coin melting" will actually solve that problem to any extent, or make it any harder for them to track "tainted" coins. Not like keeping some kind of coin blacklist is going to do anything anyway. MtGox is never, ever getting those coins back, so trying to put restrictions on them is impeding the currency in general just to make MtGox look less irresponsible than they really are. If you want to police other people's lives, you're in the wrong place; BTC is all about personal responsibility.

The US government happily spends $1 Trillion every year in bridge to nowhere projects. That's 1000 billion dollars. 100million would easily erase BTC forever, and there's absolutely zero that could be done about it. Mind you I'm ignoring any current computing clusters they might have available to compete.

Sure, it might be obvious that something is going wrong, but let's not forget who invented Tor, so if you think it will be easy or even possible to stop, think again. If the government wants to DoS BTC, then BTC will be DoSed. The developers would have to spend all their time trying to come up with some sort of counter-strategy, and development on the actual features of BTC would stop (best case scenario). However, given a few months eventually people would give up interest, and that's the end of that. Since the government can play by the rules and still do damage, there's basically nothing you can do against it.

Furthermore, timejacking attacks and similar don't even require 51%. There's some evidence that certain pool operators may be doing this already, although for the most part pool operators have refrained from causing trouble. (well, except for luke jr, and all of that noise)

Finally, at a current rate of only 80tx per block, it's totally unknown how the network will behave if/when things get really busy. It's also unknown how things will play out as the mining subsidy drops off, although already there's problems with empty blocks and botnets and such. An unreliable network is worthless to someone who wants to do business. Imagine if VISA transactions could be randomly dropped and had to be resent, or if it took an hour or 6 hours just to be sure that didn't happen. There would be no VISA. Not only that, but privacy on BTC sucks, which is one of its supposed main advantages vs centralized money. While there are a few ways privacy could be improved (that I know of thus far), an improvement in blockchain reliability would require some major changes to the protocol, and it's not necessarily obvious what would work or what wouldn't. That sort of effort isn't likely to happen unless its with another currency, or in BTC until it's much too late to fix.

I never said that cryptocurrencies were a bad idea, or that they can't work at all, just that BTC is an experiment and likely to come crashing down at one point or another.

It's not one "great flaw", but rather a war of attrition.

51% attacks could be used to destroy the currency basically by any government who cared to do so. At the current price of $21 million hardly any government around today would sneeze for that cost. There are a number of ways that 51% could be used malevolently, including timejacking attacks, block reversals, empty-block DoS, and so on, some of which may be appealing to self-interested miners, which may lead to problems with internal monopoly.

Other problems include difficulties with consensus if some major change to the software or protocol was required. A central agency (like a bank) can just take some of their servers offline and run off a backup. The same can't be accomplished in BTC without breaking the blockchain to bits. The blockchain is also an economic weakness since it requires common ownership of a limited, and worse yet time constrained resource.

Finally, issues with privacy for users and security for merchants makes the currency relatively unattractive for someone wanting to do business with it, and if enough business support for BTC is not accumulated by the time the block reward drops faster than the exchange rate increases, then the BTC economy may not be able to continue supporting miners through tx fees. Without continuous incentive, BTC would cease to exist, and this is maybe 2017-2025 at the latest. That's not a very long lifespan for a currency, especially not as a "store of value".

The fact that BTC has to deal with both economic issues and technical issues makes it both more complicated and higher risk than other currencies. BTC might die for technical reasons, or from communist revolution or monopoly action by miners, or by lack of economic support, and so on. Until at least some of those issues are dealt with or proven irrelevant, BTC is nothing but an experiment and a speculation, and can't be considered an "investment" in any intelligent sense. BTC does have some potential advantages over gold, but while gold might be easier to confiscate, its market value isn't going anywhere. BTC could disappear overnight for a number of reasons, all of which are harder to predict and prevent than confiscation.

Nope, still not following. I'm afraid I don't know what you mean by "memory pool". What does it mean for a tx to be in the memory pool? What does it mean for a coin to be included in the memory pool without being broadcast?

AFAIK a tx not broadcast will not be included in a block, and therefore is effectively not a tx. It sounds to me like you want miners to be able to include arbitrary tx which are neither received nor coinbase into their blocks, the only purpose of which that I'm aware of would be for executing a finney attack with the cooperation of a mining pool.

Since all users are free to edit and/or delete their own posts, there is no way for me to prove absolutely what you said or did not say. That said, I can no longer find the post I was referring to, but that could be simply because I haven't looked far enough. Either way I can't find it on search and I don't feel like looking any further just to prove that you're a communist. Also, I could give a shit less what my post count is or what other people think.

However, there is something I'm curious about.


Is there a purpose for doing that besides intentionally destroying coins, or perhaps making a finney attack?


Securing tx and including tx are inseparable. Security with no tx and tx with no security are equally useless, since tx are ultimately what is being secured. We would never consider paying miners just to sit around spamming an empty blockchain, since that by itself serves no purpose.

That said, I can see that there may be other technical problems with the minimum inclusion proposal, but since everyone seems to have a different idea of how tx inclusion and mining pools work (which may be true, since there are different software versions), I can't even intelligibly decide whether I'm full of shit or not, however..

(1) If pool owners are purposefully excluding tx because it is inefficient for them in some way, that is entirely their fault, or possibly a shortcoming in the BTC protocol itself; but if that is the case, then shouldn't P2mining be impractical? If distributed mining isn't practical (especially now when there are only ~80tx per block), then how practical is BTC going to be when there are 1000tx+ per block? Otherwise what do we need major pools and pool operators for to begin with?

(2) If a pool owner is excluding tx because they can't keep the blockchain on their machines, we should force blockchain validation a la gmaxwell, assuming that his proposal (or something similar) would in fact solve the problem. I have my doubts.

(3) The monopolist/commons problem may or may not become relevant. A minimum inclusion requirement wouldn't necessarily solve that problem, either. The main problem is that, unlike a free market, only one "seller" gets to sell his product every ~10 minutes or so, no matter what the demand is, so there is an inherent limitation in price matching between buyers and sellers, which biases towards unilateral miner monopoly a bit more than in a "normal" market. If history serves as any reasonable guide, the next step is that monopolists arise (probably the owner of DeepBit, for that matter), then the next thing you know they own the currency and you've got full-on fascism all over again. An external fascist nation with enough resources (ie the USA) could easily produce the same result if they wanted to purposefully destroy the currency.

Some form of proof of stake might mitigate that possibility, but I don't know of any practical way to make that work. BTC combines both technological concerns along with economic concerns, which makes it far more complicated than any other currency, period. Considering it's less than 4 years old, it's not even clear that it will actually work at all at this point, but the sheer number of ways in which it could be attacked from within or without doesn't look very promising. Without tangible benefits over fiat or gold, there's no reason to use it at all. Anyone using BTC right now is really speculating on an experiment, which is fine for personal use, but unacceptable from a business standpoint.


Makes sense. Then the question is "how consistently could a tx list be kept across different nodes on the network?"

D&T seems to think this would make tx inclusion less efficient (which it might depending on the mechanics of the inclusion quota) however I don't see how that could be the general case. As long as miners are using similar inclusion criteria, their lists should be very similar overall, so it should be possible to reach a reliable agreement over the network.

The way I see it, if a miner is happily accepting charity from their 25-50BTC block reward, paid by all BTC stakeholders and potential stakeholders, then they should happily accept a minimum quota of charity returned to those stakeholders to ensure the reliability and longevity of the network. It doesn't even require that they necessarily accept free tx, just as long as they include enough tx to prove that they're contributing something. The only outlier case is where the next block is found before any new tx are broadcast, which is possible, but there are ways of allowing such blocks to be accepted anyway.

If it becomes a serious issue, in the far distant future (assuming BTC doesn't crash before then for other reasons, and I've got a running list of them now) more BTC can be printed if needed. BTC might be recovered off of a ledger sheet from addresses that have been inactive for 100 years or more, but that's a very long time before any coins could be recovered, and by that time it'd probably be near irrelevant.

The only purpose of miners in BTC is to include and record TX.

1: Any miner not including tx for technical reasons is a communist parasite collecting a welfare check and contributing nothing. These people should be excluded 100%. One day there will be 1000tx+ per block, and miners trying to take shortcuts to just win their block subsidy will fuck the network if they dump 1000tx per block on everyone else. This is especially true once people are actually paying a fee to get their tx into a block faster, since they will still end up paying a fee but will get nothing in return.

2: The blockchain is a contentious shared resource, the only purpose of which is to record and verify tx. Any miner who excludes all tx for fee reasons should be considered a monopolist and be excluded.

3: Because miners are a communist entitlement-sucking union, they should be forced to meet a quota in order to regulate how much control they have over prices. If miners are forced to include 10% of tx, then getting into that 10% spot means bidding on the price of those slots. This doesn't stop miners from choosing the 10% they decide to include, or from excluding everyone who doesn't pay their price assuming enough people are willing to do so.

Case in point: D&T ran out as fast as possible and commissioned fee software, calculating how much he has to charge people in order to regain 50BTC per block after the subsidy is cut down, as though miners "deserve" to be paid 50BTC per block in fees, regardless of the market value of 1BTC, regardless of the value of the service they provide, and regardless of what users are willing to pay (100% exclusion for those paying less than his fee). Because the blockchain is a time-limited, shared resource, if all miners adopt similar policies, either because of what they think they're entitled to or because they want to save bandwidth so they can find a block a few seconds before the next pool, then the whole blockchain might soon be empty of tx.

The same type of problem occurred in the whaling industry, and because individual whalers had no personal incentive to limit their hunting, collectively whalers nearly hunted all species to extinction. By the same token, a subsidy with no regulation is likely to lead to all miners destroying the currency, because it is in their stupid, short term self-interest to cut corners and extort high fees regardless of whether or not BTC collapses as a currency.

Can you tell me how tx are included into a "mined" block, and how this prevents them from being tacked on after a valid header is found? In other words, why can't he have the botnet work on mining headers and then tack on the txs at a single relay point rather than relaying the txs to every node in the network?

If there's some technical reason why this can't be done, it should be relatively easy to fork him out.