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

[Eric Voskuil via bitcoin-dev]

On 05/29/2017 04:19 AM, Anthony Towns wrote:
> On Sat, May 27, 2017 at 01:07:58PM -0700, Eric Voskuil via bitcoin-dev wrote:
>> Anthony,
>> For the sake of argument:
> 
> (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.

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

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

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

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

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

> 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 

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

[Anthony Towns via bitcoin-dev]

On Sat, May 27, 2017 at 01:07:58PM -0700, Eric Voskuil via bitcoin-dev wrote:
> Anthony,
> For the sake of argument:

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

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

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

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

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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 05/26/2017 11:37 PM, Anthony Towns via bitcoin-dev wrote:
> 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 

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

[Anthony Towns via bitcoin-dev]

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 

Re: [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.



> On 26 May 2017, at 11:15 , Eric Voskuil  wrote:
> 
> 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
> 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Zander via bitcoin-dev]

On Friday, 26 May 2017 16:39:30 CEST Erik Aronesty wrote:
> 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?

> 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...
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote:
> > 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
> > wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment:
> > 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!!
> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-
> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Zander via bitcoin-dev]

On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote:
> 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
> wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment: 
> 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!!
https://medium.com/@DCGco/bitcoin-scaling-agreement-at-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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

On 05/26/2017 01:02 AM, Cameron Garnham via bitcoin-dev wrote:
> Thank you for your reply Andreas,
> 
> I can assure you that I have many motivations for activating
> SegWit.
> 
> Before studding ASICBOOST I wanted to activate SegWit as it is a
wonderful upgrade for Bitcoin. It seems to me that virtually the
entire Bitcoin Ecosystem agrees with me.  Except for around 67% of the
mining hash-rate who very conspicuously refuse to signal for it’s
activation.
> 
> 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 wider Bitcoin Community. My study of ASICBOOST lead
to a ‘bingo’ moment:  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.
> 
> This only strengthened my resolve to activate SegWit: not only is
SegWit great, it partially mitigates a very serious security
vulnerability.
> 
> This is why I call into question why you would suggest:
> 
> “This proposal is unnecessarily conflating two contentious issues
and will attract criticism of self serving motivation.”
> 
> 1. I am not conflating the issues.  I would argue that very fact
that SegWit has not been activated yet is directly because of
CVE-2017-9230.
> 2. I have no reason to believe that SegWit is contentious, except
for the attackers who it would frustrate.
> 3. I have no negative responses to my endeavours to get ASICBOOST
> as
regarded as a legitimate security vulnerability.  This would suggest
that it is not contentious in the wider technical community.
> 
> If SegWit is NOT contentious within the technical community and it
is NOT contentious to regard CVE-2017-9230 as a credible security
vulnerability. Then using it as partial security fix for a security
vulnerability SHOULD NOT be contentious.
> 
> If you believe that SegWit is contentious within the technical
community.  Or you believe CVE-2017-9230 should not be regarded as a
credible security vulnerability. Then I would logically agree with you
that we should separate the issues so that we may gain consensus.
However, I just don’t see this as the case.
> 
> Cameron.
> 
> 
>> On 26 May 2017, at 09:52 , Andreas M. Antonopoulos
 wrote:
>> 
>> I rarely post here, out of respect to the mailing list. But
>> since
my name was mentioned...
>> 
>> I much prefer Gregory Maxwell's proposal to defuse covert
>> ASICBOOST
(only) with a segwit-like commitment to the coinbase which does not
obligate miners to signal Segwit or implement Segwit, thus disarming
any suspicion that the issue is being exploited only to activate Segwit.
>> 
>> This proposal is unnecessarily conflating two contentious issues
and will attract criticism of self serving motivation.
>> 
>> Politicising CVE  is damaging to the long term bitcoin
>> development
and to its security. Not claiming that is the intent here, but the
damage is done by the mere appearance of motive.
>> 
>> 
>> 
>> On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev"
 wrote:
>> Hello Bitcoin-Dev,
>> 
>> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a
>> severe
(3) (4) and actively exploited (5) security vulnerability.
>> 
>> To learn more about this vulnerability please read Jeremy
>> Rubin’s
detailed report:
>> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>> 
>> Andreas Antonopoulos has an excellent presentation on why
>> asicboost
is dangerous:
>> https://www.youtube.com/watch?v=t6jJDD2Aj8k
>> 
>> In decisions on the #bitcoin-core-dev IRC channel; It was
>> proposed,
without negative feedback, that SegWit be used as a partial-mitigation
of CVE-2017-9230.
>> 
>> SegWit partially mitigates asicboost with the common reasonable
assumption that any block that doesn’t include a witness commit in
it's coinbase transaction was mined using covert asicboost.  Making
the use of covert asicboost far more conspicuous.
>> 
>> It was also proposed that this partial mitigation should be
>> quickly
strengthened via another soft-fork that makes the inclusion of witness
commits mandatory, without negative feedback.
>> 
>> The security trade-offs of deploying a partial-mitigation to
CVE-2017-9230 quickly vs more slowly but more conservatively is under
intense debate.  The author of this post has a strong preference to
the swiftest viable option.
>> 
>> Cameron.
>> 
>> 
>> (1) CVE Entry: 
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
>> 
>> (2) Announcement of CVE to Mailing List:
>> 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.
html
>> 
>> (3) Discussion of the perverse incentives created by 'ASICBOOST'
>> 

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

[Andreas M. Antonopoulos via bitcoin-dev]

I rarely post here, out of respect to the mailing list. But since my name
was mentioned...

I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only)
with a segwit-like commitment to the coinbase which does not obligate
miners to signal Segwit or implement Segwit, thus disarming any suspicion
that the issue is being exploited only to activate Segwit.

