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

[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 <andr...@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
> 
> 

Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

[Cameron Garnham via bitcoin-dev]

Hello Bitcoin-Dev,

A quick update that CVE-2017-9230 has been assigned for the security 
vulnerability commonly called ‘ASICBOOST’:

"The Bitcoin Proof-of-Work algorithm does not consider a certain attack 
methodology related to 80-byte block headers with a variety of initial 64-byte 
chunks followed by the same 16-byte chunk, multiple candidate root values 
ending with the same 4 bytes, and calculations involving sqrt numbers. This 
violates the security assumptions of (1) the choice of input, outside of the 
dedicated nonce area, fed into the Proof-of-Work function should not change its 
difficulty to evaluate and (2) every Proof-of-Work function execution should be 
independent.”

I would like to especially thank the CVE team at Mitre for their suggested 
description that was more appropriate than my proposed text.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230

Cameron.



> Begin forwarded message:
> 
> From: 
> Subject: Re: [scr-x] Bitcoin - All
> Date: 24 May 2017 at 18:52:22 GMT+3
> To: 
> Cc: 
> 
> Signed PGP part
> > [Suggested description]
> > The Bitcoin Proof-of-Work algorithm does not consider a certain attack
> > methodology related to 80-byte block headers with a variety of initial
> > 64-byte chunks followed by the same 16-byte chunk, multiple candidate
> > root values ending with the same 4 bytes, and calculations involving
> > sqrt numbers. This violates the security assumptions of (1) the choice
> > of input, outside of the dedicated nonce area, fed into the
> > Proof-of-Work function should not change its difficulty to evaluate
> > and (2) every Proof-of-Work function execution should be independent.
> >
> > --
> >
> > [Additional Information]
> > ASICBOOST, originality promoted as a patented mining optimisation(1).
> > Has under detailed study (2), become regarded as an actively exploited
> > (3), security vulnerability (4), of Bitcoin.
> >
> > The Bitcoin Proof-of-Work Algorithm is dependent on the following two
> > security assumptions that are both broken by 'ASICBOOST':
> > 1. The choice of input, outside of the dedicated nonce area, fed into
> > the Proof-of-Work function should not change it's difficulty to
> > evaluate.
> > 2.  Every Proof-of-Work function execution should be independent.
> >
> > 'ASICBOOST' creates a layer-violation where the structure of the input
> > outside of the dedicated nonce area will change the performance of the
> > mining calculations (5). 'ASICBOOST' exploits a vulnerability where
> > the Proof-of-Work function execution is not independent (6).
> >
> > References:
> > (1) Original Whitepaper by Dr. Timo Hanke: 
> > https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf
> > (2) Academic Write-up by Jeremy Rubin: 
> > http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
> > (3) Evidence of Active Exploit by Gregory Maxwell:
> >  
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
> > (4) Discussion to assign a CVE Number, by Cameron Garnham:
> >   
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html
> > (5) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan 
> > Grant:
> >   
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
> > (6) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan:
> >   
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
> >
> > The patent holder of this particular security vulnerability has a dedicated 
> > website: https://www.asicboost.com/
> >
> > --
> >
> > [VulnerabilityType Other]
> > Cryptocurrency Mining Algorithm Weakness
> >
> > --
> >
> > [Vendor of Product]
> > Bitcoin
> >
> > --
> >
> > [Affected Product Code Base]
> > Bitcoin - All
> >
> > --
> >
> > [Affected Component]
> > Bitcoin
> >
> > --
> >
> > [Attack Type Other]
> > Cryptocurrency Proof-of-Work Algorithm Weakness
> >
> > --
> >
> > [CVE Impact Other]
> > Creation of Perverse Incentives in a Cryptocurrency
> >
> > --
> >
> > [Attack Vectors]
> > Bitcoin Mining Unfair Advantage
> > Bitcoin Layer-Violations Creating Perverse System Incentives
> >
> > --
> >
> > [Reference]
> > https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf
> > http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
> > 

Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

[Cameron Garnham via bitcoin-dev]

(message was originally sent off-list by mistake).

Hello Tier,

Thank-you for your insightful reply,

Am I correct that this suggest is that you think it is an optimisation to find 
some nonces having lower difficulty than other nonces?

I would agree with you if this was limited to a dedicated nonce area of the 
Bitcoin System.

However, in the case of Bitcoin it is a layer violation that the PoW function 
difficulty could be affected by the choice the transaction ordering, or the 
content of the Coinbase Transaction, etc.  Possibly giving unnatural and 
unintended incentives to other parts of the Bitcoin System.

I can see two issues at play here:

1.  The choice of input, outside of the dedicated nonce area, fed the PoW 
function should not change it’s difficulty to evaluate.
2.  Every PoW function execution should be independent.

I think that both of these are security assumptions of the Bitcoin PoW function.

I consider ASICBOOST as an attack upon both accounts.

Cameron.

> 
> On 18 May 2017, at 17:59 , Tier Nolan via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> On Thu, May 18, 2017 at 2:44 PM, Cameron Garnham via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 1. Significant deviations from the Bitcoin Security Model have been 
> acknowledged as security vulnerabilities.
> 
> The Bitcoin Security Model assumes that every input into the Proof-of-Work 
> function should have the same difficulty of producing a desired output.
> 
> This isn't really that clear.
> 
> Arguably as long as the effort to find a block is proportional to the block 
> difficulty parameter, then it isn't an exploit.  It is just an optimisation.
> 
> A quantum computer, for example, could find a block with effort proportional 
> to the square root of the difficulty parameter, so that would count as an 
> attack.  Though in that case, the fix would likely be to tweak the difficulty 
> parameter update calculation.
> 
> A better definition would be something like "when performing work, each hash 
> should be independent".  
> 
> ASICBOOST does multiple checks in parallel, so would violate that.

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

[bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

[Cameron Garnham via bitcoin-dev]

Hello Bitcoin Development Mailing List,

I wish to explain why the current approach to ‘ASICBOOST’ dose not comply with 
our established best practices for security vulnerabilities and suggest what I 
consider to be an approach closer matching established industry best practices.


1. Significant deviations from the Bitcoin Security Model have been 
acknowledged as security vulnerabilities.

The Bitcoin Security Model assumes that every input into the Proof-of-Work 
function should have the same difficulty of producing a desired output.


2. General ASIC optimisation cannot be considered a Security 
Vulnerabilities.

Quickly being able to check inputs is not a vulnerability. However, being able 
to craft inputs that are significantly easier to check than alternative inputs 
is a vulnerability.


3. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.

‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and should be 
considered an exploit of the Bitcoin Proof-of-Work Function.

For a more detailed look at ‘ASICBOOST’, please have a look at this excellent 
document by Jeremy Rubin:
http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf

The Bitcoin Community should be able to track the progress of restoring the 
quality of the Bitcoin Proof-of-Work function to its original assumptions.


4. Work should be taken to prudently and swiftly restore Bitcoins Security 
Properties.

I recommend the Bitcoin Community fix this vulnerability with expediency.



Cameron.

PS:

With a soft-fork it probably is possible to completely fix this Proof-of-Work 
vulnerability.

(Here is my working list of things to do):

1. Include extra data in the Coinbase Transaction, such as the Witness Root.

2. Lock the Version. (Use a space in the Coinbase Transaction for 
signalling future upgrades).

3. Lock the lower-bits on the Timestamp: Block timestamps only need 
~1minute granularity.

4.  Make a deterministic ordering of transaction chains within a block. 
(However, I believe this option is more difficult).

Of course, if we have a hard-fork, we should consider the Proof-of-Work 
internal merkle structure directly.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Exploring Network Rule Changes

[Cameron Garnham via bitcoin-dev]

I have taken some time to think about consensus systems in-general; and write 
up a guide that explores the problems space of changing the rules of such 
systems.

Hopefully, this guide will clarify the different options available to the 
Bitcoin Community.

I am posting this to the Bitcoin Development mailing list for review. Possibly 
a more comprehensive form of this document could be useful as an informative 
BIP.


** Type of Change **

There are three categories of changes:

S:  Addition of a new Rule. (Soft-Fork)
H:  Removal of an old Rule. (Hard-Fork)
E:  Subverting an old Rule. (“Evil”, Non-Traditional Soft-Fork)

* Addition of a new Rule:
All previous rules in the system remain enforced as originally intended.

There are two sub-categories for the addition of a new rule:

1:  New Functionally is added to the system, without effecting old use 
cases. (Opt-In New Functionality)
2:  Functional users of the system must change their behaviour to suit the 
new rule. (Mandatory New Functionality)

* Removal of an old Rule
Equivalent replacing the entire system with any-new system.  All full-users of 
the system must migrate to the new system.

* Subverting an old Rule
New Functionally is added that explicitly Replaces Old Functionality.

Users must upgrade and migrate to the new Functionally to continue using the 
system.


** Type of Activation **

There are two types of activations:

U.  External Activations. (User Activated)
M.  Internal Activations. (Miner Activated, PoS Activated, Internal 
Governance Model, etc)

It is possible to have more than one Activation Strategy used concurrently.

* External Activations
These Activations are dictated by facts that are not quantifiable from within 
the System.

Generally, this will be a set-of-users, external to the system, that come to 
their own agreement to change the system.

* Internal Activations
These activations use some metric from within the system to determine if a 
proposed change is activated.

Generally, some sort of internal signalling or vetoing process will happen and 
based upon its results, will dictate the if the change is activated.


** Type of Signalling **

Users within the system with more important roles may wish to (or be forced to) 
signal or (not) veto about a particular topic. This could be part of the 
activation strategy (internal activations), or just simply to quantify the 
support of the upcoming change.

There are two core types of Signalling:

O:  Optional
F.  Forced

There are two styles of Signalling:

N.  Normal Signalling (Opt-In)
V.  Veto (Opt-Out)

* Optional Signalling
Orthogonal to the system rules; however, the signalling still may affect other 
system rules.

* Enforced Signalling
This is a meta-rule change. Normally only temporally enforced upon the system. 
This rule change doesn’t directly affect the core behaviour of the system; it 
is just used for meta-purposes in the scope of another rule change.

* Normal Signalling
Passive Behaviour signals no support.

* Veto Signalling
Passive Behaviour signals support.


If I have missed anything or if anything is not clear, please contact me.

PS.

For example, you could call a BIP9 (SegWit) activation as a:  “S1MON".  And BIP 
148 (SegWit) as:  “S1UFN”.  However this letter code is just for fun. :)

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

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Cameron Garnham via bitcoin-dev]

