Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

Den 17 apr. 2017 16:14 skrev "Erik Aronesty via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: It's too bad we can't make the POW somehow dynamic so that any specialized hardware is impossible, and only GPU / FPGA is possible. Maybe a variant of Keccak where the size of the sponge is

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

It's too bad we can't make the POW somehow dynamic so that any specialized hardware is impossible, and only GPU / FPGA is possible. Maybe a variant of Keccak where the size of the sponge is increased along with additional zero bits required. Seems like this would either have to resist

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

On Apr 16, 2017 6:28 PM, wrote: On 2017-04-16 17:04, Erik Aronesty via bitcoin-dev wrote: > This is a great solution. > > 8 or more secure hashes, each of which can be implemented on GPU/CPU, > but rotate through them - per block round robin. > > Hardware, infrastructue

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

On 2017-04-16 17:04, Erik Aronesty via bitcoin-dev wrote: This is a great solution. 8 or more secure hashes, each of which can be implemented on GPU/CPU, but rotate through them - per block round robin. Hardware, infrastructue investment is protected. ASIC is not. The write time for

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

This is a great solution. 8 or more secure hashes, each of which can be implemented on GPU/CPU, but rotate through them - per block round robin. Hardware, infrastructue investment is protected. ASIC is not. Each pow has different tracking metrics and difficulty adjustments. This means the

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

ation.org <bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Nick ODell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> Sent: Monday, March 20, 2017 6:02:52 PM To: Andrew Johnson; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Malice Reactive Proof of Wo

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

ing security. -- *From:* Andrew Johnson <andrew.johnso...@gmail.com> *Sent:* Monday, March 20, 2017 3:38:01 PM *To:* Bitcoin Protocol Discussion; John Hardy *Subject:* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners By

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

rotocol Discussion Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners It's possible to switch PoW algorithms with a soft fork rather than a hard fork. You make it so that there are two different PoWs, the old one and the new one,

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

I am in support of having multiple PoW forks to choose from, but it is indeed problematic to have one chain running a rotation of algorithms. The reason I support multiple algos is because we don't want an attacker secretly making asics ahead of time in the event of an emergency PoW fork. We want

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

Chain work currently means the expected number of sha256d evaluations needed to build a chain. Given that these hash functions are not equally hard, what should the new definition of chain work be? On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

It's possible to switch PoW algorithms with a soft fork rather than a hard fork. You make it so that there are two different PoWs, the old one and the new one, and each old-style block has to reference a new-style block and contain the exact same transactions. The new work rule is that the

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

Hi, Just a thought, Bitcoin developers shouldn't care about miners business model, they can always sell their hw and close the bz as soon as bitcoin hardforks to better ways of doing. Just focus on making a better cryptocurrency, the more decentralized the best. M > By doing this you're

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

om: Andrew Johnson <andrew.johnso...@gmail.com> Sent: Monday, March 20, 2017 3:38:01 PM To: Bitcoin Protocol Discussion; John Hardy Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners By doing this you're significantly changing the ec

[bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

I’m very worried about the state of miner centralisation in Bitcoin. I always felt the centralising effects of ASIC manufacturing would resolve themselves once the first mover advantage had been exhausted and the industry had the opportunity to mature. I had always assumed initial