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 i

[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 flag

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 specializ

[bitcoin-dev] Suggestions to improve opcodes with O(N) complexity

2017-04-17 Thread Sergio Demian Lerner via bitcoin-dev
I came across O(N) behavior of two scripting opcodes, OP_IF and OP_ROLL. By exploiting edge cases for each of these two sub-optimal algorithms, I manage to simulate a Segwit block that takes up to 5.6 seconds to verify on a Ubuntu VM running on a single Core i5 processor. The simulation is based on

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 investment is protected

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 o

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 wil