F.R.O.N.T. Attack Vector and What the Bitcoin Devs are doing to prevent it.

[h4xx0r]

I would like to share with you a vulnerability in the Bitcoin protocol I've been thinking of which might have impact on the future of Bitcoin. Please criticize it!
The Freeze on Transaction Problem

The freeze problem occurs if someone publishes a transaction with fees much higher than the block subsidy. I don’t remember who described the attack first. Suppose that, by mistake, a transaction is published with 50 BTC in fees. The transaction is included in a block at height n. If everyone acts rationally in his own interest, then the best choice for the remaining miners is to try to mine a competing block at the same height n including the high-fee transaction, to collect the fee for themselves. All the miners having solved the block at height n, now move on mining at height (n+1). But they won’t choose each other branches until one branch is sufficiently longer so that it is better to switch to it and abandon their own branch rather than try to keep the block with the high fee. This case is different from the real block competition case we see periodically on the blockchain, where the miners are generally split between two branches. Here there are multiple branches competing. If there are 10 “top” miners each having 10% of the network hashing power, then 10 different branches will compete. The analysis for this case is similar to the Gambler’s Ruin problem analysis present in the Satoshi paper, but with a fixed constant monetary incentive not to switch. Since the incentive to switch grows exponentially with the branch length difference, any initial constant is diluted. In the special and rare case that all the miners have exactly the same hashing power, then the network diverges, and this is equivalent as having two miners having exactly 50% of the hashing power each. So in principle the freeze on transaction problem is just a temporary disruption in the network, but not a fatal halt. Nevertheless, since during the freeze period each miner is mining on his own branch, it also means that moving forward with blocks is a lot slower. Assuming 10 miners having 10% of the total hashing power each (+/- 3%), the network becomes 10 times slower. I simulated it with a 50 BTC tx freeze fee, and 10 miners, and it takes approximately 6 blocks to converge, so the freeze time is approximately 60 times the block interval, or 10 hours. If the distribution is approximately 25% of the hashing power for each top miner, the freeze time is 4 hours.

Obviously what’s needed for the freeze problem to occur is that miners are 100% rational, greedy and prepared. They need to have a modified version of bitcoind which can automatically detect a high-fee transaction and prevent adding to the best chain a not-owned block containing such transaction. There will be no time for the miners to patch bitcoind if such transaction is manually spotted. Also the latest versions of bitcoind have preventions not to allow high fees by mistake. So the freeze problem is currently non-existent, but may pop up in the future in form of a state-sponsored attack.

The Freeze problem as an Attack

If an attacker plans to repeat such attack periodically at the expense of wasting a lot of BTC, there is little the current protocol can do, because miners will be prepared to take advantage of the attack. If the attacker issues a new fee burning transaction before the network converges, then the attacker can maintain incentives to keep every miner separated in his own branch. So wasting 50 BTC every 4 hours, an attacker can maintain the network frozen forever.  Even if we restrict the maximum fee per transaction, the scripting system has infinite ways to create transactions whose output can be taken by anyone, and the attacker can announce the method miners can use to collect those BTC and even prepare and publish the bitcoind patches to automate collecting those transaction outputs.

The best thing the community can do is act together and cooperate to share the high transaction fee. This will neutralize the attack completely and allow miners to earn extra bitcoins. But cooperation in the Bitcoin community has never been easy. There is a technical solution which is to modify the Bitcoin protocol so that every transaction output has a maturity time of 6 blocks, and if a transaction output is redeemed multiple times in a 6 block interval, then the BTC amount is split between all redeemers, and also fees would be automatically shared in a 6 block sliding window. At a first glance, this provides a way for miners to cooperate even anonymously and there is no immediate drawback, but an in depth analysis is necessary.

If i understand this correctly, this would take an deleberate, orchestrated and very costly attack in order to exploit the vulnerability. Personally, it does not weaken my belief in bitcoin at all; Many of crypto's greatest minds have already drafted proposed fixes for this theoretical vulnerability. Unfortunately, the best solution will make transactions in the bitcoin network even slower.

What say ye?

[h4xx0r]

