core-geth/community

meowsbits

@meowsbits

beep boop

@chunfuyang

hello everybody

Christian Xu

@ChrisXK

Hi There！

Bob Summerwill

@bobsummerwill

Has anybody got a running Core-Geth (or Multi-Geth) archival node?
That is required for running the second 1884 impact analysis.

@meowsbits @shanejonas @BelfordZ @stevanlohja @tzdybal @zcstarr?

Yaz and I got booted off the ETC Labs Discord today so I cannot ask there.

Bob Summerwill

@bobsummerwill

Hey @stevanlohja,
It really depends what the guy needs.
He has something which ran against a Geth node for the ETH queries.
Which should just work against a Core-Geth archival node.

BigQuery might have enough data to logically support the same kind of analysis, but the interface would be completely different.

Hence easiest path is for anybody on the planet who is running an ETC *-Geth archival node (if there is anybody doing that!) to just run the existing script on their machine.

@meowsbits just replied on ETC Discord.

Bob Summerwill

@bobsummerwill

Greetings, everyone!

@stevanlohja WRT to the Archival node question above, Yaz ended up starting a Core-Geth archival node and that has caught up now, so we should be able to run the 1884 queries on that very soon.

Chris Hobcroft

@chrishobcroft

Hey all, I'm seeing a load of WARN when running geth -rinkeby -rpc -rpcapi eth,net,web3 --syncmode "light" on 1.9.13-stable

WARN [04-22|12:07:01.574] Served eth_getBlockByNumber              conn=127.0.0.1:55380 reqid=19 t=224.274µs err="no trusted canonical hash trie"
WARN [04-22|12:07:05.776] Served eth_getBlockByNumber              conn=127.0.0.1:55222 reqid=23 t=178.691µs err="no trusted canonical hash trie"
WARN [04-22|12:07:06.574] Served eth_getBlockByNumber              conn=127.0.0.1:55380 reqid=20 t=103.525µs err="no trusted canonical hash trie"
WARN [04-22|12:07:10.776] Served eth_getBlockByNumber              conn=127.0.0.1:55222 reqid=24 t=181.235µs err="no trusted canonical hash trie"
WARN [04-22|12:07:11.575] Served eth_getBlockByNumber              conn=127.0.0.1:55380 reqid=21 t=233.229µs err="no trusted canonical hash trie"

Transactions are still being published successfully, but can someone help me understand what this WARN means, and how I eliminate it?

Vie

@VieYang

How etc fork at block 10,500,839, the config in https://github.com/etclabscore/core-geth/blob/v1.11.9/params/config.go is all eth?

Vie

@VieYang

With flag " --classic", thanks.

bitcodernull

@bitcodernull

i change my node from openeth to core-geth, i need to resync the all blockchain data, it is too slow
where can i download a snapshot for geth,

Yoni Moses

@yonimo

Hi, we're also trying to transition from OpenEthereum to CoreGeth, but it runs out of RAM (32GB) and crashes before it finishes syncing.
I think it happens around the time the sync reaches last Saturday's massive chain reorg.

Josh

@Jlonghi

Any fix for this? I am also unable to sync

Kieran

@kobrien2_gitlab

Hi I am setting up a full archive node just wondering does this include full traces or is there an extra command line arg for enabling this? Thanks!

Kieran

@kobrien2_gitlab

similar to parity's '--tracing=on' flag

@pbt39ppc

nevermind. too quiet here...

Dani Gorbaciov

@danigorbaciov

btclinux

@btclinux

Hello! Is it possible to include own out transactions to next block will be mined on my node?

I want to save money on fees from pool payouts

Like big pools do

sankararaokgmail

@sankararaokgmail

Hi Team, I have started my ETC node using below command sudo docker run -d --name core-geth2 -v /node-etc-geth/data:/root -p 9545:9545 -p 30303:30303 etclabscore/core-geth --classic --http --http.port 9545 --http.addr 0.0.0.0
But when i tried to check the status of it i am getting '0x0' as response.
from logs i can see node is synching and has active peers
curl -X POST -H 'content-type:application/json' --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' http://localhost:9545
please help me hear

gal432

@gal432

Hello. I'm trying to sync my new ETC node to the chain.
I'm using the version etclabscore/core-geth:version-1.11.15 with the following parameters:

geth --maxpeers 100 --http --http.addr 0.0.0.0 --http.port 8345 --http.corsdomain * --http.vhosts * --http.api debug,web3,eth,txpool,personal,net --syncmode full --datadir /data --cache 4096 --classic

In the beginning the sync was really fast and we closed 4 years of the network with less then 24h.
But now it takes a ~12h to complete the sync of 2m.

Right now I'm on block number 8886899 with age of 1y2w2d.
What can I do to improve the sync? I tried to increase the cache (from 2K to 4K) and It seems like it didn't help much, and it doesn't sounds me right to wait two weeks to let the node to finish the sync.

gal432

@gal432

ninonomad

@ninonomad

Any news for Nov?

Mario

@mmaryo

Hello
I'm looking for run a local node and get pending transactions
Since 1 day runing, no pending transactions appear

> txpool.status
{
  pending: 0,
  queued: 0
}

And I use this command line (last version of geth)

geth --datadir=~/dev/chain --syncmode fast --cache 6144 --rpc --rpcaddr '0.0.0.0' --rpcapi=eth,net,rpc,web3,txpool,personal,debug --txpool.globalslots=250000 --txpool.globalqueue=500000 console

Is the command line wrong ? Or need more time to synchronize blockchain ?

Bravo

@belmix

{"jsonrpc":"2.0","method":"eth_submitWork","params":["0xf03655db16c8ea1b","0xde2425167ae9baa2f49dc60347c48f3b6a230c392b17cdc5ca12d4f45451488f","0xe518bea8cdc1733487e9c647d5e79c239f59385af033e1cc2c0add556571c23e"],"id":"1605541498"}

is this a valid block confirmation request structure?

Bravo

@belmix

{"jsonrpc":"2.0","method":"eth_submitWork","params":["1","2","3"],"id":"1"}

Bravo

@belmix

https://blockexplorer.one/etc/mordor/blockId/2532012

is this a valid testnet explorer?

bhartiaditya

@bhartiaditya

Hello,
I'm getting the Error: Contract not deployed after cloning private geth network from one server to another.
Steps to reproduce:

Private geth network is running on server1.

Deploy contract using truffle and make a few transactions.

Stop geth n/w of server1 and copy its entire directory (accounts.txt, boot.key, genesis.json, node's password.txt along with its directories keystore and geth) and paste to server2

Change in the geth configuration --rpcaddr 'xx.xx.xx.xx' with private IP of the server2.

Bring up this geth network clone of server1 on server2 (it is able to successfully seal new block, mine potential block, and commit new mining work)

Interact with contract on server2.

Error: contract not deployed

Restart the stopped geth n/w server1 (it is able to successfully seal new block, mine potential block, and commit new mining work)

Interact with contract on server1.

Error: contract not deployed
Expectation:
Restarting the geth n/w on server1 should not cause any data loss.
Should be able to interact (get the transactions performed on server1 as the data should be present in chaindata) with the contract on server2.

Note: I was able to migrate a test geth n/w successfully for a n/w running from past 2 days. After this successful operation, I was migrating this geth n/w which was running from past 7 months which is failing now with error contract not deployed. Will it sync/heal itself if its up for a long time? What are the correct ways to restart and migrate the n/w with huge chaindata. Any documentation would be much appreciated.

Thanks

Where communities thrive

People

Repo info

Activity