Bitcoin Forum
December 13, 2024, 10:24:17 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ... 159 »
  Print  
Author Topic: Slimcoin | First Proof of Burn currency | Decentralized Web  (Read 137111 times)
ptrace
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
December 05, 2016, 02:15:27 AM
 #181


//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
Hero Member
*****
Offline Offline

Activity: 614
Merit: 506


Applications


View Profile
December 05, 2016, 03:56:47 AM
Last edit: December 05, 2016, 04:52:01 AM by Testing Crypto
 #182


//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 Offline

Activity: 2254
Merit: 1290



View Profile WWW
December 05, 2016, 12:30:25 PM
 #183

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:

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.

(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
Testing Crypto
Hero Member
*****
Offline Offline

Activity: 614
Merit: 506


Applications


View Profile
December 05, 2016, 02:38:34 PM
 #184

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:

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.

(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


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}
ArchitektoR
Full Member
***
Offline Offline

Activity: 227
Merit: 103


View Profile
December 18, 2016, 12:25:13 AM
 #185

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.
Rols
Hero Member
*****
Offline Offline

Activity: 636
Merit: 500


View Profile
December 18, 2016, 02:32:10 AM
 #186

I started the windows wallet and it had 2 connections after 5 sekonds. Will probably take forever to sync.It says 930 days ago.  Grin
gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1290



View Profile WWW
December 18, 2016, 03:56:26 AM
 #187

I started the windows wallet and it had 2 connections after 5 sekonds. Will probably take forever to sync.It says 930 days ago.  Grin

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.Cool 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
Full Member
***
Offline Offline

Activity: 227
Merit: 103


View Profile
December 18, 2016, 07:18:19 AM
 #188

Linux version can't grub blocks from "zero" Sad - stuck with 530 blocks and 0 connections...
cengsuwuei
Hero Member
*****
Offline Offline

Activity: 714
Merit: 516


#SWGT PRE-SALE IS LIVE


View Profile
December 18, 2016, 07:57:02 AM
 #189

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 ?


.SWG.io.













..Pre-Sale is LIVE at $0.14..







..Buy Now..







4.45






Rols
Hero Member
*****
Offline Offline

Activity: 636
Merit: 500


View Profile
December 18, 2016, 08:45:26 AM
Last edit: December 18, 2016, 09:10:33 AM by Rols
 #190

I started the windows wallet and it had 2 connections after 5 sekonds. Will probably take forever to sync.It says 930 days ago.  Grin

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.Cool 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.  Smiley


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
Full Member
***
Offline Offline

Activity: 227
Merit: 103


View Profile
December 18, 2016, 09:48:55 AM
 #191


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
Hero Member
*****
Offline Offline

Activity: 636
Merit: 500


View Profile
December 18, 2016, 09:54:27 AM
Last edit: December 18, 2016, 11:26:53 AM by Rols
 #192

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 Offline

Activity: 2254
Merit: 1290



View Profile WWW
December 18, 2016, 01:13:09 PM
 #193

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
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
Rols
Hero Member
*****
Offline Offline

Activity: 636
Merit: 500


View Profile
December 18, 2016, 02:11:12 PM
Last edit: December 18, 2016, 02:26:16 PM by Rols
 #194

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
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


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.  Smiley
So it looks good. You are doing a great job.

It usually the longest chain that should win.
gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1290



View Profile WWW
December 18, 2016, 03:02:34 PM
 #195

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 Offline

Activity: 172
Merit: 100


Developer at TheCryptoChat


View Profile WWW
December 18, 2016, 03:10:31 PM
 #196

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 Offline

Activity: 2254
Merit: 1290



View Profile WWW
December 18, 2016, 03:32:15 PM
 #197

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.0

Cheers

Graham
ArchitektoR
Full Member
***
Offline Offline

Activity: 227
Merit: 103


View Profile
December 18, 2016, 08:00:33 PM
 #198

Sorry to say, but Windows version still crashes when mining:

Rols
Hero Member
*****
Offline Offline

Activity: 636
Merit: 500


View Profile
December 18, 2016, 08:46:05 PM
 #199

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 Offline

Activity: 2254
Merit: 1290



View Profile WWW
December 18, 2016, 08:46:58 PM
 #200

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
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ... 159 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!