Hi Graham, glad to have you back.
I've not been away, so I'm not "back". I'm pushing 70 and the relative inactivity of long hours spent at the keyboard is becoming increasingly prejudicial to my overall heath, so for my own sake I'm obliged to reduce my level of engagement. I am happy to run a copy of this wallet, if you have the time to help me compile it please.
I'm sorry but I'm no longer in a position to provide support (see above) - which is why I shut the chain down back in February. Cheers Graham |
|
|
|
Does anybody know why the 0.16 testnet failed to mine?
-extro
Can't help you, i can#t even get in to compile. Tried ubuntu 16/18, and Mint 19 For Ubuntu 18/Mint 19, if you're working from a clone of https://github.com/datacoinproject/datacoin.git, you'll need: pushd ./src/madpool
protoc --cpp_out=. protocol.proto
mv ./protocol.pb.cc ./protocol.pb.cpp
popd
I guess I could update the repos if we can assume that everyone's compiling with modern Linux distros. Cheers Graham |
|
|
|
Hi guys. can we have a telegram channel in which to chat with others that are interested in Gapcoin? thanks
Would prefer Discord if possible J +1 Cheers Graham |
|
|
|
My 2 year necro-bump on this thread.
Mostly because I just saw that it auto-renewed on my domain bill from March. Not that roulettecoin.cc actually goes anyplace.
Anyone out there still running the wallet? Anyone care about the domain?
AFAICT, it's been just me keeping the chain going out of sheer bloody-mindedness having upgraded a while ago to a Core 0.16.2 version ( https://github.com/gjhiggins/roulettecoin-core/) but a few weeks ago I decided to call it a day, having mined a stupidly and terminally large number of coins and I shut down the remaining two nodes. So no, I guess no-one cares about the domain. If not I will take it off auto-renew and when it expires next year it just goes away again.
Seems like a plan. (If there is any interest, the chain is restartable, so speak up now or forever hold your peace.) Cheers Graham |
|
|
|
i think the wallet needs some more optimising
That's rather a thoughtless comment, given the complete absence of anyone who might be ready and willing to do this work. Was there any point to the statement other than it just being an opportunity for you to complain generally? Cheers Graham |
|
|
|
I did try on a 14.04 but it was not a "clean" setup
Works for me on a clean 14.04. sudo apt-get install qt4-qmake libqt4-dev build-essential libboost-dev libboost-system-dev libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev libssl-dev I used this install_db4.sh script to get and compile db4.8: #!/bin/sh
# Install libdb4.8 (Berkeley DB).
export LC_ALL=C
set -e
if [ -z "${1}" ]; then
echo "Usage: $0 <base-dir> [<extra-bdb-configure-flag> ...]"
echo
echo "Must specify a single argument: the directory in which db4 will be built."
echo "This is probably \`pwd\` if you're at the root of the bitcoin repository."
exit 1
fi
expand_path() {
echo "$(cd "${1}" && pwd -P)"
}
BDB_PREFIX="$(expand_path ${1})/db4"; shift;
BDB_VERSION='db-4.8.30.NC'
BDB_HASH='12edc0df75bf9abd7f82f821795bcee50f42cb2e5f76a6a281b85732798364ef'
BDB_URL="https://download.oracle.com/berkeley-db/${BDB_VERSION}.tar.gz"
check_exists() {
which "$1" >/dev/null 2>&1
}
sha256_check() {
# Args: <sha256_hash> <filename>
#
if check_exists sha256sum; then
echo "${1} ${2}" | sha256sum -c
elif check_exists sha256; then
if [ "$(uname)" = "FreeBSD" ]; then
sha256 -c "${1}" "${2}"
else
echo "${1} ${2}" | sha256 -c
fi
else
echo "${1} ${2}" | shasum -a 256 -c
fi
}
http_get() {
# Args: <url> <filename> <sha256_hash>
#
# It's acceptable that we don't require SSL here because we manually verify
# content hashes below.
#
if [ -f "${2}" ]; then
echo "File ${2} already exists; not downloading again"
elif check_exists curl; then
curl --insecure --retry 5 "${1}" -o "${2}"
else
wget --no-check-certificate "${1}" -O "${2}"
fi
sha256_check "${3}" "${2}"
}
mkdir -p "${BDB_PREFIX}"
http_get "${BDB_URL}" "${BDB_VERSION}.tar.gz" "${BDB_HASH}"
tar -xzvf ${BDB_VERSION}.tar.gz -C "$BDB_PREFIX"
cd "${BDB_PREFIX}/${BDB_VERSION}/"
# Apply a patch necessary when building with clang and c++11 (see https://community.oracle.com/thread/3952592)
CLANG_CXX11_PATCH_URL='https://gist.githubusercontent.com/LnL7/5153b251fd525fe15de69b67e63a6075/raw/7778e9364679093a32dec2908656738e16b6bdcb/clang.patch'
CLANG_CXX11_PATCH_HASH='7a9a47b03fd5fb93a16ef42235fa9512db9b0829cfc3bdf90edd3ec1f44d637c'
http_get "${CLANG_CXX11_PATCH_URL}" clang.patch "${CLANG_CXX11_PATCH_HASH}"
patch -p2 < clang.patch
cd build_unix/
"${BDB_PREFIX}/${BDB_VERSION}/dist/configure" \
--enable-cxx --disable-shared --disable-replication --with-pic --prefix="${BDB_PREFIX}" \
"${@}"
make install
echo
echo "db4 build complete."
echo
echo 'When compiling bitcoind, run `./configure` in the following way:'
echo
echo " export BDB_PREFIX='${BDB_PREFIX}'"
echo ' ./configure BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include" ...'
I copied install_db4.sh into the contrib directory and from there, executed Then I edited coiledcoin-qt.pro as follows: diff --git a/coiledcoin-qt.pro b/coiledcoin-qt.pro
index 2e1f26f..26739e8 100644
--- a/coiledcoin-qt.pro
+++ b/coiledcoin-qt.pro
@@ -1,5 +1,5 @@
TEMPLATE = app
-TARGET =
+TARGET = CoiledCoin-Qt
VERSION = 0.5.99
INCLUDEPATH += src src/json src/qt
DEFINES += QT_GUI BOOST_THREAD_USE_LIB
@@ -251,6 +251,7 @@ isEmpty(BOOST_THREAD_LIB_SUFFIX) {
isEmpty(BDB_LIB_PATH) {
macx:BDB_LIB_PATH = /opt/local/lib/db48
+ unix:BDB_LIB_PATH = ./contrib/db4/lib
}
isEmpty(BDB_LIB_SUFFIX) {
@@ -259,6 +260,7 @@ isEmpty(BDB_LIB_SUFFIX) {
isEmpty(BDB_INCLUDE_PATH) {
macx:BDB_INCLUDE_PATH = /opt/local/include/db48
+ unix:BDB_INCLUDE_PATH = ./contrib/db4/include
}
isEmpty(BOOST_LIB_PATH) {
@@ -295,7 +297,7 @@ LIBS += -lboost_system$$BOOST_LIB_SUFFIX -lboost_filesystem$$BOOST_LIB_SUFFIX -l
contains(RELEASE, 1) {
!windows:!macx {
# Linux: turn dynamic linking back on for c/c++ runtime libraries
- LIBS += -Wl,-Bdynamic
+ LIBS += -Wl,-Bdynamic -ldl
}
}
I ran qmake with qmake USE_UPNP=- USE_QRCODE=- USE_SSL=- RELEASE=1 and got a compiled Qt client. HTH Cheers Graham |
|
|
|
Going to have to figure out what my system does not like about the old code.
There are a host of forward-incompatible issues to be resolved (Qt4->5, Boost1.4->1.6, OpenSSL1.0->1.1). Perhaps a better approach that acknowledges the historical focus is to try compiling on a VM hosting a suitable vintage OS (OS X 10.5, Ubuntu 14.04 or Windows 7). Cheers Graham. |
|
|
|
If your compiler/architecture does not support 128 bit integers and you need them, you could use boost to emulate them:"
Er, "it requires a multiple precision arithmetic library that can handle 128 bit numbers" - are you unaware of the difference? Perhaps a quote from the Prime Gap Searches group of the Mersenne forum will make it clear: "the crucial part would be to find efficient 128 bit replacements for mulmod / powmod. And extending the segmented sieve (bit buckets) to more than 64 bits might also be tricky". To spare myself further apparently futile explanation, I'll consider the matter closed unless/until you can come up with some concrete, detailed suggestions for changing the mpz functions in PoWUtils.cpp and Sieve.cpp sources so they are able to perform 128-bit arithmetic. Cheers Graham |
|
|
|
It seems Sha512 supports up to width of 128 bit numbers.
If any work is done ... using int128_t, uint128_t.
The Government ... while the Math hardware can carry on regardless.
You seem to have gotten carried away more than usual, that doesn't make any sense at all - not even to you, I'd guess. The show-stopping obstacle to your suggestion of using 128 bits is that it requires a multiple precision arithmetic library that can handle 128 bit numbers - which doesn't yet exist. Until it does, your suggestion is completely impractical and you're wasting your and everyone else's time in publicly pushing for it. Cheers Graham P.S. SHA512 keys have been available in Bitcoin Core since the release of 0.13 with the migration to hierarchical deterministic keys. |
|
|
|
chainz hosting of Gapcoin block explorer has expired and will be removed in a few days if not renewed. Contribute to GapCoin Explorer hosting costs!
By contributing to the hosting costs you can extend for how long the explorer for GapCoin will be hosted.
Hosting for this blockchain expired on 2019-12-06 10:11 (about 5.3 days ago)
It's 8.90 euro for a month. Cheers Graham |
|
|
|
Sorry i've been so long coming back, i tried to remove openssl, and removed too much.....had to do a full rebuild,
It happens. I'm relieved that it built okay in the end. sudo add-apt-repository ppa:bitcoin/bitcoin sudo apt-get update sudo apt-get install libdb4.8-dev sudo apt-get install libdb4.8++-dev git clone --branch v0.9.3-gap https://github.com/gjhiggins/gapcoincd gapcoin git submodule init git submodule update ./autogen.sh ./configure --with-incompatible-bdb --without-miniupnpc make If you're going to the effort of installing libdb4.8, then you can omit the --with-incompatible-bdb, as libdb4.8 is the compatibility standard. Compatibility is for when a user migrates from a client linked against libdb4.8 to a client linked against a later version, say libdb5.3. On running the libdb5.3-linked client, the wallet is automatically upgraded to use the later version. If the user then decides to revert to the client linked against 4.8, that client can't load that upgraded wallet. Trivial solutions: save the wallet before trying a new version of the client or don't revert. Complex solution: always link against libdb4.8 unless --with-incompatible-bdb is specified in the compilation instructions. Practical solution: always build binaries for proprietary OS linked against libdb4.8 or make it SCREAMINGLY CLEAR that the binary uses the latest-and-greatest, faster, more robust version of libdb and to SAVE THE FECKING WALLET before continuing. i don't know if this is the version with your updated POW
Well, it built okay, so it must do, else it wouldn't build under Mint 19.2 Cheers Graham |
|
|
|
allocators.h:15:10: fatal error: openssl/crypto.h: No such file or directory
That's an understandable failure on the part of the compiler but it's a bit odd that the headers are missing - they should be there if libssl-dev has been apt-installed. On Mint 19.2, the openssl headers will be in /usr/include/openssl. If that directory isn't present on your system and you have done apt install libssl-dev, then I don't know what to suggest, sorry. Cheers Graham |
|
|
|
Hi guys,
Well thought i'd do a clean install of Mint 19.2 and try the latest GAPCOIN build.
So i followed gjhiggins / usernamenumer7 's instructions
./autogen.sh: 5: ./autogen.sh: autoreconf: not found
I'm sorry to say - that's the point at which you should have stopped. A missing autoreconf suggests an omitted step in the procedure, that of prepping the OS for compilation. j0nn9 has edited doc/build-unix.md to be specific to gapcoin. If you follow the instructions there (using the gapcoin code from my repos) you should get a successful compilation on a clean install of Mint 19.2 (actual under-the-hood distro Ubuntu 18.04). It also works on Ubuntu 19.10. As regards to Windows builds, the situation is pretty dire. Bitcoin Core uses the only reliable approach, that of including a specification of all the dependencies and a scheme to compile and link them locally. See https://github.com/bitcoin/bitcoin/blob/master/depends/README.md. The problem is that Gapcoin is Core 0.9 and the depends system was introduced in Core 0.11 and two issues complicate the approach of simply copying over from Bitcoin 0.11. Firstly, the gmp amd mpfr packages need adding to the list of dependencies and secondly, the source code for the dependencies to be compiled isn't included, it's downloaded from specified URLs and, because of the passage of time, some of the URLs no longer resolve (Qt specifically has gone from "official" to "archive" which is where I called it a day after several hours plugging away). If these issues can be resolved, then it has a chance of working on a Xenix installation and might even produce an executable Windows binary. Cheers Graham |
|
|
|
Cool, but I have given up on other Linux distros so no worries about boost 1.67 but it might help someone else.
You asked, I answered. I'm trying hard not to regard that as a waste of my time. What are the full implications of using ./configure --with-incompatible-bdb --without-miniupnpc?
Is it possible to compile using BDB 5.3 ect......? Would it only require doing it all the time in the future for wallets?
Could I transfer my coins from a BDB 4.8 wallet to the new Gapcoin wallet using BDB 5.3?
Answers to these questions can be found by reading the appropriate documentation. Cheers Graham |
|
|
|
Mint uses Boost 1.65 would it still compile on Linux with Boost 1.67?
I have successfully compiled the gapcoin v0.9.3-gap branch on an Ubuntu 19.10 system. I checked the compilation under Ubuntu 16.04 (the earliest version of Ubuntu still supported) and added (and documented, in doc/build-unix.md) a couple of patches to allow gapcoin-0.9.2 (the “official” distro) to compile under Ubuntu 16.04. In gapcoin-0.9.3, I've changed rpcserver.cpp in order to get to compile successfully under Boost 1.67 (and Boost 1.65) and have committed the change (to https://github.com/gjhiggins/gapcoin.git). I haven't yet committed the gapcoin-0.9.4 branch that I'm working on. Cheers Graham |
|
|
|
I learned that git submodule update needs to be git submodule update --remote --merge
But, reading more extensively, I realised what I'd been missing. Previously, when looking at the status of the changes, I thought that git was offering me the option of including all of PoWCore in the main Gapcoin repos ... well, I mean, who wouldn't? ... On branch v0.9.3-gap
Your branch is up-to-date with 'origin/v0.9.3-gap'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
(commit or discard the untracked or modified content in submodules)
modified: src/PoWCore (new commits, untracked content)
no changes added to commit (use "git add" and/or "git commit -a")
But when I looked at the actual difference, it was offering to update the reference from: ID : ca5e863b1ff6c0a9655fadb951f1d9653ba24ef1
Author : Jonny Frey <j0nn9.fr39@gmail.com>
07/01/2015 22:43
Message:
1024 max shift should work for all
to: ID : 5cdfb1fcdfe932cb10eab567048cb95d1fc13979
Author : Graham Higgins <gjhiggins@users.noreply.github.com>
26/10/2019 11:04
Committer: GitHub <noreply@github.com>
26/10/2019 11:04
Message:
Update PoWUtils.h
Address compilation failure
which is actually what I wanted. So I committed the change and the submodule update now works correctly as before, i.e. git submodule update and doesn't need the --remote --merge any longer. We can all breathe a sigh of relief  Cheers, Graham |
|
|
|
|
Show Posts
