Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

[Alex Mizrahi <alex.mizrahi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2111 bytes --]