Quote from: iamnotback on October 29, 2016, 06:48:33 PM

Quote from: iamnotback on October 29, 2016, 04:38:42 PM

Quote from: AlexGR on October 29, 2016, 01:08:13 PM

Somewhat relevant: https://steemit.com/blockchain/@dantheman/a-better-approach-to-turing-complete-smart-contracts

The performance difference is impressive. And it also allows for zero-fee txs/contracts (I guess until someone finds a way to spam it).

That is not the correct solution because of course it gives the spammer an asymmetrical advantage. And the problem with sharding is not just that messages between shards are multi-threading (this can actually be solved by requiring messages to be queued to the next block), but rather that then both shards have to verify the entire history chain of those cross-chard "transactions", which defeats the performance improvement of shards. Vitalik probably proposes to have shard validators trust each other with forfeitable deposits, but that like PoS destroys Nash Equilibrium. As well as I explained my video, external business logic can conflate shards even if cross-shard messages are restricted, leading to chaos, discontent when a shard validator set has lied (for profit obviously), and a drop in the value of the token. Bruce Wanker will be laughing again.

I finally realized the solution to last sentence in the prior paragraph, which I alluded to in my prior comment. It suddenly just popped into my mind when I listened to myself.

Dan Larimer is rushing and making mistakes:

Quote from: https://steemit.com/blockchain/@dantheman/a-better-approach-to-turing-complete-smart-contracts#@anonymint/re-dantheman-a-better-approach-to-turing-complete-smart-contracts-20161029t183257782z

Quote

Steem, on the other hand, easily survived the flood attacks thrown at it without disrupting service and all without any transaction fees!

Were those bandwidth DDoS attacks filtered by perimeter nodes, or validation attacks absorbed by validating nodes?

Quote

The price of GAS would go up until it stunted the growth of all three applications.

Incorrect. If the price of GAS would increase due to higher demand but the lesser amount of GAS needed would still reflect the unchanged cost of validating a script at that higher price.

Quote

The native implementation would cause all the same outputs given the same inputs, except it wouldnt know how to calculate the GAS costs because it wasnt run on the EVM.

It could simply compute its own cost based on some counters. If it knows its optimized implementation is less costly than the EVM, then it doesn't harm (i.e. remains compliant) by keeping the GAS if it is depleted before the script completes. Others verifying the depletion case would run the EVM, as this wouldn't cost them more than running native version. For non-depleted scripts, validators run their most efficient native version.

Quote

Require a proof-of-work on each script

Unless this is more expensive in resources than the cost of validating the script, then the attacker has an asymmetric DoS advantage. So all you've done is shifted the cost of paying the fee to generating the equivalent proof-of-work.

And unless each script consumer has access to a premium ASIC, then the attacker still has an asymmetric advantage. And if you say the script consumer can farm out this ASIC, then you've shifted the DoS attack to the said farm.

Quote

Local Blacklist / White list scripts, accounts, and/or peers

That is effective for bandwidth DDoS, but Nash Equilibirium can be gamed by an open system w.r.t. to submitting data for validation.

I just stumbled across this critique and wanted to add a response:

1. Users attempted to flood the steem network with transactions, validating nodes included transactions at the specified limit.
2. There is a limited supply of computational power, thus people bid up the price they are willing to pay to transact and it results in increased profit margins due to the fixed (unchanged computational cost) of validating a script. Just like BTC fees rise now that blocks are full, the cost to transact on ETH will rise once the single-threaded performance limit is hit.

Your remaining points about POW on each script and Nash Equilb are completely missing the point by getting lost in the weeds.

An attacker can submit a transaction for validation that fails after the allowed time (say 2ms). The attacker generates the transaction but doesn't run it themselves, which gives them an advantage over the defender.

If the defender sets an arbitrary POW requirement on a per-connection basis, then they can force the attacker to perform a 2ms POW that is validated in 1 us before attempting to process the script. The attacker would have to redo their POW for each peer they want to broadcast to.

Long-lasting connections can build up "trust" and reduce POW requirements for nodes that demonstrate they do not relay invalid transactions. First violation of trust reverts back to POW.

Anyway, preventing SPAM is a trivial problem compared to attempting to scale ETH.