Thank-you for your prompt response,

I believe I must have a different prospective of Bitcoin to you.  Ideologically 
I don’t agree that miners can be passive participants in the Bitcoin Network; 
and I certainly don’t see them acting as passive participants in the Bitcoin 
Community now.

The miners are very much political actors.  Hence why I fail to take-to-heart 
your concern "that the proposal will reject the blocks of passive participants”.

With AsicBoost, there are three miner groups: Those who use it (and have legal 
sanction to do so); Those who use it (without legal sanction); and those who 
don’t use it.  If SegWit didn’t directly affect miners, then one could possibly 
claim that there could be an ideal passive participant miner in reality. 
However since your important revelations on AsicBoost: SegWit cannot be a 
‘passive’ option for miners.

Hence, I don’t care about orphaning the blocks of of the theoretical "passive 
participant” miner. As I have no logical reasoning to suggest one could exists; 
and a large amount of evidence to suggesting one dose not exit.


On BIP 16 vs. BIP 17;  I cannot see how BIP 148 similar engineering tradeoffs.  
Is there any long-term ‘technical debt’ from BIP 148 that I’m unaware of that 
could be similar to BIP 16?


On the Drama:  Well 100M USD p/a can pay for lots of Drama; Hence going back to 
the first point: The miners are not passive participants when it comes to *any* 
form of activation of SegWit.