I should point you to some of the tools that have been discussed in
the past which are potentially helpful here:

The first is the use of locktime on normal transactions. This
behavior is already in Bitcoin core git: The idea is that users of
the system should locktime their transaction at a point as high as
they expect it to get included. If used well this means that there
should always be a base of fees which can only be collected by future
blocks, creating an incentive to move forward. This may be
particularly effective if the limitations on blocksize mean that there
is always a healthy standing load.

The second is having block commitments in transactions
(https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas). The idea is that
the data under signature in a transaction could commit to some recent
block which _must_ be in the chain or the transaction's fee cannot be
collected (or, at least, not all of the fee). This would allow
transacting users to 'vote with their fees' on the honest chain.
Arguably this could also be used to pay for doublespending forks, but
you can already do that by paying fees via a chain that stems from the
doublespend. This greatly complicates strategy for forking miners,
since future transactions which you haven't even seen yet may have
fees conditional on the honest chain.

I think both of the above are obviously useful, should be done, but
don't completely address the concern, they may be adequate.

The third is fee forwarding. An example form would be that the miner
gets half the fees, the rest are added to a pool which pays out half
in every successive block. This can prevent unusually high fees from
making as much reorg pressure and more correctly models what people
would like to pay for: getting their txn buried. The huge problem
with this class is that miners can demand users pay fees "out of
band", e.g. with additional txouts (just make a different version of
the tx for each miner you wish to pay) and escape the process. I have
had some notions about fees that come in the form of adjusting the
difficulty of creating a block slightly (which is something that can't
be paid out of band), but such schemes becomes very complicated very
fast. I am unsure if any form of fee forwarding is workable.

Something you might want to try to formalize in your analysis is the
proportion of the network which is "rational" vs
"honest"/"altruistic". Intuitively, if there is a significant amount
of honest hashrate which is refusing to aid the greedy behavior even
at a potential loss to themselves this strategy becomes a loser even
for the purely greedy participants. It would be interesting to
characterize the income tradeoffs for different amounts of altruism,
or whatever convergence problems an attempt by altruistic
participaints to punish the forkers might create.

[franky1]

90% wrong

large fee's dont cause freezes all by themselves. there have been cases in the past where a few people messed up their raw transactions and had a high fee, and guess what happened.. nothing unusual apart from the fact that the sender messed up and lost his bitcoin.

the only possible way to perform a successful freeze is to fill up a block with a single transaction with 4000 outputs (1mb data) and a very tempting fee to co-erce miners to accept their TX and ignore everyone elses, thus delaying other tx's.

the fee itself or miners wont be the cause of a freeze. but the transaction with 1mb datasize being accepted would..

the freezing does not last several blocks or hours.. mining still continues every 10 minute on average. but if a whale can continually throw large fee's and make 1mb transactions, and miners continue to choose to accept the transaction. then all other transactions will have to wait until there is a gap.

also to note that miners prefer to deal with tx's of just quarter of a mb or less, just to get a block solved faster than the other pool. (less data= better solve time). as was the case of miners blocking satoshi dice tx's as they were spamming the block.

miners would prefer to process 200 normal tx's  with small fee's for a near guaranteed 25btc normal reward and maybe 1btc total fee. rather than risk dealing with 1mb of data and processing it, just to find out it orphans because another miner ignored it and solved their block of normal tx's sooner.


thus the unethical whale wasting bitcoins would need a rather large tempting fee, and still no guarantee's miners will accept it.

[h4xx0r]

90% wrong

large fee's dont cause freezes all by themselves. there have been cases in the past where a few people messed up their raw transactions and had a high fee, and guess what happened.. nothing unusual apart from the fact that the sender messed up and lost his bitcoin.

the only possible way to perform a successful freeze is to fill up a block with a single transaction with 4000 outputs (1mb data) and a very tempting fee to co-erce miners to accept their TX and ignore everyone elses, thus delaying other tx's.

the fee itself or miners wont be the cause of a freeze. but the transaction with 1mb datasize being accepted would..

