Slimcoin | First Proof of Burn currency | Decentralized Web

[johnwhitestar]

I am actually using : v0.6.0.0-g8e9fe2c-alpha

K.

Seems like cryptoId version of blockchain is far ahead.

Interesting that their 2364xxx total blocks doesn't show up for any of my node's peers:

Code:

"addr" : "185.150.190.19:41682",    "height" : 2362598,
"addr" : "185.68.67.37:41682",      "height" : 2363859,
"addr" : "178.223.55.155:53184",    "height" : 2363828,
"addr" : "178.223.55.155:56231",    "height" : 2363843,
"addr" : "5.39.70.87:33984",        "height" : 2362598,
"addr" : "185.79.5.221:53014",      "height" : 2363717,
"addr" : "145.239.189.106:53042",   "height" : 2363845,
"addr" : "178.221.183.154:9715",    "height" : 2363767,
"addr" : "212.125.247.58:49560",    "height" : 2363719,
"addr" : "178.221.183.154:9964",    "height" : 2363720,
"addr" : "46.0.192.98:60366",       "height" : 2362598,
"addr" : "178.223.55.155:64890",    "height" : 2363689,
"addr" : "178.223.55.155:64902",    "height" : 2363689,
"addr" : "94.25.174.181:39989",     "height" : 2363729,
"addr" : "91.250.62.26:57117",      "height" : 2328476,
"addr" : "18.191.168.158:61845",    "height" : 2287922,
"addr" : "144.76.64.49:37520",      "height" : 2361253,
"addr" : "109.10.108.52:56155",     "height" : 1340151,

I've noticed it as well. That's why I thought the right chain should be something around 2363689.

@keliokan I've asked Freiexchange to have a look what is their situation, they told me they'll restart their server to see whether you'll be able send funds there.

What version are you using?  What if you begin from a snapshot again and directly connect your wallet to some of the servers mentioned above?

Have you seen this edit of my previous post?

 
"Maybe you can add the following ones as well:

Code:

addnode=185.150.190.19
addnode=178.223.55.155:53184
addnode=185.79.5.221:53014
addnode=145.239.189.106:53042
addnode=178.221.183.154:9715
addnode=46.0.192.98:60366
addnode=94.25.174.181:39989

They are all up to date, but the majority of them are not on the standard ports, that's why maybe we have issues to connect to them.
Don't know whether it's the right thing to add the port in the slimcoin.conf specifically.

I'm restarting my server with this new addnode lines to see whether it will sync. (The local wallet hasn't started yet)."

[Doorfinance]

Esta interesante la moneda alguien sabe como puedo publicar mi hilo en la plataforma para mí proyecto ?

[johnwhitestar]

Esta interesante la moneda alguien sabe como puedo publicar mi hilo en la plataforma para mí proyecto ?

No hablo mui bien espanol, qué hilo, qué plataforma?



Edit @keliokan I need to leave now, will be back later. Let's go on trying to solve this issue. I hope we'll be able to. I'm with you.

[psycodad]

...
 
"Maybe you can add the following ones as well:

Code:

addnode=185.150.190.19
addnode=178.223.55.155:53184
addnode=185.79.5.221:53014
addnode=145.239.189.106:53042
addnode=178.221.183.154:9715
addnode=46.0.192.98:60366
addnode=94.25.174.181:39989

They are all up to date, but the majority of them are not on the standard ports, that's why maybe we have issues to connect to them.
Don't know whether it's the right thing to add the port in the slimcoin.conf specifically.

I'm restarting my server with this new addnode lines to see whether it will sync. (The local wallet hasn't started yet)."

Generally spoken, connections on non-standard ports are (in 99.9% cases) incoming to the respective node, most often these are wallets behind firewalls or with listen=0 that do not allow incoming connections and you see the port they are connecting from.

When compiling nodes lists, one should IMHO filter to those with "inbound": false, as these are definitely listening nodes to which your node connected. That is not to say all others are not listening, but only from those to which your node connected you can be sure of it.

Also knowing one connected listening node is generally enough as it informs your node about all the other nodes it knows about.

