ptrace
Newbie
Offline
Activity: 34
Merit: 0
|
|
December 05, 2016, 02:15:27 AM |
|
//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"
|
|
|
|
Testing Crypto
|
|
December 05, 2016, 03:56:47 AM Last edit: December 05, 2016, 04:52:01 AM by Testing Crypto |
|
//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)?
|
ZwNpPhVYrSrPMS71GLc7TEnbqA9VSZopGn // Gift5YapqsZqSTW8T4S3sCU4sngCkvh4ba // 3Gwc4KzVtuJ9ADnuqzF7XRhSaaE7HkBWpr // 1PAGEHrN62tgUHncGWbbhKe9jhZGXsxFC4 "In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle." -- Satoshi {SAT OS hi}
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
December 05, 2016, 12:30:25 PM |
|
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)?
1. There already has been an update, see the official Slimcoin repository. (No, not that Official Slimcoin repository, this Official Slimcoin repository, specifically, the master branch). 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: - 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.
(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#L5384If 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
|
|
|
|
Testing Crypto
|
|
December 05, 2016, 02:38:34 PM |
|
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)?
1. There already has been an update, see the official Slimcoin repository. (No, not that Official Slimcoin repository, this Official Slimcoin repository, specifically, the master branch). 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: - 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.
(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#L5384If 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 It looks like you have many fixes in place, just had a look @ the updates & see many improvements. Keep up the good work, looking forward to the next release & testing the new improvement updates. Been 2 years since I've tested Slimcoin, the download & sync didn't take long at all (solid state drive & hardwired, not wireless). No problems at all so far, the 500 confirmations was just a thought about wanting to be able to PoB or PoS sooner & have no problem with 500.
|
ZwNpPhVYrSrPMS71GLc7TEnbqA9VSZopGn // Gift5YapqsZqSTW8T4S3sCU4sngCkvh4ba // 3Gwc4KzVtuJ9ADnuqzF7XRhSaaE7HkBWpr // 1PAGEHrN62tgUHncGWbbhKe9jhZGXsxFC4 "In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle." -- Satoshi {SAT OS hi}
|
|
|
|
Rols
|
|
December 18, 2016, 02:32:10 AM |
|
I started the windows wallet and it had 2 connections after 5 sekonds. Will probably take forever to sync.It says 930 days ago.
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
December 18, 2016, 03:56:26 AM |
|
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
|
|
|
|
ArchitektoR
|
|
December 18, 2016, 07:18:19 AM |
|
Linux version can't grub blocks from "zero" - stuck with 530 blocks and 0 connections...
|
|
|
|
cengsuwuei
|
|
December 18, 2016, 07:57:02 AM |
|
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 ?
|
|
|
|
Rols
|
|
December 18, 2016, 08:45:26 AM Last edit: December 18, 2016, 09:10:33 AM by Rols |
|
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?
|
|
|
|
ArchitektoR
|
|
December 18, 2016, 09:48:55 AM |
|
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...
|
|
|
|
Rols
|
|
December 18, 2016, 09:54:27 AM Last edit: December 18, 2016, 11:26:53 AM by Rols |
|
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.
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
December 18, 2016, 01:13:09 PM |
|
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
|
|
|
|
Rols
|
|
December 18, 2016, 02:11:12 PM Last edit: December 18, 2016, 02:26:16 PM by Rols |
|
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.
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
December 18, 2016, 03:02:34 PM |
|
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
|
|
|
|
CryptoCypherCoin
Full Member
Offline
Activity: 172
Merit: 100
Developer at TheCryptoChat
|
|
December 18, 2016, 03:10:31 PM |
|
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
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
December 18, 2016, 03:32:15 PM |
|
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
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://bitcointalk.org/index.php?topic=613213.0Cheers Graham
|
|
|
|
ArchitektoR
|
|
December 18, 2016, 08:00:33 PM |
|
Sorry to say, but Windows version still crashes when mining:
|
|
|
|
Rols
|
|
December 18, 2016, 08:46:05 PM |
|
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.
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
December 18, 2016, 08:46:58 PM |
|
Sorry to say, but Windows version still crashes when mining
I don't have access to a m/c running Windows, so I'm unable to reproduce that particular fault and thereby not in a position to offer direct assistance. There is a debug.log file located at ${HOME}/Application Support/SLIMCoin/debug.log which may contain a clue as to the origin of the problem. The logging of debug information is enabled either by adding debug=1 to the config file ( ${HOME}/Application Support/SLIMCoin/slimcoin.conf) or by appending --debug to the command line invocation. Rather than permanently decorating the github repos issue list with a debug log, it's common practice to create a time-limited pastebin post then advertise the URL of the post either publicly or privately according to preference/circumstance. Cheers Graham
|
|
|
|
|