the freezing does not last several blocks or hours.. mining still continues every 10 minute on average. but if a whale can continually throw large fee's and make 1mb transactions, and miners continue to choose to accept the transaction. then all other transactions will have to wait until there is a gap.

also to note that miners prefer to deal with tx's of just quarter of a mb or less, just to get a block solved faster than the other pool. (less data= better solve time)
thus the unethical whale wasting bitcoins would need a rather large tempting fee, and still no guarantee's miners will accept it.

Hmm, i disagree, having read the entire thread in the mailing list.
The scenario entails that an entity controls large amounts of bitcoin hashrate. enough to have multiple setups all claiming the same block with a higher than normal fee, OR greedy miners all attempting to go back and claim a block with a high fee and fork the chain, from what i understand. The freeze occurs when the network is attempting to decide who holds the largest chain. If you have 10 competing entities, each with 10% of the total hashrate, the scenario results in a freeze. This is not my theory btw, i read it on the mailing list, and thought i would share for those who don't subscribe. Its an interesting read, and it helps one stay abreast of these issues. we may not see this issue now, when the average fee of a block is far less than the block reward, but someday when the block rewards are gone, this could be a serious problem, as the motive for such an attack would be quite obvious.

[franky1]

the decision of which block wins is not done by hashrate total.
its not "hmm this guy has 30% others have less.. thus winner =30%".. its not done "by oh crap they all have 10% i cant decide"

its done by who has a solved block first. even a pool with just 5% can get lucky and solve it before another pool with higher hashrate.
so unless ALL pools got the solution and at the exact same split second, submitted the same solution. then.. well ull figure it out.

having an absolutely equal amount of hashrate on every pool is meaningless too as its like a lottery. one pool will always solve a block before the other due to a bit of randomness. there will never be a case where all blocks of all pools are solved at the exact same unix second of eachother.

again
all pools would have to be in collusion to wait for the exact same time that all pools had been handed the solution to then all submit it.

the only true way to delay tx confirms is to spam a block with tx's so that only the unethical tx is allowed in. which would cost that unethical spammer alot in tx fee's to achieve (miners would ignore it like they did with S' dice, without a tempting fee) and the delay will last only that block., unless the unethical hacker resent tx's every block.

[eleuthria]

This attack would only cause network slowdown, not a freeze, so the name isn't very good.  While the entity that first solved the block is working on a new block in the chain, the rest of the network is mining the previous block still to claim it themselves.  Even if the entire network is doing this, eventually you would end up with one entity creating a chain long enough that it will be impossible to wrestle it back via forced orphans.

This "attack" only works if the entire network is divided into competiting entities with almost identical speeds that are all acting to purposely orphan another entity's block to claim the enhanced reward themselves.  The second you introduce any speed discrepancy *OR* miners who aren't trying to break Bitcoin, it fails.


EDIT:  I can see honest miners being forced out eventually, but I am doubtful we'll ever see the network in a situation where the big entities are close enough in speed for this to ever actually happen.

[franky1]

This attack would only cause network slowdown, not a freeze, so the name isn't very good.  While the entity that first solved the block is working on a new block in the chain, the rest of the network is mining the previous block still to claim it themselves.  Even if the entire network is doing this, eventually you would end up with one entity creating a chain long enough that it will be impossible to wrestle it back via forced orphans.

This "attack" only works if the entire network is divided into competiting entities with almost identical speeds that are all acting to purposely orphan another entity's block to claim the enhanced reward themselves.  The second you introduce any speed discrepancy *OR* miners who aren't trying to break Bitcoin, it fails.


EDIT:  I can see honest miners being forced out eventually, but I am doubtful we'll ever see the network in a situation where the big entities are close enough in speed for this to ever actually happen.

as soon as a new block is found the other miners are not mining old blocks, they give up and move onto the next one. theres no point finishing a block if someone else has a valid block. but you are right about that unless all miners colluded together with matched results to force the same solution at the same time, then the theory would fail.

summary of theory requirements
EVERY miner submitted a block solution at exact same time to confuse the network as to which one wins, all blocks need matching tx's inside block, else the one with more tx's would win, even if time submitted was equal
or
miner would only include 1tx and win every block solution (delays other peoples tx)

[eleuthria]

as soon as a new block is found the other miners are not mining old blocks, they give up and move onto the next one. theres no point finishing a block if someone else has a valid block. but you are right about that unless all miners colluded together with matched results to force the same solution at the same time, then the theory would fail.

summary of theory requirements
EVERY miner submitted a block solution at exact same time to confuse the network as to which one wins, all blocks need matching tx's inside block, else the one with more tx's would win, even if time submitted was equal
or
miner would only include 1tx and win every block solution (delays other peoples tx)

You're missing the point of this attack.  The point is that a person includes a TX fee high enough that it is so valuable that miners will try to orphan the previous block in order to claim the transaction fee for themselves.  If the fee is high enough, the cost of trying to do this is less than the payoff, making it worth doing.  By doing this, essentially the entire network (except the entity that found the block and honest miners) stops working on the longest chain, in order to fork the chain and claim that fee for themselves.  This would slow down the network as a result (since most of the network is now re-mining a prior block in order to claim it themselves).

If the network were split evenly, and all actors were dishonest (claim it for themselves), this would result in an extremely slowed block rate because basically each entity would be mining their own version of the blockchain, hoping they get a long enough streak that the other competing entities give up on claiming it for themselves.


However, the current network is NOTHING like that.  Large entities have too much discrepancy in their speed, and the majority of the network is honest.

[franky1]

i did see your point, and the point the op made. then i thrashed it out into a few scenario's and see the discrepancies that you described along with a few other i thought up, and simply dismissed the theory. i then thought about a different scenario where a delay/freeze would be possible.

i am not saying your wrong, but in practical terms i cant see the theory happening of a permanent chain freeze without total network collusion... as you say, too many variables.

[SF-Man]

i did see your point, and the point the op made. then i thrashed it out into a few scenario's and see the discrepancies that you described along with a few other i thought up, and simply dismissed the theory. i then thought about a different scenario where a delay/freeze would be possible.

i am not saying your wrong, but in practical terms i cant see the theory happening of a permanent chain freeze without total network collusion... as you say, too many variables.

I am agreeing to you.. I will be waiting for his rebuttal.

[h4xx0r]

i did see your point, and the point the op made. then i thrashed it out into a few scenario's and see the discrepancies that you described along with a few other i thought up, and simply dismissed the theory. i then thought about a different scenario where a delay/freeze would be possible.

i am not saying your wrong, but in practical terms i cant see the theory happening of a permanent chain freeze without total network collusion... as you say, too many variables.

You've dismissed it without offering any concrete evidence to your claims. Here's the latest on the subject:

I've heard about this idea from TierNolan. Here's some quick an dirty analysis:

Suppose the last known block claimed a large tx fee of L. A miner who owns 1/N of the total hashrate needs to choose between two strategies:

1. Mine on top of that block and win usual reward R with probability 1/N.
2. Mine on top of the previous block, trying to make two blocks in a row, might get reward L with probability 1/N^2.

Thus for the first strategy expected payoff is R/N, and for the second the expected pay-off is L/N^2.

Second strategy is viable if R/N < L/N^2,
 R < L/N.

Now suppose the miner who claimed the unusually large reward will share it with the next miner, for example, using coinbase output with OP_TRUE. If that shared reward Rs is higher than L/N^2, then the next miner will be better off mining on top of that block.

This doesn't require protocol changes(*) and can be simply incorporated into a piece of code which decides what to do when a transaction with unusually large fee appears. (I.e. it will automatically share the fee, and others will recognize that). And if the biggest miner has 25% of all hashrate, sharing 25% of your loot doesn't sound that bad.

(*) Except one problem: coinbase maturity rules won't allow one to share the fee with the next miner.
So some protocol changes are required. But changes which affect coinbase maturity and sharing are probably going to be simpler and smaller than what Sergio have proposed.

[kendog77]

This attack is pretty far fetched.

First off, it assumes some other party is going to throw away BTC via extremely large transaction fees when they have no economic incentive to do so. In the cases where this has happened in the past, I believe it was a honest mistake.

Next, even if it does happen, miners have to be running software that is smart enough to recognize that it occurred and then pursue the attack. Even if they do pursue the attack, they may or may not be successful.

I doubt there are many blocks where the total transaction fees added up to more than the block reward, but that information is all in the block chain so I'm sure it would not be too difficult for someone to go back and see how often this has occurred in the past.

If you assume everyone is acting in their own self interest, including those who pay transaction fees, I think the economic incentives already in place make the probability of this attack so low that it is not worth worrying about.

[DannyHamilton]

i then thought about a different scenario where a delay/freeze would be possible.

Please don't derail the thread.  Try to keep your discussion limited to the presented attack.  If you wish to discuss some other attack that you think you've discovered, please create a separate thread for it.

i did see your point, and the point the op made. then i thrashed it out into a few scenario's and see the discrepancies that you described along with a few other i thought up, and simply dismissed the theory.

It is clear that you have dismissed the theory.  It appears that you've dismissed it based on two important facts:

• It hasn't been a problem in the past when there have been large fees paid
• The system isn't intended to operate that way

When discussing a potential attack vector, neither of these are valid defenses.

"It hasn't been a problem in the past" can simply mean that nobody has noticed the potential yet.

It doesn't matter how the system is designed.  When profit margins shrink, miners will do whatever they can to increase revenue.  That includes the possibility of ignoring a solved block in order to attempt to mine a replacement block if the potential revenue outweighs the cost associated with the potential orphan risk.

i am not saying your wrong, but in practical terms i cant see the theory happening of a permanent chain freeze without total network collusion... as you say, too many variables.

I don't see why collusion would be necessary. All that should be needed is tight profit margins on mining and modified mining pool software that computes risk of orphan cost before deciding whether to accept a new block or continue trying to solve a replacement block.

[h4xx0r]

Latest message from the mailing list on the subject sheds light on another possible preventative measure

Note that the problem might arise also by a bug / accident and not as an attack.

Since value spent is not part of the signature it is easy to create an arbitrary fee by a defective wallet software.
Collecting that huge fee might provide a higher incentive to miner than the block subsidy on the trunk.

Assuming miner are fully rational, they might even form a temporary coalition to claim the fee:
The miner who mines forking block might offer part of the fee gained in a similar transaction to
other miners, so they help to extend his fork. A sufficiently high stake could trigger a long
fork “battle” of ad-hoc coalitions.

Addressing the known bug of the signature hash, that it does not include the value spent,
would have other positive effects, e.g. for resource limited hardware wallets.

Interpretation of an OP_NOP for a value hashing signature check were suggested by Alan Reiner
discussed earlier on bitcointalk.

Tamas Blummer

[solex]

There was a transaction last year with a huge fee >3x block reward:

So, despite the block reward being >$1000, and not due for halving until 3.75 years time, fees are forced to do a moonshot.

That "moonshot" is because someone created a single transaction with 94BTC in fees: 13dffdaef097881acfe9bdb5e6338192242d80161ffec264ee61cf23bc9a1164

Fees are rising, but they haven't spiked like you think they have.

[Meuh6879]

This attack would only cause network slowdown

with 7200 bitcoin nodes (and 6000 inside that they have  all blocks of blochchain) ... you slowdown nothing

[franky1]

to clarify my point and why i dismissed it.

1. the fee itself does not cause a freeze. there is no bug relating to a fee exceeding reward.
2. whomever solves the block gets the reward and then continues onto the next block as normal.
3. the fee is just a 'temptation' for OTHER miners to go backward and try solving that expensive block and then once solved insanely attempt to rush forward to catch up and overtake the original pool whom solved it first.
4. all this does is fight over whomever gets the reward, again no slowdown of the network
5. the only way to slowdown the network is if miners ignored and avoided adding in other transactions.

in summary the fee causes no freezing. but an ignorance of other transactions could slowdown transaction confirmations. which would only be the case if miners had good reason to ignore everyone elses transactions, AND that the reason to ignore everyone elses transactions continued for every block after.

with all the variables of speed of pools playing catch up, risks of missed opportunities simply mining fresh blocks just to attempt to win an expensive block and the lack of reason to ignore everyone elses transactions. i see that a freeze wont happen.

again the variable. the tx with the large fee would also have to include a bunch of transactions to fill the block and prevent other peoples tx's 'sliding in. which in itself would make trying to solve a block for other slower pools even worse due to data bloat and chances of orphaning. thus they wont see a large enough benefit to work backwards and miss fairer, fresh rewards, simply for one single large payout reward.

the fee would need to be substantial and continual just to create a temptation, let alone having the data bloat(causing a freeze) hindering chances of overtaking. unless miners had alterier motives, its cheaper, easier and more rewarding to just shake the hands of the first block solver, congratulate them and then continue mining as usual.

if you think this is wrong.. TRY IT. the thing about bitcoin is that its built to withstand many theories of attack so if someone has an attack, they should try it.
bitcoin is only as secure as the attacks against it that fail. so feel free to try it, it can only make bitcoin stronger.

[DannyHamilton]

to clarify my point and why i dismissed it.

1. the fee itself does not cause a freeze. there is no bug relating to a fee exceeding reward.

Correct.  I don't think this has been presented as a "bug" where a large fee in and of itself somehow "freezes" the blockchain intrinsically.

2. whomever solves the block gets the reward and then continues onto the next block as normal.

Well, that is what is intended, and there is a financial incentive to encourage this behavior.  The problem is an excessively large fee can temporarily reverse this incentive, and there is nothing forcing the behavior you describe.

3. the fee is just a 'temptation' for OTHER miners to go backward and try solving that expensive block and then once solved insanely attempt to rush forward to catch up and overtake the original pool whom solved it first.

Correct.  The block reward is just a "temptation" for miners to even bother mining in the first place.  An excessively large reward distorts the "temptation" such that there is a larger "temptation" to continue working on the current block than the "temptaion" to move on to the next block.  (Generally this "tempation" is called an "incentive).

4. all this does is fight over whomever gets the reward, again no slowdown of the network

Actually, if enough miners are "fighting over whomever gets the reward" of the current block, then the next several blocks will take significantly longer than 10 minutes (since a substantial percentage of the mining hash power is not working on the next block).

5. the only way to slowdown the network is if miners ignored and avoided adding in other transactions.

This is not true.  Any time the hash power of the mining network that is working on the next block is significantly reduced, it proportionally increases the amount of time before the next block is solved.  If the current block is repeatedly orphaned, it is possible to further increase the average amount of time it will take for the next block to be solved.

in summary the fee causes no freezing.

Freezing, slowing down, confirmation stall.  Call it whatever you like.  The point is that an excessively large fee can distort the incentives, and that if a significant percentage of the mining population is prepared for such an event it can reduce the rate of confirmations.

but an ignorance of other transactions could slowdown transaction confirmations. which would only be the case if miners had good reason to ignore everyone elses transactions, AND that the reason to ignore everyone elses transactions continued for every block after.

I'm not sure how this statement relates to the current conversation.  Perhaps I'm not understanding what you are saying here?

with all the variables of speed of pools playing catch up, risks of missed opportunities simply mining fresh blocks just to attempt to win an expensive block and the lack of reason to ignore everyone elses transactions. i see that a freeze wont happen.

Perhaps you mean something different when you say "freeze" than what we are talking about here?

again the variable. the tx with the large fee would also have to include a bunch of transactions to fill the block and prevent other peoples tx's 'sliding in.

No. It wouldn't.

which in itself would make trying to solve a block for other slower pools even worse due to data bloat and chances of orphaning. thus they wont see a large enough benefit to work backwards and miss fairer, fresh rewards, simply for one single large payout reward.

That depends on the size of the reward and the risk of orphan, doesn't it?  Are you saying there isn't any combination of block size and reward size the would distort the incentives?

the fee would need to be substantial

Yes.  That's the whole point of this conversation, isn't it?

and continual just to create a temptation,

I don't think so.  Imagine for a moment a fee of 1,000 BTC. Once that transaction was mined into a block, would a mining pool such as GHash.io find it to be tempting enough to try to replace that block rather than moving on to the next block?

let alone having the data bloat(causing a freeze) hindering chances of overtaking.

Again, "data bloat" doesn't apply here.

unless miners had alterier motives, its cheaper, easier and more rewarding to just shake the hands of the first block solver, congratulate them and then continue mining as usual.

While it might be more ethically rewarding, it isn't necessarily more financially rewarding.

if you think this is wrong..

I do.

TRY IT.

No thanks.  It's a bit too expensive just for proving a point.  I suppose it could be tested on testnet though.

the thing about bitcoin is that its built to withstand many theories of attack so if someone has an attack, they should try it.
bitcoin is only as secure as the attacks against it that fail. so feel free to try it, it can only make bitcoin stronger.

Correct.  If someone tries it (accidentally or intentionally) it will eventually be noticed and modifications will be made to the protocol for the future.

[ANTIcentralized]

as soon as a new block is found the other miners are not mining old blocks, they give up and move onto the next one. theres no point finishing a block if someone else has a valid block. but you are right about that unless all miners colluded together with matched results to force the same solution at the same time, then the theory would fail.

summary of theory requirements
EVERY miner submitted a block solution at exact same time to confuse the network as to which one wins, all blocks need matching tx's inside block, else the one with more tx's would win, even if time submitted was equal
or
miner would only include 1tx and win every block solution (delays other peoples tx)

You're missing the point of this attack.  The point is that a person includes a TX fee high enough that it is so valuable that miners will try to orphan the previous block in order to claim the transaction fee for themselves.  If the fee is high enough, the cost of trying to do this is less than the payoff, making it worth doing.  By doing this, essentially the entire network (except the entity that found the block and honest miners) stops working on the longest chain, in order to fork the chain and claim that fee for themselves.  This would slow down the network as a result (since most of the network is now re-mining a prior block in order to claim it themselves).

If the network were split evenly, and all actors were dishonest (claim it for themselves), this would result in an extremely slowed block rate because basically each entity would be mining their own version of the blockchain, hoping they get a long enough streak that the other competing entities give up on claiming it for themselves.


However, the current network is NOTHING like that.  Large entities have too much discrepancy in their speed, and the majority of the network is honest.

Even if you ignore the stikeout part the attack would not work. The reason for this is because the dishonest miners would need to be relying on good luck to potentially make a chain that is 6 blocks longer then the next longest block. While they are mining on a shorter blockchain the are risking the block subsidies (and TX fees) that they would expect to earn if they were mining honestly. In a "best case" scenario the dishonest miner would lose three blocks worth of block subsidies and TX fees by the time the longest blockchain is 6 blocks longer then the next longest one (assuming the "winning" miner has 200% luck while the next best miner has 100% luck). A much more likely scenario is that all the dishonest miners would be risking many hours worth of block subsidies and TX fees (while maintaining the costs associated with mining); this would make this attack uneconomical.

[giszmo]

Interesting attack indeed but h4xx0r who did you quote with the idea of giving to the next miner a share of your coinbase tx? It's trivial to give to the next miner outside the coinbase transaction by sending the reward as a transaction using one of the current inputs. Sure, then you have to scrape the bitcoins from elsewhere.

To recap the attack in laymen's terms:

If somebody paid 10,000BTC in transaction fees, miners would not care about block rewards for the next 10,000/25=400 blocks. Any miner that thinks it could outrun the biggest other miner would try to do so. If there is a draw between the top miners, such a battle could take a long time. If the top miners hold 10% of the mining power, they might try even when the other had a head start and was slowly building a chain that's growing faster than the own chain as they could still call their friends of other pools to team up catch that guy, essentially to the point where all miners took one side or the other and the weaker group gives up.

Also the attack does only work if the biggest selfish miner is bigger than the total of his run-up competitor with all non-selfish miners, so it assumes a pretty corrupt mining landscape.

The attack's effects:

During such an episode, massive re-orgs would happen, clients would act strangely, Finney attacks would be slightly easier etc. and we would have a slightly higher level of drama. And we will never know who sponsored that drama but it would not be a cheap endeavor.