Cameron.



> On 15 Apr 2017, at 10:04 AM, Gregory Maxwell  wrote:
> 
> On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham  wrote:
>> As many may remember, there was quite some controversy about the BIP16 vs 
>> BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how 
>> this was the already “tested and proven to work” solution.
> 
> And as a result we ultimately got a clearly inferior solution (520
> byte script limit; 80-bit security; months of orphaned blocks-- and
> two of those were not issues in BIP17).  I went along for the cram
> fest on 16 after 12 caught fire, and I was mistaken to do so.
> 
> Doubly so because it took years for P2SH to achieve any kind of mass
> deployment due to issues far away from consensus.  An extra two months
> spent on some ground-work (including communications and documentation)
> could have pulled forward practical deployment by a year and given
> time to find and fix some of the flaws in the design of P2SH.
> 
>> BIP 148 is out (our?) terms of peace.  The Bitcoin Community is 
>> tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a 
>> outlet, and in Maxwell words: “...almost guarantees at a minor level of 
>> disruption.”.
> 
> It seems I lost a word in my comment: that should have been "almost
> guarantees at _least_ a minor level of disruption". A minor level of
> disruption is the _minimum_ amount of disruption, and for no good
> reason except an unprecedented and unjustified level of haste.
> 
> Considering that you did not spare a single word about the specific
> property that I am concerned about-- that the proposal will reject the
> blocks of passive participants, due to avoidable design limitations--
> I can't help but feel that you don't even care to understand the
> concern I was bringing up. :(
> 
> How many people barely reviewed the specifics of the proposal simply
> because they want something fast and this proposal does something
> fast?
> 
>> tired-to-death of this war and wants a resolution swiftly
> 
> By now competitors and opponents to Bitcoin have surely realized that
> they can attack Bitcoin by stirring up drama.
> 
> As a result, the only way that we will ever be free from "war" is if
> we choose to not let it impact us as much as possible. We must be
> imperturbable and continue working at the same level of excellence as
> if virtual shells weren't flying overhead-- or otherwise there is an
> incentive to keep them flying 24/7. Internet drama is remarkably cheap
> to generate. "The only thing we have to fear is fear itself".
> 
> The alternative is that we hand opponents a ready made formula for
> disruption: astroturf enough drama up that Bitcoiners "sacrifice
> correctness" themselves right off a cliff in a futile attempt to make
> it go away. :)

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

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Cameron Garnham via bitcoin-dev]