From the 8 nodes my node is connected to, only one is inound: false, all others are incoming connections. I guess there are just not so much listening nodes around right now.

[johnwhitestar]

...
 
"Maybe you can add the following ones as well:

Code:

addnode=185.150.190.19
addnode=178.223.55.155:53184
addnode=185.79.5.221:53014
addnode=145.239.189.106:53042
addnode=178.221.183.154:9715
addnode=46.0.192.98:60366
addnode=94.25.174.181:39989

They are all up to date, but the majority of them are not on the standard ports, that's why maybe we have issues to connect to them.
Don't know whether it's the right thing to add the port in the slimcoin.conf specifically.

I'm restarting my server with this new addnode lines to see whether it will sync. (The local wallet hasn't started yet)."

Generally spoken, connections on non-standard ports are (in 99.9% cases) incoming to the respective node, most often these are wallets behind firewalls or with listen=0 that do not allow incoming connections and you see the port they are connecting from.

When compiling nodes lists, one should IMHO filter to those with "inbound": false, as these are definitely listening nodes to which your node connected. That is not to say all others are not listening, but only from those to which your node connected you can be sure of it.

Also knowing one connected listening node is generally enough as it informs your node about all the other nodes it knows about.

From the 8 nodes my node is connected to, only one is inound: false, all others are incoming connections. I guess there are just not so much listening nodes around right now.

Thank you for the info, I haven't thought that not all the nodes allow inbound connections.

@keliokan, then only the first line of the additional ones counts.

We'll need to setup more servers, to see whether the issues will go away in that manner.

[gjhiggins]

They are all up to date, but the majority of them are not on the standard ports, that's why maybe we have issues to connect to them.
Don't know whether it's the right thing to add the port in the slimcoin.conf specifically.

