What's the problem exactly?
You can try on different investment tools. Bitcoin was not given importance to the first time, remember the times when the pizza was bought for 18000 btc. Pinetwork is an open front application because it has different features from other coins. The engraving process continues in the application. You do not give anything. Just press the green lightning icon once a day from your phone. Even if your phone is closed, scraping continues. If you want to try Pinetwork, which is a new breath in digital mining, you can access it from play stor. write "vetuka" there and complete the process
As from my analysis seems like related to "chainreorg" that happens next to this. I am just mentioning because I never seen this errors in past, but maybe the new geth started verboseing this errors just in the recent versions.
@karalabe any news on that front?
Hi, is there anyone that could answer this question? https://ethereum.stackexchange.com/questions/82184/geth-trace-transaction-int-old-block
I have a GIT issue open on this, but it's been a while since I've heard anything back - ethereum/go-ethereum#20963
Can some please have a look on ethereum/go-ethereum#21151
is the TOML parser broken for geth?
I am getting this error:(p2p.Config.BootstrapNodes) invalid public key (wrong length, want 128 hex chars)
WIth this line in the TOML file:BootstrapNodes = ["enode://de2bff7934321b702bd9b657874ba7095b93a54cb4007049c100bf430d3026ea@172.0.254.129:30303"].
The enode is generated using the -writeaddress flag of the bootnode binary utility
Hi. I am trying to understand why after running for a while my geth node seems to lose sync for apparently no reason.
Looking at my logs, I have:
Jun 03 10:36:20 Ubuntu-1910-eoan-64-minimal geth[429]: INFO [06-03|10:36:20.961] Imported new chain segment blocks=1 txs=240 mgas=9.979 elapsed=1.503s mgasps=6.638 number=10191803 hash=66452f…0fe9d0 dirty=859.69MiB
Jun 03 10:36:46 Ubuntu-1910-eoan-64-minimal geth[429]: INFO [06-03|10:36:46.018] Deep froze chain segment blocks=4 elapsed=366.459ms number=10101802 hash=007a05…97e3b9
Jun 03 10:37:46 Ubuntu-1910-eoan-64-minimal geth[429]: INFO [06-03|10:37:46.321] Deep froze chain segment blocks=1 elapsed=302.524ms number=10101803 hash=3cc00c…c5582d
Jun 03 11:04:55 Ubuntu-1910-eoan-64-minimal geth[429]: INFO [06-03|11:04:55.833] Regenerated local transaction journal transactions=0 accounts=0
Jun 03 12:04:55 Ubuntu-1910-eoan-64-minimal geth[429]: INFO [06-03|12:04:55.828] Regenerated local transaction journal transactions=0 accounts=0
Jun 03 13:04:55 Ubuntu-1910-eoan-64-minimal geth[429]: INFO [06-03|13:04:55.829] Regenerated local transaction journal transactions=0 accounts=0
Jun 03 14:04:55 Ubuntu-1910-eoan-64-minimal geth[429]: INFO [06-03|14:04:55.844] Regenerated local transaction journal transactions=0 accounts=0
My config.toml:
[Eth]
SyncMode = "fast"
[Node]
DataDir = "/storage/geth/mainnet"
HTTPHost = "127.0.0.1"
HTTPPort = 8545
HTTPVirtualHosts = ["*"]
WSHost = "127.0.0.1"
WSPort = 8546
WSOrigins = ["*"]
NoUSB = true
[Node.P2P]
ListenAddr = ":30303"
If it losing sync is due to a lack of peers, is there any option to make geth crash if it doesn't have a minimum amount of peer nodes? For me crashing should be fine as it is managed by systemd, all I am looking for at the moment is an automatic way of getting it to restart if it loses sync for too long
Also I try to send a transaction and geth just crashes..
INFO [06-04|09:32:46.460] Submitted transaction fullhash=0xdfe75491684404d097876c7092cf5ff7599fe344ea73015449b7135441188637 recipient=0xA84199E5d1E718C7c6a389f8d0fa21691be9B5bD
WARN [06-04|09:32:47.584] Gas estimation capped by limited funds original=9959364 balance=11000000000000000 sent=1000000000000000 gasprice=31000000000 fundable=322580
Killed
@pauljeremyturner have a look at this: https://github.com/MariusVanDerWijden/go-snippets/tree/master/geth-test
Hey, so without trying to re-open the can of worms that is theethereum/go-ethereum#1897, is there already a established practice/recommendation for someone that would like to obtain a list of all ETH transfers involving a given address?
(that does not involve running through the whole chain, of course)
The Diamond Standard is hot on Reddit right now: https://www.reddit.com/r/ethereum/comments/gze6k3/a_diamond_is_a_set_of_contracts_that_can_access/
@lullis - Nope. On a normal node, that information is not indexed in a way that you can get to it without scanning every transaction on the blockchain. Recently Geth introduced the option to not index transaction hashes (indexes which tell Geth how to find the tx based on its hash). Removing that index saves about 32 GB. Adding an index of all transactions by sender and recipient would probably take around 64 GB to store.
@tjayrush , thanks for the tip, but if I understand correctly it just sort of punts the issue to etherscan? From reading the docs, quickblocks/trueblocks is a tool that is a database that you can run locally connected to an ETH node, and enriches the data it gets from that node. But their docs mention usage of a tool called ethslurp that requires etherscan APIs.
For my case, I am just working on some wallet-like transaction record system, and I know that I can get the events for transfers using the ERC20 token contracts. I am just missing the ETH transfers. If I have to resort to anything that is third-party and/or relies on Etherscan, than I can just go to etherscan directly.
I can't find anything online on eth://
Are there any tuning guides for making the best use of RAM? I want to optimize for JSONRPC
eth_call query throughput and latency, where the queries typically hit a lot of DeFi contract logic. I have a 64-bit Linux box with 32 GB of RAM. Using geth 1.9.15, my config.toml has DatabaseCache = 24000, but the geth process never uses more than ~ 13 GB virtual / ~ 10 GB resident RAM even after a week of traffic. Shouldn't I expect something around 24 GB usage? Are there other settings I should tweak?
Also, is there a config option that controls how often to write cached state to disk? I don't see anything in the docs. Normally, sending the INT signal to geth causes it to shutdown gracefully, logging that it is "Writing cached state to disk" and has "Persisted trie from memory database". However, the last time I did this, geth began the shutdown process but then hung for 10+ minutes without any log messages. Upon killing and restarting, geth reported "Head state missing, repairing chain", was 14,000 blocks behind, and took over an hour to recover. Is there any way to cause geth to persist this crucial data more often? (Using v1.9.15.)