Someone (or a group of people working in concert) who can solve and submit an inordinate number of blocks (of any type) in succession can do bad things. This is a well-known problem for which there is no possible solution (at least no solution within the concept of having a decentralized proof of work blockchain).

Fortunately, in order to submit an inordinate number of blocks in succession with any significant probability, you have to have a lot of "mining power" (51% would definitely do it; maybe 33 1/3% under the right situations; probably somewhere in between the two under less "ideal" situations).


It's trivial to add one (or any number of) useless spam transactions to a block. If you're trying to save network bandwidth you could even calculate the spam transactions based on a formula, so you don't have to send the actual transaction content over the network. So rejecting empty blocks wouldn't add any security, and would really just add complications to the client. It could also potentially make Sybil attacks slightly easier (all you have to do to stop a miner from mining is stop them from getting new transactions, you don't have to shut down their network connection entirely).

You could have a rule where every block must have at least a certain number of bitcoin-days destroyed. But that would have its plusses and minuses. Something for an altcoin to consider (especially if you added something fun like negative transaction fees for "high priority" transactions), but not something that's necessary for bitcoin.

Where "artificially" means what, exactly? Everything we're doing is artificial.


Yep. A full block is better than an empty block. But the choice isn't between a full block and an empty block, it's between an empty block and a stale block.


Compared to nothing? The benefits are the ones I listed, including speeding up the confirmation of transactions.

No. That isn't right. Even an empty block helps people out. If nothing else, the empty block makes the coinbase transaction from 120 blocks previous become spendable. In practice, the empty block brings all those 5-confirmation transactions up to 6 confirmations (and 2-confirmation transactions up to 3 confirmations, etc.) The presence of the empty block makes transactions confirm faster than they would have if the empty block weren't there.

A full block is better than an empty block. But an empty block is better than nothing. (And a block at the same height and roughly the same time as someone else's partially propagated block, which temporarily splits the network into two chains of equal height, is significantly worse than nothing.)

Ideally, transaction fees probably wouldn't go solely to the block in which they were located, but would go to that block and future blocks which build upon them (maybe in a declining way like 50% to the first block, 25% to the second block, 13% to the third block....I don't know as I haven't fully thought about it). Right now it doesn't particularly matter, as the transaction fees are small compared to the block reward. But in the future when there are no block rewards at all, just transaction fees, there might be problems due to this (if someone puts an especially large fee on a transaction, there might be an incentive for miners to "steal" that transaction fee by orphaning the block which includes it instead of building upon the block which includes it). Fortunately there are many years before this will become an issue.


In addition to the direct benefits of faster confirmations and faster spending of generated coins, think about how the inclusion or non-inclusion of the empty block affects someone who is performing so-called "selfish mining" or some other sort of block delaying attack.

I'll have to try that, as well as try to find that updated description of what transactions are accepted.

There are a lot of transactions where I'd be happy to send a small fee. But $0.20+ to transfer $2.50 between wallets (where I control both ends so I don't really care about the speed or double-spend security of the transaction) is too much.

I'm not sure why your partner would refer to transactions with no fee (or even with a fee less than 0.1 "TBC", as I understand it) as "begger transactions" then.

By the way, how is someone supposed to submit a low-fee transaction to Eligius? I believe the direct submission form was taken down. http://eligius.st/~wizkid057/newstats/pushtxn.php always gives me "Sorry, function disabled.  Contact wizkid057 directly if you need a transaction mined."

wizkid057: I need a transaction mined! (Well, not right now, but I often would like to send a small, low priority transaction for less than $0.20 in fees, and unfortunately the default client treats a $0.01 fee the same as no fee at all.)

I figured as much, which is why I pointed it out.

Maybe kano wasn't intentionally lying, but rather was relying on the misinformation which is documented on the website.


I have to say that I've never heard of the term "begger transactions". If all miners cared about was maximizing short-term profits, we'd probably have mostly empty blocks, since every time you include a transaction you increase the probability of your block being orphaned, and transaction fees are tiny compared to total block reward.

"Transactions without a fee will be processed based on confidential anti-spam testing." http://eligius.st/~gateway/faq-page/faq-5

Probably should edit the title of this post too: "105% PPS NMC"

Or am I mistaken about what the 105% refers to?

Yeah, I was agreeing with Kano. If I use a pool it's so I can get a definite payout in a short period of time. If I wanted to maximize my payout in the long run but not have any guarantee that the long-run completes within my lifetime, I'd solo mine.

Umm, yeah, I was referring to CPPSRB. Yes, there's a chance that those buried shares I have on the Eligius pool might one day pay out, but if it ever happens most likely I'll never even know about it, because I don't ever check on them any more. Those shares *are* forgotten by me. I guess if they ever get paid out that they'll eventually get escheated to the state.

Yeah I'm not sure that a tiny chance of a dust payment at some unknown time in the future is worth much of anything. Maybe if you could transfer it to someone else for free.

The purpose of pools is supposed to be to get rid of those very small possibilities and indefinite timelines, isn't it?

Okay sorry! 

Don't trust any storage ever!

But now you see that you made a mistake, right?

I think we tried to say that several times, in various different ways

They've still got the domain name to sell. And the software is probably worth something too.

Did they ever explain what the hack was anyway?

Also OS. If TCP sequence numbers are being predicted, it could be that the OS isn't making the initial sequence number hard enough to guess.

Really there's no excuse for not using SSL, though.

I guess TechByPC was wrong about explaining things technically being more enlightening than calling people names...

It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.

Whether or not you want to call the former a MITM attack is another matter. Really the attacker in that case isn't (necessarily) in the middle, she just pretends to be.


By the way, neither requires being in the data centre of the server.  The latter (which I'd call a true MITM attack) just requires being somewhere in the middle (hence the name).

The former (which is probably more likely) doesn't even require that. It just requires correctly guessing TCP sequence numbers and spoofing of the source address. See, e.g., http://www.thegeekstuff.com/2012/01/tcp-sequence-number-attacks/

In any case, I think we have our answer to the question as to why the DOS is/was going on (*). Be careful what you wish for...

(*) Step 2: "[The attacker] floods Host B with new requests causing a Denial of service attack to stop Host B from communicating with A."