ethereum is useless because smart contracts cost too much money

that's what upgrades are for

>>3513868
ETH will be surpassed by BTC version of more secure smart contracts

you think its coincidence that BTC has the most active github from all cryptos?

>>3513902

you can already implement smart contracts to an extent, problem is the documentation is shit and the api is cryptic at best.

>>3513890
????

>>3513925
have you never seen the matrix movie?

>>3513868
>ethereum is useless for poor people
ftfy
poor people don't deserve things.

>>3513868
Are dapps good for anything but record keeping?

>>3513868
lightning network will fix this anon

just let ethereum die already ffs

>>3514178
Yes

>>3514918
Tell me about it. I don't know anything about cryptocurrency.

>what is off-chain computation

File: foreveralone.png (133KB, 1500x1521px) Image search: [Google]

133KB, 1500x1521px

1.) Bitcoin can't scale for shit.

2.) Ethereum is just bitcoin scripting, so it will have the same type of scalability issues when ERC20 contracts are flooding the network.

3.) People are ignoring the scalability issues coming because normies are starting to get in and NEETS want to feel like they are the cool kids for once

>>3515123
so what can be done? As someone who actually wants to make dapps, there doesn't seem to be...a point.

>>3515134
A new coin built from the ground up. Maybe some in development or out already, need to research more.

>he doesn't know about state channels

>>3515362
So ARDR or Lisk?

>>3515383
Educate me pls

>>3515123
>2.) Ethereum is just bitcoin scripting
stopped reading here

>>3515134
Metropolis, Raiden and Casper will solve scaling. The most competent people to solve scaling are the Ethereum developers. Gas prices will be way cheaper in the future.

>>3515391
https://medium.com/@matthewdif/ethereum-payment-channel-in-50-lines-of-code-a94fad2704bc

this code example should give you an idea of how a basic state/payment channel would work. the idea is that, instead of committing each and every transaction to t he blockchain, two peers exchange signed hashes of transactions, with the 'last' one being sent the blockchain. the result is that it allows use cases like micropayments and other stuff that wouldnt be possible due to gas costs

>>3515407
>>3515413
I'm very interested in learning efficient smart contract / dApp development but there is an absolute wasteland of actual knowledge and guidance out there. Any advice or even nudges in the right direction are appreciated.

>>3515450
You'd probably want someone who has developed dApps already. I agree that the information out there is an absolute clusterfuck.

>>3515506
> You'd probably want someone who has developed dApps already

for all the hype, this is a very small population

like, pre web 1.0-tier

>>3515506
The problem is no one has developed dApps...

>>3515002

>doing your processing off blockchain
>like people have been doing for years now
>because computation is cheap as fuck because computers are cheap as fuck

Then what the fuck is the point?

>the eth devs will disprove the CAP theoreom

Yeah, no.

This is an interesting territory because I would like to develop dApps as well but now it's like, is this a /biz/ thread? and /g/ probably wouldn't know shit about eth programming, because it's too unexplored for the average person to have any amount of info on

I'd like to see more people start talking about the genuine use cases and functionality of eth rather than just the price and MOOOOOOOON and DIIIIIIIP discussion because this discussion will be what actually determines the real value of the service

>>3515532
https://dapps.ethercasts.com/

>>3515557
this

>>3515557
the processing is done in a peer to peer manner, and the whole point is that it enables transactions and use cases that would be too inefficient with the blockchain. speed and costs are the primary reason for using off-chain transactions. the blockchain is still used, just at the end of the "session"

>>3515557
>>3515608
payment channels/off-chain transactions are like bar tabs. instead of many transactions you wait to do them all at once. its not that hard to understand.

>>3515628
Doesn't that defeat the purpose of decentralization of you need an offchain server calculating tx groupings

>>3515615

Right, I understand. It's like using a UI layer that just finds out the final result of your computation and records it to the blockchain. That doesn't make it any more useful though unless you're already entangled into the eth platform because any blockchain relevancy for your business will probably be accomplishable with localized computer processing anyways.

My first thought for a dApp was "well, why not a simple point of sale software?" And then it occurred to me: one, running the interface would require a computer anyhow, which would be more than capable of processing whatever simple mathematics and database stuff necessary and cost you nothing. Unless somehow you managed to completely eliminate computer overhead by just running network compatible monitors and stream everything from the blockchain anyways, but that would cost way too much and be an unreasonable load on the network.

Basically I'm not sure exactly what tangible advantages the eth network has yet. Only thing I can think of now is maybe payroll, which requires less computation than it does accountability and record retention which may make it appropriate for the blockchain.

>>3515677
theres no "off-chain" server. the transactions are exchanged directly peer to peer, with the final "balance" being sent to the blockchain. in order for a tx to be valid for the blockchain, it has to be signed by both participants, and therefore agreed to.

>>3515677
read the article i sent you, it explains how it works pretty well. for the exchange of transactions between peers in a state channel, you'd use whisper (eth's p2p messaging protocol)

https://github.com/obscuren/whisper-payment-channel

>>3515725
thanks anon. I'll read through this stuff.

>>3515687
yeah, you only want to use the blockchain to record state. everything else can be and should be done on the local client. when you want changes to persist between sessions, then i'd record the data to the blockchain. everything else can be done locally or even p2p with signed transactions.

ITT: everyone should read this
>https://medium.com/@hackdomETH/on-chain-or-off-chain-1bef4238a3a0

very good article that should explain why and when you'd need to use a state/payment channel

>>3515738

As it is right now it's more like Etherium is a proof of concept that is being held up by ICOs because the smart contracts are the only actual functional use at the moment

>>3515738
without having read this stuff yet, can you trust what is done on the local client? Let's say for example that I run a dApp that uses the state of the blockchain to manage a high scores list. If scores aren't calculated using smart contracts to "play" the game and the game is "played" locally instead and the high score recorded, is that trustworthy?

>>3513868
FUD, dont sell its mooning.

Eth will reach 0.09 tonight.

>>3515832
Give a reason other than it's mooning. It had a slight bump up vs BTC. I want a reason to go long mate.

>>3515822
that depends entirely on the type of game. if its turn based or has some kind of 'sequential events' then i would say you could easily hash each 'turn' and when the game is over and you want to submit your score to the blockchain, your turns are hashed and submitted to a smart contract that checks if the signed tx is valid or not. this would require diving into cryptography but i would say its well worth it

>>3515951
That sounds like a good way to do it. Currently I'm working on a browser-based roguelike and I wanted to use it as a way of dipping my toes into smart contract development by keeping a running list of high scores and bodycounts by eth address on the blockchain. Not necessarily really a dApp, but at least smart contracts. Since a roguelike is turnbased that would be a good test.

But wouldn't all of that cost a lot of gas, especially if the game goes on for a large amount of time? I understand each turn's data being hashed would shrink it significantly, but still.

File: eerffwerfwerfwerfwerf.png (69KB, 579x588px) Image search: [Google]

69KB, 579x588px

>>3515898
Now don't fall for the FUD, who knows the price next week but for tonight its going green.