Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

[Anthony Towns <aj@erisian.com.au>]

On Fri, May 26, 2017 at 11:02:27AM +0300, Cameron Garnham via bitcoin-dev wrote:
> If one assumes that the 67% of the hash rate that refuse to signal
> for SegWit are using ASICBOOST. The entire picture of this political
> stalemate became much more understandable.

A couple of bits of math that might be of interest:

 * if 67% of the hash rate is running ASICBoost, and ASICBoost gives a
   20% performance improvement as stated on asicboost.com and in
   Greg's BIP proposal, then blocking ASICBoost would change the
   balance of miners from 67%/33% to 62.8%/37.2%; resulting in a 6.3%
   loss for income for ASICBoost miners (not 20%), and a 12.7% gain for
   non-ASICBoost miners.  In this case, total apparent hashrate reduces
   to 88.8% of what it originally was when ASICBoost is blocked (though
   the actual security either stays the same or increases, depending on
   your attack model) [0]

 * if ASICBoost use is lower than that, say 33% (eg made up of
   AntPool 18%, BTC.top 10%, ViaBTC 5%), then the shift is from 33%/67%
   to 29.1%/70.9%, and results in a 13% loss for ASICBoost miners,
   versus a 6% gain for non-ASICBoost miners. In these cases, a price
   rise in the region of 7% to 15% due to blocking ASICBoost would be
   enough to make everyone better off [1].

 * AIUI there are three feasible ways of doing ASICBoost: overt via
   the version field, semi-covert via mining an empty block and grinding
   the coinbase extra nonce, and fully covert by reordering the block
   transaction merkle tree. If the fully covert method is made infeasible
   via a secondary merkle commitment in the coinbase a la segwit, and for
   whatever reason overt ASICBoost isn't used, then empty block mining is
   still plausible, though presumably becomes unprofitable when the extra
   20% of block subsidy is less than the fees for a block.  That's adds
   up to fees per block totalling greater than 2.5BTC, and 2.5BTC/1MB is
   250 satoshis per byte, which actually seems to be where fees are these
   days, so unless they're getting more than the claimed 20% benefit,
   people mining empty blocks are already losing money compared to just
   mining normally... (Of course, 250 satoshis per byte is already fairly
   painful, and only gets more so as the price rises)

Personally, I expect any technical attempt to block ASICBoost use to fail
or result in a chain split -- 67% of miners losing 6% of income is on
the order of $5M a month at current prices. Having an approach that is as
simple as possible (ie, independent from segwit, carefully targetted, and
impossible to oppose for any reason other than wanting to use ASICBoost)
seems optimal to me, both in that it has the highest chance to succeed,
and provides the most conclusive information if/when it fails.

Cheers,
aj

[0] Assuming ASICBoost miners have hardware capable of doing A hashes with
    ASICBoost turned off, or A*B (B=1.2) with ASICBoost turned on, and
    the remainder of miners have a total hashrate of R. Then overall
    hashrate is currently H=A*B+R, and ASICBoost hashrate is a = A*B/(A*B+R),
    with a = 67% if the quoted claim is on the money. Rearranging:

           a = A*B/(A*B+R)
           a*(A*B+R) = A*B
           a*A*B + a*R = A*B
           a*R = (1-a)*A*B
           R = (1/a-1)*A*B

    So a' = A/(A+R), the ASICBoost miner's hashrate if they're forced to
    turn ASICBoost off, is:

           a' = A/(A+R)
           a' = A/(A+(1/a-1)*A*B)
              = 1/(1+(1/a-1)*B)

    But if a=0.67 and B=1.2, then a' = 0.628.

    The ratio of what they are getting to what they would getting is
    just a/a',

           a/a' = a*(1+(1/a-1)*B)
                = (a+(1-a)*B)

    and their loss is a/a'-1, which is:

         a/a'-1 = (a+(1-a)*B) - 1
                = (a+(1-a)*B) - (a+1-a)
                = (1-a)*(B-1)

    which is only 20% (B-1) when a is almost zero. When a increases (ie,
    there is a higher percentage of ASICBoost miners, as sure seems to
    be the case) the potential loss from disabling ASICBoost dwindles
    to nothing (because 1-a goes to zero and B-1 is just a constant).

    Note that this is the case even with mining centralisation -- if you
    have 99% of the hashrate with ASICBoost, you'll still have 98.8% of
    the hashrate without it, making a 0.2% loss (though of course your
    competitors with 1% hashrate will go to 1.2%, making a 20% gain).
    The reason is you're competing with all the ASICBoost miners,
    *including your own*, for the next block, and the size of the reward
    you'll get for winning doesn't change.

    Total apparent hashrate is A+R versus A*B+R, so

        (A+R)/(A*B+R) = 1/(A/(A+R)) * (A*B/(A*B+R))/B
                      = 1/a' * a/B
                      = a/a' / B
                      = (a+(1-a)*B) / B
                      = a/B + (1-a)

    (yeah, so that formula's kind of obvious...)

[1] Except maybe the patent holders (err, applicants). Though per the
    recent open letter it doesn't seem like anyone's actually paying for
    the patents in the first place. If miners were, then coordinated
    disarmament might already be profitable; if you're paying say 10%
    of your mining income in licensing fees or similar, that might seem
    sensible in order to make 20% more profit; but if blocking everyone
    from using ASICBoost would reduce your licensing fees by 10% of your
    income, but only reduce your income by 6.3%, then that adds up to
    a 3.7% gain and a bunch less hassle.

    I think if the ASICBoost patent holders were able to charge perfectly
    optimally, they'd charge royalty fees of about 8.3% of miner's
    income (so ASICBoost miners would make 10% net, rather than 20%),
    and allow no more than 50% of miners to use it (so the effective
    ASICBoost hashrate would be about 55%). That way the decision to
    block ASICBoost would be:

        X * 1.2 * (1-0.083) / (0.5 * 1.2 + 0.5)  -- ASICBoost allowed
      = X * 1.1004 / 1.1
      > X
    vs
        X / (0.5 + 0.5) -- ASICBoost banned
      = X

    and ASICBoost wouldn't be disabled, but the patent holders would
    still be receiving 4.15% (50%*8.3%) of all mining income. If more
    than 50% of hashpower was boosted, the formula would change to, eg,

        X * 1.2 * (1-0.083) / (0.51 * 1.2 + 0.49)
      = X * 1.1004 / 1.102
      < X

    and similarly if the fee was slightly increased, and in that case all
    miners would benefit from disabling ASICBoost. Around these figures
    ASICBoost miners would only gain/lose very slightly from ASICBoost
    getting blocked; the big losers would be the patent holders, who'd
    go from raking in 4.15% of all mining income to nothing, and the
    big winners would be the non-ASICBoost miners, who'd gain that 4.15%
    of income. The possibility of transfer payments from non-ASICBoost
    miners to ASICBoost miners to block ASICBoost might change that
    equation, probably towards lower fees and higher hashrate.

    For comparison, if 67% of hashrate is using ASICBoost, they can't
    charge them all more than 5.5% of their mining income, or miners
    would prefer to block ASICBoost, and that would only give the patent
    holders 3.7% of all mining income, much less.

    If patent holders can convince miners not to communicate with each
    other so that they think that a smaller amount of hashpower is using
    ASICBoost than actually is, that might also allow collecting more
    royalties without risking collective action to block ASICBoost.

    Of course, this is assuming they can charge all miners optimally
    and no one infringes patents, and that if you're prevented from
    using ASICBoost you don't have to keep paying royalties anyway,
    and so on. Just completely realistic, plausible assumptions like that.