Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
It is expected behavior as the alert key was never changed from what is in litecoin. There are more coins that are going to see this as well I bet.Yep, a whole bunch of coins still use that key.
Yes, go ahead and use CCE Goldcoin Explorer address. I tell all coin users they can use CCE as an addnode and developers are more then welcome to use the CCE as a hard coded seed node.
The next step is a bit more complicated.
DNS seed nodes. DNS seed nodes keep DNS records of all the nodes it encounters through scanning the coins P2P network. When a client/daemon uses a dns seed node, it gets a DNS list of random address picked from the dns seed node records, normally 10 addresses.
These are kind of a pain to set up, DNS is always a pain in the arse...
At this time I cannot offer a dns seed for Goldcoin, as I am already working on a couple for other coins. I just wanted to make the community aware that this is the next step in building a full coin network.
When it won't sync, the block count comes from the node/peer with the larger chain. The count is not the same always, but its a handful of nodes. Not sure what your insinuating, but its not the LTC network trying to sync with GLD because he used the same pefix numbers and/or public/private signing keypair. the other networks connect via defined ports, which do not overlap with these.Submit code or a formula else FUD.
Still wrong.
Can you read code then? Go take a look at the code. Do a diff against litecoin. Now see what the block data shows when it will not sync. Now read the code where that block count comes from. You will see it. If you can't read the code, then stop calling for it.
I have ONLY the following lines on my client and it is working with no problems:
bantime=604800
addnode=207.12.89.2
addnode=72.14.178.111
addnode=208.115.109.157
addnode=88.161.131.83
maxconnections=4
Having said that, it obviously can't stay this way but with the base being small perhaps it should be this way for now. I believe these are the pool addresses and/or the addresses to the daemon run by the exchanges.
Hyoshi recommended getting at least 12 trusted nodes up and putting those in. Sounds like a good game plan to me to start with.
I can't say for certain though, but just because it WILL be a fully functional p2p system doesn't mean it MUST start that way and if we don't trust the pools or the exchanges as a beginning then what do we have?
It would be nice to have comments beside each addnode line saying who they are.
Only "connect" does this - not "addnode". With addnode, if a node goes down, another available node is used that's not trusted. No one runs the wallet with the firewall open so they have 100 connections - most people only use a max of 6 - 12 connections to peers.**addnode=72.11.149.185 DELETE THIS LINE ITS GONE
bantime=604800
addnode=207.12.89.2
addnode=72.14.178.111
addnode=208.115.109.157
addnode=88.161.131.83
maxconnections=4
Get rid of of all the other lines. Its not needed. Its not possible for it to go out of sync if those nodes and pools are legit (1 is mine, the others are pools)
If it does, backup wallet.dat, and gldcoin.conf, and delete all files withing %appdata%/roaming/gldcoin (this is the location you are using right?)
Now, what you need is more public trusted nodes, where people agree to keep their daemon running 24/7/365, and can forward/open port 8121 to the daemon, and have a static IP.
Ideally until the network grows you need a good 12 nodes, and you can then change maxconnections to 12.
I can confirm that so far this is stopped the client resync issue. I have had this running for about 2 hours and normally in this time the client would have tried to re-sync.
This will stop the resync issue, however it also makes it so your client only talks to the nodes you just put in your configuration file. This means the network is now rather limited and can not grow. It is also no longer really peer to peer and instead depends on a few nodes. With this configuration there is no need for this to be a blockchain based, p2p currency, it could just become a centrally controlled currency instead. This also will make testing the real fix harder and make it so you have to get people fix their configuration files when any of these nodes ever go down. Bad suggestion overall.
The problem is in appearances. Would it be possible to engineer a temporary workaround via a custom config file?Its always temporary... Until you have thousands of peers with only a handful being rogue. When there are only hundreds of peers, and a handful rogue, its likely you will always see this unless you use trusted nodes as above and limit the number of node connections.
