You do realized your rudeness just cost sprouts all of their trading pairs on Cryptopia.
Welcome to Fantasy Island. Cheers Graham |
|
|
|
im a rhel fella - and NO i dont want you to feel sorry me ... i actually like the os - whether ive submitted to it or not ...
Hm, it would be useful to cover an rpm-based solution as well as the apt-based one - meet halfway? CentOS? Cheers Graham |
|
|
|
im also looking for a 'decent' way to compile ( or cross compile if that is a good way ) windows and osx binaries for the coins we have
im looking for a much more simplified way of doing this ... any hints or links or just outright step by step instructions
Herewith markdown-formatted destructions from the Slimcoin README:
## Ubuntu-hosted cross-compilation of Windows 32bit binary
### Installing the [MXE](http://pkg.mxe.cc/) cross-compilation tool.
Make the distribution ppa known to the APT package system:
$ echo "deb http://pkg.mxe.cc/repos/apt/debian wheezy main" > \
/etc/apt/sources.list.d/mxeapt.list
Add the GPG key to the APT package system:
$ apt-key adv --keyserver keyserver.ubuntu.com --recv-keys D43A795B73B16ABE9643FE1AFD8FFF16DB45C6AB
Update the APT cache:
$ apt-get update
Install some MXE package:
$ apt-get install mxe-i686-w64-mingw32.static-qt
Names of packages are `mxe-<target>-<package>`.
Possible targets:
> - i686-w64-mingw32.static
> - x86-64-w64-mingw32.static (note that `_` replaced with `-`)
> - i686-w64-mingw32.shared
> - x86-64-w64-mingw32.shared (note that `_` replaced with `-`)
*(A complete list of packages can be found on the [MXE site](http://mxe.cc/#packages) and in [the build matrix](http://mxe.cc/build-matrix.html).)*
Packages are installed to `/usr/lib/mxe/<target>/`. The location acts as the root of the MXE source tree.
For example, cross-compile CMake project:
$ target=i686-w64-mingw32.static
$ mxedir=/usr/lib/mxe/
$ $mxedir/usr/bin/$target-cmake project-source
$ make
### 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"
The cross-compilation product is saved in the `release` directory under the name `slimcoin-qt.exe` and can be tested on Ubuntu with:
$ wine release/slimcoin-qt.exe
*(be prepared for a long wait during the loading of the index, e.g. 15-20 mins on a low-end machine)*
Once the MXE distro is installed, copy the bash script into xcomp.sh and just run that whenever required. It has proved reasonably general in that I have been able to just edit the target in order to use the script to produce a Windows binary for a different coin. BTW, the README also contains destructions for native compilation on OS X Sierra, it requires brew and XCode but otherwise fairly straightforward and works as expected on an Ubuntu 17.04-hosted VirtualBox OS X Sierra VM (which fortuitously happily upgraded itself from an El Capitan distro I managed to get my hands on). And similarly, my intention to tackle gitian deterministic builds is awaiting a fresh supply of round tuits  Cheers Graham |
|
|
|
Just a thought, ask them what value they have assigned to reservebalance.
Mmm. Looks like Cryptopia's wallet is staking: https://bitcointalk.org/index.php?topic=1798901.msg18471814#msg18471814So yes, numpties. I expect that if they set reservebalance=10000000 in the config or even set -reservebalance=10000000 on the command line, their client will remain stable. But, given their unhelpful response to a legit customer enquiry, I don't hold out much hope that any of the Cryptopia staff are motivated to do anything helpful. At present, this is an educated guess - if someone with SPRTS deposited on Cryptopia can confirm that the coins have recently staked at their Crytopia deposit address, that would dispel the uncertainty (there's an explorer URL quoted a couple of posts after the one I've referenced above).We seem to have an answer. The problem that Cryptopia is experiencing with the Sprouts client is localised to them and is due to their own ineptitude in failing to configure the client's operation for use on an exchange. Cheers Graham |
|
|
|
interesting ...
is this still viable? ...
#crysx
Seems to depend on which coin and from which version of Bitcoin it was cloned: https://github.com/p2pool/p2pool/issues/341These days it would probably be more effective to cast the process into a “devops” solution. Personally, I quite like a combo of Vagrant and Ansible, f'rinstance this is an Ansible playbook for creating an Ubuntu 16.04 VM and cross-compiling a Windows binary for Slimcoin. Cheers Graham |
|
|
|
isnt there a way to revive a coin even if devs are not involved? I am interested in knowing how that can happen.
Here you go: https://github.com/pnut-coin/pnutJust clone the source and compile it. It's your choice whether to try and find a copy of the original blockchain (and potentially be in conflict with an existing consensus of which you are unaware) or to make a trivial change to the configuration and generate a new blockchain. Now copy the binary to a VM, point the natively-hosted client at the vm-hosted client and vice versa, turn on setgenerate and watch the engine run. Invite your friends to d/l a copy. (*) even if devs are not involved
What's a “dev”? No, seriously - what qualifications are required? (Hint: none) Can't a community agree on a new dev and begin a new updated wallet that every node/network uses?
Neither dev nor agreement is needed. It's called a fork and it's not illegal, immoral or fattening. HTH Cheers Graham (*) Happy to co-operate in an open online workshop to do exactly that |
|
|
|
There is more to any specific crypto currency than its code. Much more. Such as? See also: https://en.wikipedia.org/wiki/Contract“Each party to a contract must have capacity to enter the agreement.”
Cheers Graham |
|
|
|
Someone needs to help cryptopia fix the sprouts wallet. They are most likely going to "delist" it after they fix the wallet issue. copy and paste below to my ticket there.
we only have an issue with sprts wallet constantly crashing (30-40 times a day)
Perhaps you might be able to persuade these apparent numpties that they are experiencing an issue unique to them and to include the output from the debug log? Client version and host platform architecture are also sort of vaguely useful for remote diagnosis of locality-specific issues. Is anyone else's installation of the Sprouts client also crashing 30-40 times a day or is it just an issue for Cryptopia? Just a thought, ask them what value they have assigned to reservebalance. Cheers Graham Edit: added reservebalance suggestion |
|
|
|
I was a bit confused because you one page ago recommended to use the testnet to test the 0.5 code. But I assume with your latest changes you consider it ready for mainnet.
The code compiles, the tests pass, the app syncs and handles the protocol. Those are the only verifiable criteria in this specification-by-implementation context. The only real consensus change with respect to 0.4 should be the addition of the OP_RETURN opcode, am I right?
Mostly. I have been reporting informally as I made progress. I will create a Changelist file, (based on the commit record). I get an error here (using the qmake/make method): In file included from src/qt/inscriptiondialog.cpp:2:0:
build/ui_inscriptiondialog.h: En la función miembro ‘void Ui_InscriptionDialog::setupUi(QDialog*)’:
build/ui_inscriptiondialog.h:78:22: error: ‘class QLineEdit’ no tiene un miembro llamado ‘setClearButtonEnabled’
lineEditMsg->setClearButtonEnabled(false);
^
Makefile:1917: recipe for target 'build/inscriptiondialog.o' failed
make: *** [build/inscriptiondialog.o] Error 1
The error indicates that you are using a version of Qt earlier than Qt 5.2 ( http://qt.apidoc.info/5.2.0/qtwidgets/qlineedit.html#clearButtonEnabled-prop). I doubt that C++ #ifs will work in XML so you cannot use #if QT_VERSION >= 0x050200 to isolate the code, so you need to delete lines 130-132 of src/qt/forms/inscriptiondialog.ui. (Sorry for the "Spanglish", but it should be understandable - "función miembro" should be "member function" and "no tiene un miembro llamado XX" is "hasn't a member called XX")
No hay problema, yo hablo poquito castellano. my long-term idea is to port PeerAssets (when it's ready) to Slimcoin, so we could have a crowdfunding platform It uses OP_RETURN and would need almost no porting effort. That's one approach, I have to say I'm underwhelmed by the chosen analogy. I'm intending to pick up on a nice little paper written by fellow Labbie, Jeremy Carroll (yeah, go on, accuse me of cronyism): Assuming P<GI<NP, the creation and verification of a digital signature of an arbitrary RDF graph cannot be done in polynomial time. However, it is possible to define a large class of canonicalizable RDF graphs, such that digital signatures for graphs in this class can be created and verified in O (n log (n)). Without changing its meaning, an arbitrary RDF graph can be nondeterministically pre-canonicalized into a graph of this class, before signing. The techniques in this paper are key enablers for the use of digital signature technology in the Semantic Web.
This technique should work comfortably with RDF graphs which formally describe the state change and whose canonical digital signature can be inscribed in an OP_RETURN and for which existing inference engines such as FAST++ can do the heavy lifting. - I think you know my identity.)
Sorry, I don't. Cheers Graham |
|
|
|
I have a slight doubt: Is 0.5 now enabled for mainnet or still testnet-only?
It has returned to normal behaviour, i.e. defaulting to main but configurable (via both command-line option and config file) to use test. I mused on it for a bit, trying to get a better understanding of the purpose of testnet. Bitcoin Core now has three networks, main, test and regtest. The way testnet coins are now generated points to a difference - for Bitcoin Core, testnet coins are generated via RPC console command generate <n> <N> where <n> is the number of blocks and <N> is the number of guesses (too few = no blocks). Regtest network behaves the same as main. I infer that test is for testing changes to the basic protocol and regtest is for running protocol usage experiments. Or vice versa. In principle, the public ledger must be safe from J. Random User's dedicated-but-individual attempts hack their copy of the client to suborn the network to their personal advantage. I am no different from J. Random User except that my intentions are allegedly beneficial (says me) so by the same token, the network should be safe from any of my individual efforts whether deliberately or inadvertently mounted. Of course, if I can persuade > 50% of users to join my camp, then whatever I've done to the protocol/functioning will become the new norm. Testnet gives me some protection from any inadvertent ganging up on the currently-accepted consensus but then again, I hadn't introduced any significant changes to the functioning of the engine, merely adjusted the timing belt, to use a motoring analogy. But I'm always acutely aware that the numbers represent far more than just public ledger accounting - humans are involved. Cheers Graham |
|
|
|
After I've posted this, I'll fire up the Sierra VM, update the OS X app, similarly update the release binary and advertise it here.
The OS X GUI client in the 0.5 release section has now been updated. Cheers Graham |
|
|
|
Yuck, that's a very tangled mess. I'll have to leave that approach for another time. Instead, I tracked through the commit history (tedious but effective) until I found the offending commit. I had omitted to follow-up on a crucial detail on removing the C99 “PRI64*” macros. Issue has been resolved with the latest commit: https://github.com/slimcoin-project/Slimcoin/commit/43621ddb701b01e2df36e87113e034a10accaafcand I have updated the Windows binary slimcoin-qt-v0.5.0-win32.zip listed on the 0.5 release download pageAfter I've posted this, I'll fire up the Sierra VM, update the OS X app, similarly update the release binary and advertise it here. I've also discovered the issue with the snapshot - haven't checked the bootstrap yet - it needs be of a datadir for a client that was compiled to use BDB 4.8 - I'll configure my headless client on the server to use BDB 4.8, create a fresh snapshot on the server and also advertise it here. Cheers Graham |
|
|
|
For i can see it seems a problem with the mgw47-mt thing
Indeed:
g++ -Wl,--large-address-aware -static -static-libgcc -static-libstdc++ -Wl,-s -mthreads -Wl,-subsystem,windows -o release\Coin-qt.exe object_script.Coin
-qt.Release -L"c:\Qt\4.8.5\lib" -lmingwthrd -lmingw32 -lqtmain build\bitcoin-qt_res.o -LC:/deps/miniupnpc -lminiupnpc -liphlpapi -lshlwapi -LC:/deps/boost_1_5
5_0/stage/lib -LC:/deps/db-4.8.30.NC/build_unix -LC:/deps/openssl-1.0.1j -LC:/deps/qrencode-3.4.4/.libs -lssl -lcrypto -ldb_cxx -lws2_32 -lshlwapi -lmswsock -lo
le32 -loleaut32 -luuid -lgdi32 -lboost_system-mgw47-mt-sd-1_53 -lboost_filesystem-mgw47-mt-sd-1_53 -lboost_program_options-mgw47-mt-sd-1_53 -lboost_thread-mgw47
-mt-sd-1_53 -lboost_chrono-mgw47-mt-sd-1_53 -lQtGui4 -lQtCore4
C:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -ldb_cxx
C:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lboost_system-mgw47-mt-sd-1_53
perhaps you'll have better luck with something like mgw49-mt-sd-1_55 or near offer. The resolution lies in the <coinname>.pro file, look for where BOOST_LIB_SUFFIX is bound and ensure the numbers match the versions of the installed mingw and boost packages. Cheers Graham |
|
|
|
this is the debug last lines,
hope it,s enough
Thanks ... me too I have a trial Windows VM and a 4 year-old step-by-step guide. I'll let y'all know how I get on. Cheers Graham |
|
|
|
I am using actually the last version (0.5 windows)
But it does crash all the time,
Details? I've noticed that the Windows 0.5 binary also crashes on the wine emulator in my Ubuntu 17.04-pre distro but that might be unrelated. I'm definitely not in a position to comment w.r.t. different Windows versions. I would like to know if someone has the same problem or if it is just me.
Impossible to assess, atm: absence of evidence is not evidence of absence. Cheers Graham |
|
|
|
Could anybody post a list of live nodes?
Sure. addnode=37.187.100.75:41682
addnode=212.243.7.37:57208
addnode=161.53.40.94:54692
addnode=217.175.119.125:35959
addnode=217.65.8.75:34987
addnode=217.65.8.75:27670
addnode=5.9.39.9:41682
addnode=212.74.203.97:21773
addnode=91.20.13.10:56064
addnode=92.193.110.121:48782
addnode=92.193.110.121:40066
addnode=92.193.110.121:51681
addnode=5.105.63.44:64536
addnode=94.25.179.179:53001
addnode=39.128.196.200:2410
You may wish to try a release binary: https://github.com/slimcoin-project/Slimcoin/releasesOr, if you can use (install) Vagrant and Ansible, you can use the vagrant+ansible deployment script on an Ubuntu 16.04 VM to cross-compile your own “untouched by human hands” Windows binary: https://github.com/slimcoin-project/ansible-slimcoin-qt-winCheers Graham |
|
|
|
1. Does anyone know if any of the following coins got rebranded? 2. Or ist this just a trashlist? 3. Anyone know what happened to that coins? All dead?  1. DYOR 2. Mostly 3. Yes, no. As of March 2016 (when I abandoned the effort as unprofitable [1]) ... a. Speak softly and carry a big dataset.
b. an invoice is on its way to you [1] (see what I mean?).Crowncoin and Slimcoin are both listed on an altcoin cryptocurrency exchange, that's all the contemporary data I can contribute. [2] Cheers Graham [2] Edit: Deepcoin is being currently being scoped for further development. |
|
|
|
you will fined it hard to get a good honest coin creator that will do a good job ( i have been looking for someone to fix an existing coins but no luck yet )
Which coin and what about it needs fixing? Cheers Graham |
|
|
|
|
Show Posts
