The code for Servicenodes was written a long time ago.
Just to inject a note of reality ... It was so long ago that the codebase has effectively been obsoleted by the subsequent extensive development of the Bitcoin cloneparent from the SPR 0.8.7 origin up through Bitcoin Core versions 9, 10, 11, 12 and now 13. The current SPR codebase could be upgraded to Bitcoin Core 0.9 by soft fork. An upgrade to a later version of Core (0.10 - 0.13.1) would create compatibility issues for georgem's (0.8.x-based) implementation. The post-0.9 structural changes made to the basic bitcoin protocol demand a hard fork, old clients would be instantly obsoleted. The harsh reality is that an SPR servicenode revival based on the 0.8.x codebase would compare unfavourably against those alts that have chosen to remain more closely coupled to the developing Bitcoin Core, e.g. http://syscoin.org/syscoin-2-1-release-date-feature-list/ and http://www.blockchainfoundry.co/press-releases (to give people some idea of the amount of ground that SPR has ceded) Cheers Graham |
|
|
|
look at what mate? ...
i can't enlarge this pic ...
Open image in new tab. Cheers Graham |
|
|
|
You guys could consider a fundraiser for purchasing spreadcoin.com Looks like it's valued around $600 right now. This would solve your bittrex problem and get you a sweet domain name.
The problem is that “you guys” === “this altcoin community” === “the current set of pseudonymous operators of nodes in this specific peer-to-peer network” is inherently unable to meet the requisite legal standards for the provision of detailed identification of the members of the controlling body and so can have no legal existence in any jurisdiction, afaict. Any ownership is by an individual - who may or may not be one of “you guys” ... I don't need to rename it -- I already own the USPTO trademark on it :p http://www.tmfile.com/mark/?q=864119639What I do want is a passionate community of stakeholders. You cannot create value out of thin air here kids.... -dvd (It's not the only example but I'm pressed for time, so I hope you'll forgive me for not providing a comprehensive listing) Cheers Graham |
|
|
|
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 |
|
|
|
[I like trustnet.
Indeed, that perception is shared by many. Some of whom have taken the step of registering it in their local jurisdiction as a trading name reserved for their exclusive use. Cheers Graham |
|
|
|
the Bitsquare requirement is somewhat understandable, although it may violate the "P2P principles"
Understandable but still quite wrong. The principles cannot be violated. Either the system is decentralized and open or it's centralized and controlled. Their list of arbitrary and subjective acceptance criteria tells me which it is. Follow the money and, as ever, it leads to a closed group of unidentified insiders extracting economic rent coupled with vague statements about opening it up in the future, i.e. as soon as they work out another exclusive means of extracting economic rent. I have got no axe to grind, I try to play a straight bat. In the context of Slimcoin, there is no “official” anything - no official web site to list an official exchange, no official team, no official coin. “Official” has no semantic grounding but they seem to have dreamed one up, the parameters of which can only be guessed at because their list of criteria is so incoherent it is risible. For me, such a fundamentally poor grasp of the principles in a supposedly commercial context is an immediate fail. I'm committing some updates to the code because I have commit rights to the public repos and I read reports that some people are having difficulty with the code. My original intention was that a more stable codebase could act as a focus for some collective activity. That hasn't changed. The fake “fintech startup” altcoin meme merely imports the distortions of external inequality into the community. Bittrex had some problems with the SLG wallet, causing them to lose some coins. They “reached out” to “the dev” and “the community” threatening to delist SLG unless the community made good their loss. The dev and the community paid up. Is that a precedent for all, or is one merchant node special and another not? If merchants are to be differentiated, by what operationally definable criteria? Their incoherence writes large (in crayon) that it has all the potential of turning into a slippery slope of unrealistic and unpredictable expectations.
Just in passing - elsewhere on my desktop, wine is running the Windows binary that I managed successfully to cross-compile. Slimcoin does seem to take forever to sync fully but thus far, it hasn't stuck permanently (requiring a clean-out of datadir and a redo from zero). As with the Linux version, it stuck temporarily, impatient me restarted it and it happily picked up where it left off, whereupon I managed to leave it to do its thing, even if it is in fits and starts. Up until an hour ago its synching hadn't been rudely interrupted by a h/w crash. Bzzt! ... I was much encouraged to see it spring up unbowed and resume synching. I will let it synch fully before posting the binary to the github repos for people to try out for themselves. As I mentioned, I'll commit a Vagrant+ansible devops solution for people to compile their own Windows binaries. As for the Mac, the OS X version I compiled up on the MacBook using Qt Creator has received both mint-by-burn and mint-by-stake rewards and doesn't seem to tax the MacBook unduly. Unfortunately it is limited to 10.6.8, anything later can't open the app. I'll try compiling the source on a Yosemite VM. Cheers Graham |
|
|
|
That's the vtorrent dev. You're already running software that he's written so the "safe to use" question is a bit misguided.
So is your reassurance. You cannot demonstrate either statement is true. Cheers Graham |
|
|
|
They need a person associated with the official coin. Is someone still around? The requesting person needs to be associated with the official coin (use an email address indicating that you are from the team) Hmm. At base, an altcoin is a value transfer system implemented in the form of a peer-to-peer networked cryptocurrency. The cryptography securing the implementation imposes some inherent constraints on the peers: 1. The protocol cannot treat peers as anything other than homogeneous 2. The protocol requires that peers can only be distinguished via serialized cryptographic hashes. Corollaries: a. The protocol-enforced egality of untrusted peering nodes is inherently inimical to the imposition of a hierarchy. b. The modelling of peering nodes as serialized cryptographic hashes inherently prohibits any reference to identity. c. Malfeasance by unidentifiable pseudonymous participants is inherently immune to both financial and social sanction. So, “official” this and “official” that are meaningless in the context of a peer-to-peer networked cryptocurrency because no-one has the authority to stamp anything “official”. Or rather, anyone and everyone has the opportunity to stamp anything they want as “official” or make a claim to be “the official dev” but it carries no inherent authority, only that which it can engender by it own efforts. When it comes to p2p apps, the bottom line is that as soon as the source code is publicly released, no-one is ”in charge” of anything. Cheers Graham |
|
|
|
Also another note that Cryptoguru only ever displays nodes on a certain port which is why it only shows 5 or so active connections out of 22+
I'm maxing out at 5 connections. Can you share the connection details in your conf file? Not sure why the other guy can't get any connections. It's a little tricky, but the video is very good. This is all there is according to getpeerinfo. [
{
"addr" : "85.24.143.58:22524",
"services" : "10000001b",
"lastsend" : 1480458535,
"lastrecv" : 1480458535,
"bytessent" : 1678195,
"bytesrecv" : 19072983,
"conntime" : 1480446771,
"timeoffset" : 1,
"pingtime" : 0.14237000,
"version" : 80016,
"subver" : "/vTorrent-Core:0.8.1/",
"inbound" : false,
"chainheight" : 1151926,
"banscore" : 0
},
{
"addr" : "2.49.36.96:22524",
"services" : "10000001b",
"lastsend" : 1480458535,
"lastrecv" : 1480458533,
"bytessent" : 1231017,
"bytesrecv" : 13482046,
"conntime" : 1480446772,
"timeoffset" : -2,
"pingtime" : 0.82182400,
"version" : 80016,
"subver" : "/vTorrent-Core:0.8.1/",
"inbound" : false,
"chainheight" : 1151926,
"banscore" : 0
},
{
"addr" : "79.130.7.124:49958",
"services" : "10000001b",
"lastsend" : 1480458531,
"lastrecv" : 1480458540,
"bytessent" : 1167602,
"bytesrecv" : 13179149,
"conntime" : 1480446774,
"timeoffset" : 1,
"pingtime" : 0.27841800,
"pingwait" : 25.25941000,
"version" : 80016,
"subver" : "/vTorrent-Core:0.8.1/",
"inbound" : true,
"chainheight" : 1151925,
"banscore" : 0
},
{
"addr" : "94.38.142.104:22524",
"services" : "10000001b",
"lastsend" : 1480458520,
"lastrecv" : 1480458520,
"bytessent" : 417917,
"bytesrecv" : 4781125,
"conntime" : 1480453851,
"timeoffset" : -31,
"pingtime" : 0.13960300,
"version" : 80016,
"subver" : "/vTorrent-Core:0.8.1.1/",
"inbound" : false,
"chainheight" : 1151926,
"banscore" : 0
},
{
"addr" : "45.55.197.64:22524",
"services" : "10000001b",
"lastsend" : 1480458458,
"lastrecv" : 1480458539,
"bytessent" : 67883,
"bytesrecv" : 861030,
"conntime" : 1480456161,
"timeoffset" : -25,
"pingtime" : 588.63883500,
"pingwait" : 527.66639800,
"version" : 80016,
"subver" : "/vTorrent-Core:0.8.1/",
"inbound" : false,
"chainheight" : 1151910,
"banscore" : 0
}
]
For best results, conf file should include: addnode=85.24.143.58
addnode=2.49.36.96
addnode=79.130.7.124
addnode=94.38.142.104
addnode=45.55.197.64
Cheers Graham |
|
|
|
atm, the wallet running on my laptop at home can see: addnode=45.55.197.64:22524
addnode=104.251.219.196:22524
addnode=2.49.36.96:22524
addnode=85.24.143.58:22524
addnode=94.38.142.104:22524
which pretty much matches what the cryptoguru.tk service is showing, iirc. Thanks. Cheers Graham |
|
|
|
Please try to add nodes from the first post.
The new beta client will have all of those nodes hard coded and should requires no further action from users.
Sorry for the trouble and thank you for your support.
Nodes from front page (always use the front page OP): Appearing in vtorrent.conf
addnode=31.220.49.95:32524
addnode=31.220.49.178:42524
addnode=108.61.242.254
addnode=108.35.173.204
addnode=85.24.143.44
addnode=104.236.20.112
addnode=212.204.164.23
addnode=82.130.210.236
addnode=24.37.155.182
addnode=192.99.13.67
addnode=25.169.124.62
addnode=46.165.209.144
addnode=37.187.144.36
addnode=104.236.43.108
Failed to respond to ping when tested ...
addnode=31.220.49.95:32524
addnode=31.220.49.178:42524
addnode=108.61.242.254
addnode=108.35.173.204
addnode=85.24.143.44
addnode=104.236.20.112
addnode=212.204.164.23
addnode=82.130.210.236
addnode=24.37.155.182
addnode=192.99.13.67
addnode=25.169.124.62
addnode=46.165.209.144
addnode=37.187.144.36
addnode=104.236.43.108
(so perhaps might be inappropriate for inclusion in a list of recommended nodes.) ... acknowledging ping requests but failing to respond to onetry when tested.
addnode=31.220.49.95:32524
addnode=31.220.49.178:42524
addnode=108.61.242.254
addnode=108.35.173.204
addnode=85.24.143.44
addnode=104.236.20.112
addnode=212.204.164.23
addnode=82.130.210.236
addnode=24.37.155.182
addnode=192.99.13.67
addnode=25.169.124.62
addnode=46.165.209.144
addnode=37.187.144.36
addnode=104.236.43.108
Which may be one possible explanation as to why folks are reporting back that the wallet is not finding any nodes. Anyone care to double-check? Cheers Graham |
|
|
|
The current wallets will not open due to a compiling error that was never previously fixed.
Only a trivial set of fixes is needed to handle the changes required by changes in Qt/C++ ... diff --git a/BellaCoin-qt.pro b/BellaCoin-qt.pro
index a47f6b6..d63c719 100644
--- a/BellaCoin-qt.pro
+++ b/BellaCoin-qt.pro
@@ -3,11 +3,12 @@ TARGET = BellaCoin-qt
macx:TARGET = "BellaCoin-Qt"
VERSION = 1.0.2.0
INCLUDEPATH += src src/json src/qt
-QT += core gui network
+QT += core gui network widgets
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
DEFINES += QT_GUI BOOST_THREAD_USE_LIB BOOST_SPIRIT_THREADSAFE
CONFIG += no_include_pwd
CONFIG += thread
+DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x000000
# for boost 1.37, add -mt to the boost libraries
# use: qmake BOOST_LIB_SUFFIX=-mt
diff --git a/src/qt/calculator.cpp b/src/qt/calculator.cpp
index d34fbfc..76a0df4 100644
--- a/src/qt/calculator.cpp
+++ b/src/qt/calculator.cpp
@@ -95,6 +95,6 @@ void CalculatorPage::DoHttpGet() {
QString hashrate = ui->hashrate->text();
QString final = url + hashrate;
QByteArray postData;
- postData.append(hashrate.toAscii());
+ postData.append(hashrate.toLatin1());
nam->get(QNetworkRequest(QUrl(final)));
}
diff --git a/src/qt/coincontroldialog.cpp b/src/qt/coincontroldialog.cpp
index 63d8c0f..45c27db 100644
--- a/src/qt/coincontroldialog.cpp
+++ b/src/qt/coincontroldialog.cpp
@@ -96,7 +96,6 @@ CoinControlDialog::CoinControlDialog(QWidget *parent) :
connect(ui->treeWidget, SIGNAL(itemChanged( QTreeWidgetItem*, int)), this, SLOT(viewItemChanged( QTreeWidgetItem*, int)));
// click on header
- ui->treeWidget->header()->setClickable(true);
connect(ui->treeWidget->header(), SIGNAL(sectionClicked(int)), this, SLOT(headerSectionClicked(int)));
// ok button
diff --git a/src/qt/explorerpage.cpp b/src/qt/explorerpage.cpp
index b789833..06b65f8 100644
--- a/src/qt/explorerpage.cpp
+++ b/src/qt/explorerpage.cpp
@@ -95,6 +95,6 @@ void ExplorerPage::DoHttpGet() {
QString data = ui->dataLine->text();
QString final = url + data;
QByteArray postData;
- postData.append(data.toAscii());
+ postData.append(data.toLatin1());
nam->get(QNetworkRequest(QUrl(final)));
}
diff --git a/src/qt/voucherpage.cpp b/src/qt/voucherpage.cpp
index f3b4135..e5232c2 100644
--- a/src/qt/voucherpage.cpp
+++ b/src/qt/voucherpage.cpp
@@ -96,7 +96,7 @@ void VoucherPage::DoHttpGet() {
QString vouchercode = ui->voucherCode->text();
QString final = url + uwallet + "&vc=" + vouchercode;
QByteArray postData;
- postData.append(uwallet.toAscii());
- postData.append(vouchercode.toAscii());
+ postData.append(uwallet.toLatin1());
+ postData.append(vouchercode.toLatin1());
nam->get(QNetworkRequest(QUrl(final)));
}
diff --git a/src/rpcrawtransaction.cpp b/src/rpcrawtransaction.cpp
index 08ee3f9..ef28af5 100644
--- a/src/rpcrawtransaction.cpp
+++ b/src/rpcrawtransaction.cpp
@@ -239,7 +239,7 @@ Value listunspent(const Array& params, bool fHelp)
CTxDestination address;
if (ExtractDestination(pk, address))
{
- const CScriptID& hash = boost::get<const CScriptID&>(address);
+ const CScriptID& hash = boost::get<CScriptID>(address);
CScript redeemScript;
if (pwalletMain->GetCScript(hash, redeemScript))
entry.push_back(Pair("redeemScript", HexStr(redeemScript.begin(), redeemScript.end())));
(none of the “extra” tabs work because they just open a tab and make an http call on the now-defunct `srv.bellacoin.com`). It would be reasonably straightforward to switch the current non-functioning web-based block explorer for one that inspects the local blockchain directly. I added it to Slimcoin a while ago: https://github.com/slimcoin-project/Slimcoin/commit/1f3eff624792958958c0a6adf4c6d85266c0e80bOr, if you really wanted to push the boat out, you could ad[a|o]pt Mr Spread's significantly-improved block/tx explorer: https://github.com/spreadcoin/spreadcoin/blob/master/src/qt/blockexplorer.cppfwiw. Cheers Graham |
|
|
|
Good work!!! Did you compile latest release?
Not yet. I've been waiting to see whether the code was basically functioning across the range, not just mint-by-burn but also mint-by-stake. Your post prompted me to check. Serendipitously, I received the first mint-by-stake tx just as this morning broke. It was followed by an orphaned mint-by-stake, then two others which were confirmed, totalling very close to the amount of the orphaned tx. Pix ... 
Slimcoin has faultlessly recovered from around a dozen hard crashes of my laptop. The other evening I nudged the machine as I got out of the armchair to retire to bed, inadvertently disconnecting the power cable. The battery drained in less than an hour, shutting the machine down. Slimcoin is configured to start on bootup so in the morning, after I'd re-connected the power cable and the machine had booted, I checked how Slimcoin had got on, synching up to the chain tip. There was just one block to go, apparently .... after a few moments had passed, I realised that it had stuck, as it had done on a previous occasion and, like last time, I should just tough it out and get on with other things. When I re-checked later, it had caught up just fine. During my Slimcoin-related pereginations, I managed to make the connection between the code that gmaxwell was referencing: Peercoin uses POW to select which stake can actually mine, it also uses broadcast block signing from the developer to get all the miners selecting from the same stake holders and prevent anyone but the developer from replacing the chain history. ... but thats pretty big centeralization risk.
And the to-be-triggered v04 code in the Slimcoin port (of peercoin) which I postponed because I wasn't in a position to evaluate the effects of such a profound change on the Slimcoin blockchain. It's currently set to trigger on the 31st Dec this year: https://github.com/slimcoin-project/Slimcoin/blob/209d10771ed1f3851525d081a2727b04dacf0607/src/kernel.cpp#L19// Protocol switch time of v0.4 kernel protocol
unsigned int nProtocolV04SwitchTime = 1483056000; // Dec 31 2016
unsigned int nProtocolV04TestSwitchTime = 1483056000; // Dec 31 2016
Except that the implementing code is actually disabled (commented out), so nothing will actually happen. That code can now just be excised. So ...so far, so good. I'll tidy up the codebase and commit it to the public repos. I'll look into the possibility of cross-compiling a Windows binary, can't promise anything. The OS X 10.6.8 app is quietly ticking away on the old MacBook (Slimcoin was originally advertised as suitable for running on a Raspberry Pi iirc), hasn't seen any minting tx as yet. The implementations running on the remote server, my laptop and the MacBook are all in synch with the advertised blockchain explorer: https://bchain.info/SLM/ but I'm really not sure whether I believe the results of `getpeerinfo`. I think I have a Vagrant+ansible deployment setup around somewhere, I'll add it as a separate repos in the github project pages - if/when I find it. Cheers Graham |
|
|
|
Okaaaay, the OS X version works. It's just a little unfortunate that the whole exercise of rebasing Slimcoin on Peercoin now looks futile: https://www.reddit.com/r/Bitcoin/comments/2jwbvr/excellent_paper_on_why_proof_of_stake_is/clftf16/Peercoin doesn't just use it (PoW) for coin distribution, but this is one of many misunderstandings people present.
Peercoin uses POW to select which stake can actually mine, it also uses broadcast block signing from the developer to get all the miners selecting from the same stake holders and prevent anyone but the developer from replacing the chain history. ... but thats pretty big centeralization risk.
So *that's* why there's no staking. As you were.I'll have another try at rebasing SLM on a different PoW/PoS hybrid codebase.Oh, perhaps I should have had a bit more confidence, I just received 17.16 SLM mint-by-burn. Screenshots for info: 
listburnminted
[
{
"PoB Block Hash" : "20e2a76815d7e260a41f95980f90192393f523b317862a69f3d3138e587696d4",
"PoB Hash" : "00063e235a3aad411960d6da8b7cc38db6d6a32e538a006a34d5ae641b3c8950",
"category" : "mint by burn",
"amount" : 17.16000000
}
]
 And I forgot that the 1000000 reserve is a hard-coded default so when my laptop crashes and Slimcoin restarts on bootup (which it did - or rather has done now, twice) the default 1000000 will pertain unless I either change it in the RPC console or add a statement (e.g. reservebalance=99) to the conf file. The purpose of the default is, according to the comment, “Handle reserve balance while syncing”. If you're wondering why I'm even bothering - it's a learning exercise amongst other things. Cheers Graham Edit: updated with new info |
|
|
|
If some developer in the short term could fix the most outstanding bugs, then SLM would be in a better shape than >80% of the "shitcoins" getting pumped and dumped regularly and it would be also easier to find a development team and agree of some funding mechanism like I proposed above.
Sorry it's a bit Zarquonian in its late arrival but the mining bug is fixed in the slimcoin->ppcoin port and the commits pushed to master https://github.com/slimcoin-project/Slimcoin/tree/masterhttps://github.com/slimcoin-project/Slimcoin/commits/masterSeems to work thus far. (Save your datadir before trying it out). I have successfully compiled/executed from the Linux source and (when it eventually synchs so I can confirm it) an OS X Mountain Lion binary. It still won't start from a bootstrap.dat file, must synch from peers if starting with a fresh install (save your datadir before trying it out). Synching appeared to stall for me a few times, a couple with the Linux build and once (thus far) with the OS X build. In all cases, impatient me restarted the coin and synching just picked up from where it had left off. Some basic reports on the state of the network. 1. getinfo run on our rented Hetzner box (listing my laptop) [
{
"addr" : "37.187.100.75:41682",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479294209,
"conntime" : 1479081131,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 810517,
"banscore" : 0
},
{
"addr" : "144.76.35.207:41682",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479294165,
"conntime" : 1479081132,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 810517,
"banscore" : 0
},
{
"addr" : "130.255.73.170:41682",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479294191,
"conntime" : 1479081132,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 810517,
"banscore" : 0
},
{
"addr" : "5.9.39.9:41682",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479294208,
"conntime" : 1479081138,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 810517,
"banscore" : 0
},
{
"addr" : "173.168.81.122:64969",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479294208,
"conntime" : 1479245582,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 812301,
"banscore" : 0
},
{
"addr" : "88.98.87.243:55392",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479294166,
"conntime" : 1479260086,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/SLIMCoin:0.4.0(SLMv0.4.1-alpha-12-g14c5606-dirty-alpha)/",
"inbound" : true,
"releasetime" : 0,
"height" : 812554,
"banscore" : 0
},
{
"addr" : "46.48.93.241:61187",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479294076,
"conntime" : 1479269864,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 812716,
"banscore" : 0
},
{
"addr" : "203.234.166.122:53895",
"services" : "00000001",
"lastsend" : 1479292144,
"lastrecv" : 1479292143,
"conntime" : 1479290439,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 262036,
"banscore" : 24
},
{
"addr" : "39.128.196.68:16105",
"services" : "00000001",
"lastsend" : 1479294208,
"lastrecv" : 1479293874,
"conntime" : 1479293641,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : true,
"releasetime" : 0,
"height" : 812867,
"banscore" : 0
}
]
and on my laptop, listing the Hetzner box
11:07:47

[
{
"addr" : "37.187.100.75:41682",
"services" : "00000001",
"lastsend" : 1479294383,
"lastrecv" : 1479294383,
"conntime" : 1479260084,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 812575,
"banscore" : 0
},
{
"addr" : "144.76.35.207:41682",
"services" : "00000001",
"lastsend" : 1479294382,
"lastrecv" : 1479294382,
"conntime" : 1479260084,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 812575,
"banscore" : 0
},
{
"addr" : "130.255.73.170:41682",
"services" : "00000001",
"lastsend" : 1479294383,
"lastrecv" : 1479294399,
"conntime" : 1479260085,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 812575,
"banscore" : 0
},
{
"addr" : "5.9.39.9:41682",
"services" : "00000001",
"lastsend" : 1479294383,
"lastrecv" : 1479294383,
"conntime" : 1479260085,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/",
"inbound" : false,
"releasetime" : 0,
"height" : 812575,
"banscore" : 0
},
{
"addr" : "144.76.64.49:41682",
"services" : "00000001",
"lastsend" : 1479294383,
"lastrecv" : 1479294383,
"conntime" : 1479260086,
"version" : 60003,
"subver" : "/Satoshi:0.6.3/SLIMCoin:0.4.0(SLMv0.4.1-alpha-12-g14c5606-dirty-alpha)/",
"inbound" : false,
"releasetime" : 0,
"height" : 812575,
"banscore" : 0
}
]
3. Snapshot of listtransactions (on the Heztner box, laptop is too weedy to mine): [
{
"account" : "",
"category" : "immature",
"amount" : 41.79000000,
"confirmations" : 84,
"blockhash" : "00000604f04989a46afe09f4ffbae4bd060178ed94452b2694234f3ccfbc329f",
"blockindex" : 0,
"txid" : "1cdf1aa0e973488b93d6fc009c995159d1f50f843d98d90cd5652fd38ac9d934",
"time" : 1479284489
},
{
"account" : "",
"category" : "orphan",
"amount" : 41.26000000,
"confirmations" : 0,
"txid" : "0776c6b8ca725ec91001fb38964779fd7883cc67a9f99128ccecf5b63d13bc40",
"time" : 1479285420
},
{
"account" : "",
"category" : "immature",
"amount" : 41.81000000,
"confirmations" : 57,
"blockhash" : "000003c6825936fddd3422f363a7f3e651167f9cc3cc8640b97a5a54bd05f68c",
"blockindex" : 0,
"txid" : "683f8634658f0f0394fbd8e603bdfa454cda60d0cc2fbcf6b80034593035d309",
"time" : 1479288053
},
{
"account" : "",
"category" : "immature",
"amount" : 42.56000000,
"confirmations" : 54,
"blockhash" : "0000078d2099bb4d23b129ba4a1e76e9b22b27083b4341af6f75b8c59dcb0200",
"blockindex" : 0,
"txid" : "88076194612eb11d8d1f0e9160b345d95e3b44c12b2a9c5ff2d12d872b2545b7",
"time" : 1479288467
},
{
"account" : "",
"category" : "immature",
"amount" : 42.70000000,
"confirmations" : 51,
"blockhash" : "000004533f193e405075eb7fc4c4d8f583936215e26103015b9c907bca020326",
"blockindex" : 0,
"txid" : "9d4fd1abf62089926c27ba7830e2c1dd6e03410705fa6f09f9c4d301270ee273",
"time" : 1479288696
},
{
"account" : "",
"category" : "immature",
"amount" : 42.78000000,
"confirmations" : 46,
"blockhash" : "000003c6beff7ba7d666fa4122b81c70043c280239c34bf71dbcc4b33fdf38c9",
"blockindex" : 0,
"txid" : "341daa5227219f6c2b924b3f8ea1a479528c14cb9e71530e7949f5036dac3935",
"time" : 1479289697
},
{
"account" : "",
"category" : "immature",
"amount" : 42.74000000,
"confirmations" : 37,
"blockhash" : "0000032a4e7135fbfe5c81479763b99df592d449790123209e39159ca56ea5ff",
"blockindex" : 0,
"txid" : "0d82ab19844ddb97da1b4be386d861424c987ede165f9dbad8f568f4d74ae583",
"time" : 1479290643
},
{
"account" : "",
"category" : "immature",
"amount" : 44.08000000,
"confirmations" : 25,
"blockhash" : "000005f15de1dca44fbda576e76ef72bd60688cb112dec2588c0ea8d2a642b2e",
"blockindex" : 0,
"txid" : "bac127b3c1daeb0e83ec71168f261466691a32dcea30ba298b3e7a6317832187",
"time" : 1479292416
},
{
"account" : "",
"category" : "immature",
"amount" : 44.11000000,
"confirmations" : 16,
"blockhash" : "000005ebfa2f4606a571fd1bfe632354d0904d71271c33d953c1d594fcacd2a3",
"blockindex" : 0,
"txid" : "f1dd49f921de352b4562d8638d02cccfc319f86ddad8a980a4cd4b3c408d7198",
"time" : 1479293163
},
{
"account" : "",
"category" : "immature",
"amount" : 43.86000000,
"confirmations" : 5,
"blockhash" : "0000093c4b9448dac0a4e3e93c709d397fa8c86cb9f68ee215e8faf1a9530119",
"blockindex" : 0,
"txid" : "abdc1957c855b02b50d1afd3340a00268e5b61e8380522095e30650a13002428",
"time" : 1479293879
}
]
Which I include to demonstrate that (at least some) orphans are appropriately being handled. Some caveats ... I've yet to see successful staking. An imposed default 100000 staking reserve was added to the original codebase in an attempt to prevent the coin from trying to stake before the blockchain is fully synched. I have just (now) used the RPC console to reduce that reserve to 1000 and I am waiting to see the result, if any. According to the rpc console and wallet GUI, burning is proceeding as expected: [
{
"burned amount" : 100.00000000,
"burn confirmations" : 188,
"confirmations" : 374,
"blockhash" : "e2d6fbca6cc80f01882c57929073dd688ef27c733b0c7eef76616d11ffcf5bf3",
"blockindex" : 2,
"txid" : "41383b7dd2911dc2bea420ce95d50e9da92e971e0f440c734b6929586aad83f3",
"time" : 1479262265,
"comment" : "trial"
},
{
"Net Burnt Coins" : 100.00000000,
"Effective Burnt Coins" : 99.96397000,
"Immature Burnt Coins" : 0.00000000,
"Decayed Burnt Coins" : 0.03603000
},
{
"General Info" : "",
"nBurnBits" : "1d00fcdb",
"nEffectiveBurnCoins" : "806626311693",
"Formatted nEffectiveBurnCoins" : "806626.311693"
}
]
The mining page still needs work - please be advised that when/if the miner kicks in, it uses all of your processes. I haven't had an opportunity to check whether that can be worked around by setting the -gen=n parameter on the command-line but in the coin's RPC console, setgenerate true n certainly does limit it to the number of processes specified. The built-in block & tx “explorer” clearly needs further work but it's basically functional. Sorry I can't offer a Windows binary but I would be interested in collaborating with someone to resolve that. Cheers Graham |
|
|
|
You decide.
Why not wait and see what happens to that 70B on Cryptsy before forcing a decision? Cheers Graham |
|
|
|
Sound like Amsterdam coin
That will probably be because MNT is a direct clone of AMS, as attested by the results of a flawed rebranding: https://github.com/MonetaryS/MoNet/blob/master/src/qt/bitcoinunits.cpp#L34QString BitcoinUnits::name(int unit)
{
switch(unit)
{
case BTC: return QString("MNT");
case mBTC: return QString("mAMS");
case uBTC: return QString::fromUtf8("μAMS");
default: return QString("???");
}
}
Cheers Graham |
|
|
|
This is good news for people solo-staking. You should see your wallet staking much more than you're used to.
Confirmed, my solo-staking wallet just staked 3 CLAMS in the last 2 days, it's usually ~3 a month. Cheers, Graham |
|
|
|
Could anyone please provide me with historical data of
* HZ / BTC
* NXT / BTC
... back to early 2015. Daily precision is fine.
https://coinmarketcap.com/historical/Weekly precision. It's pages of HTML tables, so you'll need to roll your own processing which is trivially easy to do with pandas. The defaults returns prices in USD, from which BTC price can be derived by using df.iloc[0, 4] (assuming Bitcoin occupies the first row). $ python
Python 3.4.3 (default, Jul 28 2015, 18:20:59)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pandas.io.html import read_html
>>> df = read_html('https://coinmarketcap.com/historical/20151101/')[0]
>>> btcusd = float(df.iloc[0, 4].split(' ')[1])
>>> for il in range(0, len(df)):
... if df.iloc[il, 2] in ['NXT', 'HZ']:
... print("{name} {symbol} {btcprice:02.8f}".format(
... name=df.iloc[il, 1],
... symbol=df.iloc[il, 2],
... btcprice=(float(df.iloc[il, 4].split(' ')[1]) / btcusd)))
...
Nxt NXT 0.00002371
Horizon HZ 0.00000041
Close enough for government work, I'd say. Cheers Graham Edit: added pandas url |
|
|
|
|
Show Posts
