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

[Cameron Garnham via bitcoin-dev]

Hello Eric,

Thank you for your question and your time off-list clarifying your position. I’m posting to the list so that a wider audience may benefit.

Original Question: ‘Presumably the "very serious security vulnerability" posed is one of increased centralization of hash power. Would this danger exist without the patent risk?’

I would postulate that if ASICBOOST was originally released without the patent risk, then much of the risk would have been avoided; all of the mining manufactures would have implemented ASICBOOST and had a similar advantage. However, now time has passed and the damage of the patent monopoly exploiting CVE-2017-9230 has been already done. If the ASICBOOST patent was released to the public for free today, while a good thing, it wouldn’t soften the severity of the vulnerability we face today.

The ASICBOOST PATENT provides a miner with a constant-factor advantage. This is a huge problem with zero-sum games, such as mining. In game-theory, a constant factor advantage gives an exponential advantage over the time period maintained.

This explains why the Bitcoin Community initially took very little notice to ASICBOOST: The effects of ASICBOOST stated at virtually nothing, and it took a while for the advantage to been seen over the normal variance of mining. However, it’s influence has been exponentially growing since then: creating an emergency problem that we now face.

The result of ASICBOOST going unchecked is that very quickly from now, surprisingly quickly, the only profitable miners will be the miners who make use of ASICBOOST. This is a grave concern.

I will again reiterate that the virtue-signalling over perceived political motivations is ridiculous in the light what I consider a looming catastrophe, we should be judging by what is real not just perceived.

The catastrophe that I fear is one company (or a single politically connected group) gaining a virtual complete monopoly of Bitcoin Mining. This is more important to me than avoiding chain-splits. Without a well-distributed set of miners Bitcoin isn’t Bitcoin.

Cameron.


PS.

This attack is part of a larger set of licensing attacks, where patens are just one form of licensing attack. These attacks are particularly damaging in competitive markets such as mining. We should be vigilant for other attempts to create state-enforced licensing around mathematical algorithms. ASICBOOST is an illustrative example of what the Bitcoin Community needs to defend against.

Signed PGP part
Hi Cameron,
Presumably the "very serious security vulnerability" posed is one of
increased centralization of hash power. Would this danger exist
without the patent risk?
e

[Erik Aronesty via bitcoin-dev]

Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is
something that will simply never happen for basic engineering reasons.

Spoonet, an oft-quoted hard fork that actually has some strong support, is
a much better candidate for the code base - but not of the supposed
supporters of bit4 MASF seem to be ready to roll up their sleeves and do
any work at all. I mean, if they really had "millions" for development,
they could just hire dome developers and built it correctly, right? But
they aren't ... instead they are pumping money into "bcoin", which doesn't
yet have any of the protections needed to get consensus. Maybe it will
some day.

Claiming that miners support segwit is disingenuous ... considering that if
they supported it, they would be signaling for it today... instead of
distracting the community with fake proposals that have no peer-reviewed
code.


On Fri, May 26, 2017 at 5:21 AM, Tom Zander via bitcoin-dev <

So, I started searching for the motivations of such a large amount of the
mining hash-rate holding a position that isn’t at-all represented in the
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.

I’m uncomfortable with your “bingo” moment, and your huge assumption to get
to make it fit.
The reality is that we have seen repeatedly that the miners are stating
they
are Ok with an ASICBOOST disabling change.
The larger mining industry has just this week come to consensus about a
better way to activate SegWit! Referring to the New York consensus
meeting!!
consensus-2017-133521fe9a77
I question your conclusions of miners not supporting SegWit because of
ASICBOOST, the evidence shows this accusation to be false.
You openly admitting here that you use ASICBOOST as a tool to push SegWit
is
further making me uncomfortable. Your intention may be pure, but the
methods
are not.
And on that I agree with Andreas, that taints this proposal.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Tom Zander via bitcoin-dev]

Post by Erik Aronesty via bitcoin-dev
Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is
something that will simply never happen for basic engineering reasons.

The modifications to Bitcoin Core would take at most a day to do, plus a week
to test.
I’m not very happy with the full compromise myself, but can we please not
stomp on actual progress with nebulous problems?
I mean, you want SegWit, right?

Post by Erik Aronesty via bitcoin-dev
Claiming that miners support segwit is disingenuous ... considering that
if they supported it, they would be signaling for it today... instead of
distracting the community with fake proposals that have no peer-reviewed
code.

The nature of a compromise like the one that happened in New York is that
both parties do something they are not the most happy with in exchange for
the thing they want.
Miners have agreed to the SegWit part of this compromise. Calling that
disingenuous is not helpful...

[Anthony Towns via bitcoin-dev]

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.

