Can Bitcoin Days Destroyed be a better resolution mechanism for competing blocks?

5

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!

Dave Scotese

Posted 2015-08-24T21:28:54.957

Reputation: 719

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 – 2015-08-24T22:20:57.760

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 – 2015-08-25T05:08:37.117

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 – 2015-08-25T20:53:06.493

@DaveScotese, this is actually what ziftrCOIN does, using the # of coin-days-destroyed as a tie breaker.

– morsecoder – 2015-08-31T19:50:07.410

@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 – 2015-09-02T01:18:27.557

@DaveScotese, right, it's not enforced, just the default. – morsecoder – 2015-09-02T01:51:35.547

Answers

1

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

Dave Scotese

Posted 2015-08-24T21:28:54.957

Reputation: 719

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 – 2015-08-27T10:32:29.130

"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 – 2015-08-27T10:35:05.903

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 – 2015-08-27T12:45:42.560

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 – 2015-08-27T12:49:06.770

@Murch I updated my answer to include the arbitrary nature of BTCDD regarding incompletely-propagated transactions. – Dave Scotese – 2015-08-28T21:26:24.820

@stephenm347 that was my idea too, but i suppose the attacker has more control over BTCDD than over the time. Although it's true that they burn through those coins relatively quickly. Has this proposal already been suggested to the wizards? Anyone a link to irc log or dev mailings post? – Jannes – 2015-09-08T03:51:20.930

And the attacker can estimate when the total BTCDD of mempool transactions reaches the BTCDD of the block he is withholding and THEN publish his block. That almost guarantees there will be no contending block and the attacker doesn't really risk his block reward. He does lose BTCDD with these 'failed' attempts but other than that the attack becomes almost riskless. Meaning every miner should start doing it. Which would cause a lot of wasted hashing because everyone is mining while someone has already found one. – Jannes – 2015-09-08T04:06:28.130

1And 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 – 2015-09-08T04:06:40.780

@Jannes, You may have missed the part of my answer that says "That advantage is easily removed by excluding from your BTCDD calculation transactions that you didn't see until you got this new block." However, we could even exclude the BTCDD of recently-collected transactions so that the attacker must release his BTCDD-heavy transaction early in order for his solution to be used. In fact, a brutal way to solve that is to double the running sum each time a new Tx is received. – Dave Scotese – 2015-09-10T05:38:15.450

Yes i had read that and found it clever. Looks like i forgot about it in my later comments i guess. Have you talked to any of the wizard yet? – Jannes – 2015-09-11T06:25:34.973

I have not sent an email to the dev groups (core or XT) yet. I wanted more critiques for testing and to refine the idea if it needs more refining. There's also the initial "how miners choose between forks isn't enforceable anyway" argument that I, myself, had trouble getting around: It's still important for the leadership to promote BTCDD of (now old and already-well-known) transactions as the best block-selection heuristic, as most miners will just leave defaults in place. – Dave Scotese – 2015-09-11T15:59:35.430

Although I find this idea interesting, I think most people would be of the mindset to 'not fix it if it isn't broken.' The current system works well. – morsecoder – 2015-12-28T16:03:04.050

Asked: 2015-08-24T21:28:54.957

Viewed: 209 times

Active: 2016-05-25T23:15:21.460