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 i
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 specializ
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 investment is protected
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 confi
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 diff
linuxfoundation.org
on behalf of Nick ODell via
bitcoin-dev
Sent: Monday, March 20, 2017 6:02:52 PM
To: Andrew Johnson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA):
Protecting Bitcoin from malicious miners
Chain work currently means
op in hashing security.
--
*From:* Andrew Johnson
*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 doi
ocol 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,
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
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 <
bitcoin-dev@lists.linuxfoundation.
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 weighted
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 significa
Andrew Johnson
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 economic incentives be
By doing this you're significantly changing the economic incentives behind
bitcoin mining. How can you reliably invest in hardware if you have no idea
when or if your profitability is going to be cut by 50-75% based on a whim?
You may also inadvertently create an entirely new attack vector if 50-7
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 centralisatio
15 matches
Mail list logo