[Eric Voskuil via bitcoin-dev]

Anthony,

For the sake of argument:

(1) What would the situation look like if there was no patent?

(2) Would the same essential formulation exist if there had been a
patent on bitcoin mining ASICs in general?

(3) Would an unforeseen future patented mining optimization exhibit
the same characteristics?

(4) Given that patent is a state grant of monopoly privilege, could a
state licensing regime for miners, applied in the same scope as a
patent, but absent any patent, have the same effect?

e

On Fri, May 26, 2017 at 11:02:27AM +0300, Cameron Garnham via

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.

* 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
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
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)
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
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.
_______________________________________________ bitcoin-dev mailing
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Anthony Towns via bitcoin-dev]

Post by Eric Voskuil via bitcoin-dev
Anthony,

(That seems like the cue to move any further responses to bitcoin-discuss)

Post by Eric Voskuil via bitcoin-dev
(1) What would the situation look like if there was no patent?

If there were no patent, and it were easy enough to implement it, then
everyone would use it. So blocking ASICBoost would decrease everyone's
hashrate by the same amount, and you'd just have a single retarget period
with everyone earning a little less, and then everyone would be back to
making the same profit.

But even without a patent, entry costs might be high (redesigning an
ASIC, making software that shuffles transactions so you can use the
ASIC's features) and how that works out seems hard to analyse...

Post by Eric Voskuil via bitcoin-dev
(2) Would the same essential formulation exist if there had been a
patent on bitcoin mining ASICs in general?

Not really; for the formulation to apply you'd have to have some way
to block ASIC use via consensus rules, in a way that doesn't just block
ASICs completely, but just removes their advantage, ie makes them perform
comparably to GPUs/FPGAs or whatever everyone else is using.

Reportedly, ASICBoost is an option you can turn on or off on some mining
hardware, so this seems valid (I'm assuming not using the option either
increases your electricity use by ~20% due to activating extra circuitry,
or decreases your hashrate by ~20% and maybe also decreases your
electricity use by less than that by not activating some circuitry); but
"being an ASIC" isn't something you can turn off and on in that manner.

Post by Eric Voskuil via bitcoin-dev
(3) Would an unforeseen future patented mining optimization exhibit
the same characteristics?

Maybe? It depends on whether the optimisation's use (or lack thereof)
can be detected (enforced) via consensus rules. If you've got a patent
on a 10nm process, and you build a bitcoin ASIC with it, there's no way
to stop you via consensus rules that I can think of.

Post by Eric Voskuil via bitcoin-dev
(4) Given that patent is a state grant of monopoly privilege, could a
state licensing regime for miners, applied in the same scope as a
patent, but absent any patent, have the same effect?

I don't think that scenario's any different from charging miners income
tax, is it? If you don't pay the licensing fee / income tax, you get put
out of business; if you do, you have less profit. There's no way to block
either via consensus mechanisms, at least in general...

I think it's the case that any optional technology with license fees can't
be made available to all miners on equal terms, though, provided there is
any way for it to be blocked via consensus mechanisms. If it were, the
choice would be:

my percentage of the hashrate is h (0<h, h much less than 1), total
hashrate is 1=100%, licensing fee is uniform per hashrate, so h*X,
advantage of using technology is a factor of r (0<r, r*h much less
than 1)

- technology allowed, I use it:
I make r*h but pay X*h, so revenue is proportional to (r-X)*h
- technology allowed, I don't use it:
I make h, pay nothing, so revenue is proportional to h

Provides the licensor sets X<r, of these choices I always chose to use
the technology, and so does everyone else. So base hashrate if no one
were to use the technology is H=1/r.

- technology not allowed, no one uses it:
I make h blocks, but total hashrate is 1/r, so revenue is proportional
to h/(1/r)=rh

But rh>(r-X)*h provided X>0, so all miners are better off if the
technology is not allowed (because they all suffer equally in loss of
hashrate, which is cancelled out in a retarget period; and they all
benefit equally by not having to pay licensing fees).

Sadly, the solution to this argument is to use discriminatory terms,
either not offering the technology to everyone, or offering varying fees
for miners with different hashrates. Unless somehow it works to make it
more expensive for higher hashrate miners, this makes decentralisation
worse.

Cheers,
aj

[Eric Voskuil via bitcoin-dev]

Post by Anthony Towns via bitcoin-dev

Post by Eric Voskuil via bitcoin-dev
Anthony,

(That seems like the cue to move any further responses to bitcoin-discuss)

I didn't meant to imply that the point was academic, just to ask your
indulgence before making my point. Thanks for the detailed and
thoughtful reply.

Post by Anthony Towns via bitcoin-dev

Post by Eric Voskuil via bitcoin-dev
(1) What would the situation look like if there was no patent?

If there were no patent, and it were easy enough to implement it, then
everyone would use it. So blocking ASICBoost would decrease everyone's
hashrate by the same amount, and you'd just have a single retarget period
with everyone earning a little less, and then everyone would be back to
making the same profit.
...

I don't accept that the ease (absolute cost) of implementing the
ASICBOOST optimization is relevant. The cost of implementation is offset
by its returns. Given that people are presumed to be using it profitably
I consider this point settled.

The important point is that if people widely use the optimization, it
does not constitute any risk whatsoever.

Post by Anthony Towns via bitcoin-dev

Post by Eric Voskuil via bitcoin-dev
(2) Would the same essential formulation exist if there had been a
patent on bitcoin mining ASICs in general?

Not really; for the formulation to apply you'd have to have some way
to block ASIC use via consensus rules, in a way that doesn't just block
ASICs completely, but just removes their advantage, ie makes them perform
comparably to GPUs/FPGAs or whatever everyone else is using.
...

I realize that the term "same essential formulation" was misleading, but
my aim was the *source* of harm (unblocked) in an ASIC patent as
compared to an ASICBOOST patent. It seems that you agree that this harm
in both cases results from the patent, not the optimization.

Nobody is suggesting that ASICs are a problem despite the significant
optimization. It is worth considering an alternate history where ASIC
mining had been patented, given that blocking it would not have been an
option. More on this below.

I agree that the optimizations differ in that there is no known way to
block the ASIC advantage, except for all people to use it. But correctly
attributing the source of harm is critical to useful threat modeling. As
the ASIC example is meant to show, it is very possible that an
unblockable patent advantage can arise in the future.

Post by Anthony Towns via bitcoin-dev

Post by Eric Voskuil via bitcoin-dev
(3) Would an unforeseen future patented mining optimization exhibit
the same characteristics?

Maybe? It depends on whether the optimisation's use (or lack thereof)
can be detected (enforced) via consensus rules. If you've got a patent
on a 10nm process, and you build a bitcoin ASIC with it, there's no way
to stop you via consensus rules that I can think of.

Quite clearly then there is a possibility (if not a certainty) that
Bitcoin will eventually be faced with an unblockable mining patent
advantage.

Post by Anthony Towns via bitcoin-dev

Post by Eric Voskuil via bitcoin-dev
(4) Given that patent is a state grant of monopoly privilege, could a
state licensing regime for miners, applied in the same scope as a
patent, but absent any patent, have the same effect?

I don't think that scenario's any different from charging miners income
tax, is it? If you don't pay the licensing fee / income tax, you get put
out of business; if you do, you have less profit. There's no way to block
either via consensus mechanisms, at least in general...

Precisely. This is a proper generalization of the threats above. A
patent is a state grant of monopoly privilege. The state's agent (patent
holder) extracts licensing fees from miners. The state does this for its
own perceived benefit (social, economic or otherwise). Extracting money
in exchange for permission to use an optimization is a tax on the
optimization.

