client/asset/eth: Use gwei in Balance. #1078
Conversation
JoeGruffins
force-pushed
the
gweibalances
branch
from
b02ea05
to
7f42416
Compare
| "istanbulBlock": 0, | ||
| "muirGlacierBlock": 0, | ||
| "berlinBlock": 0, |
There was a problem hiding this comment.
Should put us at the same.. fork as mainnet.
| "${NODES_ROOT}/harness-ctl/mine-beta" "1" | ||
| "${NODES_ROOT}/harness-ctl/mine-alpha" "1" | ||
| "${NODES_ROOT}/harness-ctl/mine-beta" "5" | ||
| "${NODES_ROOT}/harness-ctl/mine-beta" "15" |
There was a problem hiding this comment.
I had a few times where it looked like mining on alpha made transaction inclusion speed worse. Will attempt to solve the problem in a separate pr.
There was a problem hiding this comment.
Dang what a drag. Linking back to the original discussion and karalabe's comment in a different thread.
There was a problem hiding this comment.
Another related idea was to have the non-miners (clients) connected to each other or at least another non-miner (or not the primary miner): ethereum/go-ethereum#2822 (comment)
ivooz: The problem goes away when all the non-mining nodes are connected to each other, previously they only knew about miner nodes.
karalabe: ... your first topology were that all nodes were connected only to the miners. This can be problematic as the miners are heavily loaded churning out blocks, so if everyone is bugging them to distribute the data too, I can imagine that they are simply overwhelmed (you essentially DDOS the miners).
I'd recommend enabling discovery (with a custom bootnode, maybe one of the miners, should be fine) so nodes can properly connect to each other and form a decent overlay network to propagate the data.
There was a problem hiding this comment.
Oh and about the first idea of starting 2 miners, one guy said he "updated the file "static-nodes.json" accordingly". Know what we should do there? Specify enodes? Sounds like an alt was karalabe's other suggestion of enabling discovery with a custom bootnode.
There was a problem hiding this comment.
Will look into this directly after I get #1019 up to speed.
There was a problem hiding this comment.
Yeah, still scratching my head. These convos are from 2016, so maybe something different. Also, putting sleeps in the wrong places in the harness can just make everything fail. Which seems wierd.
There was a problem hiding this comment.
Pretty sure I found and fixed the problem in #1130 Calling miner.start() miner.stop() in quick succession seems to mess with the ability of txs to make it into blocks.
JoeGruffins
force-pushed
the
gweibalances
branch
2 times, most recently
from
744f5ff
to
32a85b2
Compare
|
It is 18 billion eth possible correct? |
The basic unit of eth is so small that only 18 eth worth of wei can be stored in a uint64. Deal with eth as gwei so that we are able to ensure that as much as 18 billion eth can be represented.
JoeGruffins
force-pushed
the
gweibalances
branch
from
32a85b2
to
887f147
Compare
You mean the ultimate supply? I thought it was uncapped, but with 18 million ETH per year, so with about 117 million currently existing, I'd say even 1 billion is a ton |
|
Oh no, I meant the amount of eth we can save in a uint64 as gwei. There is no eth max supply, and even if there were, they don't have a great track record of doing what that say. But 18 billion is still a far way off. |
|
Hah, ok! Yup |
Because it's mutatable, didn't think it was a great idea to export. Maybe a bad idea to have it as a package-level var in the first place? The big math isn't the easiest to reason about imo. It all takes a pointer, then it returns the value? Is it returning the same value, did it mutate the original value? Need to check the documentation every time to refresh my memory. Just seems safer to do that math locally every time, with a new What do you think? |
|
Sounds good to me. Just curious. I agree about the math/big API. |
closes #1076