Greetings. I would like to learn how to code in Ethereum. I currently code in 10 programing languages or more. Where do I start to learn the Ethereum programming language?
@RaManAli there are links to
token tutorials from the website.
@makoto How long does it usually take to mine some ether (small quantity enough to test simple contract) on test.net? I tried for a while but still showed up as zero :(
Testnet mining should be fairly quick.
You should get several ether in about 5–10 minutes
thanks @pjdelport maybe its because my machine is low performance (memory, hard disk) or internet slow? I did try for intervals of 30 minutes, but did not see anything.
How are you mining? With geth?
Does it show any mining output?
yes, i think so
not sure, I will try again later and verify
Can you pastebin it somewhere, along with the command you use to invoke it?
And just to check the obvious, do you have a coinbase account set?
not right now, but I can do later. Currently syncing with the main.net (taking a long time)
What hardware do you have, by the way?
yes, I have one main wallet account set up for test.net and an additional account set up for additional transfers
Hardware: Storage 500 GB HDD disk, Memory 4GB, Processor 2.5 GHZ Intel Core i5, Macbook pro
@pjdelport to answer your earlier question, while on test.net before via the MIST wallet interface, I just selected the mining option in window. I think it is on geth (not the C++ option). I waited for over 30 minutes, and nothing happened (the main account on test.net showed no sign of incrementing with ether), and I did not see any mining output
@pinecrest515: That should be plenty for Testnet mining.
Does your CPU usage go up?
I'm not really sure how to debug the wallet interface's mining.
@pjdelport thanks, good to know! I will try again when I get done with main.net syncing (taking a very long time! I am at block 1153000).
Try closing the wallet completely, and then running
geth --testnet?
If that's synced, try running
geth --testnet --mine
ok, I will do after the syncing (don't want to run two console windows for geth at the same time)
In a separate console window, you should be able to say
geth attach, and then for example:> eth.mining
true
> miner.hashrate
885210
hmmm
You can query your balance with
web3.fromWei(eth.getBalance(eth.coinbase))
I am currently downloading and syncing from main.net via geth....would you recommend that I run simulataneous mining on testnet? Any potential issues with memory?
@pjdelport To conserve memory I exited the ongoing main.net sychronization on geth and put in the geth --testnet --mine on a new console window, looks like it is going
I0425 18:07:10.419431 1345 miner.go:119] Starting mining operation (CPU=4 TOT=4)
I0425 18:07:10.461383 1345 ipc.go:112] IPC service started (/Users/Work/Library/Ethereum/geth.ipc)
I0425 18:07:10.956101 1345 worker.go:569] commit new work on block 801121 with 0 txs & 0 uncles. Took 536.624237ms
I0425 18:07:11.827856 1345 ethash.go:237] Done generating DAG for epoch 27, it took 1.408645264s
I0425 18:07:12.000892 1345 ethash.go:220] Generating DAG for epoch 26 (size 1291844992) (b15bb3623092c525165d45efa2d08540708d90d033aaa9fe4be8fd16ff904df0)
I0425 18:07:13.405428 1345 ethash.go:237] Done generating DAG for epoch 26, it took 1.404624657s
I0425 18:07:10.461383 1345 ipc.go:112] IPC service started (/Users/Work/Library/Ethereum/geth.ipc)
I0425 18:07:10.956101 1345 worker.go:569] commit new work on block 801121 with 0 txs & 0 uncles. Took 536.624237ms
I0425 18:07:11.827856 1345 ethash.go:237] Done generating DAG for epoch 27, it took 1.408645264s
I0425 18:07:12.000892 1345 ethash.go:220] Generating DAG for epoch 26 (size 1291844992) (b15bb3623092c525165d45efa2d08540708d90d033aaa9fe4be8fd16ff904df0)
I0425 18:07:13.405428 1345 ethash.go:237] Done generating DAG for epoch 26, it took 1.404624657s
That looks good so far.
You should see something like this in a couple of minutes:
I0425 12:18:30.510606 7634 worker.go:348] 🔨 Mined block (#818956 / 569708c0). Wait 5 blocks for confirmation
...
I0425 12:19:13.502412 7634 worker.go:447] 🔨 🔗 Mined 5 blocks back: block #818956
You won't always see the second message; sometimes the block you mined will be beaten by a faster chain.
thanks, unfortunately the operation stopped, saying Synchronisation failed: no peers to keep download active
I get this a lot and have to re-start geth
(But you might get an ommer / uncle block reward.)
Ah, that sounds like you have network connectivity problems.
haha I'll take anything, an emmer is an ommer
in theory my internet is not that bad, 3-4 mbps, but yeah, not the most ideal here
It should not be bandwidth-limited.
Does your ISP perhaps deprioritize certain traffic?
Or are you getting packet loss?
not sure
For Ethereum, you want network stability and reliability rather than throughput.
got it, thanks, good to know
yeah, I don't think my network stability ranks as top 30%
What is the metric/barometer cutoff that's needed as a measure of network stability for ethereum? I am in a co-working space in Chiang Mai, Thailand. It's not top 30% in terms of stability, but I don't think it's that bad neither.
It could be many things.
Try something like "mtr 8.8.8.8", or another random address; do you see any packet loss?
let me run a ping test
How stable are for example Bittorrent downloads for you, as a test?
I have not tried bittorrent downloads with my current network, was going to try that out with downloading the new episode of Game of Thrones :)
@pinecrest515 there is a site which gives you testnet ether for free https://medium.com/@makoto_inoue/ether-2-give-me-testnet-ether-for-freeeee-8e3b02771d0b#.ihng83vn0
looks like it is mining now on test.net after some time syncing the blocks
I was trying http://testping.net but needed to run a java update...but didn't want to do it now as there are too many applications running (memory low)
question: how does geth know which account to award the test ether to for the mining? I assume that the main coinbase wallet account has an identifier to either ip address or some other network identifier?
ah ok, I assume the main coinbase wallet account is associated with the node, so when mining geth knows where to assign and award the test ether
@makoto thanks for the tip!
I've been mining on test.net for a while, it keeps on committing new work and importing blocks, with no indication of mining completion in sight...is this normal?
sorry for asking so many newbie questions...learning by doing, testing, experimenting, f**king up, and re-trying
@pinecrest515: The coinbase account gets the mining reward, yes. It can be any account; it doesn't have to be associated with the node.
@pinecrest515 Have you seen log messages like those examples I pasted?
I did not see a line so far similar to the log message in the example you pointed out
You can look for that hammer icon.
This is the only thing I see: I0425 19:04:04.530410 1420 worker.go:569] commit new work on block 819442 with 0 txs & 0 uncles. Took 1.560650808s
I0425 19:04:04.531454 1420 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 1.556645544s. #819442 [8772ab31 / 8772ab31]
I0425 19:04:04.531454 1420 blockchain.go:1251] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 1.556645544s. #819442 [8772ab31 / 8772ab31]
it keeps on repeating this for different blocks
Give it some time; it may take a couple of minutes to mine a block.
It does look like it's mining though.
ok
@pinecrest515: Did you check those variables in a geth console?
eth.mining and miner.hashrate
I will open another console
Yeah, just open another console and
geth attach
Those should be true and non-zero, respectively.
I have to specify that it is testnet right, as in geth testnet?
You shouldn't need it for the attach
It will just connect to the running geth instance
you are correct sir!
eth.mining
true
miner.hashrate
0
actually, the miner.hashrate is zero
Hmm
It shouldn't be zero.
Is
eth.syncing false?
also: > web3.fromWei(eth.getBalance(eth.coinbase))
4
4
I get 4 for running this function
let me check eh.syncing.
Ah, so there's something. Did you use that faucet?
Otherwise, it might have mined something in the mean time. :)
eth.syncing is fales
Okay, that's good. Check
miner.hashrate again? Does it stay zero, or was that just a spike?
ah yes, I did use the faucet that @makoto pointed out
miner.hashrate is still zero
What's your CPU usage like?
Are there any errors in the log?
CPU 89% idle
Did you start the geth node with
--mine ?
no errors in the log, it just keeps repeating commit work and import
What does
top display? Does it show geth using CPU?
I started with geth --testnet --mine
It had to go back and sync some blocks before initiating the mining operation. Mining operation stopped for syncing, after sync it started, but is stuck on repeated commit work and import block
It had to go back and sync some blocks before initiating the mining operation. Mining operation stopped for syncing, after sync it started, but is stuck on repeated commit work and import block
Yes, it shows geth using 4.3% CPU
That should be fine. You should see occasional mined blocks, though.
Okay, then it must not actually be mining.
It should be using at least 1 CPU, or more, depending on how many threads you run.
yeah, it just keeps on committing new work and importing block, no additional new log messages
hmmmmm
Hmm. Maybe this could be network connectivity, and you're not getting new pending blocks in to actually mine?
What's your
net.peerCount?
wait, got something, hash rate no longer zero
miner.hashrate
15
net.peerCount
3
miner.hashrate back to zero
net.peerCount
3
miner.hashrate
0
net.peerCount
4
@pinecrest515: My guess from the other problems you're having with slow syncing is that there's some network connection stability problems.
Syncing should generally be pretty fast, too.
hmmmmm
yeah in theory it should be
And if you can't sync to get pending blocks, there's nothing for you to mine.
I've tried different internet connections, same thing where after some time sync stops
You can try looking at
admin.peers
Try pinging or tracerouting to those remote addresses.
I would highly recommend using a tool like
mtr if you can.
That will show you where along the path the connection gets bad, if it does.
Apparently you can get mtr for Mac OS X here? http://rudix.org/packages/mtr.html
thanks!
(I'm no OS X expert, though)
@pinecrest515: The good news is your mining does appear to be working after all. It should only go idle like that when there's no incoming work, though.
@pjdelport thanks, yeah that's good. I don't know why it is not accepting or starting to mine. It was able to sync the rest of the test.net blocks.
Right, but from the sound of it, it was doing that more slowly than it should.
way more slowly
could it be an issue with the mac's network setting?
default network setting?
For comparison, over here, a couple of days of backlog only takes about 2 minutes to sync.
because I have tried a couple of different internet connections
yeah this is not normal
(Both Mainnet and Testnet)
I can't help you with the Mac side of things, I'm afraid. :)
Ubuntu here.
thanks anyways, you've been very supportive :)
@pinecrest515: Definitely try
mtr, and see if it shows packet loss. Intermittent packet loss can easily cripple your connection stability.
If you're on Wi-Fi, bad reception can be a culprit.
possible, but I've tried multiple different internet connections
All over Wi-Fi?
Or how are you connecting?
I tried two different wifi connections and 1 connect via cellular wifi hotspot
Oh, are these private hotspots, or public?
I have not used a LAN line - is that the problem?
Public hotspots are very likely highly shaped, and will probably interfere with Ethereum's networking.
No, private. 1 wifi at a co-working space, 1 wifi at my apartment, and 1 cellular wifi from my phone, which in theory has very connect mobile internet
Mobile data connectivity might work, but it might also be shaped, or not quite be as stable as a wired connection.
Ah.
Those should probably be good, then.
Can't say much more without some network traces, though.
ok I am running mgr, can share some numbers
wow, the hostspot at the co-working where I am at, the packet loss% is 98.4%
That would explain it. xD
That should be close to 0%
Anything consistently higher than 1% is pretty bad.
5% to 10% should be about the highest you can go for a connection to be usable.
hmmmmm
mtr lets you see what hop that the packet loss starts at: if it's lossy from the very first hop, then it's probably your Wi-Fi reception.
You may need to move around to get better signal. The coworking Wi-Fi may be too crowded.
there is a list of 15 different hosts
do you mean start looking from the first host on the list?
Oh boy. Sounds like a very congested spectrum.
Oh, wait, nevermind.
In mtr, yeah, which host does the packet loss start at?
The packet loss and latency will generally increase as you go down the list.
Each entry is a host on the path.
As of right now, most recent list, the #1 host on the list has around 50% packet loss %
You can press
d to cycle between mtr's display modes, by the way.
Ah, then it's the Wi-Fi reception, yes.
If you have access to a LAN cable, definitely try that.
It should give you a stable connection.
of the list of 15 hotspots, only 2-3 have loss % less than 1%
3 have loss % over 40-50%
ok, I will check with a lan line
@pjdelport thanks again for the support, really appreciate it! :)
this ethereum syncing process has been frustrating in terms of the slow downloads, been at it for days figuring out why it's so slow
@pinecrest515: The second display mode of mtr is very useful, by the way.
It lets you see in real time how the connectivity improves or goes bad, when you're moving around with bad Wi-Fi reception.
ok, on the second display mode, a few of the hosts have red ?s
It's okay if one or two hops consistently don't respond, if all the ones around them do: that just means they're configured not to.
If there are random scattered
?s then it's just a product of Wi-Fi packet loss, yeah.
(If you want to paste a link to a screenshot of a full mtr display I could maybe make a closer diagnosis.)
3 of the 15 hosts on the list have consistent ?s in the entire row
here is link to dropbox folder with uploaded screenshots of mgr: https://www.dropbox.com/sh/fhptdtmdtly4dg0/AAD8CDVLAFTP00rSelMMuQW_a?dl=0
Okay, that' s a slightly unusual trace.
Those nodes with the high loss percentages may have been experiencing problems earlier?
The second screenshot looks good.
That's usually what you want to be looking at. :)
The non-responsive hosts (with all
?s) are fine if the ones after them are fine.
by 2nd do you mean the screenshot with the ? marks?
ah ok
Right.
Some hops are configured not to respond to ICMP messages, but still forward traffic; they show up like that.
The high percentages on the first graph are strange, though; it looks like you may have had connectivity problems earlier, but it's better now?
got it, so the first one with the packet loss % is odd then
You might want to press
r to reset the statistics.
hmmm...after resetting, the first host is at 100% packet loss, every other subsequent one on the list is at 0%
weird
one the good news side, miner.hashrate is now appearing to be non-zero
miner.hashrate
30
miner.hashrate
20
miner.hashrate
40
Cool. That's still very low, though.
what would be a normal miner.hashrate?
Mine hovers around 900,000
ohhh wow
This is on an i5-5200U CPU @ 2.20GHz
In the LiquidDemocracy contract, appointee is spelled apointee. If changed, will this have an effect on the program?
@pjdelport I am going back to my apt to check if I can connect to a LAN line
thanks again for all the help, appreciate it!
Cool :)
...also "newApointee"
Disapointeeng
@pjdelport I tested with a landline connection back at the apartment, but disappointingly still have the same issues with miner.hashrate = 0. This time with 0% packet loss across the board on mgr.
Odd. And your CPU is still idle?
93% idle :(
Do you have an international VPN or something to try, in case it's some kind of traffic shaping?
yeah, I will test next with an international VPN with ip in the USA
(I don't suspect that strongly, but you never know.)
small possiblity, but possible as Thailand where I am currently at is ruled by a military junta
testing with a vpn connection to USA...
Do you restart
geth after each network change, just in case?
yes, I terminated geth after each network change and restarted the console
result of testing with vpn: same issue, miner.hashrate still equal zero. The vpn connection host does have a 1.2% packet loss rate on mtr.
after each network change, I terminate and close the console window, restart the console, and type in geth --testnet --mine again
Oh well.
very baffling....
At this point you should probably try increasing the verbosity.
Someone more familiar with geth internals might be able to help troubleshoot where it's going wrong.
You might want to try https://gitter.im/ethereum/go-ethereum for that.
could it be a result of a bad timer that's not synced? I am auto synced currently with the apple apple.timer.com
I don't think your clock has to be super-precise.
It must be reasonably synchronised, at least.
Yup, I checked with Jeffrey on go-ethereum on a similar issue with slow sync on main.net. Two hypothesis: 1) Bad internet network and 2) my mac using a HDD hard disk instead of SDD
But it doesn't have to be sub-millisecond or anything.
Is your hard-drive saturated while syncing?
ok got it, then it should be in theory ok as my mac auto adjusts to apple.timer.com
how to measure hard drive saturation?
I don't know about OS X :)
I just have a little indicator on the top right.
ah ok
Some kind of thing that displays your CPU and disk utilisation in real-time would be useful probably.
I've been googling and there appears to be other instances where mac users experienced sync failed notices...could it be because MIST wallet and geth are not optimized for mac?
It could be something related to OS X's networking stack, I don't know.
hmmmm
I doubt it's platform optimisation related.
is there another possible explanation that has not been explored?
Not that I can think of.
well, anyways, @pjdelport you've been very helpful and supportive, I really appreciate it! :) I am going to bang my head for a while....quite baffling.
I hope you get it sorted out. :)
Try bumping the verbosity levels and see you if you can spot anything that looks out of place.
Ok! I also posted a similar question again on go-ethereum slack channel to see if there are any mac users out there
Actually, I am going to also attempt to download bitterness for Game of Thrones episode 1 tonight, to see if that gives any pointers on the issue :)
bittorrent *typo