* [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
@ 2017-05-26 6:30 Cameron Garnham
2017-05-26 6:52 ` Andreas M. Antonopoulos
0 siblings, 1 reply; 12+ messages in thread
From: Cameron Garnham @ 2017-05-26 6:30 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 6:30 [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 Cameron Garnham
@ 2017-05-26 6:52 ` Andreas M. Antonopoulos
2017-05-26 8:02 ` Cameron Garnham
0 siblings, 1 reply; 12+ messages in thread
From: Andreas M. Antonopoulos @ 2017-05-26 6:52 UTC (permalink / raw)
To: Cameron Garnham; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4620 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 6:52 ` Andreas M. Antonopoulos
@ 2017-05-26 8:02 ` Cameron Garnham
2017-05-26 8:15 ` Eric Voskuil
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Cameron Garnham @ 2017-05-26 8:02 UTC (permalink / raw)
To: Andreas M. Antonopoulos; +Cc: Bitcoin Protocol Discussion
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 <andreas@antonopoulos•com> 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" <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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 8:02 ` Cameron Garnham
@ 2017-05-26 8:15 ` Eric Voskuil
2017-05-26 19:20 ` Cameron Garnham
2017-05-26 9:21 ` Tom Zander
2017-05-27 6:37 ` Anthony Towns
2 siblings, 1 reply; 12+ messages in thread
From: Eric Voskuil @ 2017-05-26 8:15 UTC (permalink / raw)
To: Cameron Garnham, Andreas M. Antonopoulos; +Cc: Bitcoin Protocol Discussion
-----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
<andreas@antonopoulos•com> 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"
<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/01399
6.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJZJ+Q1AAoJEDzYwH8LXOFOqakH/R1YCifIGjV07vnnsxeC/77x
d6w5tBmtEd5MLzrX/6VtMoI8UzgLEcDM1WfFox3jDVz/HurkTVorliyJrr14BVsc
rL2nTbfychYh1rAdTIsNwFt15Wgjcp/5eAq7Lw5TM5OJ3YbPn2zWJY19QmjEAJ+M
kGz26R+IJL1095yed5RN2JoN8O9x+HVdtIjaHJJRJzLsy+3g22zMWgN1nZN0olhX
mFQJZbvS0gQyiRGJmNku3zP5Qg2cFzWt+VBtFrzNu1QTTkbK2e1owHOmpgfygTD3
g3F4VoDfyA7pBnpMMMjjTaCaG34Am3CvYu8iYnZXy85s2ZjC+XeKgqMkBLj4+q8=
=A3ne
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 8:02 ` Cameron Garnham
2017-05-26 8:15 ` Eric Voskuil
@ 2017-05-26 9:21 ` Tom Zander
2017-05-26 14:39 ` Erik Aronesty
2017-05-27 6:37 ` Anthony Towns
2 siblings, 1 reply; 12+ messages in thread
From: Tom Zander @ 2017-05-26 9:21 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 9:21 ` Tom Zander
@ 2017-05-26 14:39 ` Erik Aronesty
2017-05-26 14:54 ` Tom Zander
0 siblings, 1 reply; 12+ messages in thread
From: Erik Aronesty @ 2017-05-26 14:39 UTC (permalink / raw)
To: Tom Zander; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3755 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 14:39 ` Erik Aronesty
@ 2017-05-26 14:54 ` Tom Zander
0 siblings, 0 replies; 12+ messages in thread
From: Tom Zander @ 2017-05-26 14:54 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 8:15 ` Eric Voskuil
@ 2017-05-26 19:20 ` Cameron Garnham
0 siblings, 0 replies; 12+ messages in thread
From: Cameron Garnham @ 2017-05-26 19:20 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
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 <eric@voskuil•org> 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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-26 8:02 ` Cameron Garnham
2017-05-26 8:15 ` Eric Voskuil
2017-05-26 9:21 ` Tom Zander
@ 2017-05-27 6:37 ` Anthony Towns
2017-05-27 20:07 ` Eric Voskuil
2 siblings, 1 reply; 12+ messages in thread
From: Anthony Towns @ 2017-05-27 6:37 UTC (permalink / raw)
To: 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 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-27 6:37 ` Anthony Towns
@ 2017-05-27 20:07 ` Eric Voskuil
2017-05-29 11:19 ` Anthony Towns
0 siblings, 1 reply; 12+ messages in thread
From: Eric Voskuil @ 2017-05-27 20:07 UTC (permalink / raw)
To: Anthony Towns, 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 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.
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJZKdyaAAoJEDzYwH8LXOFO83IH/2FNwxjg1x9mlYMCLntShQZ+
2eA3M/0Hg+Zys9JfkHeRfaXr8qIC4inAJ88dDZ8EoVwKlAobmVk9iBEb/+3IS2ol
XKVSloe12AG3z0zi09bDtSu3b49Z11ZCw10uveHKbxxKqaiT1wohgX8eefHox1OJ
iGni8mGZhm3q4XTCtf5DrwTLAyplfHIeYtniXmlgkSpPjujJEB0H8viWs0QmghVc
udQqz5MfcBu1Rf9TukpT+lhOWDw189mTkomNy/npJaiJFalBIIzT6iMIU22FRS6j
xibIgdfq+3zAlZj4YAtyoIXSqdOnN2LKieY2hiLSjXwjk1xjnrqIc4ApDuW+dfk=
=NeOF
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-27 20:07 ` Eric Voskuil
@ 2017-05-29 11:19 ` Anthony Towns
2017-05-31 6:17 ` Eric Voskuil
0 siblings, 1 reply; 12+ messages in thread
From: Anthony Towns @ 2017-05-29 11:19 UTC (permalink / raw)
To: 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<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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
2017-05-29 11:19 ` Anthony Towns
@ 2017-05-31 6:17 ` Eric Voskuil
0 siblings, 0 replies; 12+ messages in thread
From: Eric Voskuil @ 2017-05-31 6:17 UTC (permalink / raw)
To: Anthony Towns, bitcoin-dev, Libbitcoin Development
[-- Attachment #1.1: Type: text/plain, Size: 5811 bytes --]
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 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-05-31 6:18 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-26 6:30 [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 Cameron Garnham
2017-05-26 6:52 ` Andreas M. Antonopoulos
2017-05-26 8:02 ` Cameron Garnham
2017-05-26 8:15 ` Eric Voskuil
2017-05-26 19:20 ` Cameron Garnham
2017-05-26 9:21 ` Tom Zander
2017-05-26 14:39 ` Erik Aronesty
2017-05-26 14:54 ` Tom Zander
2017-05-27 6:37 ` Anthony Towns
2017-05-27 20:07 ` Eric Voskuil
2017-05-29 11:19 ` Anthony Towns
2017-05-31 6:17 ` Eric Voskuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox