Re: Shelᖚy (TPTB_need_war) Psychoanalysis. Smartest Man in the Altcoin Discussions?
And I am just a spectator 
Signatures should eventually be verified on GPUs (or similar SIMD units that get integrated into CPUs in time). That will happen when it is needed. CPU SIMD instructions are kind of interesting but also kind of narrowly-targeted. Processing large amounts of data in a fixed pipeline will still be more efficient on GPU-type architectures.
This is why only main memory random access latency bound proof-of-work algorithms can potentially remain GPU and ASIC resistant. And they must be carefully designed so that increased computation can not be realistically traded for latency. One of the challenges in such a design for a memory hard hash, is that very slow speed if you want the memory consumed to be larger than the SRAM caches of GPUs and ASICs. Ideally you want the computation to be very small, so that the electrical efficiency optimization of the ASIC won't be significant.
"Insufficient" is unclear because there is no unambiguous definition of how much is sufficient.
In large part it depends on the decentralization of mining. If mining is decentralized then you only need a small (but still nonzero) incentive because any miner can't really do anything other than follow the longest chain rule. While raw hash rate attacks are possible (i.e. temporarily centralizing mining by incurring a cost), in a larger system they will have significant cost and will only succeed as long as the ongoing cost is paid.
If mining is highly concentrated by nature then you are really only relying on the weak linear security of the block reward itself, and maybe not even that, because miners (e.g., hypothesized Chinese cartels) have all sorts of perverse incentives.
Your statement would be correct if you added ", assuming mining becomes centralized as I have claimed it will."
I will argue my statement was correct as stated, because there are other parties with significant resources and incentives who may not be mining normally but once the hashrate declines to the tail reward cost, they can then decide it is easier to attack the coin.
The better retort would be to argue that the as the adoption increases, the price will rise so the fixed size (in coins) tail reward has an adaptive valuation.
But I will retort that the value of shorting also scales up accordingly.
Rather what I do in my improved design, is to set the cost of mining to the reasonable fraction of the transaction value.
That is why I say the only way to solve the block chain Tragedy of the Commons is to require what is effectively a minimum transaction fee in the protocol. But then there is the problem of miners competing with each other to rebate the fee to the payer/payee so how to enforce a minimum transaction fee?
There is only one way to do that, which is to burn the fees. But if you burn them then the money supply declines to 0. So the only way is to burn hashrate. And that is why only my design which makes mining unprofitable will solve the problem.
I believe it's not only CPU miners that are at stake here. Even signatures could be validated 2-4 at a time, on the same subroutine, to get SIMD benefits. So scaling is affected as well. It would need the main routine to be adjusted accordingly instead of sending 1 for processing (per thread) to 2-4 (per thread) and expect back 2-4. Heck, even cracking speed could be improved.
Signatures should eventually be verified on GPUs (or similar SIMD units that get integrated into CPUs in time). That will happen when it is needed. CPU SIMD instructions are kind of interesting but also kind of narrowly-targeted. Processing large amounts of data in a fixed pipeline will still be more efficient on GPU-type architectures.
This is why only main memory random access latency bound proof-of-work algorithms can potentially remain GPU and ASIC resistant. And they must be carefully designed so that increased computation can not be realistically traded for latency. One of the challenges in such a design for a memory hard hash, is that very slow speed if you want the memory consumed to be larger than the SRAM caches of GPUs and ASICs. Ideally you want the computation to be very small, so that the electrical efficiency optimization of the ASIC won't be significant.
[1] Note this means the tail reward security of Monero will be very weak and insufficient.
"Insufficient" is unclear because there is no unambiguous definition of how much is sufficient.
In large part it depends on the decentralization of mining. If mining is decentralized then you only need a small (but still nonzero) incentive because any miner can't really do anything other than follow the longest chain rule. While raw hash rate attacks are possible (i.e. temporarily centralizing mining by incurring a cost), in a larger system they will have significant cost and will only succeed as long as the ongoing cost is paid.
If mining is highly concentrated by nature then you are really only relying on the weak linear security of the block reward itself, and maybe not even that, because miners (e.g., hypothesized Chinese cartels) have all sorts of perverse incentives.
Your statement would be correct if you added ", assuming mining becomes centralized as I have claimed it will."
I will argue my statement was correct as stated, because there are other parties with significant resources and incentives who may not be mining normally but once the hashrate declines to the tail reward cost, they can then decide it is easier to attack the coin.
The better retort would be to argue that the as the adoption increases, the price will rise so the fixed size (in coins) tail reward has an adaptive valuation.
But I will retort that the value of shorting also scales up accordingly.
Rather what I do in my improved design, is to set the cost of mining to the reasonable fraction of the transaction value.
That is why I say the only way to solve the block chain Tragedy of the Commons is to require what is effectively a minimum transaction fee in the protocol. But then there is the problem of miners competing with each other to rebate the fee to the payer/payee so how to enforce a minimum transaction fee?
There is only one way to do that, which is to burn the fees. But if you burn them then the money supply declines to 0. So the only way is to burn hashrate. And that is why only my design which makes mining unprofitable will solve the problem.
Demonstrating my research on programming language (type) theory:
https://users.rust-lang.org/t/high-order-function-with-type-parameter/3112/8
https://users.rust-lang.org/t/most-coveted-rust-features/324/38
Or in short, why we probably don't need higher-kinded and higher-ranked types, but we do need first-class disjunctions and inversion-of-control ad hoc dispatch.
https://users.rust-lang.org/t/high-order-function-with-type-parameter/3112/8
https://users.rust-lang.org/t/most-coveted-rust-features/324/38
Or in short, why we probably don't need higher-kinded and higher-ranked types, but we do need first-class disjunctions and inversion-of-control ad hoc dispatch.