This proposal is unnecessarily conflating two contentious issues and will
attract criticism of self serving motivation.

Politicising CVE  is damaging to the long term bitcoin development and to
its security. Not claiming that is the intent here, but the damage is done
by the mere appearance of motive.



On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello Bitcoin-Dev,
>
> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3)
> (4) and actively exploited (5) security vulnerability.
>
> To learn more about this vulnerability please read Jeremy Rubin’s detailed
> report:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>
> Andreas Antonopoulos has an excellent presentation on why asicboost is
> dangerous:
> https://www.youtube.com/watch?v=t6jJDD2Aj8k
>
> In decisions on the #bitcoin-core-dev IRC channel; It was proposed,
> without negative feedback, that SegWit be used as a partial-mitigation of
> CVE-2017-9230.
>
> SegWit partially mitigates asicboost with the common reasonable assumption
> that any block that doesn’t include a witness commit in it's coinbase
> transaction was mined using covert asicboost.  Making the use of covert
> asicboost far more conspicuous.
>
> It was also proposed that this partial mitigation should be quickly
> strengthened via another soft-fork that makes the inclusion of witness
> commits mandatory, without negative feedback.
>
> The security trade-offs of deploying a partial-mitigation to CVE-2017-9230
> quickly vs more slowly but more conservatively is under intense debate.
> The author of this post has a strong preference to the swiftest viable
> option.
>
> Cameron.
>
>
> (1) CVE Entry:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
>
> (2) Announcement of CVE to Mailing List:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014416.html
>
> (3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan
> Grant:
>  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014352.html
>
> (4) Discussion of ASICBOOST's non-independent PoW calculation by Tier
> Nolan:
>  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014351.html
>
> (5) Evidence of Active Exploit by Gregory Maxwell:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-April/013996.html
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Cameron Garnham via bitcoin-dev]

Thank you for your reply Andreas,

I can assure you that I have many motivations for activating SegWit.

Before studding ASICBOOST I wanted to activate SegWit as it is a wonderful 
upgrade for Bitcoin. It seems to me that virtually the entire Bitcoin Ecosystem 
agrees with me.  Except for around 67% of the mining hash-rate who very 
conspicuously refuse to signal for it’s activation. 

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 wider 
Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment:  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.

This only strengthened my resolve to activate SegWit: not only is SegWit great, 
it partially mitigates a very serious security vulnerability.

This is why I call into question why you would suggest:

“This proposal is unnecessarily conflating two contentious issues and will 
attract criticism of self serving motivation.”

1. I am not conflating the issues.  I would argue that very fact that SegWit 
has not been activated yet is directly because of CVE-2017-9230.
2. I have no reason to believe that SegWit is contentious, except for the 
attackers who it would frustrate.
3. I have no negative responses to my endeavours to get ASICBOOST as regarded 
as a legitimate security vulnerability.  This would suggest that it is not 
contentious in the wider technical community.

If SegWit is NOT contentious within the technical community and it is NOT 
contentious to regard CVE-2017-9230 as a credible security vulnerability. Then 
using it as partial security fix for a security vulnerability SHOULD NOT be 
contentious.

If you believe that SegWit is contentious within the technical community.  Or 
you believe CVE-2017-9230 should not be regarded as a credible security 
vulnerability. Then I would logically agree with you that we should separate 
the issues so that we may gain consensus. However, I just don’t see this as the 
case.

Cameron.


> On 26 May 2017, at 09:52 , Andreas M. Antonopoulos  
> wrote:
> 
> I rarely post here, out of respect to the mailing list. But since my name was 
> mentioned... 
> 
> I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only) 
> with a segwit-like commitment to the coinbase which does not obligate miners 
> to signal Segwit or implement Segwit, thus disarming any suspicion that the 
> issue is being exploited only to activate Segwit.
> 
> This proposal is unnecessarily conflating two contentious issues and will 
> attract criticism of self serving motivation.
> 
> Politicising CVE  is damaging to the long term bitcoin development and to its 
> security. Not claiming that is the intent here, but the damage is done by the 
> mere appearance of motive. 
> 
> 
> 
> On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" 
>  wrote:
> Hello Bitcoin-Dev,
> 
> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3) (4) 
> and actively exploited (5) security vulnerability.
> 
> To learn more about this vulnerability please read Jeremy Rubin’s detailed 
> report:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
> 
> Andreas Antonopoulos has an excellent presentation on why asicboost is 
> dangerous:
> https://www.youtube.com/watch?v=t6jJDD2Aj8k
> 
> In decisions on the #bitcoin-core-dev IRC channel; It was proposed, without 
> negative feedback, that SegWit be used as a partial-mitigation of 
> CVE-2017-9230.
> 
> SegWit partially mitigates asicboost with the common reasonable assumption 
> that any block that doesn’t include a witness commit in it's coinbase 
> transaction was mined using covert asicboost.  Making the use of covert 
> asicboost far more conspicuous.
> 
> It was also proposed that this partial mitigation should be quickly 
> strengthened via another soft-fork that makes the inclusion of witness 
> commits mandatory, without negative feedback.
> 
> The security trade-offs of deploying a partial-mitigation to CVE-2017-9230 
> quickly vs more slowly but more conservatively is under intense debate.  The 
> author of this post has a strong preference to the swiftest viable option.
> 
> Cameron.
> 
> 
> (1) CVE Entry:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
> 
> (2) Announcement of CVE to Mailing List:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.html
> 
> (3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan 
> Grant:
>  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
> 
> (4) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan:
>  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
> 
> (5) Evidence of Active Exploit by Gregory Maxwell:
>