Those with standard ports are listening nodes which will show up when you add the node, otherwise adding the node makes no difference to the getpeerinfo result (that's also how you can tell). This is because if a node is configured to listen on a port different from the standard 41682, you have to add the ip address and the port in order for your client to treat it as a potential listening node (and potentially sync from it). Otherwise, only nodes listening on the standard port are checked by the clients for being listening nodes and those that aren't specified as such (via addnode) are assigned an arbitrary port.

F'rinstance, the IP address (144.76.64.49) of my old (should have been decommissioned months ago) Hetzner host is listed in the strDNSSeed array, the list of supposedly-stable peers that a fresh node consults first when syncing from zero. However, I'd turned off the Slimcoin node because I'm working towards decommissioning the host. In the interests of stabilising the network, I reinstalled the Slimcoin node and synced up to date from a few-days-ago chain snapshot "ip" : "144.76.64.49" "blocks" : 2362979 with the (additional to the hardcoded strDNSSeed nodes) addnode=185.150.190.19:41682 and addnode=185.68.67.37:41682.

My client on the new server (144.76.118.44) sees the newly-started client on the old server as "inbound: true" and has assigned it a random port because I haven't told it otherwise (via addnode)

Code:

    {
        "addr" : "144.76.64.49:37520",
        "services" : "00000001",
        "lastsend" : 1614350096,
        "lastrecv" : 1614350096,
        "conntime" : 1614346618,
        "version" : 60003,
        "subver" : "/Satoshi:0.6.6/SLIMCoin:0.6.0(SLMv0.5.0-253-gdffb8f2-dirty-alpha)/",
        "inbound" : true,
        "releasetime" : 0,
        "height" : 2361253,
        "banscore" : 0
    },

Also note that the blocks field of getpeerinfo is incorrect and unreliable , it reported the block height incorrectly as 2361253 and not 2362979.

I then logged on to the new server and executed addnode 144.76.64.49, then getpeerinfo with the result:

Code:

    {
        "addr" : "144.76.64.49:41682",
        "services" : "00000001",
        "lastsend" : 1614350497,
        "lastrecv" : 1614350498,
        "conntime" : 1614350497,
        "version" : 60003,
        "subver" : "/Satoshi:0.6.6/SLIMCoin:0.6.0(SLMv0.5.0-253-gdffb8f2-dirty-alpha)/",
        "inbound" : false,
        "releasetime" : 0,
        "height" : 2362981,
        "banscore" : 0
    }

The addnode command caused the node to re-check, changing the port, updating the send/conn times changin the "Inbound" status and updating the "blocks" value to the correct one.

Right now, nodes worth adding are the listening nodes: 185.150.190.19, 185.68.67.37, 144.76.64.49, 144.76.118.44

And, just for comparison with before in terms of chain movement:

Code:

"addr" : "185.150.190.19:41682",    "height" : 2362598,
"addr" : "185.68.67.37:41682",      "height" : 2364101,
"addr" : "178.223.55.155:53184",    "height" : 2363828,
"addr" : "178.223.55.155:56231",    "height" : 2363843,
"addr" : "185.79.5.221:53014",      "height" : 2363717,
"addr" : "145.239.189.106:53042",   "height" : 2363845,
"addr" : "178.221.183.154:9715",    "height" : 2363767,
"addr" : "178.221.183.154:9964",    "height" : 2363720,
"addr" : "46.0.192.98:60366",       "height" : 2362598,
"addr" : "178.223.55.155:64890",    "height" : 2363689,
"addr" : "178.223.55.155:64902",    "height" : 2363689,
"addr" : "94.25.174.181:39989",     "height" : 2363729,
"addr" : "18.191.168.158:61845",    "height" : 2287922,
"addr" : "144.76.64.49:37520",      "height" : 2361253,
"addr" : "109.10.108.52:56155",     "height" : 1340151,
"addr" : "94.25.174.181:33980",     "height" : 2362964,
"addr" : "109.10.108.52:56698",     "height" : 2362227,
"addr" : "5.39.70.87:47790",        "height" : 2362979,

Cheers

Graham

[gjhiggins]

Right now, nodes worth adding are the listening nodes: 185.150.190.19, 185.68.67.37, 144.76.64.49, 144.76.118.44

Well that was quick, 185.68.67.37 has disappeared, now there's only 185.150.190.19 plus my two servers that are listening.

The thing is, you can't sync from a node that isn't listening, you can only sync from a listening node. So all those nodes in the getpeerinfo list that aren't on a standard port aren't listening and if they have a different block height, then it's because they're on their own singleton fork. Only the sync nodes perpetuate the blockchain.

Both my servers are on height 2362986 and getpeerinfo run on the old server reports that it is (or was) in sync with the 185.150 server:

Code:

        "addr" : "185.150.190.19:41682",
        "height" : 2362966,
        "addr" : "144.76.118.44:41682",
        "height" : 2362966,

If you're on Linux, here's a handy bash incantation to pass through to calling slimcoind:

Code:

 getpeerinfo | grep -E '"addr" : "|"height" : '

I'll start a local node configured with maxconnections=1 and connect=185.150.190.19 with my chain dump from a couple of days ago and see how we get on.

Cheers

Graham

[psycodad]

Right now, nodes worth adding are the listening nodes: 185.150.190.19, 185.68.67.37, 144.76.64.49, 144.76.118.44

Well that was quick, 185.68.67.37 has disappeared, now there's only 185.150.190.19 plus my two servers that are listening.

I thought restarting the node would be a good idea as the debug.log was getting a little large (not so sure anymore if it really was a smart thing to do).
Now from debug.log it looks like a lot of blocks are getting orphaned (but I am not clear if these are blocks I have that are getting orphaned or if some other nodes tries to send me these blocks and my nodes doesn't accept them):

Code:

ERROR: ProcessBlock() : already have block (orphan) 00000cace8b563834b09
received block 000008fc93cbf886fc95
CBlock(hash=000008fc93cbf886fc95, ver=1, hashPrevBlock=0000058479ba8308616a, hashMerkleRoot=e3c6a5855e, nTime=1614195519, nBits=1e0f0bab, nNonce=568861, vtx=1, vchBlockSig=3046022100cc7c9c577e1d557b9d8d582de1c7c022732effbc111e209badd62f0bad83002f022100ccc65ca165cbf1bb67a082840b26ef444b4c26f0597f19c58488e0b72cdfbcc8)
CBlock General PoB(nBurnBits=1d033d45 nEffectiveBurnCoins=929843609442 (formatted 929843.609442))
  Coinbase(hash=e3c6a5855e, nTime=1614195347, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, -1), coinbase 0493aa36600107062f503253482f)
    CTxOut(nValue=49.23, scriptPubKey=028dd028c4c118857352f3e5cea9dea2ff402ba8bc55b5f4e57d2a3e0cea6daf9f OP_CHECKSIG)
  vMerkleTree: 
PruneOrphanBlocks() : Removed orphan block 00000b17c918aa0d1b7e30c630deda150a8fe176dcefa2b8f2d37b6cdc465bf3
ProcessBlock: ORPHAN BLOCK, prev=0000058479ba8308616a
askfor block 000007f6e62f41090086   -763482112
received block 000003b659de6b48e617
CBlock(hash=000003b659de6b48e617, ver=1, hashPrevBlock=000003bf08e6722d097d, hashMerkleRoot=cba507eea6, nTime=1614201829, nBits=1e0fe072, nNonce=224718, vtx=1, vchBlockSig=3046022100f9ba40fb8553c6eb345f5d2845ecf4989bd7f5eee3771d299d35d10cdc0f0223022100b6c47a63c56d79b32d9bab0f7ae9bf6ee099b26deac975d01639655e2986013a)
CBlock General PoB(nBurnBits=1d01ec8f nEffectiveBurnCoins=929760764127 (formatted 929760.764127))
  Coinbase(hash=cba507eea6, nTime=1614201761, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, -1), coinbase 04a1c336600101062f503253482f)
    CTxOut(nValue=49.90, scriptPubKey=028dd028c4c118857352f3e5cea9dea2ff402ba8bc55b5f4e57d2a3e0cea6daf9f OP_CHECKSIG)
  vMerkleTree: 
..

[gjhiggins]

I thought restarting the node would be a good idea as the debug.log was getting a little large (not so sure anymore if it really was a smart thing to do).
Now from debug.log it looks like a lot of blocks are getting orphaned (but I am not clear if these are blocks I have that are getting orphaned or if some other nodes tries to send me these blocks and my nodes doesn't accept them):

I had the same experience working off my old chaindump from a couple of days ago when trying to cross-sync my servers - loadsa orphans being processed.

So I started again, with same dump but this time connecting to 185.150.190.19. The first thing my node did was re-org away a pile of blocks and after that it was just a matter of syncing up to the latest block (as far as 185.150.190.19 sees it). I suspect my node was previously on a fork and as there were so many orphaned blocks, there was a good chance that 185.150.190.19 had a cleaner chain - which it seems to have had.

I have a parallel node on the main server that is currently syncing from 0, in due course that will give me a chaindump that is definitely orphan-free. I'll make a zipfile available when it's done.

In the meantime, here's the most recent chaindump zipfile, the result of the re-syncing to 185.150.190.19 as described above.

Latest node as far as my two listening servers are concerned is 2363137 #000005c5918bb70de908caf07cb8b6865ca8ff1220a0b9878eb89132ba46117b

Cheers

Graham

[johnwhitestar]

I thought restarting the node would be a good idea as the debug.log was getting a little large (not so sure anymore if it really was a smart thing to do).
Now from debug.log it looks like a lot of blocks are getting orphaned (but I am not clear if these are blocks I have that are getting orphaned or if some other nodes tries to send me these blocks and my nodes doesn't accept them):

I had the same experience working off my old chaindump from a couple of days ago when trying to cross-sync my servers - loadsa orphans being processed.

So I started again, with same dump but this time connecting to 185.150.190.19. The first thing my node did was re-org away a pile of blocks and after that it was just a matter of syncing up to the latest block (as far as 185.150.190.19 sees it). I suspect my node was previously on a fork and as there were so many orphaned blocks, there was a good chance that 185.150.190.19 had a cleaner chain - which it seems to have had.

I have a parallel node on the main server that is currently syncing from 0, in due course that will give me a chaindump that is definitely orphan-free. I'll make a zipfile available when it's done.

In the meantime, here's the most recent chaindump zipfile, the result of the re-syncing to 185.150.190.19 as described above.

Latest node as far as my two listening servers are concerned is 2363137 #000005c5918bb70de908caf07cb8b6865ca8ff1220a0b9878eb89132ba46117b

Cheers

Graham

Thank you so much for your hints!

@keliokan Graham has provided a lot of useful info here, if you need any additional help please let me know

Update: Freiexchange and cryptoId are both on the wrong chain I'm in touch with them. They are solving the issue on their side as well.

If I understood it well the instructions are

- the following line should be added into slimcoin.conf:

Code:

addnode=185.150.190.19

- and the Graham's snapshot should be used:
https://minkiz.co/noodlings/slm/slmchain.zip

For those behind the main chain just adding the addnode line and restarting the wallet should be enough.

Update2: Freiexchange has reported an error while downloading the above snapshot (Internal Server Error). Probably this one should be ok:

Code:

ftp://185.150.190.19/chain-slm.slimcoin_v0.6.0_d21-02-23.tgz

[PeterColumboFalk]

I deleted the last blockchain from february because of uncertenty. There are two blockchains remaining now:

Code:

ftp://185.150.190.19/chain-slm.slimcoin_v0.6.0_20-12-12.tgz
ftp://185.150.190.19/chain-slm.slimcoin_v0.6.0_d21-01-17.tar

Host 185.150.190.19 did not mint until now, is planned in the future. The current block is 2363595.

CryptoID explorer seems to make a full blockchain syncronisation.

[johnwhitestar]

I deleted the last blockchain from february because of uncertenty. There are two blockchains remaining now:

Code:

ftp://185.150.190.19/chain-slm.slimcoin_v0.6.0_20-12-12.tgz
ftp://185.150.190.19/chain-slm.slimcoin_v0.6.0_d21-01-17.tar

Host 185.150.190.19 did not mint until now, is planned in the future. The current block is 2363595.

CryptoID explorer seems to make a full blockchain syncronisation.

They were trying to download your snapshot while it was probably already deleted. So I've just gave them your repository link directly.

Update: Freiexchange is on the right blockchain already (should be block 2363651 right now). However the deposits are disabled for the moment to be sure everybody is on the right chain.

Update2: CryptoID are getting : "Slimcoin: Error loading blkindex.dat" while trying to use each of the snapshots, that's why they resumed to normal sync right now. I guess they are on version 0.5 of the wallet.

[gjhiggins]

Update2: Freiexchange has reported an error while downloading the above snapshot (Internal Server Error). Probably this one should be ok:

Code:

ftp://185.150.190.19/chain-slm.slimcoin_v0.6.0_d21-02-23.tgz

Doh. My bad. Fixed now, fwiw. https://minkiz.co/noodlings/slm/slmchain.zip

Cheers

Graham

[johnwhitestar]

Update2: Freiexchange has reported an error while downloading the above snapshot (Internal Server Error). Probably this one should be ok:

Code:

ftp://185.150.190.19/chain-slm.slimcoin_v0.6.0_d21-02-23.tgz

Doh. My bad. Fixed now, fwiw. https://minkiz.co/noodlings/slm/slmchain.zip

Cheers

Graham

I'll let them know immediately, but I'm not sure they'll decide to compile v.0.6 and whether the issue they have ("Slimcoin: Error loading blkindex.dat"  error message) has to do with the different version of the wallet they use.

[gjhiggins]

I'll let them know immediately, but I'm not sure they'll decide to compile v.0.6 and whether the issue they have ("Slimcoin: Error loading blkindex.dat"  error message) has to do with the different version of the wallet they use.

Not the wallet, the error msg is explicit, it's an issue with the client-generated db index file and it may be a mismatch in bdb versions, if they're using an earlier version than the libdb5.3 that my server client was linked with. If it proves to be an issue, I can recompile the node linking it against libdb4.8 and create a chaindump from that.

Cheers

Graham

[johnwhitestar]

I'll let them know immediately, but I'm not sure they'll decide to compile v.0.6 and whether the issue they have ("Slimcoin: Error loading blkindex.dat"  error message) has to do with the different version of the wallet they use.

Not the wallet, the error msg is explicit, it's an issue with the client-generated db index file and it may be a mismatch in bdb versions, if they're using an earlier version than the libdb5.3 that my server client was linked with. If it proves to be an issue, I can recompile the node linking it against libdb4.8 and create a chaindump from that.

Cheers

Graham

Message delivered, I'm waiting for their replay.

Update: The issue is solved by CryptoID as well. They compiled the v.0.6 and reported as following: "I recompiled from GitHub and it worked, though version reported by rpc API is a mix of 0.5 and 0.6. I am also on a server with a libdb5.3"

@keliokan were you able to solve the issue on your side?

Update2: Fedde from Freiexchange proposes to ban the servers that are creating this kind of issues. But it seems like we have only 6 servers constantly online right now. Namely it should be 1 mine, 1 of PeterColumboFalk, 1 of cryptoId, 1 of Freiexchange, 2 of Graham. The others are opening and closing to get rewards only. So I don't know whom we should ban and how we can calculate the "bad" servers.

I'm going to set up another server these days.
But what's not that clear to me. If we have 6 servers online, why is it my local wallet has only 1 connection?

[PeterColumboFalk]

...
But what's not that clear to me. If we have 6 servers online, why is it my local wallet has only 1 connection?

I have this behaviour too. My minting homewallet currently says "3 active connection(s) to Slimcoin network), and command getpeerinfo tells me about two connections at the same time. Yesterday evening I did "addnode 185.150.190.19" to my homewallet, and I wonder why host 185.150.190.19 does not forward some of his 22 connections (maxconnections=64) to my homewallet.

Homewallet is version 0.6.0 on Windows 8.1.

[johnwhitestar]

...
But what's not that clear to me. If we have 6 servers online, why is it my local wallet has only 1 connection?

I have this behaviour too. My minting homewallet currently says "3 active connection(s) to Slimcoin network), and command getpeerinfo tells me about two connections at the same time. Yesterday evening I did "addnode 185.150.190.19" to my homewallet, and I wonder why host 185.150.190.19 does not forward some of his 22 connections (maxconnections=64) to my homewallet.

Homewallet is version 0.6.0 on Windows 8.1.

I'm thinking maybe my server's slimcoin.conf misses something. So it's not considered a seeding node at all by the net.
What would be the best slimcoin.conf setup from the point of view of our public usefulness?

By the way we should also have another node of someone who is PoBing, so there should be at least 7 active connections each time.

[gjhiggins]

But what's not that clear to me. If we have 6 servers online, why is it my local wallet has only 1 connection?

https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery

They'll only show up if you have added them with addnode/connect in the config file and they are listening nodes ..

slimcoin.conf

Code:

maxconnections=127
connect=144.76.118.44
connect=144.76.64.49
connect=185.150.190.19

getpeerinfo (total 3 connections)

Code:

"addr" : "144.76.118.44:41682",
"height" : 2364444,

"addr" : "144.76.64.49:41682",
"height" : 2364444,

"addr" : "185.150.190.19:41682",
"height" : 2364444,

Cheers

Graham

[johnwhitestar]

But what's not that clear to me. If we have 6 servers online, why is it my local wallet has only 1 connection?

https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery

They'll only show up if you have added them with addnode/connect in the config file and they are listening nodes ..

slimcoin.conf

Code:

maxconnections=127
connect=144.76.118.44
connect=144.76.64.49
connect=185.150.190.19

getpeerinfo (total 3 connections)

Code:

"addr" : "144.76.118.44:41682",
"height" : 2364444,

"addr" : "144.76.64.49:41682",
"height" : 2364444,

"addr" : "185.150.190.19:41682",
"height" : 2364444,

Cheers

Graham

Thank you very much! Very useful.
But is

Code:

listen=1

necessary for the server?