Hello,

It is hard for me to come out disagreeing with Maxwell, however in this case I 
feel I must.

As many may remember, there was quite some controversy about the BIP16 vs BIP 
17 split; the main argument for BIP16 was the urgency of P2SH, and how this was 
the already “tested and proven to work” solution.

I was one of the man hold-out supporters of BIP17, not for any clear reason (I 
now have a much better technical understanding of the Bitcoin technical 
details, as we all do); But because it was the ‘more elegant’ solution.  I knew 
from other fields of engineering that elegant solutions very often better deal 
with the ‘unknown, unknowns’.  I also didn’t agree with Gavin’s ‘the sky is 
falling’ sense of urgency.

However, of-course the community got behind BIP16, it was activated, 
fortunately, without any signifiant incident.

I did learn that in Bitcoin there is something more valuable than technical 
elegance: that is community buy-in. On the technical side, the engineers need 
to make sure the solutions are viable: however on the community side we need to 
make sure that the good solutions are adopted in a reasonable timeframe.

It is both my empirical view and heart-felt belief that the wider Bitcoin 
Community wants SegWit quickly. In this case the sacrifice of some technical 
elegance and correctness for expediency is prudent!

It is my unfortunate view that Maxwell is missing the political forest for the 
technical trees.  Not only is SegWit a technical solution to technical 
problems; it has come to represent, by the larger Bitcoin Community, a 
political solution to the conflict that we are waist-deep in every, single, day.

BIP 148 is out terms of peace.  The Bitcoin Community is tired-to-death of this 
war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell 
words: “...almost guarantees at a minor level of disruption.”.

I am willing to go through this minor level of disruption, as the daily 
disruption from the “scaling debate war”; in my personal online life, is far 
greater.

SegWit is a exceptional feat of engineering, it solves and mitigates so many 
small and highly subtle issues within Bitcoin; yet still managed to be simple 
enough successfully reviewed: now the community is clearly calling for a quick 
activation of the ‘viable’ technical choice.

If you/we are going to provide any engineering solution to activating SegWit, 
then Swiftness should be the 1st priority after viability.

BIP 148 is both Swift and Viable.

Cameron.



> On 14 Apr 2017, at 10:56 AM, Gregory Maxwell via bitcoin-dev 
>  wrote:
> 
> I do not support the BIP148 UASF for some of the same reasons that I
> do support segwit:  Bitcoin is valuable in part because it has high
> security and stability, segwit was carefully designed to support and
> amplify that engineering integrity that people can count on now and
> into the future.
> 
> I do not feel the the approach proposed in BIP148 really measures up
> to the standard set by segwit itself, or the existing best practices
> in protocol development in this community.
> 
> The primary flaw in BIP148 is that by forcing the activation of the
> existing (non-UASF segwit) nodes it almost guarantees at a minor level
> of disruption.
> 
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
> 
> Older nodes will not include segwit spends, and so their blocks will
> not be invalid even if they do not have segwit support. They can
> upgrade to it on their own schedule. The only risk non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it, a risk many miners already
> frequently take with spy-mining.
> 
> I do not think it is a horrible proposal: it is better engineered than
> many things that many altcoins do, but just not up to our normal
> standards. I respect the motivations of the authors of BIP 148.  If
> your goal is the fastest possible segwit activation then it is very
> useful to exploit the >80% of existing nodes that already support the
> original version of segwit.
> 
> But the fastest support should not be our goal, as a community-- there
> is always some reckless altcoin or centralized system that can support
> something faster than we can-- trying to match that would only erode
> our distinguishing value in being well engineered and stable.
> 
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test.  To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
> 
> Of course, I do not oppose the general concept of a UASF but
> _generally_ a soft-fork (of any kind) does not need to risk 

