pull down to refresh

Still don't see it. Suppose there's a block X at height N and a rogue miner desides to aim at replacing X rather than building on top of it. He successfully mines a block Y also at height N. However, he must keep the fees of Y lower than the fees of X, otherwise miners would build on top of X instead and he gets nothing. So rogue miners would gradually lower the fees of the block at height N until someone builds a block at height N+1. That doesn't sound like Bitcoin is dying or anything like that. Also users can cut the crap by using locktime to aim for a particular block height.
Unless I misunderstand locktime, I don't see how either of these points is going to deter greedy mining. There is no need to reorg to have less fees, as plenty of new transactions are always percolating in. Likewise, locktime doesn't materially affect miners - the coinbase transaction will still sum to the same value and the winner will eventually get the sats.
reply
Locktime: you can set the locktime on your transaction so that it can only be included starting from the block N + 1 where N is the current block height. This way your transaction can't be included in a block with the current block height.
Reorgs: now I don't get you at all. I conjecture there might be confusion of reorg as in 51% attack scenario with greedy miner reorg (no 51% power). In the latter case the miner gets the coinbase reward anyway, so why does the coinbase size even matter?
reply