Yes, FIBRE uses UDP and FEC. That's one of the biggest reasons why it's so good. I've also seen a private UDP implementation of raw block transmission at Bitmain a few years back which allowed them to get around 90 Mbps on a 100 Mbps link across the border. UDP FEC FTW.
Given that shadders mentioned the November timeline for the "fast link idea," I think it's quite likely he's talking about Graphene. So we should ask the people who are implementing that into Bitcoin Cash daemons if they're using UDP.
Hey, are we using UDP for Graphene?
@Peter R
Thanks for doing that math. Plugging some numbers into your equations and running with it:
Assume attacker (A)=20% defender (B)=10%
rb /
ra = (1 -
B) /
B = 0.9 / 0.1 =
9
Orphan rate ratio is 9. This means that 9 out of 10 blocks orphaned will be the defender's.
For each orphaned block, the attacker gains 0.2 of a block reward due to later difficulty decreases, the defender gains 0.1, and the others gain 0.7. The owner of that particular block also loses 1.
Attacker's net results: (10 * 0.2) + (1 * -1) = 1 block
Defender's net results: (10 * 0.1) + (9 * -1) = -8 blocks
Others' net results: (10 * 0.7) + (0 * -1) = 7 blocks
So the attacker expects to gain 0.1 blocks for each orphan race in this case where he has 0.1 more hashrate than his opponent.
More generally:
An entity's benefit from someone else's block being orphaned equals 1 block times their hashrate share.
An entity's benefit from an orphan race equals the above plus -1 blocks times their probability of losing the race (i.e. their opponent's share).
A's opponent is B. B's opponent is A+C. C has no opponents.
A's net results per race: (1 * A) + (B * -1)
B's net results per race: (1 * B) + ((A+C) * -1)
C's net results per race: (1 * C) + (0 * -1)
If we assume that A can make blocks that have an arbitrarily large delay without A's acceleration, orphan races will happen whenever A miners a block immediately followed by B. That is, they happen with frequency AB.
A's expected benefit: AB * (A-B) =
0.2%
B's expected benefit: AB * (B - (A+C)) =
-1.6%
C's expected benefit: AB * (C) =
1.4%
If we plug in A=.4, B=.2, C=.4, we get:
A's expected benefit: AB * (A-B) =
1.6%
B's expected benefit: AB * (B - (A+C)) =
-4.8%
C's expected benefit: AB * (C) =
3.2%
If the unaccelerated propagation time is t, then you multiply all those numbers by 1-e^(-t/600). For the 83 second delay I calculated a couple posts ago for an adversarial graphene 1 GB block, that would be a factor of 12.92%.
A pool with hashrate=0.4 and 83 second delay can gain 0.2067%% with this attack. Typical pool fees are on the order of 0.9% to 3%, so an extra 0.2067% would
increase their total profit by 6.89% to 23.0%.
A pool with hashrate=0.2 and 83 second delay can
increase their total profit by 0.86% to 2.9%.
In BCH terms, if A=0.4 and the block reward is 12.5 BCH, then the pool can gain 350.2 BCH per month in stolen profit. At A=0.2, the pool can gain 21.888 BCH/mo in stolen profit.
That seems like a scenario where it could be worthwhile for someone to actually perform this attack. A single pool with 40% of the hashrate is not too farfetched. We've seen that before several times. Even the 20% pool has a lot to gain.
One might think that miners would just switch pools from A to C if A did a selfish attack, since C actually benefits more than A. In truth, though, A would just cycle through all the other pools, so each one would have an equal amount of time being the victim. If this attack were being performed, it would just look like A had a lower orphan rate than everybody else. When calculating how much they owe their customers, they could use the network-average orphan rate and pocket the difference.
Interestingly, this attack appears to be profitable for any sized miner or pool to perform. A pool with 1% of the network hashrate would have a positive (but tiny) expected benefit from using this attack against a 0.5% miner or pool. However, the infrastructure costs (for VPSs) increase if you want to be able to target miners that finely, so it's only practical for larger pools.
...
Can anyone think of a good name for this attack? "Propagation-mediated selfish mining" is awkward. Maybe "network-partitioning delay attack"? There has to be something better than that.