[bitcoin-dev] Strong Anti-Replay via Coinbase Transactions

[Cameron Garnham via bitcoin-dev]

  BIP: ???
  Layer: Consensus (soft fork)
  Title: Strong Anti-Replay via Coinbase Transactions
  Author: Cameron Garnham 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???
  Status: Draft
  Type: Standards Track
  Created: 2017-03-25
  License: BSD-3-Clause
   CC0-1.0


==Abstract==

This document specifies a soft fork that enables users to make transactions 
with a strong expectation that such transactions cannot be replayed on a 
different chain.

Important Note: In the case that an adversary hard-fork, the strong guarantee 
of non-replayabilty via this BIP may not be supported.

==Definitions==



==Motivation==

In the case of a chain split, it is important to protect users from, 
potentially significant, loss of funds from transaction replay attacks.


==Specification==

Upon activation of the soft-fork (activation methodology undefined in this 
proposal), the following new rules become activated on the Bitcoin Network.

New ‘anti-replay’ OpCode.  Take an unused NoOp and redefine it as 
‘OP_ANTI_REPLAY’.

The script must only have the form:

scriptPubKey: (empty)
scriptSig: OP_ANTI_REPLAY

OP_ANTI_REPLAY has the following specification:

• OP_ANTI_REPLAY outputs must only be created in a coinbase transaction.
• OP_ANTI_REPLAY coinbase outputs must only have the value of 1 Satoshi.
• Transaction must not included more than 1 OP_ANTI_REPLAY input.
• If a OP_ANTI_REPLAY input is included in a transaction, the 
transaction must also be marked as Opt-In-RBF (BIP 125).

The Bitcoin Network should maintain a total of exactly 100 000 OP_ANTI_REPLAY 
outputs, with the exception of the the first 99 blocks after activation of this 
soft fork.

Upon activation of this soft fork.  Every blocks coinbase transaction will be 
required to create exactly 1000 new OP_ANTI_REPLAY outputs, up to the total of 
100 000.

If a OP_ANTI_REPLAY is spent in a block, a corresponding new OP_ANTI_REPLAY 
must be included in the same block.

It is recommend the miners account the size of a OP_ANTI_REPLAY transaction as: 
 transactions size + size of a OP_ANTI_REPLAY output in coinbase.

In the case of an chain split after this BIP has activated, miners should 
‘recycle’ all the OP_ANTI_REPLAY outputs via spending and recreating them in 
new blocks.  Renewing the protection to the new chain.


=== Reference implementation ===

To-Be-Implemented

==Backwards Compatibility==

This deployment is compatible with all existing bitcoin software.

Upon activation, all deployed Bitcoin Full Nodes will enforce the anti-replay 
projections for Bitcoin Users. (Only upgraded nodes will enforce the other 
OP_ANTI_REPLAY requirements).

==Rationale==

The only know way of guaranteeing that a transaction cannot be replayed is to 
include an input that cannot exist, by-definition, on the alternative chain.  
Coinbase transactions are the only transaction type that is know to exhibit 
this property strongly.

This BIP makes it convenient for wallets to automate the inclusion of new 
coinbase inputs into transactions that spend potentially repayable 
transactions.  Everything in this BIP could be done manually by close 
cooperation between the users and miners, however the author thinks that it is 
preferable to have it well-defined and enforced.

On Opt-In-RBF enforcement:  In the case of conflicting spends of OP_ANTI_REPLAY 
outputs, the higher-fee transaction should take priority.  Wallets may select a 
random OP_ANTI_REPLAY, then check if the competing transaction has a 
sufficiently low fee to be replaced.

It is expected that every OP_ANTI_REPLAY output will be in the memory pools 
waiting to be spend; users must compete for this resource.

==Future Questions==

SegWit Compatibility?

==References==

Opt-In-RBF:  https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 
Universal.

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

Re: [bitcoin-dev] BIP 151

[Cameron Garnham via bitcoin-dev]

There are two different topics mixed up here.

1. Link-level security (secure connection to the node we intended to connect 
to).