Post by Anthony Towns via bitcoin-dev
I think it's the case that any optional technology with license fees can't
be made available to all miners on equal terms...

This is an important point. Consider also that a subsidy has the same
effect as a tax. A disproportionate tax on competing miners amounts to a
subsidy. A disproportionate subsidy amounts to a tax on competitors.

If the state wants to put its finger on the scale it can do so in either
direction. It can compel licensing fees from miners with no need for a
patent. It can also subsidize mining via subsidized energy costs (for
example), intentionally or otherwise.

Post by Anthony Towns via bitcoin-dev
Sadly, the solution to this argument is to use discriminatory terms,
either not offering the technology to everyone, or offering varying fees
for miners with different hashrates...

That sounds more like a central authority than a solution.

So, my point:

Mis-attributing the threat is not helpful. This is not an issue of an
unforeseen bug, security vulnerability, bad miners, or evil
patent-holders. This is one narrow example of the general, foreseen,
primary threat to Bitcoin - or any hard money.

Bitcoin's sole defense is decentralization. People parrot this idea
without considering the implication. How does decentralization work? It
works by broadly spreading the risk of state attack. But this implies
that some people are actually taking the risk.

By analogy, BitTorrent is estimated to have 250 million active users in
a month, and 200,000 have been sued in the US since 2010.
Decentralization works because it reduces risk through risk-sharing.

Bitcoin cannot generally prevent state patent/licensing/tax regimes.
Licensing is a ban that is lifted in exchange for payment. What is the
Bitcoin solution to a global ban on mining? On wallets? On exchange?

The Bitcoin defense against a patent is to ignore the patent. Berating
people for doing so seems entirely counterproductive.

e