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

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

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

ce 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 exploite

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

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

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

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 bitcoi

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

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.

[bitcoin-dev] Exploring Network Rule Changes

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

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

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

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

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

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

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

Re: [bitcoin-dev] BIP 151

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

Re: [bitcoin-dev] BIP 151

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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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