Where is the SLMv0.4.1-alpha-46-g6fe14df-alpha build for windows, if any?
It's not significant, as yet. The only changes since before Christmas have been to the build system, not the running code. Might as well trot this one out for all to “enjoy”. If you want to d/l the source, make some changes, change the version number to something you find amusing, compile and use the result - that's entirely a matter for your good self. It all happens in src/version.h and src/version.cpp. // slimcoin version - intended for display purpose ONLY
#define SLIMCOIN_VERSION_MAJOR 0
#define SLIMCOIN_VERSION_MINOR 4
#define SLIMCOIN_VERSION_REVISION 0
#define SLIMCOIN_VERSION_BUILD 0
static const int SLIMCOIN_VERSION =
1000000 * SLIMCOIN_VERSION_MAJOR
+ 10000 * SLIMCOIN_VERSION_MINOR
+ 100 * SLIMCOIN_VERSION_REVISION
+ 1 * SLIMCOIN_VERSION_BUILD;
There's a wikipedia article on the subject of software versioning. If you've read it and understood it all, you're ahead of me. 0.4.0 is where we are, 0.4.1 is what will be released after this period of testing is complete. * gjhiggins makes a mental note to find time to learn how to make releases on github Cheers Graham P.S. The actual state of play on my m/c is (lightly edited for clarity): gjh@ashpool:$ grep -rn BUILD_DESC slimcoin-master
slimcoin-master/build/build.h:1:#define BUILD_DESC "SLMv0.4.1-alpha-46-g6fe14df"
slimcoin-master/src/version.cpp:45:#define BUILD_DESC_FROM_COMMIT(maj,min,rev,build,commit) \
slimcoin-master/src/version.cpp:48:#define BUILD_DESC_FROM_UNKNOWN(maj,min,rev,build) \
slimcoin-master/src/version.cpp:51:#ifndef BUILD_DESC
slimcoin-master/src/version.cpp:53:# define BUILD_DESC BUILD_DESC_FROM_COMMIT(SLIMCOIN_VERSION_MAJOR, SLIMCOIN_VERSION_MINOR, SLIMCOIN_VERSION_REVISION, SLIMCOIN_VERSION_BUILD, GIT_COMMIT_ID)
slimcoin-master/src/version.cpp:55:# define BUILD_DESC BUILD_DESC_FROM_UNKNOWN(SLIMCOIN_VERSION_MAJOR, SLIMCOIN_VERSION_MINOR, SLIMCOIN_VERSION_REVISION, SLMCOIN_VERSION_BUILD)
slimcoin-master/src/version.cpp:67:const std::string CLIENT_BUILD(BUILD_DESC CLIENT_VERSION_SUFFIX);
slimcoin-master/share/genbuild.sh:26: NEWINFO="#define BUILD_DESC \"$DESC\""
(and there's a remaining typo, right there - “SLMCOIN_VERSION_BUILD” - hint, scroll to the right). |
|
|
|
I have now ... linked the install instructions at the new README (thanks gjhiggins!).
I encourage people to report their experiences. I was more intent on creating working binaries than recording the process, so the detail might be incorrect in one or two places - and that's an important issue to be addressed when purportedly offering copynpasta build instructions. Also, some options in the slimcoin-qt.pro file are hard-coded at the moment, merely as a side effect of me not wanting to wrestle there'n'then with the interaction between environment variables, compilation and linking flags (aka, the “JBDI” [1] approach, which I'm known to adopt in increasingly short order these days). [1] Just bloody do it. Cheers Graham |
|
|
|
today i had a thought about how to solve the mining pools centralization tendency problem. will be glad for your thoughts:
Already implemented by “Mr Spread”, Spreadcoin dev - https://bitcointalk.org/index.php?topic=715435.0 Pool Prevention
To prevent pools each block must be signed with the private key which correspondents to the coinbase transaction. See whitepaper for more details.
ocminer developed a workaround for pool mining and was able to offer a Spreadcoin mining pool. Nevertheless, the technique seems to have provided some degree of protection from predation by algo-driven multipools and the “encouraged” (rather than “enforced”) decentralisation of mining did seem to be effective to the degree that the (original) distribution profile was more equably spread than is typical for alts. An adapted version of the technique is/was also employed by Ziftrcoin https://bitcointalk.org/index.php?topic=970363.0 - described more coherently in the README https://github.com/ZiftrCOIN/ziftrcoin. Cheers Graham |
|
|
|
For info: http://bitzuma.com/posts/op-return-and-the-future-of-bitcoin/Stealth addresses offer another example of OP_RETURN in action. This scheme enables payments to be received without publicly revealing the receiver's public key or address. Data needed to make this system work are encoded within a call to OP_RETURN. In essence, the coin does double duty as a secure messaging protocol.
Cheers Graham |
|
|
|
Thanks, sounds logical, I'll try that and let you know if it worked. So far, the Linux machine has minted 120SLM in one day. Rasbperry still loading the blockchain.
I augmented the Slimcoin README.md with the peercoin.net instruction on how to mint with an encrypted wallet. The raspberry pi should be able to read gavrilo77's mega-hosted copy of the files, they will be 4.8-based. Cheers Graham |
|
|
|
Any opinions on the locking / unlocking of the GUI client? It says "Minting suspended due to locked wallet." I don't know how to take this  Minting instructions are detailed here: https://peercoin.net/minting-guide1. Ensure your wallet is encrypted with a good passphrase. Write this down and keep it somewhere safe; if you forget the passphrase you will lose your coins. The wallet encryption option can be found under the settings tab in the Peercoin-Qt wallet program.
2. To start minting go to help -> debug window -> console and enter:
walletpassphrase abc 999999 true
where "abc" is your passphrase and "999999" is the time you want to mint for in seconds. You can change the amount of time to whatever you like, but it is usually easiest just to set it at a very high number. If your passphrase has spaces then enclose it in quotation marks.
3. Clear your passphrase by pressing Ctrl-L.
4. You can check you are minting by looking at the little padlock in the bottom right corner of the client. After a few moments it should become unlocked. If you hover your mouse over it, it should say "Wallet is encrypted and currently unlocked for block minting only".
Yes, it is a little unexpected. I'll take a look at the possibility of importing the corresponding peerunity code which apparently resolves the issue. (Doesn't redress the issue of decrypting the wallet tho'). Cheers Graham |
|
|
|
Also, the GUI client, how can you unlock it? On Mac OSX I can't find this option anywhere. Once locked, it just stays like that. As inherited, encryption of Slimcoin wallets is one-way: https://github.com/slimcoin-project/Slimcoin/blame/slimcoin/src/qt/bitcoingui.cpp#L855Probably, the only way out is to sequentially feed dumpprivkey with all the addresses in each account (making a note of the label and the privkey), closing the app, moving the wallet aside, re-starting the app and then sequentially feeding importprivkey with all the privkeys and labels. That should restore the wallet accounts, addresses and balances in the new, unencrypted wallet. Cheers Graham |
|
|
|
The staking is still disabled ?
If yes how to enable it again?
How to enable staking was described in an earlier post but that was some time back. I think it's conjecture rather than diagnosis but whatever ... Whilst syncing from 0, a wallet successfully staking before it is fully synced will create for itself a fork of the blockchain containing the newly-minted block at that point - e.g. at 12th August 2015 02:34:12, if that's how far the sync has gotten when the staking occurred (aiui). That basically borks the client until that forked blockchain data is expunged from datadir. As a workaround to prevent premature staking, a reserve of 1000000 was hard-coded into the client (and which I preserved in the migration). To enable staking in practice, either collect more than 1000000 SLM or, more frugally, add the following to slimcoin.conf: Cheers Graham |
|
|
|
Well, gave it a try again, and after 38 minutes, no luck... It's most likely something on my part.
Nothing on your part. It's a bad build. Ach. The app in that dmg was incorrectly linked to the BSD 4.8 lib instead of the 6.1 lib - which is why it couldn't open the addr.dat files created with BSD 6.1. Download fixed. Install, execute & synch all checked on OSX Sierra. Cheers Graham |
|
|
|
On the linux machine I entered slimcoin setgenerate true 8 (it's a maschine with 16 cores). From your experience, how long it takes until I get to mine a block?
I model it as a ratio of my hashrate to the network hashrate ... You can do the arithmetic yourself by interrogating the daemon, e.g. on my laptop: ./slimcoind setgenerate true 1
./slimcoind getmininginfo
{
"blocks" : 859396,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.01022192,
"errors" : "",
"generate" : true,
"genproclimit" : 1,
"hashespersec" : 387,
"networkghps" : 0.00019512,
"pooledtx" : 0,
"testnet" : false
}
Letting Python handle the expression of my hashespersec as a proportion of total networkghps: >>> 0.00019512 * 1000000000 / 387
504.1860465116279
I'm contributing one fivehundredth of the hash rate so on average I can expect somewhere around 1 block in 500. Slimcoin's block target rate is one block every 90 seconds, which is 40 an hour, so say 12 hours if I'm lucky and don't suffer too much latency from being out in the sticks. I am getting some vicarious satisfaction from the Snow Leopard version, quietly ticking away on a 2012 vintage MacBook known for overheating at the slightest excuse (like being placed on a lap, f'rinstance). I burned 250 SLM out its wallet and just parked it. Doesn't stake much at all but it does (irregularly) get mint-by-burn blocks - last month (Dec) it got five mint-by-burn blocks in total, ranging between 14-17 SLM per block. Also, in the GUI wallet, there's an option about mining? Is that thing doing anything atm?
Kind of. It exhibits the same problem as the others of its ilk (e.g. Chaincoin 0.9.2) in that settings don't appear to behave as expected/designed - when it can be persuaded to work it uses all cores+threads. When I get a round tuit, I'll raise an issue in the repos - if it hasn't already been raised. Ahhh. I found this post in the old thread: the post in which the OP outlines his intention to merge slimcoin with the peercoin codebase - just for context. My plans for the future: Slimcoin is a Peercoin fork. I tried to merge it with Novacoin before but Novacoin is too different of a project to be merged at this point. There is a project called Peerunity which is the more maintained and newer version of Peercoin. I will try to merge it into Slimcoin. I will obviously test the newly merged client but hopefully this merging will solve any bugs.
Cheers, Graham |
|
|
|
Thanks a lot! Deployed it on the linux node and works like a charm. Now I have to figure out where Slimcoin stores its blockchain on a Mac. I suspect ~Library or its neighbors. Edit: it worked like a charm on Mac too. I have two nodes now, let's see how I can mine/mint some slimcoins now . Thanks for your support, you've been very helpful!I'm relieved and glad it worked. For those following along at home, the default location for datadir on OS X is ~/Library/Application Support/SLIMcoin/. (On recent OSX versions, ~/Library is hidden by default in the Finder, the show/hide checkbox is in “View Options”). Cheers Graham |
|
|
|
Yep, I figured it out, installed Berkeley DB via brew, compiled it, launched. All good. Now I need a blockchain Thanks for the info. Received wisdom holds that a straight copy of the blockchain files is readable cross-platform. If you want a short cut, here's a copy I made just now. I *think* OSX has zip/unzip. If not shout out and I'll add a gzipped tarball: https://minkiz.co/noodlings/slm/slm-datadir-blockfiles.zip
$ unzip -l slm-datadir-blockfiles.zip
Archive: slm-datadir-blockfiles.zip
Length Date Time Name
--------- ---------- ----- ----
444220984 2017-01-02 16:37 blk0001.dat
536477696 2017-01-02 16:37 blkindex.dat
0 2017-01-02 16:33 database/
10485759 2017-01-02 16:39 database/log.0000003076
--------- -------
991184439 4 files
Gzipped tarball (same contents as zip file) at:
https://minkiz.co/noodlings/slm/slm-datadir-blockfiles.tar.gz
(572Mb to d/l) Edit: tarball added (see above)Cheers Graham |
|
|
|
Well, gave it a try again, and after 38 minutes, no luck... It's most likely something on my part.
Nothing on your part. It's a bad build. Hidden behind the exuberant splash screen lurks a hidden dialog box reporting a BDB error. (Turn off the splash screen with splash=0 either in config or command-line arg.) I'll fire up the Sierra VM, see if I can guess what I did wrong. Edit: But not before setting up that cron jobAha, a hint. While the daemon was halted, I checked the server's db.log: BDB2506 file addr.dat has LSN 277/7510668, past end of log at 1/28
BDB2507 Commonly caused by moving a database from one database environment
BDB2508 to another without clearing the database LSNs, or by removing all of
BDB2509 the log files from a database environment
That's the cause of the problem, I reckon. Next step is understand precisely what the log message means. Cheers Graham |
|
|
|
Got rid of that error, now it stops at make:
an easy one ... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
clang: warning: no such sysroot directory: '/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk'
Xcode 8.2 hadn't been released at the time, the pre-release installed as Xcode-beta. Re-pull from github, I just edited the slimcoin-qt.pro file: https://github.com/slimcoin-project/Slimcoin/commit/c0b4466bb891b71c4f74d1dc33f676a7b48a70efCheers Graham |
|
|
|
If you updated the sources to work with QTWebengine that would be great. My compilation stops at "Project ERROR: Unknown module(s) in QT: webkit webkitwidgets".
It isn't much of a change per se, just a tweak to the QT config settings. The error report sounds promising in that webkit was removed in Qt 5.6 iirc, so it looks like you have Qt5.6/7 installed. What is the latest source for Slimcoin OSX?
In the “master” branch of https://github.com/slimcoin-project/SlimcoinSee the README (c.f. my caveat about the OSX build instructions being from memory, not actual note-taking, you might want to try allowing brew to first install the Qt binaries, see if that works for you).NB: above repos properly has “slimcoin” (last released version) as default branch. To use the most recent (as yet unreleased) version, checkout and compile the “master” branch. I couldn't be arsed to muck about with the png used for the dmg finder window background image, it still says “Bitcoin”. Fortunately, the latest Bitcoin Core's contrib/macdeploy offers an opportunity for theft er, adaptation. Cheers Graham |
|
|
|
Thank you, appreciate that.
Any thoughts about webkit and webkitwidgets issue for qt 5.7?
I used the Qt5.7 binaries from Stevan Binner's qt57 ppa for my Linux app, the Windows build uses the MXE qt binary (which is 5.7, I *think*) and I have updated the source to use QWebEngine/QWebEngineWidgets on Qt 5.7 by default. (I was trying to get a reliable foundation for tackling the halting problem with the Linux client). The build instructions for OSX in the README are from memory. I seem to recall that it was “merely” a matter of homebrew-installed bottles and kegs. I repeatedly tried to compile Qt from source but every attempt was ultimately thwarted by a laptop crash, so I infer that in the end, I simply installed the binaries - which would be Qt5.7, I guess. I'd need to start the OS X Sierra VM to check. Which I will do sometime this week, uninstall brew, wipe its footprint and re-do the build from start, making more accurate/precise notes of each build step. * gjhiggins will try to remember to set up a cron job to publish a copy of the blockchain files at midnight each day. Cheers Graham |
|
|
|
Well, gave it a try again, and after 38 minutes, no luck... It's most likely something on my part.
I'll ask Ngaio if she would be kind enough to d/l the latest OSX binary to her MB and check its operation. The OSX binary was compiled on Sierra, for Sierra and its operation has only been checked on OSX Sierra. Cheers Graham |
|
|
|
@gjhiggins: Do you operate a Linux version of 0.4.1 and does it sync without getting stuck from the beginning?
Yes to both questions. I haven't been able to replicate the “gets stuck whilst synching from the network” issue. (I haven't made any progress on creating a reliable bootstrap.dat file. It's not on the top of my stack because it's a bit of a nuance in view of several unchallenged reports of cross-platform success obtained merely by copying the blockchain files from one datadir to another.)I'm also considering deleting the word "Official" from the thread title.
Can I suggest “Mainstream” as a replacement? It's a reasonable claim to make; afaik, this bitcointalk thread is the only remaining active public discussion forum for the coin. I recompiled the Windows and OSX binaries with the “optimisation” flag set (-O3) and have refreshed the downloads available from https://minkiz.co/noodle/9 Dunno whether it'll make much difference to the mining hashrate, tho. I also changed the diffplot so that the chart is a little easier to read. Happy holidays to all Happy calendarial modulus, hope you make the most of the extra second. Cheers Graham |
|
|
|
My issues arise when I try to cross-compile the QT wallet for windows using MXE.
I've had success with MXE cross-compilation by adding the MXE ppa deb http://pkg.mxe.cc/repos/apt/debian wheezy main to my apt-sources, installing the appropriate cross-compiler bundle and all the pre-compiled packages: boost, qt, libqrencode, miniupnpc.  I doubt whether I actually hand-selected every single installed package, I probably selected a bundle but I had a very sketchy model of the cross-compilation process at the time, so was sort of stabbing around in blind optimism (yes, it does sometimes pay off) and don't exactly recall what I did - other than, at the end of the exercise, I had a richly-populated /usr/lib/mxe/usr/lib folder which does the biz. It also has the useful side-effect of obviating the cross-compilation of the upnp & qrencode support libs. I have this for cross-compiling SLIMCoin: #!/bin/bash
# Working setup to cross-compile Windows binaries for Slimcoin hosted on a
# Vagrant Ubuntu 16.04 VM using non-Canonical ppas for MXE and Qt5.7:
# deb http://pkg.mxe.cc/repos/apt/debian wheezy main
# Doesn't seem to pass the QT directives through, though. Tough.
# Basic path bindings
PATH=/usr/lib/mxe/usr/bin:$PATH
MXE_PATH=/usr/lib/mxe
MXE_INCLUDE_PATH=/usr/lib/mxe/usr/i686-w64-mingw32.static/include
MXE_LIB_PATH=/usr/lib/mxe/usr/i686-w64-mingw32.static/lib
# Belt and braces
CXXFLAGS="-std=gnu++11 -march=i686"
LDFLAGS="-march=i686"
target="i686-w64-mingw32.static"
# Particularise for cross-compiling
export BOOST_LIB_SUFFIX=-mt
export BOOST_THREAD_LIB_SUFFIX=_win32-mt
export BOOST_INCLUDE_PATH=${MXE_INCLUDE_PATH}/boost
export BOOST_LIB_PATH=${MXE_LIB_PATH}
export OPENSSL_INCLUDE_PATH=${MXE_INCLUDE_PATH}/openssl
export OPENSSL_LIB_PATH=${MXE_LIB_PATH}
export BDB_INCLUDE_PATH=${MXE_INCLUDE_PATH}
export BDB_LIB_PATH=${MXE_LIB_PATH}
export MINIUPNPC_INCLUDE_PATH=${MXE_INCLUDE_PATH}
export MINIUPNPC_LIB_PATH=${MXE_LIB_PATH}
export QMAKE_LRELEASE=${MXE_PATH}/usr/${target}/qt5/bin/lrelease
# Call qmake to create Makefile.[Release|Debug]
${target}-qmake-qt5 \
MXE=1 \
USE_O3=1 \
USE_QRCODE=1 \
FIRST_CLASS_MESSAGING=1 \
RELEASE=1 \
USE_UPNPC=1 \
BOOST_LIB_SUFFIX=${BOOST_LIB_SUFFIX} \
BOOST_THREAD_LIB_SUFFIX=${BOOST_THREAD_LIB_SUFFIX} \
BOOST_INCLUDE_PATH=${BOOST_INCLUDE_PATH} \
BOOST_LIB_PATH=${BOOST_LIB_PATH} \
OPENSSL_INCLUDE_PATH=${OPENSSL_INCLUDE_PATH} \
OPENSSL_LIB_PATH=${OPENSSL_LIB_PATH} \
BDB_INCLUDE_PATH=${BDB_INCLUDE_PATH} \
BDB_LIB_PATH=${BDB_LIB_PATH} \
MINIUPNPC_INCLUDE_PATH=${MINIUPNPC_INCLUDE_PATH} \
MINIUPNPC_LIB_PATH=${MINIUPNPC_LIB_PATH} \
QMAKE_LRELEASE=${QMAKE_LRELEASE} slimcoin-qt.pro
# Go for it. If successful, Windows binary will be written out to ./release/slimcoin-qt.exe
make -f Makefile.Release CXXFLAGS="-DQT_GUI -DQT_NO_PRINTER -std=gnu++11 -march=i686" LDFLAGS="-march=i686"
Oh, one last thing - all of the above assumes a VM with build-essentials, etc already apt-installed. HTH, Cheers Graham |
|
|
|
I've never yet managed to get Slimcoin to read a bootstrap file successfully on any platform.
Arrgh. Such sloppy thinking. Never even checked whether the folklore cat blk* > bootstrap.dat is actually efficacious. TIL how to create a bootstrap.dat file: https://github.com/bitcoin/bitcoin/tree/master/contrib/linearizeLinearize
Construct a linear, no-fork, best version of the blockchain.
Sounds promising - except that it doesn’t work out of the box with Slimcoin’s elderly JSON-RPC API and it's unconverted from Python 2.7 (sigh). What does work, perhaps not-unexpectedly if you think hard enough about it, is gavrilo77's SLIMCoin.rar file https://mega.nz/#!XscB0RbQ!R3FJxDyYEK65ilqlGKf9tmahAwkysh5xm6lw5SpIuZAStrictly speaking, it's not a “bootstrap.dat” in that it is a packaged copy of the relevant elements of the datadir folder. gjh@ashpool:~$ rar l ~/Downloads/SLIMCoin.rar
RAR 5.30 beta 2 Copyright (c) 1993-2015 Alexander Roshal 4 Aug 2015
Trial version Type RAR -? for help
Archive: /home/gjh/Downloads/SLIMCoin.rar
Details: RAR 4
Attributes Size Date Time Name
----------- --------- ---------- ----- ----
..A.... 80856 2015-02-08 18:54 database/log
..A.... 10485760 2015-09-29 17:31 database/log.0000000001
..A.... 10485760 2016-12-25 11:07 database/log.0000027834
..A.... 10496000 2015-02-08 18:54 database/log~
..A.... 534708224 2016-12-25 11:04 blkindex.dat
..A.... 445270627 2016-12-25 11:04 blk0001.dat
...D... 0 2016-12-25 11:07 database
----------- --------- ---------- ----- ----
1011527227 7
(which I include so everyone is sharing the model) I checked and it worked for my wine-hosted SLIMCoin.exe. And, after repackaging as a tar.gz archive (because I couldn't be arsed hunting down a copy of rar) and copying across to the Sierra VM, also works for the SLIMCoin.app OSX binary. I will check that the package also works for the Linux app and if I can create one under Linux that also works universally, I'll configure the server to publish a daily downloadable package. Edit: As ArchitektoR observes, it also works for Linux, as I just found out.. BTW, refreshed windows binary and OSX binaries (one for bdb4.8 wallet and one for bdb6.1) are on: https://minkiz.co/noodle/9Cheers Graham |
|
|
|
|
Show Posts
