Topic: F.R.O.N.T. Attack Vector and What the Bitcoin Devs are doing to prevent it. - page 2. (Read 4083 times)

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.

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.

This attack would only cause network slowdown

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.

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

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

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 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 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'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.

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.

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)

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.

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.

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.

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.