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

2017-04-17 Thread Natanael via bitcoin-dev
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

[bitcoin-dev] Transaction signalling

2017-04-17 Thread Erik Aronesty via bitcoin-dev
If users added a signal to OP_RETURN, might it be possible to tag all validated input addresses with that signal. Then a node can activate a new feature after the percentage of tagged input addresses reaches a certain level within a certain period of time? This could be used in addition to a

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

2017-04-17 Thread Erik Aronesty via bitcoin-dev
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

2017-04-17 Thread Erik Aronesty via bitcoin-dev
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] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-17 Thread Aymeric Vitte via bitcoin-dev
While I fully agree with the intent (increasing full nodes so a big miner waking up in a bad mood can't threaten the world any longer every day as it is now) I am not sure to get the interest of this proposal, because: - it's probably not a good idea to encourage the home users to run full nodes,

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-17 Thread David Vorick via bitcoin-dev
Most people do not want to go out and buy new hardware to run a Bitcoin node. The want to use the hardware that they already own, and usually that hardware is going to have a non-generous amount of disk space. 500GB SSD with no HDD is common in computers today. But really, the best test is to go

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-17 Thread Danny Thorpe via bitcoin-dev
1TB HDD is now available for under $40 USD. How is the 100GB storage requirement preventing anyone from setting up full nodes? On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > *Rationale:* > > A node that stores the full blockchain (I

[bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-17 Thread David Vorick via bitcoin-dev
*Rationale:* A node that stores the full blockchain (I will use the term archival node) requires over 100GB of disk space, which I believe is one of the most significant barriers to more people running full nodes. And I believe the ecosystem would benefit substantially if more users were running