I've been looking at selfish mining and empty blocks. In all cases, the selfish miner profits by keeping block solutions private until their value to his own pool is maximized, rather than releasing them ASAP which is the honest way to do it.

If the protocol were changed to make holding back a block far riskier than it is currently, I think this would go a long way to solving the problem presented by selfish mining. A selfish pool holds a solved block until someone else solves a block at the same height. The selfish pool then releases its pre-solved block (having had time to privately seed the global network so that as many honest miners as possible will see the selfish block first) to orphan the honest miner's block. Currently, the risk is that enough honest miners might choose the honest block with the result that the selfish miner loses both the reward for having solved it first and the advantage of being one block ahead. The papers on selfish mining show that this risk is not great enough to prevent selfish mining.

The protocol currently expects a miner to use the first block that adds to the chain. If this rule (actually a suggestion) were changed to expect a miner to use the block that destroys the most bitcoin days, selfish miners would risk far more by holding back their solutions. It would still be relatively easy for a selfish miner who has gotten ahead to exploit his position by saving the solution until it can be used (if it destroys more bitcoin days) to orphan someone else's solution, but the risk that the other solution might destroy more bitcoin days would be significant. Even if the selfish miner seeded his solution with his own very old UTXOs, he would be wasting some of his ammunition (bitcoin days).

Additionally, the rule that a miner use the first seen block or any other rule to resolve conflicts when two blocks show up as possible extensions to the current chain is not enforceable. So perhaps what is needed is not for the protocol to change, but for miners (who would like to prevent the selfish mining attack) trying to decide between two new block heads to use bitcoin days destroyed to decide. Publishing this idea, however, is not warranted until it has been criticized for flaws.

So have at it!

  • My first impression is that it would be very easy to game for a mining pool with ~20% of the total hask power to dominate mining in general, by seeding transactions with old coins they hold. – Murch Aug 24 '15 at 22:20
  • Sure. It's the same as it is now, except that they'd also have to have old coins and eat through them with each attempt. So most-btc-days-destroyed discourages selfish mining more than pick-one-at-random and also better than first-seen. It is improvement that I seek, not perfection. – Dave Scotese Aug 25 '15 at 5:08
  • Simplified to illustrate my point: Say there is two mining pools, A has old coins, B doesn't, they have each about 50% of the total mining power. A can create transactions that he mines, but doesn't broadcast, and thus oust any competing block B produces, unless B gets two blocks before A gets one. That seems broken to me. Also, (Nick pointed out to me) if neither would create extra transactions, any later block would always supercede an earlier block, because a single transaction more would give a greater figure of Bitcoin Days Distroyed. – Murch Aug 25 '15 at 20:53
  • @DaveScotese, this is actually what ziftrCOIN does, using the # of coin-days-destroyed as a tie breaker. – morsecoder Aug 31 '15 at 19:50
  • @StephenM347, I assume there is no code to enforce that, but that it is the default behavior of the code. I don't know how it can be enforced, and I guess it doesn't need to me. Just a culture thing. – Dave Scotese Sep 2 '15 at 1:18

Thanks to Murch, I'm answering my own question; Yes!

Murch made the point that using BTCDD enables a selfish miner to mine a non-broadcast transaction that spends old coins rather than having to rely on a network propagation advantage. I understand this objection. That advantage is easily removed by excluding from your BTCDD calculation transactions that you didn't see until you got this new block. Now the selfish miner has to broadcast his old-coin transaction.

(edit due to comment:) While it is true that some BTCDD-heavy transactions will have gotten to one miner and not another, making the tie-breaking strategy arbitrary, because neither will have the BTCDD-heavy transaction privately mined by the selfish miner, it is still more effective at discouraging selfish mining than letting the network choose randomly, if and when you can assume that most miners will have seen both blocks around the same time. BTCDD is arbitrary because of incomplete propagation of transactions, but because of fully propagated transactions, it is less arbitrary than first-seen.

Also, you can't spend just a part of an input. I submit that it's harder to have (enough) old coins than it is to set up a global network of tightly connected nodes for cheating. I suppose I could be wrong, but old coins is always a dwindling resource and global nodes willing to help cheat is probably a growing one.

The only purpose for orphaning a block is that you've already been mining on top of your replacement for it. This point was made soon after Sirer and Eyal described their selfish mining vulnerability, though quite indirectly. Using a "later block" to do that would severely diminish the advantage. The point is to discourage sitting on solutions by making the later block more likely to be accepted. Would you consider throwing away any seconds of your own mining when you see an alternate solution? To discourage selfish mining, I'd do a few seconds, I guess.

I also very much like discouraging empty blocks, but who mines empty blocks just to do a selfish mining attack? Oh wait, that's probably the best way to do it! Hmm...

  • Interesting points. I think the part about making it more expensive to sit on a block has merit and deserves further consideration. However, I still maintain, even though old coins are a dwindling resource, it is sufficient for you to have more coins than the competitors to have an advantage: If you and I both have 30% of the mining power, but I control 1,000,000 BTC, while you only have 1,000, I can boost my BTCDD much more than you can. (cont.) – Murch Aug 27 '15 at 10:32
  • "That advantage is easily removed by excluding from your BTCDD calculation transactions that you didn't see until you got this new block." This is not possible unfortunately, because that would mean that different nodes would treat the same data differently for arbitrary reasons, and transactions not having been seen by the whole network before they are included in a block is common, natural, and healthy in our p2p network. – Murch Aug 27 '15 at 10:35
  • 1
    @Murch, sure, if you own significantly more bitcoins, then you'd have an advantage in ties. Ties are somewhat rare, though. But you have more stake in the system too, so in some sense you're less likely to do something to harm the system, because harming Bitcoin harms you. – morsecoder Aug 27 '15 at 12:45
  • 2
    @Murch "This is not possible unfortunately, because that would mean that different nodes would treat the same data differently for arbitrary reasons" - They already do! The time a block got to you is a pretty arbitrary reason. It's okay if everyone chooses their own tie breaking procedure, as long as most-work chain wins, consensus is still maintained. – morsecoder Aug 27 '15 at 12:49
  • 1
    And the chance of the same miner finding two consecutive blocks increases. Once a miner has a 2 block lead it is probably more and more likely to succeed in extending that lead further and further. Not good. – Jannes Sep 8 '15 at 4:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.