Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 150. (Read 137076 times)
Sorry to say, but Windows version still crashes when mining:
Wow I'm seeing a trend here with all of these new mechanisms being developed: proof-of-burn
Keep on it guys, love seeing this space expand and new, exciting developments in this space
Keep on it guys, love seeing this space expand and new, exciting developments in this space
I wouldn't wish you to labour under any misapprehensions, Slimcoin is not a new project. It was launched in mid-May 2014, the original bitcointalk thread is:
https://bitcointalksearch.org/topic/ann-slimcoin-proof-of-burn-new-block-gen-mineable-by-low-power-computer-613213
Cheers
Graham
Wow I'm seeing a trend here with all of these new mechanisms being developed: proof-of-burn
Keep on it guys, love seeing this space expand and new, exciting developments in this space
Keep on it guys, love seeing this space expand and new, exciting developments in this space
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
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
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:
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:
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):
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/#blkexp
They 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
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
Code:
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:
Code:
[
{
"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:
Code:
[
{
"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):
Code:
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/#blkexp
They 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
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.
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.
https://minkiz.co/noodlings/slm/slimcoin-qt-win.zip
(Also advertised on https://minkiz.co/noodle)
Cheers
Graham
Great work, thanks! Mining working with this build, will test PoS when it will sync on another VM and PoB some time later.
Linux still stuck at 530 block from genesis... Looks like it still needs an external blockchain download...
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?
Slimcoin is old coin but i can't find exchanger in support trading in slim coin
hello dev , where is exchanger slimcoin ready added and listing ?
hello dev , where is exchanger slimcoin ready added and listing ?
Linux version can't grub blocks from "zero" 
- stuck with 530 blocks and 0 connections...
- stuck with 530 blocks and 0 connections... 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
I started the windows wallet and it had 2 connections after 5 sekonds. Will probably take forever to sync.It says 930 days ago.
Just compiled Linux version from https://github.com/slimcoin-project/Slimcoin/tree/master and let it sync. Will see how it will run and maintain blockchain.
Thanks, although that was the first thing that I typed into the console a few times & came back with an error. I did however get it to work with "setgenerate true 4", been finding blocks for a few hours now & seems to be running without any errors.
//if there is an update, would the confirmations be set to something a little more realistic & not 520 (just a thought)?
//if there is an update, would the confirmations be set to something a little more realistic & not 520 (just a thought)?
1. There already has been an update, see the official Slimcoin repository. (No, not that
2. OC (original commit) has 500 confirmations. Suggestions for changes to this value are only likely to gain widespread support if accompanied by a clear mathematical treatment describing the rationale for the change.
I have successfully compiled and executed the master branch - slimcoind on Ubuntu 14.04 and slimcoin-qt on Ubuntu 16.04, OS X 10.6.8, Windows 64bit (run on wine). I am currently trying to compile an OS X 10.10 version but am experiencing the same difficulty as others:
Quote
- if you're on 10.9 and compile against MacPorts libs, ensure MACOSX_DEPLOYMENT_TARGET is unset. You cannot use the libs from MacPorts to build bitcoin for older systems by setting it.
- if you're on 10.8 and below and compile against MacPorts libs, libstdc++ will be used automatically and you shouldn't have any problems.
- if you use boost or any other dependency from a different source, check which C++ runtime it uses using otool -L. If it's libc++ and you're on <= 10.8, you need to compile with clang++ -stdlib=libc++. If it's libstdc++ and you're on 10.9 or later, you need to compile with clang++ -stdlib=libstdc++.
- if the C++ runtimes used by your dependencies differ, you will have problems.
- if you're on 10.8 and below and compile against MacPorts libs, libstdc++ will be used automatically and you shouldn't have any problems.
- if you use boost or any other dependency from a different source, check which C++ runtime it uses using otool -L. If it's libc++ and you're on <= 10.8, you need to compile with clang++ -stdlib=libc++. If it's libstdc++ and you're on 10.9 or later, you need to compile with clang++ -stdlib=libstdc++.
- if the C++ runtimes used by your dependencies differ, you will have problems.
(They do. I do)
As regards the mining page tab, setting the number of threads via the GUI interface is rather hit and miss atm. afaict, it's either no threads or all threads.
According to the code, max threads can be set using the genproclimit configuration directive:
https://github.com/slimcoin-project/Slimcoin/blob/master/src/main.cpp#L5384
If it doesn't work the way you think it should - raise an issue: https://github.com/slimcoin-project/Slimcoin/issues (i.e. on the official unofficial repos). If you're unfamiliar with the ethos of open source code, I can reassure you that issue tickets carrying reports of individual experiences of errors (with at least a little detail) are not automatically perceived as criticism but as potentially valuable diagnostic information.
Cheers
Graham
//already found one block mining with the GUI, "setgenerate true" only seems to work with 4 & can't change it to 1-3?
Try "setgenerate true 3"
Thanks, although that was the first thing that I typed into the console a few times & came back with an error. I did however get it to work with "setgenerate true 4", been finding blocks for a few hours now & seems to be running without any errors.
//if there is an update, would the confirmations be set to something a little more realistic & not 520 (just a thought)?
//already found one block mining with the GUI, "setgenerate true" only seems to work with 4 & can't change it to 1-3?
Try "setgenerate true 3"
I remember testing Slimcoin, the afterburn staking like PoS was great & just got caught up with the 1000's of others. Would be willing to test Slimcoin again if there is progress & already have a wallet sync'd up since the talk over the last week. Downloaded it, sync'd up & swapped my .dat from years ago. It showed that there was still effective burnt coins, only like 30 on one .dat & 10 on the other. Great concept, but do remember like many others it did have problems with forking or syncing & otherwise worked well.
//already found one block mining with the GUI, "setgenerate true" only seems to work with 4 & can't change it to 1-3?
{
"blocks" : 830663,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00158252,
"errors" : "",
"generate" : true,
"genproclimit" : 4,
"hashespersec" : -,
"networkghps" : 0.00006730,
"pooledtx" : 0,
"testnet" : false
}
//already found one block mining with the GUI, "setgenerate true" only seems to work with 4 & can't change it to 1-3?
{
"blocks" : 830663,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00158252,
"errors" : "",
"generate" : true,
"genproclimit" : 4,
"hashespersec" : -,
"networkghps" : 0.00006730,
"pooledtx" : 0,
"testnet" : false
}
gjhiggins makes good things for coin
Agreed.
If you guys need help with coding count me in. I'm a sysadmin with some coding and bitcoin-skills, if thats enough.
Jump to: