|
The problem with ethereum is that it is not even in a beta stage. Too many people throw money into it and it opens up a lot of problems. Such a platform that ethereum are should be developed under 2-3 years time before anybody should invest in it. Peoples greed makes them jump into projects like this and they hope to become rich quickly. Ethereum are also faulty by design.
|
|
|
|
I really can't understand what goes through the mind of this guy.
He would earn much more money and fame by acting correctly.
Saying who he is, what he already developed.
And yet he chose the wrong way.
Vcash, it would be worth at least 20X more than the maximum she hit if he had shown who he is and acted like a decent man.
He even had a chance to come back even after he dumped and ran, however that chance ended with the exploit.
one day 2 even more decent guys meet him to explain how really famous he is, how good is his coin, and his wife, and his children, and how much he owes them to keep all that intact. as i said in previous post (moderated) this coin was "officially destroyed", we don't know the circumstances, his coin - his choice. Vcash was not destroyed. Dev team are working on new wallets and on the exploit. That exploit is almost irrelevant. To work it takes a very high mining hash. So before run, JC tried to take all the miners to his pool, creating forks for the others and slandering them This is not new. He could kick out nodes from the beginning. It was closed source and he said it was the consensus that did it. There were miners that mined with a lot of computers that lost his coins. |
|
|
|
TX wallet on Yobit are finnaly fixed and synced. Lets see if they can keep it that way  |
|
|
|
(warning: crowdfunding this project does not guarantee profit or income of any way. crowdfunding is similar to "gofundme" and you will get some of the coins but you will not be guaranteed to be made rich or anything of the sort. crowdfunding should be done if you are actually interest to see project go forward)
At least he's honest heh, but a crowdfund can be profitable for everyone if it's scaled properly for amount of users with supply/demand. So he is honest because he wrote a disclaimer? You have a terrible judgment if you think that everyone with a disclaimer are honest. Its the projekt you should look at and not 2 lines of words. |
|
|
|
I like anti coins. There have been a few of them here. But this coin is just to painful to watch.  |
|
|
|
Hi, We've added all TTY algo's to the miners multipool: www.zpool.caCheers! Appears we need new pools again. You need more than pools. This coin needs some developement. |
|
|
|
This is not legit in australia or most other countries in the world. People that have worked even just one day in their lives knows that. |
|
|
|
u ugys really buying when dev quit?
You suck at talking badly about other coins than the ones you have. Try harder. |
|
|
|
Do not listen to people talking about the pump or dumps. They just want to get someone to buy their coins as they are stuck with. Idiots can go into any faucet and fill up again.  Doge is located in a normal price point and can be used for much. It is the most important thing about it. |
|
|
|
Sorry to say, but Windows version still crashes when mining:  [/quote Hm that error maybe have something to do with orphanes. |
|
|
|
It usually the longest chain that should win.
That is often the case in practice but the criterion as implemented in the code is the amount of work done -- it is a defence against exploits that attempt to lengthen the chain by artificially reducing the diff locally so more blocks can be mined. Syncing does seem to take forever and my experience is that it often stops for a while (long enough for one to lose faith) and then just starts up again. I've synched from zero successfully with the Linux client (several times, just to convince myself that the first time wasn't a fluke) and with the OS X 10.6.8 client and the cross-compiled Windows client on wine. For not entirely-unrelated reasons, I'm allowing a wine-hosted FantomFNX windows client to load from bootstrap and so far it's run all yesterday and all night, it's still going and has managed to load just over 100k blocks, that's significantly slower than the wine-hosted Slimcoin cross-compiled Windows client did synching from the live network. Can't speak for a natively-hosted client though.Cheers Graham That is slow. Im syncing with my computer conected to a wifi router and that router is connected with 4G MOBILE network . It should take less than 24 hours to sync. Im going to rent a few vps so my nodes are onlin 24/7. I have seen old wallets that took 3-4 days to sync. |
|
|
|
I've never managed to persuade the client to read a bootstrap.dat file, it may be something to do with rejected PoS rewards from orphaned blocks causing the process to be abandoned. In each case, I've been obliged to allow the client to synch from the live network. However, it's trivial to create a bootstrap.dat file and a cron job can maintain its currency. I'll give that a go, see if it helps. As for limited connections, look to NAT. The server serving minkiz.co is an i7 running Ubuntu Wily from hetzner, i.e. on the open subnet. Here's the result of getpeerinfo gjh@Ubuntu-1510-wily-64-minimal ~ $ /www/lib/abe/slimcoin-master/slimcoind getpeerinfo
[
{
"addr" : "37.187.100.75:41682",
"services" : "00000001",
"lastsend" : 1482060903,
"lastrecv" : 1482060903,
"conntime" : 1479081131,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 810517,
"banscore" : 1
},
{
"addr" : "144.76.35.207:41682",
"services" : "00000001",
"lastsend" : 1482060903,
"lastrecv" : 1482060903,
"conntime" : 1479081132,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 810517,
"banscore" : 2
},
{
"addr" : "5.9.39.9:41682",
"services" : "00000001",
"lastsend" : 1482060902,
"lastrecv" : 1482060902,
"conntime" : 1479081138,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 810517,
"banscore" : 2
},
{
"addr" : "173.168.81.122:51691",
"services" : "00000001",
"lastsend" : 1482060903,
"lastrecv" : 1482059704,
"conntime" : 1481047106,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 832200,
"banscore" : 0
},
{
"addr" : "78.46.46.11:49712",
"services" : "00000001",
"lastsend" : 1482060903,
"lastrecv" : 1482060903,
"conntime" : 1481366071,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 835501,
"banscore" : 1
},
{
"addr" : "88.98.87.243:41262",
"services" : "00000001",
"lastsend" : 1482060903,
"lastrecv" : 1482060903,
"conntime" : 1481970259,
"version" : 60003,
"subver" : "/Satoshi:0.6.4/SLIMCoin:0.5.0(SLMv0.4.1-alpha-14-g8fa8960-dirty-alpha)/",
"inbound" : true,
"releasetime" : 0,
"height" : 842160,
"banscore" : 1
},
{
"addr" : "39.128.196.200:33192",
"services" : "00000001",
"lastsend" : 1482060903,
"lastrecv" : 1482060150,
"conntime" : 1482059581,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 843406,
"banscore" : 0
}
]
NAT does confuse matters - the “Satoshi:0.6.4” above is either the laptop I'm using right now or the MacBook sat across the room from me. I'll hunt around for some received wisdom (and maybe even go so far as running the MacBook client from a different port and configuring the NAT to enable two-way connectivity). For comparison, the result of the same call made on the client running on my Xenial i3 laptop: [
{
"addr" : "37.187.100.75:41682",
"services" : "00000001",
"lastsend" : 1482063713,
"lastrecv" : 1482063617,
"conntime" : 1481970257,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 842422,
"banscore" : 0
},
{
"addr" : "144.76.35.207:41682",
"services" : "00000001",
"lastsend" : 1482063616,
"lastrecv" : 1482063615,
"conntime" : 1481970257,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 842422,
"banscore" : 0
},
{
"addr" : "5.9.39.9:41682",
"services" : "00000001",
"lastsend" : 1482063712,
"lastrecv" : 1482063614,
"conntime" : 1481970258,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 842422,
"banscore" : 0
},
{
"addr" : "144.76.64.49:41682",
"services" : "00000001",
"lastsend" : 1482063616,
"lastrecv" : 1482063712,
"conntime" : 1481970259,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/SLIMCoin:0.4.0(SLMv0.4.1-alpha-12-g14c5606-dirty-alpha)/",
"inbound" : false,
"releasetime" : 0,
"height" : 842422,
"banscore" : 0
},
{
"addr" : "78.46.46.11:41682",
"services" : "00000001",
"lastsend" : 1482063616,
"lastrecv" : 1482063615,
"conntime" : 1481970276,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 842422,
"banscore" : 0
}
]
Hmm. The 144.76.64.49:41682 is the heztner box, the difference suggests I may have omitted to pull the latest code. Let me check that. Just to confound matters further, here's the result of getpeerinfo on the 2011 MacBook running Snow Leopard: [
{
"addr" : "37.187.100.75:41682",
"services" : "00000001",
"lastsend" : 1482064108,
"lastrecv" : 1482064107,
"conntime" : 1481632612,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 838662,
"banscore" : 0
},
{
"addr" : "144.76.35.207:41682",
"services" : "00000001",
"lastsend" : 1482064108,
"lastrecv" : 1482064108,
"conntime" : 1481632761,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 838664,
"banscore" : 0
},
{
"addr" : "5.9.39.9:41682",
"services" : "00000001",
"lastsend" : 1482064106,
"lastrecv" : 1482064107,
"conntime" : 1481632762,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 838664,
"banscore" : 1
},
{
"addr" : "78.46.46.11:41682",
"services" : "00000001",
"lastsend" : 1482064107,
"lastrecv" : 1482064107,
"conntime" : 1481637400,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 838725,
"banscore" : 0
}
]
Frankly, I don't know how to interpret the difference in heights reported by the daemon running on the hetzner box. In other versions of the Bitcoin codebase it is labelled “startingheight”. Here's the result from the same call but with Chaincoin (a Bitcoin Core 0.9 clone): gjh@Ubuntu-1510-wily-64-minimal ~ $ /www/lib/abe/chaincoin/chaincoin-cli getpeerinfo
[
{
"addr" : "162.255.117.105:63044",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061504,
"bytessent" : 80794494,
"bytesrecv" : 11243873,
"conntime" : 1472438063,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.1/",
"inbound" : true,
"startingheight" : 884591,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "5.1.56.44:35578",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061504,
"bytessent" : 55560251,
"bytesrecv" : 16004957,
"conntime" : 1474322981,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 898084,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "[2a00:e140::2c]:38470",
"addrlocal" : "[2a01:4f8:191:7330::2]:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061504,
"bytessent" : 37967409,
"bytesrecv" : 9511147,
"conntime" : 1474386341,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 898586,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "66.172.10.28:59851",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061504,
"bytessent" : 10612170,
"bytesrecv" : 4624304,
"conntime" : 1479742746,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 955754,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "80.236.18.96:47916",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061647,
"bytessent" : 12460661,
"bytesrecv" : 8681214,
"conntime" : 1479947729,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 958136,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "192.99.37.133:45792",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061773,
"bytessent" : 10416941,
"bytesrecv" : 7641128,
"conntime" : 1480279029,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 960059,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "192.99.37.133:9999",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061773,
"bytessent" : 6247740,
"bytesrecv" : 5540452,
"conntime" : 1480653683,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : false,
"startingheight" : 963415,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "45.32.231.128:49994",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061788,
"bytessent" : 6316930,
"bytesrecv" : 5614259,
"conntime" : 1480655788,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 961888,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "[2001:19f0:8001:19:5400:ff:fe2a:8427]:49593",
"addrlocal" : "[2a01:4f8:191:7330::2]:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061788,
"bytessent" : 5982793,
"bytesrecv" : 5335419,
"conntime" : 1480655801,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 962889,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "75.83.174.139:46624",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061504,
"bytessent" : 6077908,
"bytesrecv" : 1516014,
"conntime" : 1481041825,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 966379,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "45.32.231.128:11994",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061788,
"bytessent" : 3820516,
"bytesrecv" : 3575313,
"conntime" : 1481108639,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : false,
"startingheight" : 967644,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "84.200.4.67:44887",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061744,
"bytessent" : 4786012,
"bytesrecv" : 3523256,
"conntime" : 1481122035,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 967800,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "84.200.4.67:9999",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061744,
"bytessent" : 3637001,
"bytesrecv" : 3212535,
"conntime" : 1481153752,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : false,
"startingheight" : 968183,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "198.27.81.25:56571",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061564,
"bytessent" : 2578091,
"bytesrecv" : 2065377,
"conntime" : 1481555828,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 916388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "[2607:5300:60:2219::]:43147",
"addrlocal" : "[2a01:4f8:191:7330::2]:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061564,
"bytessent" : 2091118,
"bytesrecv" : 1057558,
"conntime" : 1481556052,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 968908,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "68.50.149.140:49431",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061783,
"bytessent" : 1281720,
"bytesrecv" : 847295,
"conntime" : 1481826608,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 970340,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "5.228.235.156:53678",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061504,
"bytessent" : 1136493,
"bytesrecv" : 401305,
"conntime" : 1481837534,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 970300,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "88.98.87.243:46902",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061504,
"bytessent" : 682646,
"bytesrecv" : 99616,
"conntime" : 1481949796,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.1/",
"inbound" : true,
"startingheight" : 971424,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "71.87.238.84:49376",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061766,
"bytessent" : 285324,
"bytesrecv" : 240133,
"conntime" : 1481984806,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 971863,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "68.50.149.140:49329",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061765,
"bytessent" : 236632,
"bytesrecv" : 265111,
"conntime" : 1481992128,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 971914,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "192.99.200.144:59584",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061541,
"bytessent" : 140690,
"bytesrecv" : 22993,
"conntime" : 1482019955,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 971982,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "75.139.237.75:46405",
"addrlocal" : "144.76.64.49:11994",
"services" : "00000001",
"lastsend" : 1482061768,
"lastrecv" : 1482061624,
"bytessent" : 132235,
"bytesrecv" : 18428,
"conntime" : 1482023103,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Core:0.9.2.2/",
"inbound" : true,
"startingheight" : 971982,
"banscore" : 0,
"syncnode" : false
}
]
Just about anybody's guess is better than mine atm. I'll attend to NAT/port issues to try and clarify the local conditions (which is why I'm working on an OS X Sierra version - it will enable me to recruit Ngaio's new MB, then I might get better triangulation). The performance of the Slimcoin.app on the old MacBook is a useful datum point. The Slimcoin app uses around 1.5-2% of (a OS X 10.6.8 Core Duo) CPU thread and has received several mint-by-proof-of-burn blocks, compared to just one mint-by-proof-of-stake (probably courtesy of the low diff atm) but it does suggest a validation of the original intention of producing a coin that doesn't need special hardware to mine (i.e. protect the public ledger). As regards exchanges, I consider that to be someone else's business (literally). As regard the chart, it's an initial step towards instrumenting the network in more detail. I finally managed to work out what we're looking at - there are (at least) two difficulties in play, PoS and PoW - the graph shows both, without lifting the pen, hence the up-and-down graphs - and serendipitously, the relative proportion of blocks generated by each. I presume there're also mint-by-proof-of-burn blocks in there too, perhaps there's a need for three separate plot lines. Network hash rate would be a useful addition I feel, I'm given to understand that PoS coin networks can become unstable when only a few nodes are staking. The mining tab is definitely wonky and needs further work, lemme check ... yup, thought so. Simply clicking “Start Mining” has no effect. Incrementing the threads by 1 (to 2) and clicking the “Start Mining” does work in a manner of speaking in that ALL threads are used. For an interim solution, it may be that setting the genlimit parameter will limit that. (There's always slimminer, it worked okay when I tried it with this client). As regards more than one chain, that is possible. I have added a block explorer to the coin so users can check their node's status without having to negotiate the rpc command console. There are two block explorers: https://bchain.info/SLM/and http://www.slimcoin.club/#blkexpThey are in synch as far as I can tell, e.g. 843491 appears in both and they agree on the hash as 0242f191867f6119a691ab7d945386f6334989e36911c85c40ec4f5ab8e519a7 and that's the same hash as reported by the in-client block explorer in the client running my laptop, and the MacBook, and the hetzner box. If entering 843491 and then clicking “Jump to Block” (or getblockhash 843491 on the rpc console) doesn't result in 0242f191867f6119a691ab7d945386f6334989e36911c85c40ec4f5ab8e519a7 then that client is working on a different chain. If that is the case, it is your choice to continue working on that chain or not --- in practical terms, the social consensus trumps the crypto consensus. For sanity's sake, I cross-reference with the block explorers and take my cue from them (one has to start *somewhere*). Cheers Graham My client is reporting the right height now. I have just downloaded 35% of the chain . I checked hash against bchain.info and Im on the right chain. I guess Im finished syncing tomorrow.  So it looks good. You are doing a great job. It usually the longest chain that should win. |
|
|
|
|
Its your own fault if you lose money on this projekt. Coding was not ready and there are flaws. To much money was pumped in and the result we can see today. When the price goes up everybody are happy. When it goes down ppl shouting scam. Ppl think they will be rich and throw money into something they dont understand. Eth is faulty by design but you should not throw money into it if you cant afford to lose it. I never bougt any.
|
|
|
|
|
The new windows client reports wrong amount of blocks that it needs to sync. I have 3 connections. Lets se when its fully synced.
Edit I put some peers in the conf file and it stoped syncing. Removed them and it started syncing again. We are maybe not on the same chain. Same result with the old and new client.
|
|
|
|
I started the windows wallet and it had 2 connections after 5 sekonds. Will probably take forever to sync.It says 930 days ago. I'm collating the resources for a release. Linux compilation seems robust but I've only managed to test briefly the MXE cross-compiled Windows binary under wine. Out of sheer curiosity, I compiled the code on an elderly Macbook limited to Snow Leopard (OS X 10.6. but I doubt that's of interest to anyone else. I am working to create a dmg package for Sierra. In advance of the release of a VM-hosted Vagrant+Ansible scripted cross-compilation to Windows deployment script, a pre-compiled Windows binary is available: https://minkiz.co/noodlings/slm/slimcoin-qt-win.zip(Also advertised on https://minkiz.co/noodle) Cheers Graham Thanks I check it out. Im down to 723 days ago. Edit: Im running it now. It looks stable. I have 2 connections. You have removed the animated icon and made a graf for difficulity. Im a little confused about this coin. Does it have a working PoS also? |
|
|
|
I started the windows wallet and it had 2 connections after 5 sekonds. Will probably take forever to sync.It says 930 days ago. |
|
|
|
Never |
|
|
|
|
increase in value of BTC puts pressure on TX.
|
|
|
|
My wallet has not been able to sync for over a month now.
So you got boned by the skeleton dev. You should hodl it then maybe this coin gets some flesh on it. |
|
|
|
|
Show Posts