2. Node-level security (aka; don't connect to a 'evil node').

The fist requires link-level encryption and authentication.

The second requires identity authentication.

You described the 'evil node' attack; that indeed needs an identity system to 
stop. However BIP151 doesn't intend to protect against connecting to evil 
Bitcoin Nodes.

It is important not to mixup link-level authentication and node-level 
authentication.

When your client picks random nodes to connect to, you are not considered whom 
in particular runs them. (Rather that you have a good random sample of the 
network).

If you manually add a friends node; at this point you wish to have node-level 
authentication.  However, this may (and probably should) happen out-of-band.


Sent from my iPhone

> On 29 Jun 2016, at 01:07, Eric Voskuil  wrote:
> 
> Hi Cameron, good to hear from you!
> 
>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham  wrote:
>> 
>> Unauthenticated link level encryption is wonderful! MITM attacks are 
>> overrated; as they require an active attacker.
> 
> This is not really the case with Bitcoin. A MITM attack does not require that 
> the attacker find a way to inject traffic into the communication between 
> nodes. Peers will connect to the attacker directly, or accept connections 
> directly from it. Such attacks can be easier than even passive attacks.
> 
>> Stopping passive attacks is the low hanging fruit. This should be taken 
>> first.
>> 
>> Automated and secure peer authentication in a mesh network is a huge topic. 
>> One of the unsolved problems in computer science.
>> 
>> A simple 'who is that' by asking for the fingerprint of your peers from your 
>> other peers is a very simple way to get 'some' authentication.  Semi-trusted 
>> index nodes also is a low hanging fruit for authentication.
> 
> It is the implication of widespread authentication that is at issue. Clearly 
> there are ways to implement it using a secure side channels.
> 
>> However, let's first get unauthenticated encryption. Force the attackers to 
>> use active attacks. (That are thousands times more costly to couduct).
>> 
>> Sent from my iPhone
>> 
>>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev 
>>>  wrote:
>>> 
>>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>>>  wrote:
 An "out of band key check" is not part of BIP151.
>>> 
>>> It has a session ID for this purpose.
>>> 
 It requires a secure channel and is authentication. So BIP151 doesn't 
 provide the tools to detect an attack, that requires authentication. A 
 general requirement for authentication is the issue I have raised.
>>> 
>>> One might wonder how you ever use a Bitcoin address, or even why we
>>> might guess these emails from "you" aren't actually coming from the
>>> NSA.
>>> ___
>>> 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] BIP 151

[Cameron Garnham via bitcoin-dev]

Unauthenticated link level encryption is wonderful! MITM attacks are overrated; 
as they require an active attacker.

Stopping passive attacks is the low hanging fruit. This should be taken first.

Automated and secure peer authentication in a mesh network is a huge topic. One 
of the unsolved problems in computer science.

A simple 'who is that' by asking for the fingerprint of your peers from your 
other peers is a very simple way to get 'some' authentication.  Semi-trusted 
index nodes also is a low hanging fruit for authentication.

However, let's first get unauthenticated encryption. Force the attackers to use 
active attacks. (That are thousands times more costly to couduct).

Sent from my iPhone

> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev 
>  wrote:
> 
> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>  wrote:
>> An "out of band key check" is not part of BIP151.
> 
> It has a session ID for this purpose.
> 
>> It requires a secure channel and is authentication. So BIP151 doesn't 
>> provide the tools to detect an attack, that requires authentication. A 
>> general requirement for authentication is the issue I have raised.
> 
> One might wonder how you ever use a Bitcoin address, or even why we
> might guess these emails from "you" aren't actually coming from the
> NSA.
> ___
> 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] Bitcoin XT 0.11A

[Cameron Garnham via bitcoin-dev]

Since it was a game theory analysis. I will not address your other comments.


On 17/8/2015 7:22 AM, Andrew LeCody wrote:
 4. Setup a fork of Bitcoin XT that allows people to easily make a
 transaction only on the XT fork (while leaving the original BTC coins
 untouched).
 
 I doubt this is even possible.

Trivial.

There are a few ways: here is my favorite (for the moment).

1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT'

2. Let these spam tx be in BitcoinXT, however not Bitcoin (easily done).

3. Let the forked XT client includes a unspent dust output with any
transaction. Let the this client create 100 dust outputs for other
people to use in the same transaction.

This transaction will only be possible to confirm with Bitcoin XT. -
Leaving your Bitcoin coins untouched.

I particularly like this approach, as it is ironic as the spam is more
cheaply done with larger blocks.

Cam.


A quick political note:
https://en.wikipedia.org/wiki/Abstentionism

Hard forks are not something that is a democratic process. Thus
frustrating a false-democratic process is completely legitimate.



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev